5 ms·

Ember.js 1.0 RC4 released

129 points by ebryn 13y ago

ahawkins 13y ago
I'm happy to see RC4. Ember has really come a long way since I started using it. Ember itself has really stabilized. I'm really looking forward to 1.0. There is one more thing I'd really like to see before hitting 1. https://github.com/tildeio/router.js/pull/19 https://github.com/tildeio/router.js/pull/19 is probably the most important thing happening right now. 1.0 will not be there until these problems are addressed. I hope to see the PR make it to 1.0.
- lukenyc 13y ago
  Agree. The router needs a little more power and then 1.0 will be pretty sweet.
- machty 13y ago
  This will definitely be in before 1.0
rustc 13y ago
Can 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?
- sync 13y ago
  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 -- it doesn't get significantly more complex than that initial learning curve.
  - Osiris 13y ago
    This is the same experience I had. I built a simple Angular app quickly but I soon realized I didn't understand how to go from the sample code on their website to doing more complicated things as the structure of the framework is very different from what I am accustomed to.
  - Finbarr 13y ago
    This was my experience exactly. I started a project with Angular and got the basics set up without difficulty. When it came to integrating Google Maps, it was a nightmare and I switched to Ember. It took me a little while to figure out "The Ember Way" but the integration is very clean and understandable now.
  - zwily 13y ago
    I haven't built anything in Angular yet, but I can vouch for the Ember side of this. Getting started was pretty painful, but I now feel remarkably productive even in more complicated scenarios.
  - SonicSoul 13y ago
    from my limited experience with Ember, it appears that it hosts entire application from a single base url, and overrides forward/back buttons so that the page doesn't reload in order to keep state. instead it uses query string view paths and tokens to navigate around right? Does Angular support anything like this?
    - bluepnume 13y ago
      What you're describing is pretty much fundamentally a "single page web app". This is a pretty common pattern for frontend apps.
  - ahawkins 13y ago
    Very high learning curve but it levels out. It doesn't get more complex unless you make it. It's hard to transition to a fully async environment if you're coming from the server side.
  - 13y ago
- Osiris 13y ago
  The Ember app that I'm working on has about 20 controllers plus all the models, templates, etc. It's a few thousand LOC right now. We use it because we don't actually serve (much) HTML. We server up basically an empty DOM and the Ember app uses Handlebars templates to generate the entire webpage as it pulls data from our REST API. Akamai hosts all our Ember code + handlebars templates + css + images, so the client only hits our servers for the REST API. I've done some Angular with a simple internal tool, but it didn't see possible (or at least very easy) to take a similar approach so we stuck with Ember.
  - aidos 13y ago
    I'm obviously misunderstanding something in your comment because that sounds exactly like how you'd build an app with Angular. Could you explain the issue in a little more detail.
- ethermal 13y ago
  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 of evaluating these two frameworks I found KnockoutJS and I chose it for my large project that is one year into development. After one year with it I love it more now then when I first started. It's not perfect but it is a really well thought out framework, it does lack some documentation, ko.utils I'm looking at you. But it's documentation is vastly superior to the other two frameworks, at least it was a year ago. It's very stable and I prefer the team's approach. The two binding and subscription model is great for solving some intricate problems. It's easily extensible with custom bindings and unlike angular doesn't favour bad coding habits that lock you in to the framework, I forget the name now but their custom HTML tags (I think they call them directives) is nothing but bad news and vendor lock in.
  - TylerE 13y ago
    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.
    - steveklabnik 13y ago
      http://eviltrout.com/2013/03/23/ember-without-data.html http://eviltrout.com/2013/03/23/ember-without-data.html
- mahmoudimus 13y ago
  You can see an open source, hosted dashboard that we're developing here: https://github.com/balanced/balanced-dashboard https://github.com/balanced/balanced-dashboard It's live @ https://dash.balancedpayments.com/ 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.
  - grncdr 13y ago
    just FYI, that renders like this: http://imgur.com/rFXdS4l http://imgur.com/rFXdS4l (chrome 27)
    - mahmoudimus 13y ago
      Yes, it is supposed to (that's the widget page). You can log in - the actual index is coming.
- boubiyeah 13y ago
  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)
  - tomdale 13y ago
    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/4RSYaKmbtEk/uYnY3900wpIJ https://groups.google.com/forum/#!msg/polymer-dev/4RSYaKmbtE...
    - boubiyeah 13y ago
      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 :-(
gbadman 13y ago
For those wanting to give it a quick try, you can easily fool around with a simplistic Ember.js app on Plunker: http://plnkr.co/edit/gist:5206526?p=preview http://plnkr.co/edit/gist:5206526?p=preview I would love to see more of the Ember community on Plunker!
d0m 13y ago
Scary 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.

129 points by ebryn 13y ago

I'm happy to see RC4. Ember has really come a long way since I started using it. Ember itself has really stabilized. I'm really looking forward to 1.0. There is one more thing I'd really like to see before hitting 1. https://github.com/tildeio/router.js/pull/19 https://github.com/tildeio/router.js/pull/19 is probably the most important thing happening right now. 1.0 will not be there until these problems are addressed. I hope to see the PR make it to 1.0.

lukenyc 13y ago
Agree. The router needs a little more power and then 1.0 will be pretty sweet.
machty 13y ago
This will definitely be in before 1.0

rustc 13y ago

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

sync 13y ago
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 -- it doesn't get significantly more complex than that initial learning curve.
- Osiris 13y ago
  This is the same experience I had. I built a simple Angular app quickly but I soon realized I didn't understand how to go from the sample code on their website to doing more complicated things as the structure of the framework is very different from what I am accustomed to.
- Finbarr 13y ago
  This was my experience exactly. I started a project with Angular and got the basics set up without difficulty. When it came to integrating Google Maps, it was a nightmare and I switched to Ember. It took me a little while to figure out "The Ember Way" but the integration is very clean and understandable now.
- zwily 13y ago
  I haven't built anything in Angular yet, but I can vouch for the Ember side of this. Getting started was pretty painful, but I now feel remarkably productive even in more complicated scenarios.
- SonicSoul 13y ago
  from my limited experience with Ember, it appears that it hosts entire application from a single base url, and overrides forward/back buttons so that the page doesn't reload in order to keep state. instead it uses query string view paths and tokens to navigate around right? Does Angular support anything like this?
  - bluepnume 13y ago
    What you're describing is pretty much fundamentally a "single page web app". This is a pretty common pattern for frontend apps.
- ahawkins 13y ago
  Very high learning curve but it levels out. It doesn't get more complex unless you make it. It's hard to transition to a fully async environment if you're coming from the server side.
- 13y ago
Osiris 13y ago
The Ember app that I'm working on has about 20 controllers plus all the models, templates, etc. It's a few thousand LOC right now. We use it because we don't actually serve (much) HTML. We server up basically an empty DOM and the Ember app uses Handlebars templates to generate the entire webpage as it pulls data from our REST API. Akamai hosts all our Ember code + handlebars templates + css + images, so the client only hits our servers for the REST API. I've done some Angular with a simple internal tool, but it didn't see possible (or at least very easy) to take a similar approach so we stuck with Ember.
- aidos 13y ago
  I'm obviously misunderstanding something in your comment because that sounds exactly like how you'd build an app with Angular. Could you explain the issue in a little more detail.
ethermal 13y ago
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 of evaluating these two frameworks I found KnockoutJS and I chose it for my large project that is one year into development. After one year with it I love it more now then when I first started. It's not perfect but it is a really well thought out framework, it does lack some documentation, ko.utils I'm looking at you. But it's documentation is vastly superior to the other two frameworks, at least it was a year ago. It's very stable and I prefer the team's approach. The two binding and subscription model is great for solving some intricate problems. It's easily extensible with custom bindings and unlike angular doesn't favour bad coding habits that lock you in to the framework, I forget the name now but their custom HTML tags (I think they call them directives) is nothing but bad news and vendor lock in.
- TylerE 13y ago
  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.
  - steveklabnik 13y ago
    http://eviltrout.com/2013/03/23/ember-without-data.html http://eviltrout.com/2013/03/23/ember-without-data.html
mahmoudimus 13y ago
You can see an open source, hosted dashboard that we're developing here: https://github.com/balanced/balanced-dashboard https://github.com/balanced/balanced-dashboard It's live @ https://dash.balancedpayments.com/ 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.
- grncdr 13y ago
  just FYI, that renders like this: http://imgur.com/rFXdS4l http://imgur.com/rFXdS4l (chrome 27)
  - mahmoudimus 13y ago
    Yes, it is supposed to (that's the widget page). You can log in - the actual index is coming.
boubiyeah 13y ago
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)
- tomdale 13y ago
  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/4RSYaKmbtEk/uYnY3900wpIJ https://groups.google.com/forum/#!msg/polymer-dev/4RSYaKmbtE...
  - boubiyeah 13y ago
    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 :-(

gbadman 13y ago

For those wanting to give it a quick try, you can easily fool around with a simplistic Ember.js app on Plunker: http://plnkr.co/edit/gist:5206526?p=preview http://plnkr.co/edit/gist:5206526?p=preview I would love to see more of the Ember community on Plunker!

d0m 13y ago

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