Aurelia：同构？

Question

As far as I know, Aurelia does not support server-side rendering as mentioned here .

But the question is: is it possible to do this with some hacks/workarounds?

The most obvious idea would be to use Phantom, Nightmare.js or whatever to simply render that page in Chrome on server and serve that to client, but this is very likely to cause big productivity issues.

Thanks!

UPD

According to Rob Eisenberg's response on FDConf today (16 Apr 2016), server-side rendering will be implemented in 2016, there's one core team member working on that and there's a deadline for this feature.

Answer 1

There is an open issue for Universal/Isomorphic Aurelia which you can monitor. In particular EisenbergEffect (who is Rob Eisenberg, the creator of Aurelia) states that they are gradually working towards providing Universal support for Aurelia. This post from him provides most of the detail:

EisenbergEffect commented on Aug 25

We are trying to lock things down within the next month. That doesn't mean we won't add anything after that, but we need to work towards stabilization, performance and solid documentation without distractions of lots of new features for a little bit.

Primarily, "isomorphism" isn't a use case we want to tackle for the initial v1 release. Again, that doesn't mean we won't do it later. But, we want to have a solid framework for browser-based apps as well as phone gap and electron/nwjs desktop apps first. That was our original goal and we want to make sure we handle those scenarios better than any other framework or library.

After that, we've got some other features we want to do, which are valuable in their own right, but will also take us closer to isomorphism.

1. Enable all aurelia libraries to run on the server. This enables some new testing scenarios, so it's valuable if only from that perspective.
2. Once code can run on the server, we can then implement server view compilation. This isn't isomorphic rendering, but rather the ability to run Aurelia's view compiler as part of your build and bundle process. This enables more work to be done ahead of time, as part of your build, and then it doesn't need to be done in the browser at runtime. So, this will improve the startup time for all apps and reduce initial render times for all components. It also will make it possible to store compiled views in browser local cache to improve performance of successive runs of the application.
3. After both of those things are in place, then we can look at doing a full server render for each route. This isn't quite isomorphic in the truest sense, but it solves the SEO problem without needing 3rd party libraries. So, it's nice to have a solution there.
4. Finally, we can then "sync" a server pre-rendered app with a stateful Aurelia app running in browser, giving us 100% isomorphic support. So, those are the stages. The first two would be beneficial to all developers, even those who are not interested in isomorphic apps. The 3rd stage can be done today with 3rd party libraries, so this is a nice to have for us, for those who don't want an extra dependency. All of that leads into 4 which adds the final pieces.

We have already begun some of the work on 1. That might get into our first release. We aren't going to push it, but it's already in progress and we're looking for the problem areas so we can make it work. Steps 2-4 involve significant work. Really, we are talking about a collection of features here, each one being rather complex. So, those will probably come in stages after v1, as point releases.

We really don't want to do what Angular 2 has done. They have massively complicated their architecture...to the point that very few people will be able to understand it and developing applications with it has become much more complicated, with many nuances. We really don't want that, so we're focusing on the developer experience we want first, then we'll come back and see about isomorphic support (yes, we already have ideas how to do this cleanly, but want to give those ideas some time to mature). In all of this, our goal is to be modular. So, if you don't care about isomorphism, you don't have to think or worry about it. If you do, you would install the necessary packages, agree to the "constraints" of the system and be on your way.

So, to all who are interested in this topic, I would just ask you kindly to be patient. For those who aren't interested in isomorphism, don't worry, we aren't going to brake the developer experience on you. For those of you who want it badly, you will have to wait longer and it will come in stages and in modular pieces so as not to disrupt others.

Answer 2

Just for now

The only way I can propose: render pages with phantomjs + use redis to speedup that process.

But you will have lots of trouble restoring the state at client side.

.......

Dirty solution

Load rendered page from server and at the client side render new one in the usual way, than switch UI's.

It won't be a truly isomorphic, but something like https://github.com/rails/turbolinks on first page load.

.....

I hope soon Aurelia team will provide simpler stuff for that case.

Answer 3

In the current Aurelia there is the possibility to enhance existing html. The document says

So far you've seen Aurelia replacing a portion of the DOM with a root component. However, that's not the only way to render with Aurelia. Aurelia can also progressively enhance existing HTML.

Check out enhancement section @ http://aurelia.io/docs.html#/aurelia/framework/1.0.0-beta.1.0.8/doc/article/app-configuration-and-startup

I'm looking forward to get a better documentation of this feature. It seems to me like rendering the html on the Server and inject aurelia will work with it and google will like it as well.

Answer 4

a hack i just came up with is to put a static copy of the initial rendering into the index.html file:

<html>
  <body aurelia-app="main">
    <h1>static copy of the website here</h1>
    <script src="scripts/vendor-bundle.js" data-main="aurelia-bootstrapper"></script>
  </body>
</html>

this is of course completely manual and if the initial rendering contains any content from a database then the static copy may need to be updated every time the database content changes. (which is of course what isomorphic rendering is supposed to solve)

however for my needs, which is a simple website with some information that is rarely updated, this solution is good enough. it will at least suffice until i am able to implement proper isomorphic rendering.