bucklescript-tea
bucklescript-tea copied to clipboard
OvermindDL1
Server Side Render Support
It can be cool that Bucklescript support SSR, this can help to improve the user experience and is helpfull for SEO
Entirely planned someday, but bucklescript keeps changing so it needs to be designed carefully to handle that... ^.^;
Code splitting it usually more for client work rather than server work, but yeah that would potentially help reduce initial page load time when having a multitude of views. Unsure how much it gains though overall, it's already significantly smaller than something like Elm if using standard module packagers.
Server work will involve putting any bucklescript-specific stuff behind platform checks and filling out what to do for native, then you'd be able to just generate a standard vanilla native executable that you could feed input to (say perhaps a JSON format of things) and it'd generate the initial template, this would make it very easy to create a pool of such workers (though fast enough it may not be necessary) and feed it the page data to send back the generated page. May even be able to have it generate pages in other formats than HTML for inclusion into other templating systems too.
Unsure how much it gains though
It gains a lot upon codebase grows. If you take a look at https://hnpwa.com/ main tricks to make things faster are code splitting and SSR (I mean after HTTP2 and Link/Push).
Also this article https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/javascript-startup-optimization/
I tend to follow the styles of the webcomponents spec for my work, so I inherently get code splitting already, plus progressive enhancement (a thing I think most sites are sorely lacking...). :-)
But yeah, for more traditional SPA's it's useful.
There is a general issue with Web Components and SSR. Webcomponents use shadow DOM, which is not possible to express as HTML, so instead they render HTML and on client they erase HTML and create shadow dom. So basically they do not support hydration on client side. See also https://github.com/skatejs/skatejs/tree/master/packages/ssr
Webcomponents use shadow DOM, which is not possible to express as HTML, so instead they render HTML and on client they erase HTML and create shadow dom.
The shadow DOM should only represent things that should not be visible in the DOM in any case, things like ripple buttons in the Material spec for example, or a notifications panel that should be otherwise empty when not yet connected to the server, etc...
An important aspect of web components is encapsulation — being able to keep the markup structure, style, and behavior hidden and separate from other code on the page so that different parts do not clash, and the code can be kept nice and clean. -- https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM
I understand this as they hide everything in shadow dom. See also SSR Web Components (Polymer Summit 2017)
I understand this as they hide everything in shadow dom.
It all depends on use case. In general WebComponents using shadow DOM were originally designed to just let people make their own DOM Elements of the first-class nature as any of the others like input or video. However, just like those they are really supposed to be composible and designed in such a way that they fallback gracefully in browsers that do not support them. Sadly a lot of people use them in ways that do not degrade gracefully, but I consider that a fault of the ecosystem rather than the design of WebComponents The Spec.
In general I try to use them in ways in which they were originally designed, to 'enhance' content but not 'be' the content. The only times I use them in ways where they would not fallback 'gracefully' are things like the afore-mentioned Notifications list, where if it's not working then they don't have javascript anyway, so I definitely don't want to display something in that case, instead forcing them to go to the dedicated sections, it's all part of Progressive Enhancement.
/me still has to work in older (read: IE) browsers and text browsers (both for compliance reasons as well as for literally-just-having-a-terminal-with-no-GUI reasons, so progressive enhancement is a big draw