6 ms·
(author) Cool! What's the JavaScript runtime on the server? Something JVM-based?
by frontendbeauty 13y ago
(author) Cool! What's the JavaScript runtime on the server? Something JVM-based?
- thurn 13y agoThe server code is still Java, but our template language (https://developers.google.com/closure/templates/ https://developers.google.com/closure/templates/) compiles to both JS and Java.
- sitkack 13y agoWhy not render the templates in PhantomJs and have a user account that can push the rendered template back into the server cache. No need to duplicate the work of writing two backends. Or hell, just use Rhino and generate the reified pages on the server. Also, you can't patent this now.
- lennel 13y agoThe soy templates have a java (tofu) backend already (several years old). The phantomjs idea is a shit idea and should go away. Phantom is fine and good for headless testing (hells we use it for quite a bit else) but seriously it is not a solution for a real load.
- sitkack 13y agoIn my scenario an alternative (Rhino or PhantomJs) engine would generate a page once and then push that rendered page to the server. No real load would be sent to it. Single code path for all template rendering. Zero cross implementation bugs and the client still gets a fully reified page on first load. Shit idea, lil harsh.
- peterhunt 13y agoShit idea is a little harsh for sure, but the problem is when your page relies on dynamic data and you can't prerender it. It's just too expensive to boot up a DOM on the server.
- lennel 13y agoWhy would you pre-render if your data is not changing continually? Don't you just have static content then?
- lennel 13y agoWe use the full closure stack and tofu alongside the decoration phase works a treat.
- taude 13y agoThe benefits of sharing the templates on both client and server, but with a more robust backend technology. This sounds interesting to me.