Ask HN: What is the best alternative to Angular JavaScript framework?
63 comments
EmberJS is a great alternative to Angular, and is often considered its primary competitor. To summarize, Ember is basically Rails for the front-end. It emphasizes convention over configuration, and it was designed to aid in the construction of "ambitious web applications", i.e. Javascript-heavy single-page apps that need best-in-class routing and composable views all the way down.
Companies using Ember: http://emberjs.com/ember-users/
The getting started guide: http://emberjs.com/guides/
The command line tool you should use to initialize your Ember projects (not yet mentioned in the getting started guide but it will be soon): http://www.ember-cli.com/
Companies using Ember: http://emberjs.com/ember-users/
The getting started guide: http://emberjs.com/guides/
The command line tool you should use to initialize your Ember projects (not yet mentioned in the getting started guide but it will be soon): http://www.ember-cli.com/
I really like KnockoutJS, having used it on multiple projects, both personal and professional. Many will say that it can't really be apples-to-apples compared with Angular since it's technically MVVM, it lacks many of Angular's features, like dependency injection etc. etc. And that's all true. But, the end result for me is that I'm able to rapidly build sophisticated client apps. I'd have to dig up the links, but there are some pretty complex front-end apps i.e. website builders and the like, that were developed using KnockoutJS.
I second this.
On a previous project for our company, another dev and I were able to research and decide whether to use Angular or Knockout for a specific project. We concluded that for us, Knockout was the better choice because it seemed lighter-weight in terms of actually achieving our end goal which was simply doing reactive data-binding on the client side rather than having to do so with jQuery manually. We've since used it to create some pretty awesome user experiences that would have been a pain manually. To us, it didn't seem Angular would have been a poor choice. Rather, it was just that our goal was such that we did not need everything that Angular offers.
On a previous project for our company, another dev and I were able to research and decide whether to use Angular or Knockout for a specific project. We concluded that for us, Knockout was the better choice because it seemed lighter-weight in terms of actually achieving our end goal which was simply doing reactive data-binding on the client side rather than having to do so with jQuery manually. We've since used it to create some pretty awesome user experiences that would have been a pain manually. To us, it didn't seem Angular would have been a poor choice. Rather, it was just that our goal was such that we did not need everything that Angular offers.
I concur, Knockout is awesome despite being un-hyped. Small, stable, reliable, compatible with IE6+.
If you want a modern ES5 alternative there's also Vue.js
If you want a modern ES5 alternative there's also Vue.js
Do you do databinding? I like KnockoutJS too, but to me it is purely limited to making a page more interactive, not much with back-end integration.
Knockout doesn't have built-ins to wire up UI actions automatically to CRUD calls, but the portion of that you end up having to implement is usually extremely small.
As far a wiring up objects to knockout observables you have two options:
1) use the mapping plugin. I tend to stay away from this, as it makes everything on objects observable. Not bad per-se, but I like more control.
2) define your own model...its easy: https://gist.github.com/jdc0589/c48c2355302390ad954b
As far a wiring up objects to knockout observables you have two options:
1) use the mapping plugin. I tend to stay away from this, as it makes everything on objects observable. Not bad per-se, but I like more control.
2) define your own model...its easy: https://gist.github.com/jdc0589/c48c2355302390ad954b
My team does data-binding with it via its mapping plugin. It's very powerful to use if you're working with json data to/from your server.
I just saw a demo of Knockout 3 and it looked much better than the older versions. That said I still like React and think Angular works great too.
KnockoutJS is great. It's small, simple, stable, it works on every browser, even IE6 and mixing it in with other technologies is no problem. Being able to easily read through the entire code of KnockoutJS is another big plus. I've used this on a few big projects so far and it's just a pleasure to work with.
React, which is "just the V in MVC"
Combine that with Reflux[1], which is a more opinionated framework around it. It's conceptually a little different than the Flux pattern that Facebook recommends, but the changes make sense after you have some insight into the Flux pitfalls.
Stir in some react-router[2].
It's still not as full featured as Angular or Ember, so you'll need to adjust your expectations there.
On that note, the Ember team has stated[3] they're going to to take the best ideas from React, so it's probably a good idea to keep an eye on that project as well.
Mithril[4] also looks React-ish and interesting.
1: https://github.com/spoike/refluxjs
2: https://github.com/rackt/react-router
3: https://docs.google.com/presentation/d/1afMLTCpRxhJpurQ97VBH...
4: http://lhorie.github.io/mithril/
Combine that with Reflux[1], which is a more opinionated framework around it. It's conceptually a little different than the Flux pattern that Facebook recommends, but the changes make sense after you have some insight into the Flux pitfalls.
Stir in some react-router[2].
It's still not as full featured as Angular or Ember, so you'll need to adjust your expectations there.
On that note, the Ember team has stated[3] they're going to to take the best ideas from React, so it's probably a good idea to keep an eye on that project as well.
Mithril[4] also looks React-ish and interesting.
1: https://github.com/spoike/refluxjs
2: https://github.com/rackt/react-router
3: https://docs.google.com/presentation/d/1afMLTCpRxhJpurQ97VBH...
4: http://lhorie.github.io/mithril/
Will all due respect, what are the odds that a single guy has "insights into Flux pitfalls" that the gigantic creator of React, that is deploying the tech for billions of people, has missed?
Flux, as prescribed by Facebook, involves a couple singletons and implementing an action requires coordinated changes across 3-4 files. Many people find this undesirable.
The important part about the pattern is the unidirectional data flow, which limits the amount of code you have to search through in order to track down a bug. How to go about making this happen varies and there are quite a few 'Flux' libraries bouncing around the React ecosystem.
The important part about the pattern is the unidirectional data flow, which limits the amount of code you have to search through in order to track down a bug. How to go about making this happen varies and there are quite a few 'Flux' libraries bouncing around the React ecosystem.
Quite high, actually. Remember this question is motivated by the pitfalls of Angular, which many "single guys" have legitimate architectural criticisms of:
https://news.ycombinator.com/item?id=8651641
Your reasoning about facebook and React should apply equally well to Angular and google, if it were valid.
The fact is that with complex technology, even very smart, well-funded people routinely miss things and make decisions that turn out to be wrong in retrospect.
https://news.ycombinator.com/item?id=8651641
Your reasoning about facebook and React should apply equally well to Angular and google, if it were valid.
The fact is that with complex technology, even very smart, well-funded people routinely miss things and make decisions that turn out to be wrong in retrospect.
Do you think the universality of a framework grows in scale with the size of the organization that made it?
Facebook didn't sit down and try to engineer a globally appealing framework, they open sourced and documented part of one of their internal patterns.
Facebook didn't sit down and try to engineer a globally appealing framework, they open sourced and documented part of one of their internal patterns.
That's a reasonable concern if Flux is a framework. But if you watch Facebook's presentations on it, it is not: it's a design pattern. And a very lightweight one. There's a pretty big design space for tradeoffs in it.
Mithril might be worth looking into. It's similar to React in terms of providing a unidirectional data flow pattern for code organization, and it comes with a few other useful tools out of the box (e.g. routing, ajax, promises), despite being smaller in terms of byte count.
It's designed to leverage generic knowledge as much as possible, as opposed to introducing a large amount of framework-specific terminology that no one else uses and that may be out of flavour in 3 years.
I've heard people say they were able to get up and running in less than an hour, so even if you don't ultimately use it, I think it's worth investing some time into looking into it.
It's designed to leverage generic knowledge as much as possible, as opposed to introducing a large amount of framework-specific terminology that no one else uses and that may be out of flavour in 3 years.
I've heard people say they were able to get up and running in less than an hour, so even if you don't ultimately use it, I think it's worth investing some time into looking into it.
Thanks for your work on Mithril. I haven't had the opportunity to use it professionally, but I'm using it for a hobby project and it's really great to work with.
For those looking for real world uses of Mithril, one site I know of that has a bunch of visitors and uses Mithril is the MELPA Emacs package repository: http://melpa.org
For those looking for real world uses of Mithril, one site I know of that has a bunch of visitors and uses Mithril is the MELPA Emacs package repository: http://melpa.org
http://lichess.org is also using it on its chess boards. The developer said he was moving everything else over to it as well.
Do you think Mithril can be integrated in meteor?
Edit: I just found a blog post on that. [1]
[1] http://lhorie.github.io/mithril-blog/mithril-and-meteor.html
Edit: I just found a blog post on that. [1]
[1] http://lhorie.github.io/mithril-blog/mithril-and-meteor.html
Note that the weird direction is not final yet - Angular 2.0 is still a ways off, you don't actually have to use AtScript to build your applications (ES6, ES6 + Traceur annotations, CoffeeScript, Dart, AtScript should all work), and the funky HTML attribute syntax is still under debate because most browsers don't actually support .setAttribute() with bracketed attribute names.
Besides, 1.x works and will keep functioning fine for years to come. You won't be required to update or change your tech stack if 2.0 is ever released.
I'd defer looking around until 2.0 is actually released, 1.x will do until then.
Besides, 1.x works and will keep functioning fine for years to come. You won't be required to update or change your tech stack if 2.0 is ever released.
I'd defer looking around until 2.0 is actually released, 1.x will do until then.
Thats exactly what you DONT want to do. "hold out, use angular for the time being" Once 2.0's released we can all just spend the next 6 months rewriting our entire application so it works again!
I disagree with pretty much everything you've said here!
I disagree with pretty much everything you've said here!
I think you should look at a timeframe also. If you write an application today in Angular 1.x you could probably contiue to use it for about 18-24 months. It is really hard to know which frameworks will still be maintained in 24 months time and it is not unheard of rewriting the application anyway after that time.
As for the actual rewrite from Angular 1.x to 2.x I think Google will create scripts that help with the rewrite making it go much faster than 6 months. They actually have a LOT of internal applications written in Angular 1.x and would probably not want to spend the whole of 2016 rewriting everything.
even if you don't have to use AtScript to write your app you will still need to know it to understand examples. This will make it mandatory to learn for most intents and purposes.
Agreed. It seems like it's primary purpose is to add dependency injection annotations, so its similar to today needing to understand `['$q', function($q) {` notation, or the special `$get` function for providers.
http://vuejs.org/ is similar to Angular in some aspects, but smaller and simpler. From it's site:
Philosophically, the goal is to provide the benefits of reactive data binding and composable view components with an API that is as simple as possible. It is not a full-blown framework - it is designed to be a view layer that is simple and flexible. You can use it alone for rapid prototyping, or mix and match with other libraries for a custom front-end stack. It’s also a natural fit for no-backend services such as Firebase.
Use EmberJS. Great framework with a good core team that really listen to the community.
Further details: http://t.co/GKoBKpIReq
Backward compatibility is always in mind.
Further details: http://t.co/GKoBKpIReq
Backward compatibility is always in mind.
We're using Ember and have been for a couple of years now and it's come a long way in that time. 12 months ago I'd have struggled to recommend it but it's improved significantly.
What I would say is that like most frameworks it makes things easy when you do it the way it wants you to and will fight you like crazy when you don't. The downside with Ember, probably more than most, is the way it wants you to do things isn't always as obvious as it might be. There is a way and you're going to be able to do what you want to do but you're probably going to have to dig a bit and it might not be intuitive.
Short version: expect something of a learning curve.
What I would say is that like most frameworks it makes things easy when you do it the way it wants you to and will fight you like crazy when you don't. The downside with Ember, probably more than most, is the way it wants you to do things isn't always as obvious as it might be. There is a way and you're going to be able to do what you want to do but you're probably going to have to dig a bit and it might not be intuitive.
Short version: expect something of a learning curve.
EmberJS is a great alternative. It's a bit more involved and all-or-nothing, but you gain so much in return.
Mainly:
* Consistant project structure. * Great toolchain. * Ember-Data
---
If you're starting to learn EmberJS or are making a new project, start out right using Ember CLI. It's the defacto way of building Ember applications.
Mainly:
* Consistant project structure. * Great toolchain. * Ember-Data
---
If you're starting to learn EmberJS or are making a new project, start out right using Ember CLI. It's the defacto way of building Ember applications.
Worth pointing out now that Ember Data is still in Beta. It's a late Beta so you're probably safe but it's not impossible that it will change.
Mithril. https://lhorie.github.io/mithril/
Agreed. Also, combined with https://www.npmjs.org/package/msx it feels even more modern with jsx templating
I really dislike JSX and I don't see the appeal. Mixing HTML/JS just seems like an awful idea. Mixing the two is one of the reasons I hate Angular templates.
I am using Backbone.Marionette. I like it because it is simple. Marionette helps you to write consistent codes and avoid javascript chaos even when your project gets bigger. You probably have to write more codes than Angular to archive the same thing, but the effort will pay when your project becomes big because you know what you are doing. No magic exist.
Of course as all questions related to development, the answer is definitely "It depends."
That's also why there are so much alternatives of MV(VM|C) platforms out there.
You can ask yourself a couple of questions when you start your project that will help you what framework will best fit you :
1. Is it a huge single-page app that needs client-side url handling?
2. Do you have plenty of DOM manipulation?
3. Are you going to have a REST API backend?
4. Do you plan to support IE <9 or you want the cutting edge?
5. Do you plan to use jQuery or plain ("vanilla") javascript will be your DOM manipulating library? ( Actually this one is also a question that should be answered, considering your application requirements ).
When answering all of those you can have a second round of questions :
1. What you and your team are experienced in.
2. What is the current market of developers and the popularity of your framework? ( people that have experience with Knockout are less than Backbone experienced ones - e.g. ).
That will give you not only the best alternative framework to Angular, but the right framework for your project.
That's also why there are so much alternatives of MV(VM|C) platforms out there.
You can ask yourself a couple of questions when you start your project that will help you what framework will best fit you :
1. Is it a huge single-page app that needs client-side url handling?
2. Do you have plenty of DOM manipulation?
3. Are you going to have a REST API backend?
4. Do you plan to support IE <9 or you want the cutting edge?
5. Do you plan to use jQuery or plain ("vanilla") javascript will be your DOM manipulating library? ( Actually this one is also a question that should be answered, considering your application requirements ).
When answering all of those you can have a second round of questions :
1. What you and your team are experienced in.
2. What is the current market of developers and the popularity of your framework? ( people that have experience with Knockout are less than Backbone experienced ones - e.g. ).
That will give you not only the best alternative framework to Angular, but the right framework for your project.
"AngularJS 2.0 itself will be written with AtScript, but then transpiled to ES5. You can write your AngularJS 2.0 app with ES5, ES6, AtScript, CoffeeScript, TypeScript, etc. Angular 2.0 apps will run in today's browsers, and even better as ES6 features land"
We've decided to go with React + Flux. Using Flux and CommonJS (since react plays well with it) allowed us to split all our code into small npm modules that do one and only one thing. Never had easier time managing client-side app code and a bunch of collaborating developers.
You're asking two different questions:
1) What is the best alternative to Angular?
2) What should developers invest their resources and time in?
For 1), like drinchev says, it heavily depends on your usecase. If you're making a 'regular' website i would opt for plain old backend HTML rendering combined with simple Javascript and maybe a bit of jQuery. But if you're making a 'webapp' that's very dynamic, a framework like Angular or React might be a better option.
Considering question 2): invest your time in learning Javascript, and whatever language you think might be useful. It's good to know as many frameworks as possible, but in the end language knowledge is far more useful than framework-specific knowledge.
1) What is the best alternative to Angular?
2) What should developers invest their resources and time in?
For 1), like drinchev says, it heavily depends on your usecase. If you're making a 'regular' website i would opt for plain old backend HTML rendering combined with simple Javascript and maybe a bit of jQuery. But if you're making a 'webapp' that's very dynamic, a framework like Angular or React might be a better option.
Considering question 2): invest your time in learning Javascript, and whatever language you think might be useful. It's good to know as many frameworks as possible, but in the end language knowledge is far more useful than framework-specific knowledge.
If you don't mind straying off the beaten track, you should try Nadeshiko. It's available for both Ruby and Go. Be warned that it's still a work-in-progress.
https://github.com/kirillrdy/nadeshiko
https://github.com/kirillrdy/nadeshiko-ruby
https://github.com/kirillrdy/nadeshiko-examples
https://github.com/kirillrdy/nadeshiko
https://github.com/kirillrdy/nadeshiko-ruby
https://github.com/kirillrdy/nadeshiko-examples
Ractive [1] is like React but simpler IME. I prefer tools that do one thing well.
[1] http://www.ractivejs.org/
[1] http://www.ractivejs.org/
A combo of Backbone.Marionette (composite app architecture) and Backbone.Stickit (data binding) has served me well for the past 2 years. Also, while Marionette is under active development, the core team has a policy of breaking deprecated features out into separate libraries that can be mixed into your existing project if you want to stay current with updates.
You might check the comments at https://news.ycombinator.com/item?id=8679245 for alternatives (React, for example, seems to be gaining mindshare), but this may also be a good time to reflect on the broader implications (as many are doing there as well).
Do note that React is just a view library; you'll need something like Flux or your own framework or library of choice to actually make an application with it.
I respectfully disagree. You'd need flux when you have too many stores talking to each other. Not every app becomes complicated enough to warrant that. You can get started with using an EventEmitter based Store and later refactor into actions and dispatchers if required.
And React is not just the 'V' in MVC. I've seen everyone repeating it (including the official docs), and I'm still not sure what it is trying to say. I wrote about it in a previous comment: https://news.ycombinator.com/item?id=8653517
And React is not just the 'V' in MVC. I've seen everyone repeating it (including the official docs), and I'm still not sure what it is trying to say. I wrote about it in a previous comment: https://news.ycombinator.com/item?id=8653517
I have just gotten started with meteor.js and I am liking it. I find the documentation to be lacking (or maybe I have not found the documentation everyone else uses), and there is probably just as much 'magic' going on as angular, but I like that the framework as a whole has more features, i.e. the cli or deployments.
I'm in the same boat and am curious, how is Dart and Polymer.dart? I watched a few videos from Google I/O, etc. and am really impressed with how much more sane Dart seems to make the frontend development world. Anyone gone down the path of Dart & Polymer.dart and had any major regrets?
I speak not from a position of technical experience but a position of monitoring the ebbs and flows of the community and React with the Flux architecture certainly seems to be in the ascendant.
http://paperclipjs.com/ is nice as well, which is an even more boiled down version of vuejs
That's one person's opinion. There are no reasons for his picks and they are not backed by any research among developers.
Ractive.js for the components, Backbone for Model/Collections, Router etc.
I've been really enjoying Ampersand: ampersandjs.com
Knockout.js?
meteor and espresso.js are nice. react is cool.
Not using client-side scripting
That makes about as much sense as "not using server-side scripting."
Personally, I have had great experiences building purely client-side rendered apps, with DB and other APIs exposed to the client via REST. I now consider HTML generation on the server (with separate rendering logic from the client) to be an antipattern -- done right, the same rendering logic should be usable on the client and server, and can prevent whole classes of bugs and frustration.
Personally, I have had great experiences building purely client-side rendered apps, with DB and other APIs exposed to the client via REST. I now consider HTML generation on the server (with separate rendering logic from the client) to be an antipattern -- done right, the same rendering logic should be usable on the client and server, and can prevent whole classes of bugs and frustration.
You make me very sad.
You don't have a choice when, let's say, you're building a mobile app for a service whose back-end you don't control.
Of course you have a choice. You can build a new service and place it in front of the other service. For example using Node.js. But I agree that a SPA is often the right way to go.
The alternative for Angular framework is not using a framework.
As long as you keep tying yourself to a framework, you will encounter the same situation as Angular 1.0.
Don't do it.
Just pick libraries that does one thing well and wire them together yourself.
As long as you keep tying yourself to a framework, you will encounter the same situation as Angular 1.0.
Don't do it.
Just pick libraries that does one thing well and wire them together yourself.
So you're suggesting to go back to the PHP era where everyone else was writing their own framework? Okay so yeah there's some good libraries out there that will make things easier, but you - and many others - are still telling people to basically write their own framework.
If that's not going to cause fragmentation and headaches for other developers that need to work on that project, I don't know what will.
If that's not going to cause fragmentation and headaches for other developers that need to work on that project, I don't know what will.
Agreed. I imagine Angular 1.x will continue to have strong support for a while. The community and resources seem pretty extensive.
Since angular 2.0 is moving into a weird direction i.e use of a totally different language called AtScript.What are other alternative that a developer should invest their resources and time in?
Thanks