20 ms·

Ember.js 1.0 Released

311 points by ozkatz 13y ago

makepanic 13y ago
They also have a new builds page: http://emberjs.com/builds/ http://emberjs.com/builds/
matthewlehner 13y ago
Congratulations - This is really a huge step forward for both Ember, and front end development. I know that it has been possible to build rich front-end applications using JavaScript before now, but the API and tools around Ember are excellent and really make for a productive, convention over configuration development environment.
leokun 13y ago
Awesome, have been meaning to try ember. Just finished with a 6 month meteor.js binge. Which leads me to the question: what is a good real time push solution for ember? Does it have anything for that, or is that something I'd have to build in separately with socket.io or sock.js or something?
- gavinjoyce 13y ago
  There is nothing built-in but it would be straightforward to update your model data over web sockets. The magic of Ember bindings and observers will take care of the rest.
  - sambeau 13y ago
    Saying it would be straight-forward is a little bit of an exaggeration. While, true, Ember will happily update any model pushed to it the difficult bit i.e. pushing the right data to the right model (on the right client) and only the right model to only the right client is an exercise left to the reader. The cleverness of Meteor is not in the push, it's in the logic just before the push.
    - gavinjoyce 13y ago
      That's true, Ember doesn't have any data synchronisation mechanism over websockets like Meteor does. It is easy to update your data model from incoming messages but, as sambeau points out, pushing these data updates may not be a trivial matter.
    - zaius 13y ago
      I started down this path a month or two ago and you're right - it's actually quite a big job. I've been working on a real time system for rails / ember that moves all data over a websocket and allows subscribing to updates, however it has been very hard to get working with ember-data. I've currently have it running with my own (terrible) data layer but I would really like to get it running with ember-data again before I get it up on github.
ehsanu1 13y ago
I've been interested in using Ember.js in the frontend for a Rails app, especially after watching a mock competition between it and Angular [1]. But it's beta status kept me from using it, and even now I wonder if it really is production ready, or just API-stable (which they say they will be as per http://semver.org/ http://semver.org/). I also don't know if it's really worth the up-front cost of learning and slowing down initial development of a new product, especially while at a startup trying to set an aggressive release date for the product. I'm also a bit worried about the need for everyone on the team to learn how Ember works and its conventions, when they already know how to figure out whatever mess of ad-hoc jQuery and random objects someone would write instead (as bad as that is for maintainability). And finally, I won't have the advantage of green field development, as there is an existing app which will be added to. So there will end up being a chunk of the app with Ember, and a (functionally separate) part of the app not using Ember at all.. Which does not seem ideal. Anyone want to chime in with their experiences? [1] https://vimeo.com/68215606 https://vimeo.com/68215606 - Note it's a bit unfair with the project lead for Ember, tomdale, on one of the "cage match"
- sandstrom 13y ago
  We've used it in production for quite a while, and it has worked well for us. We gradually moved our previous jQuery-implemented app onto Ember, so it's certainly possible to do it in stages (we still have a minor section which we haven't moved yet, because it's up for rewrite regardless). There are still improvements to be made, but we're certainly happy to be using it live.
- gavinjoyce 13y ago
  > I don't know if it's really worth the up-front cost of learning and slowing down initial development of a new product This is true when considering the introduction of any new technology or when to pay down technical debt. The answer for you will likely depend on the complexity of the product that you are building, how important a great UX is, how close you are to shipping something, and whether the promise of building a clean and scalable browser application outweighs the short term benefits of delivering a "mess of ad-hoc jQuery and random objects". I've worked within a medium sized team building a large Ember application and have seen first hand how beneficial it can be when dealing with application complexity and a need for precise UX attention to detail, even when using a much earlier version. I've also experienced frustration with the documentation and quickly moving goalposts as the framework evolved towards v1.0. Happily, everything has become so much easier in the last few months. The documentation and guides are now a fantastic resource after a huge push from the team and community. The framework itself requires much less boilerplate code, Ember automatically generates controllers, routes and views at runtime should you not need to customise their behaviour. The addition of support for promises across the framework has resulted in more terse and consistent application code. I've found the community to be very helpful and I'm excited to see how it will grow over the coming months. > So there will end up being a chunk of the app with Ember, and a (functionally separate) part of the app not using Ember at all. I'm helping a client do exactly this at the moment. Their current application consists of a many pages with ball of JavaScript and jQuery sitting on top of their clean REST API. They want to raise the bar for what their application can do and the medium term goal is to deliver a single page Ember application. In the short term, we're building some of the most complex new features in Ember. These features will be accessed through modal iframes for a time allowing us to build out the Ember application without having to rebuild everything.
tomdale 13y ago
I said this already on Twitter, but: It’s been 2½ years since I started working on Ember.js. While I’m proud of the code we wrote, I’m even more proud of the community we built. We have been lucky enough to attract the companies and individuals that are tackling the hardest problems in developing 100% JavaScript web applications; people for whom the only acceptable answer is solid engineering, not piles of hacks. As we mention in the blog post, Ember.js went through a reboot midway through its life when we realized the thing we were building was not the thing that needed to be built. If you tried Ember.js previously and had a bad experience, I'd really encourage you to give it a whirl again. We've smoothed over the rough surfaces, and now have the documentation and community to help you get started. If you'd just like to take a peek at what building an Ember.js app is like, I recorded a ~25 minute screencast that takes you soup to nuts: https://www.youtube.com/watch?v=1QHrlFlaXdI https://www.youtube.com/watch?v=1QHrlFlaXdI Lastly, I'd like to express my personal gratitude to everyone that pitched in at the 11th hour to get this release out the door. I couldn't be more proud to call this awesome group of developers my friends.
- Kudos 13y ago
  Have you got that screencast available as a download somewhere?
  - tomdale 13y ago
    No, but that's a great idea. Do you have any recommendations for a host that can serve up files of this size?
    - terabytest 13y ago
      You might try Dropbox.
    - wildster 13y ago
      S3
      - cpursley 13y ago
Cieplak 13y ago
If you want to see ember in action, you can see how we use it in production: https://github.com/balanced/balanced-dashboard https://github.com/balanced/balanced-dashboard It has been a great tool in our toolbox, and we really feel the benefits of all the hard work and brilliance driving ember.
- Kudos 13y ago
  How come you guys aren't using push state? Does Ember not provide it in its routing?
  - tomdale 13y ago
    Ember.js supports pushState out-of-the-box, but it does require that you configure your server. For more, see the documentation: http://emberjs.com/guides/routing/specifying-the-location-api/ http://emberjs.com/guides/routing/specifying-the-location-ap...
  - mjallday 13y ago
    We have an open issue, https://github.com/balanced/balanced-dashboard/issues/370 https://github.com/balanced/balanced-dashboard/issues/370 , that documents what's blocking. We were using iframes for backwards compatibility while we migrated from a regular HTML dashboard to our new Ember.js one. We just removed the last iframe page (yay!) last week so I think we can finally get around to doing this!
noelwelsh 13y ago
So, isn't it time we had another Angular vs Ember discussion? I tried Ember some time ago and it just didn't click for me. It's hard to explain exactly why, but I found myself switching between too many files to get simple things done. I've done some simple Angular work recently, and found it a relatively simple system. In defence of Ember everything about the project -- docs, community -- seems to be better organised than Angular. The Angular docs are hilariously bad.
- sambeau 13y ago
  How about we all try them first?
  - noelwelsh 13y ago
    Well, one reason to get others' opinions to avoid having to try everything oneself. Time is limited.
    - sambeau 13y ago
      Well, yes. I was more hoping those that have a strong opinion on one or the other would ensure that they try them both first.
  - jonahx 13y ago
    While this attitude is in-line with general hacker values, and is good advice when dealing with simple tools, it is a poor general principle when applied to complex tools with an ecosystem of experts whose opinions you trust. In the case at hand, spending half a day each (or even more) with angular and ember is not enough time to gain a truly informed opinion of either. These are big frameworks with many features, and each harbors both gotchas and benefits that won't emerge until you've worked with them over time in real projects. For developers with limited time, asking advice from fellow trusted developers is not only acceptable, but also, in many cases, the clearly optimal strategy. Of course, the trick is to find experienced people to ask with tastes and values similar to your own.
msoad 13y ago
I'm not very familiar with software licensing. What Ember.js licence means for production use?
- tomdale 13y ago
  Ember.js is released under an MIT license: https://github.com/emberjs/ember.js/blob/master/LICENSE https://github.com/emberjs/ember.js/blob/master/LICENSE Use it however you'd like; contribute back if you want to.
sintaxi 13y ago
Congrats on the significant milestone. All the best moving forward.
sambeau 13y ago
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 are two shining examples of modern open-source software. We can debate the finer points and minute advantages of each framework later, preferably once we've all tried them both. Congratulations, Ember 1.0! Roll on, Angular 1.2!
- Kudos 13y ago
  > documented Does Angular really qualify here? Technically it's documented, but they're terrible.
  - iamstef 13y ago
    lets just be happy about open-source. The magnitude and quality of work being contributed is amazing.
- danso 13y ago
  Since when did Backbone not count as a major framework?
  - mayhew 13y ago
    Backbone is a library, not a framework.
    - Helianthus 13y ago
      Backbone is still a major player in the ecosystem, whatever you call it.
      - Demiurge 13y ago
        It's more like the ORM. And I use it quite nicely when that's what I need. However, I can't compare it to Ember.js, because it can't replace it and other features in Ember.
forlorn 13y ago
I wish there were more docs/tutorials/examples in the wild. I truly love this outstanding project and I'd like more people to join the ember.js community.
- raphaelsaunier 13y ago
  I don't know if you have already come across it, but http://emberwatch.com http://emberwatch.com is a great aggregator of all the resources on Ember in the wild.
- mehulkar 13y ago
  There's also some great work going on with cookbooks that should be released soon. https://github.com/emberjs/website/tree/master/source/guides/cookbook https://github.com/emberjs/website/tree/master/source/guides...
digitalzombie 13y ago
I sorta learn Angularjs, well went through a few tutorials on Angular for a company. Turned out that company is now doing emberjs and I have to learn emberjs. I have to say EmberData is not production ready. It's modularity is more monolithic compare to Angularjs. There's a lot of moving parts that can break (in term of using emblem, brunch, handlebar, etc...). And the community is much smaller, less books, less people that talks about ember/tutorial etc... Angularjs, it seems much better but the scoping can be a hassle. I feel like angularjs is winning right now in term of hype, community, resources (books, blogs, etc..), and overall I feel like angular got it right and more ready (cause emberdata ain't ready). On the plus side, ember got a cute mascot and angular got nothing... Although this is just my initial reaction and it can change over time. Hopefully Ember will get better but if I have a side project I would chose angularjs over emberjs right now. Unless ember changed for the better. edit: direct injection is pretty awesome in angular btw.
- iamstef 13y ago
  comparing angular to ember-data seems strange, no?
  - digitalzombie 13y ago
    Well my reasoning is because angular have a so called model. It's scope. Angular doesn't need a model, it's a MV whatever. Where as ember is MVC. The framework is MVC and it's M is not complete at all. So judging from an overall framework ember is not complete in that respect where as Angular is. Like come on, 1.0 and hey our M in our MVC framework is incomplete. Um... that's shouldn't even be 1.0. 1.0 to them is the api is going to be stable but not the emberdata, the model. Really?
    - iamstef 13y ago
      o_0)
    - Kerrick 13y ago
      Ember.Object is the M in the Ember.js MVC framework. Ember Data is a library to synchronize a RESTful API with your models, without ever writing a line of networking or AJAX code.
eknkc 13y ago
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 stable release, It seems that Ember Data is in a new round of development with alpha status. It feels like some of it will never be production ready. Angular is far from perfect, I hate it's guts most of the time, but it has been stable enough to build stuff on top of. That's the number 1 advantage of Angular over Ember.
- gavinjoyce 13y ago
  > It seems that Ember Data is in a new round of development with alpha status Ember Data isn't a requirement of Ember by any means. You can happily use these instead: * jQuery.ajax * https://github.com/ebryn/ember-model https://github.com/ebryn/ember-model * http://epf.io/ http://epf.io/ * https://github.com/zendesk/ember-resource https://github.com/zendesk/ember-resource
  - shawndumas 13y ago
    and RESTLess https://github.com/endlessinc/ember-restless https://github.com/endlessinc/ember-restless
  - jonnii 13y ago
    And Emu: * https://github.com/charlieridley/emu/ https://github.com/charlieridley/emu/
- jonnytran 13y ago
  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 consider it to be a competitive advantage. 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 :)
moneypenny 13y ago
Well done, basically. Massive effort. I've been working with Ember for over a year now and things have come a long way. Out of the many brilliant things in Ember, possibly my favourite is how little code it takes to do anything. In fact, I think that Ember is happier the less code you write :)
mehulkar 13y ago
I haven't contributed much to the community or the code, but I've been around the chatrooms and keeping up with the story for around a year now. (also been actively using ember on personal and work projects). The community around Ember is amazing and it blows my mind how so many people have been working so passionately on this project. Congratulations to the team. Really well done.
programminggeek 13y ago
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.
- mjallday 13y ago
  What are the issues that you've run into? We've used Ember.js to build a reasonably complex app (github.com/balanced/balanced-dashboard) and while there have been some tricky bits it's generally been what we expected it to be. Ember.js does a great job of helping you when you start to get a lot of moving parts. I felt the same way you did before I dived in but now I'm comfortable in saying that its possible to build large apps in JavaScript.
- ulisesrmzroche 13y ago
  I think the exact opposite actually. JS Web Apps are great. What problems did you run into that made you think otherwise?
  - steveklabnik 13y ago
    I personally run into a host of issues, mostly relating to browser behavior that no longer works. For example, 'text areas' that no longer trigger the browser's built-in spell checking. Or scrolling that works differently. Or keyboard shortcuts that are overridden. Or, a simple 'submit' button that no longer works because of a browser JS bug, whereas if it were just HTML it'd work. I do like a lot of browser based apps too, but many of them have tons of annoying issues. (Note: I mean JS SPAs in general, not Ember ones. Most Ember apps I know are pretty well behaved.)
- marknutter 13y ago
  It really depends on the type of app you're building. If you're Twitter, a single-page app probably doesn't make a whole lot of sense, which I'm sure is why they backpedaled from that strategy. If you're Asana, then a single-page app makes a lot of sense. It has to do with just how many dynamic things you want happening on the page.
ppong87 13y ago
just wondering what's the difference between the different builds http://emberjs.com/builds/#/release http://emberjs.com/builds/#/release. In particular what's the difference between stable/ember-runtime.js and just stable/ember.js
- iamstef 13y ago
  ya, we should add descriptions. Mind opening an issue? https://github.com/emberjs/website/issues/new https://github.com/emberjs/website/issues/new As for the question: Ember is actually built from many smaller pieces, such as: - container - ember-metal - ember-runtime - ember-views - ember-handlebars - ember-routing - ember-application - ember - ember-extension-support - ember-testing - rsvp As it turns out, you do not always need everything, so building the subset that you need totally works. ember-runtime is made of up: ember-metal and ember-runtime https://github.com/emberjs/ember.js/blob/master/ember-dev.yml#L7 https://github.com/emberjs/ember.js/blob/master/ember-dev.ym... It provides underlying foundation, including the object model and the KVO system to the rest of ember. Leaving out views, application, routing, and many more high level ideas.
zbush 13y ago
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?
- bwship 13y ago
  What I do for my production apps is. For dev, i simply use all the individual files. For staging, I minify and concatenate and push it to an S3 bucket, and read it directly from there. For production, on CDN, because of caching, I add a version number to my js and css file name. This way I alway s guarantee that the user is using the correct version of my client code. I have grunt tasks to do all of these automatically, and it has worked really well for me.
zbush 13y ago
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?
zbush 13y ago
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?
sadadar 13y ago
congrats tom, yehuda, and the team at ember, even if we aren't using it always happy to have technology making great strides.
outside1234 13y ago
Congrats! I'm been using Ember for over a year and I love it. My protip for the newbie is to go install Yeoman, then install the generator (npm install generator-ember), and then you can scaffold out a project as easily as (yo ember), and build a minified version as easy as (grunt build), and have a live updating version of the site as easy as (grunt server).
impressive 13y ago
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-generated jellybeans and weed that will power these frameworks. They are beautiful but unnecessary cruft in such pretty packaging that you think they are doing you a favor and washing your clothes for you. But they are only washing part of your clothes. The rest are still dirty and on the floor. 2. Despite the old saying, "Everything at some point will be written in JavaScript," it is not JavaScript, but rather mobile application development that is leading the charge in the development world currently. It is the platform and the accessibility (intuitive, easily held and portable), and not the "how" (whether it is webkit running Ember or Angular). So, even though it is awesome that Ember and Angular are great, and I'm happy for you Yahuda, just like I'm happy for Misko/Igor/Vojta, I think this is a lot about only part of a solution, and it might not even be the right one. The whole package and the platform must be considered, not just the web client UI. So, I ask, now that v1.0 is out, what is being done about considering the ease of developing the entire shebang?
- jonnytran 13y ago
  Ember Data and server-side components like active_model_serializers for Rails are working towards the entire shebang. 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.
  - steveklabnik 13y ago
    This is the whole reason for formalizing the media type that ember-data expects into JSON API. That way, you can implement whichever side in whichever language and know it all works well together.
level09 13y ago
it would be really nice to build a migration/mapping sheet for people already using other front-end frameworks (Backbone/Angular/Knockout etc ..) Variety is always good, but with all JS frameworks I'm really getting confused about which framework to choose.
pearjuice 13y ago
Disclaimer: I am a backend developer sporadically doing front end to speed things up (as in: back end is done, time to help the other guys with the front end). 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?
- steveklabnik 13y ago
  JQuery is great, but it doesn't scale up well. Frameworks like Ember allow you to build bigger applications in an easy, clean way. JQuery tends toward spaghetti.
- alptrv 13y ago
  Usually most of the people realise the need for this kind of tools when they are facing a need/requirement to develop a single page web application (SPA). If you don't need to make one then it's ok to use jquery or even add some PJAX to make your web site look more snappy. But if you have to develop a SPA, then you can't go far with jQuery because it just wasn't created for this type of things, you have to think about models, templates, about application state management and all other stuff, this is where frameworks like Ember and Angular shine.
- graue 13y ago
  It depends on the scale of the project. If what you want to do can be done with 200 or 300 lines of JavaScript using jQuery, then fine. Go for it! But I've seen codebases with over 10,000 lines of JavaScript, using only jQuery, and it isn't a pleasant sight. You either end up writing your own ad-hoc framework to add structure, or, more likely, you end up with a bug-ridden, unmaintainable mess where you're writing basically the same code over and over. A framework like Ember or Angular provides structure and takes out a lot of the grunt work of making a large, single-page app.
- nbouscal 13y ago
  Ember is a framework, jQuery is a library. jQuery doesn't really give you much of anything that you don't have in regular JavaScript, it just makes things a bit more concise and smoothes over some browser inconsistencies. Ember provides you with a structure for your application, two-way binding, a template language (Handlebars), a router, and many other things. It's not better than jQuery, it's a completely different type of thing.
johncagula 13y ago
For the uninitiated, could someone please explain what we use Ember (and related frameworks like Angular.js) for? For example, I build a Rails app to handle models, views, and controllers on the backend. Then I can use HTML/CSS/JS to write a frontend to interface with the Rails app. Why do we need another MVC framework on top of Rails?
- ricardobeat 13y ago
  When writing a single-page app you only need a RESTful API on the backend, much like developing for mobile, to sync your models from the client. Ideally, the models would be shared between client and server without the need for duplicating code. There has been a few steps in that direction in node.js, but it's an ongoing problem that hopefully we'll figure out in the next couple years.
  - johncagula 13y ago
    Thanks for your response. To clarify, when you say RESTful API, do you mean the client-side MVC framework issues API calls to a server which then updates the backend (database?). I guess this model is client-centric while the typical Rails app is server-centric (MVC logic executes on the server and then serves the relevant HTML/CSS to the client). Any particular advantages to the client-side framework over the server-side framework?
    - ricardobeat 13y ago
      The main advantage would be performance, plus maintainability for complex UIs. Navigation can be nearly instant, since you're only making specific requests for data from the server, instead of shuffling html and reloading dozens of assets all the time. There are trade-offs, of course: it is a tad more complex than the old way, but that is offset by simpler implementation in the server. Network round-trips are minimized, but you use a lot more memory and CPU on the client, and need more extensive testing. It's a great fit for webapps, not so much for more content-oriented websites.
ulisesrmzroche 13y ago
Web Components. Yes! They even knocked off views off the guides.

311 points by ozkatz 13y ago

They also have a new builds page: http://emberjs.com/builds/ http://emberjs.com/builds/

Congratulations - This is really a huge step forward for both Ember, and front end development. I know that it has been possible to build rich front-end applications using JavaScript before now, but the API and tools around Ember are excellent and really make for a productive, convention over configuration development environment.

leokun 13y ago

Awesome, have been meaning to try ember. Just finished with a 6 month meteor.js binge. Which leads me to the question: what is a good real time push solution for ember? Does it have anything for that, or is that something I'd have to build in separately with socket.io or sock.js or something?

gavinjoyce 13y ago
There is nothing built-in but it would be straightforward to update your model data over web sockets. The magic of Ember bindings and observers will take care of the rest.
- sambeau 13y ago
  Saying it would be straight-forward is a little bit of an exaggeration. While, true, Ember will happily update any model pushed to it the difficult bit i.e. pushing the right data to the right model (on the right client) and only the right model to only the right client is an exercise left to the reader. The cleverness of Meteor is not in the push, it's in the logic just before the push.
  - gavinjoyce 13y ago
    That's true, Ember doesn't have any data synchronisation mechanism over websockets like Meteor does. It is easy to update your data model from incoming messages but, as sambeau points out, pushing these data updates may not be a trivial matter.
  - zaius 13y ago
    I started down this path a month or two ago and you're right - it's actually quite a big job. I've been working on a real time system for rails / ember that moves all data over a websocket and allows subscribing to updates, however it has been very hard to get working with ember-data. I've currently have it running with my own (terrible) data layer but I would really like to get it running with ember-data again before I get it up on github.

ehsanu1 13y ago

I've been interested in using Ember.js in the frontend for a Rails app, especially after watching a mock competition between it and Angular [1]. But it's beta status kept me from using it, and even now I wonder if it really is production ready, or just API-stable (which they say they will be as per http://semver.org/ http://semver.org/). I also don't know if it's really worth the up-front cost of learning and slowing down initial development of a new product, especially while at a startup trying to set an aggressive release date for the product. I'm also a bit worried about the need for everyone on the team to learn how Ember works and its conventions, when they already know how to figure out whatever mess of ad-hoc jQuery and random objects someone would write instead (as bad as that is for maintainability). And finally, I won't have the advantage of green field development, as there is an existing app which will be added to. So there will end up being a chunk of the app with Ember, and a (functionally separate) part of the app not using Ember at all.. Which does not seem ideal. Anyone want to chime in with their experiences? [1] https://vimeo.com/68215606 https://vimeo.com/68215606 - Note it's a bit unfair with the project lead for Ember, tomdale, on one of the "cage match"

sandstrom 13y ago
We've used it in production for quite a while, and it has worked well for us. We gradually moved our previous jQuery-implemented app onto Ember, so it's certainly possible to do it in stages (we still have a minor section which we haven't moved yet, because it's up for rewrite regardless). There are still improvements to be made, but we're certainly happy to be using it live.
gavinjoyce 13y ago
> I don't know if it's really worth the up-front cost of learning and slowing down initial development of a new product This is true when considering the introduction of any new technology or when to pay down technical debt. The answer for you will likely depend on the complexity of the product that you are building, how important a great UX is, how close you are to shipping something, and whether the promise of building a clean and scalable browser application outweighs the short term benefits of delivering a "mess of ad-hoc jQuery and random objects". I've worked within a medium sized team building a large Ember application and have seen first hand how beneficial it can be when dealing with application complexity and a need for precise UX attention to detail, even when using a much earlier version. I've also experienced frustration with the documentation and quickly moving goalposts as the framework evolved towards v1.0. Happily, everything has become so much easier in the last few months. The documentation and guides are now a fantastic resource after a huge push from the team and community. The framework itself requires much less boilerplate code, Ember automatically generates controllers, routes and views at runtime should you not need to customise their behaviour. The addition of support for promises across the framework has resulted in more terse and consistent application code. I've found the community to be very helpful and I'm excited to see how it will grow over the coming months. > So there will end up being a chunk of the app with Ember, and a (functionally separate) part of the app not using Ember at all. I'm helping a client do exactly this at the moment. Their current application consists of a many pages with ball of JavaScript and jQuery sitting on top of their clean REST API. They want to raise the bar for what their application can do and the medium term goal is to deliver a single page Ember application. In the short term, we're building some of the most complex new features in Ember. These features will be accessed through modal iframes for a time allowing us to build out the Ember application without having to rebuild everything.

tomdale 13y ago

I said this already on Twitter, but: It’s been 2½ years since I started working on Ember.js. While I’m proud of the code we wrote, I’m even more proud of the community we built. We have been lucky enough to attract the companies and individuals that are tackling the hardest problems in developing 100% JavaScript web applications; people for whom the only acceptable answer is solid engineering, not piles of hacks. As we mention in the blog post, Ember.js went through a reboot midway through its life when we realized the thing we were building was not the thing that needed to be built. If you tried Ember.js previously and had a bad experience, I'd really encourage you to give it a whirl again. We've smoothed over the rough surfaces, and now have the documentation and community to help you get started. If you'd just like to take a peek at what building an Ember.js app is like, I recorded a ~25 minute screencast that takes you soup to nuts: https://www.youtube.com/watch?v=1QHrlFlaXdI https://www.youtube.com/watch?v=1QHrlFlaXdI Lastly, I'd like to express my personal gratitude to everyone that pitched in at the 11th hour to get this release out the door. I couldn't be more proud to call this awesome group of developers my friends.

Kudos 13y ago
Have you got that screencast available as a download somewhere?
- tomdale 13y ago
  No, but that's a great idea. Do you have any recommendations for a host that can serve up files of this size?
  - terabytest 13y ago
    You might try Dropbox.
  - wildster 13y ago
    S3
    - cpursley 13y ago

Cieplak 13y ago

If you want to see ember in action, you can see how we use it in production: https://github.com/balanced/balanced-dashboard https://github.com/balanced/balanced-dashboard It has been a great tool in our toolbox, and we really feel the benefits of all the hard work and brilliance driving ember.

Kudos 13y ago
How come you guys aren't using push state? Does Ember not provide it in its routing?
- tomdale 13y ago
  Ember.js supports pushState out-of-the-box, but it does require that you configure your server. For more, see the documentation: http://emberjs.com/guides/routing/specifying-the-location-api/ http://emberjs.com/guides/routing/specifying-the-location-ap...
- mjallday 13y ago
  We have an open issue, https://github.com/balanced/balanced-dashboard/issues/370 https://github.com/balanced/balanced-dashboard/issues/370 , that documents what's blocking. We were using iframes for backwards compatibility while we migrated from a regular HTML dashboard to our new Ember.js one. We just removed the last iframe page (yay!) last week so I think we can finally get around to doing this!

noelwelsh 13y ago

So, isn't it time we had another Angular vs Ember discussion? I tried Ember some time ago and it just didn't click for me. It's hard to explain exactly why, but I found myself switching between too many files to get simple things done. I've done some simple Angular work recently, and found it a relatively simple system. In defence of Ember everything about the project -- docs, community -- seems to be better organised than Angular. The Angular docs are hilariously bad.

sambeau 13y ago
How about we all try them first?
- noelwelsh 13y ago
  Well, one reason to get others' opinions to avoid having to try everything oneself. Time is limited.
  - sambeau 13y ago
    Well, yes. I was more hoping those that have a strong opinion on one or the other would ensure that they try them both first.
- jonahx 13y ago
  While this attitude is in-line with general hacker values, and is good advice when dealing with simple tools, it is a poor general principle when applied to complex tools with an ecosystem of experts whose opinions you trust. In the case at hand, spending half a day each (or even more) with angular and ember is not enough time to gain a truly informed opinion of either. These are big frameworks with many features, and each harbors both gotchas and benefits that won't emerge until you've worked with them over time in real projects. For developers with limited time, asking advice from fellow trusted developers is not only acceptable, but also, in many cases, the clearly optimal strategy. Of course, the trick is to find experienced people to ask with tastes and values similar to your own.

msoad 13y ago

I'm not very familiar with software licensing. What Ember.js licence means for production use?

tomdale 13y ago
Ember.js is released under an MIT license: https://github.com/emberjs/ember.js/blob/master/LICENSE https://github.com/emberjs/ember.js/blob/master/LICENSE Use it however you'd like; contribute back if you want to.

sintaxi 13y ago

Congrats on the significant milestone. All the best moving forward.

sambeau 13y ago

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 are two shining examples of modern open-source software. We can debate the finer points and minute advantages of each framework later, preferably once we've all tried them both. Congratulations, Ember 1.0! Roll on, Angular 1.2!

Kudos 13y ago
> documented Does Angular really qualify here? Technically it's documented, but they're terrible.
- iamstef 13y ago
  lets just be happy about open-source. The magnitude and quality of work being contributed is amazing.
danso 13y ago
Since when did Backbone not count as a major framework?
- mayhew 13y ago
  Backbone is a library, not a framework.
  - Helianthus 13y ago
    Backbone is still a major player in the ecosystem, whatever you call it.
    - Demiurge 13y ago
      It's more like the ORM. And I use it quite nicely when that's what I need. However, I can't compare it to Ember.js, because it can't replace it and other features in Ember.

forlorn 13y ago

I wish there were more docs/tutorials/examples in the wild. I truly love this outstanding project and I'd like more people to join the ember.js community.

raphaelsaunier 13y ago
I don't know if you have already come across it, but http://emberwatch.com http://emberwatch.com is a great aggregator of all the resources on Ember in the wild.
mehulkar 13y ago
There's also some great work going on with cookbooks that should be released soon. https://github.com/emberjs/website/tree/master/source/guides/cookbook https://github.com/emberjs/website/tree/master/source/guides...

digitalzombie 13y ago

I sorta learn Angularjs, well went through a few tutorials on Angular for a company. Turned out that company is now doing emberjs and I have to learn emberjs. I have to say EmberData is not production ready. It's modularity is more monolithic compare to Angularjs. There's a lot of moving parts that can break (in term of using emblem, brunch, handlebar, etc...). And the community is much smaller, less books, less people that talks about ember/tutorial etc... Angularjs, it seems much better but the scoping can be a hassle. I feel like angularjs is winning right now in term of hype, community, resources (books, blogs, etc..), and overall I feel like angular got it right and more ready (cause emberdata ain't ready). On the plus side, ember got a cute mascot and angular got nothing... Although this is just my initial reaction and it can change over time. Hopefully Ember will get better but if I have a side project I would chose angularjs over emberjs right now. Unless ember changed for the better. edit: direct injection is pretty awesome in angular btw.

iamstef 13y ago
comparing angular to ember-data seems strange, no?
- digitalzombie 13y ago
  Well my reasoning is because angular have a so called model. It's scope. Angular doesn't need a model, it's a MV whatever. Where as ember is MVC. The framework is MVC and it's M is not complete at all. So judging from an overall framework ember is not complete in that respect where as Angular is. Like come on, 1.0 and hey our M in our MVC framework is incomplete. Um... that's shouldn't even be 1.0. 1.0 to them is the api is going to be stable but not the emberdata, the model. Really?
  - iamstef 13y ago
    o_0)
  - Kerrick 13y ago
    Ember.Object is the M in the Ember.js MVC framework. Ember Data is a library to synchronize a RESTful API with your models, without ever writing a line of networking or AJAX code.

eknkc 13y ago

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 stable release, It seems that Ember Data is in a new round of development with alpha status. It feels like some of it will never be production ready. Angular is far from perfect, I hate it's guts most of the time, but it has been stable enough to build stuff on top of. That's the number 1 advantage of Angular over Ember.

gavinjoyce 13y ago
> It seems that Ember Data is in a new round of development with alpha status Ember Data isn't a requirement of Ember by any means. You can happily use these instead: * jQuery.ajax * https://github.com/ebryn/ember-model https://github.com/ebryn/ember-model * http://epf.io/ http://epf.io/ * https://github.com/zendesk/ember-resource https://github.com/zendesk/ember-resource
- shawndumas 13y ago
  and RESTLess https://github.com/endlessinc/ember-restless https://github.com/endlessinc/ember-restless
- jonnii 13y ago
  And Emu: * https://github.com/charlieridley/emu/ https://github.com/charlieridley/emu/
jonnytran 13y ago
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 consider it to be a competitive advantage. 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 :)

moneypenny 13y ago

Well done, basically. Massive effort. I've been working with Ember for over a year now and things have come a long way. Out of the many brilliant things in Ember, possibly my favourite is how little code it takes to do anything. In fact, I think that Ember is happier the less code you write :)

mehulkar 13y ago

I haven't contributed much to the community or the code, but I've been around the chatrooms and keeping up with the story for around a year now. (also been actively using ember on personal and work projects). The community around Ember is amazing and it blows my mind how so many people have been working so passionately on this project. Congratulations to the team. Really well done.

programminggeek 13y ago

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.

mjallday 13y ago
What are the issues that you've run into? We've used Ember.js to build a reasonably complex app (github.com/balanced/balanced-dashboard) and while there have been some tricky bits it's generally been what we expected it to be. Ember.js does a great job of helping you when you start to get a lot of moving parts. I felt the same way you did before I dived in but now I'm comfortable in saying that its possible to build large apps in JavaScript.
ulisesrmzroche 13y ago
I think the exact opposite actually. JS Web Apps are great. What problems did you run into that made you think otherwise?
- steveklabnik 13y ago
  I personally run into a host of issues, mostly relating to browser behavior that no longer works. For example, 'text areas' that no longer trigger the browser's built-in spell checking. Or scrolling that works differently. Or keyboard shortcuts that are overridden. Or, a simple 'submit' button that no longer works because of a browser JS bug, whereas if it were just HTML it'd work. I do like a lot of browser based apps too, but many of them have tons of annoying issues. (Note: I mean JS SPAs in general, not Ember ones. Most Ember apps I know are pretty well behaved.)
marknutter 13y ago
It really depends on the type of app you're building. If you're Twitter, a single-page app probably doesn't make a whole lot of sense, which I'm sure is why they backpedaled from that strategy. If you're Asana, then a single-page app makes a lot of sense. It has to do with just how many dynamic things you want happening on the page.

ppong87 13y ago

just wondering what's the difference between the different builds http://emberjs.com/builds/#/release http://emberjs.com/builds/#/release. In particular what's the difference between stable/ember-runtime.js and just stable/ember.js

iamstef 13y ago
ya, we should add descriptions. Mind opening an issue? https://github.com/emberjs/website/issues/new https://github.com/emberjs/website/issues/new As for the question: Ember is actually built from many smaller pieces, such as: - container - ember-metal - ember-runtime - ember-views - ember-handlebars - ember-routing - ember-application - ember - ember-extension-support - ember-testing - rsvp As it turns out, you do not always need everything, so building the subset that you need totally works. ember-runtime is made of up: ember-metal and ember-runtime https://github.com/emberjs/ember.js/blob/master/ember-dev.yml#L7 https://github.com/emberjs/ember.js/blob/master/ember-dev.ym... It provides underlying foundation, including the object model and the KVO system to the rest of ember. Leaving out views, application, routing, and many more high level ideas.

zbush 13y ago

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?

bwship 13y ago
What I do for my production apps is. For dev, i simply use all the individual files. For staging, I minify and concatenate and push it to an S3 bucket, and read it directly from there. For production, on CDN, because of caching, I add a version number to my js and css file name. This way I alway s guarantee that the user is using the correct version of my client code. I have grunt tasks to do all of these automatically, and it has worked really well for me.

zbush 13y ago

sadadar 13y ago

congrats tom, yehuda, and the team at ember, even if we aren't using it always happy to have technology making great strides.

outside1234 13y ago

Congrats! I'm been using Ember for over a year and I love it. My protip for the newbie is to go install Yeoman, then install the generator (npm install generator-ember), and then you can scaffold out a project as easily as (yo ember), and build a minified version as easy as (grunt build), and have a live updating version of the site as easy as (grunt server).

impressive 13y ago

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-generated jellybeans and weed that will power these frameworks. They are beautiful but unnecessary cruft in such pretty packaging that you think they are doing you a favor and washing your clothes for you. But they are only washing part of your clothes. The rest are still dirty and on the floor. 2. Despite the old saying, "Everything at some point will be written in JavaScript," it is not JavaScript, but rather mobile application development that is leading the charge in the development world currently. It is the platform and the accessibility (intuitive, easily held and portable), and not the "how" (whether it is webkit running Ember or Angular). So, even though it is awesome that Ember and Angular are great, and I'm happy for you Yahuda, just like I'm happy for Misko/Igor/Vojta, I think this is a lot about only part of a solution, and it might not even be the right one. The whole package and the platform must be considered, not just the web client UI. So, I ask, now that v1.0 is out, what is being done about considering the ease of developing the entire shebang?

jonnytran 13y ago
Ember Data and server-side components like active_model_serializers for Rails are working towards the entire shebang. 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.
- steveklabnik 13y ago
  This is the whole reason for formalizing the media type that ember-data expects into JSON API. That way, you can implement whichever side in whichever language and know it all works well together.

level09 13y ago

it would be really nice to build a migration/mapping sheet for people already using other front-end frameworks (Backbone/Angular/Knockout etc ..) Variety is always good, but with all JS frameworks I'm really getting confused about which framework to choose.

pearjuice 13y ago

Disclaimer: I am a backend developer sporadically doing front end to speed things up (as in: back end is done, time to help the other guys with the front end). 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?

steveklabnik 13y ago
JQuery is great, but it doesn't scale up well. Frameworks like Ember allow you to build bigger applications in an easy, clean way. JQuery tends toward spaghetti.
alptrv 13y ago
Usually most of the people realise the need for this kind of tools when they are facing a need/requirement to develop a single page web application (SPA). If you don't need to make one then it's ok to use jquery or even add some PJAX to make your web site look more snappy. But if you have to develop a SPA, then you can't go far with jQuery because it just wasn't created for this type of things, you have to think about models, templates, about application state management and all other stuff, this is where frameworks like Ember and Angular shine.
graue 13y ago
It depends on the scale of the project. If what you want to do can be done with 200 or 300 lines of JavaScript using jQuery, then fine. Go for it! But I've seen codebases with over 10,000 lines of JavaScript, using only jQuery, and it isn't a pleasant sight. You either end up writing your own ad-hoc framework to add structure, or, more likely, you end up with a bug-ridden, unmaintainable mess where you're writing basically the same code over and over. A framework like Ember or Angular provides structure and takes out a lot of the grunt work of making a large, single-page app.
nbouscal 13y ago
Ember is a framework, jQuery is a library. jQuery doesn't really give you much of anything that you don't have in regular JavaScript, it just makes things a bit more concise and smoothes over some browser inconsistencies. Ember provides you with a structure for your application, two-way binding, a template language (Handlebars), a router, and many other things. It's not better than jQuery, it's a completely different type of thing.

johncagula 13y ago

For the uninitiated, could someone please explain what we use Ember (and related frameworks like Angular.js) for? For example, I build a Rails app to handle models, views, and controllers on the backend. Then I can use HTML/CSS/JS to write a frontend to interface with the Rails app. Why do we need another MVC framework on top of Rails?

ricardobeat 13y ago
When writing a single-page app you only need a RESTful API on the backend, much like developing for mobile, to sync your models from the client. Ideally, the models would be shared between client and server without the need for duplicating code. There has been a few steps in that direction in node.js, but it's an ongoing problem that hopefully we'll figure out in the next couple years.
- johncagula 13y ago
  Thanks for your response. To clarify, when you say RESTful API, do you mean the client-side MVC framework issues API calls to a server which then updates the backend (database?). I guess this model is client-centric while the typical Rails app is server-centric (MVC logic executes on the server and then serves the relevant HTML/CSS to the client). Any particular advantages to the client-side framework over the server-side framework?
  - ricardobeat 13y ago
    The main advantage would be performance, plus maintainability for complex UIs. Navigation can be nearly instant, since you're only making specific requests for data from the server, instead of shuffling html and reloading dozens of assets all the time. There are trade-offs, of course: it is a tad more complex than the old way, but that is offset by simpler implementation in the server. Network round-trips are minimized, but you use a lot more memory and CPU on the client, and need more extensive testing. It's a great fit for webapps, not so much for more content-oriented websites.

ulisesrmzroche 13y ago

Web Components. Yes! They even knocked off views off the guides.