Ember.js was created by big names in the rails community, and made big promises of being a rails like batteries included all in one framework.
There's a reason it didn't really get the popularity the other frameworks got.
Ember.js was created by big names in the rails community, and made big promises of being a rails like batteries included all in one framework.
There's a reason it didn't really get the popularity the other frameworks got.
I wonder how much of that is "The JS universe just moves too damn quickly!" vs "Nobody wants Ember".
Seems like wycats is interested renewing his Ember work as of late.
The JS universe moved quickly for about two years. The most popular frameworks at this point have been around since that time, with a few oddball upstarts. They've undergone some big changes, but are at the core the same concepts.
I recall evaluating Ember right around the time they switched from their last pretelease of I think 1.0 and suddenly all the documentation was either gone or out of date and not applicable. I ended up going with AngularJS (1.23 maybe?) and didn't look back until I went to work somewhere that used ember exclusively. It was far less pleasant to use than anything else I had been using up to that point except maybe Backbone.
There's been a few additions to the JS core APIs like webgpu and a few others, but all of them have been extremely niche. There's not much that's been added since 2016 or so that you couldn't pick up in a heartbeat, so it really boils down to the frameworks themselves. Ember lost to AngularJS, then Angular and React.
My reasoning for not using ember was it’s steep learning curve and easier libs(angular 1, backbone, react) to work with at the time(~2012 to 2014). Honestly, react wasn’t very big during this period, it was Angular that truly dominated.
What was the reason?
I’d guess that it’s because React came around and it was from Facebook so it got a lot of adoption? Maybe there’s some other reason, the comment you responded to seems to imply something anyway
The way I remember it around 2006 there were a few up and coming web development shops in my town that had their practice centered around Rails. That last half of the decade I was working on advanced RIAs like knowledge graph editors and decision support tools using systems like GWT and Silverlight that were not Javascript but had the same async comm challenges.
Circa 2010 those people who were so successful with Ruby had come to the conclusion that they couldn't sell RoR apps anymore so instead they were struggling with Angular -- not to do anything they couldn't with do Rails but rather they though customers demanded applications that looked like Angular applications.
React was a big hit because it was an "Angular" which people could actually deliver working applications with. Its strength I think it is that it addressed certain concerns but left other ones unaddressed such as the theory of async comm. If there is a simple mapping between the state of the application and the state that is represented in the React tree life is great but I look back at the applications I was writing in 2006 and it still looks like a regression.
What I like about it is that I can draw absolutely anything I can imagine with it, even 3-d virtual worlds
https://aframe.io/
Vue has a model which is closer to my mental model of web forms with first-class lists but I can see how to get into "you can't get here from there" situations.
I see the problem React solving is "how to compose an application out of components" and compared to WPF, JavaFX, and such, it's dramatically simpler, it's like a missing chapter out of Graham's On Lisp
I wasn't deeply involved in the Ember.js ecosystem as a user or maintainer, but the impression I got was that, for frontend purposes, clearer abstractions and simpler code was much more critical than "batteries included" frameworks like Rails.
Basically, if Ember.js used abstractions that were better for, say, extremely complex applications, it was dead in the water, because most applications make their library decisions when they are small and relatively straightforward. The market for javascript top-to-bottom rewrites of extremely complex apps (where something with those more complicated abstractions shine) wasn't really large enough for it to become dominant.
I also found it difficult to reason with, even though I'm an experienced Rails developer used to spooky action at a distance in the framework. Something about troubleshooting on the frontend really made it more difficult.
Javascript ajax was getting out of hand. Everyone wanted SPAs but managing the state of each button was becoming extremely unwieldy. Thousands of jQuery/js lines, the submit button wouldn't toggle to enabled once disabled...stuff like that. React came along and had prop state per element on a page (as they rebranded it, components), which helped immensely in this department.
Edit: and yes, as you said, it came from Facebook, so it wasn't just a solo developer's grad project; it had a large amount of support right out of the gate.
IMO it's that frontend wasn't really a separate discipline at the time. Ember came out of Sproutcore, which was a framework created by some Apple MobileMe developers. They were building something that was very much an application development framework for single page apps before the term 'SPA' even existed. And I think people doing front end just weren't ready for that level of complexity yet. Most web developers were self taught and didn't have experience with UI frameworks and "real programming". At the time, doing frontend largely meant using jQuery to do ad hoc DOM manipulation and AJAX requests. Angular and then React came out and only tried to solve a subset of the problem that Ember was trying to solve, so they were easier for people to get started with. Then as time went on, it turned out that everyone did actually need solutions for everything else, but by then React had won.
There's definitely a number of reasons, but I vividly remember _struggling_ with Ember data at the time. The framework itself was already complicated and the data management story felt immature and rigid in addition to complex. That definitely pushed me towards and a number of others towards backbone and eventually React.
I think it adopts some ruby conventions (one I discovered is the name in singular vs plural can mean different things like a collection and an item of a collection). I think there are a lot of conventions like this - you have to know.
I am not a UI developer and just needed to understand/debug something, it was not easy at all.
I honestly love Ember.js, but a huge reason it had limited adoption was because it was extremely difficult to incrementally migrate to it.
React could be introduced only where it was needed, but Emberjs really wanted to be everywhere and in control of everything.
what reason?