As someone still building websites mostly like it's 2010, it's funny to look at these discussions. "How do we abstract away browser APIs" — but what if you just do not? What if you use them directly? What if you don't do client-side rendering unless absolutely necessary?
The two most modern tools I use in my web stack are TypeScript and PostCSS. But these are build tools that make my life easier. At runtime, I still have zero dependencies.
I once worked on a VK mini app with one guy. He was building the app itself, I did the backend. He just recently started learning web development, having never done any programming before.
So I'm ready for him to test my backend, I tell him to make a request to https://... and pass this and that parameter. And he just has no clue what I'm talking about. He somehow managed to learn React, a bit of HTML and a bit of CSS without any of the underlying basics. I had to explain him some of HTTP, the URL structure, and what an XMLHttpRequest is.
This was a revelatory experience for me.
Why? I don't care how the chrome engine works. I care about building a great CX and making money
You don't need to understand how the engine works in detail, but in general, it's useful to know which operations are expensive, performance-wise, which are cheap, and what triggers them. For example, you want layout recalculations to only run when they're actually necessary. Or, if you want to move an element around, you should use transform instead of position as transform is "free" because it's a simple matrix multiplication that the GPU does anyway, but position might trigger a re-layout every time you update it.
> I care about building a great CX
I've yet to see a React website that doesn't feel sluggish and overall terrible.
> and making money
Ah that's more like it.
> I've yet to see a React website that doesn't feel sluggish and overall terrible
I doubt it, sounds like confirmation bias.
This is the difference, and why we can never understand each other.
I couldn’t care less how much customers like something; what matters to me is if it’s technically perfect.
This is also why I will never be happy at any job, because it turns out technical perfection doesn’t pay the bills.
I generally agree with you, but if you only care about technical perfection, it can happen that something is "technically perfect", but insufferable to use.
For example, I'm sure many of the common command-line utilities are considered technically perfect by their developers, but outside of some common use cases you've memorized, they are all a pain to use because of how undiscoverable CLI is by its nature. The "wrong input, go read some manuals" style of error messages doesn't help either.
I myself always start from user requirements and work my way down from there.
The same is true everywhere in tech, I swear.
"What if we abstracted away X?"
My dude, you're already operating on like five levels of abstractions, and you haven't the slightest clue how any of them work. The answer isn't another abstraction, it's learning how computers actually operate.