Hacker News Reader

I'm also from the before times, and still think one of the major issues with all of this is that we've decided to build a global application ecosystem by hacking stuff on top of a document format.

HTML was supposed to just a slight markup layer to make it easier to transit and render text documents, likewise that's all HTTP was designed for. The ratio of text-to-markup should be fairly high (I'm sure today it's less than 1). But for some reason (probably the initial ease of publishing globally) we decided that the future of application development should be to entirely reinvent GUIs to be built on top of this layer. If you look under the hood at what React is doing, we just have decades of hacks and tricks well organized to create the illusion that this is a rational way to create UIs.

Imagine a world where we decided we wanted to create applications by hacking Excel documents and Visual Basic (being from the before times, I had seen attempts at this), or have every app be a PDF file making clever use of PostScript? When one remembers how ridiculous it is to attempt to do what we have collectively done, it's not too surprising that a website can require megabytes of JS to render properly and, more importantly, to allow reasonable development processes allowing for some organization of the code base.

Are you implying there exists a better way of making UIs that just hasn't taken over the world for some reason?

I also don't like the state of the web.

Yes, making UI’s is not a new problem but building on top of the DOM/HTML as the backbone is.

I too am from the before times where I guess we built essentially our own frameworks to handle own unique issues and take security into our own hands (verses have to trust external libraries and external resources….)

I sadly laugh when I hear 20+ years late people are still fighting back button navigation issues. I still see sites that can’t handle double posts correctly or recovery gracefully when post responses fail/timeout.

I’m out of the game now but for all the benefits of the web it’s been haves to death to support stuff the underlying infrastructure was nit designed for.

Look at WPF (or its more modern incarnations like Avalonia or Uno) for a decent example of what a GUI framework designed for desktop apps from the get go can look like.

Things like these haven't taken over the world because they didn't have the ease of app delivery that browsers provide, and attempts to bolt them onto browsers (Silverlight etc) didn't work out because they didn't work out of the box for most end users.

These days though we have enough bits and pieces directly in the browser (wasm, canvas, WebGL etc) to recreate something like Silverlight that "just works" in any modern browser. Take a look at https://eremex.github.io/controls-demo/ for an example of what's possible.

Yes, my first GUI apps were about 20 years ago in visual basic. It was far easier than laying out webpages (assuming you're targeting desktop users). It's just far harder to get users to download and run something (and should be). But the browser's layout system (the DOM) has 0 to do with that, there is nothing but inertia locking us into that.

Desktop apps have had superior UIs compared to the web for decades, and are still superior today. The Web is a terrible application platform which only persists because it's very easy to distribute to users.

Yup, the web is a thoroughly mediocre application platform†, but the world’s best application distribution platform.

†I know this claim will rub some people the wrong way, but if you compare the capabilities of web tooling to build rich application UIs against desktop app tooling of even 20-30 years ago, there’s no comparison. The web is still primitive, and while JS and CSS are improving at a good pace, HTML is almost frozen in carbonite.

> HTML is almost frozen in carbonite.

Not really - there are pretty big escape hatches - you can do pretty much anything in canvas, custom elements allows you to define your own elements with their own behaviour.

I'd say the problem is the opposite - one of the reasons desktop apps from 20-30 years ago ( say MacOS 7 ) where great from a user perspective is pretty much all apps looked and worked in the same way, using the same UI toolkit and the same UI principals. And from a developer perspective - a lot of the key decisions had already been made for you.

The web of today is a zoo of UI styles and interaction modes.

The problem isn't so much a lack of innovation or possibilities, but perhaps rather the opposite.

It's both, really. HTML makes it really easy to do "corporate branded" fancy buttons, but you still have to jump through hoops to do something that could be done with a database and the stock data grid widget in <10 lines of code in VB or Delphi.

Are we really comparing 2 tier to three tier here? ( With the web effectively 3 tier by default ).

That old VB code that queried the database directly wouldn't work well over a non-local network.

ie there is a bit of apples and oranges comparison here.

You do have a point, but then again, think about how many corpnet apps are web apps these days, even though the network is local.

Sure.

You also might not need any access control, network traffic security, cross platform deployment, instant install, evergreen updating, trivial UI integration ( links ) etc etc.

If you really want something simple you could use Excel, Access or Filemaker as a front end.

I agree life has got more complex - and in some cases unnecessarily so - case in point it's becoming increasingly hard to write web apps without SSL - even if you don't need it.

How it talks to the backend is irrelevant here. That has zero to do with the fact that the DOM was imply not designed for dynamic application layouts.

Sure DOM is retained mode graphics - however as I said, if you want to immediate mode - then canvas is available.

But you don't have to learn "framework after framework". Realistically, at a well-organised organisation you learn React and that's it. You don't worry about the compilation and minification and what have you, because you have a working build system that does the build and does the source maps, and you have a culture that fixes these things if they break or become flaky.

As someone who stepped away from web for a while and came back to it a couple of years ago, a straight React or Next.js application is so, so much nicer to work with than old-school webapps were. It feels like the web has finally been dragged kicking and screaming into a world of regular software development best practices. JS isn't the best programming language but it's a proper programming language and it does the job, I'm continually baffled that people would rather contort themselves with the sub-Turing tarpit of CSS and what have you instead of just using some libraries, writing some code, and actually solving their problems in what's usually an objectively easier and better way.

Why would a language meant to focus only on styling need to be Turing complete?

It doesn't necessarily need to be Turing complete, but CSS in its current form is harder to understand, debug or make sense of than most Turing-complete languages.

Do you mean because of how its designed to cascade, and all the details of priority that requires? Or something else?

Personally I've never found the language itself hard to understand other than issues where a style somewhere else bleeds in and I have to hope browser dev tools can point me in the right direction.

> Do you mean because of how its designed to cascade, and all the details of priority that requires? Or something else?

Mainly that. But there are other parts that feel clunkier than they need to be too, e.g. media queries force you to repeat yourself a lot when most of the time you just want to write an expression, before/after gives you a whole new way to write elements that's only used for this one niche thing. The language has these weirdly powerful individual features but weak general features and no overall cohesion.

> issues where a style somewhere else bleeds in and I have to hope browser dev tools can point me in the right direction.

The converse part is even worse IMO. There's no way to do any kind of "find usages", so you can never tell whether a given style is used or not. With the result that people never refactor or delete anything, and the codebase gets worse and worse.

>Perhaps nostalgia and the principle of KISS (and a few others) is clouding my judgement here, after all, frameworks are made for a reason. But it's difficult to imagine a new engineer having any more difficulty with vanilla than learning framework after framework.

I feel the same way. React and Angular (well an earlier version of Angular) were made prior to ES2015 being mainstream, so I do think they made sense to use when they were initially created. Since then, I've become burned out from the constant churn of new frontend frameworks to learn. Even within the world of React, there's different ways of writing components, and different state managers.

I wanted to refute the "the constant churn of new frontend frameworks to learn". If you just stuck with React since 2015, they've only had 4 major versions since then and every ver they deprecate only a few things and then you have a full release cycle to migrate to the new hot thing. It's probably the best upgrade paths of any of the libs I work with.

But you're not wrong about there being many ways to write components and manage state.

And RSC is a mess. But thankfully you can keep pretending that doesn't exist.

> I wanted to refute the "the constant churn of new frontend frameworks to learn". If you just stuck with React since 2015, they've only had 4 major versions since then and every ver they deprecate only a few things and then you have a full release cycle to migrate to the new hot thing.

Contrast that with non-framework JS/HTML, where _you_ decide how long it lives and how often you need to upgrade (or not). Having to rejigger a web app every 2-3 years because someone outside of your organization changes something is not only unappealing, but it's horribly expensive for large-scale businesses and possibly prohibitively expensive for small-scale businesses or solo developers.

It happened to me with a personal project, I abandoned it for about 2 years and one day I decided to take it up again to add some features and when I did npm install I almost died.

> But if I'm being honest post query selector frameworks don't have a strong cost benefit argument

To me the killer app in the modern world is reactivity, ie making views that update in response to changes in the data model. To manually create listeners and do differential updates, and manage removal and teardown of event listeners etc, is akin to doing manual memory management. We used to do that with jquery sometimes, and it’s the most error-prone thing you can do. It’s a stateful shithole.

Once they manage to find a way to modularize components in a way that is largely view-declarative, I would be happy to crawl up on the surface of vanilla JS again, but not before. It’s simply missing functionality, imo.

Reactivity features are helpful, but in my opinion they're only helpful in a problem that largely shouldn't exist.

For a vast majority of websites out there state largely lives on the server. Reactivity is only helpful when the state reacted to is client side, and for that most sites that's only going to happen when we decide to keep a duplicate copy of state in the client rather than rendering on the back end where the state lives.

I get the desire for smooth transitions, optimistic rendering, etc. Those goals lead to endless complexity and bugs when the actual source of truth lives elsewhere.

How a site is build becomes way more simple when we stick to keeping HTML rendering where the state lives even if that means making UX tradeoffs.

Yes and for those cases it’s kind of already solved decently like with htmx or just plain old forms and post requests. I think those old ways are underrated.

But, for a chat app it isn’t gonna cut it. Or a collaborative app, where changes need to be pushed to the client. Or maps, or similar. Or anything which needs offline working. (I’m working on a desktop app where majority of state is owned by and lives on the client.)

TLDR I agree for passive web pages but the web is often more than that, many times for good reason.

Not sure if its an unpopular opinion here, but in those kinds of cases I think browsers are just a bad deployment target for the problem.

Dealing with cross-platform issues and app store policies can be frustrating, but the web was fundamentally designed for documents and it just doesn't lend itself well to complex, mostly or entirely clients side apps.

It’s not unpopular, I see it as the majority opinion on HN. It’s based on skepticism against web in general, and outright hatred for electron (which is at least somewhat justified).

My app is 11MB bundle (most of which is an unrelated native extension) on most platforms, and has complex stateful business logic and views. It performs mediocre only on Linux due to lacking investment in webkitgtk.

> the web was fundamentally designed for documents

And yet it successfully penetrated the application server market, which it (JS) was never designed for. Stateful apps are much closer to the original design. The gap is essentially a few enumerable pain points that get smaller every year. Most importantly though, the only other toolkit supporting all 3 desktop, 2 mobile and web is Flutter, which is proprietary and entirely downstream the goodwill of a mega-corp.

At 100s of millions I’m assuming you have something closer to a static site than an application?

It's a popular non-netflix/google video streaming app that you've maybe heard of. HTML5 apps/sites/whatever are just part of our supported clients. All clients are supported by a largish SOA. All of the HTML clients are indeed sites, SPAs on a CDN to be more specific, and not "apps" but this is the sickly nomenclature our industry has adopted. But I really should have called them sites if I want to motivate others to do the same, thanks for the correction.