Live data from Hacker News

Why we're moving away from Ember.js

errplane.com

1–10 of 66 posts

Re: Why we're moving away from Ember.js

#2
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?

Re: Why we're moving away from Ember.js

#3
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.

Re: Why we're moving away from Ember.js

#6
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.

Re: Why we're moving away from Ember.js

#8
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.

Re: Why we're moving away from Ember.js

#9

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 :)

Re: Why we're moving away from Ember.js

#10
post #6

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.
Post reply on HN