
Throne of JS: Eight JavaScript MV* Libraries Compared - jashkenas
http://blog.stevensanderson.com/2012/08/01/rich-javascript-applications-the-seven-frameworks-throne-of-js-2012
======
Maciek416
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.

------
ilaksh
<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
Agree on widgets. Have you seen the Web Components effort?
[http://dvcs.w3.org/hg/webcomponents/raw-
file/tip/explainer/i...](http://dvcs.w3.org/hg/webcomponents/raw-
file/tip/explainer/index.html)

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...](https://dvcs.w3.org/hg/webcomponents/raw-
file/tip/spec/shadow/index.html)

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...](http://html5engineers.com/projects/playing-with-web-components)

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

~~~
ilaksh
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.

~~~
deafbybeheading
Is it? One could argue that divorcing widgets from backend infrastructure so
thoroughly is an asset.

~~~
ilaksh
Almost everyone does argue that.. sort of.. only there usually is no argument.
Its taken as a given in most cases.

That belief is more a result of where we have been than on a logical
assessment of where we are now.

If your back end team is separate from your front end team, programming in a
different language, building a codebase to support multiple departments or
multiple third-party integrators with a single web API for a one-of-a-kind
world changing application running primarily in HTML browsers, then it may not
make a lot of sense to try to package together the back end and front end code
the way I am suggesting.

However, if your goal is to create an easy to use desktop-like website/web
application building/editing experience that maximizes code reuse across
applications (built on the same framework) on a
Node.js/WebSocket/MongoDB/HTML5 stack, however, then my approach with
packaging the back end code along with the front end code makes more sense.
Yes, you may need to add a REST API on top of the back end if you need that.

------
jarito
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.

~~~
steve-sanderson
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?

~~~
vtry
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).

~~~
steve-sanderson
OK. I was just taking it for granted that it was easy, because the same is
true in Knockout (viewmodels are entirely independent of views, and so are
trivial to unit test with QUnit or whatever else).

~~~
vtry
Pretty much only Angular and KnockOut and maybe 1 other js framework can do
real unit test

------
encoderer
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.

------
ebiester
"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. ;)

~~~
asolove
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.

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

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

~~~
WickyNilliams
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>

------
SchizoDuckie
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>

~~~
SchizoDuckie
[edit]whoops, wrong link: <http://goo.gl/gz7zo> [/edit]

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

[http://www.downforeveryoneorjustme.com/http://blog.stevensan...](http://www.downforeveryoneorjustme.com/http://blog.stevensanderson.com/2012/08/01/rich-
javascript-applications-the-seven-frameworks-throne-of-js-2012)

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

~~~
ryanhuff
It looks to be down again.

~~~
daemon13
Now up - all works.

~~~
davydka
Down again.

------
trung_pham
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.

------
ianstormtaylor
"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.

~~~
vtry
Angular meetup.

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

~~~
MindTwister
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._

~~~
unwiredben
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.

------
dj_axl
"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
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-sanderson
> 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.

------
netghost
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-sanderson
Nice one! It's cool to see these ideas expressed in such minimal code.

------
easternmonk
Incomplete without including YUI3 App framework.

~~~
drgath
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-sanderson
Eric's talk was more about general web development principles than about any
YUI technologies specifically.

------
malandrew
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.

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

