Hacker News Reader

Comment by frontendbeauty | Hacker News Reader

(author) Cool! What's the JavaScript runtime on the server? Something JVM-based?

The server code is still Java, but our template language (https://developers.google.com/closure/templates/) compiles to both JS and Java.

Why 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.

The 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.

In 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.

Shit 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.

Why would you pre-render if your data is not changing continually? Don't you just have static content then?

The benefits of sharing the templates on both client and server, but with a more robust backend technology. This sounds interesting to me.

We use the full closure stack and tofu alongside the decoration phase works a treat.

Reply on news.ycombinator.com