Hacker News new | ask | show | jobs
by crystal_revenge 401 days ago
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.

2 comments

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.

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

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.