8 ms·

Thanks for saying this, as I know a lot of people on HN have very negative feelings towards this trend. Personally, I feel the browser is a great way to stop re

by osrec 4y ago

Thanks for saying this, as I know a lot of people on HN have very negative feelings towards this trend. Personally, I feel the browser is a great way to stop reinventing the wheel, and the APIs abstract away a lot of the heavy lifting. They pretty much get you 80% of the way there, and the last 20% is where you can really add the stamp of "uniqueness" to your implementation. 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.

ryandrake 4y ago
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.
- MR4D 4y ago
  > Ship an entire physical PC to the user pre-loaded with the application? Ironically, that’s essentially what IBM did with mainframes. Another example of what’s old is new again.
  - arghwhat 4y ago
    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.
    - MR4D 4y ago
      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.
      - arghwhat 4y ago
        That sounds more like a case of "you're buying an app for our mainframes, so you'll need something to run it on".
- MereInterest 4y ago
  > 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.
- madelyn 4y ago
  > 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. Though yeah, I wish Slack was faster too.
  - MaxBarraclough 4y ago
    > 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.
    - water8 4y ago
      Could be for backwards/intergenerational compatibility because and hardware is no longer standardized for a console generation
- rafram 4y ago
  > 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!
- choeger 4y ago
  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.
  - gumby 4y 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.
  - rektide 4y ago
    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.
- noduerme 4y ago
  >> 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.
- account-5 4y ago
  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.
- ravenstine 4y ago
  > Then, Docker and containers (ship the whole OS with the application) 𝚃̶𝚘̶ ̶𝚋̶𝚎̶ ̶𝚏̶𝚊̶𝚒̶𝚛̶,̶ ̶𝚝̶𝚑̶𝚊̶𝚝̶'̶𝚜̶ ̶𝚜̶𝚑̶𝚒̶𝚙̶𝚙̶𝚒̶𝚗̶𝚐̶ ̶𝚝̶𝚑̶𝚎̶ ̶̶𝚔̶𝚎̶𝚛̶𝚗̶𝚎̶𝚕̶̶ ̶𝚊̶𝚗̶𝚍̶ ̶𝚗̶𝚎̶𝚎̶𝚍̶𝚎̶𝚍̶ ̶𝚙̶𝚊̶𝚌̶𝚔̶𝚊̶𝚐̶𝚎̶𝚜̶ ̶𝚠̶𝚒̶𝚝̶𝚑̶ ̶𝚝̶𝚑̶𝚎̶ ̶𝚊̶𝚙̶𝚙̶𝚕̶𝚒̶𝚌̶𝚊̶𝚝̶𝚒̶𝚘̶𝚗̶.̶ ̶ ̶𝚃̶𝚑̶𝚊̶𝚝̶'̶𝚜̶ ̶𝚙̶𝚎̶𝚍̶𝚊̶𝚗̶𝚝̶𝚒̶𝚌̶,̶ ̶𝙸̶ ̶𝚔̶𝚗̶𝚘̶𝚠̶,̶ ̶𝚊̶𝚗̶𝚍̶ ̶𝚠̶𝚑̶𝚒̶𝚕̶𝚎̶ ̶𝚠̶𝚑̶𝚊̶𝚝̶ ̶𝚢̶𝚘̶𝚞̶ ̶𝚜̶𝚊̶𝚒̶𝚍̶ ̶𝚒̶𝚜̶ ̶̶𝚝̶𝚎̶𝚌̶𝚑̶𝚗̶𝚒̶𝚌̶𝚊̶𝚕̶𝚕̶𝚢̶̶ ̶𝚝̶𝚛̶𝚞̶𝚎̶,̶ ̶𝚛̶𝚎̶𝚖̶𝚘̶𝚟̶𝚒̶𝚗̶𝚐̶ ̶𝚘̶𝚗̶𝚎̶ ̶𝚕̶𝚎̶𝚟̶𝚎̶𝚕̶ ̶𝚘̶𝚏̶ ̶𝚊̶𝚋̶𝚜̶𝚝̶𝚛̶𝚊̶𝚌̶𝚝̶𝚒̶𝚘̶𝚗̶ ̶𝚏̶𝚛̶𝚘̶𝚖̶ ̶𝚝̶𝚑̶𝚎̶ ̶𝚍̶𝚎̶𝚜̶𝚌̶𝚛̶𝚒̶𝚙̶𝚝̶𝚒̶𝚘̶𝚗̶ ̶𝚛̶𝚎̶𝚊̶𝚕̶𝚕̶𝚢̶ ̶𝚌̶𝚑̶𝚊̶𝚗̶𝚐̶𝚎̶𝚜̶ ̶𝚝̶𝚑̶𝚎̶ ̶𝚖̶𝚎̶𝚊̶𝚗̶𝚒̶𝚗̶𝚐̶ ̶𝚜̶𝚒̶𝚐̶𝚗̶𝚒̶𝚏̶𝚒̶𝚌̶𝚊̶𝚗̶𝚝̶𝚕̶𝚢̶.̶ ̶ ̶𝚃̶𝚑̶𝚎̶ ̶𝙻̶𝚒̶𝚗̶𝚞̶𝚡̶ ̶𝚔̶𝚎̶𝚛̶𝚗̶𝚎̶𝚕̶ ̶𝚘̶𝚗̶ ̶𝚒̶𝚝̶𝚜̶ ̶𝚘̶𝚠̶𝚗̶ ̶𝚒̶𝚜̶ ̶𝚜̶𝚘̶𝚖̶𝚎̶𝚝̶𝚑̶𝚒̶𝚗̶𝚐̶ ̶𝚕̶𝚒̶𝚔̶𝚎̶ ̶𝟷̶𝟶̶ ̶𝚖̶𝚎̶𝚐̶𝚊̶𝚋̶𝚢̶𝚝̶𝚎̶𝚜̶.̶ 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.
  - easrng 4y ago
    I thought docker used the host kernel with a different rootfs?
    - ravenstine 4y ago
      Apologies... I've been thinking in Docker For Mac Land. Yes, I think what you're saying is correct if you're running Docker on a Linux host.
  - cpuguy83 4y ago
    Containers don't ship a kernel, just the userspace.
    - deleted 4y ago
      [deleted]
- rektide 4y ago
  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. [1] "Writing an App is Like Coding for Laserdisc" https://shkspr.mobi/blog/2022/09/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 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 https://news.ycombinator.com/item?id=29807022 (558 points, 8mo ago, 419comments)
- amelius 4y ago
  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.
bonestamp2 4y ago
If I understand you comment correctly, WebAssembly is on a path to give you that web based container that can be as powerful as your computer allows while still being sandboxed in the browser.
- psychoslave 4y ago
  https://tomassetti.me/wasi-how-to-run-webassembly-code-outside-of-your-browser/ https://tomassetti.me/wasi-how-to-run-webassembly-code-outsi...
PaulDavisThe1st 4y ago
> Personally, I feel the browser is a great way to stop reinventing the wheel 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?
_Algernon_ 4y ago
The browser is inefficient. Use a modern website on a ten year old laptop and it is close to unusable because of modern web dev practices. That laptop is still perfectly usable for a lot of things. 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.
- meltedcapacitor 4y ago
  "modern web practices" may be more to blame than the browser. It's possible to make lean fast things running on browsers (within reason), but the culture is nobody gets fired for bloat. It's ubiquitous, same for mobile apps, server side, etc.
  - account42 4y ago
    The browser is responsible for providing web developers with ever-increasing resources to eat up. It also defers way an increasing amount of much functionality to javascript (or at least allows javascript to reimplement that functionality) - e.g. there is no native support for DASH video so you are always beholden to whatever js the website uses (unless you want to use website-specific hacks).
- loudmax 4y ago
  There's no desktop standard. Desktop operating systems are either proprietary or niche. Any application you write needs to be ported again to each operating system separately. 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.

by osrec 4y ago

ryandrake 4y ago

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.

MR4D 4y ago
> Ship an entire physical PC to the user pre-loaded with the application? Ironically, that’s essentially what IBM did with mainframes. Another example of what’s old is new again.
- arghwhat 4y ago
  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.
  - MR4D 4y ago
    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.
    - arghwhat 4y ago
      That sounds more like a case of "you're buying an app for our mainframes, so you'll need something to run it on".
MereInterest 4y ago
> 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.
madelyn 4y ago
> 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. Though yeah, I wish Slack was faster too.
- MaxBarraclough 4y ago
  > 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.
  - water8 4y ago
    Could be for backwards/intergenerational compatibility because and hardware is no longer standardized for a console generation
rafram 4y ago
> 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!
choeger 4y ago
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.
- gumby 4y 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.
- rektide 4y ago
  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.
noduerme 4y ago
>> 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.
account-5 4y ago
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.
ravenstine 4y ago
> Then, Docker and containers (ship the whole OS with the application) 𝚃̶𝚘̶ ̶𝚋̶𝚎̶ ̶𝚏̶𝚊̶𝚒̶𝚛̶,̶ ̶𝚝̶𝚑̶𝚊̶𝚝̶'̶𝚜̶ ̶𝚜̶𝚑̶𝚒̶𝚙̶𝚙̶𝚒̶𝚗̶𝚐̶ ̶𝚝̶𝚑̶𝚎̶ ̶̶𝚔̶𝚎̶𝚛̶𝚗̶𝚎̶𝚕̶̶ ̶𝚊̶𝚗̶𝚍̶ ̶𝚗̶𝚎̶𝚎̶𝚍̶𝚎̶𝚍̶ ̶𝚙̶𝚊̶𝚌̶𝚔̶𝚊̶𝚐̶𝚎̶𝚜̶ ̶𝚠̶𝚒̶𝚝̶𝚑̶ ̶𝚝̶𝚑̶𝚎̶ ̶𝚊̶𝚙̶𝚙̶𝚕̶𝚒̶𝚌̶𝚊̶𝚝̶𝚒̶𝚘̶𝚗̶.̶ ̶ ̶𝚃̶𝚑̶𝚊̶𝚝̶'̶𝚜̶ ̶𝚙̶𝚎̶𝚍̶𝚊̶𝚗̶𝚝̶𝚒̶𝚌̶,̶ ̶𝙸̶ ̶𝚔̶𝚗̶𝚘̶𝚠̶,̶ ̶𝚊̶𝚗̶𝚍̶ ̶𝚠̶𝚑̶𝚒̶𝚕̶𝚎̶ ̶𝚠̶𝚑̶𝚊̶𝚝̶ ̶𝚢̶𝚘̶𝚞̶ ̶𝚜̶𝚊̶𝚒̶𝚍̶ ̶𝚒̶𝚜̶ ̶̶𝚝̶𝚎̶𝚌̶𝚑̶𝚗̶𝚒̶𝚌̶𝚊̶𝚕̶𝚕̶𝚢̶̶ ̶𝚝̶𝚛̶𝚞̶𝚎̶,̶ ̶𝚛̶𝚎̶𝚖̶𝚘̶𝚟̶𝚒̶𝚗̶𝚐̶ ̶𝚘̶𝚗̶𝚎̶ ̶𝚕̶𝚎̶𝚟̶𝚎̶𝚕̶ ̶𝚘̶𝚏̶ ̶𝚊̶𝚋̶𝚜̶𝚝̶𝚛̶𝚊̶𝚌̶𝚝̶𝚒̶𝚘̶𝚗̶ ̶𝚏̶𝚛̶𝚘̶𝚖̶ ̶𝚝̶𝚑̶𝚎̶ ̶𝚍̶𝚎̶𝚜̶𝚌̶𝚛̶𝚒̶𝚙̶𝚝̶𝚒̶𝚘̶𝚗̶ ̶𝚛̶𝚎̶𝚊̶𝚕̶𝚕̶𝚢̶ ̶𝚌̶𝚑̶𝚊̶𝚗̶𝚐̶𝚎̶𝚜̶ ̶𝚝̶𝚑̶𝚎̶ ̶𝚖̶𝚎̶𝚊̶𝚗̶𝚒̶𝚗̶𝚐̶ ̶𝚜̶𝚒̶𝚐̶𝚗̶𝚒̶𝚏̶𝚒̶𝚌̶𝚊̶𝚗̶𝚝̶𝚕̶𝚢̶.̶ ̶ ̶𝚃̶𝚑̶𝚎̶ ̶𝙻̶𝚒̶𝚗̶𝚞̶𝚡̶ ̶𝚔̶𝚎̶𝚛̶𝚗̶𝚎̶𝚕̶ ̶𝚘̶𝚗̶ ̶𝚒̶𝚝̶𝚜̶ ̶𝚘̶𝚠̶𝚗̶ ̶𝚒̶𝚜̶ ̶𝚜̶𝚘̶𝚖̶𝚎̶𝚝̶𝚑̶𝚒̶𝚗̶𝚐̶ ̶𝚕̶𝚒̶𝚔̶𝚎̶ ̶𝟷̶𝟶̶ ̶𝚖̶𝚎̶𝚐̶𝚊̶𝚋̶𝚢̶𝚝̶𝚎̶𝚜̶.̶ 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.
- easrng 4y ago
  I thought docker used the host kernel with a different rootfs?
  - ravenstine 4y ago
    Apologies... I've been thinking in Docker For Mac Land. Yes, I think what you're saying is correct if you're running Docker on a Linux host.
- cpuguy83 4y ago
  Containers don't ship a kernel, just the userspace.
  - deleted 4y ago
    [deleted]
rektide 4y ago
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. [1] "Writing an App is Like Coding for Laserdisc" https://shkspr.mobi/blog/2022/09/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 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 https://news.ycombinator.com/item?id=29807022 (558 points, 8mo ago, 419comments)
amelius 4y ago
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.

bonestamp2 4y ago

If I understand you comment correctly, WebAssembly is on a path to give you that web based container that can be as powerful as your computer allows while still being sandboxed in the browser.

psychoslave 4y ago
https://tomassetti.me/wasi-how-to-run-webassembly-code-outside-of-your-browser/ https://tomassetti.me/wasi-how-to-run-webassembly-code-outsi...

PaulDavisThe1st 4y ago

> Personally, I feel the browser is a great way to stop reinventing the wheel 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?

_Algernon_ 4y ago

The browser is inefficient. Use a modern website on a ten year old laptop and it is close to unusable because of modern web dev practices. That laptop is still perfectly usable for a lot of things. 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.

meltedcapacitor 4y ago
"modern web practices" may be more to blame than the browser. It's possible to make lean fast things running on browsers (within reason), but the culture is nobody gets fired for bloat. It's ubiquitous, same for mobile apps, server side, etc.
- account42 4y ago
  The browser is responsible for providing web developers with ever-increasing resources to eat up. It also defers way an increasing amount of much functionality to javascript (or at least allows javascript to reimplement that functionality) - e.g. there is no native support for DASH video so you are always beholden to whatever js the website uses (unless you want to use website-specific hacks).
loudmax 4y ago
There's no desktop standard. Desktop operating systems are either proprietary or niche. Any application you write needs to be ported again to each operating system separately. 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.