

Client-side JS MV* Framework Roundup - amiel
http://blog.susestudio.com/2013/03/client-side-js-mv-framework-roundup.html

======
kevinastone
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
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.

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

~~~
kevinastone
Thanks, I wanted that little expansion about the concerns about Angular's
markup.

I, in fact, think quite the opposite and appreciate(d) both Knockout and
AngularJS's data binding models to make it much easier to create more
interactive web apps without the usual boilerplate of DOM manipulation (or
other scaffolding) required in other frameworks.

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

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

~~~
bear454
I'm tickled pink Angular is working for you.

I have to say, it looks really cool. But, its just not something we'd use in
SUSE Studio.

I'm sure a thousand other people will have a thousand other ways of describing
how I've slighted or misrepresented their project... and I totally expected
that. It's a blog post, not a term paper - there's just no way to
comprehensively describe everything about everthing.

That being said, the effort I put into making a responsible decision for my
project wasn't one I took lightly. I'm sorry folks seem to think so, just
because I tried (and slightly failed) to write a 3K word summary of 80 hours
of JS framework madness.

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

~~~
bear454
>> 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
No need to roll your own, there are solutions out there already:
<https://github.com/railsware/smt_rails>, and surely others by this point

------
xal
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
> It's production ready by definition.

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

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

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

