Ask HN: Which JavaScript frameworks do you use? | Hacker News Reader

Ask HN: Which JavaScript frameworks do you use?

66 pointswmw67 comments

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?

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

View on HN

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

> 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

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.

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

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

The virtual DOM is sick on ReactJS. However, I ran into quite a bit of trouble when I used Semantic UI + Reactjs for implementing a modal window. Because React works with the virtual DOM, you're not supposed to modify the DOM directly or else React loses track of what's going on. So when I implemented my Semantic UI modal, I would get DOM errors and my application would freeze. What would happen is that Semantic UI's modal changes the DOM directly when you open and close the modal (as in, without going through React's virtual DOM), which makes the whole application unusable.

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

There's a react module for modals :) https://github.com/rackt/react-modal

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

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/

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

Also using ractive here. Very happy with it.

Agreed. I very much appreciate tools that do one thing well, and Ractive falls exactly in that category.

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

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

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

This is my go too library for all new projects now. Big or small because its that easy to work with and makes web development that much easier.

I also use ractive for everything i can. Everytime i have to work with something else i want to shoot myself in the head after some time.

I was in love with Ractive at one point. But I have come to appreciate JSX over mustache after working on some non-trivial projects at work. Being able to do whatever can do in JS has saved me from googling for template helpers.

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

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.

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.

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.

There are many frameworks because there are many, many JS programmers. The web is the farthest reaching platform you can code on, and as a result, there are more programmers targeting the web than any other platform. As a result, you get a diversity of frameworks to choose from. Frameworks like Angular and Flux/React offer different paradigms of development and there's nothing wrong with that.

"Why are there so many frameworks in the first place?" seems like a question for psychology paper more than a computer science one :)

I use Marionette: 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.

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)

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.

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.

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

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

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.

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

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) and attaching your subscriptions to routes.

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.

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.

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.

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.

Have you started using the new components available in knockout?

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

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

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.

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

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.

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

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

I like Mithril which is similar to React/Ractive.

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.

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

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.

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/

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

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.

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.

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.

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

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

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

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.

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

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.

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

Aurelia.

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.

http://vanilla-js.com/

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

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.

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.

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.

> makes me a blazing fast Javascript contractor

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

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.

I'm using intercooler.js:

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

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.

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.

A place to share which framework you use and why you use them? http://www.stackbus.com/

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

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.

Let the framework wars begin...

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

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.

Reply on news.ycombinator.com