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:
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.
Thank you for this video! It nearly convinced me to build my first EmberJS app (I'm coming from a BackboneJS background and I haven't decided yet between Angular and Ember).
Will you continue this kind of videos? Building a series by continuing the current "story" could be really really nice.
Around what time did this reboot occur? I remember being impressed with what you were working on when it was still called SproutCore 2, but it was so hard to follow, I ended up taking Handlebars RC3 and writing my own JS layer.
I've compiled a list of learning sources (tutorials, videos and Ember focused blogs) that I've found very helpful in my path to Ember: http://bit.ly/1aQXnrz
Good work Tom, Yehuda, and team. I had very difficult time recommending Ember during the transition phase (mostly because the router was impossibly difficult to understand). I wanted to like it so bad, and now I finally think I can. I'm going to reboot the project I was working on and give Ember 1.0 a shot.
Thanks for sharing this video. It's been awhile since I checked out Ember, but this video would've been a great resource early on. I'm happy to see that it'll provide a high level glance of Ember to people deciding on a JS framework to use.
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.
> Let's not use this opportunity to start another Ember vs Angular argument.
So are you mentioning Angular.js then? If you are going to celebrate Angular 1.2 wait for the Angular 1.2 announcement and post there. Sounds like "I don't want to troll but I will anyway while telling everyone I don't want to".
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/). 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 - Note it's a bit unfair with the project lead for Ember, tomdale, on one of the "cage match"
> 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.
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.
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).
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.
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.
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.
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.
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.
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 :)
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?
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.
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?
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.
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?
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.
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?
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.
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.
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.
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.
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.
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?
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.
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.
just wondering what's the difference between the different builds http://emberjs.com/builds/#/release. In particular what's the difference between stable/ember-runtime.js and just stable/ember.js
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.
[+] [-] tomdale|12 years ago|reply
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
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.
[+] [-] yannski|12 years ago|reply
[+] [-] bsimpson|12 years ago|reply
[+] [-] cpursley|12 years ago|reply
I've compiled a list of learning sources (tutorials, videos and Ember focused blogs) that I've found very helpful in my path to Ember: http://bit.ly/1aQXnrz
[+] [-] hellopat|12 years ago|reply
[+] [-] arms|12 years ago|reply
[+] [-] johnny_reilly|12 years ago|reply
[+] [-] nakkiel|12 years ago|reply
[+] [-] Kudos|12 years ago|reply
[+] [-] sambeau|12 years ago|reply
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!
[+] [-] SkyMarshal|12 years ago|reply
http://facebook.github.io/react/
http://www.ractivejs.org/
[+] [-] Kudos|12 years ago|reply
Does Angular really qualify here? Technically it's documented, but they're terrible.
[+] [-] rdtsc|12 years ago|reply
So are you mentioning Angular.js then? If you are going to celebrate Angular 1.2 wait for the Angular 1.2 announcement and post there. Sounds like "I don't want to troll but I will anyway while telling everyone I don't want to".
[+] [-] danso|12 years ago|reply
[+] [-] ehsanu1|12 years ago|reply
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 - Note it's a bit unfair with the project lead for Ember, tomdale, on one of the "cage match"
[+] [-] gavinjoyce|12 years ago|reply
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.
[+] [-] sandstrom|12 years ago|reply
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.
[+] [-] outside1234|12 years ago|reply
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).
[+] [-] programminggeek|12 years ago|reply
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|12 years ago|reply
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.
[+] [-] marknutter|12 years ago|reply
[+] [-] ulisesrmzroche|12 years ago|reply
[+] [-] noelwelsh|12 years ago|reply
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.
[+] [-] eknkc|12 years ago|reply
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|12 years ago|reply
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
* http://epf.io/
* https://github.com/zendesk/ember-resource
[+] [-] jonnytran|12 years ago|reply
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 :)
[+] [-] johncagula|12 years ago|reply
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|12 years ago|reply
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.
[+] [-] impressive|12 years ago|reply
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?
[+] [-] matthewlehner|12 years ago|reply
[+] [-] Cieplak|12 years ago|reply
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|12 years ago|reply
[+] [-] leokun|12 years ago|reply
[+] [-] gavinjoyce|12 years ago|reply
[+] [-] pearjuice|12 years ago|reply
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?
[+] [-] graue|12 years ago|reply
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.
[+] [-] alptrv|12 years ago|reply
[+] [-] nbouscal|12 years ago|reply
[+] [-] steveklabnik|12 years ago|reply
[+] [-] digitalzombie|12 years ago|reply
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.
[+] [-] zbush|12 years ago|reply
Regarding hosting an Ember app, can you use something like s3 with cloudfront or will it not refresh fast enough to be usable?
[+] [-] bwship|12 years ago|reply
[+] [-] mehulkar|12 years ago|reply
[+] [-] makepanic|12 years ago|reply
[+] [-] sintaxi|12 years ago|reply
[+] [-] forlorn|12 years ago|reply
I truly love this outstanding project and I'd like more people to join the ember.js community.
[+] [-] raphaelsaunier|12 years ago|reply
[+] [-] mehulkar|12 years ago|reply
[+] [-] ppong87|12 years ago|reply
[+] [-] iamstef|12 years ago|reply
Mind opening an issue? https://github.com/emberjs/website/issues/new
As for the question:
Ember is actually built from many smaller pieces, such as:
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.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.