Tag Archives: JavaScript

Web Designers: Stop making SPAs for inherently web 1.0 style sites

It is 2017. What’s with the drive to make everything an SPA whether it needs to be or not? This is getting a little ridiculous. I’m going to ramble on below a bit because I’ve got a hankering to do so — pay this no mind.

All around the web I see sites that are best represented as a collection of inter-linked documents, and all around the web I see many of those being changed into single-page application (SPAs). Even more stupid is when the SPA in question was built by some naive dope who included a little bit of almost every JS framework in existence — including a random selection from the thousands of obsolete and dead ones.

What is the goal? What’s the deal? Do web authors today not know how the web was actually intended to work originally? That document publication is actually its reason for existence in the first place and that “web applications” are a new thing that is a backhack to an incomplete standard that only sorta-kinda-works?

Granted, the reason it only sorta-kinda-works is due mostly to the problems inherent in the fact that only a single language is allowed in scripts… which is ridiculous. Was nobody paying attention to the Guile2 approach all those years? The only lesson learned from the Java applet and Flash experience seems to have been that “it sucks to force users to install runtimes as plugins”. Ugh.

Anyway, back to web applications…

I get it. For the moment we don’t have a solid distinction between “a document browser” and “an application browser” so we are stuck with this insufficient worst-of-both-worlds nether region of “applications that masquerade as documents”. And that drives anyone nuts who has given this much thought.

Not that a lot of people have considered the difference deeply. I imagine that is probably because very few new coders today have ever written more than a line or two of code intended to run natively on a user’s local system. Nearly everyone has written thousands of lines of code intended to run natively on server-side systems, but even that is getting wonky because many youngsters today don’t know how to deploy without using Docker yet lack the faintest inkling as to what problems Docker actually is intended to solve and wind up bypassing better solutions when they exist.

Tools shine when they are used in a focused way, performing they job for which they were intended. The web is the same way. Yes, it is a big jumble of crap. So let’s just leave that there. Networks are a big jumble of crap, too, and so are human societies — so we’ve adopted dirty ways of dealing with the dirt. The jumbly pile of shit that is the web is one of our ways of dealing with that. Everything times out. Everything is sent in text. Protocols are bloated and redundant. There isn’t even a proper definition of what “valid” HTML and XML and JSON and whatever else is in most cases. Its all racing toward a singularity where everything is uniformly stupid. But… whatever, it sort of kind of still works — and humans just barely work themselves, so that’s par for the course.

The original web was designed to function as an insecure document publication system where documents could be interlinked. We realized that we could include more interesting stuff by expanding the definition of “document” to include more than just text, and quite recently with HTML5 the way in which documents can be written is only a few orders of magnitude behind, say, LaTeX, in its ability to arrange things on the screen (that’s feature lag is not entirely the fault of the HTML5 authors).

This gives a lot of freedom to website authors — perhaps too much.

If a website is a set of news articles or academic papers (or even tweets) then you really don’t need a SPA, you need a more traditional sort of “web site”. It can be dressed up all pretty with shiny things sprinkled around, of course, but we don’t want a SPA that mysteriously changes state in ways that users cannot bookmark things, can’t easily send links to one another to specific resources (something Twitter got right despite some initial confusion over how to frame their content), etc.

If a website is actually just a delivery front end for a graphical RPG, well, obviously the game part of the site is probably best designed as a SPA, but the rest of the site — the forums, armory, character pages, beastiary, fan wiki, manual, guild rankings, lore pages, etc. — are absolutely best presented outside of that SPA as an actual website.

See the difference?

The game example is actually quite useful to contemplate for a variety of reasons. I’ll probably come back and cut this post down to just that part. Either that or eventually come back and rewrite the first bits to more accurately convey the humor with which I, as a graybeard resident in cyberspace for about 30 years now, view the state of the web today.

Whatever you do, dear reader, have fun coding, and remember: Don’t outsmart yourself!

A Note to a Web Retailer about JavaScript-or-Else Pages

I was cruising computer hardware retailers on the web today because I’ve got to make a few orders. Not so many that I need to pester the manufacturers directly, but a large order compared to what most folks buy online with a credit card. Specifically, I need to replace one motherboard and build six new computers (complete with screens, etc.). Checking through a few shops I decided to order from one of the top 3 online stores for computer gear — and was rejected by their website for even trying to browse the product listings because I don’t have JavaScript enabled by default.

This got me to thinking about how stupid that was. JavsScript isn’t necessary for any of that site’s core functionality, particularly when just browsing. I hadn’t put anything in the cart, hadn’t done anything that requires “interactivity” (a laughable concept in a website if you know anything about the history of port 80, but whatever) or anything like that — I was just checking specs and prices, which worked just fine, but every single page is set to a five-second redirect delay if and only if the customer doesn’t have JavaScript enabled.

So I wrote the webmaster a note — and moved on to make my purchase somewhere else. Here’s the note:

Your website works just fine without JavaScript enabled but after a few seconds redirects *everyone* with JS disabled to a “turn JS on or you can’t browse our site” page. There is irony here because most people who browse the web with it disabled by default are IT professionals like myself who
1- Order huge amounts of hardware online and
2- Already know that they have JS disabled and how to enable it when they want to.

So that’s the situation and my complaint. Here’s a suggestion to solve it:
Test for JS and redirect to the JS-or-Else page only when the user hits ordering or shopping cart dialogues or something else to which JS is actually central. (Almost nothing, in fact, really requires JS, its just the only way a lot of web developers know how to think at this point.)

Compromising by making your site broadly accessible and then only forcing JS when the user actually needs a client-side script to run is a much better design policy than doing what you’re doing currently — which is drive customers elsewhere when they are just beginning to browse.

Its too easy to go somewhere that doesn’t do that, and so that is what what I’m doing now after writing you this note. Consider that I’d seriously consider turning JS on if I’d gone so far as to pick out items, fill the cart up, etc. and *then* get told that I can’t process the purchase without JS turned on.