Javascript is Ruining the Internet

In 1994 Yahoo gave us a hyperlinked directory to the nascent web, and Netscape delivered on the promise of Mosaic. In my opinion these concurrent developments ushered in the era of the graphical web.

HTML was the lingua franca and web pages were mostly text and links. Life was good…

if your browser does not support images...

Coincidentally this is the year that I created a website for hire for the first time, starting my lifelong affiliation with writing code deployed online.

I created a red, white, and black fully graphical site for an industrial plant that makes huge boilers. The most cutting edge features of the site were image map menus and a perl cgi contact form! Of course I had to create text menus for browsers that didn’t support images…

To be fair I have always been on the server side of scripting starting with Perl, PHP, and now Python. I’ve always seen JavaScript as a necessary evil.

Lest you think I am just an old man shouting “get off my lawn”, CSS was introduced well after I had created literally dozens and dozens of websites. I adopted it whole-heartedly along with the semantic web it make possible.

That being said, JavaScript as initially deployed ( LiveScript ) was a train wreck. It was buggy, slow, and many basic features were not implemented.

Over the years, JavaScript has had its fair share of security issues as well. Cross-site vulnerabilities, Misplaced trust in the client, Misplaced trust in developers, Browser and plugin coding errors, Sandbox implementation errors, as well as Hardware vulnerabilities.

Is it JavaScript or is it Frameworks?

JavaScript has come along way. Ever since 2009 when everyone finally agreed on a standard way to implement it JS has taken off. Node.js, V8, Vue.js, and even JQuery have revolutionized what could be done with JS and how people looked at it.

It may be a fair argument to say that JavaScript itself is not ruining the Internet – that the problem lies with JavaScript frameworks and libraries. To my mind that is a distinction without a difference.

If you are trying to load a web page on your phone these days, and it is taking f o r e v e r the problem, most likely, is JavaScript.

Now multiply that by the 5 different JS libraries this sites “framework” is calling…

This rant is not aimed at people that can actually code JavaScript.

Good coders are good coders, regardless of which technology used. The problems start when someone that can’t code implements a quarter of a megabyte of JQuery without understand a thing about what is going on in all that code.

People who are cutting and pasting code into gui’s and using content management systems with frameworks and plugins that call 50 different libraries without an understanding of the underlying technologies ( including JS ) are the problem.

It just turns out that with today’s stack JavaScript gets abused the most.

Actual JavaScript specific Issue for coders

There are some problems on the technical side of JS as well. Effectively it doesn’t do object-oriented programming. The more I progress with Python the more import this is to me personally. I am effectively a OOP convert at this point.

From what I understand the difference between client and server JS is still confusing at best.

Additionally it appears to me that the documentation for a number of the aforementioned libraries are wanting. At least compared to the documentation available for similar Python libraries.

The Solution

Obviously nobody wants to go back to the static web ( Gopher? ), but the state of web scripting is a clusterf*ck at this point by my estimation.

Is it inherently JavaScript’s fault that it has become the defacto website bottle neck? Debatable.

What I don’t think is debatable is that the majority of the time it is.

I’m as guilty as everyone else. This very plain website runs WordPress. As simple as it is it only rates a 75 on Google’s developer tools performance scale and that is mostly JS related.

So that’s the problem. What is the solution?

Leave a comment

Your email address will not be published. Required fields are marked *