
Ask HN: What is the best alternative to Angular JavaScript framework? - ericthegoodking
Hey everyone,<p>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?<p>Thanks
======
csallen
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/](http://emberjs.com/ember-users/)

The getting started guide:
[http://emberjs.com/guides/](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/](http://www.ember-cli.com/)

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

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

~~~
jdc0589
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](https://gist.github.com/jdc0589/c48c2355302390ad954b)

------
o_____________o
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](https://github.com/spoike/refluxjs)

2: [https://github.com/rackt/react-router](https://github.com/rackt/react-
router)

3:
[https://docs.google.com/presentation/d/1afMLTCpRxhJpurQ97VBH...](https://docs.google.com/presentation/d/1afMLTCpRxhJpurQ97VBHCZkLbR1TEsRnd3yyxuSQ5YY/edit#slide=id.p)

4: [http://lhorie.github.io/mithril/](http://lhorie.github.io/mithril/)

~~~
swah
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?

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

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

~~~
davexunit
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](http://melpa.org)

~~~
lhorie
[http://lichess.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.

~~~
galfarragem
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](http://lhorie.github.io/mithril-blog/mithril-and-meteor.html)

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

~~~
joshcrowder
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!

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

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

------
jsangilve
Use EmberJS. Great framework with a good core team that really listen to the
community.

Further details: [http://t.co/GKoBKpIReq](http://t.co/GKoBKpIReq)

Backward compatibility is always in mind.

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

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

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

------
davexunit
Mithril.
[https://lhorie.github.io/mithril/](https://lhorie.github.io/mithril/)

~~~
orkj
Agreed. Also, combined with
[https://www.npmjs.org/package/msx](https://www.npmjs.org/package/msx) it
feels even more modern with jsx templating

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

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

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

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

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

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

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

[https://github.com/kirillrdy/nadeshiko-
ruby](https://github.com/kirillrdy/nadeshiko-ruby)

[https://github.com/kirillrdy/nadeshiko-
examples](https://github.com/kirillrdy/nadeshiko-examples)

------
kitd
Ractive [1] is like React but simpler IME. I prefer tools that do one thing
well.

[1] [http://www.ractivejs.org/](http://www.ractivejs.org/)

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

------
percept
You might check the comments at
[https://news.ycombinator.com/item?id=8679245](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).

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

~~~
jasim
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](https://news.ycombinator.com/item?id=8653517)

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

------
tdicola
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?

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

------
durango
[http://paperclipjs.com/](http://paperclipjs.com/) is nice as well, which is
an even more boiled down version of vuejs

------
BerislavLopac
[http://www.fse.guru/how-to-pick-a-frontend-web-
framework](http://www.fse.guru/how-to-pick-a-frontend-web-framework)

~~~
emsy
That's one person's opinion. There are no reasons for his picks and they are
not backed by any research among developers.

------
findjashua
Ractive.js for the components, Backbone for Model/Collections, Router etc.

------
simantel
I've been really enjoying Ampersand: ampersandjs.com

------
Koldark
Knockout.js?

------
mc_hammer
meteor and espresso.js are nice. react is cool.

------
insertnickname
Not using client-side scripting

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

~~~
insertnickname
You make me very sad.

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

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

