Aurelia：同构？
Aurelia: Isomorphic?
据我所知，Aurelia 不支持服务端渲染here。
但问题是：是否可以用一些 hacks/workarounds 来做到这一点？
最明显的想法是使用 Phantom、Nightmare.js 或其他任何东西来简单地在服务器上 Chrome 中呈现该页面并将其提供给客户端，但这很可能会提高生产力问题。
谢谢！
UPD
根据 Rob Eisenberg 今天（2016 年 4 月 16 日）在 FDConf 上的回应，服务器端渲染将在 2016 年实现，有一个核心团队成员正在处理这个问题，这个功能有一个截止日期。
暂时
我可以建议的唯一方法：使用 phantomjs 呈现页面 + 使用 redis 加速该过程。
但是在客户端恢复状态会很麻烦。
.......
肮脏的解决方案
从服务器加载呈现的页面并在客户端以通常的方式呈现新页面，而不是切换 UI。
它不会是真正的同构，而是在第一页加载时类似于 https://github.com/rails/turbolinks。
.......
我希望 Aurelia 团队能尽快为这种情况提供更简单的东西。
有一个 open issue for Universal/Isomorphic Aurelia 您可以监视。特别是 EisenbergEffect（即 Aurelia 的创建者 Rob Eisenberg）表示，他们正在逐步努力为 Aurelia 提供通用支持。他的 post 提供了大部分细节：
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.
- Enable all aurelia libraries to run on the server. This enables some
new testing scenarios, so it's valuable if only from that perspective.
- 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.
- 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.
- 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.
在当前的 Aurelia 中，有可能增强现有的 html。
文件说
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.
我期待获得有关此功能的更好文档。
在我看来，在服务器上渲染 html 并注入 aurelia 可以使用它，google 也会喜欢它。
我刚刚想到的一个技巧是将初始渲染的静态副本放入 index.html 文件中：
<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>
这当然是完全手动的，如果初始渲染包含数据库中的任何内容，则可能需要更新静态副本
每次数据库内容更改时。 （这当然是同构渲染应该解决的问题）
但是对于我的需要，这是一个简单的网站，其中的一些信息很少更新，这个解决方案就足够了。在我能够实现正确的同构渲染之前，它至少足够了。
据我所知，Aurelia 不支持服务端渲染here。
但问题是：是否可以用一些 hacks/workarounds 来做到这一点？
最明显的想法是使用 Phantom、Nightmare.js 或其他任何东西来简单地在服务器上 Chrome 中呈现该页面并将其提供给客户端，但这很可能会提高生产力问题。
谢谢！
UPD
根据 Rob Eisenberg 今天（2016 年 4 月 16 日）在 FDConf 上的回应，服务器端渲染将在 2016 年实现，有一个核心团队成员正在处理这个问题，这个功能有一个截止日期。
暂时
我可以建议的唯一方法：使用 phantomjs 呈现页面 + 使用 redis 加速该过程。
但是在客户端恢复状态会很麻烦。
.......
肮脏的解决方案
从服务器加载呈现的页面并在客户端以通常的方式呈现新页面，而不是切换 UI。
它不会是真正的同构，而是在第一页加载时类似于 https://github.com/rails/turbolinks。
.......
我希望 Aurelia 团队能尽快为这种情况提供更简单的东西。
有一个 open issue for Universal/Isomorphic Aurelia 您可以监视。特别是 EisenbergEffect（即 Aurelia 的创建者 Rob Eisenberg）表示，他们正在逐步努力为 Aurelia 提供通用支持。他的 post 提供了大部分细节：
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.
- Enable all aurelia libraries to run on the server. This enables some new testing scenarios, so it's valuable if only from that perspective.
- 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.
- 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.
- 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.
在当前的 Aurelia 中，有可能增强现有的 html。 文件说
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.
我期待获得有关此功能的更好文档。 在我看来，在服务器上渲染 html 并注入 aurelia 可以使用它，google 也会喜欢它。
我刚刚想到的一个技巧是将初始渲染的静态副本放入 index.html 文件中：
<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>
这当然是完全手动的，如果初始渲染包含数据库中的任何内容，则可能需要更新静态副本 每次数据库内容更改时。 （这当然是同构渲染应该解决的问题）
但是对于我的需要，这是一个简单的网站，其中的一些信息很少更新，这个解决方案就足够了。在我能够实现正确的同构渲染之前，它至少足够了。