Why we're moving away from Ember.js | Hacker News Reader

Why we're moving away from Ember.js

errplane.com

66 pointspauldix64 comments

I've been using Ember for nearly two months to build a product. Every day I've been writing Ember code and learning, and making plenty of mistakes. I've loved every minute of it.

To be clear, I was a huge Ember skeptic last year. I've lived through the Microsoft WPF and Silverlight attempts to bring bindings and all that goodness to developers before, and then watch them make it so complex and poorly documented that no one used it, and they died except on banking LOB apps. I worried that the same would be true of Ember.

So I started to give it a crack of the whip, and really use it to build an ambitious (at least for me) product. Yes, it's been tough, and yes at the moment there is an almost Wittgenstein-esque 'throw the ladder away once you have climbed it', but I've never felt so productive with a product that looks and works really well. My conversion came when I finally had something click, was able to start removing bunches of code and lean on Ember to co-ordinate almost everything.

I recently had a run-in with Ember Data that left me really frustrated, and now (today even) I'm re-learning and checking my assumptions and to be honest, I think the problem was my understanding and not Ember Data. That said, it is clearly marked DNUIP, so if you do use it in production, you should be prepared for a bumpy road.

Discourse doesn't use ember data and it has been an absolute pleasure to code in EmberJS. I think a lot of people don't realize just how simple it is to create an Ember object from an AJAX call and start using it. A finder is usually as simple as:

$.get("/user/eviltrout.json").then(function(json) { Discourse.User.create(json) });

I'll probably end up writing up an AJAX tutorial because I think a lot of people are underestimating just how simple it is.

This is our strategy as well at Uniiverse. This is also an effective way of ensuring that data is in sync, should that be a requirement in a particular state. Just attach the call on State.enter() and you're good to go.

We use this strategy also. In setupController functions, (of your routes), we typically run fetches and fill content of our controllers. Why does everyone get hung up on Ember-data?

How are ya'll caching your stuff? Sounds like all that is doing is just making fresh requests for every route.

We use a local storage method in browser and app data when running in phone gap

The Controller. Then you can do a quick check to see if `someControllerForState.hasData()`.

Same approach here. No ember-data just creating Ember objects within a type of DAO ember class/object using ajax calls to the server side. Caching is enabled both in client at that Ember controller and on the server side before hitting the data source, however this depends on the data requested. If offline capability is required on the browser or mobile device, local storage also comes into play. I agree that all this is really clear and simple.

Ember being impressive but not yet ready for prime time seems to be a common refrain on HN these days, and one of the big gaps holding Ember back appears to be Ember.Data. I have no doubt the team is working hard to improve Ember.Data and move it into "ready for prime time" territory, but why move Ember-proper to a "1.0" release without Ember.Data also being ready? Every major competitor to Ember (including its predecessor, SproutCore) has a data layer that does more than pass the buck off to jQuery. Yes, the move to 1.0 locked the non-Ember.Data portions of the API, but it seems short-sighted to believe that that will be enough for most users.

The "1.0" is communicating a set of implicit expectations that I suspect the core team didn't intend for it to quite yet. It was a mistake to "release" Ember itself as a 1.0 before Ember.Data was ready.

Yeah, you have to be very careful with what you assume about version numbers. Node.js is v0.10 which strikes me as overly-cautious version numbering. And Gitlab is... v5?!

> Every major competitor to Ember (including its predecessor, SproutCore) has a data layer that does more than pass the buck off to jQuery

SproutCore had a robust data layer, but 2013-era frameworks mostly expose HTTP directly as the abstraction to use, either via $.ajax or a framework-specific HTTP library. Other frameworks are not trying to solve data persistence and loading beyond delegating to HTTP, but Ember's solution isn't ready yet (so we don't get to say that it's a win of using Ember over the competition -- yet).

>Other frameworks are not trying to solve data persistence and loading beyond delegating to HTTP

I don't think that's true, given how Backbone and Angular are designed.

I'm not an expert in JS frameworks, but my understanding is that backbone converts 'save this model' to '{PUT,PATCH} /models/:id', and then makes the request.

Isn't that just delegating to HTTP?

I'm not sure how Ember Data is different beyond providing a smarter interface to collections and models than BackBone.

Hence 'not ready yet.'

Have you actually read http://docs.angularjs.org/api/ng.$http or https://github.com/documentcloud/backbone/blob/master/backbo... ?

Yes, I think we just disagree on how different and special Ember Data is.

> It was a mistake to "release" Ember itself as a 1.0 before Ember.Data was ready.

Ember 1.0 was released? Looks like only an rc-1 so far to me.

Also, Ember-data is a distinct project from Ember itself, no? It's in a different repo (https://github.com/emberjs/data) and states "This is definitely alpha-quality. The basics work, but there are for sure edge cases that are not yet handled."

Fine, you got me on "release" vs "release candidate." Still, it is clear that the plan is to release Ember as a 1.0 without Ember.Data (it would be very strange to add something of Ember.Data's scope into a release but not have it in the RC).

I'm aware that Ember.Data is considered separate. The entire point of my post was that I believe this is a mistake.

> It was a mistake to "release" Ember itself as a 1.0 before Ember.Data was ready.

I would only agree with that if ember.js were useless without ember-data or a similar data-persistence layer. I don't think it would be wise to delay the release of Ember 1.0 RC simply because ember-data is still in alpha. Not everyone is going to be using ember-data, and releasing ember without it lets them solve the data persistence on their own.

Unfortunately how separate Ember.Data is depends on which documentation you read. In general most of the official documentation assumes you're using Ember.Data. That makes it feel missing, not separate.

Very true. I don't think the distinction is clear enough that ember-data is a completely different repo, and I think that's definitely a problem.

I am working on a meeting agenda site which is all a JavaScript app talking to a backend API (Node) which hands out JSON in response. The project seemed simple enough to me that I felt like learning Ember, Backbone, etc. might take longer than it was worth.

So I solved some of these issues myself with rather simple solutions/brute force. For example the navigation issue; mine is a single page app. To handle reloads I am storing a cookie with what page the user was last on and any appropriate object ids to know what to load from the API. If they come back to the app at any point before closing their browser, it remembers exactly where they were and returns them there. That of course works for Refresh as well.

As for being able to link to a point inside the app from outside, that's what location.hash is for. For pages users need to be able to link other people to (in my case, the page where you view the agenda and can write minutes, etc.), I update the location.hash to one that if clicked on will send them there (and takes precedence over the cookies.) Granted it's not super elegant, but it works.

I've found that my single page app is remarkably fast even on a slow, old computer. I'm really happy with it. Starting out I was a little worried it might get unmanageable (and it may yet) but at this point I have a large majority of the functionality I wanted and it's still quite manageable.

Hi, I'm the lead Square Dashboard engineer at Square, and the one who wrote that blog post a year ago on building our app in Ember and D3.

I'll say that after a year's worth of experience with Ember, we've gotten much better at it, but we've still had to add our own components (e.g., a validation framework) or fork off what components and use + fix them before they're completely production ready. We accepted these tasks as a cost of living on the bleeding edge, but admittedly given the rapid pace that the API has changed in the past year, we've acculumated a bit of necessary tech debt.

W.r.t. Ember Data, that wasn't a consideration for us, as the component didn't exist when we were building Dashboard. That said, we chose to integrate with ED in one of our more recent features, and while I'd be lying if I said there weren't any pain, what we took away were learnings about how our non-ED models related to each other and informed subsequent refactors that made the overall app better.

We all expect to find a Rails/Django equivalent for JavaScript apps.

There's nothing like that.

All of the JavaScript frameworks are in their infancy. It doesn't mean we can't use them yet. It's just that they are not mature enough to be easy to use.

This is probably the most accurate and fair description of situation :)

The original SproutCore was pretty close to rails-level usability. At least, it helped frame up controllers and views with a handy tool.

We are going full-in on Ember at my consultancy, DockYard. I've been a big fan of the organization and the possibility of the framework. I've been developing in Rails and for me Ember has the most common-sense choices for building larget-scale complex client side apps. The framework is such that building abstractions on top of Ember is very nice. (for example my form builder library: https://github.com/dockyard/ember-easyform)

I do feel the pain of Ember-Data at times but the bad rep it is getting is not valid, this is pre-release software we're talking about. There are people (like us) "living on the edge" and working around the difficult sections of ember-data but there is a great plan in place to move ember-data forward: https://gist.github.com/stefanpenner/9ccb0503e451a9792ed0

ActiveModel::Serializers maintainer here.

We've been working closely with Discourse (which is currently running edge AMS) to make sure we have the easiest and best way to get data from your Ruby web framework into shape so that it's easily consumed by any JS framework, not just Ember.

It's important to get all of this stuff right: the seam in the middle is where your SPA talks to the back-end, and provides the ability to, for example, have two different teams work on each side without worrying as much about the format, or possibly even writing a new back-end without affecting the client side.

Feedback and comments very welcome: https://github.com/rails-api/active_model_serializers/issues... for bugs and https://groups.google.com/forum/#!forum/rails-api-core for feature requests and discussion.

I've been treating Ember-Data very cautiously, and feeding it carefully prepared data. The biggest irritations involve multi-record commits and validation/error handling. But it's working well enough for my straightforward needs. Still, don't touch it unless you like reading the source, and you're willing to use something that's marked "NOT PRODUCTION READY".

The Ember.js tutorial situation is abominable, but I see two or three new tutorials are out in the last two weeks. And after much head-scratching, I finally figured out what's up with Routes vs. Controllers vs. Views.

Keeping all those caveats very firmly in mind, I'm really happy to be using Ember. My code is lot cleaner than that of my previous web apps, and features are getting done fast.

When it hits 1.0 (including Ember-Data!), I think it's going to be one of several excellent choices.

Yeah, I know nothing about ember.js, can anyone point my in the direction of a tutorial or a simple example app so I can get my head around it?

I am an illustrator, turned front end developer, turned "just get it done" rails developer. I am currently working on a basic forum for a website that is 100% Ember powered.

Before finding Ember, I created "islands of richness" with Backbone.js. What was frustrating for me was my own lack of software engineering skills. I would design these hard to maintain apps that were just an absolute mess at the end. Like Rails, Ember opened this world of application development that has been such an absolute thrill to get into. It teaches me good practices, you instantly feel when you're doing something wrong.

I have been working with Ember every day for the past two months, and yea there are times that I get lost and it's frustrating, like struggling with complex forms in Rails for the first time, but you eventually move past it and the feeling is gratifying. I'm not the best dev in the world, but Ember has shifted my vision on what I can create completely, and I am really excited for the first time in a while.

For me, Ember isn't just a framework, I find myself using the Ember runtime everywhere. Where I used to take Backbone models and collections, I know take Ember core - even in a Node environment.

I really appreciate what Tom and Yehuda have done as well as the rest of the community. It has me excited to create in this new way I had not been able to before.

His complaints about the router also plague Backbone apps - how do you cleanly deal with users reaching the route through your app, and users navigating to a route directly?

I have had some luck with Backbone.routes (http://siong1987.com/posts/introducting-backbone-routes/) but it is still not quite where I want it to be.

Think of the router as the "main" method of your application. It's passing you the initial arguments. You just parse it and run the correct logic and/or display the view that is required.

That's a pretty handy shift in perspective.

I've hacked my webserver to respond to any request that looks like a Backbone route. For example, if you define a backbone route '/search/:query/:page', the server will return a minimal html page to any request starting with '/search'. The minimal html contains the backbone and app javascript, which then dynamically renders the page.

I've done something similar with a Symfony2 application I'm working on, but with a tweak.

The app is basically one big REST endpoint, but it does some header sniffing to handle requests with a "text/html" Content-Type. If it encounters one, the request to the still goes through and returns JSON, but that response is then injected as a preloaded datastore into the template being rendered. This bypasses the whole double load scenario that Twitter once was. Discourse is a great example of this in action, just have a look at the view-source://

Always load index.html, give up the idea that "I'm already on the server, I should go ahead and render here", you'll never win trying to do that.

this is bad advice imo. in a good system you should render what people requested and then go from there, if the system does not cater for it then the system is not good enough.

You absolutely should render it, in the client.

I honestly just don't agree with this. any templating language you use should work equally well on the client or the server and you should be able to get anywhere. we obviously consider other types of constraints than you do.

We've been using Ember in our production environment for nearly a year now. There are lots of plus' and some minus', but I'd like to take a few minutes to share our experience.

We picked up Ember 0.8 in March of last year. Having some prior SproutCore experience it was a pretty easy thing to get going with. Back in those days, Ember was pretty nonconventional, there was a right way and a wrong way to do things, but the framework didn't really enforce a strong point of view. This was really good and really bad at the exact same time. The good was there was a much lower learning curve. The bad was it was so easy to head down the wrong path and shoot yourself in the foot.

I think in the summer of last year, just after Ember 0.9.8 was released, many of the core team members started to explore some the criticism and problems with the framework at the time. The end conclusion, from my view, was to restructure the architecture of the framework. The pieces were the same, but they fit together differently. The biggest of these changes was with the introduction of the strong router conventions. In addition, there we're major changes to the default template context, view hierarchy, runtime and metal, among others. IMHO this was the first time Ember really expressed a strongly enforced convention through the framework.

Fast forwarding to today. Ember has a lot of concepts that people have spent months and months working on. I can sit here and endlessly explain why how the router's pattern makes your application more flexible, or how the template patterns make for easy reuse, etc etc etc. But the truth is you won't really appreciate them until you've given Ember a fair shake.

EDIT: A fair shake doesn't mean picking it up on a weekend. A fair shake means trying to build a reasonable size application with it. Spending a two or three weeks. It has a big learning curve, but that doesn't mean it isn't valuable.

This post is titled wrong:

> I'm not yet ready to leave my server-side framework behind

That is the right title, pulled from the concluding paragraph.

This sentiment happens to apply to angular, backbone, knockout and everybody else.

The first thing I ever programmed was a single-page web app built with MooTools 5 years ago. Its still the most impressive application I've built and people ooh and ahh over it to this day (which is sad, since I was clueless).

When I think about all the JS I've written from then to now, nothing has the promise that ember + ember-data do. My ember code is so straightforward, declarative, and minimal.

Perhaps I haven't gone as deep as the author with ember, but when you pick a framework that is very openly pre-release software, and you're already apprehensive about "asynchronous data" (welcome to the web?) don't expect much success.

My company moved away from ember-data recently in favor of our own simplified replacement. I like the concept of ember-data but we just ended up fighting with it more than we'd like.

It's a bad idea if you go into ember expecting it to be a solution to all of the javascript development hurdles. You should expect to fight the framework from time to time. You should expect a learning curve.

The solution is to be a patient developer, become familiar with the ember code base and it's concepts, keep up to date on the community happenings.

We are more than ecstatic about the results of our nearly complete product and I am positive having used any other framework would have made our development more difficult, and without a framework would have taken multitudes longer.

I used to hate doing frontend work because of all the gruntwork: Now I love it. I used to hate javascript: Now I love it.

I attribute a lot of that to structure and grunt-work-handling of Ember.js.

I can't go back. Ember.js might not be where we end up in terms of the SPA framework we end up using (but if I were betting I'd say yes), but in general this is where web apps are going.

I wish there was more information about "where" they're going now. They imply that it's not Ember that's broken rather Ember isn't done and the problems are hard that Ember is trying to solve. So I'd ask - why not stay with Ember and help solve the hard problems? Or did you find another technology that "solved" it?

Those are both good questions. Currently, we're a team of two trying to maintain and evolve a production application. Believe me, we'd both love to have spent more time pushing the ball forward on Ember Data, but it just wasn't feasible. Besides, it's already on a maturation path that will resolve all of the issues before long - it just needs a little more time.

In the meantime, we're just keeping it simple and making magic with D3 and plain jQuery. We pushed all of the CRUD back to Rails, which is probably where it should have been in the first place.

Regardless, it was a great learning experience. I still highly recommend giving Ember a shot on something that's not on a tight deadline to get deployed to production.

The great thing about Ember is that it is NOT all all-or-nothing proposition. We have several apps that don't use Ember Data or the router, several that don't use one of the two, and some that use both.

Well it says right on GitHub, "Is It "Production Ready™"?" - "No. The API should not be considered stable until 1.0."

https://github.com/emberjs/data

Ember.js is as close to being finished as it can. We have a really large app under development, using Ember.js. It works so well. Better than anything I've ever used (and I've made single page Javascript apps since way before it was cool). Development is fast and fun. Often I sit back with a feeling like "Was that all that I had to do to make this work??". The performance is good, if not great. Ember cleans up everything it creates itself, which makes it very simple to make advanced apps that are easy on browser memory consumption.

It seems like Ember Data (and documentation, which is an easy problem to solve) is currently the only achilles heel of the whole Ember. But PLEASE don't judge Ember.js based on a pre-alpha version of an add-on library. There is no sense in that. Ember Data will receive its glory once it's done. Anybody who's every implemented a data persistence layer can tell you that it's not a trivial problem to solve.

Conclusion: Ember.js IS awesome. I love it. A lot of people love it. If you don't like it, then fine. Don't hate on it for no reason. I don't like cauliflower (I hate it), but I don't hate on people who eat it. I admire that they want to be healthy.

Yapp is built on Ember and it has been a joy. Terrific community and a lovely layered design that lets you work at the level of abstraction appropriate to the interaction you are building. We have ember-data in production in selective places, and it definitely has a ways to go to deliver on its full promise. That said, you can't really build an ambitious app without some model/persistence concepts, or without an identity map, so it is a big win for that already.

The common refrain that I hear talking to people in NYC and the wider internet world is that people want Ember what Ember promises and has begun to deliver. More and more of those folks (including my team) are rolling up their sleeves to help make it fulfill its promise.

I've been using Ember Data in all of my applications so far, two of them are in production, another one will be very soon.

Yes there are some rough corners and the documentation is really not that great, but that's something you have to expect from a pre 1.0 release, especially in the case of Data where it's clearly stated that it's unfinished.

The "problem" with Ember is that it's nothing like Backbone, and Ember Data is nothing like $.ajax. It is no surprise that Ember makes you do things a certain way, which is different than most people are used to.

This sometimes leads to thinking that "Ember is broken", but in reality most of the times you're just doing it wrong. I'm not saying that everything is rainbows and unicorns. I'm not even saying that Ember is easy, there's a pretty steep learning curve.

What I'm saying is that once you get past a certain point, most of the issues will just disappear, because you'll know why things "appear to be wrong" and how to fix them :)

I really don't think there's any good alternative to Ember right now, and if you're not satisfied with Ember Data, go ahead and use $.ajax. Discourse does it and it works great for them.

I like Ember over Backbone as it follows C over C which I found missing completely in Backbone. Though I feel that client side MVC have a serious case to use across all projects if file uploading and multi model support is seamless. File uploading hacks actually stops me from using it in major projects of mine.

Convention over configuration is fine until all you need is a little configuration, at which point it becomes a game of hunting down where the magic comes from and how to override it, because nobody thought that anybody would need anything other than the conventional approach, and so they didn't document how to configure it, and then your code turns into a bunch of workarounds.

I think Backbone is pretty aligned with this philosophy: http://www.python.org/dev/peps/pep-0020/

I've played around with Bootstrap and didn't like the idea of trying to replicate MVC on the client. Like the article said, I'm not yet ready to move away from server side frameworks for the most part. However, I like the data binding style of programming a rich client UI and I've actually found that Knockout.js is really nice for just doing that part. Does this seem reasonable? Would I gain anything by moving to Ember to do the same thing?

Nice informative article. People are always trying to go to the extreme with javascript and they should realize that its good to practice application development in moderation. Trying to heavily front-load an application almost always get you in the end, and its just taking a step backwards in application development. And especially so when dealing browser compatibility and JS.

Balance the front end and back end application development people!

I also started out using Ember.Data and later abandoned it due to similar issues (lack of validations being the biggest), but have stuck with Ember.js itself and am really enjoying it for a basic CRUD app.

Entering a route through a user hitting it directly vs. transitioning within the app should not be a problem with Ember.js, everything seems to just work for me at least. I suspect this is an education thing more than anything else.

Let me give you one reason to stop this bullshit: No Ember code is replaceable, can work together / integrate with any modern JavaScript code like over 30.000 NPM modules. It is the North Korea of the JavaScript world.

I use several npm modules in my ember app.

I did use Ember with many NPM modules, and actually structured couple of Ember apps as CommonJS projects.

But I'm pretty dissatisfied. Which makes me a troll.

Your comment history indicates that this is a troll account, but I'll reply in case a bystander takes your post seriously:

Ember is actually composed of many smaller, independent packages. For example, we built four microlibraries for use in Ember that you can use totally independently: router.js, route-recognizer.js, rsvp.js and metamorph.js.

Additionally, many people use other great projects from the JavaScript ecosystem to do Ember development, like D3, Crossfilter, mocha, Jasmine, etc. Your assertion that it does not work together or integrate with other tools is 100% false.

If my assertion is false,

- Where is one single Ember example re-using an NPM module by one of the brilliant & profilic authors producing high quality libraries, such as substack, visionmedia etc. ?

- Where is one single Ember example that can be required by a CommonJS project?

- Where is one single Ember module in NPM registry?

Sorry for trolling.

It would be helpful if some of you could share links to the production Ember apps you're working on.

Totally agree.

Reply on news.ycombinator.com