As someone who has no legal duty to advocate in your best interest, I think you should keep posting about your intent to damage the platform-holder whose terms of service you are contravening.
`unknown` is a standard type in TypeScript for "it could be anything and you don't know what it is, so you need to introspect it and assert a type if you want to use it". (As opposed to `any`, which is "it could be anything but you don't have to introspect it to use it, you're just opting out of the type system".)
This is not "normie" TypeScript but I wouldn't characterize it as particularly scary.
A: "We submit to capital controls and while extremely infrequently our investment groups make (occasionally disastrous) mistakes, the system of human finance is arguably more stable than at any point in the history of our species' efforts to trade with people beyond the horizon."
B: "We bought a house for the founder's parents while they advised ways to hide it and threw millions of dollars at the insolvent-by-design crypto fund of somebody in the boss's polycule."
> If you are creating a different kind of application and therefore don't need the DOM or other browser things then why JS at all?
Because I like TypeScript and don't like Lua.
JavaScript, I don't like. It's in the same bucket to me as Python, Ruby, and Lua - things I might have to use sometimes but I'm holding my nose. But TypeScript? I like TypeScript and want to use it more.
Sure. That's a tradeoff you consciously make to get the thing out the door. That's what technical debt is. You pay it down later. (Or you go bankrupt and it doesn't matter anymore.)
Yeah, but it's the one we've got. As much as people want to sniff about it, that bell isn't getting un-rung for more, perhaps most, use cases--on balance things are better where we're at now.
I look forward to returning to the days where everybody wrote their own slightly-to-significantly-wrong state management tooling while being distracted by the minutiae of DOM wrangling. That was a good time.
(It was not. It was why I stopped doing frontend work.)
In my experience: a profiler, usually. Just because I can throw down a lot of code quickly doesn't mean I don't have the tools to analyze code when I go "hmm, that seems slow".
Is git bisect a power user feature? I was taught git by a senior engineer early in my career and it was the first "this will save your rear" tool he showed me.
I mean...maybe. I am not up on it enough to say, though my intuitive answer is "it's not that simple." But that's just not how any existing stuff works, too. If you want to work with the ton of middleware, etc. that already exists, you work the way Unreal (or Unity, etc.) do.
That is typically done with matrix transformations, which all end up in floating-point space anyway. Having to do integer-to-float transforms for everything to get you there is bad news.
Having asked this myself once, and tried to write it: it is hilariously slow to render. Graphics cards are float crunchers. Changing one's frame of reference is not trivial but isn't impossible, and it is much faster.
I disagree that the frontend will be specific in even a "vast" majority of cases--if only because of the obvious proliferation of mobile. And while I agree that you can often make a good-looking server-side-rendered, templated application, I will contest that you can ever make a server-side-rendered, templated application feel correctly on a mobile device.
Even in the case where you do have a specific frontend, I contend that there's still value in the separation because it very strongly encourages (coupled with tools like, shameless plug, nestjs-data-sec[0]) the writing of very clear viewmodels where thought must be put into what exactly should be exposed over the wire in a way that commingling database objects and template logic doesn't allow.
I think server-side rendered pages are properly rated at this point, not underrated; there are places to use them but they're shrinking as other tooling get better. As an example, even I write React almost exclusively because I write React faster and with fewer errors than any templating language I see in common use except maybe Razor (and Razor implies buying into ASP.NET, which, no). React/TypeScript are hard to get wrong and easy to burn through quickly. And I would call a React page rendered through NextJS a "server-side rendered app"--but I get the feeling you would not. ;)
I think it is worth considering whether you may have the arrow of causality backwards. For tech specifically; your second paragraph is right on point. The folks I know who've got a fundamental grounding in the stuff you listed (and I count myself among them) all seemed to have an understanding of What Makes Systems Good before doing so. In many ways it becomes the naming of parts along with elaboration upon fairly basic ideas.
I do not believe in the idea of a bimodal distribution of software development (not just programming) aptitude, but I sometimes wonder.
(Regardless, I don't call myself an engineer. Engineers get sued if their stuff doesn't work. I'm a software developer, no matter how good and careful I might be.)
React (and other SPAs) may be fashionable, but I generally contend that--when written well or even passably, which obviously requires an asterisk lest the Scotsmen come by but I don't think is a very high bar--if nothing else it requires developers to treat a web application as a client of an API rather than tightly integrating it. It enforces a level of separation of concerns that, IME, tends to encourage loose coupling and better design.
Forget everything about responsiveness or whatever (which I find way more valuable than the tradeoffs one makes)--the lack of tight coupling is the real win of React and similar. I mean, if you'd like you can pretty easily build a server-side React app with NextJS and still get a lot of these benefits while using React purely as a pretty-dang-good templating language.