Languages #29: JavaScript
Part 28 is here
This entry has been a long time coming. I had hope that I could find a way of writing the post in a more exciting way than the boringness that are “Computer Languages”, well to me at least and it wouldn’t turn into a rant.
So, without further waffling… drum roll please….
29. JavaScript #
I first came across this language in its very early days. Probably in the Netscape browser, possibly in Internet Explorer. Somebody came up with some code that displayed a clock on the page and as you moved the mouse the clock moved with it. Another example I saw was a snow effect that could be added to any web page to display falling snow over it.
Back in the early 2000’s I was building websites and learnt just enough to get by. The earliest piece of JS I wrote was to perform rollover display changes before I discovered that I could do it using CSS.
For the last fourteen years I have writing JS for a living on a large SaaS (well half the time, the other half I write PHP) and have progressed from knowing the basics to -—from my perspective — to being really good at it. I even finally got my head about prototypical objects.
Generally I have stayed away from the large frameworks (React, Angular etc). Back in 2012 when — as the chief architect — I was looking for a good PHP/JS framework, and failing to find anything we ended up building our own which has grown and become the bedrock on which all parts of the application’s UI is constructed. Components exist as PHP code and JS code. If you create one in PHP a matching one is created on the JS side for you automatically with the same methods and data passing between them. It has grown over the last 13 years and it’s possibly time to throw it all away and start again based on what we have learnt.
As a SaaS type WebApp I have written more JS than I could possibly imagine. One of the pages alone — the most used one — has 20,000+ lines of JS. It is highly interactive.
Of the more modern frameworks Vue.js is the one I have used both within the product on some internal pages and for personal projects. I have yet to use it on any customer facing pages. I would like to use it more but each time I go back to it I have to learn so much about how it works each time. If I used it more this would probably not be an issue.
I’m not a fan of cross compilation - eg: bable, coffeescript. Having spent my years debugging other languages in assembler, if I am going to write code in CoffeeScript I want to be able to use a source level debugger that displays CoffeeScript not transpiled ES5. Thus I write in ES5/6 so what I code is what I debug. Plus all bugs are mine not the transpilers.
I am a big fan of linting (eg: ESLint) and type checkers (eg: FlowType). I would like to use TypeScript as it seems to be a reasonable compromise. The transiled code at least looks like the original. so maybe I will move in that direction.
I am also not a big fan of complex build systems, or in fact build systems at all. If you write in C you need build systems to compile and link. If you write in an interpreted languages like JS and PHP you have no need. I should be able to edit a file, hit save and reload. Deployment to a server should involve checking out a copy of the source and minimal setup. If you want minification of your JS, let your CDN do it on the fly for you. See me if you need further advice on this.
That ended up a little ranty which is what I feared. I confess I’m almost as opinionated about JS as Douglas Crockford.
Part 30 is here