Why is Ember fading away?
medium.com
medium.com
The React world is the wild west. Libraries come and go so quickly that you're better off building it yourself if you see your app as long living. Ember, on the other hand, does a great job of keeping everything in check. Because the community is so small, things just work because there's less things to maintain.
Admittedly, when I first got into Ember, it was pre 1.0 days. Even prior to v2.0, Ember struggled to keep things working as intended. Now that the framework has matured, most pain points have gone away. The way they do their versioning is the smartest in the industry. React has been around for years and still the community seems fragmented.
What it boils down to is:
Is your app fairly small and intended to only last about a year? Use React
Is your app core to your business used by many and intended to last for the foreseeable future? Use Ember
Everything is a trade off, so if you value structure and convention over raw speed then Angular would make sense over React. Also, I imagine the latest versions of angular are faster than Ember (but I don't actually know).
There was Addy Osmani's talk on performances of different JS frameworks and Angular was the slowest. Slower than what chrome team recommends :)
I’ll say that Angular recieved alot of flack over the 1-2 change ( alot rightly so ) but it’s really solid now and marching at a steady pace of improvments. I’ve looked over react and vue.js projects recently and they are all basically the same thing with slighy differences.
And it shouldn't even have to sacrifice it's "open/modular" nature to fix that.
The core team (Dan, etc) could just adopt/suggest a few specific companions (router, redux, etc) that they consider "official" part of React, and still allow open interfaces for people to be able to replace them with whatever they want.
And there doesn't seem to be anything on the radar to do so. While I've played with enough boilerplate projects in the React/Redux world, there's nothing considered to be officially supported and even the most popular ones have stagnant development.
I can start building an actual app within 3 minutes of typing "ember new" – with React, I'd spend the first couple of days just fiddling around with build scripts.
Sure, there are now react boilerplates that do this, but there are too many out there to properly evaluate what to use. Why not just make it a part of the framework?
I think one of the reasons React has been successful is that most developers inherently enjoy the actual act of tinkering as much as they do actually building something. They are ok with spending the first 72 hours of their project picking and setting up their build tools.
On the other hand, I can't stand that stuff.
That's what's so weird to me about all this. Ember is to front end JS exactly what Rails was. Yet rails was successful and Ember wasn't. I think it's the difference between front-end culture and back-end culture.
> Sure, there are now react boilerplates that do this, but there are too many out there to properly evaluate what to use. Why not just make it a part of the framework?
create-react-app [1] is the official out-of-the-box CLI for React apps. It's maintained by the React team and has been around for a while now too. I may occasionally disagree with what gets included (e.g. service workers) but overall it's been a massive bootstrapping productivity booster for me.
Isn't this what `create-react-app` is supposed to solve?
Yeah a long time ago now. Since July 2016 create-react-app has been available, there are many other scaffolding tools as well.
>Sure, there are now react boilerplates that do this, but there are too many out there to properly evaluate what to use.
Use the one provided by the creators, facebook.
Why not just make it a part of the framework?
React is small (ok, "small"), you can use it out of the box without any build scripts. It doesn't make sense to package it up.
And speaking as someone who's done React for a couple years now and had to port old rails codebases to api-only / react views... yuck, never again. Rails is cluncky and most of the devs I worked with didn't know how anything works 'under the hood'.
The developer experience I got from create-react-app was astounding - it gave me the most productive frontend experience (live reloading, preconfigured Babel) I've ever had.
These days I turn to React for quick throwaway projects because I know create-react-app will have me up and running straight away.
This was their downfall.
Angular, sexy geometric design. React, sexy nuclear design. Vue, Sexy V geometric design. Ember, a big goofy rodent looking at you lol. "But abledon, what about GOlang? they have a rodent too?" Yes but golang resides in backend land where designers and frontend visual brains are lacking, only performance matters, doesnt matter if your framework's logo is a steaming pile of poo, if its fast and easy to write concurrent code in, it will win the backend holy wars.
When we changed, I wrote about it: https://about.gitlab.com/2015/05/18/a-new-gitlab-logo/
But it is.
A lot of how "clean" or "modern" people think a given library is, is driven almost entirely by it's marketing homepage and only loosely tied to the actual experience of using it.
Angular is seen as "The Google Solution" (disregarding that Google doesn't actually use it as much as people think). React is seen as "The Facebook Solution". Ember is more decentralized, and lacking a strong primary champion/sponsor. Something that developers SAY we like in open source projects, but which frankly doesn't really match our actions so much.
I chuckled a bit at the parent comment, but I won't say that logos don't matter to front-end developers (half of the HN discussion threads about a link seem to be about its font and CSS choices rather than its substantive content). But that's only a slice of what I think is the overall reason. Ember just doesn't have strong corporate brand muscle behind it.
I think the react 'view as a function of state' makes a ton of things easier to reason about, and will probably last for a while.
I've been developing professionally for 15 years and even in that short a time I've had to frequently start fresh in new frameworks or languages as the old ones lost their edge. The concept that someone would all-caps "NOT" use something is hilariously junior to me because the sands _will_ shift and you _will_ one day face the cliff of: my existing skills have no job demand, do I learn new skills or change profession? Harboring tribalism toward frameworks will not help you make the right decision in times like these.
As in nature in general, it helps, from an evolutionary standpoint.
Having too many, and letting them all be, instead of people rooting for their favorite and having one or two emerge as the leaders, leads to dispersion of resources, confusion for newcomers, and multiple weaker implementations of the same thing...
Even if the emergent leader is not the best, the mere fact of it having eclipsed the others, means tons of work, libs, documentation, books, support etc will be concentrated towards it.
And it's better to have one leading framework that's 3/5 good with huge community and support, than a 5/5 good framework with lackluster community and support.
From a comment without any substance, this is rich.
>And 5/5 is 1 genius
Besides, the ad-hominem, I was referring to a quality rating (as in "5 out of 5 stars") not a generic ratio.
But even at that, 5/5 (1) is bigger than 3/5 (0.6), so the point remains, either way you look at it, Erdos.
Tribalism leads to choosing between two hobbled solutions because it closes the door on teamwork across tribes. Ember has its flaws but their upgrade strategy is world class. Every maintainer of an open source project should at least be familiar; but how can that happen when ppl happily report they "have heard of Ember and would NOT use it"?
There's no law of physics preventing it. I'll give you that.
But between fragmentation of effort, few full-time collaborators, no funding for less interesting work, and other such things, there are many reasons we can't (and don't) have any 5/5 frameworks with huge community and support.
Judging by the fossil thread the other day, I'm guessing there is tribalism in any area that requires "investment" to learn/master. The "Git" tribe has a very strong band of loyal followers unwilling to see the merits of other VCSs, ditto for [insert favorite VCS] followers
Ember shines best when building very UI rich, complex front end apps. Not apps that need to work on shitty connections or devices. Apps you would use from your office in NY or Toronto.
But the sad fact is that there just aren't that many frontend apps out there, relatively speaking. Ember is hard to learn because you need to learn a lot to get things done, and most people building something simple are lazy. By the time their project is a huge mess they're already locked in. Take HN for instance, the tech powering it is dead simple. It doesn't need to be giant frontend app.
Ember is a really solid framework that I love that is never going away, but it isn't for everyone and that is ok. Ember devs make a higher salary because they generally need to know more and the apps are more maintainable and generally run by pro dev shops, but it's not for everyone.
One thing I think that could really help Ember is a version of Rails or some other backend that required less mucking around to get everything working. It's such a chore to fully follow JSON API v1.1. But relation links and cursor based pagination are great with tools like Ember Data, so it's worth the effort.
Curious, why would you say that? I've only ever dabbled with Ember a little, never built anything production-ready with it. But I did have to maintain an Angular (1) app. And that thing was chatty as hell. I was the backend dev, and developed the REST api that our apps and this Angular bowl-of-spagetti communicated with.
Where ember has, built in, localstorage caching and even some cool REST-sync systems, angular has none of that. The closest I could get was angular-resources, which is a ORM-alike-approach to communicating with a REST backend. Proper HTTP-caching headers, Etag caching and so on, allowed leveraging the browsers-caching to avoid some calls, but Ember has a far neater and cleaner way to talk to such a backend.
This is just an anecdote, but I was pretty convinced that from all the JS-frameworks, ember had the "get data in- and out of a REST backend" solved the nicest, fastest and cleanest.
Whereas the other frameworks don't make things as app-y as easily so its more like a local template language than an app builder. So people don't go as hog wild.
That plus a larger initial JS file than something slimmed down like React. It kinda adds up even if in theory it shouldn't.
This was certainly good for technological progress, but if anyone recalls the arduous process of "which frontend stack should I choose?" back then, it was an absolute nightmare. I had no idea which framework was production-ready, which framework would be around in 2 years, and heck, which framework even worked as advertised (and I remember distinctly wasting two weeks of my life trying to get a-then-very-beta ember-data to even fetch correctly, and eventually gave up and apologized to the client that their project wouldn't be done on time).
Fast forward to 2018, as happens with basically every technological advancement ever, we are starting to standardize. Most of the evolutionary branches are dying out in favor of one or two of the strongest candidates (in this case, React, as far as I can see). This has resulted in huge maturity gains, performance improvements, library standardization, lower training costs, generally lower software maintenance costs, and overall stability in the ecosystem. And as someone who is generally a fan of the "more wood behind fewer arrows" philosophy, having suffered through the world war that was JavaScript in 2013, I am really enjoying the calm before the next storm.
Because, as always, the next wave of disruption will rise again. This current consolidation is at the expense of change -- there will be less paradigm shifts, there will be less new ways of doing things, and that both provides for stability and stagnation. But like clockwork, come about 2020, there will be a new catalyst for change (maybe our next Cambrian explosion will be thanks to WebAssembly?).
So in short order, don't worry, we'll get to play the "which of these libraries even works" game in no time.
I'd argue that Backbone is from an even older generation.
We continue to be super productive with Ember, our customers love our product, our code base has never been healthier and Ember's careful upgrade path and approach to deprecations means that we don't spend much energy or time thinking about non-product related technical challenges.
We've grown from 10 to 150 engineers in that time and Ember's strong conventions has helped us continue our tradition of enabling new engineers shipping to production on their first day and shipping a feature to production in their first week.
Ember is not fading away for us, it's enabling us to focus on continuously shipping better and better features to our customers.
- Angular had the spot, then bumbled the transition from 1->2->5.
- Durandal died/was transformed into Aurelia, whose hype never materialized.
- Backbone +/- Marionette seems to be in super slow decline, but doesn't update as fast as Ember.
- I don't know much about Polymer but it just seems like an interesting project, not something I'd suggest an org to use (I'm probably wrong).
Ember shouldn't be compared to tools like React/Vue because it's almost never just React/Vue, and Ember itself has lots of plugins that come into play. "React" =~ React + React-Router + Redux/Reflux/Fluxxor/Flux/whatever, and roughly the same with Vue -- though you can choose to extend Ember with plugins, by default everything you need is baked in, with ONE set of well-written if not long documentation. I can certainly say that Ember is more coherently put together than react/vue + react-router/vue-router + redux/vuex.
One of the biggest problems with ember of course, is the breakneck pace of change. I think it's slowed down somewhat recently, but keeping up with it can feel like a full time job sometimes, if you get stuck behind for too long, it gets harder and harder to update your codebase.
As far as I'm concerned, Ember should keep doing what it's doing, it's basically the only worthwhile competitor these days in the most-batteries-included (aka frontend framework rather than frontend library) space. If anything these days, Angular (5?) is looking like it's pivoted it's way to essentially emulating Ember, so I'd place it second.
If there's somewhere in the front-end world where this is not the case, short of going back to jQuery spaghetti, I'd love to find it. We're largely settled in with AngularJS, having caught it after the crest, so that is largely settled, but everything around it is moving and breaking and deprecating things left and right. I always feel like we're standing on quicksand, just waiting for some bower or npm package to get yanked out from under our feet.
Compared to the back-end, where things move at a much, much slower rate of change, it is a little maddening to see the churn in JS-land. I have NuGet packages that I use all the time that haven't seen more than minor-minor version updates in three years - and that's fine, they work, they're stable, there's no reason to burn it down and flex it all around every three months. But that's also a benefit of being in the Microsoft ecosystem, where backwards-compatibility is prized.
I spend a lot in frontend land and I've grown somewhat accustomed to it's insanity. I actually even like it at this point -- Let everyone go insane in all the different directions, watch how they fare, then let the good stuff rise to the top, and pull out the interesting paradigm shifts if there are any. Platforms like C# often have a lot more enterprise weight behind them and "stable" takes on a completely different meaning.
I might even say that churn in .NET is happening too, it's just way way more localized. For example the .NET core/standard move is happening right now, but I can only assume that the vast majority of codebases on .NET 4.x don't care at all, and are letting it work itself out maybe over the next year before they even consider moving (if they ever move at all). As a person who's struggled with porting a .NET 4.x package to .NET core/standard, and with some associated libraries (EF, mostly), it was not a pleasant experience, but by the time it gets to everyone else, it probably will be.
What it suffers from is a small community: we depended on a table component someone wrote which used some weird internal APIs and never got properly upgraded to ember 2.0 so we got stuck with ember 1.x until now because the overhead cost of switching to another library was too high to be worth it. Even then, the maturity of the project has been great and things don't break all the time. The API has been improving and the ember developers are proactive about pulling in the best ideas from newer projects. If you read the Ember RFCs they're always introspective and future-conscious and great. I really hope the project survives, not that I had much doubt. I think there is still quite a dedicated crowd.
As a total outsider to Ember, but an insider in the JS community, having worked in various web-dev roles for 10 years and served as tech lead on a full-stack ReactJS app, my recommendation is to double down on production of junior developers (yes, I said "production" instead of education, and that is how you should look at it; producing capable workers).
High barrier to entry is the Achilles' Heel of ReactJS. It's in a very similar position to Ruby on Rails five years ago. If you want to kill React, go for the low-hanging fruit: the juniors. Take a lesson from Python. It doesn't matter how old you are; capture Programming 101 and the future is yours.
Its a shame but the reality is that ember will not stand the test of time.
From what I have seen from my peers, EmberJS is indeed often ignored :/ The developers I know that are using it at work seem very satisfied AND very productive with it though. And the same core team also released GlimmerJS which is very interesting: https://glimmerjs.com.
Popularity for frameworks is also important if the framework needs adapters to enable third-party libraries to work with the framework. Depending on how opinionated the framework is, the friction in embedding libraries may hamper productivity indirectly.
If you're a one man band, then it's definitely less important. If the framework is a really good fit for the job, likewise. Otherwise, there's safety in numbers.
If you want to grow a team, you need to hire a mix of experience levels. With younger devs, talent is correlated with being opinionated - they have passion that hasn't been balanced by broad experience. And opinions are fashion-led. Find me a young dev who has no real opinions, and I'll show you a dev who has no taste.
I like it, I could do real, valuable (if small) contributions within a month. I am 9 months in it now and I can handle significantly more complex features.
As it was explained to me, this was part of the decision of choosing Ember.
I will try to list the reasons for us:
- Timing: it was a time when the Angular broken upgrade from 1 to 2 was happening and React was starting to get traction.
- Ember was a solid and mature framework, stable enough to use on a startup with product-market fit entering the growth phase.
- There were clear signs that the framework was not going to be abandoned by its developers. Not only the maturity, but its future seemed solid. In retrospect, this was right. Ember keeps staying as a modern framework (even if not hyped that way).
- Its "conventions over configuration" approach was very important as we hadn't enough experienced software developers in the team. It made it welcoming to junior developers (like myself) that could not properly anticipate all the possible outcomes of early configuration and architectural decisions. React is very tricky in this aspect. I believe a lot of React applications being created these days by not so experience engineers will cause a lot of problems in the future.
The downside is mostly human capital. Hard to find Ember developers these days. But not such a big deal, as our hiring policy focus on more fundamental frontend skills rather than framework knowledge, so we hired good frontend developers that first got in touch with Ember here. And it is fairly easy to pick up Ember for junior and senior developers both.
That said, talking to some senior developers here, it appears that, were they doing that decision today, they would probably go with React. Being easier to attract new hires is a big deal of that decision, as we are growing a lot our development team and if we could offer React options we would certainly attract an order of magnitude more candidates.
Also, React is more mature and we have more developers that are experienced enough to make the right calls on its architecture and configuration.
But, my personal opinion, is that Ember would still be the right choice for our situation today. Something solid, with a large enough range of problems already solved, welcoming to new developers, easy enough to be productive from start.
Ember has always been the little guy even in the days when Backbone dominated. But it seems to have been replaced by Vue in this regard.
Enteprise - Angular
Startups and Larger Agencies - React
Smaller Agencies - Vue
Angular is dominant because large Enterprises are slow to adopt and Angular is really great because it works so well and everything is packaged out of the box.
React is still new compared to Angular which is why Startups are adopting it. Kind of like how Rails was popular with the Startups a few years ago.
Vue is universally loved by Developers but is not backed by the big companies in the States (it's bigger in China apparently?). It's considered Indie in North America so it's relegated to low budget projects.
I think Ember is fading because it's just pretty different from other frameworks and there is a pretty big learning curve. But once you get up the curb you become super-productive and it's really nice.
It's a shame.
This is mainly due to my ability to focus on shipping features rather than build processes. Also, depending on Ember Data, ember-cli-mirage, and the JSONAPI spec have allowed me quickly spec out how my schema will look, allowing me to move from the frontend to backend quite seamlessly. I've used React as well to develop widgets and such, but nothing has matched my ability to build, test, and ship features more than Ember.
We are all in this together and should focus on lifting all of us up. Positivity begets positivity.
Having said that, one of the reasons that Ember's core development seems so slow is because everything is announced beforehand, even discussed before hand. So if a feature A is proposed, it first needs to be submitted through RFC, go through a long period of discussion in Github then implemented and only then released. So it appears that it takes a long time to deliver features but it isn't really like that.
Umm, I'm not sure that a "disclaimer" actually nullifies that.