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/
Further, to quote Tim Berners-Lee directly on his intention when he created the first version of the WWW (emphasis mine):
"Creating the web was really an act of desperation, because the situation without it was very difficult when I was working at CERN later. Most of the technology involved in the web, like the hypertext, like the Internet, multifont text objects, had all been designed already. I just had to put them together. It was a step of generalising, going to a higher level of abstraction, thinking about all the documentation systems out there as being possibly part of a larger imaginary documentation system." — Tim Berners-Lee
https://en.wikipedia.org/wiki/Tim_Berners-Lee#Career_and_res...
edit: cleaned up formatting and attributed emphasis.
> The purpose of this document is to answer the question "When did we start seeing web-forms that captured credit-card details, and passed them to CGI-scripts, thereby enabling interaction with server-side applications
It's odd to say something like "REST was introduced in 2000 by Fielding", since it makes it sound like support for a feature. But REST is just a description of how the Web works. Fielding's dissertation is a retrospective, documenting what the real work of standardization at IETF and among browser makers and server distributions had already earlier enabled.
Secondly, JS was workable performance-wise in the early 2000s in Netscape 6, even without a JIT.
Amazon went public a year later.
I also don't think the longevity of Web sites will necessarily continue. The earliest sites will render today, but will the same be said of today's "single-page-application" sites that rely on scripting?
And finally, I think the LaserDisc comparison is dumb. LaserDiscs from the '70s were playable through the format's demise in the 2000s. "Coding" for it... makes even less sense.
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).
Flash was used for apps; I remember one webmail provider which had built their frontend in Flash (can't remember the name sadly), and there various enterprise apps that were deployed with Adobe Flex (I remember Paychex being one of them).
They had the same vision for it that Sun had for Java, with the same flaws that would become apparent when that vision was finally manifested in Electron: write once, run anywhere, and be hideously inefficient compared to native code.
I never used flash seriously from 1996-2015 when I switched to an electron front end and then mostly to backend work.
The same is true for PDF, yet it’s still primarily a document format.
1: https://opensource.adobe.com/dc-acrobat-sdk-docs/library/jsd...
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.
the UI was consistent across the entire platform, all the accessibility worked out of the box
yes, the main advantage is that the web runs on "everything", but then the added complexity of needing 4 different programming languages and half a dozen build tools don't put it in a state where it has "never been easier"
even Java+Swing was better in pretty much every respect (other than providing employment for tens of "web developers")
(same as people who <3 visual studio today obviously haven't tried JetBrains...)
The 90s were great, not because they had the best experiences possible at the time, but because there was such anticipation for the future. Sadly the web did not evolve quickly enough, and we have been paying the price ever since.
The only place where GUI apps have reigned supreme is in trading applications in finance, although I suspect that dominance is beginning to erode.
You don't need those for the Web. You can choose to use them. You can choose not to, too.
We recommend viewing this sentiment in Chrome. It’s not been tested elsewhere.
Yes, that is part of the problem. Parsers should be fail-fast and deterministic, this is one of the many problems of the web. Developers don't notice their incorrect code due to this and without noticing rely on the implementation-specific way one browser handles the issue. Then 3 versions later or in a different browser they whole house of cards comes tumbling down.
> One developer can do with the web what 10 couldn‘t do with native
Building a non-trivial app is always faster to do native. By a huge margin.
Raise your hackles about the choice not to fail fast if you want, but when they fail, they do fail deterministically. It's a too-common myth that they don't. (A little perverse that people who make a big deal out of others unable to follow spec, but by doing so prove they haven't checked what the spec says—because if they did, they'd know this...)
This was XHTML documents when sent with the correct Content-Type. "Just don't display anything if the document is malformed" is worse for users if devs still create malformed documents.
Another problem with it is that everyone who can get something to display in their browser suddenly thinks of themselves as a developer.
Ancient history now, but HTML5 was developed by WHATWG specifically as pushback against priorities of W3C at time (chief among which was push for XHTML).
That's not to say things cannot be improved, just to say this has all happened before and it will all happen again (and it is worth paying attention to what happened last time).
The ability of web apps to be instantly installed and updated is a huge win, as is the fact that it runs on everything from a phone to a desktop with zero additional effort. Certainly it comes with tradeoffs, but if your goal is not just to write code but to put it in front of customers, it's hard to do better than Html plus JavaScript.
There's a lot of people receptive to this toxicity- it's fact-free rage people want to hear, it's viral & it spreads- but the truth is webdev works fine & we have many perfectly reasonable frameworks to pick from that do a very fine job. Even straight vanilla js is not unreasonable an option, especially with webcomponents.
I dunno, it looked pretty aggressive to me. There was maybe a kernel of fact, but mostly opinion:
> As a platform for developing interactive applications the web is simply terrible.
Many disagree. Many would rather use Electron than native apps & find it nicer.
> 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.
I laughed out loud. There were already interactive buttons & form controls from the start. Vanilla JS is fine today. One of the web's strongest suits is that you can take a static page & sprinkle in just a little interactivity, just a little applicationization, if you want. Ultra-thin ultra-simple libraries like Enhance are doing great to provide just a little common shape & definition, tiny code but some norms & practices to adopt. It can be extremely incremental to move from document to application, with very little work at each step. We see what we want to see, and a lot of people want to see it as hard, as hugely complicated, but here's an industry heads down cranking without a ton of internal complaint, plenty of simple ways of doing things, and plenty of people doing fine.
> The result a UI that is unnecessarily complicated and fragile.
Sources wanted. Not all sites are perfect but a huge amount of things work very well. And unlike apps, users have a toolkit of capabilities they can learn & apply everywhere to help them (forward, back, bookmark, share link). Extensions let users go further than apps permit. Again, it's just, like, ya'll's downer opinion, man.
Anyhow, I like your note on hope. A lot. I don't see this ancestor post as having much hope there; it seemed set up to ruin. Trying to identify more constructive opportunities, trying to figure out new architectures we might layer onto the platform: that stuff should be exciting.
One place I lose excitement rapidly though is replacing the web with rendered canvases, as you say here:
> I am hoping that wasm and webgl can bypass html css and js for people who just want to make a webapp.
This is my nightmare. If folks want to do something else, fine, go somewhere else. But don't break the web. Don't break every user agent. Don't break view source, scraping, & accessibility tools. Just because alternate paradigms are succeeding as much as laserdisc doesn't mean they should come in & break the web next. That should be enragening.
The web is for more than pushing pixels into peoples faces. There's some value here, some shared expected experience, & coming in crashing it all because the only stakeholder you can imagine is those who "just want to make a [not-so-web]app" and damn all the rest.
I've had this bone to pick with Flutter, which is doing this imperialistic web takeover plan with CanvasKit, effectively turning the browser into a vnc session for an app. Incredibly hostile & deeply cruel way to snub hypertext & make yourself unintelligible to the rest of the ecosystem.
(The "direct calls into the DOM" wasm desires are going to be a bit chaotic & hurtful to view-source, but we've already made that hard; so ok, fine, and yeah, it is exciting to give people a post-JS web.)
Ideally I want security sensitive apps to turn into blackbox webapps. I want most everything else to be pure html+css. With interactivity there when you really need it to convey your meaning or to generate documents more quickly.
In reality, I think your nightmare scenario is far more likely. It just makes serving ads so much easier. And they still will keep making native apps for things that should be websites (which is my nightmare) because that makes it even easier to get valuable data.
This is nothing new. We used to have Flash, after all. (And I doubt Flutter on web will come close to reaching the ubiquity of that platform.)
Given how the web is embarking a takeover of desktop via Electron and of mobile to a much lesser degree with Ionic, to the annoyance of many users, turnabout is fair play.
Their response wasn’t glowing.
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.
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
Previously:
Isn't this an Apple thing? Seems like you should still be able to find and run old Android VMs. They ship with the SDK unless they retroactively pulled them.
Applets weren’t even easy to run in 1995.
If they're purely client-side, sure, but there's a good chance that anything we could reasonably call a web application, also has a backend component on a server. How confident are we that the backend code from 1995 will still run?
1995 is when Microsoft Frontpage launched. PHP was a year old. I'd be surprised if anything written in those sorts of environments still functions without being run on a 1995 version of Windows/Linux on 1995 era hardware.
Software is a process, it always has been, it always will be.
This seems like it would apply equally to native and web.
You can render a web page from 1995 but you can’t run any server-side logic if you don’t have a copy of the server.
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.
https://docs.microsoft.com/en-us/troubleshoot/windows-client...
If you want to try, extract disk4-apps.img:
Point of order: 16-bit applications used the NE format, while PE was introduced to support 32-bit 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.
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.
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?
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.
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.
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 ?
Oh my god, that sounds so cringey, right out of a marketing copy. It’s hard to wrap my head around someone writing this with a straight face.
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.
In the year 2022, multitouch gestures on the web still feel janky and wierd and just don’t work all that well.
"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.
The earliest fully interactive web apps are still usable, and native apps from the same time are not.
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).
But yeah, having such a nice GUI designer would be awesome - I miss Delphi a lot, and the WinForms designer was good too. Now finally Flexbox/Grid have support on all major browsers so perhaps we could get this part of the workflow back.
Phones - for sure, that's a modern development. But it's been more than a decade now, there are adult people who don't remember world without iPhones and Androids! Crazy... Myself, I started on Windows 98, but it's Windows XP (and Delphi) that defines my childhood.
Pretty standard on any other platform, but on the web, no one gets it right.
This is exactly how I would summarize it too. Before we had grid, I would be forced to agree with the original comment.
Now that we have these things, thick CSS/JS frameworks like Bootstrap aren't really a big deal anymore. 95% of the reason I used this stuff in the past was because I couldn't figure out the magic spell for getting things positioned properly. We even have media queries now, which can be combined with Grid to toggle between 2 or more layouts depending on viewport or other device factors. Our current web app handles all of the dynamic/responsive layout crap within about 30 lines of js & css.
I will only go back to native application development if someone pays for a one-off contract deal that only has to be supported for <3 years. For any long-term project with a user interface, I feel like the web is the safest default for building your product. We are signing contracts with B2B clients right now with terms measured in half-decades, so I really don't want to be playing games in traffic with 5 major versions of iOS and Android if I can avoid it.
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.
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.
The only reason I went back to cloud and Web development, is that pre-covid it was the best way to get 100% remote jobs, so I put up with it.
By the way, most of those iOS/Android users are using apps and not Websites.
.NET is dead to me, I simply don't trust the platform/libraries to continue existence and receive updates. Also the JS/NPM ecosystem is much larger and that's truly what's keeping me there.
IMO Flexbox and Grid only remove the need to have a stylesheet dedicated to layout like Bootstrap and foundation. That may be important for building tiny sites with no dependencies, but for an application, there will usually be a bunch of npm cruft required anyway. Having a bootstrap.min.css in the mix doesn't really impact my quality of life.
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.