Client-side JS MV* Framework Roundup
blog.susestudio.com
Client-side JS MV* Framework Roundup
1–10 of 21 posts
Re: Client-side JS MV* Framework Roundup
#2To 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.
Re: Client-side JS MV* Framework Roundup
#3Its 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.
Re: Client-side JS MV* Framework Roundup
#4To 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 chu…
>> 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.
Re: Client-side JS MV* Framework Roundup
#5Its 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…
> 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.
Re: Client-side JS MV* Framework Roundup
#6One 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.
Re: Client-side JS MV* Framework Roundup
#7Its 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…
> 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.
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.
Re: Client-side JS MV* Framework Roundup
#8Its 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…
> 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.
[deleted]
Re: Client-side JS MV* Framework Roundup
#9Earlier quoted context omitted.
> 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.
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.
Thx
Re: Client-side JS MV* Framework Roundup
#10So, 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".