Hacker News Reader

Comment by 0xbadcafebee | Hacker News Reader

Innovation is never constantly increasing. It usually appears in bursts, and stops around the point that humans don't need it as much, or development hits a ceiling of effort. But it's always slowly simmering. Usually it's research or yak-shaving that, after years, suddenly appears as if out of nowhere as a useful product.

I am hopeful that in my lifetime, the web will die. It's such an insanely stupid application platform. An OS on an OS, in a document reader (which, due to humans' ability to go to any lengths to avoid hard work, literally all new network protocols have to be built on top of).

You want cool visualizations? Maybe don't lock yourself into using a goddamn networked document viewer. Native apps can do literally anything. But here we are, the most advanced lifeforms on the planet, trapped in a cage of our own making.

View on HN

> I am hopeful that in my lifetime, the web will die.

I'd like to see the www go back to its roots as a way to share and browse documents, hyperlinked together. The web worked when it was just documents to render and click on links. It is terrible as an application platform.

It's been 30 years since JavaScript was invented. Imagine what we'd have today, if instead of making the WWW into this half-assed application platform, those 30 years of collective brainpower were instead spent on making a great cross-platform native application development and delivery system!

Native for Windows, Macs, Linux, iPhones and Android devices?

Now imagine trying to update all of those native apps across a large enterprise or multiple large enterprises.

Since I do use multiple devices, when everything is on the web, you also don’t have to worry about syncing or conflict resolution like you do with semi connected scenarios.

> Native for Windows, Macs, Linux, iPhones and Android devices?

> Now imagine trying to update all of those native apps across a large enterprise or multiple large enterprises.

With the tools we have now, it would absolutely not work. In my post I was imagining a parallel alternate universe where native development tools got all the brainpower and innovation over the last 30 years, instead of the web tools getting it.

The web got it because for some _insane_ reason, websites were able to convince IT departments to allow scripts to run.

That left the barn door unlocked. Suddenly the download everything every time (or hope some is at least cached) environment of JavaScript / ECMAScript became the ONE place a user could 'for sure' 'install' (run someone else's unapproved) program.

Websites, _really_, should work just fine with zero scripts turned on. Possibly with the exception of a short list of trusted or user approved websites.

As opposed to native apps like the parent poster is proposing with no sandbox and that need to be created for each platform?

As opposed to applications authorized by professionals in charge of equipment.

???

Native development's story has been, for the longest time, the native way or the highway, which is precisely why it failed in favor of web where everyone begrudgingly supports a common feature set. No one wants to implement the same feature in five different native idioms.

And unfortunately, every system had their own way. Native development has suffered for decades from stubborn OS vendors who are incentivized against portability and cross-platform interoperability. Everyone's "way" was different and required you to rewrite your application to support it. I always wonder, if the web never took off as the common platform, would we today have better cross-platform native tools and APIs? I guess we'll never know.

There have been cross platform API and tools forever and they all suck and you end up not taking advantage of the platform and features.

Java Swing, Electron, QT, React Native, etc.

If you are going to create a “native” app that doesn’t take advantage of the platform features, you might as well just use the web.

Besides, it’s always a leaky abstraction that forces you to have some type of escape hatch to take advantage of subtleties of the platform.

Yes, but in fairness if operating systems don't differ then what's the point in having them.

This is the "what killed [os] innovation" problem: if nobody is writing native apps then there's no incentive to add new capabilities to your OS.

What's really needed here is a platform with the same advantages as the web, but which makes it much easier for OS vendors to expose proprietary capabilities. Then you will get innovation. Once browser makers killed off plugins it was over for desktop operating systems as outside of gaming (where innovation continues apace), there was no way to let devs write 90% cross platform code whilst still using the 10% special sauce.

It can work. I have spent several years of my life making it work :) Obviously, on mobile you have app stores including enterprise app stores.

On desktop you don't, or you do but they suck so people often don't want to use them. Making shipping desktop apps as easily as you can ship a web app is the goal of my company [1] and although it's always a work in progress it does get very close to that goal now. In particular:

- Once set up you can deploy with a single command that builds, signs, integrates auto update engines, renders icons, uploads and everything else. It's not harder than uploading a new version of a web app.

- Apps can do synchronous update checks on startup, web style, so once you push a new version everyone will get that version when they next start up the app. You can easily implement version checks whilst the app runs to remind users to restart after a while (big SPAs have the same issue if the server changes whilst user's tabs are still open).

- Apps can update in the background too.

- Delta updates make update times very low once the initial install is done.

- On Windows, apps from different vendors can share files. So if two apps share a runtime and it's stable enough that files don't change totally from version to version, the user won't have to download them. Unfortunately on other platforms this nice trick doesn't work, and in a world where runtimes update every few weeks it's of less value. But still.

All this works behind the firewall, also.

[1] https://hydraulic.dev/

We have JavaFX and Qt, and they're both better than ever, but they don't see much use. With JavaFX you can build and distribute a portable .jar file, and I think it can be used with JNLP/Java Web Start for distribution if you prefer that approach. With Qt, you're likely to be delivering self-contained native application packages in the target platform's native form.

(JavaFX has been carved out of the core JVM, which is annoying, but if the target machine has a JVM installed that bundles JavaFX, you're all set.)

I'm not sure you can say that Qt doesn't see much use, when there are hundreds, probably thousands, of well-known commercial apps using it, and it's in millions upon millions of embedded systems. And obviously KDE as well.

It's just it's largely invisible. It works, it does exactly the job it's meant to do, and it does it well.

Because most folks nowadays rather ship Chrome with their application, and then they complain Google has taken over the Web.

Indeed JavaFX is better than ever ;-) See https://www.jfx-central.com/ for many example applications, libraries, tutorials, etc.

The web as it was originally conceived - readable (but not interactive) content with linked resources - feels a far cry from the web of today, a platform for interactive applications that seems to grow asymptotically towards feature-parity with native applications (UI, input handling, data processing, hardware access) while never quite getting there, encompassing the fundamental things that make 'applications' work.

If the modern web _did_ reach feature parity in some way the real question would then be 'What makes it different?'. As linked resources doesn't seem like a particularly strong unique feature today the only other things I can think of are the simpler cross-platform experience and the ease of distribution.

So then the questions are 'What would make for a better cross-platform development experience?' (Chromium embedded framework not included) and 'How do we make app distribution seamless?' Is it feasible or sensible to have users expect to access every application just by visiting a named page and getting the latest version blasted at their browser?

And I guess that's how we got Chrome OS.

The web gained traction as a development platform because for the most part, it broadly works the same on every device due to the web standards, and so it's very easy to develop something that works consistently on all the different devices. Purists may bemoan that things no longer respect the "native look and feel" but that is a feature, not a bug, for the vast majority of users and developers. As an example, I absolutely hate that my work email on Outlook does not have the same feature set on Windows vs Mac vs whatever, and even in scenarios where application developers want to deliver the same features everywhere the minutiae of the native development patterns make it like herding cats.

It is basically the electrical plug of our era, in that it is a means to an end, never mind if 110V 60Hz is necessarily the most efficient way to deliver power in the home in North America.

> 'What would make for a better cross-platform development experience?'

Back in the day, people balked at using Java as a universal portable application platform, because ironically, everyone wanted their own language and their own platform semantics. Yet everyone on the planet has already unanimously agreed to a cross-platform development platform with a strict set of languages:

  - HTML/CSS for presenting text/style/layouts
  - Javascript for crafting and organizing the UI
  - WebAssembly for compiled code run in a VM
  - HTTP for IPC

So right there you have prescribed languages, formats, protocols. We gave up a single simple prescribed system for a more complicated one.

However, if you wanted to, you could get rid of the browser, and still support those same things - plus everything else a native app can do.

Separate those components into libraries, then link those libraries into your app, have your app load the libraries & components you want, and configure how the library should handle the presentation, UI, and business logic. You're then basically shipping a custom, streamlined browser - except it doesn't have to obey browser rules! It can run any code you want, because it's your app. It can present any way you want, because it's your app.

But it's also portable! The UI, the business logic, presentation, would all be using libraries ported to multiple platforms. Just recompile your app on the target platform. Avoid native code for an instant recompile, or add native code and deal with the portability tax.

It's sort of like compiling one browser on multiple platforms, except 1) it's broken down into components, 2) you can interchange those components with ones from different vendors that follow the same standards, and 3) you are not limited to these libraries - you can add your own native code.

In terms of interoperability with other apps, use the same network protocols, the same URIs. You can add new ones too, if you prefer, just for your own custom backend for your app... but probably everyone will stick to HTTP, because it's a universal way to access everyone's backend APIs or other native apps across sandboxes.

I wish an embedded TCL won over JS.

Also, I loved mozplugger. Embedded applications inside the browser.

For the younger HN users, mozplugger basically opened some videos/ audio / documents, by simply embedding some native window from an application inside the browser. That's it. For Windows users, imagine the Sumatra PDF subwindow inside a browser tab to open the PDF's. Or VLC for HD videos.

Video playing with mplayer under Linux was really fast in late 00's/early 10's.

Far better than today with Chrome embedding maybe ffmpeg like ass, not delivering the whole performance. Because even with WebkitGTK4, running MPV with some h264 based settings outperforms Luakit on <video> tags by a huge margin.

> So then the questions are 'What would make for a better cross-platform development experience?' (Chromium embedded framework not included) and 'How do we make app distribution seamless?'

The question for me isn't what would make for a better developer experience, it's what would make for a better user experience. And, personally, as a user, what makes my experience better is when I get to decide how an app looks and works, and the developer's say in that is more limited. That is the big flaw with web apps: too many app authors want to be artists and want to create custom interfaces and lots of shiny gizmos. I want apps to generally be using standardized widgets like menus and buttons whose look and feel is determined by the user's platform preferences and are not a bespoke creation of the app author.

I couldn't agree more, though it's kind of unfortunate that OS's are also going in the same direction. As meaningful innovation has, more or less, ended in the OS world - instead it's OS with shiny things I don't want, making controls look different just for the sake of looking different - sorry "new", packed with ad-tech I don't want, and soon undoubtedly to be packed with "AI" tech which I don't want.

And all of this forced upon you thanks to imposed obsolescence with things like hardware [in]compatibility with older OSs. The entire tech world is really screwed up with how adversarial companies have become with their "customers."

Yeah, when I found out what "client side decorations" are a little bit of me died inside. :-)

> An OS on an OS, in a document reader

Versus an interpreted language executed in a runtime running on a virtual thread of an OS running on top of a BIOS over a glorified calculator!? Insanity! Whatever happened to good old-fashioned pen and paper!?

There's nothing wrong with the model of delivering your software as a small program to run in a sandboxed browser environment. WASM, canvas, WebGL -- you can do nearly as much on the web as native nowadays, with a dead-simple deployment model. One of the only type of programs that's much harder to make in a web application is malware. Calling a modern browser a "networked document reader" is as silly as calling a modern computer a calculator.

The DOM seems fair to call a networked document reader. You've suggested a different build target for what would have been native apps - I think you and OP meet in the middle a bit; you get the power of non-html app development. OP laments the overhead of having to shove that into the existing web model designed for documents; you appreciate the sandboxing.

I think you have similar opinions that mostly overlap, regardless of insults about statements being silly.

You’re assuming that teaching fleshy monkeys to smear their gunk on glorified bathroom tissue was ever a good idea.

> Native apps can do literally anything.

That's just as much a downside as an upside. You're putting a lot of trust in a native app that you aren't putting in a website.

What about sandboxed native apps? If the browser can do it, why can't native apps do it as well?

It's much harder than it looks. I've investigated all this very deeply and should really write a blog post about it.

A blog post would be awesome, I haven't done a massive deep-dive. (and no pressure if you end up not writing it)

The gist is that native sandboxing is a mess of undocumented APIs, very different approaches between operating systems, one-size-fits-all policies, kernels are full of bugs, the whole setup is a nightmare to debug and to top it off there are no useful cross-platform abstractions. Not even Chrome has one; beyond Mojo the sandbox is a pile of special cases and platform specific code all over the codebase.

We have sandboxing technology on every modern operating system.

In HN spirit / guidelines, I'm going to presume the best.

Did you mean: "the web (as an application platform) will die" / once again swing back from mainframe / thin client to powerful local computing platforms?

In the spirit of empowering the user, I too hope the average user once again owns their destiny, the storage, computation, and control of their data. Though I think the web as a publishing media does empower that user if there are open platforms that promote the ability to choose any fulfillment partner they desire.

The web is just a convention that gained rapid adoption so now browsers dominate software. As far as conventions go, it is not bad compared to some of the stuff humans have landed on. Better than paving over everything so we can drive and park cars all over, better than everything being single use and disposable. Web has it's ups and downs but it is decent based on our track record.

I am exploring an alternative browser-like platform concept that would allow for near native performance. However established web protocols are hard to overcome.

Stagnation in viz design has pretty much nothing to do with the shrinking native<->web capability gap, and the web is here to stay.

Same here, although most of my UI work is on the Web nowadays, I miss the days when the browser was only for hypertext documents, and everything else was done natively with networking protocols, and standards.

Hence why my hobby coding has nothing to do with Web technologies, Web pays the bills, other stuff is for fun.

>>Native apps can do literally anything

like hack your banking account or steal your password...

Reply on news.ycombinator.com