Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we're moving away from Ember.js

errplane.com

Post reply on HN
Print view View original

61–66 of 66 posts

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

#61

Post by fmargaine »

EvilTrout wrote: post #18

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 und…

Just for the kicks, you could simply write:

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

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

#62

Post by elliotanderson »

pnt wrote: post #12
STRML wrote: 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.

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

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

#63

Post by lennel »

MatthewPhillips wrote: post #49
lennel wrote: post #47

Earlier quoted context omitted.

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.

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

#64

Post by melc »

EvilTrout wrote: post #18

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 und…

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.

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

#65

Post by darthdeus »

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.

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

#66

Post by mpowered »

troygoode wrote: post #59
mpowered wrote: post #53

Earlier quoted context omitted.

> 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…

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