71–80 of 104 posts
Earlier quoted context omitted.
Backbone is a library, not a framework.
Backbone is still a major player in the ecosystem, whatever you call it.
Congratulations! I remember looking at Ember way back and bring really unsure since it was all over the place. You all have done incredible work; I'm looking forward to building with it! Regarding hosting an Ember app, can you use something like s3 with cloudfront or will it not refresh fast enough to be usable?
After building some single page JS web apps small and large, I am not sure that building large JS web apps is actually a good idea. In fact, a lot of the time they probably aren't a good idea. It is often better to just build out separate pages and on a page that requires more interactivity, use knockout or something similar.
Variety is always good, but with all JS frameworks I'm really getting confused about which framework to choose.
I've been developing on AngularJS for a while now, and have been constantly checking Ember's development. I happen to like a lot of stuff in Ember and meant to use it in production. I mean, I really want to use it! However, it took forever to reach this state. It was always beta, rc or some other non-production version, in rapid development with API changes and stuff. While this is great news that it's finally a stab…
Ember Data, on the other hand, hasn't been ready. I also took the plunge with Ember Data with 0.12, and it turned out to be a mistake that's still looming over my head. (I think I would have been better off with Ember Model, or EPF which didn't exist at the time. Yes, I understand when you're new to the ecosystem, they all sound the same.) I think this has been a big part of where the confusion stems from. People who are new to Ember don't realize that Ember Data is a completely separate project with its own status.
Please correct me if I'm wrong, but as far as I understand, there's no equivalent of Ember Data in Angular. Am I right? If that's right, then of the little bit you've said, it seems like you've run out of excuses not to use Ember :)
Let's not use this opportunity to start another Ember vs Angular argument. Can we instead take a moment to celebrate the fact that we now have two major, stable, fast, capable, testable, tested, supported, documented, git-hubbed single-app javascript frameworks with large, passionate communities. Let's also recognise and celebrate the hard work put into these projects by the Ember & Angular teams. Ember and Angular a…
Since when did Backbone not count as a major framework?
I said, "Let's not use this opportunity to start another Ember vs Angular argument."
I've been developing on AngularJS for a while now, and have been constantly checking Ember's development. I happen to like a lot of stuff in Ember and meant to use it in production. I mean, I really want to use it! However, it took forever to reach this state. It was always beta, rc or some other non-production version, in rapid development with API changes and stuff. While this is great news that it's finally a stab…
I definitely hear your concern. But on the flip side, I decided to take the plunge with Ember rc2, and I've had to deal with very few breaking changes. And of the breaking changes, they were very minor. I didn't have to re-architect anything. It's been very pleasant, and the amount of value I've been able to extract out of Ember has been tremendous. So much so, that I've held off being a huge advocate since I conside…
Angular has nothing like ED. There is $resource, which is basically a wrapper around $http to provide some sugar. Not really extensible. But it works. The thing with angular is that the change tracking is transparent, so any simple javascript object / array is fine as a model. That makes it bearable to work with an inferior data library.
At work we have been using Angular for about a year and we had evaluated Ember and decided not to use it because it wasn't really as good at the time. It may be better now, but I'm not as excited. Here's why: 1. For most applications, the JS MVC framework needs server-side backing, so don't fool yourself: You are no longer using MVC- you are using MVC X 2. There is no magic server-side out there that runs on self-gen…
I agree that mobile development is driving a lot of this. If you've built mobile-first, then you already have an API that services multiple clients. And the web app is just another client, no?
So it makes me wonder, maybe what we need is the equivalent of Ember Data that runs on iOS and Android to bridge the gap between the API and the native framework.
Earlier quoted context omitted.
I definitely hear your concern. But on the flip side, I decided to take the plunge with Ember rc2, and I've had to deal with very few breaking changes. And of the breaking changes, they were very minor. I didn't have to re-architect anything. It's been very pleasant, and the amount of value I've been able to extract out of Ember has been tremendous. So much so, that I've held off being a huge advocate since I conside…
Haha yes I'm aware that it's a seperate project but it also seems like a tightly bound seperate project. I'd not be surprised to see some changes in Ember for the sake of ED's convenience for example. Ember Data is destined to be the dominant solution when it goes stable. That makes me want to use Ember Data, you know, it feels like "the whole stack". But I can't now :) Angular has nothing like ED. There is $resource…
This is why I'm saying I think a lot of people fall for the same trap/gotcha as you. Ember Data is totally not necessary to be productive with Ember.
Why is this better than jQuery? I haven't looked at the full code base and documentation but did watch the 25 min demo video posted in this thread and thought: "Well, I can do all of this with jQuery too probably just-as fast.". What makes this different? Am I missing something?