Missing the Point of Server-side Rendered JavaScript Apps
1–10 of 79 posts
Re: Missing the Point of Server-side Rendered JavaScript Apps
#2So they are building a server-side app to deliver a usable first-load experience with HTML and CSS, while the JavaScript loads in and runs, and until the JavaScript runs, all the links work like normal anchors.
Sounds like Progressive enhancement [1].
[1] http://tomdale.net/2013/09/progressive-enhancement-is-dead/
Re: Missing the Point of Server-side Rendered JavaScript Apps
#3My response to this consists of a library: http://intercoolerjs.org/
Server-side rendered HTML: an idea so crazy... It. Just. Might. Work.
Re: Missing the Point of Server-side Rendered JavaScript Apps
#4So they are building a server-side app to deliver a usable first-load experience with HTML and CSS, while the JavaScript loads in and runs, and until the JavaScript runs, all the links work like normal anchors. Sounds like Progressive enhancement [1]. [1] http://tomdale.net/2013/09/progressive-enhancement-is-dead/
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.
Re: Missing the Point of Server-side Rendered JavaScript Apps
#5You gotta love the Orwellian naming on this one. "Ember FastBoot" meaning Ember-we've-been-selling-you-very-slow-booting-for-years-and-now-we're-hoping-to-mitigate-it-slightly-but-it's-still-vaporware.
Meanwhile, the commonsense approach has always been faster and simpler than this model: Use a small JS framework, not a bloated one, and only load the minimal UI and data set that you need to render the initial page at first. Load the rest later. This includes bootstrapping — remembering to put all the data you need to render the page inline as a JSON object in the HTML.
This can often result in less data sent over the wire than a large HTML page with tons of repeated DOM elements. It's also far easier to cache appropriately.
Re: Missing the Point of Server-side Rendered JavaScript Apps
#6So they are building a server-side app to deliver a usable first-load experience with HTML and CSS, while the JavaScript loads in and runs, and until the JavaScript runs, all the links work like normal anchors. Sounds like Progressive enhancement [1]. [1] http://tomdale.net/2013/09/progressive-enhancement-is-dead/
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 execute…
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.
Re: Missing the Point of Server-side Rendered JavaScript Apps
#7I would take it a step further and say that server-rendered JavaScript apps completely changes the game and will have ripple effects throughout the web industry.
Here's MercuryJS's example of server rendered app: https://github.com/Raynos/mercury/tree/master/examples/serve...
As you can see most of the code is the client-code. All the server code does is run a function and stringify the results.
What this means is that you no longer need a back-end team and a front-end team. Your front-end team is your team (not counting "API" teams). Sure, some companies have already been doing this but now you can do it with far less code. And you can do it faster. And with fewer developers (there's less work). Which means you can do it cheaper.
All of this means is, if you are writing your front-end and back-end in different languages, you are in a real competitive disadvantage.
So any language used for web development is going to see its usage slide if they can't find an answer for transpiling to JavaScript. And hopefully having an isomorphic answer the way JavaScript now has.
Re: Missing the Point of Server-side Rendered JavaScript Apps
#8Thank you Tom Dale for continuing to make ember better with Fast Boot. I personally write and live-test a lot of my apps on 4chan's /g/ and /r/programming (which I imagine hosts a large "tinfoil" user base), and the most common feedback I would get from them is "why do you need javascript for this trash?" (well, the actual most common feedback I'd get from them are personal insults regarding my sexual preferences, but they're not constructive and heeding them will not lead to a better product). So thank you so much for working to make ember server-side-enabled.
Also, not to put the cart before the horse, but any chance we'll be getting virtual dom any time soon?
Re: Missing the Point of Server-side Rendered JavaScript Apps
#9You gotta love the Orwellian naming on this one. "Ember FastBoot" meaning Ember-we've-been-selling-you-very-slow-booting-for-years-and-now-we're-hoping-to-mitigate-it-slightly-but-it's-still-vaporware. Meanwhile, the commonsense approach has always been faster and simpler than this model: Use a small JS framework, not a bloated one, and only load the minimal UI and data set that you need to render the initial page at…
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.
Re: Missing the Point of Server-side Rendered JavaScript Apps
#10I don't think anyone is missing the point at all. I fully understand what you're attempting to do because I tried to implement an Ember project only to have so many negatives pile up that it was actively working against our goals.
I really wanted to like Ember, but even with those issues aside, the two most common comments on out team about Ember were "Wait, why is that working?" and "I didn't change anything, why isn't it working now". Neither is something you should be hearing from your dev team.
You can do some pretty cool things pretty quickly, but there are more promises that resolves.