The entire front-end framework landscape is like this. It's all designed to appeal to the kind of "engineer" that just wants to copy paste code and have it work like magic without ever thinking about what's actually going on.
I think there are two approaches to software development, and a gradient of people transitioning between them:
(1) I’m responsible for this system and I either have to understand this well enough to feel comfortable being directly responsible for it or delegate responsibility through my org structure or vendor contracts.
(2) I don’t understand how any of this works, it’s just a bunch of magical incantations that get me results, and one incantation is interchangeable with another.
Your dumbdumb fake engineer isn’t a fair characterization of (2) but I do believe a lot of tools in a lot of ecosystems are optimized for engineers without the depth of knowledge necessary to operate them under the API contract.
That’s totally fine when that API contract is provided by a responsible party you can delegate responsibility to. The problem comes in when you provide these “simple” API contracts on top of extremely complex internals and hand them to a developer/user who is ultimately responsible for the entire stack, internals and all.
In some cases (2) can offset risk using a “cattle” approach where multiple live versions of the system are kept up, changes happen one at a time, and you can fail over if something goes wrong and throw away the old state. I’ve met engineers who operate K8S clusters this way. They are clearly out of their depth with kubernetes, but they can fail over to a secondary and rebootstrap a bad cluster from scratch to get back to a good state. By keeping things disposable you exclude most (all?) failure modes other than “poison pill” bugs that repeatedly put your system into a bad state.
But, for the most part, these complex open source systems that try to hide complex internals give the illusion of delegating responsibility. You might get pretty far before an incident comes knocking and it’s time to pay the toll.
That's why I look down upon engineers with your mindset. I won't generalize all backend engineers as you did to frontend though.
I've met many who get it but of course prefer the peacefulness of controlling the execution environment and the limited state of a server.
Btw imo backend is boring because the reasons above, frontend has a lot more going on. As a full stack engineer I'd say frontend is much much harder, and that's why you have all the tech trying to make it easier to scale and maintain. That's not to say backend doesn't have it's own difficulties. It all depends what you are making too. A website is easy, a complex app is much more difficult.
Why are you assuming I am a backend dev? In fact why do you even assume I do web dev? You do know that there are many more areas where programming is needed, right?
How I took that is you just don't want to commit to your own statements, so you speak through these "others"...
And backend isn't just web. I was using a catch-all to call out how, misinformed, ignorant, and offensive your statement was.
I didn't make anything up. I just noticed that frontend devs were being looked down upon when talking to some devs and I investigated further. It seems that most frontend devs are just what is usually called "code monkeys" who just fling shit until it works. No real understanding of math, algorithms, architecture and general good engineering principles. Which is also why usually frontend code looks like garbage. I am sure there are exceptions but for the most part frontend stuff doesn't get the best and brightest people working on it. Because it's considered boring and uninteresting. Personally I don't care. Web dev in general seems to be complete and utter trash and I work on things that are on a completely different plane of complexity (as in if things go wrong people die). It's just funny that you still cling on to the idea that frontend is some sort of holy grail of engineering and absolute complexity.
Every engineer I’ve known who’s “looked down” on frontend or was dismissive of it was not only bad at frontend and didn’t understand what it takes to be good at it, but also a jerk about the perceived depth of their own knowledge.
It sucks that people learn this the hard way, though, and the only way to grow beyond this for people new to the field is to eventually get burned and learn there are other ways to do all of this.
There are whole generations who don't know what session cookies are! And... that's just OK.
I really enjoy JWTs, but the idea of sending all my user data on every request hadn’t occurred to me, and still feels mildly wasteful.
You could utilize a key system to gain the same advantage as not having to use persistence as one gets using JWTs when implementing session cookies, if you wanted, too.
My biggest gripe with them as a technology is that they have no way to associate a `<style>` tag in `<head>` with a ShadowDOM tree (short of cloning and injecting w/ JS).
The only way to say "this CSS goes with this <template>" is to nest the `<style>` tag in `<template>` itself or painstakingly expose `part`s on everything you want to style.
I'd really like a template selector for CSS where I can say something like `::template(#id) button` to select all buttons inside the `<template id="id">` for whatever ShadowDOM it is mounted to.
Without this, I either have to do CSS in JS, CSS in HTML, or I have to use special build magic to take my standard index.css files and inject them into my HTML or JS. All of that is kinda gross.
If you want to support your case, you either inject css or you design your web components to support css variables which pierce throgh the shadow dom.
Let’s better spend time on important things instead of wasting time trying to make UI behave properly across a plethora of browsers, OSes and platforms.
Cross-browser compatibility was the problem that jquery was trying to solve back in 2008 or thereabouts. Not a problem that react is trying to solve in 2023.