ember-fastboot

ember-cli-fastboot

JavaScript2015–2021

ember-fastboot / ember-cli-fastboot

ember-cli-fastboot

Server-side rendering for Ember.js apps

Explore on GitHub Read Hacker News discussions

10Distinct people

12Mentions

0Explicit recommenders

848GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Server-side rendering for Ember.js apps

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year12 dated mentions

Observed mentions: 2015-02-04 15:27:19 UTC to 2021-04-10 02:03:11 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2015	2015-01-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	6	6
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	4	4
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	1	1
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	0	0
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	0	0
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	0	0
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	1	1

What Hacker News says

12 sources

glaucon·Apr 10, 2021

This is interesting. I use ember but never fastboot. I've been looking at the deployment doco within the fastboot site. Is this along the lines of what you're using ? https://github.com/ember-fastboot/ember-cli-fastboot/tree/ma... . Also, looking at your profile, is https://sqwok.im using that approach ? Thanks.

In AWS Lambda Edge changes duration billing granularity from 50ms down to 1ms

Touche·Mar 28, 2017

I think Ember is really good at marketing the stuff they work on, but it is usually overhyped. Fastboot, for example, was announced what, 3 years ago? The readme says it's still not ready to use: > The bottom line is that you should not (yet) expect to install this add-on in your production app and have FastBoot work. https://github.com/ember-fastboot/ember-cli-fastboot I find this is often true of Ember projects (like Glimmer 1), a lot of hype for something that has a lot of rough edges.

In Glimmer – Fast and light-weight UI components

matthijs_·Apr 9, 2016

Reminds me of Ember FastBoot. Different framework, different use case, but relatively easy to implement. https://github.com/ember-fastboot/ember-cli-fastboot

In Rendering React without browser JavaScript

mixonic·Mar 30, 2016

Opening an issue on https://github.com/tildeio/ember-cli-fastboot is probably the best way to get help tracking down a bug.

In Ember Fastboot

taveras·Mar 29, 2016

I saw Tom give a great presentation on FastBoot back in January. for those interested, here is the checklist for getting to 1.0: https://github.com/tildeio/ember-cli-fastboot/issues/98

In Ember Fastboot

sotojuan·Jan 22, 2016

Seems like Ember is working towards this: https://github.com/tildeio/ember-cli-fastboot

In JavaScript web apps considered valuable

hardwaresofton·Dec 4, 2015

This is currently true, but one of the great (and terrible) things about Ember is that they adapt. They're currently working on a way to get past this, by actually enabling server-rendering (much like react): https://github.com/tildeio/ember-cli-fastboot

In Open source software for developing world hospitals

kellysutton·Oct 15, 2015

The Ember FastBoot project has the goal to provide exactly this: lightweight HTML/CSS on the initial load and then hydrate the page/application with JS. http://emberjs.com/blog/2014/12/22/inside-fastboot-the-road-... https://github.com/tildeio/ember-cli-fastboot

In Page Weight Matters (2012)

kellysutton·Jul 9, 2015

Looks neat. For those looking for this functionality in a more mature framework, check out Ember FastBoot: https://github.com/tildeio/ember-cli-fastboot

In Skit: A pure JavaScript front end for building better web clients

wycats·Jun 13, 2015

> What happened to the server fast-boot thing? I was under the impression you guys wanted to ship it with 2.0; has that feature been scrapped / moved into a separate project altogether? SEO-only FastBoot shipped in canary a while ago (as the `ember-application-visit` feature). It is designed to work with the FastBoot addon (https://github.com/tildeio/ember-cli-fastboot). Rehydration, the big enchilada, depends heavily on the Glimmer work, and should begin momentarily. > There was no mention of the deprecating changes to the initializer API (i.e. the splitting into instanceInitializer and vanilla initializer). Have we gone back to the old initializer API in 2.0? We're sticking with the split-apart API we shipped a few releases ago. It's important to make FastBoot efficient with real-world addons. > With the removal of action bubbling, do w

Read the rest

e now have to manually bubble up actions that start in some nested controller but gets handled in application route? For example, say you have an AdminUserController and it has an action that generates an ephemeral flash message, but you handle flash rendering in your application route. Do you now have to laboriously put an actions: { handleFlash { ... } } on every route along the way? We're starting with more laborious (with services as an escape valve), but have some ideas for conventional situations where you could get away with less ceremony. Stay tuned! (by which I mean, there will be RFCs in the near future addressing this kind of issue).

In Ember.js 1.13.0 and 2.0 Beta Released

tomdale·Feb 5, 2015

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

Read the rest

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.

In Missing the Point of Server-side Rendered JavaScript Apps

tomdale·Feb 4, 2015

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 Fl

Read the rest

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

In Ask HN: What have you achieved in January 2015?