Should Discourse adopt Ember's Fastboot?


(Jacob Chapel) #1

First question, barring any obvious technical and platform differences (Node vs Ruby), should Discourse adopt Fastboot?

I personally think we should. Having fast (and potentially cacheable) HTML available to users without requiring JS to execute would be great for the site experience as well as things like SEO and accessibility. In my day job I focus on optimization for search, and prefer server-side rendering when available at least for the initial page load. Beyond that single page apps generally have a better experience with proper URL/history management.

If Fastboot was not able to be ported to Ruby/Rails for usage with Discourse and required Node, should Discourse add Node for the rendering portion alongside the Ruby/Rails parts?

This I am torn on. On one side, I love Node and use it as my primary platform both personally and at work, but outside of rewriting Discourse in Node, I feel it would be too much. I guess it would depend on the amount of pieces that would have to be maintained to accomplish this, but if it was easily isolated and worked similarly to any other client just as a Node process, that might not be so bad.

I wanted to open discussion on this as I think it is interesting and wanted to know what people think.

References:


Preload certain site images
Optimizing Performance for Non Logged In Users on Mobile
(Kane York) #2

Discourse is already shipping Node for uglify.js. (This causes extremely long upgrade times for people using the old (old old old) manual install without Docker, and really fast upgrade times for people using Docker.)


(Jacob Chapel) #3

Not exactly the same thing though, but a step closer.


(Jacob Chapel) #4

Found this discussion on Embers forum and look who posted. @codinghorror

Does this mean you’re interested? I’d like to understand the scope of work involved and hopefully be of help.


(Sam Saffron) #5

I am very interested, in particular on mobile, we already ship node in our base docker image.

It a very long road to get there though. Very long road.

We also already bundle v8 in ruby, and could use it, however recently I discovered some perf issues with the bridge which is the reason I ended up adding node


(Jacob Chapel) #6

Yes, looking around, it will be a large job to untangle things.

At the very least, Fastboot is still a little bit away, at least to where we can use it. So there is time to figure out how best to handle that transition.

@sam Would it make sense to move the Ruby app side of things to only handling the API and have Nginx route HTML requests to Node.js? Let me know if I’m asking a dumb question as I don’t know much about the Ruby side of Discourse atm.


(Sam Saffron) #7

Honestly I would first have to see how well therubyracer fairs once @wycats and @tomdale finish shipping fastboot, we also would need a bunch of prep work for some “non-Ember” parts of the app that reach into the DOM.

We would be looking from guidance from them before making any radical moves here.


Show a loader starting page for slow connections?
(Jacob Chapel) #8

Thought it was a good take and explanation.