3 ms·

I'd take it even further. Browsers and things like Electron are just run-times. The browser's main advantage is cross-platform compatibility. But only kinda-

I'd take it even further. Browsers and things like Electron are just run-times. The browser's main advantage is cross-platform compatibility. But only kinda-sorta as any web developer can tell you. Your code is usually targeting 3 different run-times at a minimum and there are always problems with anything non-trivial. It is easy to imagine something much better, where your code runs on a nice tidy runtime native to the OS, with relatively easy layout tools and a language that is better than JavaScript (and really, what language isn't?). It'd be nice and fast, and rewarding to develop in. If we are starting anew, with fresh eyes, and we were handed browsers, with JavaScript, CSS, and the DOM, we'd be like, "This is complete BS. Visual VB for DOS has this beat." But because it grew organically, with instantly built in lock-in, and we're now thoroughly indoctrinated, the Stockholm Syndrome lives on. If you can just take 3 steps back it's fairly obvious. But people would rather just keep making the next React or Bootstrap and digging the hole deeper than make something better. Someday, make my words, there will be a cross-platform runtime that doesn't suck, that doesn't use JavaScript, and won't the stupid mistakes of the JRE, and developers will abandon web browsers as a platform in droves. I mean, can you really see this as the state of affairs in 2030? 2040? That'd just be sad. Edit: typo

arkanciscan 6y ago
> It is easy to imagine something much better, where your code runs on a nice tidy runtime native to the OS Yeah, cause that's how every native platform has been since the begining. Yet the web still needed to be invented. Why?
- Spivak 6y ago
  Because no two platforms can agree on anything so now we have "hosted platforms."
- thayne 6y ago
  The biggest reason is probably that you don't need the user to explicitly download and install your app. Also, a web app works on all the major OSes with a single GUI environment. And then of course the fact that webapps run in a more secure sandbox. A standard cross API and sandbox could potentially solve the second two. But I'm not sure how to solve the first outside of a browser.
megameter 6y ago
A big part of this browser creep was simply that there was friction and danger in native apps, but our demand for more kinds of apps was insatiable and the browser was able to soak up that demand. When you ran Windows 95, a misbehaved, even well-intentioned app could wreck your hard drive with relative ease. Most did not, but there are horror stories. And when you went to download it, well, nobody wanted all the clicks of downloading and installing. As ever, the average computer user is undisciplined and impatient. The market provided for this by pushing the browser as far as it could go, because it did text, forms and images and when you have those and a CGI script, you have an app. But now we have gone full circle to the browser being the operating system, and unsurprisingly, it's really bad, being in the position of being a "terrarium" for sandboxing all kinds of software behind an API of some sort. Nowadays we have the alternative models of the curated package manager/app store and more extensive virtualization techniques available. Last night I wanted to try an old Windows 3.1 game. It took a few hours to gather and configure everything but I eventually got DOSBox and Windows 3.11 for Workgroups installed and configured with all the drivers, and the game worked. But the experience of installing this antiquated software reminded me of how Windows itself was a solution to a related kind of compatibility problem: Every program on MS-DOS had ended up in the position of shipping drivers for everything - printer drivers, sound card drivers, SVGA drivers. The solution of Windows was to build a ton of APIs to hide the hardware, just like the browser hides the native APIs. And this solution is a kludge, but a productive one for the near term. It's premised on I/O being bespoken enough that it doesn't have a standard, but not so much so that it can't be addressed in some standardized form. And emulators take that thought in the other direction, adapting new, more capable I/O to old. But I don't think more terrariums (new runtimes) are necessarily the productive way forward. This always comes down to basic theories in and around CS - digital signal processing, Turing completeness, structured programming, relational data. The runtime is a certain endpoint of data that formats to an I/O medium, but it develops the terrarium structure when we start accommodating all forms of media and saying "well, you can set it up in any configuration".
gjvc 6y ago
the DOM is the root of all evil.

arkanciscan 6y ago

> It is easy to imagine something much better, where your code runs on a nice tidy runtime native to the OS Yeah, cause that's how every native platform has been since the begining. Yet the web still needed to be invented. Why?

Spivak 6y ago
Because no two platforms can agree on anything so now we have "hosted platforms."
thayne 6y ago
The biggest reason is probably that you don't need the user to explicitly download and install your app. Also, a web app works on all the major OSes with a single GUI environment. And then of course the fact that webapps run in a more secure sandbox. A standard cross API and sandbox could potentially solve the second two. But I'm not sure how to solve the first outside of a browser.

megameter 6y ago

A big part of this browser creep was simply that there was friction and danger in native apps, but our demand for more kinds of apps was insatiable and the browser was able to soak up that demand. When you ran Windows 95, a misbehaved, even well-intentioned app could wreck your hard drive with relative ease. Most did not, but there are horror stories. And when you went to download it, well, nobody wanted all the clicks of downloading and installing. As ever, the average computer user is undisciplined and impatient. The market provided for this by pushing the browser as far as it could go, because it did text, forms and images and when you have those and a CGI script, you have an app. But now we have gone full circle to the browser being the operating system, and unsurprisingly, it's really bad, being in the position of being a "terrarium" for sandboxing all kinds of software behind an API of some sort. Nowadays we have the alternative models of the curated package manager/app store and more extensive virtualization techniques available. Last night I wanted to try an old Windows 3.1 game. It took a few hours to gather and configure everything but I eventually got DOSBox and Windows 3.11 for Workgroups installed and configured with all the drivers, and the game worked. But the experience of installing this antiquated software reminded me of how Windows itself was a solution to a related kind of compatibility problem: Every program on MS-DOS had ended up in the position of shipping drivers for everything - printer drivers, sound card drivers, SVGA drivers. The solution of Windows was to build a ton of APIs to hide the hardware, just like the browser hides the native APIs. And this solution is a kludge, but a productive one for the near term. It's premised on I/O being bespoken enough that it doesn't have a standard, but not so much so that it can't be addressed in some standardized form. And emulators take that thought in the other direction, adapting new, more capable I/O to old. But I don't think more terrariums (new runtimes) are necessarily the productive way forward. This always comes down to basic theories in and around CS - digital signal processing, Turing completeness, structured programming, relational data. The runtime is a certain endpoint of data that formats to an I/O medium, but it develops the terrarium structure when we start accommodating all forms of media and saying "well, you can set it up in any configuration".

gjvc 6y ago

the DOM is the root of all evil.