Suggestion about node.js-side rendering

[fullfs]

Hello, again!
I'm sorry about being impatient about the subject, but I would like to make a suggestion about how to implement node.js-side rendering (if you would).
I've tested rendering with jsdom a bit and came with conclusion it's rather slow. With huge amount of elements to render the time could reach 10-20 seconds (!!)
So maybe it would be smarter to implement separated template-preparing engine. Maybe something similar to Ractive .toHTML() (http://docs.ractivejs.org/latest/ractive-tohtml)
And with the separated engine it would be much easier to make a system for picking up server-side-rendered html in browser :)

P.S. Thanks for your efforts! I really loved Vue.js and hoping to use it as a basis at my project and I absolutely will if I will be able to produce proper server-side rendering :)

[yyx990803]

Yeah, it's probably necessary if jsdom is that slow :/
Also because in Vue's rendering a large portion of the time is spent on setting up dynamic bindings, which is not needed at all for server-side rendering.

[rayfranco]

Maybe we could learn something from rendr?

[ayamflow]

I was looking at Mercury, a modular alternative to React, which is supposed to have a fast virtual-dom module.

I have no idea if it is possible but maybe it could be possible to "plug" Vue to a vdom for server-side rendering - but I'm not sure that a plugin would be enough to do that, more like a dedicated compiler.

[yury]

Hi,

I'm thinking about combine server side and client side rendering and bindings.

We can inject additional processing to Jade or Slm.

Here is simple template:

p v-text=this.message1
p v-text=this.message2

Template function will produce 3 parts:

1. Rendered html with injected marks (html comments in special format)

<!-- 0,n --><p>message1</p><!-- 1,n --><p>message2</p>

In 0,n 0 is index of binding, n - indicated that binding for next sibling dom element.

1. Array of serialized bindings

[
  {/* serialized text binding */},
  {/* serialized text binding */},
]

1. Data used to render view

On client process will look like:

1. Find all marks
2. Find all needed nodes (by marks)
3. Attach bindings to nodes
4. Trigger events if needed

Since Vue supports IE9+ for finding marks we can use treeWalker:

function getCommentNodes(containerNode) {
    var treeWalker = document.createTreeWalker(containerNode,
        NodeFilter.SHOW_COMMENT, null, false);
    var comments = [];
    while (treeWalker.nextNode()) {
        comments.push(treeWalker.currentNode);
    }
    return comments;
} 

console.log(getCommentNodes(document.body));

• This will reduce parsing time. (We only have to find markers in simple format)
• Content will show as page is loaded

So, my question is this doable on Vue side? If it is, I can start implementing this on Slm side.

More examples:

<ul id="demo">
    <li v-repeat="items" class="item-{{$index}}">
        {{$index}} - {{parentMsg}} {{childMsg}}
    </li>
</ul>

ul#demo
  li v-repeat=this.items class="item-${$index}"
    . ${$index} - ${parentMsg} ${childMsg}

or

ul#slim
  - vRepeat(this.items)
    li class="item-${$index}"
      . ${$index} - ${parentMsg} ${childMsg}

<span v-text="message | capitalize | reverse"></span>

span v-text=filter(this.message, "capitalize", "reverse")

[yyx990803]

This is an interesting idea, but here's my thoughts:

• This would only work for text bindings, right? So Vue still has to walk the whole tree for other directives.
• Text parsing is actually a relatively cheap part of the Vue's rendering procedure.
• Ideally, I'd want to reuse the same template on both server and client.

But the concept of marking bindings with comment nodes is definitely an idea worth exploring.

[yury]

This would only work for text bindings, right? So Vue still has to walk the whole tree for other directives.

No. I provide simple example with text binding just to illustrate the idea. It can be more complex, like ifs, repeats, even components are possible. Yes, we can't do DOM operations, server side bindings should work with html ast. But if binding require DOM, it can be delayed and processed on client. The main idea is to try to produce full, valid (in terms of content) html, and then attach bindings and provide dynamic behavior.

I didn't research Vue internals yet, so I don’t know what bindings are complex, but if you give me an example I could try to illustrate how this binding could work.

Text parsing is actually a relatively cheap part of the Vue's rendering procedure.

And what about constructing dom? What is the slow part right now?

Ideally, I'd want to reuse the same template on both server and client.

Slm can compile template to functions that require small runtime helpers (for escaping and attributes merging) about 1.5kb unzipped. So, yes. Templates can be reused on server and client.

Also, Slm is quite small by itself 29kb unzipped. So it can compile templates on client side too (not yet, i'm working on that :)

[ayamflow]

Bumping here,
I was told of cheerio, a nodejs jQuery allowing to render DOM 8x faster than JSDOM (at least that's what they said). @fullfs might want to give this a try with your previous setup to compare ?

[fullfs]

Good point @ayamflow. But 8x times faster is still not enough...
Another thing is cheerio won't help in launching Vue.js. Cheerio is a module that allows to work with html stored as string as if it were real dom using jQuery syntax. In other word, cheerio works with plain text, no dom emulation. But with Vue.js in current state we can't work with just plain text. We need dom.

By the way I've gone a little crazy and developed decent server rendering module for Vue.js... it uses some Vue.js modules (like text parsing and expression parsing) and copies almost all Vue.js behavior excluding events, dynamic things, etc. It's even stable and fast. Only thing the quality of it's code is poor and I'm afraid it won't be any help to @yyx990803 in the end. Though maybe it could be interesting as concept.

[yyx990803]

@fullfs wow, that still sounds pretty cool though. How are you picking up the pre-rendered content on the front end?

[fullfs]

@yyx990803 I'm just not :D I mean I just re-render it on the client. For example, ractive.js do it the same way. And it's not event blinking, you know.
The only flaw shows itself with things like flash-banners if we render them twice.

Back to picking up, I imagine the process to go like that:

1. we get html from server
2. we get raw templates from somewhere and initialize Vue.js with those
3. Vue renders dom tree, but won't append it in document for a while (creates hidden dom tree)
4. Vue starts matching present (visible) nodes with nodes from hidden dom tree, searching for equal elements, changing binding from hidden nodes to visible nodes.
   Note, that the process requires equal html rendering result from every side.

With this method we still need to render it twice, plus time for matching and re-linking.

Did you take a look at derby.js? It uses some interesting mechanism for html picking up. Broadly speaking, it sets IDs at nodes with some unique value like "hf65h-76gfh-df545f-h65gh" or so, than it sends some map as embedded JSON containing those IDs with some marks. Probably it re-renders dom in shadows too.

P.S. Ok, I probably should tell you... right know my team is working on a new project where we wanted to use some kind of full-stack framework to have both-sides rendering with isomorphic ideology (sharing same templates and code on both server and client). It's a long story about why we decided to go this way (ok, main thing is Vue.js is really good). So far we developed a framework prototype based on Vue.js with both-sides rendering. Don't know if we could share forces or something, but at least we could provide you with some feedback. Also we having some troubles with the development due several Vue's features and we would like to make some suggestions for enhancements from full-stack approach point of view.

[yyx990803]

Interesting... blowing everything away isn't ideal, but if it's working for you then maybe it's good enough.

Would love to hear any feedback I can get - you can shoot me an email (it's in my profile)

[fullfs]

I don't think it's the best way either.
Anyway i can't manage to do any better without some serious Vue modifications while I wanted to leave Vue in its original state.

Talking about right way to do it I can make some notes:

• we need some kind of template pre-compilation. A function to convert raw html to tokens we could send from server to client to make first initialization faster (handlebars or ractive has something similar)
• if we don't want to spend time rendering nodes twice we need some other way. But we still need some kind of map of fully compiled Vue instance to match html againt. There we could use pre-compiled templates to make the map without creating real dom nodes (it should be faster, right?)
• next we could make the matching where Vue would pick up html from server as its own nodes without need to create new ones and replacing existing.

What do you think about it?

P.S. actually I'm not sure you're motivated to go through trouble making Vue work as full-stack technology. I mean i don't want to trouble you with the subject if it's not in your plans. Just imagined it would be great.

[yyx990803]

The limitation mainly comes from Vue's approach of DOM-based templating (same issue for Angular). Vue's compilation process relies on having the DOM, and leaves the string parsing to the browser. Basically it was not designed with isomorphic javascript in mind.

It could be made to work with

1. A separate string-based parser on the server which should leave "hints" in the rendered HTML
2. A plugin on the client side which helps Vue to pick up the "hints".

But yeah, these are non-trivial efforts and really not a priority for Vue. I'm ok leaving this space to frameworks designed specifically with isomorphism in mind (e.g. React)

[fullfs]

Ok, thanks for explaining. Will focus on developing my own crazy stuff for pseudo-Vue rendering then :D

[fullfs]

Recently we've made a pre-release of the project I'm working on where we use Vue.js and also my insane script that imitates Vue's behavior on server side - VueServer (we use one component code both on server and client).
And I'm glad to say its all working just fine!
There it is: http://novosibirsk.n1.ru/ (sorry its on russian, can't help you there...). You could press some buttons or so... :) Also, check it out with javascript disabled to see server-side html.

P.S. @yyx990803 thanks so much for your Vue.js! It's like it made me fall in love with frontend development once again :)