Hacker News new | past | comments | ask | show | jobs | submit login
Ember.js 1.0 Released (emberjs.com)
311 points by ozkatz on Sept 1, 2013 | hide | past | web | favorite | 100 comments

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:


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.

If you're deciding between Angular and Ember, this video is a entertaining comparison with good examples - http://vimeo.com/68215606

More entertaining than informative I'm afraid. Project Lead v.s. Guy Who Uses. I don't mean that as a criticism of Rob, I just don't think it's fair or expected for him to have the depth of knowledge in AngularJS that Tom has with Ember. I'd have done worse.

I know it's a pain to have to evaluate all of these frikin' frameworks all the time just to get moving, but I'd really recommend building a non-trivial app in both ember and angular.

There are plans to have a "cookbook" section on the EmberJS site that will be one of the go to places to answer the question of "How do I do X in Ember?". It's currently on the master branch for the site, so expect that soon. In the mean time here are some other video resources http://www.embercasts.com/ and http://ember101.com/. They may be slightly out of date but they are still relevant. Make sure to look in the console for warnings about deprecations.

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.

Thanks Tom (and team), Ember is fantastic.

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.

Fantastic video Tom - really enjoyed it.

Thanks for posting this, there's a lot of value in this screencast.

Have you got that screencast available as a download somewhere?

No, but that's a great idea. Do you have any recommendations for a host that can serve up files of this size?

At the risk of offending some people.. Mega.co.nz gives 50 GB free storage.


Nginx + S3 & CDN for blazing fast client side apps.

You might try Dropbox.

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!

We've got more than two. Facebook's React, and Ractive.js, and the old stalwart Knockout.js to name a few.



> documented

Does Angular really qualify here? Technically it's documented, but they're terrible.

lets just be happy about open-source. The magnitude and quality of work being contributed is amazing.

Since when did Backbone not count as a major framework?

Backbone is a library, not a framework.

Backbone is still a major player in the ecosystem, whatever you call it.

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.

I didn't say it didn't. In fact I din't mention Backbone at all.

I said, "Let's not use this opportunity to start another Ember vs Angular argument."

Ember and Angular are cars, Backbone are sneakers.

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

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.

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.

I think the exact opposite actually. JS Web Apps are great. What problems did you run into that made you think otherwise?

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

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 working in Ember full time now for a few months, and I really advocate using just two files, at least to start: one for Javascript and one for HTML.

I know, it's a terrible, horrible practice, but hear me out.

Learning Ember, especially at the beginning, required me to sort of rewire my brain about what goes where. It's "MVC", but the M, V, and C mean totally different things than they mean in Rails. Really it's more like MVCRT (model view controller route template).

I found all the different files extremely confusing at first, especially since each tutorial told you to lay things out slightly differently.

If you put it all in one file though, you can really easily move stuff around. You'll find yourself frequently pulling stuff out of a controller and sticking it in a view, or a route. Having to constantly switch files, remember where things are, create new files, and remove stuff from version control really puts a damper on things.

My advice to anyone starting with Ember: download the starter kit from emberjs.com and try to stick inside that as long as you can. You can just drop it into your Rails /public folder and get up and running.

Once you have a solid understanding of the architecture, and your app is getting bigger, it's literally an hour's work to pull everything out into separate files and drop it into something like the Rails asset system.

Although lots of work still needs to be done.

http://github.com/stefanpenner/ember-app-kit aims to prevent and mitigate the tooling pain, by having the community bear the burden.

I wrote the first ~25% of my first few Ember apps completely in jsbin. The ease of starting and sharing what I'd done with others was great.

Ember doc as of last week was base on RC3 or something while I was using RC7. Wtf. I followed the tutorial with RC3 and some emberdata version that was included in the tutorial. Switch to RC7 everything break. The error response was gibberish, had to stack trace it, to find out I need to switch emberdata to the newest version.

I don't get why people keep on saying AngularJS doc is bad.

Maybe I'm weird but I've found Ember JS to be horrible and AngularJS to be very good.

How about we all try them first?

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.

Unless those trusted developers are also experts in both, you're back to square one.

Well, one reason to get others' opinions to avoid having to try everything oneself. Time is limited.

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.

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.

> 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

* http://epf.io/

* https://github.com/zendesk/ember-resource

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 :)

Haha yes I'm aware that it's a seperate project but it also seems like a tightly bound seperate project. I'd not be surprised to see some changes in Ember for the sake of ED's convenience for example. Ember Data is destined to be the dominant solution when it goes stable. That makes me want to use Ember Data, you know, it feels like "the whole stack". But I can't now :)

Angular has nothing like ED. There is $resource, which is basically a wrapper around $http to provide some sugar. Not really extensible. But it works. The thing with angular is that the change tracking is transparent, so any simple javascript object / array is fine as a model. That makes it bearable to work with an inferior data library.

I do that too. Extending Ember.Object also makes a perfectly fine model. You can mix in things like Ember.Evented to use it as an event target. You can work with Ember where it expects promises simply by implementing a `.then()` method.

This is why I'm saying I think a lot of people fall for the same trap/gotcha as you. Ember Data is totally not necessary to be productive with Ember.

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.

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?

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.

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?

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.

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.

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.

If you want to see ember in action, you can see how we use it in production: 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.

How come you guys aren't using push state? Does Ember not provide it in its routing?

We have an open issue, 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!

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

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.

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.

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.

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.

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.

comparing angular to ember-data seems strange, no?

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?

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.

Nobody is forcing you to use Ember Data. There's quite a few alternatives out there and you can even use $.ajax.

This is a very unfair comparison between a complete stable release of Angular and an alpha of Ember Data that even tells you it's extremely unstable and not production ready.


One of the problem is that the tutorial on the emberjs website makes use of ember-data and doesn't show you anything else. You have to dig a bit further to realize what exactly the distinction is and what you can use instead of ember-data. It doesn't really make it explicit (maybe on purpose) that ember and ember-data are distinct projects.

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.

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

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

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.

I don't know if you have already come across it, but http://emberwatch.com is a great aggregator of all the resources on Ember in the wild.

There's also some great work going on with cookbooks that should be released soon. https://github.com/emberjs/website/tree/master/source/guides...

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

ya, we should add descriptions.

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:

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

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

Ember.js is released under an MIT license: https://github.com/emberjs/ember.js/blob/master/LICENSE

Use it however you'd like; contribute back if you want to.

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.

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

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

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact