9 ms·

All software is web software now

79 points by paulgb 4y ago

ocimbote 4y ago
True in a quite limited way: you have to ignore servers, embedded, mobile, games and probably more I didn't think of here.
- bckr 4y ago
  All of those use HTTP, to the author's point.
  - AnimalMuppet 4y ago
    Some embedded devices use HTTP. Many do not, for anything, ever. (Do your anti-lock brakes use HTTP? I strongly suspect they do not.)
    - bckr 4y ago
      "All of those /categories/ use HTTP"
  - PaulDavisThe1st 4y ago
    TFA was not about using HTTP, but about the development of applications that run "in the browser".
    - bckr 4y ago
      That's untrue. An accurate, less clickbaity title for the article would be "Web-centric technologies are ubiquitous in all types of software now".
zwieback 4y ago
I'd say "all GUIs" are web software now. Outside of that there's still plenty of traditional development.
- dehrmann 4y ago
  There's a huge lesson in this. Web's layout engine is really bad, but because so many developers have experience in it and it works everywhere, it makes sense to build Electron apps.
  - dasil003 4y ago
    The "works everywhere" part is the original reason (developer mindshare grew from that). It's hard to fathom how big a chasm it was to cross for a truly cross-platform open-standard GUI environment to reach critical mass such that every general purpose computer + OS must support it out of the box. It's not like Sun, Macromedia and Trolltech didn't take their shot, but these things need skin in the game from the OEM/OS side in order to succeed. It's the same structural advantages that ultimately loosened Microsoft's iron grip on profitable software in the early 00s.
  - voat 4y ago
    How is it really bad? With flexbox and grid I believe it's the most capable layout engine available.
  - marcosdumay 4y ago
    Web rendering is flexible to a degree that has no parallel in any other stack. Of course, that means that developers just reach for the most advertised rigid framework, so that they don't need to deal with all that freedom.
  - wildrhythms 4y ago
    What issue do you have with 'web's layout engine'?
avgDev 4y ago
I started out my career writing a small business application that was sideloaded on 20+ devices. There were many bugs, as this was my first professional project. I was literally figuring out how APIs work and how to move data between the android app and the server. Many poor decisions were made. Every update was extremely painful as users were not technical, so often I would have to collect the devices and perform the updates myself. It was a mess. Then, I decided to use the web instead. I was more experienced in it and bugs were much easier to handle. Every device on the local network could access it, no need for installs. You do miss out on some built-in features but for me it was a good sacrifice.
recursive 4y ago
Close. Some is not though. DAWs, AAA games, other hardware intensive things.
- bckr 4y ago
  DAWs use XML, to the author's point. I'm not familiar enough with AAA development but I wouldn't be surprised at all if JSON and XML make a showing there as well. That's not to mention that if the game is online, it certainly uses some combination of HTTP and sockets.
  - capableweb 4y ago
    Which DAWs use XML specifically? Haven't digged deep, but I never found any XML when dealing with any DAW. Games don't use HTTP (or WebSockets, which I suppose you mean) for gameplay. Maybe for stats, lobbies or such, but gameplay networking mostly happens over UDP.
    - PaulDavisThe1st 4y ago
      Ardour uses XML (and thus so does Mixbus and the now defunct-but-available Waves Tracks Live).
    - bckr 4y ago
      Take any DAW project file and unzip it. It's probably XML. True for Ableton Live and Reaper.
    - symfoniq 4y ago
      Cubase uses XML for config files (expression maps, etc).
  - rootlocus 4y ago
    Last time I was interested in this, most AAA games used some sort of html solution for UIs: scaleform [1] / awesomium / ultralight [2]. 1. https://www.birdtools-developers.com/scaleform/ https://www.birdtools-developers.com/scaleform/ 2. https://ultralig.ht/ https://ultralig.ht/
agentultra 4y ago
If this is the case I hope it gets better because the standards process seems to be failing these days. I need to keep at least two browsers on a machine in case a site I use doesn't work with one of them. It seems that since the standards process is largely controlled by commercial vendors we're regressing back to that era of the web where vendors largely ignored standards and touted their own tech/extensions/etc. Update: Not to mention how often buggy they can be and how terrible the performance is in terms of energy usage, responsiveness, etc.
brundolf 4y ago
Make sure you read the article; the contents are not exactly the same as the title.
- paulgb 4y ago
  That's fair, it was hard to condense the gist of it into a few words. I think (hope!) the opening paragraph is a good summary of what it's actually about, though: > Here’s a theory: browsers, by sheer force of adoption, become the standard bearer for every domain of software they touch, even usurping incumbent standard bearers. As browsers become more capable, this is encompassing a large fraction of software standards. In a certain sense, (nearly) all software is now web software. In this sense “web software” is broadly meant in the same sense that software that deals with Linux standards might be called “linux software”, and the point of the article is the surprising amount of influence browser developers have over software (and even hardware) we don't usually think of as being “web software”.
  - brundolf 4y ago
    Definitely. I think it's a nice way to frame it and I didn't mean to imply it was deceptive. I just see lots of people in the comments here saying things like "Nuh-uh! Apps X, Y, and Z are still written in native languages", which if they'd clicked the link they'd know is not at all the point being made in the article
tester756 4y ago
We need e.g Linux basic tools to switch / start supporting web-ish data format - json as their output e.g df -h --json so we do not need parsers for every tool, but one coherent format which is already popular and has built in parser for every lang out there
- thibran 4y ago
  Or just use a shell that understands JSON and can just pipe the output to JSON. In Nushell you can query the free space and then add `| to json` and you are done.
  - tester756 4y ago
    What do you mean? how it'd work for the "df -h | to_json"? could you please paste the json you're receiving? how does it understand the structure returned yb df -h?
- ilyash 4y ago
  The idea of JSON output is brought up regularly. Very interesting project that helps with that is https://wiki.freebsd.org/LibXo https://wiki.freebsd.org/LibXo Meanwhile, there is jc so that jc df returns JSON. See https://github.com/kellyjonbrazil/jc https://github.com/kellyjonbrazil/jc Hope this helps.
redleggedfrog 4y ago
IMHO and we're worse off for it. I still keep around non-web versions of old software like Picassa that are so much better than the web alternatives now being offered. We've given up a lot for being able to run in a web browser. Web UI is janky and fussy and time consuming to use. I've been using computers since 1988, and the UI now is the worst it's ever been for anything other than dicking around doing half-assed work.
- dangus 4y ago
  These are some seriously rose tinted glasses. What I remember about computers in the 90’s was incompatibility and inconsistency. The last paragraph of the article is worth revisiting. I couldn’t use the same features between Windows and Mac, and the Linux version of commercial apps would barely work if they existed at all. Fighting with codecs, flash player, macromedia, incompatible file formats, ActiveX, RealPlayer, etc. No way to easily extend functionality in the way that web based apps’ APIs offer. How do you connect information between two unrelated applications in the 90’s? The answer is that you didn’t! On top of that, plenty of applications are still just regular local applications. We can use Picassa as an example. Many of its alternatives are not even web-based, including Apple Photos (native app, does not require iCloud or Internet at all), Adobe Lightroom, and many free alternatives like gThumb. The thing is, most web-based applications are web-based because the web is so powerful and useful. For example, VSCode would lose its powerful extension ecosystem if it wasn’t web-based. The whole reason it’s so successful is that any web developer can make an extension easily. On top of that, the app works the same on Mac, Windows, Linux, even inside a web browser. What would we gain by the app no longer being based on web technologies that wouldn’t be offset by the lost functionality? Offline apps are still developed, and they’re developed for uses where that makes more sense. For example, DaVinci Resolve, Affinity Photo, and Final Cut Pro are all regular non-web applications, because that’s what makes sense for them.
  - mike_hearn 4y ago
    It can be spun both ways. - Fighting with codecs? Indeed, gone if you use the web because one or two browser makers force a lowest common denominator codec on everyone to keep their own IP costs low. Would your use case benefit from a higher quality codec and you're willing to pay for it? Pound sand, you get what Mozilla wants you to get even if you don't use Firefox. - Flash player? Indeed, gone because one man didn't like it. Would you benefit from the highly artist friendly timeline and vector art system Flash had, the compact binary format, the powerful animation system? Did you enjoy animated web comics made by people with tons of artistic skill and no coding abilities? Pound sand, you get CSS animations and you can roll the rest on your own (which nobody does). - How do you connect information between two unrelated applications in the 1990s? Wow, pick your poison. DCOM/OLE was the most advanced implementation of this, but Apple had OpenDoc. Apps could expose components that implemented standardized APIs, they could expose sophisticated object models allowing you to reflect and script them from many kinds of language, they had a more powerful equivalent of iframing and so on. What does web tech give you that can match this? Nothing! If two web apps can connect to each other it's because of a bespoke integration. Browsers think they're drawing scientific documents so they don't have any notion of a page having an API. Every web API is a horrible hack in which you pretend some code is actually a pile of "documents". Schemas, API conventions, tooling, language binding is all totally scattershot. There's not really any such thing as just scripting a web app from a language of your choice like Windows managed decades ago, it's all custom each and every time. "most web-based applications are web-based because the web is so powerful and useful" Will have to disagree with that. The web lacks many basic features once considered essential. People like making web apps for the desktop (not mobile) because of things like sandboxing, convenient server connectivity, "instant on" without (un)installation, clickable URLs without extra effort, no piracy risks, monitoring and metrics coming for free, blurred lines between documents and apps etc. Basically because of the stuff that browsers happen to expose as an artifact of their implementation and evolution path. There's other reasons too (e.g. Microsoft/Apple dropped the ball on window management, a ball picked up by tabbed browsers) but I won't try and make a comprehensive list of all of them here. That's a future project :) Oh, also and hugely importantly, because distributing desktop apps is much harder than it should be - there's lots of legacy tech and platform differences making it awkward. That's absolutely fixable though. In fact, my new startup is getting ready to launch a tool that makes distributing desktop apps as easy as distributing web apps. It's not quite launched yet but there's a mailing list form you can fill out at https://hydraulic.software https://hydraulic.software if you're interested. The goal here is to start at the beginning: make it easy to distribute apps outside the browser, and then start to explore platforms that retain most of the benefits of a browser whilst fixing their weak points. It should be especially useful for the community of developers interested in building decentralized apps, which are a very poor fit for web tech.
PaulDavisThe1st 4y ago
Except, of course, for browsers themselves. Oh, and video editors. DAWs. Console-y video games. Compilers. Linkers. Operating systems. The overwhelming majority of mobile apps. Dental imaging systems. Robot assisted surgery systems. CNC controllers. Scientific data analysis. GPT-N. Jeesh. Browser-at-platform offers some amazing possibilities, but get your head out of the sand and grasp the scope of what software actually is and does.
- brundolf 4y ago
  Gentle reminder to read the article
  - waffletower 4y ago
    Gentle reminder to the author that naming is hard.
    - brundolf 4y ago
      I think it was an intentional riff on/reframing of the phrase. They lay out the intended meaning very plainly at the top
  - PaulDavisThe1st 4y ago
    I read the whole article. The final two sentences of the opening paragraph: > As browsers become more capable, this is encompassing a large fraction of software standards. In a certain sense, (nearly) all software is now web software. This is just bullshit, that can only be written by someone too immersed in web-centric development to understand the full scope of software development and design.
    - brundolf 4y ago
      They were being intentionally hyperbolic. Most of the domains you listed have at least been touched by one web technology or another, whether that be JavaScript, HTTP, video codecs, etc. Nobody's saying literally all software, but virtually every domain has been affected at least a little bit by a web-related standard or technology. Chill out.
mike_hearn 4y ago
OK, let's break down and analyze the authors arguments which IMO, are good, but perhaps are more of a jumping off point than a conclusion. He argues that web tech tends to leak out of browsers and into other domains. There are lots of examples of this. This occurs because: 1. Web tech is hard to change after launch due to the sheer size of the web and the amount of abandoned content, so it remains stable and is designed to be general. Developers like both. 2. Browser tech is subsidized by ads and hardware sales so has big budgets yet gets given away for free. 3. Browser makers (or rather, Google/Mozilla) insist on patent-free technologies. This can potentially kill off or stymie the development of more advanced tech, in particular in the codec space, but it's convenient. He then argues that WebAssembly, WebGPU and QUIC will be the next technologies to go the way of JSON, XML etc and get widespread adoption outside the browser. And that's about it. The author passes little judgement on this trend beyond observing that it happens. There's definitely a lot of reasons why our industry has settled on (let's face it) abusing a document format and document renderers as a way to distribute software, and Paul identifies some of them. In particular the rigorous commitment to backwards compatibility in a way that's PM-promotion-proof is hard to beat. It comes from a combination of the enormous amount of free content that any new browser (version) wants to be able to render, along with the network reachability of that content allowing very solid regression testing programmes. Other platforms tend not to test against their user's codebases in the same way that browser makers do. Still, there's a lot of dissatisfaction with web tech out there because it was simply never meant for what we do with it and the seams are really showing these days. The sheer number of pre-processors and languages-transpiling-to-other-languages that modern web tech involves is a testament to that. It feels like there's scope for competitors to the web stack to arise. I've noticed a lot of developers like to spin implausible stories about the importance of being on the web and how "nobody downloads apps anymore", but there's not much concrete evidence for this. Mobile/tablet is obviously a major hole in this theory, along with the fact that people actually download Chrome itself, the success of Minecraft, the existence of the entire video games industry etc. People often end up over-betting on web tech because they like the idea of a standards based platform, but then quietly hit its limitations and give up (most notable example: Steve Jobs). I remember when WebGL was new there was a wave of predictions that video games would all be web apps in future. Yeah, didn't happen. What would a competitor want to emulate about the web? There's a million things that could be written about what the web does well and badly, but to focus on just one issue raised in the article you'd really want a way to discover downloadable apps that were built with the platform, so you could download them and run them against new versions of your platform. Once you can precisely measure how much stuff your new version breaks you can then set metrics around it and drive it to zero, so developers get a rock solid platform with no regressions. It'd also let you quantify the cost of breaking backwards compatibility (which should discourage it). You'd probably also want a much higher degree of modularity. Although the article claims web tech keeps leaving the browser and being reused this is really more in spite of browser makers, not because of them. The Chrome team don't actually care about anything they do being used outside of Chrome itself, which is why stuff like Electron and NodeJS all come from external organizations, and why there's tons of useful tech in the Chromium codebase that languishes unused. It's not well documented, it's often not particularly well modularized, etc. Any competitor could certainly do better and provide more like an IKEA kit of components that, in one instantiation, happens to provide a browser like experience with sandboxing, tabs, code streaming etc, but in others could be more like an Electron-style library experience.
marcosdumay 4y ago
Well, that's what you get when network operators block everything that is not the web.
chrisweekly 4y ago
Great post, thanks for sharing. HTTP really is pretty amazing.
sto_hristo 4y ago
Well, not all at all. But there is so much desktop software going on the web and that is a good thing. You don't have to install it to use it and it doesn't need the performance and native capability of the bare metal.
tabtab 4y ago
But web standards are crappy for decent GUI/CRUD applications that typically are used on a desktop, which is most business software. Web standards natively lack state handling, and the DOM makes sanely controlling the position of text a royal bear. We really need a state-ful GUI markup standard. Bending the web to do that job makes for really ugly stacks and/or resulting software. Related: https://www.reddit.com/r/web_design/comments/uzttbu/zardotabs_forced_ui_choice_principle/ https://www.reddit.com/r/web_design/comments/uzttbu/zardotab...
jenkstom 4y ago
For those of us maintaining any of the billions of lines of legacy code that runs the majority of IT... nope. A lot of use cases can be covered by the web ecosystem, but a lot can't as well. This seems to be a common fantasy or fallacy of developers under a certain age (I too far from that age to guess). I suspect because of the amount of dedication required to keep up with front-end technologies. The reason it's so complex is because it's a bad fit. Soon enough everything will be WASM and we'll be right back where we were in the 90's with the "thin client" vs "thick client" debate. The good part of it is that there ARE some problems being solved. WASM is a good start on trusted computing, and that's not going to go away ever. Unless that other fantasy of my generation (X-Gen) comes true - post-apocalyptic societal collapse. Not sure that could be called a "fantasy", maybe "collective nightmare" is a better term for it.
mikewarot 4y ago
>HTML started as a format for hypertext documents, but as it became more capable, applications jumped on it as a cross-platform UI layout engine. I wish HTML actually allowed markup of hypertext. The most productive parts of the design space got truncated with the mistake of flatting markup INTO the text.
dusted 4y ago
Thank god it is not, but the problem is certainly getting worse at an aggressive rate. This too will pass, the cycle towards the mainframe way of thinking will swing back to the idea of personal compyting again sometime in the future.

79 points by paulgb 4y ago

True in a quite limited way: you have to ignore servers, embedded, mobile, games and probably more I didn't think of here.

bckr 4y ago
All of those use HTTP, to the author's point.
- AnimalMuppet 4y ago
  Some embedded devices use HTTP. Many do not, for anything, ever. (Do your anti-lock brakes use HTTP? I strongly suspect they do not.)
  - bckr 4y ago
    "All of those /categories/ use HTTP"
- PaulDavisThe1st 4y ago
  TFA was not about using HTTP, but about the development of applications that run "in the browser".
  - bckr 4y ago
    That's untrue. An accurate, less clickbaity title for the article would be "Web-centric technologies are ubiquitous in all types of software now".

zwieback 4y ago

I'd say "all GUIs" are web software now. Outside of that there's still plenty of traditional development.

dehrmann 4y ago
There's a huge lesson in this. Web's layout engine is really bad, but because so many developers have experience in it and it works everywhere, it makes sense to build Electron apps.
- dasil003 4y ago
  The "works everywhere" part is the original reason (developer mindshare grew from that). It's hard to fathom how big a chasm it was to cross for a truly cross-platform open-standard GUI environment to reach critical mass such that every general purpose computer + OS must support it out of the box. It's not like Sun, Macromedia and Trolltech didn't take their shot, but these things need skin in the game from the OEM/OS side in order to succeed. It's the same structural advantages that ultimately loosened Microsoft's iron grip on profitable software in the early 00s.
- voat 4y ago
  How is it really bad? With flexbox and grid I believe it's the most capable layout engine available.
- marcosdumay 4y ago
  Web rendering is flexible to a degree that has no parallel in any other stack. Of course, that means that developers just reach for the most advertised rigid framework, so that they don't need to deal with all that freedom.
- wildrhythms 4y ago
  What issue do you have with 'web's layout engine'?

avgDev 4y ago

I started out my career writing a small business application that was sideloaded on 20+ devices. There were many bugs, as this was my first professional project. I was literally figuring out how APIs work and how to move data between the android app and the server. Many poor decisions were made. Every update was extremely painful as users were not technical, so often I would have to collect the devices and perform the updates myself. It was a mess. Then, I decided to use the web instead. I was more experienced in it and bugs were much easier to handle. Every device on the local network could access it, no need for installs. You do miss out on some built-in features but for me it was a good sacrifice.

recursive 4y ago

Close. Some is not though. DAWs, AAA games, other hardware intensive things.

bckr 4y ago
DAWs use XML, to the author's point. I'm not familiar enough with AAA development but I wouldn't be surprised at all if JSON and XML make a showing there as well. That's not to mention that if the game is online, it certainly uses some combination of HTTP and sockets.
- capableweb 4y ago
  Which DAWs use XML specifically? Haven't digged deep, but I never found any XML when dealing with any DAW. Games don't use HTTP (or WebSockets, which I suppose you mean) for gameplay. Maybe for stats, lobbies or such, but gameplay networking mostly happens over UDP.
  - PaulDavisThe1st 4y ago
    Ardour uses XML (and thus so does Mixbus and the now defunct-but-available Waves Tracks Live).
  - bckr 4y ago
    Take any DAW project file and unzip it. It's probably XML. True for Ableton Live and Reaper.
  - symfoniq 4y ago
    Cubase uses XML for config files (expression maps, etc).
- rootlocus 4y ago
  Last time I was interested in this, most AAA games used some sort of html solution for UIs: scaleform [1] / awesomium / ultralight [2]. 1. https://www.birdtools-developers.com/scaleform/ https://www.birdtools-developers.com/scaleform/ 2. https://ultralig.ht/ https://ultralig.ht/

agentultra 4y ago

If this is the case I hope it gets better because the standards process seems to be failing these days. I need to keep at least two browsers on a machine in case a site I use doesn't work with one of them. It seems that since the standards process is largely controlled by commercial vendors we're regressing back to that era of the web where vendors largely ignored standards and touted their own tech/extensions/etc. Update: Not to mention how often buggy they can be and how terrible the performance is in terms of energy usage, responsiveness, etc.

brundolf 4y ago

Make sure you read the article; the contents are not exactly the same as the title.

paulgb 4y ago
That's fair, it was hard to condense the gist of it into a few words. I think (hope!) the opening paragraph is a good summary of what it's actually about, though: > Here’s a theory: browsers, by sheer force of adoption, become the standard bearer for every domain of software they touch, even usurping incumbent standard bearers. As browsers become more capable, this is encompassing a large fraction of software standards. In a certain sense, (nearly) all software is now web software. In this sense “web software” is broadly meant in the same sense that software that deals with Linux standards might be called “linux software”, and the point of the article is the surprising amount of influence browser developers have over software (and even hardware) we don't usually think of as being “web software”.
- brundolf 4y ago
  Definitely. I think it's a nice way to frame it and I didn't mean to imply it was deceptive. I just see lots of people in the comments here saying things like "Nuh-uh! Apps X, Y, and Z are still written in native languages", which if they'd clicked the link they'd know is not at all the point being made in the article

tester756 4y ago

We need e.g Linux basic tools to switch / start supporting web-ish data format - json as their output e.g df -h --json so we do not need parsers for every tool, but one coherent format which is already popular and has built in parser for every lang out there

thibran 4y ago
Or just use a shell that understands JSON and can just pipe the output to JSON. In Nushell you can query the free space and then add `| to json` and you are done.
- tester756 4y ago
  What do you mean? how it'd work for the "df -h | to_json"? could you please paste the json you're receiving? how does it understand the structure returned yb df -h?
ilyash 4y ago
The idea of JSON output is brought up regularly. Very interesting project that helps with that is https://wiki.freebsd.org/LibXo https://wiki.freebsd.org/LibXo Meanwhile, there is jc so that jc df returns JSON. See https://github.com/kellyjonbrazil/jc https://github.com/kellyjonbrazil/jc Hope this helps.

redleggedfrog 4y ago

IMHO and we're worse off for it. I still keep around non-web versions of old software like Picassa that are so much better than the web alternatives now being offered. We've given up a lot for being able to run in a web browser. Web UI is janky and fussy and time consuming to use. I've been using computers since 1988, and the UI now is the worst it's ever been for anything other than dicking around doing half-assed work.

dangus 4y ago
These are some seriously rose tinted glasses. What I remember about computers in the 90’s was incompatibility and inconsistency. The last paragraph of the article is worth revisiting. I couldn’t use the same features between Windows and Mac, and the Linux version of commercial apps would barely work if they existed at all. Fighting with codecs, flash player, macromedia, incompatible file formats, ActiveX, RealPlayer, etc. No way to easily extend functionality in the way that web based apps’ APIs offer. How do you connect information between two unrelated applications in the 90’s? The answer is that you didn’t! On top of that, plenty of applications are still just regular local applications. We can use Picassa as an example. Many of its alternatives are not even web-based, including Apple Photos (native app, does not require iCloud or Internet at all), Adobe Lightroom, and many free alternatives like gThumb. The thing is, most web-based applications are web-based because the web is so powerful and useful. For example, VSCode would lose its powerful extension ecosystem if it wasn’t web-based. The whole reason it’s so successful is that any web developer can make an extension easily. On top of that, the app works the same on Mac, Windows, Linux, even inside a web browser. What would we gain by the app no longer being based on web technologies that wouldn’t be offset by the lost functionality? Offline apps are still developed, and they’re developed for uses where that makes more sense. For example, DaVinci Resolve, Affinity Photo, and Final Cut Pro are all regular non-web applications, because that’s what makes sense for them.
- mike_hearn 4y ago
  It can be spun both ways. - Fighting with codecs? Indeed, gone if you use the web because one or two browser makers force a lowest common denominator codec on everyone to keep their own IP costs low. Would your use case benefit from a higher quality codec and you're willing to pay for it? Pound sand, you get what Mozilla wants you to get even if you don't use Firefox. - Flash player? Indeed, gone because one man didn't like it. Would you benefit from the highly artist friendly timeline and vector art system Flash had, the compact binary format, the powerful animation system? Did you enjoy animated web comics made by people with tons of artistic skill and no coding abilities? Pound sand, you get CSS animations and you can roll the rest on your own (which nobody does). - How do you connect information between two unrelated applications in the 1990s? Wow, pick your poison. DCOM/OLE was the most advanced implementation of this, but Apple had OpenDoc. Apps could expose components that implemented standardized APIs, they could expose sophisticated object models allowing you to reflect and script them from many kinds of language, they had a more powerful equivalent of iframing and so on. What does web tech give you that can match this? Nothing! If two web apps can connect to each other it's because of a bespoke integration. Browsers think they're drawing scientific documents so they don't have any notion of a page having an API. Every web API is a horrible hack in which you pretend some code is actually a pile of "documents". Schemas, API conventions, tooling, language binding is all totally scattershot. There's not really any such thing as just scripting a web app from a language of your choice like Windows managed decades ago, it's all custom each and every time. "most web-based applications are web-based because the web is so powerful and useful" Will have to disagree with that. The web lacks many basic features once considered essential. People like making web apps for the desktop (not mobile) because of things like sandboxing, convenient server connectivity, "instant on" without (un)installation, clickable URLs without extra effort, no piracy risks, monitoring and metrics coming for free, blurred lines between documents and apps etc. Basically because of the stuff that browsers happen to expose as an artifact of their implementation and evolution path. There's other reasons too (e.g. Microsoft/Apple dropped the ball on window management, a ball picked up by tabbed browsers) but I won't try and make a comprehensive list of all of them here. That's a future project :) Oh, also and hugely importantly, because distributing desktop apps is much harder than it should be - there's lots of legacy tech and platform differences making it awkward. That's absolutely fixable though. In fact, my new startup is getting ready to launch a tool that makes distributing desktop apps as easy as distributing web apps. It's not quite launched yet but there's a mailing list form you can fill out at https://hydraulic.software https://hydraulic.software if you're interested. The goal here is to start at the beginning: make it easy to distribute apps outside the browser, and then start to explore platforms that retain most of the benefits of a browser whilst fixing their weak points. It should be especially useful for the community of developers interested in building decentralized apps, which are a very poor fit for web tech.

PaulDavisThe1st 4y ago

Except, of course, for browsers themselves. Oh, and video editors. DAWs. Console-y video games. Compilers. Linkers. Operating systems. The overwhelming majority of mobile apps. Dental imaging systems. Robot assisted surgery systems. CNC controllers. Scientific data analysis. GPT-N. Jeesh. Browser-at-platform offers some amazing possibilities, but get your head out of the sand and grasp the scope of what software actually is and does.

brundolf 4y ago
Gentle reminder to read the article
- waffletower 4y ago
  Gentle reminder to the author that naming is hard.
  - brundolf 4y ago
    I think it was an intentional riff on/reframing of the phrase. They lay out the intended meaning very plainly at the top
- PaulDavisThe1st 4y ago
  I read the whole article. The final two sentences of the opening paragraph: > As browsers become more capable, this is encompassing a large fraction of software standards. In a certain sense, (nearly) all software is now web software. This is just bullshit, that can only be written by someone too immersed in web-centric development to understand the full scope of software development and design.
  - brundolf 4y ago
    They were being intentionally hyperbolic. Most of the domains you listed have at least been touched by one web technology or another, whether that be JavaScript, HTTP, video codecs, etc. Nobody's saying literally all software, but virtually every domain has been affected at least a little bit by a web-related standard or technology. Chill out.

mike_hearn 4y ago

OK, let's break down and analyze the authors arguments which IMO, are good, but perhaps are more of a jumping off point than a conclusion. He argues that web tech tends to leak out of browsers and into other domains. There are lots of examples of this. This occurs because: 1. Web tech is hard to change after launch due to the sheer size of the web and the amount of abandoned content, so it remains stable and is designed to be general. Developers like both. 2. Browser tech is subsidized by ads and hardware sales so has big budgets yet gets given away for free. 3. Browser makers (or rather, Google/Mozilla) insist on patent-free technologies. This can potentially kill off or stymie the development of more advanced tech, in particular in the codec space, but it's convenient. He then argues that WebAssembly, WebGPU and QUIC will be the next technologies to go the way of JSON, XML etc and get widespread adoption outside the browser. And that's about it. The author passes little judgement on this trend beyond observing that it happens. There's definitely a lot of reasons why our industry has settled on (let's face it) abusing a document format and document renderers as a way to distribute software, and Paul identifies some of them. In particular the rigorous commitment to backwards compatibility in a way that's PM-promotion-proof is hard to beat. It comes from a combination of the enormous amount of free content that any new browser (version) wants to be able to render, along with the network reachability of that content allowing very solid regression testing programmes. Other platforms tend not to test against their user's codebases in the same way that browser makers do. Still, there's a lot of dissatisfaction with web tech out there because it was simply never meant for what we do with it and the seams are really showing these days. The sheer number of pre-processors and languages-transpiling-to-other-languages that modern web tech involves is a testament to that. It feels like there's scope for competitors to the web stack to arise. I've noticed a lot of developers like to spin implausible stories about the importance of being on the web and how "nobody downloads apps anymore", but there's not much concrete evidence for this. Mobile/tablet is obviously a major hole in this theory, along with the fact that people actually download Chrome itself, the success of Minecraft, the existence of the entire video games industry etc. People often end up over-betting on web tech because they like the idea of a standards based platform, but then quietly hit its limitations and give up (most notable example: Steve Jobs). I remember when WebGL was new there was a wave of predictions that video games would all be web apps in future. Yeah, didn't happen. What would a competitor want to emulate about the web? There's a million things that could be written about what the web does well and badly, but to focus on just one issue raised in the article you'd really want a way to discover downloadable apps that were built with the platform, so you could download them and run them against new versions of your platform. Once you can precisely measure how much stuff your new version breaks you can then set metrics around it and drive it to zero, so developers get a rock solid platform with no regressions. It'd also let you quantify the cost of breaking backwards compatibility (which should discourage it). You'd probably also want a much higher degree of modularity. Although the article claims web tech keeps leaving the browser and being reused this is really more in spite of browser makers, not because of them. The Chrome team don't actually care about anything they do being used outside of Chrome itself, which is why stuff like Electron and NodeJS all come from external organizations, and why there's tons of useful tech in the Chromium codebase that languishes unused. It's not well documented, it's often not particularly well modularized, etc. Any competitor could certainly do better and provide more like an IKEA kit of components that, in one instantiation, happens to provide a browser like experience with sandboxing, tabs, code streaming etc, but in others could be more like an Electron-style library experience.

marcosdumay 4y ago

Well, that's what you get when network operators block everything that is not the web.

chrisweekly 4y ago

Great post, thanks for sharing. HTTP really is pretty amazing.

sto_hristo 4y ago

Well, not all at all. But there is so much desktop software going on the web and that is a good thing. You don't have to install it to use it and it doesn't need the performance and native capability of the bare metal.

tabtab 4y ago

But web standards are crappy for decent GUI/CRUD applications that typically are used on a desktop, which is most business software. Web standards natively lack state handling, and the DOM makes sanely controlling the position of text a royal bear. We really need a state-ful GUI markup standard. Bending the web to do that job makes for really ugly stacks and/or resulting software. Related: https://www.reddit.com/r/web_design/comments/uzttbu/zardotabs_forced_ui_choice_principle/ https://www.reddit.com/r/web_design/comments/uzttbu/zardotab...

jenkstom 4y ago

For those of us maintaining any of the billions of lines of legacy code that runs the majority of IT... nope. A lot of use cases can be covered by the web ecosystem, but a lot can't as well. This seems to be a common fantasy or fallacy of developers under a certain age (I too far from that age to guess). I suspect because of the amount of dedication required to keep up with front-end technologies. The reason it's so complex is because it's a bad fit. Soon enough everything will be WASM and we'll be right back where we were in the 90's with the "thin client" vs "thick client" debate. The good part of it is that there ARE some problems being solved. WASM is a good start on trusted computing, and that's not going to go away ever. Unless that other fantasy of my generation (X-Gen) comes true - post-apocalyptic societal collapse. Not sure that could be called a "fantasy", maybe "collective nightmare" is a better term for it.

mikewarot 4y ago

>HTML started as a format for hypertext documents, but as it became more capable, applications jumped on it as a cross-platform UI layout engine. I wish HTML actually allowed markup of hypertext. The most productive parts of the design space got truncated with the mistake of flatting markup INTO the text.

dusted 4y ago

Thank god it is not, but the problem is certainly getting worse at an aggressive rate. This too will pass, the cycle towards the mainframe way of thinking will swing back to the idea of personal compyting again sometime in the future.