Ask HN: ExtJS vs. Backbone/Ember/Angular for huge Enterprise app? | Hacker News Reader

Ask HN: ExtJS vs. Backbone/Ember/Angular for huge Enterprise app?

12 pointsbjhoops110 comments

I have been doing some contracting work with a client that has an enormous Enterprise web application that they spent 100,000+ programmer-hours building in Adobe Flex. They are concerned about the viability of the Flex/Flash platform moving forward, and are looking to replace their application with an HTML5/JavaScript application.

I initially did some prototype work for them demonstrating a Backbone app, but now their team is leaning towards using ExtJS.

I have not worked with ExtJS before, but my gut reaction is that this would be a mistake, and they would be better served with something like Backbone (possibly with Marionette on top), Ember or Angular.

Are there legitimate reasons to avoid ExtJS (is it performant? can it dynamically load modules/JS resources not needed at startup?), or am I just biased because it is so Enterprise-y?

What do you think?

View on HN

I think you should avoid ExtJS. I believe you should avoid it because it's considerably heavier, hard to look at, and most importantly, there are some other people where I work that use it, and I don't envy them at all.

I feel that their development is held back in large part by difficulty understanding ExtJS, and difficulty finding documentation for a lot of things. Don't get me wrong, ExtJS has a very extensive man pages, but a lot of it is just descriptions (sometimes incomplete) of classes and methods -- where as when I last checked, the official guide was lacking.

I'm about 90% sure that ExtJS can dynamically load modules. It really depends on what kind of performance you are looking for for your app. There are some benchmarks out there, this one should help: http://jsperf.com/angular-vs-knockout-vs-extjs-vs-backbone

Like acesubido said however, Sencha is a resource that the devs are free to tap into and get support from if they buy a Sencha contract. This will be extremely important if you feel the team will have trouble adapting.

However, my general opinion (as stated above) is that ExtJS is more trouble than it is worth. From what I have seen, my colleagues spent more time making ExtJS components and trying to figure out what went where than building useful functionality. Also, from what I have seen (though this may be specific to my witnessed case) - choosing ExtJS means basically moving away from markup, in general. When looking through the code base of my colleagues (I had to help them debug their app alot), there was a metric ton of JS, but almost no HTML. ExtJS, though very powerful, abstracts almost too much from markup, and gets very heavy very quick.

If you're wanting them to learn HTML5 as they go, or even any HTML at all, they're gonna want to at least get a chance of writing it.

Please take all this with a grain of salt, I'm very biased against ExtJS because of how much trouble I've had with it -- as a confident developer I'd choose Backbone/Ember/Angular... If I wanted the safety net, I'd choose ExtJS

Avoid ExtJS like the plague. It is bloated nonsense that takes up hundreds of megabytes of RAM per tab for large applications. Extremely hard to do properly and almost impossible for UX guys to skin thanks to the over abstraction and the almost pathological fear of HTML in the library.

(anecdote: forced to work on a "cutting-edge" ExtJS 3 app for months. They had "customized" it so much just to get it to do what they wanted to do that they could no longer upgrade to later versions of 3 or the much better 4.)

I guess the reason why your client chose ExtJS of Sencha instead of Backbone/Ember/Angular is due to the level of support they can get from Sencha, not because of any advantages or what not.

Decisions like that don't come from developers, they come from the typical 'business guy'. Generally speaking bleeding-edge frameworks don't bode that well for any business guy. If a problem arises and a developer gets stuck, a developer just googles it and looks for ways to tinker with it - in the eyes of the 'business guy' they'd opt to throw money at the problem for it to go away, no time should spent troubleshooting or googling.

To sum it up: your client can't rely on a community of people that supports things only in their spare time. Thus by gaining comfort and trust from buying ExtJS contracts (https://www.sencha.com/store/extjs/) - whenever something goes wrong, your client's dev team gets stuck or needs training they can choke the hell out of Sencha for it.

Just let them go through with ExtJS. If the decision maker has consulted his devs long enough, it's a better decision. Being in one page and getting their things done quickly is far better than taking too much time learning things and contemplating on what framework to use.

"The reason why they chose ExtJS of Sencha instead of Backbone/Ember/Angular is due to the level of support they can get from Sencha, not because of any X number of features."

I would pay 10x more for consulting instead of support. The constant need for support means your team is incompetent. If you need external support to keep things moving, chances are you won't get very far.

"in the eyes of the 'business guy' they'd opt to throw money at the problem for it to go away, no time should spent troubleshooting or googling."

I'm also a co-founder and technical guy, I assure you spending money is always the last thing any company wants to do.

"Decisions like that don't come from developers, they come from the typical 'business guy'."

Lead engineers are usually who de-facto make those choices together with a CTO.

"To sum it up: your client can't rely on a community of people that supports things only in their spare time."

I've been running an 'enterprise' company with Rails, for almost 7 years now. Both the applications and the company are large. I don't really understand what 'rely on a community' means here. Who does not depend on open source software?

> I would pay 10x more for consulting instead support. The constant need for support means your team is incompetent. If you need external support to keep things moving, chances are you won't get very far.

Totally, agree

> I don't really understand what 'rely on a community' means here. Who does not depend on open source software?

I'm sure you know this - that's how a huge chunk of non-tech people view anything labelled with "open-source", they all view it as "unreliable" or "geeky". By how I constructed my sentence it seems I'm saying this from my perspective, but we're like minded in that aspect: everyone depends on open source software one way or another.

I'm just assuming that's how his client thinks.

I'm assuming the decision maker for his client is one of those 'guys' who's outside the tech bubble, and probably worse: they don't listen to engineers. I mean, if OP has already built a nice prototype on Backbone and it's all good why would they go towards ExtJS? Backbone is widely used and constantly worked upon, if his client is well aware of the software development industry they wouldn't just dismiss the prototype and go towards something with 5-digit contracts.

Again I'm just assuming the worst case scenario about OP's client by trying to understand the situation from what he said about their decisions.

> I'm also a co-founder and technical guy, I assure you spending money is always the last thing any company wants to do.

I'm also sure you know this: any hard-headed, non-tech decision maker outside the software industry who is very desperate would throw a lot of money for a problem to go away.

Having just finished a large Backbone.js app, I wouldn't pick that either. UNLESS, you're prepared to figure out going in a wide range of other libraries and add-ons you're prepared to mate with it in order to get a solution that really covers a variety of needs.

Backbone.js by itself is just missing so many pieces that the name is a real misnomer. I don't know anybody who could stand up if their real backbone was missing that many vertebrae.

I agree with you there - having built out even small to medium sized Backbone apps, you find yourself wondering what the "Backbone way" to do things is, only to find there is no "Backbone way." Something I've found which does a great job of filling in those gaps is MarionetteJS (https://github.com/marionettejs/backbone.marionette). Definitely worth checking out.

Google has some fairly large projects running with Angular. The entire doubleclick app is full Angular, it has ~200k lines of code with comments included and about 90k lines of just controller code. There's a talk about it on youtube, check the /angularjs channel for something with "doubleclick" in the title.

There's also tons of tutorials, videos, documentation and examples floating around.

I've been using it recently and it's really nice but I haven't personally used it on anything huge yet, not because I don't think it would work but because I have no huge projects atm.

In my honest opinion Dojo is a better choice than ExtJS. As was mentioned elsewhere, ExtJS abstracts you away from the HTML quite a bit, that being said for really large apps, ExtJS and Dojo are really the only two games in town. I have built some extremely large apps with Require/Backbone/jQuery/Underscore etc. and while it can be done, Dojo and ExtJS provide more uniform ways of doing it, think of them as more akin to Java where the other way is more akin to Perl one provides a well tested and integrated toolkit for building large apps. While the other allows you to add features from different libraries as you realize you need them, sometimes that leads to less constancy in the code base. But with good conventions and design you can build and app with Backbone/etc. that is just as maintainable and scalable as ExtJS or Dojo. There are all, after-all just Javascript when you strip it all away. When I use Dojo, I also use Backbone as the two are compatible and Backbone provides a far better design pattern for Hash management and routing.

I haven't worked with ExtJS but I've heard from developers I know that have worked with it that it is painful to deal with. Full of bugs, hard to customize, and overall just challenging to do anything with. It also has a pretty large footprint.

I think it would be a good idea to try to push for one of the other technologies you listed.

Reply on news.ycombinator.com