Throne of JS: Eight JavaScript MV* Libraries Compared

http://blog.stevensanderson.com/2012/08/01/rich-javascript-applications-the-seven-frameworks-throne-of-js-2012

by jashkenas • 14 years ago

167 70 14 years ago

blog.stevensanderson.com

jblz• 14 years ago

"It's not just you! http://blog.stevensanderson.com looks down from here."

http://www.downforeveryoneorjustme.com/http://blog.stevensan...

steve-sanderson7• 14 years ago

Sorry, looks like I need to rebuild my Linode instance. It's back now.

ryanhuff• 14 years ago

It looks to be down again.

speg• 14 years ago

Still down.

peter_l_downs• 14 years ago

Just worked fine for me here.

jarito• 14 years ago

I wish he'd touched on testability. I chose Angular for my project because it is dependency injected by default and includes mocks for common tasks. This makes is possible to do the majority of my UI testing in unit testing which is much faster and easier than using something like Selenium.

ch0wn• 14 years ago

I really can't emphasize that enough. Angular's test support is by far the best any MV* framework I've seen has, at the moment. With dependency injection being the foundation of the framework, AngularJS has a major benefit over most competing products in this area.

steve-sanderson7• 14 years ago

Unit testing your viewmodels/scopes is great, but it's a totally different kind of activity to end-to-end testing via browser automation, isn't it? Unit testing will help with design, but end-to-end tests will catch an entirely different (and bigger) set of bugs. So don't you need both?

vtry4• 14 years ago

Most frameworks it is not possible to do proper unit test. With Angular, you can actually do it. As the controller is totally separate from the view (html/dom).

fuzzythinker2• 14 years ago

If meteor is included, I would say enyojs and derby (linked in his meteor's overview) should be too.

steve-sanderson7• 14 years ago

Is Enyo really a comparable kind of technology? I'm not familiar with it, and its website seems to imply it's for building mobile apps more than web apps.

fuzzythinker2• 14 years ago

I'm not using enyo, so I don't know from a dev's perspective, but according to http://enyojs.com/about/ , it is targeted to be cross platform, including all major browsers on the web.

quarterto• 14 years ago

Enyo is nothing like Meteor or Derby.

MindTwister• 14 years ago

They weren't there:

The premise was to take the seven top JavaScript frameworks/libraries for single-page and rich JavaScript applications — Angular, Backbone, Batman, CanJS, Ember, Meteor, Knockout, Spine — get the creators of all of them in one location, and compare the technologies head to head.

unwiredben2• 14 years ago

We had two Enyo engineers up there to talk to attendees, but we weren't able to get a speaking slot due to being a bit late to the event.

easternmonk• 14 years ago

Incomplete without including YUI3 App framework.

drgath• 14 years ago

Yup. Oddly enough, YUI had a core team member (Eric Ferraiuolo) at Throne of JS to talk about Y.App, but apparently didn't get a mention in the linked blog post. shrugs

steve-sanderson7• 14 years ago

Eric's talk was more about general web development principles than about any YUI technologies specifically.

scotty792• 14 years ago

Knockout is awsome. Check it out. You can grasp it over the afternoon and examples of advanced ui-s are interesting and concise.

rimantas2• 14 years ago

And then you try to use it for more complicated cases, run into limitations and switch to backbone.

scotty792• 14 years ago

I've done Backbone course in codechool.com It's very basic and targeted at beginners but in last lessons already I've seen how it becomes tangled and begins to fall apart.

I feel that Knockout provides you with much more structure that prevents you from making too much of a mess.

Custom bindings provide easy way to insane flexibility http://learn.knockoutjs.com/#/?tutorial=custombindings and the models don't look like hundredth attempt at just implementing CRUD. Also no re-rendering of html and no need for rebinding DOM events (vide http://ianstormtaylor.com/rendering-views-in-backbonejs-isnt... ).

Thus my noob preference.

krosaen2• 14 years ago

knockout and backbone serve different goals:

http://stackoverflow.com/a/6340870/231589

For me, the dependency tracking and automatic ui refresh provided by knockout hits the sweet spot, functionality that isn't in the scope of what backbone provides.

WickyNilliams• 14 years ago

I take issue with this kind of generalisation. I don't think these problems are inherent to knockout, but I do think there is a lack of architectural guidance on building large apps with it.

That said, building a maintainable, extensible knockout app is the same as building any other object-oriented system. First, decompose your app into multiple view models (a single view model doesn't have to be bound to the entire page) with clearly defined responsibilities. Combine that with a good Pub/Sub system [1] and you're most of the way there.

That said, it would be nice to see some examples of large-scale knockout apps, as there doesn't seem to be much discussion out in the open in this area. A perfect candidate (in my mind) would be for Steve to release the source code for the knockout tutorial site since that is fairly complex.

[1] https://github.com/rniemeyer/knockout-postbox

Maciek416• 14 years ago

I attended the conference, and the topic (framework vs. framework vs. library) was definitely timely. There are strong points of contention between the major competing frameworks/libraries right now, and this was reflected in the panel discussions.

What struck me about the talks I saw was the degree to which each project strongly reflects the personalities of its authors; Jeremy Ashkenas was indeed (as the article says) the calm zen master of the panels, taking a minimally-prescriptive stance on how his code should shape your code.

Tom Dale and Yehuda Katz, on the other hand, came in with passionate arguments for the idea that JS frameworks should have strong opinions and exert a great deal of influence on your code and the outcome of your solutions. Katz's central thesis seemed to be that for highly common problems for which Ember would be used, extremely similar (if not identical) solutions should emerge.

All in all a good conference, and very differently-flavoured from JSConf.

ilaksh7• 14 years ago

http://tjholowaychuk.com/post/27984551477/components

Those frameworks are great, but they all fail to take advantage of a key advance in software development: the widget.

Reusable, composable GUI components that package front end and back end files together and can be distributed easily as plugins are the next step up in abstraction and superior from a software engineering perspective.

The reason many web developers aren't able to either grasp or accept that is because A) understanding and building those types of components that are truly generic enough to be applicable to a wide variety of applications as well as reusable, has a significant learning curve and is time consuming and B) the better you are at it, the less likely you are to get credit for your programming skills, because unfortunately if you can build an application without typing colorful ASCII text, then you didn't do any programming and aren't a programmer.

To get past B) we just need to redefine what programming is, and also grow up a little. Also realize that even if you are programming with GUI components, you still have to create new components sometimes, so you are still programming and still a programmer.

I have a very early rough draft system that I am throwing together on my own, mostly because very few people seem to be able to appreciate these concepts. Or the ones that do are happy to use existing systems like ASP.NET or WordPress.

https://github.com/ithkuil/cureblog

https://vimeo.com/43784316 Note that I have modernized the interface somewhat since I made that video.

jmesserly• 14 years ago

Agree on widgets. Have you seen the Web Components effort? http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/i...

It's an attempt to standardize widgets at the browser level. Really cool stuff.

It's based on ShadowDOM, which is an encapsulation notion: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shado...

There are a few polyfills for playing with web components, such as Mozilla's http://x-tags.org/ and http://html5engineers.com/projects/playing-with-web-componen...

Also some of the frameworks do have a "widget" or "component" notion. For example, see "Create Components" at http://angularjs.org.

ilaksh7• 14 years ago

Right, web components and angular js components are an improvement, but they still emphasize manual ASCII coding, which defeats one of the main advantages of GUI components.

Also the strong separation and lack of cohesion between the front and back end systems is a severe limitation.

vtry4• 14 years ago

Angular directive is pure genius. Much more reusable than traditional "widgets"

lmm• 14 years ago

Coming from Wicket, the thing I'm really looking for to make reusable components more possible is a very weak templating system. I want inert, textual templates where literally the only thing they can do is define an anchor point at which the code inserts text, or another component. Maybe I have to write it myself.

unwiredben2• 14 years ago

Reusable widgets are the core of the Enyo JS framework (www.enyojs.com) that I work on under sponsorship of HP.

We had a few of the Enyo engineers up at Throne of JS, but we didn't get a speaking slot. Maybe next time.

nahname4• 14 years ago

Widgets are expensive to build into a framework and very limited in their application. They only fit the use-case of something that widgets are a core part of (iGoogle/widget pages) or something that is marketed at parttime programmers (Wordpress/blogging platforms).

If you can create a website from scratch. Using widgets in place of custom code is a waste of everyone's time, including the person who is going to extending and maintaining that application.

ilaksh7• 14 years ago

Widgets are very limited in their application?

I think that there may be a few full-time professional Swing, WPF, ActiveX, Wicket, Flex, ASP.NET, Sencha, WordPress, etc. developers who would disagree with you.

dsrguru• 14 years ago

The thing is, the sites that benefit most from these client-side-centric approaches are single page applications [1]. I'd imagine the benefits of having prewritten reusable widgets are the same for SPAs as they are for desktop software. They provide computer illiterate end users with an interface consistent with other similar applications, and like any form of abstraction, they make development faster and maintenance easier.

[1] I know some JavaScript lovers are convinced that client-side rendering is better than server-side even for non-SPAs, but I'm of the rather strong opinion that they're wrong. For non-SPAs that are sufficiently complex, the sexp model of server-side rendering in Clojure, Common Lisp, and Racket produces applications that are so much more concise than their client-side DOM-manipulating equivalents. For the few sites small enough that the overhead of macro writing/bottom-up development outweighs productivity gain, rendering HTML in Rails or Django is probably better than an all-JS approach.

cutie2• 14 years ago

How about the dojo widgets, do those qualify?

tmbsundar• 14 years ago

I was about to ask the same thing. How good is Dojo? This seems to be a complete framework with widgets support. How does this differ from the frameworks discussed above? When should I choose one over the other group?

nl2• 14 years ago

Angular.JS has widgets, eg: http://blog.angularjs.org/2012/05/custom-components-part-1.h...

rimantas2• 14 years ago

> The reason many web developers aren't able to either > grasp or accept <…>

The reason is simple: they have already been burnt and know better.

krosaen2• 14 years ago

In knockoutjs, bindings (and the ability to create custom bindings) are akin to widgets in they define exactly how view model state maps to and from the dom. I've created a number of custom bindings to bind things like a number range to a jQueryUI slider widget.

dj_axl• 14 years ago

"The only stalwarts here appear to be Backbone (other than its default routing feature, it works on IE6) and Knockout (which for now at least insists on total IE6 support)."

IE6 support is a must-have for me (corporate clients).

geon• 14 years ago

Is the ie6 support accidental or do the devs sacrifice maintainability, readability or performance to specifically support it?

It seems to me that since it is so small, and doesn't really do much, they'd have to go out of their way not to support ie6.

steve-sanderson7• 14 years ago

> they'd have to go out of their way not to support ie6

Oh, how I wish! Try searching the Knockout source code for "IE" and see how many special-case rendering and event bugs it has to work around. For sure, getting 90% IE6/7 support might be quite easy, but that last 10% is a real pain and that's the value of using a mature framework where someone else has already debugged the heck out of it.

ianstormtaylor• 14 years ago

"In my view, the strongest argument here came from the Angular guys who stated that in the near future, they expect DOM-based templating will be native in browsers, so we’ll best prepare ourselves for the future by adopting it now. "

Would love to know where this was discussed in more detail.

vtry4• 14 years ago

Angular meetup.

netghost• 14 years ago

For what it's worth, I've been playing around with making a really tiny MV* library called Ivy (http://adamsanderson.github.com/ivy/).

It's similar to Knockout with data binding, dom templating, and some nice debugging tricks.

The entire thing clocks in around 900 lines with comments, and has no dependencies so if you're curious, have a look.

steve-sanderson7• 14 years ago

Nice one! It's cool to see these ideas expressed in such minimal code.

ebiester• 14 years ago

"Agreement: Progressive enhancement isn’t for building real apps. All the technologies follow from the view that serious JavaScript applications require proper data models and ability to do client-side rendering, not just server rendering plus some Ajax and jQuery code. Quote from Jeremy Ashkenas, the Backbone creator: “At this point, saying ‘single-page application’ is like saying ‘horseless carriage’” (i.e., it’s not even a novelty any more)."

I really don't understand this. While I get WAI-ARIA for accessability, Google still depends on static content for indexing, last I checked. Are we just stuck doing two separate page flows? If that's the case, why bother with the framework at all if it's just doubling the workload?

(Note: I'm looking at a way to allow the initial rendering of the page statically, then using backbone to attach to events after the fact and use as a single page application after the fact. Handlebars and Hogan handle the templating on client and server side, and both client and server models are extending a common model shared with both.

It will be great if it all works. ;)

ilaksh7• 14 years ago

See my comment in this thread, I have a link to my github repo (and a video describing the project) where I have a solution to the static content on dynamic websites problem. My solution is to use PhantomJS to render static pages using the same code that the dynamic pages are rendered with.

asolove• 14 years ago

There are two answers here.

If your page is a content page, you should follow the pattern that YUI's MVC uses, which is to hydrate your model objects by scraping the html on the page. So you need templates shared (or similar) on back-end and front-end, you render them on the back-end with initial content, when dom ready happens you create models instances with the data that you grep out of that markup, and then as soon as the user does something you re-render that data with the client-side templates. Needless to say, this is less than fun. (Especially if you do i18n and need templates that can do so on both front- and back-end.)

The second answer is: web apps usually aren't for searchable content. Let's say you're a startup with information about local restaurants, and you add a Backbone app for finding things nearby and filtering by type. Google should crawl your external site (home page, marketing pages, etc.) as well as your data pages (one page per restaurant, one per type per city, etc.). And all those pages link to or include your shiny new restaurant-finder Backbone app/widget. But Google doesn't need to crawl that app.

For most users of Backbone, where their app sits behind a login wall anyway, worrying about search engines is irrelevant.

nl2• 14 years ago

Google still depends on static content for indexing

Actually, no. Google now will run JS in some cases[1]. I don't believe they have made public statements about when they do this, but I would suspect it may to to verify that the ajax-crawlerable version of the site[2] matches the real one.

[1] http://swapped.tumblr.com/post/23133779276/google-bot-now-cr...

[2] https://developers.google.com/webmasters/ajax-crawling/

andybak• 14 years ago

Throwing away Progressive Enhancement makes sense for things way at the 'App' end of the spectrum but it's going to spread like a cancer right up to the 'Content' end of things and if we're not careful one day we're going to look back and realise we've broken the web.

encoderer• 14 years ago

I recently had to choose between client-side frameworks for a fairly complicated browser-based application.

I had no real requirements, except that I really preferred easily using CoffeeScript. Obviously all of them can be used with CoffeeScript, but some easier than others.

I embraced and evaluated Batman. This was before they updated their documentation a couple months ago. Their docs were so brief that I had to consult the (partially annotated) source for basic things like bindings, routings, etc.

I built a little example in about 5 days and called it quits. When it gets to 1.0 I'll take another look. Their new documentation looks promising.

I then went pursuing frameworks with automatic 2-way binding like Knockout (and batman). I really didn't want to go w/ Backbone because it doesn't provide that feature. But what I ended up finding is that implicit 2-way bindings like that are more of a performance blackbox. Not altogether bad, but that they have enough downside that they're not an absolute must-have.

I ended up choosing Backbone flavor Chaplin.

Chaplin is an opinionated implementation of Backbone written in CoffeeScript. It implements a Pub/Sub message bus using Backbone Events. It gives you defined structure that makes it easier to get started. And it provides garbage collection which can be super helpful. When a controller (and its models) is swapped out there are a lot of circular references that have to be manually broken for it to be garbage collected. Chaplin takes care of that for us.

And Brunch.io includes Chaplin now in its default recipe, which is also super helpful.

ww520• 14 years ago

Knockout is pretty good. Simple to use and get the job done.

trung_pham• 14 years ago

Why are people so quick to dismiss Yahoo Mojito? All these frameworks only run inside the browser. A little ehh to me, nothing revolutionizing. Yahoo's Mojito is a game changer. It can run in the browser and on the server. And it's SEO friendly!

Really wish Yahoo does a better job at marketing their own framework.

SchizoDuckie2• 14 years ago

The one thing i'm missing most in all these frameworks is proper data access, offline

I agree that it's an awesome time we live in with an mv* framework coming out every day, but where's the love for offline apps? None of the frameworks seem to support grabbing data from SQLite in a proper way without including hundreds of extra kb's of js.

How about a real world scenario where you store products, and categories and prices in an sqlite database, and want to access and filter those, especially offline? There's no use in using a REST service, and you'd have to implement Sqlite Support yourself in all of them. (and no, compiling from coffeescript or depending on Nodejs doesnt count)

Building a (properly performing!) CRUD system for a tablet that works offline is still a hassle. That's why i'm currently working on CreateReadUpdateDelete.js, a project that aims to solve this by bringing my tiny ORM to JS.

Check it out if you're interested in a WIP, there will be a post here soon.

http://goo.gl/avnzk

SchizoDuckie2• 14 years ago

[edit]whoops, wrong link: http://goo.gl/gz7zo [/edit]

malandrew• 14 years ago

For those that are using AngularJS, the frontend guys over at Duolingo gave a great talk about using browserify to perform dependency injection into angular so it feels like you are using angular as a library instead of a framework. It was some really cool stuff.

Throne of JS: Eight JavaScript MV* Libraries Compared

Related Stories