Ask HN: Which JavaScript frameworks do you use?

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.

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?

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.

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

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.

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.

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.

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.