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.

Im currently evaluating a front-end architecture for a big app that will be developed by a team of about 6 developers + 1 web designer so that said, having a robust SVN friendly architecture is a must. So far I'm evaluating this two options:

  • A mixture of JQuery/UI/Mobile + Backbone/Underscore + Require JS + Twitter-Bootstrap
  • ExtJS 4

This are the requirements the architecture needs to meet:

  • SVN Fiendly (or Friendly depending on you previous experiences)
  • Active community and extensive documentation
  • Extensible
  • Easy to learn and to maintain (nice to have)
  • Cross-browser support (most of the time at least)
  • Support for Mobile devices
  • Easy to maintain (MVC, MVVM)
  • OpenSource (nice to have)

The previously mentioned ones meet most of the requirements in different levels and so far they are the only ones I've found about, am I missing any others?

share|improve this question
1  
Have you looked at knockoutJs? –  Kyle Hodgson May 25 '12 at 14:39
3  
Heh, I gather the first requirement is SVN Friendly instead of fiendly but the mistake is too funny to fix, SVN being the fiend that it is... –  Yannis Rizos May 25 '12 at 14:42
    
Cool! y just noticed, let me "fix" it –  Chepech May 25 '12 at 14:45
    
I just love people who down vote without givin any justification =). Thats the spirit! thats a great way to improve! –  Chepech May 25 '12 at 14:52
2  
I have an ex-colleague who has used jQuery, backbone.js and ExtJS. He really loves the combination of jQuery and AngularJS. jQuery is great for DOM manipulation, and Ajax calls. AngularJS actually tries to make you use an MVC architecture which is friendly to designers. –  Alan Jul 5 '12 at 14:15
show 2 more comments

2 Answers

I'm confused by your SVN requirement. I've never heard of a JS framework, tool or library causing problems for version control. It's all just static files typically.

The most important tool in any front end arsenal is a tool to eliminate crossbrowser woes and DOM API cruft at the source. jQuery is an excellent choice on that front.

jQ, runs on a design philosophy that everything on the front end should follow, IMO. It stays out of your way when you want it out of your way and it plays nicely with others.

I tend to be less impressed with JQ's libraries and plug-ins but I would leave those choices to your devs.

EXTJS, is the exact, diametric opposite. It is a heavy-handed framework that is very difficult to reverse engineer owing to an obtuse anti-pattern cascading inheritance scheme, it does awful things to the DOM and throws CSS at absolutely everything, right down to redefining the box-sizing CSS for EVERYTHING on the page and adding IDs to just about everything that doesn't already have one. I do not recommend EXT. We've been wanting to strip the last vestige of it out of our app for a year now but it's been too much of a pain to give it the proper time commitment. It cracks me up that the guys who wanted to create a JS library that is less than open source wrote the worst one to ever enjoy any popularity of the lot.

My impression of bootstrap is that it's a designer tool. Let your devs and designer decide if they want it. The JS components it provides are nothing special and it's written by people who handle decidedly lower levels of complexity than it sounds like you plan on dealing with. What I dislike about it is that it relies overly much on non-standard HTML attributes (now considered okay in HTML5, but still making HTML harder to read in my book) and hooks into pre-defined classes that describe styles rather than component types or content hierarchy. It's okay to have hooks in the HTML but I find it's best when the framework or library lets you set them.

I have not used backbone, but it's very popular. The turnoff for me was seeing it described as a lock-in framework by which the article's author meant that if you ever decide you want to move on and use something different, it's going to be hard to port your existing functionality out of it. I've had too many headaches of that nature with dismantling EXT to see that as an acceptable tradeoff for any benefit.

What I would seriously recommend is that you get your client-side team assembled first, then decide on tools in context to what you're using on the back-end and what your own front end experts consider a good idea for creating an easily extended app with code written for the long rather than short-term. In spite of the plethora of JS architecture frameworks, UI widget and pre-styled HTML libraries out there nowadays, my personal choice, when I have the choice, is to write my own UI, and wrap the jQuery soup in DIY architectural object schemes with ease of implementation and debug in mind. I also find I like the MVC pattern more for its general principles than exact implementation in a strictly client-side context.

In a complex front end app scenario, any tool that produces components that aren't easy to modify, sets restrictions on or otherwise pollutes the client-side environment as a whole, or poses the prospect of making it really hard to ditch the framework in the future is big no-no in my book. But take that with a barrel of salt. I'm a bit of a curmudgeon and hard to please when it comes to my tools, partially because I've had to put up with some really bad ones (CMSes in particular).

At the end of the day though, nothing I'm aware of has the same flexibility as DIY (except jQuery which really just eliminates UI boilerplate) but make sure you have a dev team that can get behind some sort of consistent architecture or they may indeed be better off with backbone or knockout, or JS MVC.

share|improve this answer
1  
I'd guess that version control friendly implies a set of frameworks that facilitate separation of code elements/function. So how easy is it to put the model in one set of files and templates in another an UX support with the "view"...? –  Murph May 26 '12 at 12:31
    
SVN Fiendly-ness usualy comes along with separation of concerns (just as Murph described), this means that you can have multiple people working at the same time in different layers of the application without unnecessary conflicts. As you'd probably know, in Javascript you can have all the application wrote in one gargantuan .js file which is great for reducing loading overhead but is as close to development hell as you can get. –  Chepech May 29 '12 at 16:59
    
Oh okay, well that's always up to you, the JS dev, typically. There's no framework I'm aware of that's going to insist you extend off of existing objects or call library functions in the same file as the definition. You should be able to split files as you please in anything that wasn't actually written with the intention to cause developer pain. –  Erik Reppen May 29 '12 at 19:02
    
@Erik Reppen: Actually if you implement the whole ExtJS MVC, you are forced to use a lot of files for models, stores, views, and controllers so on. They also offer a "compiler" that produces huge minimized files for production environments. The same goes of you use Backbone with RequireJS which is very similar. However this features are completely optional. –  Chepech May 30 '12 at 13:27
    
But those files are still intended to be static and untouched. You still reference the same namespaces in other files. Compiling is really just minification of local var names to single character values and elimination of unnecessary whitespace. –  Erik Reppen May 30 '12 at 15:33
add comment

I'm writing in ExtJS and using Sencha stack since 2008. I also use jQuery, YUI, Twitter Bootstrap and tried EmberJS. I love component-based approach that is promoted by Sencha. You create your UI from a set of ready-made controls. You put your data in models and tie them using controllers. If you introduce additional layers like global AJAX call handling, error processing and i18n, you've got a great foundation for a lot of projects. CRUD-based ones like admin panel or CRM can be done really quickly. There are certain dos and donts that you should keep in mind, but overall ExtJS allows you to be very efficient. However there are significant drawbacks:

  • It uses quite heavy DOM. In modern browser it doesn't matter a lot, but if you are writing for devices, this will be paintful. On a flip side, it's easy to override, say, Ext.Button's method that produces DOM and put DIV instead of table structure.
  • It's not that easy to customize the appearance. We ended up creating our own set of overrides and SASS mixins that we use in the projects. However, creating such foundation takes significant time, I admit. Styling jQuery app with lightweight DOM and Bootsrap is faster and easier. On the flip side, if you are fine with common themes, you have no problems and you get your product really fast.
  • ExtJS is for desktops. Sencha Touch is for devices. You cannot create product that works fine for both device and desktop. Good approach is use Sencha Touch and let it scale on desktop and tablet. But, hey, guys, approach to touch-based and click-based interfaces are REALLY different. So, yes, it's a problem, but you will get this problem anyway :-)
  • ExtJS is large. Yes, but you can customize the build. It would still be larger that jQuery, but it can do way more than jQuery for you :-) Minimize and serve it from CDN and you'll be fine
  • Custom components are not easy to create. Yes, if you need to extend ExtJS components, that's usually quick. However if you need your custom one or want to change existing component significantly, you'll get a headache. However, building GOOD jQuery plugin that does something useful is a pain too. I did both components for ExtJS and plugins for jQuery. When you use right approaches, both are complex enough, but I can't say that Ext is harder.
  • ExtJS doesn't have good routing. No excuse for that. Modern framework and modern app should provide it.

As a conclusion, I'd say that if your UI is large, but consists of a components youcn find in ExtJS palette and you don't need significant design updates, ExtJS is definitely the way to go. If you have something really customized, scaled from android phone to macbook pro retina screen, using custom controls and having completely unique look&feel, then check out jQuery, but combine it with structural framework like EmberJS and with CSS/component framework like Bootstrap. Given you learn that stack really good, you'll be quite efficient with that.

And never, never, never write in jQuery with ExtJS mindset and vice versa. Framework is a code+philosophy behind it's architecture and it's way. Learn it, follow it and you'll get good results.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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