Earlier quoted context omitted.
I'm throwing my 2 cents in, although I haven't built a large scale app with either, I did do a full evaluation of both before my latest large app and I decided on neither one. There were many reasons but every time I wanted to do anything that was remotely non-trivial both fell apart. Although most of that had to do with the MVC pattern more than the actual framework (but the two are tied intricately) In the process…
That's pretty much the same conclusion I came to. Wake me up once ember-data is stable and can support things like range queries and pagination, and just generally dealing with a small subset of data.
Ember.js 1.0 RC4 released
21–28 of 28 posts
Re: Ember.js 1.0 RC4 released
#22Can anyone who has tried Ember and Angular on moderately sized apps (500-1k+ LOC) compare their experiences? I'm using Angular, I love how little code I have to write to make testable apps with their two-way binding, and dependency injection. I went from 0 to Todo App in about an hour after I started to learn Angular. Should I give Ember a try?
You can see an open source, hosted dashboard that we're developing here: https://github.com/balanced/balanced-dashboard It's live @ https://dash.balancedpayments.com/ We're currently moving over the old dashboard to the new one, so it's currently a WIP. Happy to field any questions on Github.
just FYI, that renders like this: http://imgur.com/rFXdS4l (chrome 27)
Re: Ember.js 1.0 RC4 released
#23Earlier quoted context omitted.
You can see an open source, hosted dashboard that we're developing here: https://github.com/balanced/balanced-dashboard It's live @ https://dash.balancedpayments.com/ We're currently moving over the old dashboard to the new one, so it's currently a WIP. Happy to field any questions on Github.
just FYI, that renders like this: http://imgur.com/rFXdS4l (chrome 27)
Yes, it is supposed to (that's the widget page).
You can log in - the actual index is coming.
Re: Ember.js 1.0 RC4 released
#24Scary breaking change though. Something that was called automatically before isn't anymore. I personally would have opted for a safer alternative to implement this breaking change. I guess it's a little detail in the grand scheme of ember thing, but for the poor developers who will have RC4 on prod, there could be some very sneaky bugs.
That being said, happy to see ember getting closer to 1.0 Final, it's a beautifully designed framework.
Re: Ember.js 1.0 RC4 released
#25Can anyone who has tried Ember and Angular on moderately sized apps (500-1k+ LOC) compare their experiences? I'm using Angular, I love how little code I have to write to make testable apps with their two-way binding, and dependency injection. I went from 0 to Todo App in about an hour after I started to learn Angular. Should I give Ember a try?
Angular is vastly superior to Ember technology wise; Their approach is also more future proof (No stupid getter/setter, string templates, the architecture is based on something very close to web components, etc)
Re: Ember.js 1.0 RC4 released
#26Can anyone who has tried Ember and Angular on moderately sized apps (500-1k+ LOC) compare their experiences? I'm using Angular, I love how little code I have to write to make testable apps with their two-way binding, and dependency injection. I went from 0 to Todo App in about an hour after I started to learn Angular. Should I give Ember a try?
Angular is vastly superior to Ember technology wise; Their approach is also more future proof (No stupid getter/setter, string templates, the architecture is based on something very close to web components, etc)
Thank you for your well-reasoned comment. However, it sounds like you're basing your opinion on some misinformation. That's okay, it happens to everybody. :)
Ember.js is extremely future-proof. Yehuda Katz, who I work with on Ember.js, is on both the W3C and TC39, the committee designing the next version of JavaScript. Needless to say, we have a pretty good idea of what's planned for the future of the web platform; we're also very involved with the standards bodies to make sure it is as powerful as possible for building web applications.
Setters and getters are a trade-off. While we'd prefer not to require them, the alternative is that you have to diff objects every time a change happened. And not just a change, but a possible change—which means in response to almost any event. By using getters and setters, we avoid this particular performance footgun.
Actually, Ember views have much more in semantically common with Web Components than Angular directives, despite the fact that many people like to repeat this misinformation. For more, see this thread on Google Groups: https://groups.google.com/forum/#!msg/polymer-dev/4RSYaKmbtE...
Re: Ember.js 1.0 RC4 released
#27Earlier quoted context omitted.
Angular is vastly superior to Ember technology wise; Their approach is also more future proof (No stupid getter/setter, string templates, the architecture is based on something very close to web components, etc)
Thank you for your well-reasoned comment. However, it sounds like you're basing your opinion on some misinformation. That's okay, it happens to everybody. :) Ember.js is extremely future-proof. Yehuda Katz, who I work with on Ember.js, is on both the W3C and TC39, the committee designing the next version of JavaScript. Needless to say, we have a pretty good idea of what's planned for the future of the web platform; w…
Yes, forgive my tone. I should just have said that when it comes to picking a third party framework (I don't always do), I personally prefer the compromises made by Angular than the ones made by Ember. Of course, the biggest compromise of Angular (dirty checking all over the place just to be sure) also make it unsuitable in a number of situations :)
About future-proof, I mean the Angular programming model is closer to what we'll be doing in a few years (There won't be any get/set or computed properties anymore); I never implied the Ember team is not aware of what's coming.
To me none of the frameworks are ideal, although I find Ember or Angular well architectured, as far as implementing the vision of the authors go. With the current capacities of Js and no compilation steps, compromises can not be avoided :-(
Re: Ember.js 1.0 RC4 released
#28Earlier quoted context omitted.
Ember is a lot harder to go from 0 to Todo App in an hour. There's a fairly steep learning curve, but once you've grokked the "Ember Way", building more complex apps is significantly easier. With Angular, you can build a Todo App in no time, but building anything more complex requires you to understand e.g. Services, Directives, and Transclusion. With Ember, you are just learning about Models, Views, & Controllers --…
Learning directives, services, and the scary sounding "transclusion" has not been an issue at all for my team and I who are using angular on a very large project and loving it. Directives are quite simple once you understand the basic principles. Transclusion when actually explained ( http://www.egghead.io/video/cjrBTjMvruI ) is a trivial and obvious concept. I understand the confusion one may have around services/fa…
For me it wasn't learning the terms, I didn't have an issue there. The problem was how limited Angular was in comparison to Ember, particularly the idea of directives. I actually spent a large amount of time on freenode discussing in the Angular chatroom how I might construct a directive to replicate a common jQuery plugin like Zurb's Joyride. In short it couldn't be done in anyway that seemed remotely non-hackish.
Ember has jQuery included, so using existing plugins is generally easy or at least possible. Beyond that, it has a far more powerful router (try doing deep routing with Angular. Angular UI's router may be changing this, but you would still have to include outside code to get the power of the standard Ember router) and in the future much more powerful REST support with Ember-Data (currently volatile, but still very powerful).
I started building a large application with Angular using FuelPHP for the REST server. Angular simply didn't have the power to do the things I needed it to at that time. Hopefully that's changing, since it seems to be the dominant framework these days.