No Time To Play

When technology is using us

by on May.17, 2014, under Off-topic

You know, lately I’ve been thinking about all this crap that’s going on. Net Neutrality going bye-bye in the US — and make no mistake, that will affect the entire Internet. Mozilla, the last bastion of the open web, putting DRM in Firefox. The Heartbleed debacle. It’s a worrying trend, and partly it’s all because we, the people who actually use computers to do meaningful stuff, have made ourselves powerless. We’ve made ourselves dependent on corporate interests for most of our computing needs.

How? By demanding more and more of our computers, until out hardware and software needs could no longer be met by anyone but the richest of corporations. How many desktop CPU manufacturers are left in the world? Two: Intel and AMD. How many GPU manufacturers? Also two: ATI and nVidia. And ATI has been bought by AMD years ago.

There used to be at least a handful of each.

Something similar has happened with Web browsers. There used to be a lot of them. Now only two still matter: Firefox and Chrome. (There are a few more based on the same engine as Chrome — WebKit — but none of them is nearly as popular, except perhaps Safari for iOS, and that’s only because you can’t have an alternate browser on iOS.) Sure, all the open source text-based browsers are still around, but they’re increasingly useless on a Web that can’t seem to function anymore without Javascript. It’s no joke: even Google has been forced to start interpreting Javascript because otherwise a lot of websites would remain unindexed. And web developers think that’s NORMAL.

It’s our fault. Think of all the crap we’re expecting our browsers to do.

HTML. XML. CSS. Video. Audio. Scripting. Canvas. WebGL. Local storage. Filesystem access. Webcam access. Then then stuff that makes all of that possible, such as the DOM. And whatever layers are underneath that. It’s a wonder Firefox for Android is still under 100MB in size.

And all of that because we couldn’t be happy with clicking a link to open a video in VLC. It just had to be inline. Because, um, er….

Because we’re like children, that’s why. Always demanding more, more, more. Glitzy stuff. Cool stuff. We have completely forgotten that computers were designed to be tools. To help us work, not to do the work for us. Let alone the thinking. We’re no longer content to type plain text, we need Word. We can’t just use any graphics software, it has to be Photoshop. (Yes, fluffy, I know; remember when people only had pen and paper? MS Paint is an improvement over that. But we can’t seem to be happy with mere improvements.)

Sure enough, the vast majority of us don’t use the vast majority of what we’re asking for. Yet we keep asking, and the corporations are all too happy to deliver, because that way they can keep taking our money. While free software developers are ridiculed because they can never add the same amount of bling. Of course they can’t. They’re working on a shoestring — yes, even when they have corporate sponsorship — and moreover they use their own software, so naturally they want it lean and mean. As does anyone who actually performs any real work with a computer. But it’s not what we’re saying out loud, is it?

How important that is became very visible when, in the aftermath of the aforementioned Heartbleed bug, the OpenBSD team started a major cleanup of the OpenSSL library. It turned out, fully 80% of the code was crud. 80%?! Let that sink in for a moment.

Now imagine how much crud there must be in the nearly 100 megabytes of Firefox. And it’s partly our fault. Because if they stopped adding features for one year in order to clean up the crud, we’d just start using other browsers that didn’t stop adding features.

If we had lighter websites and smaller software, maybe it wouldn’t hurt as much to be in the slow lane of the Internet. (And US residents already are, in a way, what with the state of broadband over there.) If we used simpler protocols everywhere we can, such as Gopher instead of HTTP, it wouldn’t hurt as much when browser makers betray us — a basic Gopher client is trivial to code.

A web browser isn’t. Not even the text-based kind. And nowadays we use them for all kinds of tasks that really should be performed with simpler software, such as checking our e-mail.

Maybe that gains us a little convenience. But think of the costs.

Because it does cost you.

Edit: just three days later, we get a frightening reminder of the harm done by overly complex software. Wake up, people.

Creative Commons License
When technology is using us by Felix Pleșoianu is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.


3 Comments for this entry

  • Christian Berger

    This is actually a lesson we have learned over and over again. It is the lesson that lead to UNIX or IP for example.

    What we would need now would be a simple “GUI-Protocol”. Something that can just get GUI elements and their logical relations across, letting the client “scale” the GUI to whatever device you have. This could be much simpler than HTML with its SGML roots.
    If we want to have local code, it could be done in Forth which is orders of magnitude easier to implement than Javascript, yet can provide more than enough power to custom render a GUI element or check some values in a form. (Plus it’s moderately painful to write in so it’ll discourage some of the idiotic Javascript we have now)

    Maybe every programmer should be forced to do one large project in an Assembler. In Assembler every bit of complexity hurts, so you are conditioned to avoid it whenever possible.

  • Felix

    Hmm, good points. And I really like the idea. In fact, a well-written Forth API wouldn’t even be so hard to use — though you’d have to be careful. A Forth interpreter would also be easier to check for correctness due to simplicity, and easier to sandbox, too, since it wouldn’t have to do nearly as much as JS.

    But hasn’t that been tried before? It sounds not unlike what X Windows was originally doing, or perhaps similar to the Java ME windowing API. Neither was sufficient in the long run. I butted my head against the limitations of the latter myself. There’s doing less, and then there’s not having even a minimum of flexibility.

    Still a thought-provoking proposal. Thanks!

  • Christian Berger

    Well we could have 2 basic concepts, a document, which specifies a “page of layout” and can be cached, and a dialogue, which is a conversation between client and server.
    Both could be done via a trivial protocol based on TCP/IP, or via HTTP(s) and Websocket.

    You’d then have GUI elements which are rectangular areas of the screen. There would be standard elements like buttons or text entry fields which could have hooks to certain events happening in them. For example you would have an OnDraw hook which will be executed whenever the element redraws.
    Those events would be sent to the server by default or could be handled by local Forth code which would then only have access to that GUI element.

    GUI elements could be nested, and elements on the same level could be tiled automatically (just like Delphi does). Alternatively the server or server level code running on the client could do the alignment.

Posts by date

May 2014
« Apr   Jun »

Posts by month