I really don’t like JavaScript

I’m a .NET developer. Before that, I was a C/C++ and Visual Basic developer. Before that, a QuickBASIC and assembly developer.

Along the way, I have had to work with JavaScript, because World Wide Web.

I learned to dislike JavaScript early.

There were no developer tools. Notepad was about as good as it got. The Web editors of the day – Visual InterDev, FrontPage, and DreamWeaver – did not help much with JavaScript, just with HTML.

Debugging for JavaScript was worse than QuickBASIC, and reminded me of how I started debugging BASICA and Applesoft BASIC way back when. It was difficult to set breakpoints and check the interim values of variable.

Also, there was a reason strongly-typed languages like Pascal and C++ were more popular than weakly-typed languages. It was too easy to make a logical error and only find out when the program was running, so strongly-typed languages helped catch many logical errors related to using the wrong type.

JavaScript has types. It just doesn’t care much about whether you abuse the shit out of them or not, whether you do something idiotic or not. It’s just fine with whatever you do.

So here we are now.

We have better tools. Debugging is much better.

Was have Node.Js and NPM and hundreds of thousands of really cool JavaScript libraries and tools.

We have TypeScript and CoffeeScript to bring some structure and some stronger typing.

And things are better.

But they’re also worse.

When I wanted to learn any new language, it was just a matter of getting the compiler or interpreter, writing Hello World, and building up from there by reading the documentation. Patience and perseverance were the most important things you needed to possess. It was a little like building Lego toys.

This is not how things work with JavaScript.

In JavaScript, everything has so many different ways to do the same thing, where they are somewhat similar but just slightly incompatible with other parts of the solution. You really have to know and anticipate all the things before you get too far with your solution and paint yourself into a corner.

It’s a little like building your own version of Lego toys, only also using parts that come from Play-Dough, Tinkertoy, Erector Set, wooden blocks, Spirograph, Operation, Mouse Trap, Hot Wheels, Lionel model trains, Silly Putty, Slinky, Duncan Yo-Yo, and that weird bronze contraption you found in the garage that has gears and a flat-sided axle that nobody remembers what it goes to.

Sure, that’s fun.

Want to package some JavaScript files together? NPM. Solved? No. Because Bower and Yarn mix it up a little. Use Yarn. Unless you depend on Bower packages.

Want to put in a dependency on other JavaScript files? CommonJS. AMD. ES6 modules with Babel. Or not. Are you on Node or in the browser? Do you need to support both with isomorphic code?

Want a front end? React. No, wait – Angular. AngularJS or Angular? AngularJS is still active.

Want to use strong types? TypeScript. But not with AngularJS. Wait, yes, you can, but your build system will have to support it.

Build system? Webpack. No, NPM and Browserify. No, Gulp. Not Grunt. Unless you like Grunt. Nobody likes Grunt. Except Grunt fans, who don’t count because we’re not Grunt fans.

Confused yet? We’re just getting started!!

SERIOUSLY. This is not cool.

Here was a fun article I read last year, that still applies:

https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f

At least I’m not alone.

I have a peer who loves JavaScript, who used to hate it. He loves the flexibility. I suppose that once you have selected a myriad of toys that somehow have managed to get glued, soldered, banded, taped, and otherwise stuck together in a way that makes an interesting toy, then JavaScript might make some things easier.

But God help you if you are still trying to figure out how to make those toys. And I really don’t expect the creation to hold up well over time, with all the new toys that are coming out. You’ll try to stick a new thing in there … and it will expose the fragility of all the things stuck together.

Software should be built like kitchen or industrial appliances, not like artwork. It matters that your product is functional. If you make a neat kitchen blender from Legos, papier-mâché, a Slinky, and … well, let’s just say I don’t want to be responsible for adding new features to that blender.

Author

Alan McBee

comments powered by Disqus