jQuery: 1) 4 hours 2) 3 3) depending on code base, maintainability can be extremely easy but it can also be extremely spaghettti 4) cross-browser compatibility of client-side scripts that manipulate DOM

linked-in dust: 1) ~1 hour 2) 3 3) 3 4) cross-browser compatibility, small size, one of the fastest

jQuery-ui: 1) ~1 hour 2) 3 3) 3 4) cross-browser compatibility, granular control over what features I deploy

1. It depends, you can make something quickly but when it comes debuging or make strange things you need a deep understanding of what is going on. I would say between 30 to 40 hours.

2. At first it's like 2.5, but when strange things start happening, it can slow to about 2.

3. I would say 2.4

4. It was really popular, has a lot of resources available and made development really easy.

Now for my personal projects I'm learning ReactJS

1. The framework is really easy, and it can take about 10 hours to learn it deeply. The difficult part is thinking the way they propose you with Flux. That can be as long as angular with 30 o 40 hours.

2. Productivity can be a little worse than angular with 2.0, but results are much better.

3. This is the best part. Although I haven't build a big project, at first sight it might seem this is the best part of react. I give it 3.0

4. Speed, control of what is going on in the views, popularity, the idea of having the possibility to easily port my apps to native with React Native, the tools such as browserify make even better.

I hope it helps you, sorry for my english.

Used angular for 2 years at work, and for a bunch of personal stuff. Now I'm trying out react, and even though it uses 10-100x as many lines as angular to do simple things. I'm hoping that for more advanced systems it will be on par, with better modularity and maintainability.

Performance is a + with react. Even though you can build performant systems with angular, it just seems to come more natural with react.

If I were you (and honestly I wish I was, I loved being a student) I'd focus much less on analyzing an arbitrary list of JS frameworks and instead turn my attention to questions like:

    Why are there so many frameworks in the first place?
    What problems are JS frameworks trying to solve?
    Why does it seems like new frameworks are constantly being produced? 
    Why can't any single framework achieve critical mass?

I've been working in React/Flux for one project, and though I was writing code within maybe 4 hours, I'm still learning the framework after ~2 weeks. I'm also not typically a front-end guy, so that is relevant.

1) You will likely see in the comments that developers will self-report that whatever FRAMEWORK X they are using right now is amazing. Super fast and super maintainable. It's just the nature of how people feel about their current tool of choice.

2) I think it's fascinating that unlike native/mobile application development, there is no clear and dominant application framework for the web. I think this is a topic worth exploring IMHO.

Want a live binding, 2 way, super performant virtual DOM, that feels less like a framework and more like something that came with JavaScript?

    var binding = new Ractive({
      el: '.some-class',
      template: '<p>Hi there {{ name }}</p> <input value="{{name}}"/>',
      data: { name: 'Alex' }
    })

http://www.ractivejs.org/

## Time needed for Learning the Framework (in Hours)

The basics take 30 seconds because almost everyone is familiar with handlebars/mustache templates, but 4 hours total.

Eg, ractive has promises for when stuff changes, and you'll have to decide how to load templates (eg, ES6 template strings, or browserify fs). Once you've done that there's not a lot to learn, which is great.

## Overall Development Speed (0-3 Points, greater better)

Development speed: 3. It's insanely fast to work with because it's simple.

## Maintainability of the Code (0-3 Points, greater better)

Maintainability: 3. it's small, so super readable.

## Why did you choose that Framework?

All of the above, plus the support side. It's been around for two years and everyone I know who's used it loves it.

DeloreanJS [1] complements it well for Flux-y architectures.

[1] - http://deloreanjs.com/

The one thing I do miss from Ractive is event-bubbling.

Other than that React has some other fringe benefits: ecosystem: React Native, React Router etc clojurescript: Reagent, Om etc

1. It took me month and documentation is sufficient well enough to learn it faster. (I'm slow at learning, of course learning speed is vary, depends on habit of people)

2. I would give point 3

3. also 3

4. reasons why I choose this framework are it's productivity, u will get good development habits, good patterns while using it and it's good ecosystem

sorry my bad english.

1. 5 hours to learn 80% of it 2. 3 Very productive 3. 3 Easy to extend and change 4. Easy to learn, easy to use, simple to understand, and highly productive. It is based on ES5 using getter/setter js features to make N-way bindings and data updates easy. Key was looking at todomvc in less code while being very easy to understand how it worked.

1. It's just a component framework. It doesn't do the kitchen sink, like Angular does. A couple hours reading the spec and implementing a small test case gets a seasoned developer up to speed on it. Flux takes a little bit longer to get used to, though, and I'm still not quite sure I'm 'doing it right.'

2. Coupled with webpack and an automated testing toolchain, development speed is quick. Webpack provides hot module reloading - no need to refresh your browser when you change a file. Very fast feedback loop. 3/3.

3. React with Flux provides a pretty strict but flexible guideline for how to build things. Discrete components, actions and data stores all look similar from a structured point of view. This provides a fantastic environment for unit tests. The favored test runner, Jest, provides automocking for dependencies and code coverage analysis. 3/3.

4. Virtual DOM for rendering performance. ES2015-oriented structure. Ease of testing. Enforcement of application structure without being a serious impediment. Warnings against implicit two-way databinding that can lead to disastrous cascading DOM changes. Good browser debug tool. On a purely subjective level, it "feels like the future."

Thanks for sharing! A few questions about Jest:

a. Are you happy with Jest auto-mocking? How do you keep a team from banging its head on this "exotic" behavior? (Typically, devs would be stuck on a test for a few hours, only to notice they failed to unmock something in the chain being tested). Have you tried the alternative of eschewing Jest and doing vanilla Jasmine, including lots of mocks?

b. You mention "code coverage analysis". Is it working now? Last time I used it, it was broken and in need of a dependency (Istanbul) revamp/upgrade.

c. Do you do "semi-end-to-end" DOM tests (i.e. those booting a micro Selenium-like browser/js environment [1] and letting you do DOM assertions like `findRenderedDOMComponentWithClass` and others at [2])? Last time I worked with React, the team initially loved the ability to do those (as an in-between of unit tests & real end-to-end tests) but after adding a bunch of them, tests took 2min to run instead of 2s, and we were considering removing/splitting them.

[1] Don't quote me on that, I have no idea how these environments work but it's certainly not Selenium :P . BTW, can anyone detail the machinery / underlying engine making those work?

[2] https://facebook.github.io/react/docs/test-utils.html

Everything in my ./node_modules is unmocked, though.

On a previous project, we used karma+jasmine and the mocking became extremely cumbersome very quickly. Setup/teardown for a given module was up to 5-10x longer than the actual tests for said module. It might have been an artifact of applying unit tests to a codebase that was never tested properly before (and then not having time to refactor).

b. It 'just worked' for me. I'm happily generating lcov / clover reports with jest 0.4.17 `jest --coverage`. I even have it in my continuous build setup, so my coverage reports update every time I save. There's weirdness where it will report a branch or function as ignored, and I can't find which branch that is ... but I think that may be an ignored/missed function in the transpiled source (I work in ES2015).

c. Yes. And I love them. Default setup is to run these in JSDom (headless). We're considering doing full end-to-end tests with selenium in an e.g. jenkins environment, but haven't come to a decision yet - as much of that testing would be duplicating the already-written component unit tests.

It is slowing down a little bit. My test suite takes 21 seconds to run right now (including coverage analysis), which is pretty slow considering the number of components I have. Some of the async modules run even slower, though - it hasn't been a sticking point so far, but it will be fairly soon. Average test per component is ~3 seconds, with the longest taking 10 seconds. Test suite runtime doesn't grow linearly, though: average component test is 5.34s; average non-component test is 0.8s; total time taken by tests is 63s; actual (perceived) time for the entire test command including webpack build is 21 seconds.

c. jsdom, yeah, thanks! Maybe you're used to longer tests and are okay with it; I got spoiled by the early test suite of this project running in one or two seconds, which enabled me to tell my editor to automagically run tests at each save and report brokenness (in Atom, with the test-status package [1]). Which is amazing, almost physical, because it lets you feel when you break stuff and when you're back in a stable state. Then we discovered the jsdom tests, and at this point we didn't have any end-to-end Selenium tests, so it sounded like a great first step and we added them, but liiittle by little they started lengthening the tests, to a point where I abandoned my auto-test setup. Maybe this auto-test looks futile to you, to me it's the kind of enabling real-time dev. experience I now want to replicate on all the projects I work on, like react-hot-loader [2].

[1] https://github.com/tombell/test-status

[2] http://gaearon.github.io/react-hot-loader/

I guess all I'm trying to say is that yes, React's virtual DOM has its pros, but it will occasionally also have cons (like when you use a third party .js that modifies the DOM directly).

I'm new to React though (two weeks). So there may be well known work arounds for this 'problem'. Since I do not know of any, if anyone does, please share ! :)

But yeah, in a similar fashion to angular, modifying the DOM outside the 'blessed' render()ing is a pathway to darkness. You can do a bit of fiddling in the lifecycle though - take a look at https://facebook.github.io/react/docs/component-specs.html#u...

I finally made the step to make my own framework, utilizing the best parts of what I've come across. The first version was ok, but the thirds version that I'm currently using makes me a blazing fast Javascript contractor.

... and a nightmare to the poor developer that has to maintain it.

Time needed: I'm not sure. Rendering something on screen, including setting-up the environment, took an hour, tops. But with all the surrounding terminology and concepts, it may have taken around a week or two as I had just the afternoons. I think around 20 hours of investment would bring you good understanding of how React.js works, accomplishing the boring stuff with it like routing and state-management with something like Flux, understanding how to render from server and share code with the client.

Development speed: 1 in the project startup, with an exponential speed increase towards 3 as complexity increases, all relative to Knockout.js and Angular.js.

Maintainability: 3. I think this is where React.js shines. If you apply the common design patterns that are popular among many React.js projects, you'll be guided to write maintainable code and your data will flow in a single direction. I can't overstate the burden this removes when you are developing a complex application. Strange things never happen.

Why: I try all the frameworks and experiment with them just for the fun of it. I stayed with React.js because it made things easier to maintain, as stated above. Development speed wasn't so attractive in the beginning but later, after finishing a project or two, you get on par with the alternatives.

- form2object for form serialization

- pnotify for notifications

- routie or page.js for routing

- jqplot for graphs

- jquery for dom manipulation and ajax calls

- moment.js for date math

- socket.io for websockets

- ejs for templating

- bootstrap for the layout

and not much more really.

1. Time needed for Learning the Framework (in Hours): A few months to learn JS really well

2. Overall Development Speed (0-3 Points, greater better): 2

3. Maintainability of the Code (0-3 Points, greater better): 3

4. Why did you choose that Framework?: I didn't want to be locked in to angular when react comes out, or be locked in to react when the next big thing comes out.

This is a very valid point and something we consider a lot as our application will likely take 5 years to be production ready. However for the vast majority of projects they will be dead before the next big thing arrives, and frameworks really help as a one stop shop for most of what you need.

I chose Ember because its programming model feels like you're programming with classes, and in general, it's the most object-oriented of the top contenders (the others being React and Angular) and provides, in my opinion, the best way to organize your code.

Note: nothing significant has been built yet on the client-side (we are currently building the back-end with Django and Django Rest Framework). But having read documentation and done tutorials for Angular, Ember, and Knockout, plus courses for Backbone and Ember, I felt Ember, while requiring some initial commitment to learn, would give the best return on our investment.

The way the Ember project is managed also inspires confidence. "Stability without stagnation" means there won't be big, bad rewrites, or breaking changes introduced without enough of a heads up to facilitate a smooth migration to a newer version.

Edit: you mention isomorphic frameworks. One of the top contenders there is Meteor, but it currently gives you no choice but to use MongoDB, which rules it out for a lot of people.

Edit 2: fixed a typo.

We write mostly internal apps and so performance/scaling are not usually on the radar, but ease of maintainability across a wide spectrum of developer skill levels is.

As for comparing to other frameworks, my biggest concern with some frameworks is the writing HTML templates as strings in JS. I've seen a lot of folks arguing that "it's different this time" and that writing string HTML in JS is OK, but it just is such a smell to me to write one language as a string in another.

http://knockoutjs.com/documentation/component-overview.html

As a knockout enthusiast I was excited to see that get developed.

What do you use for routing?

I've been dreaming up a framework that's actually knockout +/- routing +/- requirejs +/- model management...

1. I would say no more than 2 hours at worse. The biggest issue for me is understanding the creation of methods for an object (I'm use to C# and Java, so JS is generally alien to me).

2. 1.5 - 2.

3. 2.5 once you have the core logic for your object models laid out.

4. Because it was what my employer mandated, unfortunately, I prefer Knockout but it all seems to the same in terms of end result. There's minor differences in terms of templating your pages such as for tabular data. The rest seems to be purely a matter of preference and familiarity.

https://lhorie.github.io/mithril/

It doesn't abstract away too much from JavaScript and provides good methodologies as outlined in the Learn/Guide section of the site.

As per your points:

1. A good couple of hours to about 6 depending on expertise just to test the workflow, get comfortable with MSX and to read the docs.

2. I've not used it in production as for current as I am still in an experimentation speed, but the whole premise is that it acts as a UI layer amongst the business logic that you may already have. It is fairly transportable.

3. This would be on a medium scale level depending how you couple your code and how modular you keep it.

4. Because it is fairly straight forward to get up and running. The blog posts alone provide great insight into application structure. Also the benchmark claims are quite appealing.

Take my opinion with a (large) grain of salt. I'm not a "professional" JS/front-end developer. I'm a back-end dev (Java/Scala/Python) by day and really only touch frontend stuff when working on my own projects. My "me" time is precious and I don't want to spend it wrestling with some uber-framework :)

I'm actually pretty excited the see React/Meteor happening since it provides a similar paradigm.

1. You can grasp the basics in just a few hours, but obviously this is entirely subjective. A week-long training course will really get you going, though. The nice thing in terms of learning it is that the maintainers consider Marionette the "non-framework framework," in that it's just JavaScript, with no new paradigms to learn.

2. Hmmm, 3 for me, but that's also subjective. The more work you put into developing a sane architecture, the higher this number will be, but Marionette doesn't really impose an architecture on you, so YMMV.

3. 3, but see caveat from #2. Depends on how you write your code, really.

4. I chose it because, as stated above, "it's just JavaScript." I don't have to get my team up to speed on an entirely new development paradigm in order to use it. It's not really a "framework," per se, since you aren't given as much functionality out of the box as you would be when writing an Ember app. This means there's less chance of being hemmed in by the limits of the framework. This is a familiar tradeoff - a larger framework that gets you up and running faster, but with more chance of encountering an edge case that it doesn't fully support, vs. a smaller library that requires more up-front work, but is easier to mold to fit your own ends when necessary. In a few years, as the larger frameworks grow more mature, I'll be more likely to use them in my projects.

BTW, skeletor here (I think we may have worked together before, very very recently)

1. One or two weeks to learn and let it start sinking in.

2. Speed: probably 3. I can make the code do what it needs to without much effort.

3. Quite maintainable. In fact, I've contributed a few bug fixes and feature improvements to the source repos. In my own code, making changes also happens quickly.

4. I chose it after reading Human Javascript (http://humanjavascript.com) (which AmpersandJS is based on) and poking around with the boilerplate generator app. It all instantly clicked.

http://intercoolerjs.org/

It's kind of an crypto-javascript front end framework in that it makes AJAX a declarative, HTML-based tool, so the isomorphism is with respect to HTML and more traditional web development, rather than with respect to server side logic. There are events and a JS API to hook into to, though.

The docs lay out the isomorphism:

---

  <a href="http://intercoolerjs.org/">Get Intercooler</a>

"When a user clicks on this link, issue an HTTP GET request to 'http://intercoolerjs.org/' and load the response content into this browser window".

Intercooler builds on this simple concept:

  <a ic-post-to="/button_click">Click Me!</a>

"When a user clicks on this link, issue an HTTP POST request to '/button_click' and load the response content into this element".

1. Time to learn: I'd say it took me about 120 hours to really feel comfortable and get down the flow of how to build things with it. The hardest part to really grok is the whole Mongo.Collection publication/subscription model. But once you get it, it's smooth sailing.

2. Development speed: 3. You build stuff out with one language, real-time is baked in, packages out there to do almost everything. It's pretty nifty.

3. Maintainability: Too early to tell, but you can build things with very few LoC. Less code means less chances for bugs. Also, the community is still shaping out what the best way to structure files/folders are. Since Meteor is lax in that area, everybody has their own flavor of best practices.

4. Why did I chose it? I can use React pretty seamlessly in the application. It comes with latency compensation built in. Real time built in. There's a huge thriving community of people using it and building cool stuff with it. It's popular.

---

Overall I really enjoy my time building things with Meteor. I can focus much more on my features and forget about plumbing code. Here's some more developer feedback on Meteor:

http://stackshare.io/meteor

For 3) I've used meteorchef's excellent base package (https://github.com/themeteorchef/base) for two big projects so far and it's great.

Use FlowRouter and BlazeLayout, both found on Atmosphere.

It's like yeah Martini is popular in the Go ecosystem, but it's now considered bad to use now that people know better.

http://aurelia.io

https://github.com/aurelia

It has the most streamlined, elegant conventions of any framework I've looked at, it focuses on writing in plain, modern JavaScript (ES2015/2016), it's highly modular and plugable, and it tries as much as possible to always comply with modern standards.

Hopefully performance is on par with React when it hits official release so that at least a few more people take a serious look at it. It's unfortunate that so much hype surrounds Angular and React simply due to Google and Facebook backing them.

Don't get me wrong. I also like React. However, the hype is a little unwarranted. People treat it as if it's the end-all, be-all way to write JS from now until the end of time.

I found Aurelia and I think it's the next one I'll learn and use in my projects: http://aurelia.io/

1. You can do the tutorial in an hour or so, and get the general idea in I'd say about 4 hours.

2. From what I've seen it'd be a 3.

3. Looks like a 3 too!

4. I've watched a couple of videos from his creator Rob Eisenberg, and the guys knows what he is talking about ;) Plus, it support the Flux architecture with a plug-in:

http://blog.durandal.io/2015/07/23/creating-reactive-loosely...

Also there's been some discussions comparing Aurelia to Angular2 and well, seems like Aurelia has the best architectural decissions in, for example:

http://blog.durandal.io/2015/03/17/aurelia-angular-2-0-code-...

A very important thing for me is that it sports a set of tools for quickly setting up a development environment (yeoman generator, jspm, gulp, browsersync).

It also supports modern Javascript (ES2015/ES2016) from the start (with Babel).

1. Time to learn: I think 1-2 hours

2. Overall dev speed: initially 3, but as you dive into more complex pages that need to e.g.: retain state between AJAX calls, it moves towards a 1

3. Maintainability: 1. Keeping track of selectors grows to be very tricky business.

4. Why I chose jQuery: I started with it before the explosion of JS frameworks (and I've always said that jQuery started the golden era of JS that we're in), and I would still choose it today if I need to deal with legacy sites at all.

I have also used ReactJS:

1. Time to learn: I think between 16-40 React hours to really grok components, their lifecycle and how to communicate between them. It's a little reminiscent of components in Mobile development, but really understanding props vs state can take a while

2. Development speed: 2. There's a lot of boilerplate involved (usually render, getInitalState, getDefaultProps)

3. Maintainability: 3. Easily the most maintainable and reusable JS code I've ever written

4. Why did I choose React? I was tired of writing code for the views in the backend (PHP) and then in JS when the data changed. React makes it easy to write once and control the lifecycle of HTML elements

For me, virtual-dom + main-loop is a pretty great combo for front+back universal javascript. I made some repos about setting up virtual-dom, main-loop, routing, and browserify/watchify with npm run scripts:

* https://github.com/substack/virtual-dom-starter - bare-bones main-loop + virtual-dom setup * https://github.com/substack/virtual-dom-universal-starter - universal (front+back)end js example with shared routing and single-page pushState

I usually use an ordinary EventEmitter to rig up the unidirectional flow (but I dislike how "flux" makes this a big deal). Here's an example of that: https://github.com/substack/virtual-dom-unidirectional-examp...

If jsx is your thing, I made an example of setting up jsx in virtual-dom land too: https://github.com/substack/virtual-dom-starter-babel-es6-js...

As far as the research questions go for 1-3, I don't think sampling people about their subjective opinions will lead to any interesting findings, but for question #4:

I chose virtual-dom and main-loop because each piece has a singular concern and performs that concern well. I don't want to use a tool that does a bunch of unrelated things because I want to be confident that in the future I can discard pieces of my tooling at will as my requirements change. With bigger tools with larger scope that is not so easy.

The problem with getting stuck into one particular framework is that then become an "X" programmer, not a web programmer. If you need a fully fledged bells and whistles one though, Angular is probably top dog at the moment.

1. 2 months

2. 3 (and code reuse is great)

3. 3

4. Directives is a greatest idea we had in 2011

Those who are writing "15 hours" to learn a framework - I think it's the time to read basic APIs, not the time needed to learn how to write effective and reusable code, not "it works!" mess.