Having implemented a similar concept using React (and Flummox), I'm curious how FastBoot solves the async data fetching problem; does it require the developer to be careful about how things are set up, or does a solution naturally fall out of how Ember works? Running what amounts to an event-loop once to get the HTML result wasn't that difficult, but ensuring that the app wasn't relying on said event-loop to render parts we needed out as HTML on the server was slightly annoying (but not insurmountable).
Ember has default model() hook for routes, and propose to add extra data fetching you need in children components into afterModel hook.
Everything is working just like you would set it up with React, except that with Ember declaring data dependencies on route is existing convention. And React gives you maybe a little bit more control around that.
> declaring data dependencies on route is existing convention
That makes sense, I believe that's exactly what react-async does (if I recall correctly?) with react-router.
For our project, we basically call "await ApiActions.getData(routeParams)" in the server's route, after pulling that params out, which is effectively the same idea, and it worked quite well. I'm curious how one would tackle that from a different perspective, but it seems we all end up coming to the same conclusion!
Hi, I'm new to Ember and more complex JS apps in general. Can you confirm my initial "understanding" of what you did?
Normally Ember app would render everything within the browser after all JS is downloaded and components etc. are processed. 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) and sends the output to the client. It does it for every route separately. 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 :)
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)
Right. Typically, the way most client-side JavaScript applications (or "SPAs") work is by having a small, static HTML file that doesn't contain much content (beyond maybe a loading page). It contains <script> tags that point at your JavaScript payload.
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 :)
Currently it does a full rerender once it loads, but one of the motivating features for writing Glimmer 2 is the ability to quickly "rehydrate", so that rerenders are imperceptible to the user assuming nothing has changed. We'd also love to automatically serialize the backing models of the app so you don't have to double fetch.
> 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.
Aren't we now just back to square one again in terms of MVC frameworks? What are the advantages here over simply implementing Django, RoR, Spring, Laravel, etc and cutting back on the JS (at least in terms of content-driven sites)?
> What are the advantages here over simply implementing...
You get all of the advantages of single page apps, without the unresponsive initial load time. There are also whole classes of apps you can't build with Django, RoR etc, so the question is a bit ridiculous IMO.
It really isn't. Jumping into using a huge performance sink like ember to add a little interactivity to a content page is a horrible decision to start with. This just seems to drag the poor performance back to kill your server
That's a straw man though. Sure, adding Ember for a "little interactivity" is kind of stupid. But if you want to add a lot of interactivity? Is a load of "$.click" function soup better?
> I think FastBoot is a great option for (...) supporting JavaScript-less clients.
Wait, is one use-case that works out of the box to have a view that works both in text-mode browsers, like w3m and lynx (or graphical browsers with js disabled due to security or other reasons), and also "ramps up" to work well as "regular" SPAs?
Because that's one thing I've yet to see anyone really pull off: being able to define sane, simple components/widgets that also works reasonably without javascript (eg: the ability to render data as a table, and have click-able headings for sort that works both in lynx and without hitting the server in a modern js browser).
This is actually a very good comment that helps newbies decide whether they should create/need a "universal" app or not for SPAs. To add to this, there's also the claim about code reuse.
There are other initiatives in the ember-verse for solving the 'universal app' issue.
Specifically, ember-engines provides a way to separate code into logical apps, but having them appear to be a single app. It's currently 'experimental', but in very active development.
For us, it provides the best-of-both worlds... a single interface to the customer, without having to load up all of the code, services, etc that are used in every corner of the app.
Yes it's correct for first route you visit, it's rendered on server and sent already rendered to your browser, then the rest of the framework is downloaded and another request is rendered in your browser.
The Inspector works by injecting some debug code into the running app, so it won't work with FastBoot because the JavaScript is running on the server.
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.
How is initial render performance currently? If I recall correctly, Glimmer 1.x unintentionally slowed down initial render performance. Has this been or will this be addressed?
We're running Ember 2.2 on Intercom and we've found it to be faster than 1.x. In addition to this, it looks like Glimmer 2 will bring significant render time improvement for both initial render and subsequent DOM updates.
Ember continues to be an antidote to the insane package/build madness in the JS ecosystem. It's opinionated for sure but it's also very easy to get started with.
While I love Ember, one of it's biggest downfalls is definitely has a longer ramp up period, and more complexity than other frameworks. Ember's documentation is very good now, but still, there is a lot you have to read (and eventually experience to truly understand) about how ember works under the covers.
One of ember's greatest benefits is that it adapts to change and doesn't miss out on features for very long at all (you can look at fastboot as a reaction to isomorphic react apps, or something that the ember team would have just pursued anyway). However, that benefit can also be a pitfall for newcomers to ember as it's hard to find consistent discussion, help, and resources for a framework that changes so fast.
BTW, while Ember CLI makes things much easier, it does not improve the complexity situation, it just becomes one more thing you have to learn when learning Ember (even as a newbie). What if a newbie isn't familiar with node? what if they're not sure why you're precompiling? what if they're not familiar with task runners like grunt and gulp?
Contrasted with frameworks like Angular 1, Backbone+Marionette, Ember definitely has the most rampup and complexity, not the least.
I think the CLI helps tremendously, even if you have to learn it (and for simple stuff you don't aside from `ember new` and `ember start`, maybe a few file generators). The biggest problem with beginners is setting up a JS environment—I've seen people waste hours doing it. Ember's CLI tool takes care of all of that.
I agree it helps -- but there is a hidden cost of people not understanding all the towers of abstraction that have been built up for them, despite sitting on top of it.
Ember CLI does file generation and a whole lot more. I'm not saying it shouldn't -- but that shouldn't be the easiest most approachable way to start with Ember.
Why should someone have to learn all the following things:
- transpiling
- nodejs
- npm & packaging
- bower
- broccoli/task runners
- livereload
... just to START with a web framework?
Maybe don't market Ember to beginners? Again, I like Ember, I think it's the most viable large framework out there right now -- but this is certainly an issue
Most frameworks I have used (yes React included) don't require any of those. Their documentation is lacking/confusing, and the community build "documentation" is not designed to bring a newbie from the newbie level to the guru level gradually - it is designed for jumping straightway up. Several hundreds of "starter" templates are one good place where the dependency bloat starts because the template maker wanted to cover every single usecase ever, but not help the user start (see the irony?).
You can very well use React/Angular(1, atleast)/etc. just by including a script file in your markup and continuing to write your application code. There was a tutorial series for React posted on HN sometime before that made you learn React just this way.
> I've rarely seen Ember be recommended to beginners.
I started a new job and went from 0 JS (other than some JQuery and knowing the syntax) to 100 with Ember. Ember is really really good for beginners, grandparent talks of having to know transpiling, broccoli/task runners and livereload but doesn't understand that you need to know none of that to get working with Ember.
Write your app by editing the files ember-cli produces. No transpiling, or add transpiling with a single 'ember install' command. Who cares about broccoli, I just edit my ember-cli-build.js file with some paths and it all works. Livereload is hardly difficult to understand, with Ember you just run "ember serve" and it also all just works.
I stand corrected -- clearly what I thought was what beginners would feel is not what they did.
My point though, was that after you build on all this complexity that you don't understand (and don't have to deal with), when something goes wrong, you're in for a world of hurt. But maybe that's not an issue
Abstractions aim to hide complexity until one requires them.
As a developer, one becomes productive when one realize when to put the blinders on, and when to take them off. As such I for one, love that I don't need knowledge of x86 assembler, chip design, or signal processing until the problem at hand actually requires them.
Ember-cli aspires to keep developers focused on features, not orthogonal tech. That is unless they need to peel back that layer of the onion, and dive in. Even then, the goal is for only a few community members to dive in, explore the problem space, and ultimately contribute the solution. Next release, all community members benefit, without also having to invest (until the point where they have a specific itch to scratch).
Abstractions hurt when they leak, as such we must aspire to provide the best abstractions we can (at each layer), and this is only possible in collaboration with an eager and enthusiastic community.
An symptom of a curated solution, is all aspects of the stack evolve to work together. Mitigate abstraction leaks at the various boundaries.
Yeah, Ember maybe shouldn't be recommended to beginners... I think it has some of the best documentation however (especially true in recent versions, if your codebase is pre-1.10, you're donezo though).
Also react's documentation is terribad. I'm in the middle of teaching someone who is completely new to JS how to use React, and the documentation has been horrendous (for newbies), reasons:
- JSX is super hard to properly understand if you only know HTML and JS and don't know they normally don't mix, and aren't actually mixing
- Requiring precompilation (no more JSXTransformer, no more babel-browser)
- The entire concept of components-all-the-way-down
- Documentation (Reference) section that does not differentiate between code blocks you can use and function signatures
- Hints on how to deal with routing
- No explanation of where to store data/state
I, as an experienced developer, can very easily understand React (I've used it on 2 projects now I think, and I like it), but there is so much for beginners to stumble on.
> only sources of sanity and reason in this community
Oh come on now, lets not be hyperbolic. I'm a massive fan of Ember, but I'm a bigger fan of Redux with React; the reason that Ember can afford to be opinionated is because the team is extremely smart and takes the best winning ideas from the outside "insane" community.
I'm not being hyperbolic, and I think the React ecosystem deserves a large part of the blame for this mess. I am totally aware that is an unpopular opinion.
The fact that Ember can distill the insanity of the community into an opinionated and usable framework (and also take wonderful ideas from things like Rails) is exactly what I mean by a source of reason.
Good news is that on a medium-sized project (10s of routes and models), it still just takes two commands... haven't gone through setting up production yet, but I don't foresee any big issues.
Ember just keeps getting more and more interesting (Ember NYC meet ups have been great so far!). Going to have to give a good, lengthy try. Coming from React, I like the cli tool and strong community conventions.
Having access to .cljc (clojure files that can be loaded by either CLJS or standard CLJ) helps tremendously here. This means the server-side happens in Clojure on the JVM, so all of the async worries just go away entirely.
I work on server-side rendering for DoneJS[1] and ours is probably the best solution out there today, in my biased opinion. We provide:
* Fully asynchronous rendering, so you don't have to awkwardly architect your app so that it can be rendered synchronously.
* Everything is fully progressively loaded. This means if you go to a particular page in your app, only that page's JavaScript and CSS will be downloaded in the client. Additionally the correct css link elements will be inserted.
* Caching XHR requests so that they are not repeated on the client (data used to render is included in the page).
What makes our solution unique is that you have to think about the server very little, if at all. If you need to make a request to services, just make it in your code. No additional wiring is needed and everything will be server rendered.
Much of this is possible because of Zones, a spec that is being worked on for standardization in TC39. We have a library that implements Zones[2] with SSR in mind. This is what makes XHR caching possible, for example. Check out this simple jQuery example app[3] (using jsdom on the server) to see how easy Zones make things.
Sorry to nitpick, but I don't think the React example is an analogous initiative. ;)
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.)
> conventionalizing app boot and figuring out how to run multiple instances concurrently
I am a software engineer who usually develops also for the client side and I follow and experiment with the JS trends because I find them interesting. However, I don't understand what you mean by these. Could you please be more specific? Thank you.
...and "conventionalizing app boot" just means making it a few simple commands to implement for any given Ember.js application (instead of each application needing its own bespoke solution).
Author of the simple React example here – Tom says there's a "huge gulf", but forgot to mention there's literally an example[1] of an asynchronous routing and data fetching app linked to in the first section of that page that's a logical progression of the first. (and others have pointed out much more complex examples you can achieve with React if you so wish)
The goal of those small examples is to illustrate that you don't need complex frameworks to achieve server-side rendering with data fetching and routing.
I have no doubt that FastBoot was a huge undertaking, and I think a large part of the reason for that is that it's aiming to fit into a very comprehensive existing framework, with pieces for routing, fetching data, "application instances", etc – there's a lot more work involved in that (for the framework author I mean, not the end user) than there is starting off with just a view library and adding your own pieces around that.
Honestly, it comes off pretty poorly for you to downplay the work of your competitors.
It might be easier to get server-side rendering working with React, but pretending that it's not the same thing is just condescending. There are dozens of examples out there showing how to render React pages on the server, including fetching the necessary data for that rendering.
The mechanisms you use might be different, but pretending they're not analogous is duplicitous at best. Both let you ship a fully rendered first view to the client.
If I wanted to downplay competitors, why would I acknowledge that Angular 2 is doing something similar? Angular has much larger marketshare at the moment than React.
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.
I totally believe the work you've done here is significantly more polished and "conventionalized", that is awesome and congrats! Ember's tools are really slick.
That said, everything you're describing – "asynchronously boot an app, marshall async data, render an async UI, and do it concurrently" – is really, really, really the same thing we're (my team at least) doing with React. People aren't just using `renderToString` and calling it a day.
I think this argument is coming down to semantics.
Is there an 'analagous initiative' in React? No.
Can you end up with the same result in React? Yes.
There are people doing this in React, but each team needs to do it slightly differently because their app is setup differently. There are guides and examples on how to do it, but unless you setup your project exactly like the original author, you'll have to figure out portions of it on your own.
On top of that, you won't know if the modules that you are using will play well with the offline rendering.
The convention-driven approach IS the product... You make it sound like that is just a little bit of polish, maybe a page or two of documentation... But it took over a year of planning and architecture to make all of the changes. (There was a great demo of fastboot a year ago) Because of the planning and framework changes, however, every addon that follows the conventions will 'just work' with fastboot.
When Tom says "An App"... he means "Any App"... and that isn't something that I've seen being worked towards by the React community. It IS being done by other communities, as seen in this thread, so I think that it's valid for Tom to call this out as not being analogous.
> I'm not downplaying their work—it just really, really, really is not the same thing.
The methods might very well be different, but the result is the same.
Pretending that you can't do server-side rendering with React is not helpful and untrue. Just because they haven't put the same work into conventionalizing it does not mean that analogous initiatives don't exist for React.
There are plenty of guides and tutorials out there showing how to do server side rendering in React.
From one point of view (a user of the framework who doesn't care how the sausage gets made) they are analogous. But from the point of view of someone who developed the solution or who has to micro optimize the solution I believe tom dale is right that it is quite different.
You're right that tomdale came off condescending (as he often does when promoting/defending ember...ah well). But it certainly isn't "duplicitous at best"!
> 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 dont think it is fair to say it that way. React implementation doing all this (except async/streaming rendering) is man-week at worst in existing medium sized project, and man-day for a new project with no pre-existing code.
FastRender [1] for Meteor is a similar but not analogous project. Similar in that it improves initial render speed. Different in that it does so by delivering the data required to render the page along with the initial payload so things are still client-side rendered, not rendered for you on the server.
For what its worth, FastRender was first released in 2013. The just-released Meteor 1.3 now has ES2016 module support which should enable more improvements in this area.
i'm not sure i understand the distinction you're making.
you write a client-side app and can render on server via Node and hydrate/attach the js on client after the dumped html. you get "instant" initial render and "progressive enhancement" once the js executes.
My naive understanding is fastboot actually understands stuff like your client-side routing, and how an Ember app 'loads' and fetches data (from your API) so you don't have to recreate that stuff with duplicate code on the server-side like you would have to with the aforementioned React example, and I think, your library.
i think it heavily depends on how coupled your router is to your view and data/fetch layer. with domvm everything is decoupled, so wiring any of those modules up is pretty trivial.
a more fleshed-out demo would be valuable for a more realistic comparison. they mention the non-congruence between ajax vs node's fetch, but this is easy to shim so the same code works on both.
the main complexity is the view rendering and post-render hydration.
Build error
The Broccoli Plugin: [object Object] failed with:
RangeError: Maximum call stack size exceeded
at new Error (native)
at Error (native)
at Object.fs.mkdirSync (fs.js:794:18)
at sync (C:\Users\marke\ember\github-fastboot- example\node_modules\ember- network\node_modules\broccoli- templater\node_modules\broccoli-stew\node_modules\broccoli- funnel\node_modules\mkdirp\index.js:71:13)
at sync (C:\Users\marke\ember\github-fastboot- example\node_modules\ember- network\node_modules\broccoli-templater\node_modules\broccoli-stew\node_modules\broccoli-funnel\node_modules\mkdirp\index.js:77:24)
at sync (C:\Users\marke\ember\github-fastboot-example\node_modules\ember-network\node_modules\broccoli-templater\node_modules\broccoli-stew\node_modules\broccoli-funnel\node_modules\mkdirp\index.js:78:17)
at sync (C:\Users\marke\ember\github-fastboot-example\node_modules\ember-network\node_modules\broccoli-templater\node_modules\broccoli-stew\node_modules\broccoli-funnel\node_modules\mkdirp\index.js:78:17)
at sync (C:\Users\marke\ember\github-fastboot-example\node_modules\ember-network\node_modules\broccoli-templater\node_modules\broccoli-stew\node_modules\broccoli-funnel\node_modules\mkdirp\index.js:78:17)
at sync (C:\Users\marke\ember\github-fastboot-example\node_modules\ember-network\node_modules\broccoli-templater\node_modules\broccoli-stew\node_modules\broccoli-funnel\node_modules\mkdirp\index.js:78:17)
at sync (C:\Users\marke\ember\github-fastboot-example\node_modules\ember-network\node_modules\broccoli-templater\node_modules\broccoli-stew\node_modules\broccoli-funnel\node_modules\mkdirp\index.js:78:17)
The broccoli plugin was instantiated at:
undefined
Np! There is also a #-fastboot room on the Ember Community Slack, directions for jumping in there can be found on emberjs.com: http://emberjs.com/community/
Looking forward to see this project grow. Haven't had the time to check it out, but as I've been using Ember for the past months, it looks very interesting.
I dislike code generators and want to use my own tooling for building, testing, etc.
In my eyes Ember has become an old-school Rails like Blob and newer frameworks are more about modules and "Bring Your Own Tools". I mean who, besides Ember, uses Broccoli?!
That seems to me like a really bizarre thing based on a really personal story(that I'd like to hear). After all:
* Code generators can speed up development
* They give newbies a better idea of how the framework should be treated
* They give the framework a more dependable layout
* They still provide the escape hatch of not using them!
What would a dev have failed at simply because they built a code generator?
> What would a dev have failed at simply because they built a code generator?
Creating an understandable API and making stuff easily extensible.
I often have the feeling these code generators try to hide bad design decisions, which resulted in a huge amount of boilerplate code, that wouldn't be needed if things were designed different.
And you can't even blame most frameworks for it. Ember has so much history that you can't simply throw every thing out, because "now animations or server-rendering is a PITA", so devs maneuver around it with code generators.
There are valid reasons to have them. But when I have to choose frameworks for a new project, code generators are definitely red flags for me.
I don't have much of a problem with this controller/route/model generation stuff, that you mentioned. I wouldn't use it, but I can see why people save a few minutes.
That's really all that Ember has in terms of code generation. That, and getting tests set up for you.
I don't see how you have a large ecosystem that is still friendly to a new developer without code generators unless you want huge boilerplate. A frontend requires a lot of moving parts, and letting someone else take care of that for me is important.
(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.)