I would say the app I work on falls into the need for SPA, so I naturally love React. Hooks are where I actually jumped to React, from Marionette / Backbone and it's been love for me ever since. I don't do CSS in JS stuff, I stick to Tailwind for my needs there, so I guess we're in agreement on that.

But I'm so crazy fast in React + Tailwind that I really don't understand the frustration. Combined with Typescript, coding is just a joy for me these days.

Maybe I'm happy because I'm not jumping to each new framework trying to micro improve things, but honestly I'm not sure.

Coding the frontend in 2023 compared to 2013 feels like a piece of cake.

Do you use next.js as well or just client side react?

I worked on an enterprise stack that started as ASP.net web forms, with C# used instead of PHP (this is not a C# vs PHP debate, the core problems exist no matter what backend form stack you use). The app was created in early 00s and by the early 10s, it was hundreds of pages. While everyone thought our application was mostly a C# app, by 2013 or so, we actually had more lines of JS than C#. Every time a dev needed to add some dynamic behavior to the site, they would import Jquery, or Jquery UI, add a plugin or few, add some inline JS on a CSHTML file, add a css file, etc etc. Eventually the entropy of that sort of thinking, of treating JS as a second class after thought, as like something you can casually inject or bang out on a per page basis, cost us a great deal on product momentum, refactoring, modernization, mobile compatibility, and more.

Facebook itself is a PHP app. React was invented to solve similar problems for Facebook.

If you're building a basic form app and you're able to make a business out of it in 2023, by all means, use some Jquery, a dead simple form UI and go to town. But if that app starts to evolve beyond a few screens or if more dynamic behavior is required, you owe it to yourself and your team to use a proper JS framework and toolset.

> you owe it to yourself and your team to use a proper JS framework and toolset.

In 2023 JS is no longer necessary, for instance, Blazor also works fine, and works great for small teams building just LOB apps.

Blazor Server and WASM both have issues that make them non-starters for me, namely latency quickly gets out of hand for the former and the latter is far too heavy. The (unfortunate?) reality is that Javascript is unavoidable if you want good bundle sizes and client-side interactivity.

I find HTMX is a better alternative if I'm trying to write as little JS as possible, I find it smooths over the latency issue better and just lets me write normal web app code that feels like a SPA to use.

Hi, do you have an open source repo of something you've built in Blazor? Would love to check it out. While it sounds interesting, there are still numerous limitations to wasm. There's no garbage collection, I'm curious how large Blazor apps are at scale on larger code bases, I'm also curious how well that works with either a PHP or Ruby stack, for example, and how easy you find it to integrate with other frameworks outside of the Microsoft stack?

I'm not sure you understand what React Server Components are if you think server-side web forms with only the necessary client-side JS is in opposition of it instead of being exactly what it's about.

> I'm not sure you understand what React Server Components are

Not in depth, but that's kind of my point. I don't really need to anymore.

You never “need to” learn much of anything, but I think it would give you a different perspective. You don’t know what you don’t know.

I generally agree with your overall philosophy. But I have one disagreement. String interpolation is subject to XSS, when used to generate HTML. Yes, it's possible to sanitize and escape, but you have to remember to do it every time.

You don't even have to write document.getElementById as all html ID`s are global variables.

Wot! That is insane. But what if the id you want is a value in a string?

window[myElementsId]

That didn’t work in chrome console for me

The point of using frameworks is to take advantage of complex code written by others that’s also well tested. This makes implementing common tasks faster, simpler, and less error prone.

I have a webpage for my wife that has one form to submit they sends an email to her. I used plain JS. It took longer than I thought to implement because I had to reinvent the wheel, so to speak. I had to write everything from scratch.

For a business where the website is changing frequently with many developers, being able to leverage a plethora of existing code and solutions is very helpful.

Heck, even for people writing plain JS, I bet you find yourself writing helper functions and small libraries to DRY you code and make common things easier. Framework invented!

> If you are struggling and want a no-bullshit stack, why not PHP or string interpolation in your favorite language?

Found the guy responsible for the shitty local government websites leaking data left and right.

This is fine advice for a personal project, but I don’t recommend proliferating a new custom framework if you expect other people to join and ramp up on your codebase. It’s nice to be able to join a shop that’s using something you’re already familiar with.

There are many use cases where server components making no sense:

    1. RESTful or API sites that just need a SPA to render
    2. embedded boards that can never run node.js etc, there are millions or billions of them.
    3. Eletron.js or React Native related applications, why do I need a next.js alike component involved at all?

Mixing SPA with SSR into React makes thing unnecessarily complicated, can SSR be an opt-in component just like what it used to be, so us SPA users do not need know your yet another revolutionary goodies that everybody must love it or he/she has no clue what's the best right now?

I switched from Vue to React, now it seems I must switch back as Vue still separates SSR from CSR, god knows how long will that stay.