Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We have been tasked with replacing a series of 25 year old mainframe applications with web applications. There are 4 applications in the series and we are trying to come up with a stack that will work on all 4.

Now these applications are big. Not huge, but big. Based on the work that our sister company did to replace similar pieces of their systems, the small one is expected to come in at about 150k lines of rest service code and about 80k of UI code. For the big one, a million of service code and 200k of UI code isn't out of the question. The small application, so far we have about 150 different views, The big one has about 500 we know about.

Now I understand that line numbers are a bad metric to use, but at the moment, its the best i got, so lets just go with that.

So in the world I typically work in, this is one medium size application and three large ones. The next issue we have. Across the board, all systems. No user action is to take more than one second. Meaning, if you come into an application, the app has to be loaded and ready to login within one second. If you click on a search button, the response has to be displayed within one second. We have people that use the mainframe systems that process paperwork and in order for them to hit their daily quota, they have to average a start to finish processing time of 15 seconds for each case. The green screens they use right now just barely hit that mark.

Dont get me going on eliminating the paper. State and Federal law requires it.

So we already know that we have to build the app in such a way that a user can use it without touching the mouse. No way are they going to hit their quotas if they have to be mousing all over the place. Thats not such a big deal, we can define hot keys to do that. But the big issue is the speed.

The typical internal framework is JSF. The standard is RichFaces, but many years of horrible performance out of Rich has finally convinced them to move to Prime. We would be about the 2nd or 3rd to use Prime. But since our performance requirements are the highest they have ever encountered, they asked my team to evaluate different frameworks. For internal applications, the current acceptable response time is between 5 and 7 seconds. Pretty typical in an enterprise, usually pretty easy target to hit with JSF.

So we spent the past 5 weeks evaluating various options and by leaps and bounds the highest performing framework was GWT. In our benchmarks it blew Vaadin and JSF/Prime completely out of the ball park. Also, aside from JSF, its pretty much the only thing we could find designed to handle applications of this size with surprising ease. (Struts and SpringMVC are strictly forbidden in our enterprise)

Then the problems started. Our Enterprise group said no, we can't use it. They acknowledge the fact that there is very little chance of JSF pulling off our performance requirements and the only practical way of hitting our goal is a thick browser front end, but, instead of GWT, they want us to use Angularjs. For the purpose of this post, lets not get into why they said no, lets just stick to the fact the answer was no.

So, the past 2 days, I started digging into Angular. So far, I'm not impressed. It looks ok for very small applications (compared to what I normally deal with) but I can't find anything anywhere that shows an experience in trying to build an application of the size that I need to build. The closest I found was a guy talking about his "Enterprise" application he built with Angular that was about 9k lines. He said it was a bitch to pull off, mostly from inexperience, but once he found the tool Lineman, it became tolerable and he was able to pull it off. In the applications I need to build, 9k lines won't cover the logic I need to build into my search UI (so far we have identified about a dozen different ways to search for various data, and counting). To say nothing about actually doing anything with the results.

So I called up two of our really, really good developers and asked their opinion. After we got past the initial "Your out of your mind, that's what GWT was built for" phase of the conversation, it was settled that to try to pull off apps of this size as single page javascript apps, like you can in GWT very easily, would be complete suicide. Angular just simply wasn't designed to go that big, it was designed for tiny stuff. Mobile apps, small web apps, etc. Nothing of this scale. The idea is we have to break the app into smaller modules. But, this brings the problem of how to transfer application state from one module to the other. This problem has been tackled at this company before with very poor results. But, they had an idea.

Since we can't switch out our Websphere servers for Node.js, Their suggestion was to try a hybrid approach. The idea is to create a JEE6 Conversation bean. Then create a JSF file for each module of the application. That JSF would be linked to the conversation bean. This way, each module can run Angular to handle the MC side and the V side can be basic HTML with Twitter Bootstrap to make it pretty. When the user switches from one module to another, the JS application state is posted to the conversation bean. The conversation bean then redirects you to the new JSF module page, then the JSF can grab the object that represents the current application state from the conversation and pass that to Angular, loads it and they are off to the races. Then of course Angular would talk to the REST services directly. We are using the slow ass JEE stack as little as possible, but still able to sorta easily move app state from one module to another.

The stack sounds ok to me. We have the ability to break the app into modules, if the module gets too big, we can break them into sub modules, use the conversation to move the state from module to module, and we can use Angular.

My problem with this stack is 2 fold. One, thats a lot of plumbing. Lots of things to go horribly wrong. Two, I can't find anyone that has tried something like this.

Questions: What is the practical size limit of an application based on Angular that does not have the benefit of Node.js sitting behind it?

I have been told by my UI programmers that when an application gets to the point of about 10k HTML elements within a single page JS module, the performance starts to degrade. When you hit about 25k elements, the performance drops off a cliff, and about 40k elements the app usually doesn't load. Are these numbers consistent with medium to large applications that you have written? For comparison sake, lets say Stack Exchange is a medium sized application, Google Drive is large.

Does a design pattern exist for this scenario. Meaning does a pattern exist where you can break a large JS based front end app apart into modules that can be handled easier by the JS frameworks by using JSF or some other system to transfer the application state from one module to another. The failed attempt made in the past was to post the app state object to a web service and that service store it in an application scoped EJB to be retrieved by the next module. That technique failed miserably when the app came under any kind of meaningful load.

Are there any other frameworks out there to consider that can give us the performance, scalability, flexibility, and ease of developing large applications like this that doesn't have Google in its name?

BTW, I was told about Angular Modules about 15 minutes before I walked out the door today. All I really know about it is its name. If you think it could help me, please let me know.

Thanks guys/gals. I'm really stumped here.

share|improve this question

closed as primarily opinion-based by MichaelT, Jimmy Hoffa, GlenH7, gnat, Robert Harvey Dec 24 '13 at 19:15

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

6  
Lines of code estimates are really useless as a metric for most things, but for this thing they're especially useless because language-to-language differences absolutely destroy their meaning completely. It's probably just like 2 or 3 lines of Haskell for all of those apps after all –  Jimmy Hoffa Dec 20 '13 at 23:12
3  
If the only medicine you had was a cyanide pill, would you take it when you got a headache? –  Jimmy Hoffa Dec 20 '13 at 23:25
2  
@scphantm "Have any of you tried to do a thick browser client app like this on this scale without using GWT?" - "Have any of you tried to do anything with Angular of this scale?" - "What do you think of our stack idea. What parts of it are going to get me fired 3/4 of the way thru?" ---- These are questions that are inherently poll like asking for many opinions on the subject rather than a problem and asking for a solution. –  MichaelT Dec 20 '13 at 23:35
4  
You don't have to go with single page web application approach. You can build a "traditional" web application (say, with JSP or even plain HTML) and place an angular application on each page. Such applications can reuse the same modules. Otherwise you would have to control the amount of data stored in browser (i.e. angular services and cached templates) This is not impossible. –  lorus Dec 21 '13 at 5:55
5  
My impression, after reading this question several times, is that you've given a lot of thought to the issues but not the problem. You don't need to load up the entire app at once, but you do have to be mindful of browser memory. But focusing on the front end, to me, seems wrong: data entry will always be server-intensive, so that should be where you look to solve performance problems. If you can offload some of the work using a tool like Angular, great (I've done this), but it's not going to solve the underlying problem of server workload. –  kdgregory Dec 21 '13 at 12:36

1 Answer 1

up vote 0 down vote accepted

I don't think the framework is mature enough for your purposes. I also think you'll be able to split up some of your logic by using good ajax... In terms of garbage collection, javascript sucks.

Sencha is probably closer to having the ability to support your needs... However, the one great thing about AngularJS is its ability to wrap the dom...

Backbone.js is another interesting starting point. While it is referred to as a framework, I view it as more of an advanced Object Oriented Object Abstract... I think that some of its architectural features, especially around garbage collection would help with your goals...

It sounds like you'll be wanting to do a lot of Ajax Updating to client side html elements, and migrate as much of your logic to the server as possible... In terms of searching I see no reason to build the logic into the UI more than you have to, that is what Ajax is all about.

One of the key JS killers of performance is string concatenation, take a look at array.join() if you plan on doing any string concatenation.

share|improve this answer
    
You may also want to look at Vanilla.js –  mprototype Dec 24 '13 at 18:15
    
and Foundation 5 w/ jQuery –  mprototype Dec 24 '13 at 18:15
    
Thanks for your help. Our tests with angular came up with same conclusion. We are going to strip JSF to the bone, no faces, no nothing. just the basic template engine, AJAX, and Twitter Bootstrap. Hopefully we can get some speed out of that, but since its still JSF/JEE, i highly doubt we can get the speed we are looking for out of it. –  scphantm Dec 24 '13 at 20:26
    
ironically if iOS didn't kill Flash Player as a viable client... Adobe Flex and amf data would handle what you're seeking without blinking. We'll see how long the javascript world takes to catch up, but it does seem to be moving in the right direction. –  mprototype Dec 24 '13 at 20:36
1  
A few years ago, same client actually spent $10 mill rebuilding one of their legacy systems on Flex. 3 months after deployment they were having such massive problems with maintenance, scaling, and compatibility that they decided to scrap the whole system and rewrite it a second time. Thats pretty much the same experience i had at another large client. Only it took them a year to make the same choice, not 3 months. –  scphantm Dec 24 '13 at 23:06

Not the answer you're looking for? Browse other questions tagged or ask your own question.