Re:ReactJS in Java Hello World
by tracker1 on Tuesday December 09, 2014 @12:45PM
(#8724251)
But it isn't just the data and templates... Server-side rendering for an initial view puts the initially rendered data request(s) closer to the database(s). Not to mention the amount of JS that has to cross the wire and get parsed. It depends on your needs.
If you need to be able to have a user jump into any given page from a search engine result, it matters even more. Initial page rendering is paramount. Depending on your usage a fairly simple flux application (flux, react, templates => broserify) will yield out a 500kb JS payload pretty easily. Which in the scheme of things really isn't too bad.. but it's a lot more than, say 30k of HTML for the initial render... not to mention parsing time and display of additional resources (images).
I try to avoid images (save for logo) in the shell/design of a site. favoring CSS tricks and even multiple layers. It was done a while ago, but there are relatively few images on photogallery.classiccars.com (other than the gallery images) for example. It was pretty much my first SPA that needed to be search engine accessible about 3 years ago.
Today I'm working on a flux application that will share server/client logic using Yahoo's tooling as a base. It isn't really much easier in the end than progressive enhancement over HTML delivery. Where it does help is allowing for the same code client and server, and a lot of conditionals for optimal rendering for browser or mobile (minimal useragent detection). Initial renders for mobile devices are very light. Some reactive design (bootstrap base) catches the rougher edges. And progressive enhancement takes the rest.
What this allows for is a very nice initial rendering system that is highly cache-friendly. That output caching is what can allow a site to scale to a much larger load. Caching reverse-proxy servers can ease the stress on back-end servers. Client-side enhancement allows for logged in users to get the whole picture while still working for others.
Being able to share a single framework is a huge boost. Not trying to manage a server-side only rendering system... bolting on client-side templating beyond that is really nice. I agree that it isn't simpler overall... but will argue that it is easier to maintain, especially when you aren't context switching for server/client tooling.
If you need to be able to have a user jump into any given page from a search engine result, it matters even more. Initial page rendering is paramount. Depending on your usage a fairly simple flux application (flux, react, templates => broserify) will yield out a 500kb JS payload pretty easily. Which in the scheme of things really isn't too bad.. but it's a lot more than, say 30k of HTML for the initial render... not to mention parsing time and display of additional resources (images).
I try to avoid images (save for logo) in the shell/design of a site. favoring CSS tricks and even multiple layers. It was done a while ago, but there are relatively few images on photogallery.classiccars.com (other than the gallery images) for example. It was pretty much my first SPA that needed to be search engine accessible about 3 years ago.
Today I'm working on a flux application that will share server/client logic using Yahoo's tooling as a base. It isn't really much easier in the end than progressive enhancement over HTML delivery. Where it does help is allowing for the same code client and server, and a lot of conditionals for optimal rendering for browser or mobile (minimal useragent detection). Initial renders for mobile devices are very light. Some reactive design (bootstrap base) catches the rougher edges. And progressive enhancement takes the rest.
What this allows for is a very nice initial rendering system that is highly cache-friendly. That output caching is what can allow a site to scale to a much larger load. Caching reverse-proxy servers can ease the stress on back-end servers. Client-side enhancement allows for logged in users to get the whole picture while still working for others.
Being able to share a single framework is a huge boost. Not trying to manage a server-side only rendering system... bolting on client-side templating beyond that is really nice. I agree that it isn't simpler overall... but will argue that it is easier to maintain, especially when you aren't context switching for server/client tooling.