JavaScript is not as bad as people make it out to be

ooh I’m sure this one is gonna be really controversial but here I go
time and time again I’ve heard from people just how horrible JavaScript is, but I beg to differ.
- this is my opinion after having experienced writing a small to medium-sized JavaScript app for some stuff I’ve been working on for the treehouse.
  - can’t tell you what it is yet.
I will purposefully refrain from talking about the JavaScript package ecosystem, because I don’t use it myself.
- my past experiences using npm have been quite painful, so I wouldn’t recommend using it for anything.
  - (obviously this is written from the perspective of an indie website; different requirements will mandate different solutions, and you should pick the right one for you!)
let me start with the hugest advantage JavaScript has over literally every single language in the world: you already have it on your computer.
- don’t believe me? let me show you:
  console.log("see?") // and if you have JavaScript enabled, you can edit this!
  see?
- and this goes for pretty much every modern personal computing device on the planet nowadays - you can already run JavaScript on it.
  - sure it may not be the cleanest language in terms of design, but JavaScript running anywhere and everywhere is its superpower.
- JavaScript being available on everyone’s computers makes it a super-accessible programming language to learn: all you have to do is open your web browser and go to the console in its Developer Tools.
  - moreso, if you are building a website and would like to embed a language interpreter (like me,) you already have JavaScript for that.
    yes, you could in theory embed Lua, but for most cases JavaScript is Already There and there is nothing wrong with it. apart from the fact that it’s kind of hard to sandbox.
    this is precisely why tairu is written in JavaScript - not because it’s a particularly good language for the task, I think for game development C++ is a lot better - but I really wanted to build a blog post environment with interactive code examples, and JavaScript is the only way to do that without pulling in any dependencies.
the 2nd best part of JavaScript is that if the author wants it (and you should!) it’s extremely easy to inspect .js files and learn from them.
- if you’re on a computer, you can try it yourself with the treehouse!
- if you’re an independent blogger and you believe that having a more open Web is something you’d like, you should also avoid minifying your .js files.
  - gzip or brotli compression can already do wonders with compressing your text files - according to PageSpeed Insights, I could shave off around 48 KiB of transferred CSS and JS in the treehouse just by compressing it.
    I don’t do it yet only because I haven’t yet gotten around to doing it. I can’t really pre-compress certain assets, too - such as /b? links, which have a dynamically-generated description. I could probably LRU-cache those though.
when you do get to the language… it’s really not as bad as many people paint it
- the biggest quirks of JavaScript lie around the type system.
  - I do believe some of the type coercions are pretty inexcusable, but I’ve never really run into them in practice
  - stuff like "" == false is a result of having to disambiguate type mismatches, but arguably you shouldn’t be passing incompatible types around in the first place.
    the TypeScript language server makes this easier, because it has type inference that can show types in your IDE.
  - if you really hate the type system, there’s always TypeScript. I choose not to use it in the treehouse codebase, because I don’t like additional build steps slowing down generation.
    the TypeScript compiler is slow enough to require me to perform incremental compilation, which complicates builds a lot.
    right now the treehouse regenerates itself in its entirety, every single time. iirc this takes around 40ms on debug mode, on Linux. because moving files around on Windows is really slow.
    I love NTFS
    arguably there’s swc but that still requires parsing and reemitting the JS
    
    this may not be a lossless process, and I would like to preserve all comments and spacing choices
    
    parsing is slow. one thing I tried was to automatically make all links in the generated HTML have something akin to a ?cache= query that would make the server inject a “cache forever” policy, but it extended build times pretty much twofold.
    
    adding a release mode switch is one solution, but it’s an extra code branch I have to maintain. if I build only in debug mode locally, and then I push onto production which runs release mode, I won’t find any bugs with the release mode-only parts of the generator until I get to production.
    also I was using html5ever which uses hash maps everywhere and produces non-deterministic HTML files
- Web Components, albeit being pretty verbose, are a surprisingly pleasant API to work with.
  - apart from sometimes having to deal with tricky state updates, retained UI is still a really robust framework to build your UI on.
  - my only problem with programming the Web is that sometimes you Just Wanna Draw Shit on the Screen, but it doesn’t let you do that. you have to go through <svg> or <canvas>, both of which are kind of annoying to use.
    <svg> needs tricky state updates, and it’s hard to write code with it that doesn’t thrash the heap and make the GC stutter your page into oblivion.
    <canvas> is not DPI-aware by default, so if you zoom into it, you’ll get a pixelated mess.
so like, yeah. stay away from npm and coding in JavaScript really isn’t that bad.
- the modern Web platform is a really mature kit for building apps that run anywhere. I think that is a really valuable tool to have in my toolbelt, even if JavaScript can be a bit quirky at times.