But here’s the thing: every language is weird. And every language makes regrettable design choices early on that it has to reckon with. How and when these mistakes are dealt with is a part of the language, too. Just because you disagree with the decisions doesn’t make the language bad.
The author is free to like JS if they want but I feel like they are trying to rationalize it by drawing an equivalence between bad decisions in JS and all languages. But that is, IMO, very disrespectful to those language authors that have spent a lot of time thinking through the semantics of their language to not be surprising.
Not all language mistakes are the same, and JS makes some pretty terrible language decisions that are significantly worse than other languages. We don’t need to know the genesis of those mistake to observe that the behaviour is surprising and undesirable.
It’s OK to like JS and be fine with that but we don’t need to use faulty logic to accomplish that. We don’t need to pretend there are no faults or any faults that exist are equal to every other language’s mistakes.
It’s even more odd because his defense of Javascript is Typescript. Which is not javascript. Javascript is just a compile target at that point. It’s more like a defense of the NodeJs ecosystem than of Javascript the language.
TypeScript is “not JavaScript” in the strictest sense, but it’s a rather small superset. It adds… (surprise) static type checking. And not much else. (It can also compile some extra features like decorators… which are proposals for future JavaScript.) The compilation process is mostly just erasing type annotations. The object model, class syntax, async/await, generators, modules etc. is all standard JavaScript.
Static Type checking is huge though. It drastically changes the things that bring the most pain for Javascript development. At least it does for me anyway. Downplaying that difference downplays pretty much the biggest complaint from me about JS development.
I don’t think it’s that huge… in fact I’m still not using it. I’m working on mostly-UI apps that don’t have much logic (like, not far off from a lit-html starter example, more added HTML than JS) and I absolutely don’t feel the need for static types.
We are very different obviously. I’ve been doing this a long time and I’ve decided that types make modifying older codebases much much safer to do. And since the vast majority of my work is modifying older codebases I really value a good type system in my languages.
My personal issues with JavaScript are not with the language itself, but with the fact that a language with which people can do some pretty user-hostile things is automatically executed by my web browser.
99% of the time, I’d settle with a small set of declarative additions to HTML and CSS that would make it possible to build more dynamic webpages, but without any all-purpose imperative language. At the least, it would prevent all JavaScript-aided privacy invasions.
99% of the time, I’d settle with a small set of declarative additions to HTML and CSS that would make it possible to build more dynamic webpages, but without any all-purpose imperative language.
My biggest philosophical problem with JS on the Web is that it’s all-or-nothing, rather than incremental. With HTML and CSS, new features can be added and old ones deprecated without too much breakage, and user agents (browsers, crawlers, screen readers, format converters, etc.) can build up incrementally; if some element or style isn’t expected/understood, we can just carry on with the rest and get a reasonable result.
On the other hand, JS comes as big blobs of text and any problem (from programmer error, some feature/API not being present, etc.) causes the whole thing to abort. This is usually worked around by doing almost everything in event handlers, e.g. attached to page load; that way, only the individual handlers crash. Yet this (a) requires manual effort and (b) is very coarse grained.
I think a much nicer approach would be to first make the code’s structure more explicit, rather than relying so heavily on implicit sequencing of effects (my preference would be for s-expressions, but whatever). Second, evaluation would work by rewriting sub-expressions which match known rules; e.g. (when true x) would become x, (when false x) would get removed, etc. Interaction, events, etc. could be implemented by “stuck” expressions, e.g. (when (buttonClicked) foo), which can’t be evaluated since we don’t know what (buttonClicked) is; when the button’s clicked, (buttonClicked) gets replaced with true and the “handler” gets evaluated. This way, unknown/unexpected expressions would just get ignored, since as far as the interpreter’s concerned they’re just “stuck” (since they match no known rules); evaluation would just carry on with the rest of the structure, including inside those unknown constructs (just like HTML renderers treat unknown elements).
I haven’t fleshed this idea out much, but I think such a model feels more “Web-like” than e.g. imperative DOM operations.
Interesting ideas! My personal ideas revolve around extending CSS to allow conditional rules and extending HTML with a declarative interface for remote requests. My writings about it were posted here on Lobste.rs a while back, if you’re interested.
I don’t have a beef with JavaScript itself, despite occasional jokes about Douglas Crockford’s JavaScript: the Good Parts being a fantasy novel because there are no good parts.
I do have a beef with people who use JavaScript to enable adtech, user tracking, and other nefarious shit that most people cannot block without breaking the vast majority of websites and web apps.
How do such developers justify the shit they do for a paycheck? I’ve seen televangelists with more integrity.
No, it’s really not a good language. It’s a pretty terrible language on which a colossal malinvestment of human resources has been squandered, leading to a not-entirely-terrible ecosystem which is just barely usable for real work.
If the effort which had been mis-spent on JavaScript had instead been focused on an actually good language, then the world would be so much better off now.
Not just that, though: JavaScript has poisoned the web. What was once a really nice way to serve resources has become a grotesque, undesigned application development platform whose sole virtue is that it’s been deployed everywhere. Also, it’s used regularly to undermine privacy & security.
I’m glad the author has an environment they like, and I absolutely adore many things built in the worldwide JavaScript community. I don’t want to yuck anyone’s yum!
That said, as far as “a language is good/bad” can have any meaning, I don’t think this is a persuasive defense of the language. Most of the points have comparables in other languages that are far superior, and the history of working with JavaScript is a lot richer than what the author describes here.
The syntax section uses cutting-edge features of JavaScript syntax (async/await, let/const, fat arrow functions) which is far from most of the JavaScript code much active maintenance happens in. Most of us still have to understand var and deal with its weird function-scoping, and have to use callbacks or promises instead of async/await. When you take that code sample and backport it to how it’s almost always looked, it’s certainly a tangled nest of weeds that few would call a fun time.
It also elides what language features could enable something better, like preemptive scheduling or proper lexical scoping. My experience has been that, no matter what version of JS you’re writing, you have to know 4 meanings of this and the minor differences between function() { and () => { to maintain most codebases.
This also doesn’t go into the various abstractions one can use: in Ruby or Java, you have Objects. In OCaml, you have modules and functions (some folks use the OO features but it’s rare). In my experience, JS has far less consensus: some use objects like Lua tables, some use them to create class hierarchies, some write something like Scheme and largely rely on functions.
When the author gets to toolchains, which is mostly backporting other language features. Static type checking is great, but it’s a far cry away from something like Reason or Rust. It’s still opt-in. Are all those linters really a world above gofmt? How about the complexity of picking one, then integrating it with grunt/gulp/webpack/Make? And with Jamine/Chai/other test frameworks?
When you stitch something together, it is very impressive, but I don’t think the language helped us here, it was more the sheer number of bodies and amount of investment by the world’s wealthiest companies.
I do most of my programming interviews in JS because I’ve learned to be fast with it, and again, I highly appreciate a ton about it. I also think there are many people who hate on JS in an over-the-top, performative way that’s probably them just trying to feel important. But when people criticize a language that was designed in 10 days for looking like it was designed in 10 days, I think it’s valid.
Javascript is poor language but its runtime environment is great:
Drawing things is accomplished by manipulating tree of data and loading appearance rules, not by onPaint
Elements of this tree are just data records, not shady OOP objects incapsulating mystery state and having 10 inheritance parents
Easy text layouting and vector graphics
Works on all major operating systems
Running apps off network storage
This is why iOS and Android developers (mentioned in article) think that js is way better and simpler. Swift and Kotlin are surely better designed than JS, but environments are terrible there, not much better than WinAPI and MFC.
This is also why Electron is popular, despite existence of PyQt/PySide.
I think the notion of some languages as “bad” is really problematic. Languages are huge collections of ideas, some are likely helpful to you and some not. This post does a great job of explaining this argument for javascript
That quote always comes up in these kinds of things. And it’s a stupid quote. Like most things that try to draw dichotomies, it’s not really true. Not every language people used is equally bitched about. Some people even praise languages more than complain about it. That quote is effectively used to argue for any status quo. Let’s not try to discuss how we could do things better because people will just bitch about it anyways. Or all languages equally suck so let’s use whatever we have here. It really adds nothing to the conversation.
I heard this phrase a lot when I was a PHP developer. In my experience it was used as a conversation stopper, which got very frustrating.
For example, after fixing some bug I might recommend that we stick to using === instead of == because the latter behaves in complicated and potentially confusing ways; get the reply “There are two kinds of programming languages…”. OK, that’s nice, but are we going to use === instead of == or not?
Or we might be discussing how to design a certain system or feature. Point out that X tends to be a bad idea due to Y, get the response “There are two kinds of programming languages…” “So…?” “We’re going with X”.
It doesn’t mean that you shouldn’t complain, or even that you’re a conservative person who like to use latin phrases here and there. :) It rather means that, generally, people complain a lot about any successful language.
Some people even praise languages more than complain about it.
Sure, but I’d assert that those tend overwhelmingly to be niche languages.
A lot of people love languages like APL, Haskell, ML, Idris, Elm, and so forth–fact is, those languages just aren’t very relevant to mainstream software engineering.
The best thing that can be said is that exposure to them helps people using bad languages reconsider how to approach things in their vulgar daily driver. The worst thing to be said is that zealots of those languages try to infect otherwise bearable languages with features from their pet tongue and in so doing make things more complicated for everybody else (FP folks did this to C++, Java folks did this to JS, etc.)
I really like coding in JS. I also really like coding in Java. And Ruby. And Python. And pretty much anything.
To be honest, the only things that irk me are languages with odd syntactical features that make typing more difficult (thinking immediately of PHP’s $object->method), but I still enjoy working with those languages.
All that said, I’m most productive in plain old JavaScript, but it’s because I know it the best (been coding in it since the 90s). Yeah, it has quirks to it and some weird stuff, but I still like it. It is missing some things I really like in some other languages, but it has some cool features that some other languages don’t have too. I’m not trying to compare them beyond that, they all have their uses. Can’t we all just get along? 🙃
The author is free to like JS if they want but I feel like they are trying to rationalize it by drawing an equivalence between bad decisions in JS and all languages. But that is, IMO, very disrespectful to those language authors that have spent a lot of time thinking through the semantics of their language to not be surprising.
Not all language mistakes are the same, and JS makes some pretty terrible language decisions that are significantly worse than other languages. We don’t need to know the genesis of those mistake to observe that the behaviour is surprising and undesirable.
It’s OK to like JS and be fine with that but we don’t need to use faulty logic to accomplish that. We don’t need to pretend there are no faults or any faults that exist are equal to every other language’s mistakes.
It’s even more odd because his defense of Javascript is Typescript. Which is not javascript. Javascript is just a compile target at that point. It’s more like a defense of the NodeJs ecosystem than of Javascript the language.
TypeScript is “not JavaScript” in the strictest sense, but it’s a rather small superset. It adds… (surprise) static type checking. And not much else. (It can also compile some extra features like decorators… which are proposals for future JavaScript.) The compilation process is mostly just erasing type annotations. The object model, class syntax, async/await, generators, modules etc. is all standard JavaScript.
Static Type checking is huge though. It drastically changes the things that bring the most pain for Javascript development. At least it does for me anyway. Downplaying that difference downplays pretty much the biggest complaint from me about JS development.
I don’t think it’s that huge… in fact I’m still not using it. I’m working on mostly-UI apps that don’t have much logic (like, not far off from a lit-html starter example, more added HTML than JS) and I absolutely don’t feel the need for static types.
We are very different obviously. I’ve been doing this a long time and I’ve decided that types make modifying older codebases much much safer to do. And since the vast majority of my work is modifying older codebases I really value a good type system in my languages.
My personal issues with JavaScript are not with the language itself, but with the fact that a language with which people can do some pretty user-hostile things is automatically executed by my web browser.
99% of the time, I’d settle with a small set of declarative additions to HTML and CSS that would make it possible to build more dynamic webpages, but without any all-purpose imperative language. At the least, it would prevent all JavaScript-aided privacy invasions.
My biggest philosophical problem with JS on the Web is that it’s all-or-nothing, rather than incremental. With HTML and CSS, new features can be added and old ones deprecated without too much breakage, and user agents (browsers, crawlers, screen readers, format converters, etc.) can build up incrementally; if some element or style isn’t expected/understood, we can just carry on with the rest and get a reasonable result.
On the other hand, JS comes as big blobs of text and any problem (from programmer error, some feature/API not being present, etc.) causes the whole thing to abort. This is usually worked around by doing almost everything in event handlers, e.g. attached to page load; that way, only the individual handlers crash. Yet this (a) requires manual effort and (b) is very coarse grained.
I think a much nicer approach would be to first make the code’s structure more explicit, rather than relying so heavily on implicit sequencing of effects (my preference would be for s-expressions, but whatever). Second, evaluation would work by rewriting sub-expressions which match known rules; e.g.
(when true x)would becomex,(when false x)would get removed, etc. Interaction, events, etc. could be implemented by “stuck” expressions, e.g.(when (buttonClicked) foo), which can’t be evaluated since we don’t know what(buttonClicked)is; when the button’s clicked,(buttonClicked)gets replaced withtrueand the “handler” gets evaluated. This way, unknown/unexpected expressions would just get ignored, since as far as the interpreter’s concerned they’re just “stuck” (since they match no known rules); evaluation would just carry on with the rest of the structure, including inside those unknown constructs (just like HTML renderers treat unknown elements).I haven’t fleshed this idea out much, but I think such a model feels more “Web-like” than e.g. imperative DOM operations.
Interesting ideas! My personal ideas revolve around extending CSS to allow conditional rules and extending HTML with a declarative interface for remote requests. My writings about it were posted here on Lobste.rs a while back, if you’re interested.
I don’t have a beef with JavaScript itself, despite occasional jokes about Douglas Crockford’s JavaScript: the Good Parts being a fantasy novel because there are no good parts.
I do have a beef with people who use JavaScript to enable adtech, user tracking, and other nefarious shit that most people cannot block without breaking the vast majority of websites and web apps.
How do such developers justify the shit they do for a paycheck? I’ve seen televangelists with more integrity.
No, it’s really not a good language. It’s a pretty terrible language on which a colossal malinvestment of human resources has been squandered, leading to a not-entirely-terrible ecosystem which is just barely usable for real work.
If the effort which had been mis-spent on JavaScript had instead been focused on an actually good language, then the world would be so much better off now.
Not just that, though: JavaScript has poisoned the web. What was once a really nice way to serve resources has become a grotesque, undesigned application development platform whose sole virtue is that it’s been deployed everywhere. Also, it’s used regularly to undermine privacy & security.
I’m glad the author has an environment they like, and I absolutely adore many things built in the worldwide JavaScript community. I don’t want to yuck anyone’s yum!
That said, as far as “a language is good/bad” can have any meaning, I don’t think this is a persuasive defense of the language. Most of the points have comparables in other languages that are far superior, and the history of working with JavaScript is a lot richer than what the author describes here.
The syntax section uses cutting-edge features of JavaScript syntax (async/await, let/const, fat arrow functions) which is far from most of the JavaScript code much active maintenance happens in. Most of us still have to understand
varand deal with its weird function-scoping, and have to use callbacks or promises instead of async/await. When you take that code sample and backport it to how it’s almost always looked, it’s certainly a tangled nest of weeds that few would call a fun time.It also elides what language features could enable something better, like preemptive scheduling or proper lexical scoping. My experience has been that, no matter what version of JS you’re writing, you have to know 4 meanings of
thisand the minor differences betweenfunction() {and() => {to maintain most codebases.This also doesn’t go into the various abstractions one can use: in Ruby or Java, you have Objects. In OCaml, you have modules and functions (some folks use the OO features but it’s rare). In my experience, JS has far less consensus: some use objects like Lua tables, some use them to create class hierarchies, some write something like Scheme and largely rely on functions.
When the author gets to toolchains, which is mostly backporting other language features. Static type checking is great, but it’s a far cry away from something like Reason or Rust. It’s still opt-in. Are all those linters really a world above
gofmt? How about the complexity of picking one, then integrating it with grunt/gulp/webpack/Make? And with Jamine/Chai/other test frameworks?When you stitch something together, it is very impressive, but I don’t think the language helped us here, it was more the sheer number of bodies and amount of investment by the world’s wealthiest companies.
I do most of my programming interviews in JS because I’ve learned to be fast with it, and again, I highly appreciate a ton about it. I also think there are many people who hate on JS in an over-the-top, performative way that’s probably them just trying to feel important. But when people criticize a language that was designed in 10 days for looking like it was designed in 10 days, I think it’s valid.
Javascript is poor language but its runtime environment is great:
onPaintThis is why iOS and Android developers (mentioned in article) think that js is way better and simpler. Swift and Kotlin are surely better designed than JS, but environments are terrible there, not much better than WinAPI and MFC.
This is also why Electron is popular, despite existence of PyQt/PySide.
I think the notion of some languages as “bad” is really problematic. Languages are huge collections of ideas, some are likely helpful to you and some not. This post does a great job of explaining this argument for javascript
When reading Javascript/PHP rants, I’m always reminded of this:
That quote always comes up in these kinds of things. And it’s a stupid quote. Like most things that try to draw dichotomies, it’s not really true. Not every language people used is equally bitched about. Some people even praise languages more than complain about it. That quote is effectively used to argue for any status quo. Let’s not try to discuss how we could do things better because people will just bitch about it anyways. Or all languages equally suck so let’s use whatever we have here. It really adds nothing to the conversation.
I heard this phrase a lot when I was a PHP developer. In my experience it was used as a conversation stopper, which got very frustrating.
For example, after fixing some bug I might recommend that we stick to using
===instead of==because the latter behaves in complicated and potentially confusing ways; get the reply “There are two kinds of programming languages…”. OK, that’s nice, but are we going to use===instead of==or not?Or we might be discussing how to design a certain system or feature. Point out that X tends to be a bad idea due to Y, get the response “There are two kinds of programming languages…” “So…?” “We’re going with X”.
Thankfully I’m no longer a PHP developer.
It doesn’t mean that you shouldn’t complain, or even that you’re a conservative person who like to use latin phrases here and there. :) It rather means that, generally, people complain a lot about any successful language.
Sure, but I’d assert that those tend overwhelmingly to be niche languages.
A lot of people love languages like APL, Haskell, ML, Idris, Elm, and so forth–fact is, those languages just aren’t very relevant to mainstream software engineering.
The best thing that can be said is that exposure to them helps people using bad languages reconsider how to approach things in their vulgar daily driver. The worst thing to be said is that zealots of those languages try to infect otherwise bearable languages with features from their pet tongue and in so doing make things more complicated for everybody else (FP folks did this to C++, Java folks did this to JS, etc.)
I really like coding in JS. I also really like coding in Java. And Ruby. And Python. And pretty much anything.
To be honest, the only things that irk me are languages with odd syntactical features that make typing more difficult (thinking immediately of PHP’s
$object->method), but I still enjoy working with those languages.All that said, I’m most productive in plain old JavaScript, but it’s because I know it the best (been coding in it since the 90s). Yeah, it has quirks to it and some weird stuff, but I still like it. It is missing some things I really like in some other languages, but it has some cool features that some other languages don’t have too. I’m not trying to compare them beyond that, they all have their uses. Can’t we all just get along? 🙃