It just feels like every time software developers can't (or won't) build things cross-platform, users end up with bigger and bloatier solutions and poorer experiences.
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.
> Ship an entire physical PC to the user pre-loaded with the application?
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.
> A phone (hi iOS), a video game console, a smart appliance, etc. are examples of this.
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.
You're absolutely correct. IMO, the reason is, to a large degree, ineptness of software engineers. It simply doesn't pay to hire or train high-quality SEs, if you're not google or Amazon (and even they probably only hire and pay the best to prevent competition).
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.
> You're absolutely correct. IMO, the reason is, to a large degree, ineptness of software engineers.
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.
I agree with what you wrote 99% but draw a different conclusion.
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 see so much growth & positivity, so much can-do-ism. Everyone's doing great things, but in particular the web has brought about a much higher access to systems that seem much safer for users, much more sandboxed, with better tools/extensions/navigability/accessibility/hackability, that have much more open source activity going on than native (which has been to huge benefit in so many ways: to productivity, to learning, to exploring, to having fun, to creating social cultures & groups).
> 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.
> Ship an entire physical PC to the user pre-loaded with the application?
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.
>> Ship an entire physical PC to the user pre-loaded with the application?
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.
Eh? Mainframes are and always were general purpose computers, and run stufd like Linux just fine.
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.
I never commented on the specificity, rather I pointed out this quote "Ship an entire physical PC to the user pre-loaded with the application." Replace "PC" with "Mainframe" and the sentence was true (at least back when mainframes were a thing.
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.
The problem with HTML is that it is not a layered technology. It's all or nothing.
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.
Operating systems like WebOS, KaiOS/Firefox OS, ChromeOS largely do away with many layers of the stack, by making the web technology front & center. I do think you're right that perhaps some layers could go, but I think native apps & much of the native OS itself are far closer to the LaserDisc technology[1] that we can get rid of.
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.
I've being wondering about this myself for a personal project.
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.
> Ship an entire physical PC to the user pre-loaded with the application?
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!
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.