The fact that the browser is also heavily sandboxed is another big benefit. I personally feel safer using a web app than a native app on any device, any day. You just don't know what a native app might be doing in the background, but with a web app, I feel things are much more transparent.

I can potentially see a future where you could deploy docker-like containers directly from the browser, while keeping the same fine grained controls that a browser allows. Then it really would make the web a truly flexible, infrastructure agnostic application delivery platform.

First, it was cross-platform UI toolkits and OS abstractions like Qt (require users to use a big, "lowest common denominator compromise" library )

Then, it was web apps (require users to provide a browser)

Then, it was Electron and friends (ship the whole browser with the application)

Then, Docker and containers (ship the whole OS with the application)

Where do we go from here? Ship an entire physical PC to the user pre-loaded with the application? We keep trading away the end user's resources and convenience to gain developer's time and resources. All to keep (badly) solving the "Well, it works on my computer" class of problems.

A phone (hi iOS), a video game console, a smart appliance, etc. are examples of this.

Building cross platform, native applications is expensive (comparatively) to building web applications.

I made an FM synthesizer in the browser using WASM and the webaudio api just for personal use. I wouldn't have made it if I had to write it as a native app, because native apps are a time sink and annoyance to me (I mean, I'm on linux anyways. I probably have to use either GTK or QT anyways!!!)

Demand for software is MASSIVE right now, and making shipping easier, even if the end product isn't as fast, does have value.

Though yeah, I wish Slack was faster too.

Related to this: iirc, games for the Xbox One (and presumable the latest generation 'Series' consoles) always run in a VM, with their own kernel and graphics drivers.

Instead, the industry as a whole hands out more "productive" tools, i.e., the abstraction layers you mentioned, in order to build ever more trivial applications (that don't work properly in most of the cases anyways).

I think that we're in a downwards spiral at this point: Business doesn't make enough money per line of code to hire or train really good engineers. Tries to push out more software, resulting in more crap. Software quality sinks. Business makes even less money per line of code. Engineers throw the towel and are replaced by less experienced people. Rinse and repeat.

Hmm, software engineers? IMO the culprits are "greedy" managers who didn't like (and still don't like) common libraries, file systems etc. Motto: "It must be my standard, or else ..." Where's the common (license free and secure, encryptable) standardised file system, to exchange data between all platforms, including digital cameras and other gadgets? Where's the graphics API? Java tried to answer some of these questions, but failed miserably IMHO.

My experience: as soon as I learned to use some API or framework, at least two new APIs or frameworks showed up posing as the best thing since sliced bread. Sorry for the sarcasm, but I lost my optimism regarding software development some years ago.

The 1% where I don't agree: most developers aren't engineers. These days companies hire engineers for stuff that is hard and important. But most do not need that.

And my impression is that that is a good thing. There's been a real democratization of development which means there's a lot of software being written. Most applications I see are fundamentally CRUD apps, and while I'm a bit fearful of the security of the banking apps, the massive frameworks are at least designed (implicitly at least) to reduce complexity and steer people towards some "best practices". Any kid today can build something that only a couple of decades ago (or less) really did need serious engineering.

We've followed the same path before. Rich people used to hire chauffeurs who didn't just drive but performed maintenance on the cars. Then people knew how to change tyres, gap their spark plugs etc. Now people know how to turn the key and steer around the road, hopefully not killing too many people in the process. Next, they'll only need to know how to step into the vehicle.

We should be glad software is going that way. It's not like that will reduce employment for engineers.

> I think that we're in a downwards spiral at this point

I'm mainly writing a reply just to say: I have huge hope we're on an great upward ascent & have made things increasingly better.

> IMO, the reason is, to a large degree, ineptness of software engineers.

I sometimes encounter less than optimal code or solutions, but the amount of times that it matters is unbelievably little. Focusing on really good engineers making really excellent decisions is, not, to me, a critical issue in most places. I think there's a lot of value in just finding the budget to support open source engineers, in trying to support good community efforts, like Web Incubation specs, like Bytecode Alliance. Time & care, about doing good things for community, over time, is the incomparable advantage, is the prime requirement of turning acceptable/passable/maybe-a-little-defect-y code into something that really works well & serves & is/has-become enduring.

> Instead, the industry as a whole hands out more "productive" tools, i.e., the abstraction layers you mentioned,

I see so little harm to using the good, well embraced, ultra productive, mid-industrial toolset we've grown into. And I see so little benefit to trying to go any other way. We should respect resource consumption, and some apps (webapp and native both) do bad jobs, but the layers mentioned seem like a vanish point of concern, far far far down where I think computing needs to be dwelling & caring & trying to do better. There's so few examples that there are real gains to be made from abandoning the layers we have; efforts like react-native show we can do basically the same high-production technioques at a native layer, but the rewards for doing it native have almost never materialized; just using the web stack continues to be good.

I think there are far more productive things to be debating & discussing, as we decide where to orient ourselves & the next steps of computing to. Worrying about these stacks has infected too much of the online discourse time spent, has become a mind-virus.

I'm going to guess that there will be a few intermediate steps, with the additional goal of removing rights to your own computer.

After Docker and containers, an image for a virtual machine, to provide a kernel and not just the libraries.

After virtual machines, a connection to a remote machine, to avoid downloading the entire image and reduce your first-use bandwidth.

After connections to remote machines, a "co-located server", with an abstraction layer between using the remote machine to reduce first-use bandwidth and using the machine in your house to reduce latency.

Which is all to say that I wouldn't be surprised if it happened that way over the next 10-20 years, resulting in you renting the computer that sits in your own house.

𝚃̶𝚘̶ ̶𝚋̶𝚎̶ ̶𝚏̶𝚊̶𝚒̶𝚛̶,̶ ̶𝚝̶𝚑̶𝚊̶𝚝̶'̶𝚜̶ ̶𝚜̶𝚑̶𝚒̶𝚙̶𝚙̶𝚒̶𝚗̶𝚐̶ ̶𝚝̶𝚑̶𝚎̶ ̶̶𝚔̶𝚎̶𝚛̶𝚗̶𝚎̶𝚕̶̶ ̶𝚊̶𝚗̶𝚍̶ ̶𝚗̶𝚎̶𝚎̶𝚍̶𝚎̶𝚍̶ ̶𝚙̶𝚊̶𝚌̶𝚔̶𝚊̶𝚐̶𝚎̶𝚜̶ ̶𝚠̶𝚒̶𝚝̶𝚑̶ ̶𝚝̶𝚑̶𝚎̶ ̶𝚊̶𝚙̶𝚙̶𝚕̶𝚒̶𝚌̶𝚊̶𝚝̶𝚒̶𝚘̶𝚗̶.̶ ̶ ̶𝚃̶𝚑̶𝚊̶𝚝̶'̶𝚜̶ ̶𝚙̶𝚎̶𝚍̶𝚊̶𝚗̶𝚝̶𝚒̶𝚌̶,̶ ̶𝙸̶ ̶𝚔̶𝚗̶𝚘̶𝚠̶,̶ ̶𝚊̶𝚗̶𝚍̶ ̶𝚠̶𝚑̶𝚒̶𝚕̶𝚎̶ ̶𝚠̶𝚑̶𝚊̶𝚝̶ ̶𝚢̶𝚘̶𝚞̶ ̶𝚜̶𝚊̶𝚒̶𝚍̶ ̶𝚒̶𝚜̶ ̶̶𝚝̶𝚎̶𝚌̶𝚑̶𝚗̶𝚒̶𝚌̶𝚊̶𝚕̶𝚕̶𝚢̶̶ ̶𝚝̶𝚛̶𝚞̶𝚎̶,̶ ̶𝚛̶𝚎̶𝚖̶𝚘̶𝚟̶𝚒̶𝚗̶𝚐̶ ̶𝚘̶𝚗̶𝚎̶ ̶𝚕̶𝚎̶𝚟̶𝚎̶𝚕̶ ̶𝚘̶𝚏̶ ̶𝚊̶𝚋̶𝚜̶𝚝̶𝚛̶𝚊̶𝚌̶𝚝̶𝚒̶𝚘̶𝚗̶ ̶𝚏̶𝚛̶𝚘̶𝚖̶ ̶𝚝̶𝚑̶𝚎̶ ̶𝚍̶𝚎̶𝚜̶𝚌̶𝚛̶𝚒̶𝚙̶𝚝̶𝚒̶𝚘̶𝚗̶ ̶𝚛̶𝚎̶𝚊̶𝚕̶𝚕̶𝚢̶ ̶𝚌̶𝚑̶𝚊̶𝚗̶𝚐̶𝚎̶𝚜̶ ̶𝚝̶𝚑̶𝚎̶ ̶𝚖̶𝚎̶𝚊̶𝚗̶𝚒̶𝚗̶𝚐̶ ̶𝚜̶𝚒̶𝚐̶𝚗̶𝚒̶𝚏̶𝚒̶𝚌̶𝚊̶𝚗̶𝚝̶𝚕̶𝚢̶.̶ ̶ ̶𝚃̶𝚑̶𝚎̶ ̶𝙻̶𝚒̶𝚗̶𝚞̶𝚡̶ ̶𝚔̶𝚎̶𝚛̶𝚗̶𝚎̶𝚕̶ ̶𝚘̶𝚗̶ ̶𝚒̶𝚝̶𝚜̶ ̶𝚘̶𝚠̶𝚗̶ ̶𝚒̶𝚜̶ ̶𝚜̶𝚘̶𝚖̶𝚎̶𝚝̶𝚑̶𝚒̶𝚗̶𝚐̶ ̶𝚕̶𝚒̶𝚔̶𝚎̶ ̶𝟷̶𝟶̶ ̶𝚖̶𝚎̶𝚐̶𝚊̶𝚋̶𝚢̶𝚝̶𝚎̶𝚜̶.̶

EDIT: What I've said is not exactly correct. If you're not running Docker on a Linux host, then you'll have a Linux kernel running in emulation but it's not shipping with containers. Not sure what I was thinking. I believe this is closer to the truth.

Believe it or not, I've done this, and I have to maintain a small fleet of them now. The software in question functions as a server/database for a mobile app that's only used by employees on a given job site. It was deployed before Docker was a thing.

Ironically, that’s essentially what IBM did with mainframes.

Another example of what’s old is new again.

Nowadays they are mainly meant as machines with extreme reliability guarantees, from things like running multiple processors in lockstep to detect spontaneous processor errors, but they're still just computers.

While their cost makes them hugely impractical for .øst usecases, mainframes do have some really cool tech, including their new CPU designs with quite interesting cache layouts.

The software came pre-loaded with the hardware, and IBM shipped it to you and set it up for you. You couldn't buy an app without paying for the hardware. Technically, you rented everything from IBM, and paid one lease price.

And sadly it will get more complicated over time.

I just figured that at some point we should start over with a very simple sandbox that allows to run all the webgl renderers, javascript interpreters, css parsers, and whatnot, inside it. This simple sandbox would also be more secure, because of its simplicity.

Reciprocally, on the server, there's definitely traction strong traction with webassembly being the de-facto platform for glue/extensions/user-code, owing to it's super sandboxing & capability systems like WASI. Being able to take any langauge, compile to wasm, and distribute & safely run that module has been a huge upgrade, and a very nice bit of platform that historically wasn't really available/commonplace on "native".

Your issue with "Electron and friends" is wrong. As you say, Electron does at present bundle a whole browser in each app. But many "friends" have new approaches. Tauri recently went 1.0, and generally builds off the already available WebView that all major OSes include[2]. I'd be interested to see what kind of fear/concern you'd present if Electron also had a more respectful shared-library usage-pattern.

[1] "Writing an App is Like Coding for Laserdisc" https://shkspr.mobi/blog/2022/09/writing-an-app-is-like-codi... https://news.ycombinator.com/item?id=32723192 (153 points, 1d ago, 184 comments)

[2] "Tauri [1.0] - Electron alternative written in rust" https://news.ycombinator.com/item?id=29807022 (558 points, 8mo ago, 419comments)

I don't want to have to code the project in multiple native languages, and likely wouldn't be able to without massive amounts of time learning each language.

Similarly I want access to native APIs, some of which browsers don't have. And I don't want to run a website to host my app.

I'm currently learning dart/flutter due to this. IMO it is the answer. You may disagree.

Maybe not that, but it’s becoming popular to run high-intensity programs on a remote server and stream video to the user’s machine, both for pretty sensible reasons (e.g. Stadia for games) and totally nonsensical ones (e.g. Mighty for Google Chrome). It’s mainframes all over again!

The modern web drives obsolescence second only to gaming, but while gaming is user driven and entertainment focused (i.e. not essential), the web is megacorp driven and also includes necessary modern infrastructure.

That is all around a bad thing.

The web is the closest thing there is to a ubiquitous operating system. And with the development around WASM, performance and efficiency is getting closer and closer to native. That's along with built-in security and sandboxing.

This is all around a good thing.

This is an optimistic take on the near- and mid-term evolution of software. What makes you think that working inside the browser will stop wheel reinvention? Have you not tracked the endless reinvention of "the right way" to do interactive app development inside the browser?

Same.

My latest project is a waveform generator for wavetable synthesizers [1]; there are visualizations, as well as handling audio (not real time but still). I was surprised that I could build that as a web app and achieve good UX and performance.

[1]: https://merely.xyz/waves

DDG search does not help much [1], [2]

Any pointers ?

1: https://duckduckgo.com/?q=waveform+generator+for+wavetable+s...

2: https://duckduckgo.com/?q=wavetable+synthesizers&ia=web

And your domain is really cool too. I presume it’s like a self deprecating math joke.

The .xyz pun was not intended, but it does make a lot of sense for a math related app. Thanks for spotting that too!

- Very hard for me to find the play button.. took like 10s of looking. I looked at the segment buttons

- Accidentally, I got some really cool sounds by mashing the play button to overlay it. Not sure why it gets distorted if it should be playing the same waves. But it sounds cool

My worry is basically that the absent functionality is the best thing about the web as a user. Take the notification API: One of the nice things about web pages and apps is that they stop bothering me once I close them; not so if I accidentally permit notifications! Fortunately I can turn that whole feature off, but at first I found myself wondering who ever thought that would be a good idea.

Yes I picked an extreme example, and I don't actually mind some of these things. I wish there were a permission pop-up before playing sound at all. Also, WebGL does concern me, since heavy GPU usage can draw a lot of power. Things like gamepad support and spatial audio (if they are behind permission pop-ups) don't really bother me, though.

> I wish there were a permission pop-up before playing sound at all

The browser can't actually play sound unless 1) it's triggered as the result of a user action (such as a mouse click) or 2) if you've often listened to sound on that page in the past.

Re: sound, "Triggered as the result of a user action" is not a high enough bar.

And the chat app, and the email app, and the social media app (other opinions about social media notwithstanding). I think each of these things have their own legitimate use for notifications.

I guess it's the point of "weakening a primary advantage". I don't see how it's weakened (or rather, I don't see how it's a problem) when the notifications are on a per site permission. Especially so when the notifications can be turned off completely per browser.

> Re: sound, "Triggered as the result of a user action" is not a high enough bar.

I'm with you on this. Although it took until this thread for me to realize that sound at all should be a permission.

The point is that a click should not give the website permission to play audio - that should be handled much explicitly and not just the user selecting text or some other interaction. Besides, last time I checked Firefox still let AudioContext play sound without any user interaction even though the <audio> element has more restrictions. Which is another problem: the HTML + JS spec is too bloated to properly secure things.

if you don't like it turn it off. arguing that things shouldn't exist just because you choose not to use them is pretty selfish.

[0]- With only anecdotes supporting my suspicion; I haven't done a rigorous study.

Some interesting ones:

- Screen recording/capture

- Battery status

- Barcode Detection

- Bluetooth

- Sensors (e.g. Accelerometer)

- Wake/screen lock

- Color picker

- Vibration

- MIDI

- USB

- Contacts picker

- Presentation (AirPlay, Chromecast)

- Virtual reality

I'm amazed at how quickly I can throw together a front end feature in JavaScript on my otherwise html site.

Really all of web impressed me over the desktop/app counterparts. I wrote and read to/from a php database with less than 2 hours of time. Laravel has me doing user authentication + useful coding in less than 40 hours after the tutorial.

No permissions required.

I had issues as recent as last year's new products.

But otherwise I love the concept of hardware access with HTML. The embedded guy in me thinks the future is going to be crazy. I can't quite wrap my head around the possibilities.

I also keep Bluetooth disabled on my mobile devices. It's used extensively to ID and track people and their devices. For things that don't move and are only ever paired to a single thing (like a speaker) it works fine. Most of the complaints I hear about bluetooth are from people who pair multiple devices to a single source and want to easily switch between them.

The underlying technology is terrible. HTML and CSS are for displaying documents. Things which should be trivial to add to an application UI (add a ListView, anchor element X to be left of element Y, etc) are nigh impossible without using some bloated toolkit anyway. JS is a slow and brittle language to work with.

The fact that the web became an application delivery platform is an unfortunate historical accident that I am not sure we can recover from.

If we devoted 10% of the engineering that went into "web technology" into an actual dedicated cross platform application platform, it would be way better than the web is today. Faster, less bloat, better technology so that we don't need frameworks on frameworks to do a hello world, etc.

I wish there was something similar for but for modern browsers, taking advantage of HTML5 and all the browser API's available now which previously required a plugin like adobe flash.

As you mentioned the API's and capabilities are there, built right into the browsers now. I just wish the tooling was better.

And also doing this declaratively makes it so much easier to secure & build well-thought-out privacy & consent UX around.

An imperative API has so many variations on implementation approach for the end-developer / API consumer that the combinatorics become much more challenging for browser implementers.

(obviously imperative APIs for doing this already exist, but the existence of this declarative API at least makes limiting imperative API access less draconian/severe as a measure).

For me the big thing holding it back is IndexedDB.

Actually in the process of designing a software solution that needs to work on desktop and mobile, and be able to write mission critical data while offline.

As much as I'd love to just make one responsive web app - I just can't trust the safari or even chrome browsers to not /dev/null users data if it feels like it.

Unfortunately what's convenient for you as a developer is more often than not hostile and awful UX for me as a user.

Too often, developer convenience trumps good UX.

Wouldn't be really a sandbox anymore if they could

Other than that... I'm not sure even I'd want to allow a webpage to do that.

I have made a web editor that uses this. There is an example pwa app Https://webide se/

The thing I like about it is what you just said.

And that's much better than Apps, where you are forced into an unfavorable ecosystem.

Any time I've tried to use WebGL... pain.

One of the best things about NIH-ing my own engine is that I don't need to make it generic, meaning one less layer of abstraction to complicate implementation and debugging.

https://aframe.io/