tomdale

Now that the pace of evolution on TC39 and in the browsers is so much more vibrant, we can start pushing a lot of those features into the language itself.

That has two important side effects. One, it means huge swaths of code can be deleted from Ember. Two, and perhaps most importantly, it increases the chances people will already be familiar with those features once they try to pick up Ember, reducing the learning curve that much more.

  We might not be able to provide novice users with One True Framework, but we need to do better than boilerplate, both for their sake and for our own. If we can’t find a higher level abstraction to work with our own frameworks, how are we sure that we understand it ourselves?

In fact, it's exactly this received wisdom—that the web is open, and therefore each app should handpick its own bespoke stack—is, in my opinion, the very thing setting us back. We spend so much time integrating pieces that were never designed to work together that we both waste time and hit a limit in the capabilities of the browser we can take advantage of.

The browser now supports offline storage, Service Worker, WebGL and more. But taking advantage of those things requires code. But not too much, because you need to preserve the instantaneous the web is known for. To balance this constraint, we're going to need even more tools that help us parcel up our application into little pieces that can be delivered on demand, then cached as aggressively as possible on the user's device. All of this requires code, and more importantly, it requires code that can reason about the entire system. At some point, we're going to get to a place where bespoke frameworks simply don't let you build the caliber of app that you can with Ember or Angular 2—there's too much to do, and too much of it relies on a shared understanding of the entire system. When that happens, I hope the web community can finally accept that shared solutions are the only way to compete with native apps.

It is fundamentally different, as I outlined above. That's not downplaying the work of React—they've done significant work in advancing the state of the art of DOM rendering that has hugely inspired the work of both Glimmer and Glimmer 2, as we have said frequently and publicly.

I have tremendous respect for the Angular and React teams and consider many contributors to both to be personal friends. I'm not downplaying their work—it just really, really, really is not the same thing.

That said, it should work just fine once the Ember app finishes loading and running in the browser. I would love it if you could file an issue on the Ember Inspector GitHub page with the error you're getting.

  With Fastboot, somehow an additional, non-interfering layer of computation on the server does the same loop (without having to download anything and without significantly slowing down overall client app JS initialization)

First the browser downloads the HTML, then the JavaScript, then the JavaScript runs and fetches the data via XHR. Only then does the user see the content they were after in the first place.

This actually works surprisingly well for "workspace" apps where the user is using it throughout the day (Gmail, Google Docs, etc.) On modern devices with good broadband, the difference is negligible.

But the thing this sucks for is content sites, where you aren't using an "app" but you're just clicking a link in Twitter or something. If it doesn't load within a second or so, you aren't that invested that you don't just close the tab. That has been the biggest source of pushback on frameworks like Angular and Ember for sites like this.

FastBoot bends the curve by replacing that static HTML file. Rather than serving an empty document that just points to JavaScript assets, we keep your Ember app running in Node.js on the server. When an HTTP request comes in, we direct it to Ember's router, where it figures out what models to load and components to render. When it finishes, it sends the document back to the browser.

You can think about this is as effectively outsourcing the JavaScript runtime to the server for the first load, but then the browser can take over again on subsequent navigations so it's very fast.

I think FastBoot is a great option for search crawlers, Facebook and Twitter embedding (it supports Open Graph and Twitter Cards), and supporting JavaScript-less clients. Most importantly, it's a way to get content quickly to users with a cold cache.

That said, we are planning to aggressively take advantage of App Cache and Service Worker, so ideally any second-time visitor to your site only has to fetch the raw data to see what they're after.

  I'm guessing that somehow the client's processing is disabled on that first "pageview" to avoid double calculation. Is that correct? (if it is, it's very cool :)

Markdown is the lingua franca of open source, but until Canvas, none of the online collaboration tools we used understood it. Not only does Canvas support Markdown, it supports programmer-flavored Markdown, with great support for things like checkboxes and code fencing. It's become an indispensable part of how we build open source software online.

Just a few of the ways we use Canvas:

1. Writing feature proposals/documentation side by side with someone

2. Taking collaborative meeting minutes during the weekly core team Google Hangout

3. 12+ of us sitting around a couch, writing an agenda for our quarterly in-person meetings

Canvas is all about small details that continue to delight as you learn it. I think my favorite "hidden" feature is that you can add `.md` to the end of any document URL and it serves up a static Markdown file, making data export incredibly easy.

(P.S. One thing I think that's pretty meta-cool about the FastBoot site is that it is, itself, a FastBoot site, running on Heroku.)

There is a huge gulf between "synchronously render a component in Node" and "asynchronously boot an app, marshall async data, render an async UI, and do it concurrently."

I touch on this a little bit in this talk[1], but the bulk of the work we've done over the last year is conventionalizing app boot and figuring out how to run multiple instances concurrently, cheaply.

Angular 2 is much more similar to what we're doing with FastBoot, and I'm excited to see where they go with that and crosspollinate ideas. (The work they're doing with Web Worker rendering is also very exciting.)

1: https://vimeo.com/157688134

The best part of Mobiledoc is its portability; I've seen it used in both Ember.js and Riot.js, two libraries on opposite ends of the spectrum.

It's also been designed for rich, interactive content in addition to rich text. You can add interactive cards (think slideshows, before/after image sliders, etc.) and easily provide a different implementation on each platform. This lets your content authors write once and have a great experience on both native and web, and adding a new card is super easy.

1: https://github.com/bustlelabs/mobiledoc-kit

Given how fast the frontend ecosystem is moving, we've tried to strike the right balance between delivering new features and taking care to ensure that we don't leave the existing ecosystem of apps behind.

I think you'll agree that if we did nothing, our community would slowly die off as people moved to competing libraries and frameworks that made them more productive. So total stability would feel good in the short term, but long term, having to do a wholesale rewrite of your app because the framework stagnated would be much more painful, right? (You can approximate this effect by locking yourself into an older version of Ember, which sucks! People rightfully want the new features.)

The goal of Ember's additive-only strategy is to deprecate features, rather than remove them. This is more work for the maintainers, but we think it's worth it because users can "refactor towards the future" at their own pace, amortized over the year and a half between major releases. Development teams have a natural ebb and flow, and that amortization of deprecations over the year means you can use lulls/downtimes to refactor the deprecations out when it's most convenient to you.

We made a mistake and rushed in a bunch of deprecations in 1.13 because it was our last chance to remove features for the next year or so. In retrospect, we got overzealous, and for that I am sincerely sorry. Users like you rightfully felt overwhelmed, and that is something the entire system is designed to avoid.

If there's a bright side, it's that your app should continue to work as you upgrade, and when you're ready to make the jump, you can upgrade to Ember 1.13 and refactor away all of the deprecations. Once that's done (whenever you decide to do it), you will be able to upgrade to the latest version of Ember 2.x, because Ember's SemVer guarantees means that a deprecation-free 1.13 app is compatible with any 2.x version (2.7, for example).

Sorry again that it's been a slog for you. Once you're through it though, we hope you enjoy all the new features, and we certainly hope the simplifications we've made to the framework over the last year make it easier for new developers to join your team and get productive.

On a personal note, the team behind Confetti also organizes the NordicJS conference in Stockholm. In addition to running one of the best JS conferences in the world, IMO, they are also some of the nicest people in the community. As a NordicJS attendee, I've been "beta testing" Confetti for some time. It's a great product and I wish the team all the best.

Recently, the results of the Ember Community Survey were released and the aspect of it I'm most proud of is the number of developers who are using the latest release version[1]. The majority of respondents were on either 1.9 or 1.10, and 1.10 wasn't released until halfway through the survey.

1: http://www.201-created.com/ember-community-survey-2015#relea...

You would of course still use a CDN for any static assets. Only the HTML that changes would be served by FastBoot, and of course you probably want to cache certain responses from that as well.

I would ask readers of this discussion to visit any of the web applications they use on a daily basis, open the developer tools, and look at the size of the JavaScript payload. Whatever libraries or frameworks they're using, the payload size is almost always several hundred kilobytes.

I'd argue that using small libraries is a noble goal, but in practice, you just need several hundred KB of JavaScript to build modern apps. If we're honest with ourselves about it, we can try to do a good job of managing it from the beginning. Otherwise you just end up with an ad hoc mess.

The other point I tried to make here is that, yes, of course, you can do all of this by hand. But in practice, most teams are so under the gun to ship features that they don't do it. If we can make great boot performance as easy as installing an npm package, why not?

Lastly, regarding the vaporware claim: we've got a very alpha version up on GitHub already. I invite Ember users to play around with it and give us feedback: https://github.com/tildeio/ember-cli-fastboot.

The approach described in this blog post builds a JavaScript app from the get-go, and uses a server-side technique to extract standalone HTML from the JavaScript application.

The net effect is the same (you get HTML on the client before you executed the JavaScript), but the developer paradigm is sharply different.

Typical progressive enhancement techniques require you to carefully construct a version of your application that works without JavaScript, and then find ways to shim in and bring the page alive. The approach I'm working on provides the HTML as a by-product of running the application normally.

Additionally, progressive enhancement techniques almost always involve server-side rendering, which means you lose the benefits of client-side routing I describe in the post.

The goals of progressive enhancement are wonderful. My complaint has always been that previous techniques hamper developer productivity far too much to be realistic. With FastBoot, I'm hoping we can offer the benefits with far fewer costs.

I guess the high order bit for me is that developers shouldn't have to worry about stuff like this—picking the "right" implementation of their app architecture. Ideally, everything just works out of the box. The harder it is to do, the less likely people are to do it.

FastBoot allows you to boot up your JavaScript application on the server, gather model data, and send the rendered output as HTML to the client. This allows search crawlers, cURL, and people with very slow JavaScript engines to access apps that were previously unavailable. I've had a fire in my belly to make this work since I had a conversation with Dan Webb at Twitter about all of the reasons they switched away from client-side rendering[1].

1: https://blog.twitter.com/2012/improving-performance-on-twitt...

Most people think this problem has already been solved by being able to render templates on the server, but the problem is much harder than that. For example, I learned on HN yesterday that most server-rendered Flux apps can only handle one request a time, due to the reliance on singletons[2]. You really need an application-wide DI system like Angular/Ember to get this working with multiple requests in parallel.

2: https://news.ycombinator.com/item?id=8989667

I'm really really really excited about this work because I think we can have a single, robust solution for all Ember developers that is dead simple to install and get running. Most importantly, this makes JavaScript apps accessible for everyone, while retaining the UI advantages for those whose devices are capable enough. In other words, I think once this is complete, we can finally put to bed the controversy over whether server-side or client-side rendering is best—we'll have a hybrid that offers the best of both worlds.

We'll be working on this feature for the next few months, and we think it has the opportunity to fundamentally change how web apps are written. As you noted, little bits and pieces of server-side rendering have existed for awhile (I've heard of people using Backbone + Handlebars, as well as React), but historically it's required so much manual labor, and is so error-prone, that in practice very few people have the resources to pull it off.

We hope that by moving a full-stack framework like Ember.js to the server-rendered model, it will start to see wide-scale adoption.

In this case, I think you've got the causality mixed up. Projects often gain prominence thanks to the work Yehuda puts into them, as he's particularly good at articulating their strengths to a wider audience. It's not that he's bandwagon hopping—it's that he's helping to create the bandwagon. ;)

We've been using Rust in production for awhile now, specifically because of its combo of native speed and memory safety[1]. This bending of traditional tradeoffs has let us implement features that would have been otherwise impossible.

Interfacing with Ruby via its C APIs, we are able to do some pretty crazy stuff, like sample memory allocations in production with imperceptible overhead[2]. Most importantly, we can do it without fear of segfaulting our customers' servers.

It's really great to see people other than low-level bitbangers being added to the core team. In this case, having a production user and someone focused on new users demonstrates the Rust team's commitment to building a functionally diverse community.

Lastly, I think opening up the core team to a wide coalition of companies is the right way to build a robust, long-lived open source project. Yehuda talked a little bit about this in his Indie OSS talk[2]. There are several "pathogens" that can affect open source projects, and the more diverse the distribution of power, the more likely you are to be immune to these pathogens.

1: http://blog.skylight.io/bending-the-curve-writing-safe-fast-...

2: http://blog.skylight.io/announcing-memory-traces/

3: https://www.youtube.com/watch?v=YqXU4o24Hkg

I beg to differ there. ;) I work on Skylight (https://www.skylight.io) which is definitely doing some interesting stuff in the APM space.

By focusing on just Rails, we are able to provide features that other services that try to be a jack-of-all-trades frequently miss. For example, we just rolled out a feature that helps you monitor memory usage in production with extremely low overhead[1], which I don't think is something any of our competitors offer.

But yeah, definitely agree that New Relic has been a market leader here. They've validated that people are willing to spend real money on improving performance, something that wasn't obvious just a few years ago.

1: http://blog.skylight.io/announcing-memory-traces/

As an open source maintainer, one of the most valuable things people can contribute is great design. Not a lot of designers think to spend their spare time contributing to open source.

If you work at a company with great designers and you ever notice they have some spare cycles, you can have a huge impact by helping them contribute to your favorite open source project. Not only does the open source project get desperately-needed design, your company gets the increased visibility that goes with it. (How much is that DockYard logo on the front page worth in advertising $$$?)