Hacker News Reader

Comment by frivoal | Hacker News Reader

> 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/

View on HN

I consider (paper) forms to be documents as well. In my opinion, it's a minor evolution of what is considered a "document" to go from a paper form to a dynamic, interactive form. A media application or video game in a browser is quite different. That doesn't mean it's not now a valid use of browsers, it's just not what the intended use of the web originally was.

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 early '90s only had GET in the HTTP protocol (0.9) so you couldn't actually build any CRUD applications. Quite far from it. POST came in 96 (1.0) and PUT, DELETE in 97 (1.1). REST was introduced in 2000 by Fielding and the idea that the web could used to build large scalable applications slowly gained momentum as CRUD was mapped to POST/GET/PUT/DELETE and the proposal gathered steam in '00s. In the meantime massive amount of engineering went into making JavaScript workable, performance wise (Chrome/V8). Everything came together only in the late 2000's. So, quite far from claiming web as a viable mechanism for building applications in the early '90s.

HTTP POST was in common use well before 1996. It was standardized with HTTP 1.0 in 1996, but form POSTs were common well before then. People were developing "web apps" in the 90's using Perl CGIs, ASP pages (VB script), and even Javascript (Netscape's web server supported server side Javascript applications.)

It's funny that there's contention on this. Here's someone trying to answer the question in 2002:

> 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

<http://www.rogerclarke.com/II/WCBirth.html>

Yet there I was building online shopping apps in 96 in my internship. Get was more than good enough for a search of the catalog to find what you needed. Our system just sent an order email in and we called you for payment. That was via post.

Amazon went public a year later.

In addition to icedchai's comment, there are two more issues worth quibbling about what's written here:

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.

You can definitely make a crud app with only GET. E.g. PHP used to have support for automatically adding session ids to urls in links, for people who didn't like cookies.

I think it's right on the money. The Web has long sucked even for presentation, let alone for application delivery. It's not that you can't do it now; but it's still a hack upon a hack.

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.

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.

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).

That's what I remember too - but what's the difference between an app and a game? Usually your score would be sent back to the server too.

Adobe really wanted it to be used for serious stuff. There was AIR, a Flash desktop runtime. They started integrating Flash into their tools, I recall a few Illustrator palettes that would make my computer’s fans come on just by opening them because they would make the Flash runtime wake up and start busy-waiting for input on 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.

A managed switch we use somewhere for something uses flash to display port status (I think?). I guess that part doesn't work anymore...

>Maybe my memory is fuzzy, but I don't remember Flash being used for apps

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).

Up through 2008 we made very heavy use of posts in web apps where I worked, js was more of an accelerant for things like autocomplete and client side validation. Amazon retail was still building mostly post based experiences when they were doing the universal detail page project in 2015.

I never used flash seriously from 1996-2015 when I switched to an electron front end and then mostly to backend work.

> 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.

Not to mention it has a js interpreter[1]...

1: https://opensource.adobe.com/dc-acrobat-sdk-docs/library/jsd...

"App" is short for application, which is just a fancy word for program. If a page does computations locally (using javascript), then it is a program; if the page does nothing locally but push requests to the server (get/post), then this is a user interface. By this distinction, the early Web even with POST had no application, it was just at best a remote interface.

A remote interface to an application living on the server.

Reply on news.ycombinator.com