Throne of JS: Eight JavaScript MV* Libraries Compared
blog.stevensanderson.com
blog.stevensanderson.com
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.
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.
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.
Also the strong separation and lack of cohesion between the front and back end systems is a severe limitation.
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.
We had a few of the Enyo engineers up at Throne of JS, but we didn't get a speaking slot. Maybe next time.
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.
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.
That said, there are no doubt good examples using those technologies to do useful things. I am not arguing that widgets make it impossible to create useful things. I am arguing that widgets by their very nature limit what the developer can do. At best you get indirect access to things you need (Application state, Database, etc...) and often times you have no access.
They are the worst form of abstraction. Extremely easy to do one thing. Hard to customize and nearly impossible to do something unintended.
I think that it isn't that hard to have a difficult experience with widgets, but that doesn't invalidate the model, and not all component frameworks are alike in regards to things like ease of extension/modification etc.
That said, my experience is primarily with coolite and versions 2 and 3 of the framework. I was working closely with another team using 4, which sounded better.
ExtJS' main problem is that it does too much. It tries to replace jQuery, CSS, JavaScript OO frameworks and then adds it's widget/control and code structure on top of all that.
If it just did the last one (maybe two), it would be a decent framework. I still would not choose it because I don't like how it gets in the way of API calls nor the control of event handling in versions 2 and 3. This last point has probably been improved in 4 with the introduction of an actual MVC structure, but I don't know for certain.
In any case, using enormous object literals to configure and control everything from styles, events and actions made it both difficult to work with and test. Often times these blocks of code would exceed hundreds of lines. In short, ExtJS sets up developers to fail. Most of what it does can be written in jQuery using CSS classes far more concisely. It's strongest points were it's UI controls, especially the grids. I think these are the things where the framework adds value, the rest would be better served using more commonly adapted practices.
* [1] : library based on the author's definition and framework based on sencha's documentation.
* [2] : the learning curve is steep even for experienced javascript developers.
edit: I just had to fight the * * *
[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.
In my experience, widgets generally end up in the second category. This is also shared by people generally looking down on things like drag and drop development. Obviously nothing is going to be faster than dragging the complex control someone wants to use into an HTML page and clicking deploy. The problem is that it is almost never the case that the user or your needs are met by the default setup. Then you start configuring and customizing the control. Developers often spend more time configuring and hacking these widgets than it would take to write something that exactly met their needs.
If the choice is between Meteor and my system, I would choose my system, of course (although I may be biased and honestly my system has a month or two of work left before its really ready for release). Whereas Dojo Widgets (for example) are only for the front end and designed to look like a desktop application, my components include both front end and back end code, with automatic database wiring, and the widgets are set up so that it is easy to customize their appearance.
The reason is simple: they have already been burnt and know better.
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.
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. ;)
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.
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...
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.
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.
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.
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://www.downforeveryoneorjustme.com/http://blog.stevensan...
Really wish Yahoo does a better job at marketing their own framework.
Would love to know where this was discussed in more detail.
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.
IE6 support is a must-have for me (corporate clients).
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.
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.
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.