If meteor is included, I would say enyojs and derby (linked in his meteor's overview) should be too.
Throne of JS: Eight JavaScript MV* Libraries Compared
11–20 of 73 posts
Re: Throne of JS: Eight JavaScript MV* Libraries Compared
#12I 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.
I really can't emphasize that enough. Angular's test support is by far the best any MV* framework I've seen has, at the moment. With dependency injection being the foundation of the framework, AngularJS has a major benefit over most competing products in this area.
Re: Throne of JS: Eight JavaScript MV* Libraries Compared
#13If meteor is included, I would say enyojs and derby (linked in his meteor's overview) should be too.
Is Enyo really a comparable kind of technology? I'm not familiar with it, and its website seems to imply it's for building mobile apps more than web apps.
Re: Throne of JS: Eight JavaScript MV* Libraries Compared
#14I 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.
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?
Re: Throne of JS: Eight JavaScript MV* Libraries Compared
#15If meteor is included, I would say enyojs and derby (linked in his meteor's overview) should be too.
Enyo is nothing like Meteor or Derby.
Re: Throne of JS: Eight JavaScript MV* Libraries Compared
#16Incomplete without including YUI3 App framework.
Re: Throne of JS: Eight JavaScript MV* Libraries Compared
#17If meteor is included, I would say enyojs and derby (linked in his meteor's overview) should be too.
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.
Re: Throne of JS: Eight JavaScript MV* Libraries Compared
#18If meteor is included, I would say enyojs and derby (linked in his meteor's overview) should be too.
Is Enyo really a comparable kind of technology? I'm not familiar with it, and its website seems to imply it's for building mobile apps more than web apps.
I'm not using enyo, so I don't know from a dev's perspective, but according to http://enyojs.com/about/ , it is targeted to be cross platform, including all major browsers on the web.
Re: Throne of JS: Eight JavaScript MV* Libraries Compared
#19Knockout is awsome. Check it out. You can grasp it over the afternoon and examples of advanced ui-s are interesting and concise.
Re: Throne of JS: Eight JavaScript MV* Libraries Compared
#20I 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.