Second-guessing the modern web (2020)

The problem you describe is a data modeling problem, its because the same data comes from different places and is stored on multiple places, where each change triggers many changes. Its like like programming using only global variables. The solution is to have one directional data flow rather then bidirectional. UI should only listed to changes- not mutate data directly. Instead UI input should be sent to a client/server data store that in turns trigger the listeners.

I have to admit, I’ve been avoiding TypeScript and React for any professional projects.

TypeScript due to lack of experience, but I understand the benefits.

React due to many reasons, but most of which is that I don’t agree with the “benefits”.

I have been working with the Frontend for over a decade and have been on the forefront of its progression. KnockoutJS was a pivotal moment and cemented what followed with Backbone, Angular, Vue, and React (and several others).

It don’t think the current state of development is going in the right direction. But that’s just my opinion and a wild one at best.

> many of your visitors and clicks are repeat visitors

I think this isn't a guarantee and depends on what kind of application you're trying to build. A DMV website is (hopefully?) not going to have many users returning every day or even every week or month. If it's not social media or gaming, it's probably not going to have any sort of consistent userbase, so most visitors are not going to benefit from client side caching.

> You think heavy HTML responses are cheaper than one extra-heavy initial JS request?

If we assume "cheap" means cost-wise here, almost certainly. Consider a search engine like Google. If you are generating HTML server side (ex. PHP), the row count is limited by whatever you assume the user's screen resolution will be. That means a few hundred results returned at most, since no user is going to scroll through thousands of results on the same screen. So you perform a DB query and generate the HTML for a hundred rows or so and return it, job done.

Now consider the JS equivalent: the user downloads up to a megabyte of bundled JS. Then, the JS has to perform a fetch call to some API which probably returns the rows in JSON. At last, the client side JS iterates over the JSON and generates some new DOM elements for each row. Job done.

In the JS example, the user's browser had to download the bundle and the API response in order to render the rows, while the PHP example only queried the DB in order to render them. You might think, well the PHP way still uses up bandwidth to get results from the database right? Which is technically true, but pricing wise your database is most likely in the same data center as your web server so you're not paying anything for that bandwidth (since it's going over a physical direct connection cable instead of the Internet proper). Whereas the user is 100% not going to be in the same data center as your API server, so you're going to get whacked with bandwidth charges wherever your API is hosted on top of serving the JS bundle.

Of course, for the majority of people we're talking about pennies here. It really doesn't matter until you start getting more than 1 request per second, at which point every hour of every day of every month of every year is going to compound your bandwidth pricing problem until you figure out a way to slim down your payloads. Or, just do what most news sites do and keep adding third party advertiser JS until your ad profits outweigh your bandwidth expenses. Lots of options in this brave new frontier!

See 1MB club: https://1mb.club/

This is entirely new infrastructure, and I don't have data yet since this is a side project.

I am biasing towards relying on a connected socket for all state management which is fair for board games (and, I do believe more generally given how connected the world is becoming).

There are tremendous problems with using WebSockets in production, but they can be overcome with a decent protocol design as you have a number of failure modes to contend with. I'm in the process of publishing a paper for a conference that will share some of the architecture of my production learnings.

This hit a nerve...