Why we're moving away from Ember.js • Hacker News Board

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

#21

Post by bcardarella » Fri, Mar 22, 2013, 6:57 PM UTC

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

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

#22

Post by MatthewPhillips » Fri, Mar 22, 2013, 6:59 PM UTC

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.

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.

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

#23

Post by davedx » Fri, Mar 22, 2013, 7:03 PM UTC

troygoode wrote: post #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 prede…

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?!

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

#24

Post by tomsthumb » Fri, Mar 22, 2013, 7:20 PM UTC

andrzejkrzywda wrote: post #10

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.

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.

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

#25

Post by allenc » Fri, Mar 22, 2013, 7:24 PM UTC

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.

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

#26

Post by combataircraft » Fri, Mar 22, 2013, 7:25 PM UTC

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.

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

#27

Post by jcromartie » Fri, Mar 22, 2013, 7:26 PM UTC

rohandey wrote: post #13

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/

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

#28

Post by wycats » Fri, Mar 22, 2013, 7:27 PM UTC

troygoode wrote: post #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 prede…

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

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

#29

Post by terbanator » Fri, Mar 22, 2013, 7:32 PM UTC

psycr wrote: post #19

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…

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?

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

#30

Post by outside1234 » Fri, Mar 22, 2013, 7:33 PM UTC

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.