I'd really like to see this too. Most of what I've seen is something like "use node.js on the server and make use of the framework's server-side rendering capabilities". For me that's a problem, because I don't want and can't use node.js on the server.
These javascript frameworks ultimately produce, at the end of the first page load, a DOM structure with event hooks attached. The DOM structure could be 100% created using html markup from the server, so if the framework provided a way to just hook up the events and then manage the DOM from that point on, you'd get the best of both worlds. It's possible to do this with native javascript jQuery by putting either classes or data attributes in the markup to indicate where the hooks go and then running an init method to find them. Bootstrap components work this way, for example. One of the earlier SPA frameworks, Knockout, worked this way too.
I wonder if you could get a build tool to dig in to the redux default state and compile the thing to index.html. Then you could use whatever you want for the backend.
That's basically the pattern my company is already using, implementing using our own plugin. We render the full page server-side (using ASP.Net MVC, which is hooked into our server-side Enterprise Application Framework), and then we hook up javascript handlers to manage client-side events. Those handlers can make AJAX requests for content updates, which we deliver either as pure data or server-side rendered html (which are rendered using the same partial templates that the initial page used.)
Depending on the page, we can go anywhere from old-school full-page-refresh to a complete single-page-app design. Mostly we do Enterprise back-office interfaces and customer web portals, both of which tend to have a lot of data grids. So a very common feature of our applications is a data grid that supports paging-in-place, along with server-side filtering and sorting of large datasets. So we'll do that SPA-like, even if the overall site is more of an old-school design where each link loads a new page.
Our plugin does more than just fetch a url; the client side and server side are designed to work together to allow standard options to be passed up to the server along with the request, standardized error handling and content in the response, and standardized ways of handling the response when it gets back client-side.
Comments
I'd really like to see this too. Most of what I've seen is something like "use node.js on the server and make use of the framework's server-side rendering capabilities". For me that's a problem, because I don't want and can't use node.js on the server.
These javascript frameworks ultimately produce, at the end of the first page load, a DOM structure with event hooks attached. The DOM structure could be 100% created using html markup from the server, so if the framework provided a way to just hook up the events and then manage the DOM from that point on, you'd get the best of both worlds. It's possible to do this with native javascript jQuery by putting either classes or data attributes in the markup to indicate where the hooks go and then running an init method to find them. Bootstrap components work this way, for example. One of the earlier SPA frameworks, Knockout, worked this way too.
I wonder if you could get a build tool to dig in to the redux default state and compile the thing to index.html. Then you could use whatever you want for the backend.
I don't understand, you want a javascript framework to do server-side rendering, but don't want to use node?
Sounds like he wants to the server-side rendering with whatever tech he is using now, and then have the client-side JS code take over.
No, I want to do server-side rendering using whatever I want, and have the js framework take over once it is clientside.
That's easy with both React and Angular.
Please please please look at jQuery-Pjax. It does exactly this. If you have any questions about it, feel free to ask!
That's basically the pattern my company is already using, implementing using our own plugin. We render the full page server-side (using ASP.Net MVC, which is hooked into our server-side Enterprise Application Framework), and then we hook up javascript handlers to manage client-side events. Those handlers can make AJAX requests for content updates, which we deliver either as pure data or server-side rendered html (which are rendered using the same partial templates that the initial page used.)
Depending on the page, we can go anywhere from old-school full-page-refresh to a complete single-page-app design. Mostly we do Enterprise back-office interfaces and customer web portals, both of which tend to have a lot of data grids. So a very common feature of our applications is a data grid that supports paging-in-place, along with server-side filtering and sorting of large datasets. So we'll do that SPA-like, even if the overall site is more of an old-school design where each link loads a new page.
Our plugin does more than just fetch a url; the client side and server side are designed to work together to allow standard options to be passed up to the server along with the request, standardized error handling and content in the response, and standardized ways of handling the response when it gets back client-side.
Nice, I work on similar sorts of projects, but I run a Python shop :)