render on server

[yoshuawuyts]

From #1 cc/ @ahdinosaur

as for your question about how to use this on the server, is there a specific use case you have in mind? i can't imagine another way other than providing a minimal DOM implementation in node, such as through jsdom or min-document, neither of which currently support custom elements as far as i'm aware.

Yeah, I've been playing around with min-document and jsdom today; but feel neither works well for webcomponents. If anything they would need to be either included by the custom-element or injected in a way; neither of which is pleasant.

Right now I'm thinking of adding a .toString() method to custom-elements for server-side rendering (See Also: vel, base-element). I reckon it should be able to take the same data as .on('render').

Actually all of this is starting to make me question whether or not custom-elements are the right abstraction; perhaps the correct approach would be to render the other way around; virtual-dom -> custom-element if need be. All that needs to happen then is create init, update and remove events + render (for server) and we're set. Figure this would make for a cleaner abstraction.

It's kind of a rough realization to make that custom elements cannot possibly be rendered cleanly on the server. I feel this means we're forever stuck using frameworks, right?

Does this make sense?

[ahdinosaur]

what you're saying makes sense.

my own feeling is still that web standard APIs are no less framework-y than module APIs, in fact i usually find specification committees write worse APIs than do module authors. so yeah, i agree that virtual-dom is preferable to custom elements. in general i prefer to use abstractions i really vibe with and then seek compatibility with web standards later, never the other way around.

with that in mind, maybe even virtual-dom isn't the best abstraction. for example recently i found vdux which implements a virtual dom on top of the abstractions in redux (action creators, reducers, middleware), and uses virtex-dom for dom rendering and virtex-string for server-side rendering. that is to say, i think you should feel free to experiment with new abstractions! :boom:

[yoshuawuyts]

hm, virtex looks pretty much the same as mercury except using a different state / event engine. But I fully agree with you; going to publish this repo with a big fat warning that all of this is a bad idea. Thanks!

[ahdinosaur]

a big fat warning that all of this is a bad idea

well as far as providing a compatibility bridge to use custom elements within virtual-dom, if there isn't a need for server-side rendering, i think this is still a useful module.

[yoshuawuyts]

what you say is true; but I feel that SSR is becoming more of a hard requirement these days. Not in the traditional sense (e.g. facebook style load data + render all the things) but closer to pre-rendering templates for a good first-render pass, that can later be filled with actual data. Though it might be slightly uncommon in the wild atm, I'm concerned that if people adopt custom elements they'll end up shooting themselves in the foot down the road.

Hopefully putting a giant warning sign up will make people at least think about the matter (': (or something like that)

[dominictarr]

interesting. I was just chatting about this with mikey on the cyphernet, and he linked me to this thread. I should admit I'm a react skeptic - not that I think it's a bad idea - I think react/etc is a great idea - but it's a not a golden hammer.

perhaps the correct approach would be to render the other way around; virtual-dom -> custom-element if need be.

yes this is what my intuitions tell me. custom-elements should be for when you have a really clearly defined problem that is not coupled to any particular app. html is for just rendering some content. you are never gonna reuse your html, infact there is a bunch of different ways you could do it even in this app.

I wrote about this recently on a patchwork thread "the IKEA architecture"

%5U+7Fblfzf1iO+bE+anI/wn/L9L0LkpM5A9+Mlf0Wcc=.sha256

(I hate to give a cold link like this... we gotta get a web gateway for this thing...)

[yoshuawuyts]

FWIW I've given up on webcomponents completely - even more than that: I actively warn people against using them.

The more I've used webcomponents, the more I've found that in reality the truth of my application is not HTML, but always, always, always JS. Custom elements require a mad amount of hoop jumping to get anywhere, and the moment you want to use it in Node it all comes toppling down. Also worth keeping in mind that custom elements don't work unless you're registering them through JS beforehand anyway.

For me the only benefit they provide is to backport browser features to older browsers / give spec people a way to toy before implementing. Same goes for CSS' houdini despite the browser marketing machine positioning it differently. Ah well.

Instead of custom elements I think something like yo-yo does a better job. It's HTML syntax that we then transform into something more useful, bridging the gap between web tech everyone knows and grouping of functionality. yo-fs does a good job at showing how to use it for widgets.

---

I think react/etc is a great idea - but it's a not a golden hammer.

What do you mean by that? I'm curious about your critique

[dominictarr]

@yoshuawuyts a very simple example of something that react doesn't really suit is infinite scroll - you are basically mostly appending but not always and you are doing that when the user scrolls down etc. It has some state (quite a bit) bit it's not what your app is about. React's diffing model means that append is O(n) instead of O(1)... It's like, your car has loads of state, but the only thing that matters to the passangers is what their destination and current location is.

@ahdinosaur told me about the benefits of separating state so that you can have good things like linkability and history. The benefits of immutable programming. I countered there are usually things you don't want to be linkable or have history, but you do need to display, like, connection status, or your friend's online status, or probably, where your scroll bar is at, a rich text editor...

That stuff is very important, but it's like your engine. A user doesn't care about that, except when it doesn't work. What is user cares about is the data that is about them. This is what react is good at.

[dominictarr]

Golden Hammer = special hammer that works with every sort of nail

[yoshuawuyts]

Hmm, yeah but then all that's needed is a way to opt out of the diff algorithm in order to optimize and get O(1) - good one. Would still use bel for that tho; still feels neater than custom els

[dominictarr]

@yoshuawuyts hang on, can you describe what sort of components you where making as custom-elements... and now that I take a second to imagine what a custom element on the server is... my mind boggles.

[yoshuawuyts]

So custom elements are nothing but good ol' existing elements but mashed together. For example x-gif is an <img> element that can control the speed of gifs. This happens to map well to a single component, so rendering on the server using <img is="x-gif"></img> should work well, but more complex custom elements break down with that analogy.

Using JS means everything is rendered the same everywhere because it's just a function call and we can circumvent any odd DOM dynamics. Does that make sense?

[dominictarr]

@yoshuawuyts you answered the opposite of my question. I can see that x-gif would work naturally as a custom element... but what sort of elements where you building? (where the "analogy broke down")

[yoshuawuyts]

For example a tabular data widget has nested tags and can thus not be rendered on the server. Or am I mistaken here?

[dominictarr]

Hmm, so I would have thought that the right way to render a custom-element on the server would just be to return <x-gif...> and insert the appropiate javascript into the document also. But it's starting to sound like you are returning the tags that the custom-element are made from?

[yoshuawuyts]

But it's starting to sound like you are returning the tags that the custom-element are made from?

Yup, I want to have the option to. Sometimes that's exactly what you want, sometimes not (e.g. app vs site). Custom elements take that option away all together so instead I prefer to use functions.

[dominictarr]

riiiight. can you describethe of the sort of thing that you are creating with functions?

[yoshuawuyts]

Discussion kinda died down; closing!