Feature request: Server side rendering #486
Replies: 5 comments
-
|
@Immortalin I'm definitely open to this since it would help to address questions like this. However, for the moment I'm both under informed on the topic and over committed to other work. Unless I can find some help on this one, I'll have to finish up what I've already promised to do with IDOM (as well as fix bugs) and then educated myself about Gatsby/Next.js. Perhaps an intermediate solution to loading times would be to figure out some clever compression techniques to reduce the dependence on network latency? |
Beta Was this translation helpful? Give feedback.
-
The simplest SSR method would involve rendering any new DOM components as a HTML string and pushing them into the |
Beta Was this translation helpful? Give feedback.
-
|
@rmorshea Might be worth moving all feature requests to GH Discussions so people can vote on them. |
Beta Was this translation helpful? Give feedback.
-
|
@rmorshea Should manually remove this from the 0.33 release notes. Although technically the ticket was closed, having it on the changelog it makes it look like SSR capabilities were completed. |
Beta Was this translation helpful? Give feedback.
-
|
This feature will be discussed in #578 |
Beta Was this translation helpful? Give feedback.
-
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when the page takes time to load, especially when the widgets are big.
Describe the solution you'd like
Server side rendering like those used by Gatsby and Next.js.
Describe alternatives you've considered
N/A
Additional context
Rehydrating the websocket connection will probably require custom code. SSR will most likely need node.js as a dependency.
Beta Was this translation helpful? Give feedback.
All reactions