It would be helpful if some of you could share links to the production Ember apps you're working on.
Why we're moving away from Ember.js
41–50 of 66 posts
Re: Why we're moving away from Ember.js
#42Let 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.
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 eco…
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.
Re: Why we're moving away from Ember.js
#43Let 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.
Re: Why we're moving away from Ember.js
#44Yapp 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.
Re: Why we're moving away from Ember.js
#45Ember 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…
> 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."
Re: Why we're moving away from Ember.js
#46Earlier quoted context omitted.
> 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 s…
>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?
Re: Why we're moving away from Ember.js
#47His 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.
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.
Re: Why we're moving away from Ember.js
#48ActiveModel::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.
Re: Why we're moving away from Ember.js
#49Earlier quoted context omitted.
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.
Re: Why we're moving away from Ember.js
#50I'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 t…
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?