Hi Kenny, great to see you here! And hello Sergio!
My understanding of next.js is that it handles SSR and React routing. I think this is different than what I have in mind, which is essentially static-site-generation (but not to final HTML output, but to templated views for MVC).
The conceptual difference is this: SSR is still rendering the output HTML in real time (only in server side code, instead of client side). It still takes server resource to do this on-demand. SSG (static site generation) is sort of what the JAM stack is about -- you pregenerate HTML from your React/Vue/Svelte frontend components, and it simply lives as static HTML files on the web server (and in the case of JAM, they talk to an API server afterwards). In the case of what I propose, they are rendered as templated views, where an MVC framework could just call render(pagename, variables); at the end of a controller to render the view.
Perhaps I would need to run some benchmark to know if there's actually significant performance improvements to gain at all. Like I said, I spent no more time than what it took to write down the thoughts, to think about it, so more work is warranted. :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Kenny, great to see you here! And hello Sergio!
My understanding of next.js is that it handles SSR and React routing. I think this is different than what I have in mind, which is essentially static-site-generation (but not to final HTML output, but to templated views for MVC).
The conceptual difference is this: SSR is still rendering the output HTML in real time (only in server side code, instead of client side). It still takes server resource to do this on-demand. SSG (static site generation) is sort of what the JAM stack is about -- you pregenerate HTML from your React/Vue/Svelte frontend components, and it simply lives as static HTML files on the web server (and in the case of JAM, they talk to an API server afterwards). In the case of what I propose, they are rendered as templated views, where an MVC framework could just call
render(pagename, variables);at the end of a controller to render the view.Perhaps I would need to run some benchmark to know if there's actually significant performance improvements to gain at all. Like I said, I spent no more time than what it took to write down the thoughts, to think about it, so more work is warranted. :)