And yet the sanest option for this, web components, keeps struggling.

I've been using WebComponents a lot lately.

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.

That's how it is intended to work to avoid that using two web components on two different websites leads to major inconsistencies because the root shares several classes.

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.

It's just front-end engineering in general, you don't get this with people who work in other subfields of software engineering. I get it, though. It's OK until you need to learn and grow beyond it, which I think anyone doing this long enough will.

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.

> There are whole generations who don't know what session cookies are!

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.

Generally a session cookie requires that you send over a unique ID. That's usually it. If you use JWTs, you're sending over the same amount of data if not more, but now you have to do things yourself instead of just utilizing features browsers natively have.

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.

What’s wrong with that?

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.

> 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.

This is exactly the “just use react” stereotype. Download a random react component from NPM and 90% chance they just added wrapper divs until they could get the CSS to (kind of) work.

That sounds just like me and my backend coding too! What are you doing to justify being to high and mighty?

It’s hilarious how frontend engineering is both for dumbdumb fake engineers while also being too complex for vaunted backend engineers to understand.

No. It's not too complex. It's just boring. And you people keep reinventing the wheel and presenting old concepts as "revolutionary" or "innovative". That is why you get looked down upon.

Or you don't understand the needs or the technology because of your stubbornness and ignorance.

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 environment and the limited state of a server.

I didn't say I look down upon frontend devs. I said that because of the way frontend seems to be chasing trends a lot of people look down on you. Maybe I should have said "That is why you get looked down upon by a lot of people".

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?

Do you have the same judgement you invented or would you like to mind read other's opinions and generalize groups of people some more?

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.

The reason you think frontend is more complicated is because of historically terrible terrible decisions made. Frontend is made complex because of the initial idiots developing it.

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.

Do you write in assembly?

Very rarely. Hmm, I don't think I wrote assembly in the last few years though. Why?

The only people who look down on frontend or backend engineers are people who don’t understand what it means to be great in either domain, and are too arrogant to take the time to learn and appreciate its nuances.

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.

I don’t think this is a truly irreconcilable stance and I don’t think it’s exclusive to frontend, you run into it up and down the stack.

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.

Sounds reasonable and like good code and design, perhaps we "engineers" think hard enough already. I just started reading A Philosophy of Software Design and it talks about "deep" modules (they give the example of UNIX's open creat close lseek and read vs java's I/O interfaces).