Hacker News Reader

Comment by mohamedkoubaa | Hacker News Reader

This points to our failure as an industry to design a universal app engine that isn't a browser.

Counterpoint: is the web browser not already fulfilling the "universal app engine" need? It can already run on most end user devices where people do most other things. IoT/Edge devices don't count here, but this day most of their data is just being sent back to a server which is accessible via some web interface.

Ignoring the fragmentation of course; although that seems to be getting less and less each year (so long as you ignore Safari).

Yes. But it consumes at least 10x-100x more resources to run a web app than to run a comparable desktop app (written in a sufficiently low level language).

The impact on people's time, money and on the environment are proportional.

> But it consumes at least 10x-100x more resources to run a web app than to run a comparable desktop app (written in a sufficiently low level language)

Does it? Have you compared a web app written in a sufficiently low level language with a desktop app?

Yes. I can run entire 3D games.... ten times in the memory footprint of your average browser. Even fairly decent-looking ones, not your Doom or Quake!

And if we're talking about simple GUI apps, you can run them in 10 megabytes or maybe even less. It's cheating a bit as the OS libraries are already loaded - but they're loaded anyway if you use the browser too, so it's not like you can shave off of that.

> Yes. I can run entire 3D games.... ten times in the memory footprint of your average browser.

What about in QML, which uses Web technologies like CSS, JS and even basic HTML? The whole KDE Plasma 6 desktop is built around these technologies now and I (and many others) consider it light and high-performance.

If you saddle up those technologies in the full browser everything then it will get larger, yes, but nothing requires you to do this, just as nothing requires providing your app as a full-fat Fedora install when a distroless container would have sufficed.

Plain Javascript can be very fast and still come at relatively low resource demands and the same is true of HTML and CSS. Many "plain desktop-native" applications often end up reinventing their own variants of HTML and CSS in the course of designing the U/I anyways.

It's better, but it's still quite bloated, to be honest. Linux is generally more memory-hungry than Windows because of how modular it is, and having no Win32 equivalent really hurts. Although they've started doing UI in React Native over there too...

Qt is much lighter than your Chromium-based stacks but all the waste kind of adds up.

"just as nothing requires providing your app as a full-fat Fedora install when a distroless container would have sufficed" Containers are hungrier than running stuff on bare metal...

Yeah, React Native is apparently how Claude Code operates (even on terminal) so it wouldn't surprise me to see it being useful in a native GUI context as well, if we can get more bindings than Skia.

> Containers are hungrier than running stuff on bare metal...

Containers are tremendously lightweight compared to VM. You might as well point out that running a full multiuser security-protected OS like Linux is hungrier than running on bare metal with DOS too. It's just as true, and even proportionally as true.

In any event a full Fedora container with all packages installed is going to be tremendously larger than a distroless hello-world "built" around Alpine, for instance, even though they both use container technologies. Same applies to Web technologies, you can certainly go and easily add a lot of waste using them but they are not themselves inherently wasteful.

I believe Firefox use separate processes per tab and most of them are over 100MB per page. And that's understandable when you know that each page is the equivalent of a game engine with it's own attached editor.

A desktop app may consume more, but it's heavily focused on one thing, so a photo editor don't need to bring in a whole sound subsystem and a live programming system.

>Counterpoint: is the web browser not already fulfilling the "universal app engine" need?

Counter-counterpoint: Maybe it's time to require professional engineer certification before a software product can be shipped in a way that can be monetized. It's to filter devs from the industry who look at browsers today and go "Yeah, this is a good universal app engine."

This was cathartic to read thank you

I think a browser is an inverted universal engine. The underlying tech is solid, but on top of it sits the DOM and scripting, and then apps have to build on top of that mess. In my opinion, it would be much better for web apps and the DOM to be sibling implementations using the same engine, not hierarchically related. You wouldn’t use Excel as a foundation to make software, even though you could.

Maybe useful higher-level elements like layout, typography, etc. could be shared as frameworks.

You are thinking along the same lines as me. The fact that the first thing to be standardized was HTML made it a fait accompli that everything had to be built on top of it, since that "guaranteed" <insert grain of salt> cross vendor compatibility.

There are many alternate histories where a different base application layer (app engine) could have been designed for the web (the platform)

We have failed to design a universal app engine…except for the one that dwarfs every other kind of software development for every kind of device in the world.

Can a single webpage address & use more than 4gb of ram nowadays? I was filling 16gb of ram with a single Ableton live session in 2011.

How about a webpage shouldn't ever address & use even 4GB of RAM! :O

But that's the thing, if I'm doing audio and buying 128GB of ram for the sake of doing music with my sample libraries, and loading hundreds of parallel tracks and being able to scrub through them without lags or audio clicks, I absolutely want to be able to load them to play with them.

Via electron I’m sure it could. In the main browser it’s probably best to cap usage to avoid having buggy pages consume everything. Anything heavy like a video editor you’d rather install as an electron app for deeper system access and such.

But JS arrays are limited to 4GB. Size is defined to be a 32-bit int.

No. We did, it is the browser.

"The Browser" has turned out to be a pretty terrible application API, IMO. First, which browser? They are all (and have been) slightly different in infuriating ways going all the way back to IE6 and prior. Also, a lot of compromises were made while organically evolving what was supposed to be "a system for displaying and linking between text pages" into a cross-platform application and system API. The web's HTML/CSS roots are a heavy ball and chain for applications to carry around.

It would have been great if browsers remained lightweight html/image/hyperlink displayers, and something separate emerged as an actual cross-platform API, but history is what it is.

They're not that different, and it's a pretty good platform and pretty easy to program for. That's why it won.

It didn't win. It just survived long enough. The web is a terrible platform. I haven't ever shipped a line of "web code" for money and I plan to keep it that way until I retire. What a miserable way to make a living.

Perhaps you're taking the npm/react/vercel world to be the entire web? I agree that that stuff is a scourge. But you can still just write html and Javascript and serve it from a static site, I wrote an outline in https://incoherency.co.uk/blog/stories/web-programs.html which I frequently link to coding agents when they are going astray.

When I was a kid I was running websites with active forums and a real domain name, and I did it with vBulletin and my brain. Someone bought the domain name and website off of me, haven't touched web tech since. I did use Wt at an old job once, but the "website" was local to 1 machine and there were no security concerns.

I wouldn't say that react is what's wrong with the web. I would say that the web is what's wrong with react.

I envy your pure soul. I am one of many who has had, at times, been coerced through financial strain to write some front end code. All I ask for is, when the time comes, you try to remember me for who I was and not the thing I became.

Look at caniuse, if you see green boxes on all the current version browsers. Than you are good to go. If not, wait until the feature is more widely supported.

Remember Flash? The big tech companies felt a threat to their walled gardens. They formed an unholy alliance to stamp out flash with a sprinkle of fake news labeling it a security threat.

Remember Livescript and early web browsers? It was almost cancelled by big tech because Java was supposed to be the cross platform system. The web and Javascript just BARELY escaped a big tech smack down. They stroked the ego of big tech by renaming to Javascript to honor Java. Licked some boots, promised a very mediocre, non threatning UI experience in the browser and big tech allowed it to exist. Then the whole world started using the web/javascript. It caught fire before big tech could extinguish. Java itself got labeled a security threat by Apple/Microsoft for threatening the walled gardens but that's another story.

You may not like browsers but they are the ONLY thing big tech can't extinguish due to ubiquity. Achieving ubiquity is not easy, not even possible for new contenders. Pray to GOD everyday and thank her for giving us the web browser as a feasible cross platform GUI.

Web browser UI available on all devices is not a failure, it's a miracle.

To top it all off, HTML/CSS/Javascript is a pretty good system. The box model of CSS is great for a cross platform design. Things need to work on a massive TV or small screen phone. The open text-based nature is great for catering to screen readers to help the visually impaired.

The latest Wizbang GPU powered UI framework probably forgot about the blind. The latest Wizbang is probably stuck in the days of absolute positioning and non-declarative layouts. And with x,y(z) coords. It may be great for the next-gen 4-D video game, but sucks for general purpose use.

Flash had quite a lot of quite severe CVE; how many of those do you suppose are "fake news" connived by conspiracy (paranoid style in politics, much?) as opposed to Flash being a pile of rusted dongs as far as security goes? A lot of software from that era was a pile of rusted dongs, bloat browsers included. Flash was also the first broken website I ever came across, for some restaurant I never ended up going to. If they can't show their menu in text, oh, well.

As I recall, Flash and Java weren't so much security issues themselves, but rather the poorly designed gaping hole they used to enter the browser sandbox being impossible to lock down. If something like WASM existed at the time to make it possible for them to run fully inside the sandbox, I bet they'd still be around today. People really did like Macromedia/Adobe tools for web dev, and the death of Flash was only possible to overcome its popularity because of just how bad those security holes were. I miss Flash, but I really don't miss drive-by toolbar and adware installation, which went away when those holes were closed.

Steam is pretty close.

> design a universal app engine

You've reminded me of the XKCD comic about standards: https://xkcd.com/927/

Do you really want a universal app engine? If you don't have a good reason for ignoring platform guidelines (as many games do), then don't. The best applications on any platform are the ones that embrace the platform's conventions and quirks.

I get why businesses will settle for mediocre, but for personal projects why would you? Pick the platform you use and make the best application you can. If you must have cross-platform support, then decouple your UI and pick the right language and libraries for each platform (SwiftUI on Mac, GTK for Linux, etc...).

Please, for the love of all that is holy, not GTK.

Platforms and app engines are orthogonal concerns. I agree that platform guidelines are worth preserving, and the web as a platform solves it by hijacking the rectangle that the native platform yields to it. Any app engine could do the same thing.

> the web as a platform solves it by hijacking the rectangle that the native platform yields to it

That's a terrible solution that preserves nothing. Try using a screen reader with an app rendered onto a rectangle.

Reply on news.ycombinator.com