Provide Server-Side-Rendering helper using more purely JavaScript

[denghongcai]

What problem does this feature solve?

Current Server-Side-Rendering implementation is bond to Node.js, makes it hard to use in Nashorn (lightweight high-performance JavaScript runtime in Java with a native JVM) or other JavaScript runtime.

Foundations needed by Vue like vm and fs modules may be passed into renderer or runner as parameter which implements some interfaces.

What does the proposed API look like?

[posva]

Added a note about Nashorn

[wojtask9]

I would love to see that happen.

I'm trying to use Vue.js with nashorn too.
It will be great if Vue.js SSR added interfaces such a FileSystem or Engine to externalize
some functionalities that are bind to node.js

I've made some research:

1. path in all places can be abstracted
   currently used path.extname, path.join, path.isAbsolute, path.dirname

2. fs in all places can be abstracted too
   currently used fs.existsSync, fs.readFileSync

3. module
   only one usage NativeModule.wrap
   According to docs and soruce code this only wrap script code with

(function (exports, require, module, __filename, __dirname) {
// Your module code actually lives in here
});

so this is can be replaced with function if we are not on node.js

4. resolve , vm used in create-bundle-runner.js
   This file can be somehow abstracted :) not sure how and what interface could look

5. stream, source-map-support TODO :)

I made small modifications in source code to get rid of stream and path
my entry:

//import 'core-js/modules/es6.array.find.js';
//import 'core-js/modules/es6.object.assign.js';
//import 'nashorn-polyfill'
//import 'event-loop'
import  Vue from './web-runtime-with-compiler'
export { Vue }
export { createRenderer/*, createBundleRenderer*/} from './web-server-renderer'

result sizes:

1. only createRenderer() and removed path and stream requires (commented stream functions and replaced path with own simple implementation)
   after browserify -> 430KB
2. only createRenderer() (commented out bundleRenderer form entry)
   after browserify run -> 580KB
3. createRenderer() and createBundleRenderer() (not modified at all)
   after browserify -> 700KB

[denghongcai]

@wojtask9 suprised to see you go further! Would you mind share us a demo code?

[wojtask9]

Yes of course. I can share my code. But you must be patient (because of Easter Holiday)
JS part I'll try share tomorrow evening and java part probably on Tuesday.

[denghongcai]

@wojtask9 Thanks! I will also try to design and implement some helper for Nashorn, to see how it will be going.

[danspeck]

@wojtask9 Hey, we're interested in seeing your solution as well. Can you post it somewhere?

[wojtask9]

yeah. I'm finishing it. have been busy for the last days.
Currently trying to run ssr tests on nashorn to be sure if everything is OK.
Please be patient :)

[wojtask9]

You can find "my" code here:
https://github.com/wojtask9/vue

packages/vue-server-renderer-nashorn/vue-nashorn.js -> complete JS file with all required dependencies and polyfills for Nashorn.

I tried to do modify Vue sources as less as possible.
People can build Vue for Nashorn typing npm run build:ssr-nashorn
For jasmine tests in Nashorn type npm run test:ssr-nashorn (on windows you must change path to jjs.exe in package.json)

Currently only renderToString works.
renderToStream have some issues with threads but should be resolved soon.

createBundleRenderer is currently commented because first I must resolve issues with Streams but on my TODO :)

If you have any questions I'll try answer :)

[wojtask9]

Ok i fixed streams and other issues.

There is only one left issue that I'm aware of ( read -> everything works)
For big data (like benchmark/ssr/common.js) renderToString and renderToStream doesn't return output.
If I change rows and columns in generateGrid to 10,10 from 1000, 10 everything is OK.

Not sure where the problem is :/

Another thing that make me wonder is event-loop. Currently setTimeout is invoked in thread that is different from main-thread. This is difference between node.js and nashorn.
I'll made implementation that behaves like node.js but currently it is more complicated.
But first I'll focus on issue mentioned above.

[wojtask9]

Now everything is solved.
MAX_STACK_DEPTH was too big for nashorn (original 1000 and currently on nashorn 190).

Performance (on the same linux machine)
nashorn full version 1.8.0_121-b13
--- renderToString ---
Complete time: 20982.00ms

--- renderToStream ---
first chunk: 1202.00ms
complete: 28488.00ms

node.js v6.10.0
--- renderToString ---
Complete time: 2164.08ms

--- renderToStream ---
first chunk: 90.15ms
complete: 2005.17ms

so it is rather slow :/ but why?

[denghongcai]

The result is consistent to what i tried using React. repo

Benchmark using JMH framework shows that typically nashorn version server side render is 1000% slower than Node.js version. I thought of wasting time in create/destroy nashorn context.

Since Vue.js use vm module and React.js not, I expected better performance ssr using Vue.js.

Run SSR in Nashorn is more robust than in Node.js. Thread-control, ability to terminate render at any time, cache across thread.

@wojtask9 how about share your benchmark code to see if something can be optimized?

[yyx990803]

I honestly think this is simply because V8 produces much better optimized machine code than Nashorn... not much can be done in Vue/React to solve that :/

[denghongcai]

Nashorn directly map js to JVM bytecode, implementation now may not great enough as V8. I believe things will get better. It's valuable to make Vue.js SSR not bond to a specific JavaScript Runtime. Nashorn (etc. Browser's Service-Worker, Embedded JavaScript Engine)

Define some abstract interface and provide Node.js implementation as default will be great.

[yyx990803]

@denghongcai yeah, that's probably what we will do in the future - but for now we want to focus on providing a good, stable and performant Node-based SSR solution first.