Choosing the Right JavaScript Framework
airpair.com
airpair.com
Polymer is interesting because it's the first one that's geared around the idea that the browser is an app rendering engine, not a document reader. Being able to declare your own HTML elements and bind them together could very well be the future of web development. Unfortunately, it's still a bit immature to use commercially.
Hence, I chose React. It's idempotent, which is a fancy way of saying the markup it outputs is a strict function of the inputs it's given - no side effects, no externally-mutable state. This means you can live-edit your markup in your favorite editor without having to reload the browser on every save (using a tool called the Webpack Dev Server with the react-hot package). Using Webpack also means your dependencies are explicitly declared with `require` statements. It has all the benefits of Angular's Dependency Injector without all the boilerplate.
Finally, and perhaps most importantly, it has 0 dependency on the DOM. This means you can render your initial request on the server, and pass markup down to the client that's indistinguishable from what you'd traditionally get from Flask/Django/Rails/PHP. There are no assumptions that your client speaks JavaScript, so it's more friendly to non-browser clients like searchbots, which is in turn safer for SEO. It also means your view is already rendered when it reaches the client, which is important in a world where many clients are phones with underpowered JS capabilities. You get both the benefits of a single-page-app (slow client rendering is still faster than slower network requests, and network requests are smaller if you don't have to also send down the template every time) and those of a server-side one (SEO is maintained, and the client can display your page without waiting to execute the JS first).
I should disclaim that I haven't seriously considered Ember since it's been rebranded from SproutCore; however, I have worked on a few Angular apps; and even forgoing the above benefits, React is just easier to work with.
// When I say
<IconButton
link-to = "home"
src = "home.svg
/>
// give me
<a
class = "IconButton"
href = "/"
>
<img src = "home.svg" />
</a>
The best part is, thanks to React & Flux I'm building a large scale web app without jQuery for the first time in my life :)
Flux lets you cheat around that: Since you're using require statements, you can make an action and `require()` it in both the component it's dispatched from and the one that's listening to it.
// Traditional event bubbling
child.dispatchEvent(...) ----> parent.addEventListener(...)
// Reflux
child:action() ----> store.listenTo(action) ----> store.trigger(data) ----> parent.listenTo(store)
Honestly, I'm murky on the utility of the Store and even less confident in the utility of the Dispatcher. That's why I'm using Reflux instead of FBFlux, and I'm still tempted to skip the store and just listen to my actions from the parent component.
Are there any real world combinations of real time frameworks like Derby, Meteor, SocketStream, Mojito, or even Firebase+MVC with a pre-rendering engine like Polymer or Famo.us?
>This means you can render your initial request on the server, and pass markup down to the client
That's how derby works too.
Thanks for pointing this out, I'm always glad to see people taking responsibility for the quality of their contributions to the web and finding tools that enable good work.
<li ng-repeat="phone in phones | filter:query | orderBy:orderProp"> for me this is too much programming logic in html. Same goes for React.js too. Too much html + logic mixup, that requires two parsers to work in your head in parallel (html + javascript, and maybe even some css?). I find it messy.
None of it in ember. Logic is neatly separated. In ember I also really enjoy how you separate functionality on a single page into neatly defined controllers/routes/ and components.
Also the article says you add lots of <script> tags to your code. Not true. Using ember-cli you don't see any <script> tags.
https://www.youtube.com/watch?v=DgVS-zXgMTk
React is about separating concerns, not technologies. Everything you need to know to draw an App Bar is in AppBar.jsx. You can dynamically generate the markup with JavaScript, but that doesn't change your separation of concerns, because everything concerning that component lives in that file.
That being said, there's many times where I work with Backbone and I feel like its missing pieces it should have. I don't have too much experience with Angular but it seems to be a much more complete choice.
Backbone only is not enough to do any serious kind of work today.One always end up with tons of plugins making it as complicated as EmberJS or AngularJS. There is no serious view layer,so one has to use React,Vue,or Ractive. The router sucks,frankly,so one has to replace it. The model layer doesnt handle relationships between model,so one ends up using something else...
There is nothing good in Backbone today frankly.It was one of the first successfull "clientside" framework ,yet refused to evolve(like underscore or coffeescript today),refused to incorporate good ideas from third parties that would have made it still relevant today.
There is no future in Backbone.Maybe there is still a place for a Backbone like framework that would still be based on jQuery and would incorporate a better view layer. But Backbone itself is dead.
I personally prefer AngularJS ,not because of its directives but because I strongly believe in IoC containers over any other way to build and wire objects. But I think EmberJS is as good.
AngularJS was released in 2009 [1], whereas Backbone was released a year later in 2010 [2].
Sure,that's why i said
> It was one of the first successfull "clientside" framework
Did you miss the word successfull or what?
furthermore old angularjs looked more like Adobe Spry than current AngularJS,while Backbone hardly evolved(which is not good of course).
Backbone is a much simpler library than Angular. There's less of a need for it to evolve, since it's meant to be extended on a per project basis.
React will fit the bill here, and can be used with Backbone.
Backbone is easier to learn, agreed. I would recommend checking out a list of sites built with Angular & Backbone too.
Sites built with Angular: https://builtwith.angularjs.org/
Sites built with Backbone: http://backbonejs.org/#examples-documentcloud
Some of the pros are that it's easy to learn (e.g. if you know js, you already know the templating language syntax), and it's one of the fastest frameworks in the market right now.
There's also a more detailed comparison w/ other frameworks here: http://lhorie.github.io/mithril/comparison.html
I think they just could have added the line "As an alternative to using underscore templates in Backbone, you can use React instead."
- Flux Architecture Pattern [0]
- React Router [1]
Note that there isn't really a prescribed model in Angular aside from $scope either.
A model really isn't part of Angular core since it was split out but something like angular-resource is what I am talking about.
Anyone here got a real try on sencha (the full package, including sencha architect) recently ?
It got enterprise traction because they were early to the game and promised MVC. They were pretty good for a while, but the other frameworks have passed them by.
Compare Ext JS with something like Backbone and in addition to the way in which Backbone/Underscore helps you implement an MVC structure you've now got a whole host of UI widgets, a class/dependency system, an optional build tool in Sencha Command.
The things that you'd say were feature-matches from Backbone would be stuff like Controllers (and in v5 ViewControllers), but there's a lot of stuff (like refs) to help that work with the UI components. I'd say that where ever there's an equivalent feature in Ext JS it's going to be a lot more complicated!
This is a burden and a curse. Like the config system that was brought in for v4. Initially seemed like overkill, can occasionally be a godsend but when you're working on complex class structures can be a massive PITA.
On top of that you have the licensing costs and indeed the licensing itself which was something that put people off of Ext JS a few years ago when they changed it. Plus I suspect "enterprise" shops will be interested in Sencha Architect too, which bumps up the cost.
Sencha Command does wind me up a little bit because it feels like an opaque mess built on top of ant. I just wish they could use something like gulp and have each part be a little clearer. In fact if they opened it up to the community on github that might be enough, they're not charging for it so I don't see the harm.
Now, I'm pretty negative on client-side MVC anyway (see intercooler.js) so I'm probably not a fair judge, but if I were starting a project today that had to have a large client-side footprint, I'd avoid ExtJS.
I will say that ExtJS looks great OOTB and comes with a ton of widget functionality when compared with other options, so if you want to get something done really quickly with, say, a tree UI, that might be a reason to look at them harder.
ExtJS component life cycle changed a lot form 4.0 to 4.2 and they refactored the code to be more like Sencha Touch. I guess this is the preamble to ExtJS 5, and it confuses a lot of people.
Sencha delivers on cross browser compatibility, since their layouts are all done by JavaScript. Trying to add CSS layout on top of that will break a lot of things. This is the so called "fighting the framework" people in Sencha community calls it. ExtJS 5 lets you develop desktop/touch hybrid apps for touch laptops. With smooth scrolling driven by touch event and transition, they work on Android as well (where it doesn't have WebKit overflow scroll touch)
The thing about sencha that makes them different is that they abstract away the html and css parts to a large degree, by constructing the dom programmatically behind an abstracted component api (e.g., a panel component has a title bar, several toolbars, and multiple child components laid out using border, anchor, column or any of the other layout systems). The upside is that the ui controls are richer than standard html controls and require fewer lines to do advanced things (like having a field with server-backed autocomplete). The downside is that html+css skills don't translate well, if at all. Instead of thinking in terms of dom updates, html templates and style rules, you think in terms of the component lifecycle, the container layout system and themes. The skillset required is extensive and specific, and the code is so deeply tied to extjs that no part of it can be reused outside of it.
Some people like it, some people don't. You can't fight the framework. You have to adopt sencha's architecture and component system completely, or you will have a painful time. We have had to invest extensively in training because the framework is so different from other js frameworks that new developers have a hard time learning it.
As for the whole she-bang, sencha cmd, sencha architect and so on. I tried those tools several times, but they always lacked maturity. The last time i looked at it is 2 years ago though, so they may have improved. Meanwhile we just use the frameworks.
Update: I realized I didn't actually say whether I would recommend it or not. I would not choose ExtJS again, but I would choose sencha touch again, despite the API's being so similar. I feel like the use-case of writing a mobile cross-platform app fits in well with the sencha architecture and api, better than other js frameworks. By contrast ExtJS isn't bad, but it's no better than the free alternatives like ember or angular for building traditional web apps, so I don't see the point in spending the money on a license if you're starting from scratch.
Each framework has it's advantages, and it really depends on where you and your company align with those advantages. When I started my journey I realized I needed better testing for AJAX events in jQuery, which lead me to Backbone. But in 2012 Backbone seemed like an outdated solution to an outdated app landscape. Now it seems even more outdated, but learning it certainly helped elevate my JS game to choose between Angular and Ember (though now I'd through React/Flux and/or Meteor into the mix).
From there it's really about what you need, as I've said before. For me, a lightweight, performance-driven solution with a great testing framework was necessary. Angular is lighter weight than Ember, but both have great testing frameworks, so Angular won. If I wanted better documentation, an easier learning curve, or better community support (it happens that Rails people seem to like Ember because Yehuda works on it) I would have chosen Ember, but that wasn't important to me or my company. Again, that was 2012-2013, today I'm still using Angular but entertaining the idea of having React replace Angular directives, which I still don't like writing. Again, it's all about what works for you and your organization, and that really is about introspection, not about what some article can do to act as your oracle.
[1] http://code.tutsplus.com/tutorials/3-reasons-to-choose-angul...
Eh. Backbone is good for enabling small elements of interactivity on mostly-static web pages (a design which isn't dead yet and useful if you have a lot of people landing on a lot of individual pages from third-party sources search engines or the like, and you want to keep down page load times). Angular and Ember are much more targeted at fancy interactive web apps where you want to stay in one DOM for a longer amount of time while doing a lot of interaction or page manipulation.
So this part:
> the right framework is all dependent on what your needs are
This is javascript in general not just AnjularJS ... it seems that Google has created a framework that does a little too much. Half the time im doing something that has already been done a thousand times , either making a tab content layout, displaying a dialog , performing an ajax request and editing markup ... I dont need fancy scope for these things. And when I do ill write my own state machine. I feel like all the special AnjularJS features are built to handle stuff like google docs. Most of us dont need this, not every one is on the "kill the desktop application long live the web-app" koolaid ... And ill keep my js logic out of my view and markup, thank you very much (did we not learn this is for the lazy not the smart a long time ago)
Each framework follows such a different paradigm that it's hard to transition incrementally, especially if you're app has a rich data layer rooted in an existing framework's mentality (in our case the backbone model/collection/sync mentality).
I'd love a better view framework, but not if it requires a full rewrite of the model layer and all the related libraries.
Until there's a ruby on rails quality model/collection/associations library that can be paired with a performant view framework with two-way data binding, I'll just stick with backbone where things are simple. Even if it costs me a few extra keystrokes.
> A good rule of thumb is not to have more than 2,000 active bindings on the same page.
Anyone personally run into this? What are you supposed to do in angular if you need to listen to change events for thousands of models?
While angular has tons of beginner hype because of the bootstrap effect (don't learn a technology, just put it in your html tags!), I've found that marionette tends to attract a more mature developer crowd, and as a framework is much better suited to building large and complex apps anyway because of the strict modularity and separation of concerns. I say this from experience both seeing and working on very large and complex apps with marionette. And if you don't believe me, ask some of the developers at Etsy, who build with marionette.
The community is a hell of a lot smaller than something like angular, but I see that as a huge benefit, especially when that means no proliferation of beginner problems, and easy access to the core team for help or feedback.
There are also three excellent books[0] about Marionette, and about 3x more Marionette questions on Stack Overflow than React questions (for what that's worth).
We introduced it into our Backbone app and haven't looked back. It's great.
[0]https://leanpub.com/building-backbone-plugins https://leanpub.com/marionette-gentle-introduction https://leanpub.com/marionette-serious-progression
Actually Backbone is painful because of the two way data binding. You do have to write way more boiler plate, but forms and actions in views will update your models and so will content coming in from the server and your event listeners have to be able to ensure that your events don't runaway from you causing all kinds of problems. Like view action -> updates model -> listener sends something to websocket -> websocket sends a response event -> updates model -> listener sends something to websocket -> an error or infinite recursion.
I'm sure it's not going to be biased at all.
i think it might be better to use a non-trivial example and show side-by-side implementations for 10 or so important aspects (routing, templating, data binding, etc.), with commentary on what kinds of projects would benefit the most from each frameworks' approach to each aspect. since airpair is about selling programming expertise, this would demonstrate actual expertise that would be attractive to prospective customers (vs. the ability to talk about programming, which is easier).
It covers the same frameworks (Angular, Backbone, Ember) and also mentions Polymer and React.
~20$ for the early access version.
what i find interesting with these frameworks is that they're all moving the templating engine (something like coldfusion from 15 years ago, ha!) to the frontend... part of the ebb and flow of server vs client side computing i guess.
Assuming you're not spamming, submit an article yourself or talk about your framework's tradeoffs engaging points from the article above.
Personally, I'm a bit suspicious of any JS framework more than a few years old, barring a few notable exceptions (jQuery, bootstrap, etc.).
Dojo is just too large for me to feel comfortable using it in an app--with Angular or Backbone, I know there's only so much crazy in the tin; Dojo has mudballed a lot.
As for Meteor, I think this was a comparison of frontend-only js frameworks. I would love to see a Meteor vs. Rails vs Djano comparison however :).
Yeah, but so were Google Reader and Google Wave.
</shameless-plug>
If it reaches anywhere near its potential it's going to be awesome.
In a client side application,if the app is slow,the users wont be happy about it.
If it takes for ever to load,the users wont be happy about it.
On the server there is always caching so that requests never hit the app itself.
On the client,if the js code is slow ,for whatever reason,you cant hide it to the user.
What you say might be true on the server,these "features" definetly have to be balanced with performances on the client.That's why sometimes it make sense to use React over AngularJS,for instance,because Angular is known to be slow.
Furthermore, it allows for easier data portability- when you can 'collect' data as you go and have API calls that much faster, it's okay to make more expressive UI decisions.
Not to mention, at the end of the day I like having a separation between my frontend and backend. Frontend testing from Rails or Django always feels a little dirty, a little off, and in many cases is even a discouraged practice("If you need to test your view, you should be using a helper" logic). I also like not ever having to make model method choices based on what my frontend desires might be- the concerns can be completely separate.
And lastly, I frankly can do a lot more interesting things much faster in Ember than I can in Rails from a UI standpoint. Ember turned my favorite part of software development, UI design, into the joy it used to be when I was just using pad and paper.