Hey! Thanks for reading! Just a reminder that I wrote this some years ago, and may have much more complicated feelings about this topic than I did when I wrote it. Happy to elaborate, feel free to reach out to me! 😄
🎵 The song for this post is Bustin', by Neil Cicierega. 🎵
The short answer is I don't usually love it; but have loved it before and most haters are shortsighted. Let's elaborate, I'll start with the flames, since that's probably what you're here for.🍿
There are four meanings of
var scoping and function hoisting
have no precedent in any other language I can find (it's usually just called a
scoping bug). Before strict mode, if you define a variable without
it is globally scoped by default. All functions are vararg functions. You have
no integers, all numbers are floats. Null, the billion-dollar mistake, is
Implicit casting rules, combined with truthy/falsey values,
are a legendary hell.
==, but also
This isn't to say it's not liveable (we clearly do live with it), but I don't think I can ever love this language when there's all this mess going on.
But it was designed in 10 days!
But [thing you mentioned] isn't a problem anymore because [subsequent library or tool]!
Many companies you'll work at are still using Backbone or Angular 1 or whatever tool was popular at the time. You may be maintaining CoffeeScript v1! Which was great, but it's also an uncanny valley of "kinda ES6 but not."
In this way, you still have to know all the pitfalls of the language to appropriately maintain and debug, since many codebases won't (for reasons of history or portability) get to take advantage of The New Hotness.
And the [subsequent library or tool] you mentioned? There's usually competition behind which one to use, and it's normally to add some language feature that exists elsewhere. Did you pick TypeScript or Flow? Cool, you just got types. Remember when we were fighting over RequireJS and CommonJS? Nice, now you've got modules, until ES6 got modules (in their defense, C++ still doesn't have them 😝).
Having to choose between popular competitors and configuring it into a working
build system goes beyond language features: did you pick Bluebird or q for promises?
Ever seen a project with both
.jslintrc? Are you into Chai
or Jasmine? Did you get on the Bower train when that was the way to
build things? Did you/do you invest in Brunch? Browserify?
Yeoman? Yarn or NPM? And on and on and on… these are all off the top of my
head, and I've never been a full-time frontend dev!
To be clear, ecosystem competition is great, and I love most of these tools. But almost all of those tools are, in my mind, addressing weaknesses in the language and/or building projects in it, and there is a lot of mental overhead in keeping track of any of them.
this is for a server program that's 328 lines whose job is to serve static files and mock data.— 💣 b∀BГO 💣 (@SrPablo) October 8, 2015
we in Node again pic.twitter.com/Aik5ZzhsB2
At the same time, server developers like me have a terrible habit of being self-serious and treating their programming like it's Real Programming. The browser is a fucking nightmare, and developers who build tools and program for it deserve massive commends.
Front end software development is:— Yehuda Katz 🥨 (@wycats) November 14, 2017
- real-time (instant load, 60fps)
- distributed, incremental (synchronize remote data as needed)
- reactive (react to user actions in realtime)
Front end is the hardest kind of dev I do. The folks who do it every day are heroes.
It's also worth noting that other languages aren't really aren't much better at
this. It's hard to complain about build tools when you consider what goes on in
./configure script, or think about trying to produce a project in Python:
It's worth mentioning that a lot of JS's complexity comes from serving the most globbed-on, fast-changing, widest-available platform and APIs in history. JS applications have to make sense of a document model that does multiple network calls compatible with every possible display size. Of course its got messy bits.
virtually no other mainstream language has: transparent object types. You
can take any object, pass it to
inspect its properties.
In Java you have to you write
toString(), Python it's
__str__(), Ruby it's
to_s, and in each you have to keep it up to date with
its fields. And you can only really do this with objects you define!
While it's dogma that objects should be opaque and we should operate purely
on interfaces, in practice, when I need to see what's happening, I find this
invaluable. I'm a
printf debugger through and through.
tickled and frustrated with how much fun hacking in Node is— 💣 b∀BГO 💣 (@SrPablo) September 5, 2016
I love the web and am glad its winning; the web as a terrible, horrible, very bad, no-good platform that probably shouldn't have so much power in execution context is well-illustrated by this tale.
- Fast rendering.
- Search indexability.
- Easy l10n + translatable as a page from a tool.
Similarly, I like the Vanilla JS splash page 😛
Related questions I'm not tackling in-depth — rapid fire!
How do you feel about The Most Modern Version of JS? — it's far too much like Scala, doing too many things at a time, gives me a headache to read it.
I promise I'll blog something unambiguously positive next 😄
Thanks for the read! Disagreed? Violent agreement!? Feel free to join my mailing list, drop me a line at , or leave a comment below! I'd love to hear from you 😄