
Ask HN: Which JavaScript frameworks do you use? - wmw
For my Bachelor Thesis i am doing all little research about the usage of webframeworks. The Thesis is about isomorph JavaScript based frameworks but i am also interested what else do you use. 
Please evaluate your framework under the following aspects: 
1. Time needed for Learning the Framework (in Hours)  
2. Overall Development Speed (0-3 Points, greater better)
3. Maintainability of the Code (0-3 Points, greater better)
4. Why did you choose that Framework?<p>I know its difficult to define or measure those things but it will get a helpful overview for my thesis. Thanks in advance for your Time! :)
======
warfangle
ReactJS + webpack, though I've used Angular and browserify in the past.

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

~~~
ronjouch
> 3\. [...] The favored test runner, Jest, provides automocking for
> dependencies and code coverage analysis. 3/3.

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](https://facebook.github.io/react/docs/test-utils.html)

~~~
warfangle
a. I am. I'm the only one working on this product so far, so I haven't run
into the issue of it being exotic. I test my components, actions, data stores,
api util, and misc util modules completely separately though. I have run into
the issue of "oh, it's failing because that thing that's mocked is returning
undefined instead of an empty array", but that just means I need to test for
undefined behavior :)

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.

~~~
ronjouch
b. Glad to learn it works now :)

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](https://github.com/tombell/test-
status)

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

------
nailer
ractive. It's the best kept secret in web development.

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' }
        })
    

It's created and maintained by The Guardian interactive team.

[http://www.ractivejs.org/](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.

~~~
callum85
"best kept secret in web development" – agreed, Ractive has the lowest
hype:quality ratio of any library I've used. It makes React look over-
engineered and slow (and React is one of the best).

------
crabasa
I think the self-reported data that you're going to get is going to be
worthless. Anyone who says (for example) that they learned Angular in 3 hours
probably didn't really _learn_ Angular.

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?
    

You might learn some very interesting things about the web as a platform and
JavaScript as a language.

~~~
mod
Hopefully they can at least self-report on what they're using professionally.
I also wouldn't trust any 'number of hours to learn' responses.

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.

~~~
crabasa
A couple of things:

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.

------
techpeace
I use Marionette: [http://marionettejs.com/](http://marionettejs.com/)

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.

~~~
hardwaresofton
I'm surprised you didn't mention backbone once... Are you using marionette
without backbone?

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

~~~
techpeace
Haha, hey man! No, it's not really possible to decouple Marionette from
Backbone, I just don't like typing "Backbone Marionette" every time, so I just
use "Marionette." But for the uninitiated, Marionette is indeed a layer on top
of Backbone.

------
y0ghur7_xxx
I use plain vailla JS with some libraries I like for the functionality I need.
I can easly replace any lib when something better or some new functionality
that the old lib does not implement comes out:

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

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

------
jcadam
My preference is Backbone + Marionette, with Bootstrap for layout. I've tried
Angular and Ember and I have to say I'm not a fan.

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 :)

~~~
ralmidani
It depends on how large your projects are. At some point, the time required to
learn an "uber-framework" like Ember is eclipsed by the time needed to
implement things not included with a smaller framework like Backbone.

------
sergiotapia
I use MeteorJS. It really does feel like the future of web development, so
much so that going back to other frameworks feels like drudgery.

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](http://stackshare.io/meteor)

~~~
chrisquinnr
For 1), the hardest part for me coming from LAMP stack apps was shifting over
to the way routing works (see [https://github.com/iron-meteor/iron-
router](https://github.com/iron-meteor/iron-router)) and attaching your
subscriptions to routes.

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

~~~
sergiotapia
FWIW don't use IronRouter. It's considered an antipattern now to tie your
router to your subscriptions and generally to have reactivity in your router.

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.

------
egeozcan
My choice is React.js

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.

------
steven777400
We use Knockout in our workplace. I particularly like it because it is
lightweight (you can mix it with plain JS or jQuery) and because it doesn't
involve writing HTML as a string in JS.

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.

~~~
hardwaresofton
Have you started using the new components available in knockout?

[http://knockoutjs.com/documentation/component-
overview.html](http://knockoutjs.com/documentation/component-overview.html)

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

~~~
steven777400
Yes (and I like them too), but I don't put the template as text. Instead I use
one JS and one HTML file per component, loaded with require.js.

~~~
hardwaresofton
Yeah I'd imagine most people don't use the template as text -- one of the best
parts about knockout is it's natural (HTML) feeling templates.

What do you use for routing?

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

~~~
steven777400
I haven't done any client-side routing. Normally each page is either static
HTML/JS or is served by ASP.NET MVC on the server side. Then APIs are used to
load the models on the client side and perform interaction. In other words,
we're not making any effort to move to "single page" applications.

~~~
hardwaresofton
Ah I get it -- knockout is even better for that kind of usecase

------
arenaninja
So naturally, I've used jQuery for a few years now:

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

------
rish
I like Mithril which is similar to React/Ractive.

[https://lhorie.github.io/mithril/](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.

~~~
bpicolo
If the benchmark claims are true I think it'd be super cool! Would have to see
for myself though.

------
clschnei
Backbone models/collections/events bound with React components. The beauty of
a data API with the expressive components is something I have really liked so
far.

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

------
lobo_tuerto
I have been using Angular for about 2 years. And just started to have a look
at other frameworks yesterday and deciding between going for Angular 2 or
something else.

I found Aurelia and I think it's the next one I'll learn and use in my
projects: [http://aurelia.io/](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...](http://blog.durandal.io/2015/07/23/creating-reactive-loosely-
coupled-apps-with-aurelia-and-flux-episode-1/)

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-...](http://blog.durandal.io/2015/03/17/aurelia-
angular-2-0-code-side-by-side-part-2/)

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

------
sharavsambuu
EmberJS, once u learned it u will get enormous amount of productivity.

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.

------
nazrak
In my job we use Angular

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.

~~~
hmottestad
I'm in your camp.

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.

------
simulo
Backbone 1\. Learning is relatively easy (I can’t give Hours, for my first
code I needed like 2h, for totally understanding the whole lib in depth (at
least possible) probably 1 or 2 Months) 2\. 1 (Relatively much Boilerplate
code) 3\. 1-2 (depends on your skills and if you use any extensions that help
you structuring your code) 4\. It is easy to understand and to extend. I work
a lot with interactions like Drag/Drop, custom Widgets etc. Using those was a
chore in other frameworks (and needed much binding code and/or extensions), in
Backbone it can be just bridged to jQuery (UI).

------
ramtatatam
I'm not a javascript guru and there was a time I was reluctant to use any
framework - such a luck we grow up from silly ideas :-)

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

~~~
warfangle
I'd argue that none of those are frameworks: they're utility belts.

------
ralmidani
After months of agonizing, for my startup I settled on Ember.js for desktop
apps, and Cordova + jQuery for tablet apps (we'll see if we need an actual
framework, and if we'll want/need phone apps).

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.

------
kenbellows
do you have a Google Form/Spreadsheet or anything similar set up for this, or
are you planning to scrape the comments here later? Might be tough to filter
out en masse the comments answering your questions from the strictly
discussion comments, even at the top level, depending on response. You'd also
probably get better responsiveness with an easy form for folks to fill out,
especially considering the structure of the responses you want

------
diverted247
[http://vuejs.org/](http://vuejs.org/)

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.

------
substack
I'm a big fan of virtual-dom and the ecosystem of very sharp single-purpose
libraries that people have built up around it, usually not even coupled to
virtual-dom at all.

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](https://github.com/substack/virtual-dom-starter) \- bare-bones main-loop + virtual-dom setup * [https://github.com/substack/virtual-dom-universal-starter](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...](https://github.com/substack/virtual-dom-unidirectional-example)

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...](https://github.com/substack/virtual-dom-starter-babel-es6-jsx)

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.

------
joshburgess
Aurelia.

[http://aurelia.io](http://aurelia.io)

[https://github.com/aurelia](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.

------
omgtehlion
[http://vanilla-js.com/](http://vanilla-js.com/)

------
dhritzkiv
AmpersandJS ([http://ampersandjs.com](http://ampersandjs.com)), which is more
a set of rules for modular libraries than a framework (but it's still a
framework).

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](http://humanjavascript.com)) (which AmpersandJS
is based on) and poking around with the boilerplate generator app. It all
instantly clicked.

------
EugeneOZ
Angular

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.

------
norea-armozel
At my job we're starting to use angular as it helps us separate business logic
from UI and even IO.

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.

------
neals
Been using all kinds of frameworks going back to PureMVC and RobotLegs in AS3,
backbone and Angular in JS. Built a great many sites small and large.

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.

~~~
robmcm
> makes me a blazing fast Javascript contractor

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

------
doobiaus
We're running production apps based mostly on Knockout.js and jQuery. We also
use lodash and moment.

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.

------
carsongross
I'm using intercooler.js:

[http://intercoolerjs.org/](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>

This tells a browser:

"When a user clicks on this link, issue an HTTP GET request to
'[http://intercoolerjs.org/'](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>
    

This tells a browser:

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

------
vijayr
Would you be able to share your findings? Not the thesis, just a (very) short
summary of anything interesting that you found. There are 46 other comments as
I write this, and sooooooooo many frameworks being used.

------
jononomo
I use Meteor.js and I love it. As for time needed to learn the framework, I'd
suggest 80 hours. Overall development speed, 3. Maintainability of the code --
can't judge yet.

------
d_luaz
A place to share which framework you use and why you use them?
[http://www.stackbus.com/](http://www.stackbus.com/)

------
talves
Make sure before you include some of the recommendations here that they are
truly an Isomorphic Javascript Framework and not just UI libraries.

------
ackava
For first three points, I will say Atoms.js is very fast to learn and easy to
maintain. Fur fourth point l will say I built it.

------
joeyspn
Let the framework wars begin...

------
abrkn
frontend: react + react-router + redux. pack with webpack

------
justwannasing
This question is asked ad nauseum on any web forum of any type. Can't you just
visit those and glean the same answers? You could get new answers on an almost
daily or weekly basis from the same sites and those answers change annually.

