Hacker Newsnew | comments | show | ask | jobs | submit | tomdale's comments login

I was at EmpireJS where this was announced and they said they had a team of Googlers working on it, and showed a few production Google apps built using it.

-----


Interesting. Can you offer any details on which production Google apps were presented?

-----


Always awesome to see another production Ember.js app in the wild.

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.

-----


Thanks Tom, those words mean a lot!

-----


Thanks, Sam. Like all things in technology, there are tradeoffs to make and a cost-benefit analysis that every project will do differently. We spend a lot of time on backwards compatibility in Ember, but my goodness, it's painful.

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

-----


Yes, I totally agree. Sorry if that was confusing—I was trying to simplify the diagrams and perhaps oversimplified.

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.

-----


Re: Virtual DOM, keep an eye on https://github.com/tildeio/htmlbars/pull/282.

-----


I don't want to get into a big discussion on small libraries vs. big frameworks (your use of the word "bloat" gives away your position here ;).

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.

-----


I'd like to stand up and be counted as saying that both

1. Ember absolutely isn't to my taste and I've successfully avoided it so far and intend to continue doing so in future

2. The work you're doing is really cool and I'm looking forward to seeing it completed, both for the benefit of my friends with different tastes who're happily using ember and for the benefit of everybody else in that it provides a worked example of an awesome idea.

(and people who dislike it just because they dislike ember might, possibly, need to remember that trailblazing is important for new ideas)

-----


Typical "progressive enhancement" calls for creating HTML in templates that have no knowledge of the JavaScript, and then using JavaScript to attach behavior to that HTML.

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.

-----


Tom, it's ok to backtrack here. You (and the rest of us) didn't know at the time that progressive enhancement could be possible without making development much more difficult.

-----


I think this might be semantic quibbling at this point.

Yes, progressive enhancement and server-side rendered JS are similar. You can see the latter as a new version of the former. But it is implemented in such a way - a novel way - that it definitely deserves a term of its own.

-----


Progressive enhancement is not a technique, it's a goal. Server-side rendering is a method for achieving the goal.

-----


It's not really useful for the conversation to lump it in with the traditional definition of progressive enhancement that's been done for years.

Even middle of the road efforts I tried a few years ago (such as sharing a templating language between client and server even when the implmentation language differs) was fraught with friction compared to this technique.

-----


Playing devil's advocate:

PE techniques aren't documented (so far as I know) so it's up the developer to take the path they're most comfortable with.

FastBoot, I suspect, will dictate how I code my application/server side logic.

On the surface, it looks like the cost of FastBoot is higher.

The benefits are, I suspect, are higher though: single code base, reusable views, etc.

-----


I got an alpha version of something we call FastBoot working for Ember apps: https://github.com/tildeio/ember-cli-fastboot

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.

-----


It's awesome to see you guys embracing server rendering, but it's incorrect to say most server-rendered Flux apps can only render one request at a time. If you're designing an isomorphic architecture, it's certainly a consideration, but I doubt any production apps have this limitation.

A common pattern is to instantiate a new store for every request, to avoid collisions.

-----


The Flux fragmentation makes this hard to talk about. The examples I've seen from Facebook all use global singletons. There are some libraries/implementations that work correctly, but it's hard to know how widely used those are.

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.

-----


We described our motivation in the previous blog post in this series: http://emberjs.com/blog/2014/12/22/inside-fastboot-the-road-...

-----


Correct me if I'm wrong, but doesn't Derby use MongoDB for the backend? While Derby broke significant ground, that dependency eliminates it from consideration for most people I've talked to.

-----


We use Mongo and currently Mongo is the only database with an adapter for the full realtime synced stack. However, Derby itself can be uses without the ShareJS backend, and it is possible to write adapters for different databases. Thanks for the question!

-----

More

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

Search: