← Back to context

Comment by corethree

2 years ago

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.

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?

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.

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

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

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

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?

  • >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?

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

      4 replies →

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.

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

  • > 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`?