Interesting. What would you say are the main advantages over simply passing the data through a server side rendering library?

Not the grandparent, but it makes things a lot easier.

Basically, think of something as trivial as form validation. You need to do it both client and server-side regardless, but client side you might have additional complexity, like "if paying by credit card, show those fields, and if paying by PayPal, redirect." This means that your server might need to be aware of these branches of state that might happen, and it means complexity.

On the other hand, if you keep UI state to the UI layer on the client, the server side becomes super simple: you have an API that says something like "here are the shipping and billing details using a credit card. Charge it" or "shipping and billing details + PayPal token. Charge it." There is no "if we are rendering a PayPal processing error, re-render the entire state of the page, preserving all the checkboxes and showing the right bits of the DOM." It's just pure business logic.

Something like Vue is also much better geared at doing a UI than a server-side rendered template. It's dynamic by nature, and directly affects the DOM. The state is kept in such a way that it pertains to the UI. If you are processing something like a request to /orders?filter=recent&order=amount&page=3, you have to re-parse the state from the URL and then get the results every time. Vue/VueX will keep the state in a convenient fashion and the URL can be instructed to reflect it. No need to write custom code to interpret it.

Simple CRUD stuff is super easy with Vue + VueX + Bootstrap + Django. That's been my stack and I like it. Complicated stuff if much faster to develop using this than to try to use something like Django templates + jQuery.

Well, these are the general arguments for these frameworks. But how do they apply to the linked page? I used it for a while and did not come across a Credit Card vs Paypal form.

The linked page simply talks about Using a simpler compilation toolchain than the Vue standard one (Webpack), at the cost of it supporting fewer features. It's sort of like the argument of using clang vs GCC: it assumes you already are using C for your project, just talking about which compiler. Actually a better example would be autotools vs CMake.

In my opinion, client-side rendering is here as a justification for the unfortunate splitting of the Fullstack developer into Frontend/Backend roles.

Frontend developer used to be a designer who also knew HTML/CSS but the problem with that is that in order to do CSS well, you need to be a programmer. Especially if you're trying to achieve effects that work best as a mix of JS/CSS. Unfortunately, when it comes to design, UX and UI, most developers are lazy and refuse to learn the basics of it. So in order to prevent PMs from assigning them design-related tasks, the role of Frontend developer was born.

And once there was a separate role, it only made sense to isolate the Frontend developers' environment from the backend developers' so that they could stop stepping on each others toes.

Essentially, the whole Single Page Application architecture is because there is a class of developers who imagine that it's sensible to completely ignore design considerations and who built a moat around their responsibilities in the form of an unnecessary abstraction. Now rather than our views having direct access to our databases, we need a separate API endpoint for every single database call and since we can't trust client code, we need to authorize/authenticate every single little action rather than being able to blindly trust the code that's being run like we used to.

Boy I don't mess the days of dealing with SQL queries inside of PHP "view" files. Reminiscing aside, you can build server-side applications in both Vue and React.

I'm not advocating for SQL in views. MVC and ORM are great. As is free auth and form generation from database models. I haven't seen a framework that gives me everything that Django or Laravel does for free.

You are _completely_ missing the point of frontend applications, here's a few to get you started:

- Ease of creating complex user flows.

- Decentralization of application work: app runs on client, less CPU cycles for my server!

- Separation of concerns: API does one thing, client application does another, there is a bright red line between the two.

You can build complex user flows with JavaScript on top of server rendered views. Ajax works great with server side rendering, see Pjax https://github.com/defunkt/jquery-pjax or Intercooler http://intercoolerjs.org/

The server is rendering JSON anyway, more or less just as expensive to serve HTML. Besides, the bottleneck is usually database access.

It's a false separation and forces you to expose far more than necessary. It's nice to have my full database available on every page render without needing to define explicit endpoints.

I also like having forms generated from database models.

You don't have to render stuff on the server?

I never felt any pain that my servers do rendering. Did you encounter any problems with it?