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
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/
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
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.
If you want a modern ES5 alternative there's also Vue.js
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...
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.
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.
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.
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.
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
Edit: I just found a blog post on that. [1]
[1] http://lhorie.github.io/mithril-blog/mithril-and-meteor.html
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.
I disagree with pretty much everything you've said here!
Further details: http://t.co/GKoBKpIReq
Backward compatibility is always in mind.
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.
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.
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.
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.
https://github.com/kirillrdy/nadeshiko
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
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.
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.
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.