As someone who has moved from using Ember daily for 2+ years to now using React/Redux, I miss Ember on a daily basis. React suffers from lack of standardization like no other. I hate starting a new project or working on an existing project and having to think about where to put things. Ember grew from developers who existed in the Rails space and understood that convention over configuration is the way to go. React devs likely came from Express land where everything is composed of tiny modules that you'll spend days carefully putting them all together.
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
>As someone who has moved from using Ember daily for 2+ years to now using React/Redux, I miss Ember on a daily basis. React suffers from lack of standardization like no other. I hate starting a new project or working on an existing project and having to think about where to put things.
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.
I still strongly favor Ember for exactly the reasons React and other frameworks simply haven't caught up: the out of the box experience.
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.
> 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?
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.
I started using React properly a year ago and I was dreading having to tinker with scripts for 72 hours.
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.
> 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?
Isn't this what `create-react-app` is supposed to solve?
>with React, I'd spend the first couple of days just fiddling around with build scripts.
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'.
I'm just going to say it: Their mascot was an annoying hamster.
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.
I think it's more about corporate sponsorship and branding.
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 hate that this is the defining thing people look for in their front end libraries.
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.
I think there is a lot of tribalism in the js community and liking one framework (often the one you use for work) is synonymous with hating the others. Take this survey done where the people who have "heard of Ember and would NOT use it" is completely outsized with the rest of the data. (https://stateofjs.com/2017/front-end/results/)
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.
>I think there is a lot of tribalism in the js community and liking one framework (often the one you use for work) is synonymous with hating the others.
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.
> I think there is a lot of tribalism in the js community and liking one framework
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.
> Not apps that need to work on shitty connections or devices.
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.
I think it's the natural evolution of frameworks. About 5 years ago, we had the Cambrian explosion of front-end frameworks -- Angular, React, Ember, Meteor, Backbone, even jQuery was still hot back then, and certainly dozens more. Technology had advanced enough that we finally were seeing new innovative ways of building web apps, and everyone had their own opinion on how to do it the Right Way.
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.
We've been using Ember at Intercom for over 4 years to build our main app.
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.
In my mind, if you need a large framework that a whole team can use day in and day out, Ember is the go-to choice. It's got a lot of batteries included and the learning curve is pretty steep, but it has patterns and a way to do things for just about everything. It's also been rapidly absorbing the best parts of other frameworks and approaches -- fastboot, glimmer, etc.
- 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.
> 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.
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 really feel for Ember - we picked it for a project we started a few years ago because react was still very new and angular was in the middle of the 2.0 transition. The Ember folks really made sure that transitioning to new Ember versions is straightforward. I don't even enjoy writing javascript, but I have really nothing but good things to say about it overall.
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.
> What are your thoughts? What, if anything, should be done to make Ember relevant in the JavaScript horizon again?
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.
We us Ember at my company. We started using it around the 1.0 release. We have been very happy with it. But as a shop that doesn't really have any dedicated front end developers the most frustrating thing for us is that their conventions are always changing or worse threatening to change but don't so your left always wondering if what you are doing is the right thing. People have been waiting for controllers to be deprecated for years. That being said I think they do have to make these changes to keep the framework moving forward and I appreciate the amount of effort they put in to keep things backward compatible. I think now that they are providing code mods for a lot of the new conventions people won't be as hesitant to upgrade. Before there was a lot of friction when upgrading to a new version that had different conventions and you felt you should go and modify your existing code to follow the new conventions. I have confidence that with their strong user base they will stay relevant for many types of applications. If people are hesitant to try it I'd tell them to keep in mind that even though Ember has conventions and provides the ember way of doing things it is possible to integrate most of the exciting things going on in the js world with Ember. Some people even use react components in their ember apps.
I invested a lot of my time over the last few years into Ember and though it was a difficult decision I eventually had to accept that I would be better off moving to Vue.js. I have written a bit about my decision here:
https://hackernoon.com/why-i-am-migrating-propertywebbuilder...
Its a shame but the reality is that ember will not stand the test of time.
I was confused by the title but this is about EmberJS, the web front-web framework.
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.
The premise seems to be that popularity is what's important. I'd say the useful metric is whether or not you can be productive with the tool at hand. Popularity is sometimes something that can make a framework more productive (as tutorials, documentation and libraries are released), however popularity is hardly a prerequisite.
Popularity is important if you want to hire developers - developers are generally less interested in moving their career in a different direction than the industry trends.
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.
I am a junior frontend dev working on my first dev job and both the main web apps (customer facing web app and internal tools web app) are in Ember.
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.
That's me understanding as well. NG and React are the top players and VueJS and EmberJS are niche. On stackoverflow jobs looks like around the end of 2017 Vue jobs > Ember jobs.
http://reallyhyped.com/?keywords=vue.js%2Cember.js
My very first job after University was creating a large app in Ember. I had no modern Javascript experience but I was productive enough with it to build a pretty complex SPA with a lot of bells and whistles. So Ember has a fond place in my heart.
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.
For any indie developers, Ember can be extremely productive. In the past year, I have pushed out 3 moderately complex Ember apps in addition to having a full time job. I've reused some code for each application, have been able to depend on backwards compatibility for addons and always have received lots of help from other community members here: embercommunity.slack.com
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 worked with React and Ember, in Ember I am super productive. I can setup a whole app in a couple of days. I think the market is so big in front-end that even a relatively small market share is actually quite big in absolute numbers.
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.
I'm not surprised, I've had mostly negative experiences with Ember. We wrote a pretty small web app and several of my colleagues had immense problems getting into it and making changes. (People who had JS experience and had used other stuff in the past.) We ended up rewriting it completely in a week (as I said, it was small) into AngularJS and no one ever complained again.
It came and went, plain and simple. It made assumptions and design choices which at the time seemed sound but by today’s standards look silly. Mustache templates for instance. Separating logic from presentation should be a choice not a hard/fast rule with a severely limited templating engine.
I don't think it's any fault of Ember, but more that there are now other competing options in the front-end Javascript space, and these will naturally suit some other use-cases more.
I see a lot of people who like ember-cli, but after the first few minutes I just found it frustrating. Granted, this was a little over a year ago, but at that time if you simply wanted a npm module in your code you had to do all the extra work to wrap it in an ember plugin. IMO, this severely slowed down the ecosystem.
As far as I know it has never been required to wrap an NPM module in an add-on. I have used Ember since pre 1.0 and you could have just ember-browserify for the last 3-4 years to pull in an npm module.
Ember felt very Rails-y to me. The ember community felt entrenched in rails, and rails is reaching end-of-life. It is old-school thought. Ember made existing ideas better, a 2x gain maybe. I want new ideas, the 100x leap.
senoroink|8 years ago
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
coldtea|8 years ago
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.
tashoecraft|8 years ago
saurik|8 years ago
atonse|8 years ago
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.
davedx|8 years ago
> 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.
[1] https://github.com/facebook/create-react-app
simonw|8 years ago
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.
theodorton|8 years ago
Isn't this what `create-react-app` is supposed to solve?
zerr|8 years ago
rublev|8 years ago
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'.
abledon|8 years ago
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.
StevePerkins|8 years ago
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.
jdavila90|8 years ago
maxsilver|8 years ago
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.
ythn|8 years ago
heckanoobs|8 years ago
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.
coldtea|8 years ago
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.
ythn|8 years ago
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
anoncoward778|8 years ago
3pt14159|8 years ago
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.
berkes|8 years ago
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.
aclimatt|8 years ago
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.
darepublic|8 years ago
darepublic|7 years ago
gavinjoyce|8 years ago
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.
hardwaresofton|8 years ago
- 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.
megaman22|8 years ago
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.
makmanalp|8 years ago
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.
tboyd47|8 years ago
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.
mar225|8 years ago
realty_geek|8 years ago
Its a shame but the reality is that ember will not stand the test of time.
anoncoward778|8 years ago
tbassetto|8 years ago
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.
_m8fo|8 years ago
barrkel|8 years ago
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.
soneca|8 years ago
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.
antoniuschan99|8 years ago
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.
myth_drannon|8 years ago
orf|8 years ago
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.
snewcomer24|7 years ago
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.
icholy|8 years ago
jherdman|8 years ago
vasilakisfil|7 years ago
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.
wink|8 years ago
whalesalad|8 years ago
StevePerkins|8 years ago
Umm, I'm not sure that a "disclaimer" actually nullifies that.
matthewmacleod|8 years ago
chrisjshull|8 years ago
oneplusone|8 years ago
jacknews|8 years ago
dustingetz|8 years ago
atonse|8 years ago
draw_down|8 years ago
[deleted]
wildchild|8 years ago
[deleted]
mememaestro|8 years ago
[deleted]