(In other news, I would desperately like some free time)
Seconded. It makes hosting a breeze; especially when you can just throw it on GitHub Pages within minutes. I also like being dependent on only a text editor and a browser ... a combo still performant on just about any device from the last 20 years if not longer. No need to install full-featured IDEs and the various dependencies.
What security risks are removed by using a client side app instead of a server side one?
developers who only know how to write fat JS frontends
Nearly every web app is now two apps, and it's increasingly infeasible for any developer to have a mastery of both backend and frontend stacks.
Not necessarily a terrible problem when you have dozens of developers, but a lot of dev teams are 1-3 people. Instead of web dev circa 2010 where you might reasonably have a 3-person team of people who can each individually work anywhere in the stack, now your already-small team is bifurcated.
In many ways this is an inevitable price of progress... 100 years ago you had one doctor in town and they could understand some reasonable percentage of the day's medical knowledge. Today, we can work medical miracles, but it requires extreme specialization.
At least in the development industry, we can choose not to pay that price when it's not necessary.
The front/back divide also existed back then, with barely any possibility of a front person ever touching the back-end (a possibility that exists nowadays, without going into its merits or demerits).
For a reasonably ambitious and industrious individual nowadays it’s not unreasonable to become really good at one client and one server technology. There’s more to it than writing server-side code with HTML templating for presentation, for sure, but it remains well within the grasp of many people.
There was not "frontend" and "backend" developers. There were designers and developers. Designers created designs. They were usually delivered as PDFs, because the bulk of them came from print design backgrounds.
Their designs were then implemented by developers. Senior level developers tended to more of the application level heavy lifting (server-side scripting & db), with junior level developers working on converting designs to html, then to templates. By the time a junior developer moved on to app code, they were well versed and had mastered HTML and all the weird edge cases. They knew HTML.
The first real wave of "frontend" and "backend" developers came on the scene when you had designers learn Flash. They started driving more complex applications and there was a more bifurcation.
Granted even in small teams of the era, you had developers prefer "front" or "back". We tended to value "A jack of all trades is a master of none, but oftentimes better than a master of one"
Because the stack in the old days was smaller and level of quality was far lower. In the '90s there was no css and javascript, nor did anyone care for accesability, multiple languages, security or interactive features. In the old days we had real documents with links and simple structure, not apps and mature frameworks. It was something on the level you get today with simple markup like markdown or org-mode.
In any case, discussions around front end frameworks and especially React are scarcely any better here. Although they are usually politer at least.
This isn't true, Twitter is a place where a large percentage of Twitter users who are interested in web development talk about it.
Twitter is not a lens on the entire internet, it is a lens on a bubble of a bubble.
Source?
I left this part of the business space for the browser business at this time, but I assumed that the server-side rendering stuff would keep evolving. It didn't.
Then the "PHP CMS" wave came, and dumbed everything down.
Then the "reduce the server to an API" and "let insanely complex javascript frameworks/apps deal re-invent the browser navigation model" came... and here we are.
Are you creating a complex webapp? Use React. Go nuts! But are you making a mostly static page (blog, marketing site, whatever)? Then don't use React. It adds entirely unnecessary bloat and complication.
- Code sharing - how do you share reusable snippets of code that includes both the SSR logic and the JS that is also required on the frontend. React’s component model is fantastic where a team can develop a component independently
- Skill set - getting 50 React developers to write HTML and JS should be fine if other problems were solved, but often the suggested solution is obscure things like Elm or Elixir
- Even if most of what a company builds is static marketing content, other parts can be more app-like and having developers be able to share code and use the same basic technology is a great productivity booster
Kinda is. It makes my mobile work harder and thus uses more battery.
I recommend React when making an app, web or otherwise.
I recommend vanilla HTML + CSS with optional JS when making a website.
There are many use cases for which a client-side framework like React is eesential.
But I feel the vast majority of use cases on the web would be better off with server-side rendering.
And...
There are issues of ethics here.
You are kidding yourself to an extent when you say that you are building a "client-side web app." It is essentially an application targeted at Google's application platform, Chromium. Sure, React (or whatever) runs on FF and Safari too. For now. Maybe not always. They are already second-class citizens on the web. They will probably be second-class citizens of your client-side app unless your team has the resources to devote equal time and resources to non-Chromium browsers. Unless you work in a large shop, you probably don't.
Server-side rendering is not always the right choice, but I also do see it as a hedge against Google's, well, hegemony.