tomdale

If you're gonna step to me, better make sure your framework game is tight.

HTMLbars will land well before 2.0, most likely in the next release. We've been doing the integration piecemeal to ensure that we don't break production apps; we want everyone to get to experience the new awesome.

Hey Colin,

Not negative at all!

Ember CLI is a relatively small layer on top of a bunch of other open source modules. The core of the build system uses Broccoli[1], which is like a more powerful Gulp.

Dependencies are managed with bower and npm, and we use off-the-shelf npm modules to do the post-processing.

Basically, you should think of it as a curation of what we think are the best-of-breed tools for Ember developers, with a layer of developer ergonomics applied on top. At the same time, we don't do anything to hide the implementation from you. (Each new Ember app generated by Ember CLI includes the Brocfile.js right in the root directory.)

[1]: https://github.com/broccolijs/broccoli

We do development of new features behind feature flags, and have automated tools to help enable, disable and strip them. We're planning on moving to a model where we do an approximately annual "garbage collection" pass on the framework (corresponding with a major version bump) and simply nuke all of the code that has been deprecated since the last major version release.

Thanks! We know how important stability is, especially for companies that are not technical by nature. We hope this announcement demonstrates our commitment to stability without stagnation, and allows people to make the case to their boss that we'll be around for a long time.

Needless to say, we’re incredibly excited about this release. If you’re in a hurry, you can just skim; the bolded sentences and code samples are the important takeaways.

The reason this is so long is that we’re doing the 2.0 release through our community RFC process[1]. Change can be scary when you’ve made serious investment in an open source tool, so we want to provide as much detail as we can while leaving open the opportunity to incorporate feedback.

I’d like to thank the members of the Ember core team, who paid out of pocket to spend this past weekend with me in Chicago for the face-to-face meeting where we banged out all of these details. Maintaining an indie open source project can be painful at times, but I think history demonstrates there’s no better way to foster a project that is as aligned with the goals of its users as possible.[2]

[1]: https://github.com/emberjs/rfcs

[2]: http://blog.endpoint.com/2010/01/state-of-postgres-project.h...

I read the New York Times and subscribe to the Sunday paper (grudgingly; the online subscription is perversely more expensive than allowing them to leave a piece of paper on my doorstep every Sunday!)

The Times puts up too many obstacles to becoming a subscriber in the digital age, as others have mentioned.

Also, either I'm oblivious or they're doing a terrible job marketing their spinoffs. I read the Times daily, on both my phone and at a desktop, and am definitely in their target demo for NYT Cooking, but I haven't even heard of it. I already subscribe to Cook's Illustrated and visit sites like Serious Eats regularly; how is it I didn't know about their new venture?

(http://cooking.nytimes.com/ looks amazing, by the way. I'm disappointed I had to hear about it in the context of these job cuts.)

Thanks for asking. If you're interested in the nitty-gritty, Yehuda and I gave a talk on the architecture behind Skylight at RailsConf: http://www.confreaks.com/videos/3394-railsconf-how-to-build-...

The short version is that the agent runs on your servers and collects information from your Rails app using the ActiveSupport::Notifications instrumentation built in to the framework. We serialize that into a protobuf that's transmitted via IPC to a background daemon (written in Rust).

That daemon batches multiple reports into a single payload that is sent to the Skylight servers, where we use Storm and Cassandra to process the requests, and periodically do aggregate roll-ups.

Unlike New Relic, Skylight gives you access to the entire distribution of response times, not just the average response time. (According to DHH, averages are "useless.")[1] This ends up being a lot of data, and a lot of CPU-intensive processing, which is why we sell it as a hosted service.

[1]: https://signalvnoise.com/posts/1836-the-problem-with-average...

We've been using Rust in production for Skylight (https://www.skylight.io) for many months now, and we've been very happy with it.

Being one of the first to deploy a new programming language into production is scary, and keeping up with the rapid changes was painful at times, but I'm extremely impressed with the Rust team's dedication to simplifying the language. It's much easier to pick up today than it was 6 months ago.

The biggest win for us is how low-resource the compiled binaries are.

Skylight relies on running an agent that collects performance information from our customers' Rails apps (à la New Relic, if you're more familiar with that). Previously, we wrote the agent in Ruby, because it was interacting with Ruby code and we were familiar with the language.

However, Ruby's memory and CPU performance are not great, especially in long-running processes like ours.

What's awesome about Rust is that it combines low-level performance with high-level memory safety. We end up being able to do many more stack allocations, with less memory fragmentation and more predictable performance, while never having to worry about segfaults.

Put succinctly, we get the memory safety of a GCed language with the performance of a low-level language like C. Given that we need to run inside other people's processes, the combination of these guarantees is extremely powerful.

Because Rust is so low-level, and makes guarantees about how memory is laid out (unlike e.g. Go), we can build Rust code that interacts with Ruby using the Ruby C API.

I'm excited to see Rust continue to improve. Its combination of high-level expressiveness with low-level control is unique, and for many use cases where you'd previously use C or C++, I think Rust is a compelling alternative.

Those are big companies but not necessarily big apps.

Ember has now got one of the best (IMO) release cycles in the business. We borrow heavily from Chrome, and have a very polished release infrastructure, with release, beta and canary channels you can subscribe to. Additionally, we have a strict commitment to SemVer and most Ember apps are on the latest release.

As for the complaint about tying models to routes: Ember does want you to have a model per route, but the model can be any data structure you want: an array, a hash with multiple models, or a single model.

I'm not sure exactly what issue you hit, but most apps of any complexity have multiple models on the page, and of course that's something we support out of the box. (You can see this if you open any production Ember app in the Ember Inspector browser extension, such as http://vine.co or http://twitch.tv.)

One of my favorite things about Ember is how we've incubated a community that tries not to get too "high on its own supply."

We've borrowed ideas liberally from Backbone and Angular when we saw how those ideas benefitted developers working on large apps. Now we have the opportunity to improve our view layer based on the pioneering work of React.js, while maintaining the edge that being used in hundreds of large-scale, production apps gives us.

Ultimately, I believe Ember's biggest strength—a sort of meta-strength—is the willingness of the community to abandon old ideas when a new, better idea comes along. At the same time, there's a tendency to be skeptical and really understand the idea, to make sure there's some "there" there, and not just chasing the latest hype.

One question I always ask when looking at a package manager is, "Will this help me have reproducible builds?" (http://martinfowler.com/bliki/ReproducibleBuild.html)

I've worked on enough large projects that relied on prayer and optimism instead determinism when resolving dependencies, and eventually you end up losing hours or days trying to get the app running on a new server or a new developer's box.

Not requiring a manifest is a bug, not a feature. If people can specify dependencies, and information about the version used is lost, then you can be sure that it will happen in practice. Code designed for "proofs of concept" has a funny way of making it into production.

As we know from studies of things like organ donation rates, even the smartest humans get tired or distracted and make bad decisions. The only guard we have against it is choosing sane defaults. (See Yehuda Katz' RailsConf keynote for some interesting insight into how this interacts with convention over configuration: http://www.confreaks.com/videos/3337-railsconf-keynote-10-ye...).

While the simplicity of DuoJS allows it to win the Pepsi Challenge against other options, where the first sip tastes very sweet, I would never again willingly choose a dependency manager that makes reproducibility anything other than mandatory.

Nope, it calls it regardless of state change—that's the point, you eliminate the challenge of determining when state has changed.

To quote TFA:

> A set method to change state could trigger a rerender (React has setState), but there's an even easier way to react to changes: continuously call renderComponent with requestAnimationFrame to repaint the UI, and only change the DOM when the component returns different content.

Edit:

I was mistaken about how Om works. I was under the impression that Om scheduled a rAF every 16ms to check for state change. In fact, it only schedules a rAF once the state changes.

However, this relies on being able to listen for state change from the underlying model data. I was under the impression that one of the benefits of Om/React was that you could use its data bindings with any JavaScript library, even if it hadn't been instrumented for property observation. Instead, it seems that with Om, you are limited to consuming data structures that implement its state change notification interface.

I guess this discussion hinges carefully on our relative definitions of "spam." ;) What I mean to say is that, changes or not, the browser will be invoking your diffing algorithm every 16ms.

This is a really thoroughly researched post and jlongster has my gratitude for writing it up.

I have two concerns with this approach. Take everything I say with a grain of salt as one of the authors of Ember.js.

First, as described here and as actually implemented by Om, this eliminates complexity by spamming the component with state change notifications via requestAnimationFrame (rAF). That may be a fair tradeoff in the end, but I would be nervous about building a large-scale app that relied on diffing performance for every data-bound element fitting in rAF's 16ms window.

(I'll also mention that this puts a pretty firm cap on how you can use data binding in your app, and it tends to mean that people just use binding from the JavaScript -> DOM layer. One of the nicest things about Ember, IMO, is that you can model your entire application, from the model layer all the way up to the templates, with an FRP-like data flow.)

My second concern is that components libraries really don't do anything to help you manage which components are on screen, and in a way that doesn't break the URL. So many JavaScript apps feel broken because you can't share them, you can't hit the back button, you can't hit refresh and not lose state, etc. People think MVC is an application architecture, but in fact MVC is a component architecture— your app is composed of many MVCs, all interacting with each other. Without an abstraction to help you manage that (whether it's something like Ember or something you've rolled yourself), it's easy for the complexity of managing which components are on screen and what models they're plugged into to spin quickly out of control. I have yet to see the source code for any app that scales this approach out beyond simple demos, which I hope changes because I would love to see how the rubber hits the pavement.

It's always interesting to see different approaches to this problem. I don't think it's as revolutionary as many people want to make it out to be, but I've never been opposed to borrowing good ideas liberally, either. Thanks again, James!

Can you expand more on what you mean by two Ember components will "break each other"? This isn't something I've experienced when putting components together.

Can you also expand on what React design decisions has made vs. Ember that allow components to work well together? We've spent a lot of time thinking about creating a unified interface for Ember components, so I'd like to better understand where it's broken down for you.

In this case, the author didn't actually comment out the code; he left it in place, assuming it would not affect the app when in fact it did.

You get the security model of the browser; you can run code at native speed without worrying about it accessing your private data.

I will challenge your assertion that it wasn't our number one priority. :)

See http://emberjs.com/blog/2013/05/03/ember-data-progress-updat... for the blog post that did what you requested. We've probably fixed most of the issues you hit. You should give us another try!

Sorry you guys had trouble with Ember Data. Our first conception of Ember Data was that it would act as an ORM on top of JSON, and the architecture would allow developers to build adapters for many different kinds of backends.

Unfortunately, there is no JSON analog to SQL. Every existing backend forms their JSON differently, especially when you start modeling relationships. It would be like trying to build ActiveRecord if every team rolled their own query language for each new project.

We're trying to make this better in the long-term with projects like http://jsonapi.org, and https://github.com/rails-api/active_model_serializers for Rails. We'll get there someday.

In the meantime, we totally rebooted the Ember Data project to make it simple for people to customize how their apps consume JSON APIs. Most people we've talked to have been very happy about the fact that the defaults are simple to override now, and how much simpler the internals have become. We have a small amount of work left to do before we declare a 1.0 final; in the meantime, we've cut a 1.0 beta build that you can get from http://emberjs.com/builds.

Of course, you are always welcome to stick with older versions. But given that Angular will not be following SemVer until 2.0, it seems likely that compatibility issues between the point releases will quickly isolate you from the greater Angular community.

If it's not too tacky, I'd like to give a plug for the talk I gave at CascadiaJS called "Stop Breaking the Web":

http://m.youtube.com/watch?feature=plpp&p=PLLiioAbFTbKP9CxF9...

If you're developing web apps using JavaScript, especially Angular or Backbone, I'd ask you to take 25 minutes to watch it and understand how important URLs are to the web, and how many JS developers currently treat them as an afterthought.

I work on Ember.js and lots of my thinking stems from that. Even if you don't use Ember, though, you can take these ideas back to your particular JS ecosystem. It's obvious to me that JavaScript is the future of the web, so we need to make sure we're doing our part to be good web citizens.

I'm really excited to make this public. As Anant said in the blog post, we spent some time at the Firebase offices in SF hacking on this together, and I was surprised (in the good way) just how quickly it came together. The real-time updates that Firebase gives you dovetail extraordinarily well with Ember's battle-tested bindings system.

I'm excited about a future where JavaScript developers don't have to worry about building and deploying a backend. While we're obviously not there yet for everyone, I think Firebase really gives us a taste of that future. As more and more web apps shift the majority of their logic, behavior and UI to the client, I think you may find that using a tool like Ember helps you build apps that don't fall apart under their own weight—especially if you're working on a team.

You are building up a strawman against JSON without acknowledging that every problem you outline applies just as much, if not more, to HTML.

Is the HTML of any popular website publicly documented? Is there any guarantee that an XPath to a particular value won't change? Is there any guarantee the data I need is marked up with semantically accurate class names? No.

HTML is intended for public consumption—by a human, at a particular time. It is not a data interchange format.

Contrast that with things like Twitter or GitHub, which provide a versioned JSON API that is guaranteed not to change. Your web site becomes just another consumer of that API.

JSON contains all of the data you need, but in a way designed to be consumed by computers, and you don't have to do all of that awful HTML scraping.

And as for Bustle not having a public JSON API, well, here you go:

curl -H "Accept: application/json" http://www.bustle.com/api/v1/sections/home.json

A versioned JSON API that is guaranteed not to change. Can any public site on the internet guarantee that about its HTML?

Every Ember.js app, by definition, connects to an API that does all of the things you are asking for.

Seriously, open up any Ember.js app and look at the network traffic. You'll see a series of requests, usually using very RESTful URLs, that requests the document.

The only difference is that, instead of HTML, where you are conflating the markup and the content, you get a nice, easily-consumable version of the document in JSON form.

There is literally no change to the web here, other than the UIs are faster and better, and it's easier for me to consume JSON documents than trying to scrape HTML.

Accessibility is a red herring. JavaScript apps work just fine with screen readers, especially if you support WAI-ARIA.

http://words.steveklabnik.com/emberjs-and-accessibility

First, the accessibility argument is a red herring that I'm getting frustrated people continue to try to throw around. Screen readers support JS, okay? Let's put this argument to bed.

http://words.steveklabnik.com/emberjs-and-accessibility

Okay, thank you for letting me get that off my chest.

Second, one nice thing about "embracing 100% JavaScript" that I talk about in the post is that it requires you to implement a really solid JSON API, because your web site is now a true client that consumes an API. This makes it really easy to integrate with third-party services that consume your content. I agree that putting content behind JavaScript sucks; I'm just advocating that the content be JSON (or some other normalized format), not HTML.

Bustle actually uses PhantomJS to create static versions of the site, for serving to search spiders.

The advantage of using Ember.js for Bustle is that it's really, really, ridiculously fast. Seriously, try it. Go to bustle.com and click around.

They could make it work without JavaScript, but they're a new company with a long list of technical challenges to solve. They ran the numbers and the percentage of users with JS disabled is so microscopic it just doesn't make sense to spend time on it.

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