10 ms·

"The earliest websites are viewable on modern browsers." The problem with this statement is that a website is not the same thing as an application. The web was

by Aaargh20318 4y ago

"The earliest websites are viewable on modern browsers." The problem with this statement is that a website is not the same thing as an application. The web was designed to publish documents, it was never intended to build applications. Saying that a document from the early web is still viewable while a fully interactive application from the same time is not is a bit disingenuous. As a platform for developing interactive applications the web is simply terrible. There is no good way to develop a UI in HTML/CSS/JS, all attempts to do so rely on layers upon layers of wat are essentially hacks to build something resembling a UI toolkit on top of a document markup language. The result a UI that is unnecessarily complicated and fragile. Laying out and rendering HTML and CSS is incredibly complex compared how traditional UI toolkits do the same task. That complexity comes at a cost, both in development time and in UX.

danwee 4y ago
Sure, but the lesson here is to improve the web (or to create some platform for apps, in the same spirit of the web), not to jump into walled gardens.
- layer8 4y ago
  From a certain perspective the browser is much more of a walled garden than native desktop development.
ChrisLTD 4y ago
> The web was designed to publish documents, it was never intended to build applications. But the web has been evolving in that direction with the help of standards bodies and browser vendors since at least the late 1990s.
- capableweb 4y ago
  > with the help of standards bodies and browser vendors Who are made out of people (developers) building for the web, and users of the web as well. Lets not pretend that these web applications were forced upon us by outside forces.
MontyCarloHall 4y ago
>Saying that a document from the early web is still viewable while a fully interactive application from the same time is not is a bit disingenuous. Indeed, though running a Java Applet from 1995 is a lot easier than running an iOS app from 2010. Although browsers haven’t natively supported Applets for a very long time, there are several third-party tools that let you run them as standalone applications. Good luck virtualizing a 10 year old version of iOS to do the same for the old app. That said, the argument in the OP holds true if we don’t go back in time quite as far. Most JavaScript-based single-page applications from 2010 should still run flawlessly in modern browsers.
- statictype 4y ago
  > Indeed, though running a Java Applet from 1995 is a lot easier than running an iOS app from 2010 Applets weren’t even easy to run in 1995.
  - mikepurvis 4y ago
    But somehow still way easier than booting up an old iOS.
- danjoredd 4y ago
  I discovered this unfortunate reality recently myself. In 2012 I was gifted by my parents a first gen Kindle Fire. I got a lot of free apps back then because Amazon had a "free game of the week" deal going on where a lot of normally paid apps would be temporarily free. Out of nostalgia I downloaded the Amazon App Store to my phone last month and found that not only were most of my favorite apps not in my library anymore, but that the few left over were built for a version of Android so old that it is no longer compatible with my phone. It was a very sad moment for me, as I had a lot of fun with those games
  - mysterydip 4y ago
    As a hobbyist game developer with several games of my own no longer available due to the marching on of OS versions, I sympathize. There just isn't enough time or incentive for me to keep old codebases current with arbitrary API changes.
YesWeWill 4y ago
With CSS Flexbox and Grid, the web is the best GUI app platform I know of (and I was a WinForms developer before). It is made for apps now, and it has been the goal for some time already - since HTML 5 at least, but I'd say it began as stated goal with DHTML.
- pjmlp 4y ago
  Ironically the CSS grid is based on WPF grid, and was originally proposed by the WPF team.
  - YesWeWill 4y ago
    Don't see the irony, WPF was a nice idea that should be copied - unfortunately they axed it before it could grow and then the general uncertainty forced me off the platform.
    - pjmlp 4y ago
      It is still there on Visual Studio, and with a more certain future than WinUI will ever get. The irony that the Web needs to keep copying native development experience, and it is still miles behind of what VB and Delphi were offering 30 years ago, unless one is paying for stuff like OutSystems or PowerApps.
      - YesWeWill 4y ago
        WPF might be there, but with all the "deprecated - oh not deprecated again - not deprecated but no updates for many years - deprecated again - not deprecated again" cycles I'm not going to touch it with 10-meter pole for anything that I need to support - same with anything else related to .NET. Also the UI designer experience for WPF is much worse than it used to be with WinForms - so bad I just wrote the code manually, and at that point I can just write HTML/CSS. But perhaps they fixed that - I left .NET in 2015. It doesn't run in the browser anyways - and the browser is what my customers want, because everyone has a browser, but not everyone has Windows desktop - especially today, when many people don't even own a PC and use something with Android/iOS as their primary computing device.
yesimahuman 4y ago
Many, many web developers would disagree with your assertion that you can't build great apps (including desktop and mobile (hello Electron and Capacitor)), or that the UI technologies available to web developers are a "hack" or aren't actually extremely productive and enjoyable to use. The argument that the web is only for documents and not app experiences is simply a relic of a different time.
- Aaargh20318 4y ago
  > your assertion you can't build great apps (including desktop and mobile (hello Electron and Capacitor)) I have yet to see a great app built on web technology. All Electron apps provide a terrible UX, they are slow, unresponsive and feel out of place with the rest of the OS I'm running on. I want my apps to feel native, to look and feel exactly like all other apps. One of the greatest tragedies of web UI's is the lack of a standard UI toolkit. Almost evert web-based app has to roll their own UI components, there is no consistency. This is terrible for usability, especially for users that are not as tech-savvy as we are. It's one thing to have to explain what a certain UI component is and does once, but it gets infinitely worse if every app has their own spin on it. Who doesn't love teaching their grandma 1232043 different variations on a checkbox ?
  - yesimahuman 4y ago
    This is just your opinion and perception then, because Electron apps have been hugely commercially successful and teams using it have built very strong experiences that users love. If they were so "terrible" and "out of place" users would reject them, and they don't. The HN crowd has been consistently wrong about this.
    - Aaargh20318 4y ago
      > If they were so "terrible" and "out of place" users would reject them, and they don't. You are acting like users have a choice. For example: Microsoft Teams is an abomination of an app. It's slow, clunky, eats memory like there is no tomorrow and feels totally out of place on macOS. Still it's a huge commercial succes and I use it every day, even though as a user I absolutely hate it. I simply have to use it because my employer chose it as the company collaboration tool. And they didn't choose it because of it's incredible UX, they chose it because we already have an Office365 subscription and it was included in that, so we already paid for it anyway. Some Electron apps have been huge commercial successes despite their terrible UX.
ravenstine 4y ago
> As a platform for developing interactive applications the web is simply terrible. This is where you lose me. For such a "terrible" platform, it sure has a lot of users now, don't it? Maybe you mean from a developer's perspective, and it's not unreasonable that someone might consider web tech terrible, so I'd be interested to know why they see it that way. > There is no good way to develop a UI in HTML/CSS/JS Nonsense. Most UIs suck in general. On the web, they suck a little more because HTML/CSS/JS have such a low barrier to entry, and the industry requires very little intellectual rigor that would cause one to think twice about "just npm install that shit, bruh." Despite that, there's no sensible reason why a "good" UI can't be built with web tech. The web is what you make of it. > all attempts to do so rely on layers upon layers of wat are essentially hacks You're going to have to explain what makes working within the confines of a webpage a "hack." Sometimes we create workarounds, but everything may need workarounds. > to build something resembling a UI toolkit It is a UI toolkit. > on top of a document markup language. Which many people agree is well suited for describing UIs, whether it's HTML or something else. > The result a UI that is unnecessarily complicated and fragile. The cause not being something wrong with webpages, but the choices developers make and the way organizations approach software development. Give me a fragile web app and I'll show you a fragile and hard to work with native codebase. > Laying out and rendering HTML and CSS is incredibly complex It's as complex as you make it out to be. None of what's on a webpage has to be complex. We make it complex because of a lack of actual engineering mindset and because HTML/CSS is relatively abstract and forgiving. If one doesn't prefer something that's forgiving, they can work with native code or something that transpiles to HTML/CSS. Doesn't mean HTML and CSS aren't capable of performing the job they've been doing for almost my entire lifetime now. > compared how traditional UI toolkits do the same task. Depends on the task. Depends on the toolkit. > That complexity comes at a cost, both in development time and in UX. As already stated, that complexity comes from no one but the developer. Given reasonable time, a developer should be able to build most UIs using web tech and have it working as intended. HTML, CSS, and even JS aren't really what most people consider complex about web development. What's insanely complex about modern web development, that people frequently complain about, is everything we've done to turn web development into Java development (i.e. a churn of build steps, toolchains, transpilers, runtimes, and so on).
layer8 4y ago
Win32 applications from (almost?) 30 years ago also still run on modern Windows. By a far margin, it’s a choice of keeping compatibility or not. In contrast, I had to stop using my favorite SSH application on iOS because the author had died and Apple stopped supporting 32-bit apps instead of providing a compatibility layer.
- RajT88 4y ago
  I run all 64 bit Windows 10. But, if I was on 32 bit, I wouldn't count out Windows 1.0 16 bit PE's from running: https://docs.microsoft.com/en-us/troubleshoot/windows-client/application-management/x64-windows-not-support-16-bit-programs https://docs.microsoft.com/en-us/troubleshoot/windows-client... If you want to try, extract disk4-apps.img: https://winworldpc.com/product/windows-10/101 https://winworldpc.com/product/windows-10/101
  - jcranmer 4y ago
    > Windows 1.0 16 bit PE's Point of order: 16-bit applications used the NE format, while PE was introduced to support 32-bit applications.
- hedora 4y ago
  Win32 apps also run extremely well in dosbox on Linux, etc.
selfmodruntime 4y ago
> As a platform for developing interactive applications the web is simply terrible. There is no good way to develop a UI in HTML/CSS/JS, all attempts to do so rely on layers upon layers of wat are essentially hacks to build something resembling a UI toolkit on top of a document markup language. The result a UI that is unnecessarily complicated and fragile. Laying out and rendering HTML and CSS is incredibly complex compared how traditional UI toolkits do the same task. That complexity comes at a cost, both in development time and in UX. This is so disingenuous and untrue that I‘m close to calling it an outright lie. Development of UI has never been easier, more accessible and better for the disabled than with web tooling. Any businesses from tiny startups to gigantic corporations can build value creating applications which generate billions of dollars of revenue which runs on almost all devices, using just one language and one code base. Browsers HTML and CSS parsers are incredibly generous in what they accept, allowing small markup mistakes in a latest update to not grind your operation to a halt. Modern HTML and CSS are dead simple to use, deliver sane defaults and capabilities which most browsers understand all the same. Never before has it been so easy to develop an application for your business with a language and frameworks millions of developers speak. Prototyping is incredibly simple. Modern browsers deliver incredibly tight sandboxes so malicious applications can neither access the information of other applications nor anything else on a targeted users system. Fake applications can be identified with SSL certificates in ways native applications never could. The web enables the famed „write once, deliver anywhere“ which native desktop always aspired to be. My apps run on android, iPhones, MacOS, rare Linux operating systems, Windows and Tablets alike. The only thing they need is a browser. I only need one programming language for this. One developer can do with the web what 10 couldn‘t do with native. How one could take a look at fortune 500 companies which are almost all at their size in thanks of the web and its advantages and then go on to declare the latter the worst platform to build is beyond me.
- pohl 4y ago
  The web enables the famed „write once, deliver anywhere“ which native desktop always aspired to be We recommend viewing this sentiment in Chrome. It’s not been tested elsewhere.
- rektide 4y ago
frivoal 4y ago
> The web was designed to publish documents, it was never intended to build applications. I find that repeated a lot, but to me, it's somewhere between an overstatement and a misconception. Sure, the early web wasn't anywhere near the versatility of what we have today, and interactivity was extremely limited (and as you say, is still more complex than it ought to be). But the semantics of HTTP+HTML, from the early days, allowed for application development. If all we had had were <p>, <h1>, <aside> and GET, sure, documents it is. But we had forms and POST and everything you need to make a CRUD application from the early 90s. It was pretty basic, but so was support for documents (tell Desktop Publishing people that HTML in the 90s was good for documents, and they're not likely to agree much). Just as one example, what is this, of not an application: https://thehistoryoftheweb.com/postscript/pizzanet/ https://thehistoryoftheweb.com/postscript/pizzanet/
- layer8 4y ago
  > But we had forms and POST and everything you need to make a CRUD application The same is true for PDF, yet it’s still primarily a document format.
  - blacksmith_tb 4y ago
    Not to mention it has a js interpreter[1]... 1: https://opensource.adobe.com/dc-acrobat-sdk-docs/library/jsdevguide/index.html https://opensource.adobe.com/dc-acrobat-sdk-docs/library/jsd...
- c7b 4y ago
  Sure, you could write apps using forms and POST, but how prevalent was it? One of the most popular frameworks for early-ish apps was Flash eg, for which support has been thoroughly discontinued.
  - rkangel 4y ago
    Maybe my memory is fuzzy, but I don't remember Flash being used for apps. It got used for video playing and games mostly, as well as unnecessary animation on restaurant/hotel websites. The occasional enterprise app used it, but generally they were ActiveX. What we had was server-side frameworks. Generated HTML, click a link that does a GET or POST. That's how my webmail at University worked, that's how the control panel for my web hosting worked etc. I think my first exposure to proper clientside UI was GMail (lunched 2004, I think I signed up ~2006).
_8j50 4y ago
> The web was designed to publish documents, it was never intended to build applications. This is false. Various inputs and forms were in html since its early days, these are not required to simply publish and view a document but to interact with text and graphical content. It did lack the ability to do "rich" content/apps and flash tried to fill in that gap, html5 came a bit late but I hope it is forward compatible. Would an html5 app from 2015 run fine in 2035?
- Aaargh20318 4y ago
  > This is false. Various inputs and forms were in html since its early days The same is true for PDF files, they support forms and can even POST to a server. Would you consider PDF a format designed to build apps instead of one designed to publish documents ? HTML is great for these kinds of 'apps', like this website. This is where HTML is fulfilling its original purpose. Reading text, filling out a few forms, that's exactly what it is for. I'm not arguing against interactive websites such as e.g. Reddit or Slashdot. What I'm arguing about is actual full-fledged apps built in HTML. Photoshop should not be a web app, nor should Visual Studio.
  - _8j50 4y ago
    You are changing the topic with photoshop and VS, I or no one else on this thread claimed they should be web apps. PDF like say word and excel documents can be made to write applications. With classic html, you can do similar things as with PDF but it was used to write anything from IRC clients, school exams, games and a lot more. Like PDF, it contained support for scripts to allow applications not mere documents to be implemented but unlike PDF it was especially made for the web. People did implement full fledged apps in plain html powered by powerful server side languages like php or jsp. The trend of doing a lot of heavy lifting in clients is fairly modern after clients were able to handle such workloads and internet speeds were not a deterrent. For clienr capabilities of the time, html was very much meant to implement apps in the browser with all the heavi lifiting done on the server side because pentium 1 with 500mb ram,dialup and windows 98 can't do modern types of apps even with flash well.
amadeuspagel 4y ago
> Saying that a document from the early web is still viewable while a fully interactive application from the same time is not is a bit disingenuous. The earliest fully interactive web apps are still usable, and native apps from the same time are not.
deleted 4y ago
[deleted]
drewcoo 4y ago
From the article, in the same paragraph, just before the quote you lifted: "The web has none of that." I'm pretty sure that indicates that the author knows web pages aren't like apps. And cherry picking quotes out of context to misrepresent what's said isn't cool.
peanut_worm 4y ago
The statement is still true though. A over engineered react app built in 2022 should still work perfectly fine in 2032.

danwee 4y ago

Sure, but the lesson here is to improve the web (or to create some platform for apps, in the same spirit of the web), not to jump into walled gardens.

layer8 4y ago
From a certain perspective the browser is much more of a walled garden than native desktop development.

ChrisLTD 4y ago

> The web was designed to publish documents, it was never intended to build applications. But the web has been evolving in that direction with the help of standards bodies and browser vendors since at least the late 1990s.

capableweb 4y ago
> with the help of standards bodies and browser vendors Who are made out of people (developers) building for the web, and users of the web as well. Lets not pretend that these web applications were forced upon us by outside forces.

MontyCarloHall 4y ago

>Saying that a document from the early web is still viewable while a fully interactive application from the same time is not is a bit disingenuous. Indeed, though running a Java Applet from 1995 is a lot easier than running an iOS app from 2010. Although browsers haven’t natively supported Applets for a very long time, there are several third-party tools that let you run them as standalone applications. Good luck virtualizing a 10 year old version of iOS to do the same for the old app. That said, the argument in the OP holds true if we don’t go back in time quite as far. Most JavaScript-based single-page applications from 2010 should still run flawlessly in modern browsers.

statictype 4y ago
> Indeed, though running a Java Applet from 1995 is a lot easier than running an iOS app from 2010 Applets weren’t even easy to run in 1995.
- mikepurvis 4y ago
  But somehow still way easier than booting up an old iOS.
danjoredd 4y ago
I discovered this unfortunate reality recently myself. In 2012 I was gifted by my parents a first gen Kindle Fire. I got a lot of free apps back then because Amazon had a "free game of the week" deal going on where a lot of normally paid apps would be temporarily free. Out of nostalgia I downloaded the Amazon App Store to my phone last month and found that not only were most of my favorite apps not in my library anymore, but that the few left over were built for a version of Android so old that it is no longer compatible with my phone. It was a very sad moment for me, as I had a lot of fun with those games
- mysterydip 4y ago
  As a hobbyist game developer with several games of my own no longer available due to the marching on of OS versions, I sympathize. There just isn't enough time or incentive for me to keep old codebases current with arbitrary API changes.

YesWeWill 4y ago

With CSS Flexbox and Grid, the web is the best GUI app platform I know of (and I was a WinForms developer before). It is made for apps now, and it has been the goal for some time already - since HTML 5 at least, but I'd say it began as stated goal with DHTML.

pjmlp 4y ago
Ironically the CSS grid is based on WPF grid, and was originally proposed by the WPF team.
- YesWeWill 4y ago
  Don't see the irony, WPF was a nice idea that should be copied - unfortunately they axed it before it could grow and then the general uncertainty forced me off the platform.
  - pjmlp 4y ago
    It is still there on Visual Studio, and with a more certain future than WinUI will ever get. The irony that the Web needs to keep copying native development experience, and it is still miles behind of what VB and Delphi were offering 30 years ago, unless one is paying for stuff like OutSystems or PowerApps.
    - YesWeWill 4y ago
      WPF might be there, but with all the "deprecated - oh not deprecated again - not deprecated but no updates for many years - deprecated again - not deprecated again" cycles I'm not going to touch it with 10-meter pole for anything that I need to support - same with anything else related to .NET. Also the UI designer experience for WPF is much worse than it used to be with WinForms - so bad I just wrote the code manually, and at that point I can just write HTML/CSS. But perhaps they fixed that - I left .NET in 2015. It doesn't run in the browser anyways - and the browser is what my customers want, because everyone has a browser, but not everyone has Windows desktop - especially today, when many people don't even own a PC and use something with Android/iOS as their primary computing device.

yesimahuman 4y ago

Many, many web developers would disagree with your assertion that you can't build great apps (including desktop and mobile (hello Electron and Capacitor)), or that the UI technologies available to web developers are a "hack" or aren't actually extremely productive and enjoyable to use. The argument that the web is only for documents and not app experiences is simply a relic of a different time.

Aaargh20318 4y ago
> your assertion you can't build great apps (including desktop and mobile (hello Electron and Capacitor)) I have yet to see a great app built on web technology. All Electron apps provide a terrible UX, they are slow, unresponsive and feel out of place with the rest of the OS I'm running on. I want my apps to feel native, to look and feel exactly like all other apps. One of the greatest tragedies of web UI's is the lack of a standard UI toolkit. Almost evert web-based app has to roll their own UI components, there is no consistency. This is terrible for usability, especially for users that are not as tech-savvy as we are. It's one thing to have to explain what a certain UI component is and does once, but it gets infinitely worse if every app has their own spin on it. Who doesn't love teaching their grandma 1232043 different variations on a checkbox ?
- yesimahuman 4y ago
  This is just your opinion and perception then, because Electron apps have been hugely commercially successful and teams using it have built very strong experiences that users love. If they were so "terrible" and "out of place" users would reject them, and they don't. The HN crowd has been consistently wrong about this.
  - Aaargh20318 4y ago
    > If they were so "terrible" and "out of place" users would reject them, and they don't. You are acting like users have a choice. For example: Microsoft Teams is an abomination of an app. It's slow, clunky, eats memory like there is no tomorrow and feels totally out of place on macOS. Still it's a huge commercial succes and I use it every day, even though as a user I absolutely hate it. I simply have to use it because my employer chose it as the company collaboration tool. And they didn't choose it because of it's incredible UX, they chose it because we already have an Office365 subscription and it was included in that, so we already paid for it anyway. Some Electron apps have been huge commercial successes despite their terrible UX.

ravenstine 4y ago

> As a platform for developing interactive applications the web is simply terrible. This is where you lose me. For such a "terrible" platform, it sure has a lot of users now, don't it? Maybe you mean from a developer's perspective, and it's not unreasonable that someone might consider web tech terrible, so I'd be interested to know why they see it that way. > There is no good way to develop a UI in HTML/CSS/JS Nonsense. Most UIs suck in general. On the web, they suck a little more because HTML/CSS/JS have such a low barrier to entry, and the industry requires very little intellectual rigor that would cause one to think twice about "just npm install that shit, bruh." Despite that, there's no sensible reason why a "good" UI can't be built with web tech. The web is what you make of it. > all attempts to do so rely on layers upon layers of wat are essentially hacks You're going to have to explain what makes working within the confines of a webpage a "hack." Sometimes we create workarounds, but everything may need workarounds. > to build something resembling a UI toolkit It is a UI toolkit. > on top of a document markup language. Which many people agree is well suited for describing UIs, whether it's HTML or something else. > The result a UI that is unnecessarily complicated and fragile. The cause not being something wrong with webpages, but the choices developers make and the way organizations approach software development. Give me a fragile web app and I'll show you a fragile and hard to work with native codebase. > Laying out and rendering HTML and CSS is incredibly complex It's as complex as you make it out to be. None of what's on a webpage has to be complex. We make it complex because of a lack of actual engineering mindset and because HTML/CSS is relatively abstract and forgiving. If one doesn't prefer something that's forgiving, they can work with native code or something that transpiles to HTML/CSS. Doesn't mean HTML and CSS aren't capable of performing the job they've been doing for almost my entire lifetime now. > compared how traditional UI toolkits do the same task. Depends on the task. Depends on the toolkit. > That complexity comes at a cost, both in development time and in UX. As already stated, that complexity comes from no one but the developer. Given reasonable time, a developer should be able to build most UIs using web tech and have it working as intended. HTML, CSS, and even JS aren't really what most people consider complex about web development. What's insanely complex about modern web development, that people frequently complain about, is everything we've done to turn web development into Java development (i.e. a churn of build steps, toolchains, transpilers, runtimes, and so on).

layer8 4y ago

Win32 applications from (almost?) 30 years ago also still run on modern Windows. By a far margin, it’s a choice of keeping compatibility or not. In contrast, I had to stop using my favorite SSH application on iOS because the author had died and Apple stopped supporting 32-bit apps instead of providing a compatibility layer.

RajT88 4y ago
I run all 64 bit Windows 10. But, if I was on 32 bit, I wouldn't count out Windows 1.0 16 bit PE's from running: https://docs.microsoft.com/en-us/troubleshoot/windows-client/application-management/x64-windows-not-support-16-bit-programs https://docs.microsoft.com/en-us/troubleshoot/windows-client... If you want to try, extract disk4-apps.img: https://winworldpc.com/product/windows-10/101 https://winworldpc.com/product/windows-10/101
- jcranmer 4y ago
  > Windows 1.0 16 bit PE's Point of order: 16-bit applications used the NE format, while PE was introduced to support 32-bit applications.
hedora 4y ago
Win32 apps also run extremely well in dosbox on Linux, etc.

selfmodruntime 4y ago

> As a platform for developing interactive applications the web is simply terrible. There is no good way to develop a UI in HTML/CSS/JS, all attempts to do so rely on layers upon layers of wat are essentially hacks to build something resembling a UI toolkit on top of a document markup language. The result a UI that is unnecessarily complicated and fragile. Laying out and rendering HTML and CSS is incredibly complex compared how traditional UI toolkits do the same task. That complexity comes at a cost, both in development time and in UX. This is so disingenuous and untrue that I‘m close to calling it an outright lie. Development of UI has never been easier, more accessible and better for the disabled than with web tooling. Any businesses from tiny startups to gigantic corporations can build value creating applications which generate billions of dollars of revenue which runs on almost all devices, using just one language and one code base. Browsers HTML and CSS parsers are incredibly generous in what they accept, allowing small markup mistakes in a latest update to not grind your operation to a halt. Modern HTML and CSS are dead simple to use, deliver sane defaults and capabilities which most browsers understand all the same. Never before has it been so easy to develop an application for your business with a language and frameworks millions of developers speak. Prototyping is incredibly simple. Modern browsers deliver incredibly tight sandboxes so malicious applications can neither access the information of other applications nor anything else on a targeted users system. Fake applications can be identified with SSL certificates in ways native applications never could. The web enables the famed „write once, deliver anywhere“ which native desktop always aspired to be. My apps run on android, iPhones, MacOS, rare Linux operating systems, Windows and Tablets alike. The only thing they need is a browser. I only need one programming language for this. One developer can do with the web what 10 couldn‘t do with native. How one could take a look at fortune 500 companies which are almost all at their size in thanks of the web and its advantages and then go on to declare the latter the worst platform to build is beyond me.

pohl 4y ago
The web enables the famed „write once, deliver anywhere“ which native desktop always aspired to be We recommend viewing this sentiment in Chrome. It’s not been tested elsewhere.
rektide 4y ago

frivoal 4y ago

> The web was designed to publish documents, it was never intended to build applications. I find that repeated a lot, but to me, it's somewhere between an overstatement and a misconception. Sure, the early web wasn't anywhere near the versatility of what we have today, and interactivity was extremely limited (and as you say, is still more complex than it ought to be). But the semantics of HTTP+HTML, from the early days, allowed for application development. If all we had had were <p>, <h1>, <aside> and GET, sure, documents it is. But we had forms and POST and everything you need to make a CRUD application from the early 90s. It was pretty basic, but so was support for documents (tell Desktop Publishing people that HTML in the 90s was good for documents, and they're not likely to agree much). Just as one example, what is this, of not an application: https://thehistoryoftheweb.com/postscript/pizzanet/ https://thehistoryoftheweb.com/postscript/pizzanet/

layer8 4y ago
> But we had forms and POST and everything you need to make a CRUD application The same is true for PDF, yet it’s still primarily a document format.
- blacksmith_tb 4y ago
  Not to mention it has a js interpreter[1]... 1: https://opensource.adobe.com/dc-acrobat-sdk-docs/library/jsdevguide/index.html https://opensource.adobe.com/dc-acrobat-sdk-docs/library/jsd...
c7b 4y ago
Sure, you could write apps using forms and POST, but how prevalent was it? One of the most popular frameworks for early-ish apps was Flash eg, for which support has been thoroughly discontinued.
- rkangel 4y ago
  Maybe my memory is fuzzy, but I don't remember Flash being used for apps. It got used for video playing and games mostly, as well as unnecessary animation on restaurant/hotel websites. The occasional enterprise app used it, but generally they were ActiveX. What we had was server-side frameworks. Generated HTML, click a link that does a GET or POST. That's how my webmail at University worked, that's how the control panel for my web hosting worked etc. I think my first exposure to proper clientside UI was GMail (lunched 2004, I think I signed up ~2006).

_8j50 4y ago

> The web was designed to publish documents, it was never intended to build applications. This is false. Various inputs and forms were in html since its early days, these are not required to simply publish and view a document but to interact with text and graphical content. It did lack the ability to do "rich" content/apps and flash tried to fill in that gap, html5 came a bit late but I hope it is forward compatible. Would an html5 app from 2015 run fine in 2035?

Aaargh20318 4y ago
> This is false. Various inputs and forms were in html since its early days The same is true for PDF files, they support forms and can even POST to a server. Would you consider PDF a format designed to build apps instead of one designed to publish documents ? HTML is great for these kinds of 'apps', like this website. This is where HTML is fulfilling its original purpose. Reading text, filling out a few forms, that's exactly what it is for. I'm not arguing against interactive websites such as e.g. Reddit or Slashdot. What I'm arguing about is actual full-fledged apps built in HTML. Photoshop should not be a web app, nor should Visual Studio.
- _8j50 4y ago
  You are changing the topic with photoshop and VS, I or no one else on this thread claimed they should be web apps. PDF like say word and excel documents can be made to write applications. With classic html, you can do similar things as with PDF but it was used to write anything from IRC clients, school exams, games and a lot more. Like PDF, it contained support for scripts to allow applications not mere documents to be implemented but unlike PDF it was especially made for the web. People did implement full fledged apps in plain html powered by powerful server side languages like php or jsp. The trend of doing a lot of heavy lifting in clients is fairly modern after clients were able to handle such workloads and internet speeds were not a deterrent. For clienr capabilities of the time, html was very much meant to implement apps in the browser with all the heavi lifiting done on the server side because pentium 1 with 500mb ram,dialup and windows 98 can't do modern types of apps even with flash well.

amadeuspagel 4y ago

> Saying that a document from the early web is still viewable while a fully interactive application from the same time is not is a bit disingenuous. The earliest fully interactive web apps are still usable, and native apps from the same time are not.

deleted 4y ago

[deleted]

drewcoo 4y ago

From the article, in the same paragraph, just before the quote you lifted: "The web has none of that." I'm pretty sure that indicates that the author knows web pages aren't like apps. And cherry picking quotes out of context to misrepresent what's said isn't cool.

peanut_worm 4y ago

The statement is still true though. A over engineered react app built in 2022 should still work perfectly fine in 2032.