Ember 2 vs Angular 2 vs React ecosystem (Non-Meteor Discussion)

Hey folks, I think with Angular 2 in beta, we now have the best 3 options for front-end defined.

Ember 2.0 is Blaze-like, with support for SSR, the React-inspired Glimmer rendering engine, and thought it’s not talked about a lot, many big companies are using it.

Angular 2.0 is a complete front-end solution, like Ember. I’m still trying to figure out what the crack features of it are. One which I’ve read about is where it renders the page on the server and then pushes that on the client for a quick load. After that, it loads Angular and all the dependencies to become an Angular app.

Both are using a Meteor-style CLI, I believe with the build tool and etc built into the platform.

React is looking a little messy right now but it’s developing in an interesting direction with GraphQL and whatever Facebook comes up with next, but there is a lot manual lifting which I think many of us don’t really want to do.

Angular 2.0 and React both are developing native support, but as I’ve heard with React Native the code reuse is not that great, and I’m not really clear what Angular 2.0 is planning here. All three are “reactive”, and I’d say Meteor “inspired”.

About 2 years ago, I went all in on Meteor and I think it was a good investment. Right now, I do not know what direction Meteor is going, and I at least want to be solid on the front-end side for next 2-3 years. I think many others feel the same way, so it would be great to set up some kind of knowledge exchange.

6 Likes

In terms of going native I’m guessing there are no plans with Angular yet. This is am assumption, I am not using Angular but I’m heavily using Polymer, which is also developed by Google and in fact Google uses Polymer a lot now, you see it being used in most new apps or partially already in older apps - I’d say Polymer is Google’s new flagship.

But for Polymer there are no official plans for a native version yet, if there is, it has to be in a still secret branch (there’s nothing in the experimental branches). That’s why I’m assuming, if the flagship framework (i know i know blabla polymer is no framework) has no concrete plans yet, then Angular won’t have anything concrete either.

On the ‘popularity’ scale, it’s clear Angular has more fans. But a lot of very large companies are using Ember: http://emberjs.com/ember-users/ - it’s a proven technology.

What I like about Ember is that it has a first-party CLI that is built for ease of use and constructive dictatorship. You will be told what to do/where to place things, but in return you will be able to focus on your business value.

Ember’s community is also transitioning towards being component based. Meaning the tools are there (Ember has components), the developers just need to start working that way. It’s great and takes all the sexiness from React, but leaves the baggage of JSX.

Here’s a good litmus test: http://stackshare.io/stackups/react-vs-emberjs-vs-angularjs

I cannot speak towards Angular, never used it.


@msavin I think Meteor has already come out and said “We’re React now boys.” pretty much, right? They’ve outright said that, I remember. Sure they support other things, but React is what they recommend 100%.

Agree! I’m using Meteor for 3.5 years.
All I want is just a solid code environment.
There’s a lot hype going on. I just hope meteor can change little by little. And bring awesome technology in background. Just like it used to be.

So, I really like the idea of sideburns (implement react but in blaze syntex)
I’m not saying that we shouldn’t change the syntax. it’s just that I hope to change it smoothly

1 Like

The law of the three :smile:

But how will they do it? Totally React? Or Blaze syntax with React rendering engine? I don’t know if they have made a clear statement. Or maybe I have missed it…

Just a good old [ReactMeteorData] was what I understood. And if I’m mistaken then Meteor really has to step up communications :laughing: because I check these forums frequently.

“Omg they killed Kenny! You bastards!”
(Southpark)

From what I’ve heard, Ember is in the process of adopting everything that React invented, from components to anything else.
So now not only Meteor mimics React, but also Ember, and even Angular2 stole some of the concepts (components, no more 2-way binding, etc.).
People who haven’t loved React, have to deal with a world where most of the frameworks are mimics of React…

Anyway, I’m afraid that you omitted the best 3 options for Meteor:

  1. Blaze…
    And if MDG can’t dedicate 20 developers for this, they should try to dedicate 1.
    You can’t say that this project requires 20 developers, otherwise it will die, and on the other hand - to claim that nobody is killing it and that it will continue to work for years.
    The truth is in the middle: It will not continue to work when 0 effort is invested in it, but on the other hand - 1 developer will make a huge change! Less than 20, but if it’s claimed that it will continue to work for years, then 1 developer will just help it to progress even further.
    This will keep backward compatibility, allow new developers to jump on the Meteor’s bandwagon easily and quickly, prove MDG’s responsibility and guarantee to its developers (critical for the success of Galaxy!), allow hundreds of existing modules (based on Blaze) to continue to run, avoid making all the ecosystem (books, guides, tutorials, examples, lectures) obsolete, and give developers something that nobody else gives them.

  2. Web Components: if components are so important, why not adopting the standard that is going to be supported NATIVELY by all the browsers? It is already built in Chrome (the most popular browser), being inserted into the rest, and can already run under all of them today using Polymer. And Google pushes it as the future way to program the web!

  3. And even if you insist on a framework which is not built in the browser (why? I have no idea…), then what’s bad with Vue?! Very similar to React, but much simpler, and extremely tiny.

This actually sounds really nice. I think what people want is an integrated, HTML-y solution, and Ember has it. It’s not that nobody likes components model as much as they don’t like JSX and the fragemented ecosystem.

More and more, I think Facebook does not focus on building a front-end solution, they really are just building tools for themselves. They are good tools none the less, but I am leaning more towards Angular/Ember now.

Angular still has 2-way data binding, it just works a bit different. Components were there from the very beginning, they were just weaker (no wonder, as they’re few years older). You could say the same way that React stole the concept of components from Angular. Or that React stole the concept of no 2-way data binding from JQuery.

Thank you very much for your comment!

I had no meaning to offend Angular2 for being a thief, my point was different:

When a product, in any field, chooses a direction which some of its users don’t love, they spread between its alternatives (or competitors, in a commercial market).

But when this direction is adopted by almost all of the alternatives too, then all of the frustrated users move to the only alternative that didn’t adopt it.

There are some concepts that are being pushed by React. They are not negative and each of them has its advantages. However, many developers are not happy with them.

Moreover, these concepts are being adopted by React’s alternatives (e.g. Ember; Maybe Angular2 just changed defaults or hides features, but it’s a change of direction, and breaks backward compatibility, and the case of Meteor is even worse).

In such case, the only brave who don’t fear the trend and prefers to keep its direction, takes it all. The users that love the new trend, spread between all of the other products which mimic each other, and all of the users who don’t love it, move from all of the other products to this brave, which takes it all. And of course its original users which stays with him.

And back from the allegory to the reality: Meteor could be this grave and become the main alternative for all the developers who are not happy with all the new trends, plus keeping its original developers, but unfortunately, preferred to join the herd.

All of the 3 frameworks in the title of this thread, look much similar to each other than in the past, and instead of joining them, it could be a great opportunity to keep the original direction which made Meteor much easier than anything else.