[corethree]

The Entire front end web stack looks like a design mistake.

Backend looks better only because of the flexibility. You can do anything in the back. But the front you're locked into multi decade old tech and the decade old wrappers written around it.

[paulddraper]

Sorry I can't hear you over the sound of my fifteen hundred microservice infrastructure configured with Chef, no actually Puppet, no actually Ansible, no actually Terraform, no actually Tofu, no actually Pulumi. Wait, what is Docker Swarm and does anyone use it?

[lmm]

Thankfully you can opt out of most of those and pick the one that works for you. Sadly there's no alternative to CSS.

[paulddraper]

Yes, if you restrict it to web browsers, and more specifically HTML (not Canvas, WebGL).

[corethree]

Bro backend is a different set of problems.

[dtagames]

I disagree. First of all, all of computing is locked into decades-only technology: assembler language and machine instructions. Everything comes down to that whether you write front or back end and regardless of what other "tech" is in the middle.

Today, we can do anything on the front end. Some of the most popular and complex apps in history are front end apps made with JS/HTML and web components (Discord, Spotify, Photoshop for Web, YouTube, and many others.)

The reason that this "stack" has survived and thrived is precisely that it does, at this point, allow front end devs to do anything and to do it in a way that runs everywhere. And that's a Very Good Thing.

[treyd]

> assembler language and machine instructions

Except no we're not, new processors bring along new features and drop/discourage old ones, on x86 they even run in different modes depending on requirements, and compilers can choose to target specifically new ones and drop support for older processors without them. This isn't a valid comparison.

I think it's a bad thing because even though "you can do anything" it doesn't mean you can do it well because the web was always designed to be narrow and restricted for privacy/security reasons. That's good, but there's large classes of applications (chat clients, music players, image editors, etc) where that shouldn't be an issue and the costs of running in a web-like environment. Which, even if you drop the security features, manifests as worse UX to users due to the layers of indirection you're dealing with between the developer and the host OS.

[blackbear_]

Lol, do you really consider a music player and a chat application as the most complex apps in history?

[corethree]

But front end is a high level specification.

The principles of physics remain the same but the machines around those laws of physics should improve.

[cantSpellSober]

This article is just about CSS not the entire frontend web stack.

Curious though, do you consider server-side-rendered components "frontend?"

What about React Server Components?

[corethree]

>This article is just about CSS not the entire frontend web stack.

Why waste your effort to inform me something I already know? You know that I know.

>Curious though, do you consider server-side-rendered components "frontend?"

Why are you curious about vocabulary and categorization? If you know what I'm talking about by "front-end-stack" then who cares?

[cantSpellSober]

Oh, strange non-sequitur then.

I don't know what you mean specifically by "front end stack", so I asked (unanswered) clarifying questions.

> Why are you curious about vocabulary and categorization

Because the frontend/backend lines are blurring, and I want to define our terms before discussion.

[corethree]

You haven't answered my question. Why inform me on something obvious that I know? I know the article is about css. And you know that I know.

By front end I mean any technology directly associated with rendering and processing on the browser. The lines of this definition are blurry so I will adjust those lines and move them accordingly to fit the intent of what I'm saying here. But again you know my intent so why make me waste my time to specify something you clearly know?

[cantSpellSober]

I thought your question was simply rhetoric. I didn't realize how confused you were.

To answer: if there's an article about tomato slices and someone goes on a rant about hamburgers (tomato slices being a small part of the whole) it's not clear or "obvious" that they read or understood the article.

You haven't answered my question, do you consider server-side-rendered components "frontend?" They are "directly associated with rendering and processing on the browser." (Even if they aren't rehydrated.)

[corethree]

Depends on the situation. They can be one or the other or both. It's meta, you construct code on the backend for rendering on the front end. There's no clear answer to your question other than the code being constructed is front end exclusively while the code constructing the code is hard to categorize.

>I thought your question was simply rhetoric. I didn't realize you were genuinely confused.

If the tomato is rotten, I'm saying that's the least of your problems if The entire hamburger is rotten. Pretty clear about my intent. Did you honestly think that I was being completely random or did you have another motive for saying something rhetorical?

[PaulHoule]

What's the alternative?

The 1990s style HTML form app that works like a green screen mainframe application? (It seems to be forgotten technology in the age of React like Stonehenge or the Egyptian Pyramids but I think it's quite appropriate for the kind of application it's capable of, which is more > 50% of what people use React for.)

Cross-platform frameworks like GTK, Qt, Tk, FLTK, wxWidgets (was that a winner in the world cup for "ugliest UI"?), Flutter, etc. (I did a shootout of x-platform UI frameworks and concluded that Electron really is the best of the bunch, is it any worse to make people download a 30MB Electron runtime than a 50MB Java runtime or a 25MB Python runtime?)

Apple fanboys inexplicably seem to like iTunes and MacOS, they all swear by xCode but even people who think "it is is all good" when it comes to fruit swear at the App Store when it comes to delays and restrictions. I'm pretty sure there is a good UI framework somewhere inside Windows but it might be hard to find in a maze of twisty little APIs that all look alike:

https://www.reillywood.com/blog/windows-ui-frameworks/

Compare that to the freedom of the web platform. I've lately been playing around with this framework with my Meta Quest 3:

https://aframe.io/examples/showcase/modelviewer/

which makes it straightforward to make an application that targets desktop, mobile, VR and AR headsets. Although it is based on React it has the same entity-component architecture as the Unity framework. I'm sure I could get better performance writing a more-or-less Android app based on Unity but dealing with Facebook's App Store seems like messing around with IBM cards, particularly when I want to target Apple Vision when it comes out and when I need to have an experience for people that don't have a VR headset because those aren't very common yet.

[lmm]

One of these days I'll actually try writing a React-style (well, really Wicket-style) UI framework where styling is always inline - no cascades, no stylesheets, no selectors, just style attributes. If you want to reuse styling, you do it the same way as reusing markup, by having libraries of components.

With transparent compression it shouldn't make pages any bigger on the wire, and given that the browser always has to figure out what styling to apply to each element it shouldn't use any more memory.

[cantSpellSober]

> What's the alternative?

Good question! What do you mean? There is no alternative, just enough experience writing it that these mistakes become hardwired, or having browsers updated to interpret "no-wrap" as "nowrap" for ex.

The options you mention make sense, but just a level of abstraction. CSS is still the compile target (unless you're using WASM etc).

Unless you mean alternatives to, say, using things like `!important`?