I’d definitely say the web is a bad tool for most of the things we use it

for.

(Let me say that I like and appreciate that you can perform hacks like dynamic web pages; I’m just horrified that so many people think…

I’d definitely say the web is a bad tool for most of the things we use it for. In particular, the technique of using javascript sitting within a document to dynamically edit that document’s structure & CSS attributes is a particularly inefficient way of building a user interface, and without the heavy optimization being done by browser maintainers any such application would be unusable. (As much as I dislike Java, I have to admit that applets are actually the appropriate solution here.)

(Let me say that I like and appreciate that you can perform hacks like dynamic web pages; I’m just horrified that so many people think you should. Dynamic web pages are, essentially, self-modifying code. Anywhere else, we would be very wary of that.)

HTTP specs provide response codes that address some of the problems related to addressing documents via their position on machines. (Doing this rather than using CAN is a mistake in the first place, but TBL was working with a slow network before ideas about CAN were very widespread.) If we were to try to implement up to the original spec & use that spec to get as close as possible to traditional pre-web hypertext best practices, we would make the content of each page static (no CGI), keep track of where every document is at all times, use temporary and permanent redirect response codes if a document moves, never have two different documents (or a modified version of the same document) with the same full URL, and only use a 404 return code in the apocalyptic case that somebody simultaneously nuked your server and all your backups (or in the case that a document never existed). Today, these codes are not used that way.

(HTTP also specifies some very useful functionality that is very rarely implemented. Specifically: HEAD requests to get the length of a document and special variations on GET requests that return a span of bytes, given a starting offset and length. Such features are very useful in an environment where documents are static but potentially very long. Having worked on code intended to perform transclusions from arbitrary URLs, this feature would have drastically simplified my efforts.)

Right now, the most promising competitor to HTTP is IPFS — a CAN-based file transfer system. It doesn’t solve the problem of servers going down permanently (there is no automatic redundancy), but popular files will outlive short outages because requested files are served from cache (which also saves bandwidth upstream). IPFS avoids CGI-style hacks, but you can still serve arbitrary HTML/Javascript blobs, so it’s not as though it breaks that functionality. (Again, I consider using javascript to manipulate HTML messy and slow.)

My main complaint with web apps is that very few things benefit from being on port 80 & being stuck inside HTML. An applet, because it’s essentially a native application that has been sandboxed, doesn’t have the problem of needing to draw using drawing routines intended for dealing with messy hand- written markup, nor does it have the problem of working against a set of quirk rules organically grown to protect against 20 years worth of random but very specific attacks on web browsers. An applet can use standard protocols, instead of depending on services that are exposed over HTTP wrappers. (HTTP- exposed APIs take the rule-breaking of CGI — which, remember, discouraged people from using redirects properly and led to the current user-hostile behavior of redirects; they are additionally generally less efficient than existing standard protocols.)

Applets have gotten a bad name, because most applets are either Java or Flash, and both of those platforms have a history of being quite awful. But, there’s no particular reason that an applet viewer for javascript, or lua, or smalltalk couldn’t exist, provided that someone decided on a decent standardized drawing model that properly supported all the various things people like to put in GUIs.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!

By John Ohno on January 18, 2017.

[Canonical link](https://medium.com/@enkiv2/id-definitely-say-the-web-is-a- bad-tool-for-most-of-the-things-we-use-it-for-c4c86124a678)

Exported from Medium on September 18, 2020.