To this day, even after going through react tutorials, I still feel like it so much more overhead than what is needed compared to using a good templating engine like jinja. I can easily make components and in one file inject css and js that is only used on that component.
Plus, most times the templates are cached. So with very little css/js to load it's really fast. Basically like a static site.
But, data binding. Ok, so there's some is on the page that can change some elements. You can still make an Ajax request to some endpoint to get a json response and update the UI. Even faster with a websocket to subscribe to an endpoint. You still don't need react/Vue for that.
Another upside, is libraries getting out of date. No need to update your react version when a new one comes out. Less headache, no overhead. Sure there will be something if you're using is for Ajax requests, but that's likely an easier upgrade anyways.
I forget any other reason server site template rendering was just easier?
Note 1: My goal here is to have a conversation about this. I am trying to learn better for both sides of the argument.
Note 2: I do want to be fair in saying that I understand the desire for this for a rich interactive application interface that has a lot more moving parts that don't need to communicate with a back end. Such as where you would build an offline application
Top comments (10)
Maybe worse performance on first render, but I am not sure if it is harder. With
console.log, client-side rendering might be easier to debug.Also, JavaScript might be as powerful as templating engine language, while being more familiar (and easier to debug in case of client side.)
About pre-rendering, it should be done to improve performance. That's why prerender-spa-plugin and Nuxt were born.
Beyond the first render, reactive component libraries syncs better with JavaScript than templating engine (where JavaScript's
querySelectorhas to be used.)I think we should assume equal knowledge of front end and back end language here. And I am not saying server side rendering isn't fast once rendered after the first load.
But my point is, that's after the first load. Server side templating doesn't have that issue. But now you have the complexity of a framework like react being in your application.
Even if the backend is node and using say nunjucks or something for templating. The same for python/jinja. There's often significantly less overhead and way less bytes to download.
The benefit of server side templating engines, is that there's not really much in them to debug. You can still use the inspector to debug it some. But using a debugger you can step through your templates as well, just like debugging react.
Actually, template engine is usually not about backend language, but rather a DSL of the template engine language...
For some reasons, template engine DSL is much more popular than simply string interpolation, or
lit-html, for example, for the backend.Also, what is usually slow, is the communication between frontend and backend.
front to backend takes time yes. But what takes more, an html template, or react + components. And react/vue/angular/etc do take more bandwidth on the first load. Granted yes that is only once. This part I think is the minor part of the issue at hand. What is more complex, the html templating, or react with components.
Granted I am still learning react, most templating on the server side is dead simple. React and others are way more complex.
My point, is that all that complexity to me, so far, is for nothing. when templating is way simpler and using react adds the complexity and much more code to debug, test, integrate, etc. And the more thing that can break.
You can render React and Vue sites server-side if you want, or even pre-render them and serve them over a CDN.
To me this is worse. There's already complexity over using normal server side temolatea. Now your adding a later to render html output from JavaScript (jsx) to then load to the browser.
The less layers you have to break means the less code you have to break.
Not really. There are already tools that do it for you, like
vue-server-side-rendererandprerender-spa-plugin. You donβt even have to set them up yourself. Runnpx create-nuxt-app <name>, answer a few questions, and you can have a full Vue SPA that can be served statically, supports server-side rendering, and has both a component library/CSS framework and server framework set up for you. If thatβs not easy to do, nothing else is.Yes, I know it's not hard to get it pre-rendered. But it is another step, however minor.
My main argument, is that now you have a whole front end layer of react/vue/angular/whatever which is a lot of added complexity that you need to build, test, integrate, and so on. It is easier to have that break than a simple template.
To me, that added complexity isn't worth it. Even in django/flask and im sure others like rails, you can have it generate a static site when you run the server and have it be seamless too. But theres no cognitive overhead of having to worry about a frontend framework which so far in my experience is way harder to learn than simple templating.
Well, I invite you to go try it.
I'm not sure I'd go that far even. I'd stop at "interactive application interface". Even communicating with the backend this client approach can still be preferable. To me it comes down to something should be keeping track of user state. Hopefully it's not the server as that scales worse. Complexity of client apps comes in that they manage state and transitions. When you go to the next page they still remember everything since you didn't reload the whole page. Sure you can encode information back and forth on request/url but that can get ugly quick. So you can regularly be communicating with the server and still have this persistence beneficial. Not to mention if you are serving multiple clients(mobile, different products) anyway it's possible a JSON API is more re-usable than an HTML one.
So while it matters very little if your backend is writing JSON or HTML for performance, it makes all the difference for what the client does with it. Now it's possible to use AJAX to insert server-rendered HTML but at the point these updates are distributed it's no more beneficial than client rendering. In fact the client could do more granular change with data in the right format. If the JS is loaded(cached) for updates the client rendering after initial load is just better.
So really the main argument for server templates is initial load. I'm not going to deny the solution here is not complicated. Classic server rendering is just insufficient for many scenarios. So we instead attack the issue of client rendering on the server, and have been researching improvements to JS code splitting, client rehydration and streaming async on initial request to overcome the classic shortcomings here.