-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Server Side Render Support #62
Comments
Entirely planned someday, but bucklescript keeps changing so it needs to be designed carefully to handle that... ^.^; |
WIth code splitting and SSR. We can get "Elm 0.19" |
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. |
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 |
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... |
I understand this as they hide everything in shadow dom. See also SSR Web Components (Polymer Summit 2017) |
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 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 |
It can be cool that Bucklescript support SSR, this can help to improve the user experience and is helpfull for SEO
The text was updated successfully, but these errors were encountered: