Client-side JS MV* Framework Roundup

http://blog.susestudio.com/2013/03/client-side-js-mv-framework-roundup.html

by amiel • 13 years ago

23 18 13 years ago

blog.susestudio.com

adamnemecek• 13 years ago

To comment on what they say about ember.js.

>> Views are handled via 2-way binding against rendered Mustache templates;

Ember uses Handlebars.

>> we would need to roll our own Mustache template compiler

I'm not sure if I understand this point but why not just use Sprockets to compile templates? Or what do they mean by 'own [...] template compiler'?

>> the typical SPI issue of a blank page, followed by the browser chugging on JSON and templates before finally rendering the page

In practice, both JSON and templates is usually inlined, so no additional requests are necessary on the initial page load.

bear4544• 13 years ago

>> we would need to roll our own Mustache template compiler

> I'm not sure if I understand this point but why not just use Sprockets to compile templates? Or what do they mean by 'own [...] template compiler'?

We'll be using the same partials for both server-side and client-side rendering. Its enough we have to have two sets of controllers, and two sets of models; I'm not about to maintain two sets of views as well.

33degrees• 13 years ago

No need to roll your own, there are solutions out there already: https://github.com/railsware/smt_rails, and surely others by this point

ganarajpr• 13 years ago

Its already clear from the article that they did not actually do an objective study of the different frameworks. They were already heavily biased towards rails and given that batmanjs is something that is very close ( convention over configuration, coffeescript, works quite well with rails ) it was an obvious choice for them.

It appears that they did not actually try any other framework to be frank. Just noted their cons mostly.

bear4544• 13 years ago

> It appears that they did not actually try any other framework to be frank. Just noted their cons mostly.

Wrote code in every one of the 13 frameworks I mentioned. Thanks, though, for assuming I'm a complete jackass.

hmottestad• 13 years ago

Batman.js does look quite good.

I'm currently using Angular for a personal project, and I really really like it. Pity you didn't.

wambotron• 13 years ago

I don't think you should take these comments personally. The world of frameworks is loaded with fanboys of one or the other. :/

taproot2• 13 years ago

I don't like the way the AP made his feelings known but I felt a similar way, I felt the scoring of each point was rather subjective and more or less fixed in order to give the desired outcome. (eg: YUI 4 for community / consistency, and a laughable 3 for publicity, reading your definitions for those and your evaluation of yui, I'm amazed you didn't give 5's across the board)

Also, "Wrote code" is pretty relative, did you ship something significant in each, preferably the same thing? Maybe even do your own todo but something relevant to your shop. Or even just a basic twitter / simple blog in each. Until you really use something for something meaningful writing a couple of little gists won't tell you what you really need to know.

If you just want to use the shiny new cool kid on the block that is batman, just say so, lots of us do this, not enough of us simply own it (and its consequences.)

xal• 13 years ago

One thing that batman.js has that none of the other systems have is that it's origin is an extraction from a huge production system. Batman was extracted from Shopify's admin interface that is one of the largest single page JS apps. It's production ready by definition.

Smudge• 13 years ago

> It's production ready by definition.

That is, if you define "production ready" as "already being used in production."

james2vegas• 13 years ago

That definitely seems to be the way people are defining it these days, sadly.

kevinastone2• 13 years ago

So, the answer to your headline of why batman.js over AngularJS is because of "invalid html" attributes despite that being incorrect?

If you just vetoed AngularJS based on an incorrect assumption, why would it be your summary headline? How even did those attributes impact your system and force you to explore alternatives?

I'd suggest a less sensationalist headline: "SUSE Studio uses Batman.js because due to familiarity and ease of rails integration".

vlad• 13 years ago

Even though the author updated the article to point out that Angular definitely works with strict HTML, he or she left the conclusion that AngularJS requires "invalid" HTML to use it to full capacity. That's incorrect.

taproot2• 13 years ago

Aside from the poor title choice, I find it hard to discount that angular encourages invalid html. Work arounds aside, it says a lot about the framework mentality.

I should probably note that in general I dislike the ideas put forward by angular, knockout, and similar. Binding logic to your view or in other words tight model/view coupling is just a stupid idea in the first place, it is quite plainly analogous to inline scripting like binding click events with onclick albeit in a slightly tidier way.

These frameworks basically undo the last decade or so of separating logic from presentation.

Feel free to discount / argue my point, I'm interested in a response as it is an opinion more than anything else. I have seen these frameworks work well, I just don't really agree with the ideas.

dccoolgai• 13 years ago

These things always miss jsrender and jsviews by boris moore, which imo is the most promising of the bunch.

Client-side JS MV* Framework Roundup

Related Stories