6 ms·

It's been 16 or 17 years since I wrote my first line of JavaScript and I still hate the language and almost everything that comes with it. The language is still

It's been 16 or 17 years since I wrote my first line of JavaScript and I still hate the language and almost everything that comes with it. The language is still arcane, even if or sometimes even more so if you use TypeScript; browser incompatibilities are still prevalent (though not as ugly as they used to be); and even popular libraries are barely documented and you regularly have to wade through hundreds of wannabe tutorials on Medium/Hackernoon/… by people who, as it turns out, don't have a clue any more than you do, until you finally come across that one open Github issue that explains (and confirms) all the reasons for your frustration. What's more, people are adding more magic and opaqueness to their build pipelines every day. There's not one linker ("bundler", "loader") and one compiler/transpiler, no, there are several. And depending on the bundler, loaders, compiler and transpiler and the target platform, some things like imports might work in completely different ways. (If you thought getting imports right in Python was difficult, good luck with JS.) Of course, these often happen to be precisely the things that are not well documented at all. I'm not sure what the point of my post is, other than to vent. I guess sometimes I just wish we would get rid of JavaScript entirely and switch to a sane language with sane build tools.

ostenning 5y ago
Your frustrations are felt by many. Every tool is attempting to dethrone the competition, coming up with yet another way to do the same simple yet infinitely elusive fucking goal: render a website. The whole ecosystem is fucked
ASalazarMX 5y ago
JavaScript was made in like ten days just to add missing interactivity to HTML. If Brendan Eich had known how it was going to be used today, the language would have been very different, if at all. Edit: it seems I don't have to wonder. Type coercion is one of the worst features IMO, and coincidentally one of his regrets: > "One of the notorious ones was, ‘I’d like to compare a number to a string that contains that numeral. And I don’t want to have to change my code to convert the string to a number, or the number to a string. I just want it to work. Can you please make the equals operator just say, Oh this looks like a two, and this looks like a string number two. They’re equal enough.’" > "And I did it. And that’s a big regret, because that breaks an important mathematical property, the equivalence relation property… It led to the addition of a second kind of equality operator when we standardized JavaScript.” One of the people who helped standardize JavaScript was Guy Steele, one of the co-creators of Scheme. “Guy said, ‘Don’t worry about it. There are Lisps that have five kinds of equals operators. We’ll just add another one.'" https://thenewstack.io/brendan-eich-on-creating-javascript-in-10-days-and-what-hed-do-differently-today/ https://thenewstack.io/brendan-eich-on-creating-javascript-i...
- deckard1 5y ago
  The problem with equality and dynamic typing is rather deep and intractable. Kent Pitman (of Lisp fame) has an entire essay about it: https://www.nhplace.com/kent/PS/EQUAL.html https://www.nhplace.com/kent/PS/EQUAL.html > If COPY can't be done properly, then neither can EQUAL. And, in fact, that's the case. There is no uniquely determined equality function for complex structures--there are only arbitrary ones. What Steele says about equality is true for Scheme. Everyone has seen the famous "Wat" video of adding "{} + {}" in Ruby or JS. But no one ever mentions Scheme or Lisp: scheme@(guile-user)> (eq? "test" "test") $1 = #t scheme@(guile-user)> (eqv? "test" "test") $2 = #t scheme@(guile-user)> (define x "test") scheme@(guile-user)> (define y "test") scheme@(guile-user)> (eq? x y) $3 = #f scheme@(guile-user)> (eqv? x y) $4 = #f Of course, if you read the RxRS specs then it's all documented and to be expected. But the same is true for JavaScript. As much as I hate typing the "===", there is precedence. > breaks an important mathematical property Even mathematicians get lazy and create new syntax and short cuts to express their ideas. Programming is ultimately a human UI. It's easy to see why automatic type coercion was once popular (and probably will be again, I can almost guarantee this).
  - tialaramex 5y ago
    I was surprised that I was OK with that fact that in Rust a vector and an array with the same elements compare equal. It felt completely reasonable, and I definitely didn't feel that way about it in some other languages where that's true.
    - bsder 5y ago
      Erm, no, that doesn't work. I created a quick check in the Rust Playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=473a0c6db6ca709a11dd501e38f3f0dc https://play.rust-lang.org/?version=stable&mode=debug&editio... Do you have some more context? I suspect somehow things are getting coerced to slices and then compared.
      - Measter 5y ago
chain-- 5y ago
I like Javascript (mainly Typescript) and use it quite a lot. If you aren't a fan, I completely understand. However I don't understand why people feel the need to discredit something that they don't like. It honestly makes me not want to open HN threads about JS as I know I will be met with a barrage of negative comments about something that I enjoy. I'm all for open discussion of the downsides of the JS ecosystem but that is rarely what these comments are.
- eweise 5y ago
  They gave a laundry list of reason why it sucks so its a not a dislike based on personal preference. JS actually does suck.
- jacquesm 5y ago
  It is very well possible to like working in a language and to have a sincere dislike for its shortcomings. Language shortcomings are those things that repeatedly bite you in the backside or require work-arounds when there would have been alternatives known at the time of language design that would have avoided those particular pitfalls.
  - chain-- 5y ago
    I completely agree with that, there are some things that would be nice to change that are unlikely ever to be changed due to the goal of being backwards compatible. But a lot of the OP's comment was unrelated to the language itself. > browser incompatibilities are still prevalent It's true, browser difference are a pain to work with. But what is the alternative, to only support a single browser engine? Note that this has improved a lot in recent years. As long as you don't need to support IE11 or below then you shouldn't come across many issues. You can find browser support using caniuse.com or looking at MDN docs. > even popular libraries are barely documented and you regularly have to wade through hundreds of wannabe tutorials on Medium/Hackernoon/... I don't think that incomplete documentation is is exclusive to Javascript by any means. It is quite possible that the standard for packages and articles is lower due to Javascript having a lower entry level. I think we saw a similar thing with PHP. > one compiler/transpiler, no, there are several... I personally don't see a problem with this? Usually they have different goals, pros and cons. Do we think that it would be beneficial to not create competing solutions? For example would it be beneficial to only have React and not have Angular, Vue, Svelte? Agreed that multiple solutions can be confusing for new users and generally I would direct new developers to all-in-one solutions so they don't need to deal with these things. > some things like imports might work in completely different ways I'm not quite sure what is being referred to here, maybe the difference between commonjs and es imports? I personally haven't encountered any issues but they are completely different. I might be able to point someone in the right direction if they clarify. Again I understand if you don't like having to deal with these things, but there are reasons for them that can't just be glossed over. Discussions are great! But I find it hard to have them when developers ignore the nuances and insist on approaching them from a negative angle.
austincheney 5y ago
Most of my career in the mega Corp world has enjoyed watching people struggle to really put the Java in JavaScript. Epic fail. There are many valid reasons to hate JavaScript but ignorant Java developers is not one of them.
- spiralx 5y ago
  Going from Java to JavaScript really does seem to be painful for developers who don't know other languages as well, I know what you mean... "A closure?" I'm sure it's an easier switch today but I've read a lot of awkward JS written by people who came from Java 5 and earlier.
greenhatman 5y ago
Have you considered a career change? I'm sure there are jobs that don't require JavaScript.
chrbp 5y ago
None of what you said is unique to JavaScript. Take a look at any language that has a similarly large adoption and you'll see similar frustrations. Half-baked frameworks and libraries, largely undocumented popular projects and build tools with steep learning curves. Why we have so many of the same thing that seemingly solves the same issues? Could it be because people have different needs and requirements that aren't already solved by these tools? Perhaps the tools over complicate things that could be simplified? From Grunt and Gulp, onto Webpack, Parcel and Rollup, and now Snowpack, ESBuild and WMR – Each solving a similar problem much differently from each other due to the new kind of applications and the problems that come with it. To provide a good user experience for a majority of people, there are a lot of things that has to be done to make that possible here and now. Browsers, unfortunately, don't update quick enough to provide the UX until the problem is big enough to warrant a built-in solution. That is how the web has been able to move forward; by peoples innovation in the space and the approaches they took to solve them.

ostenning 5y ago

Your frustrations are felt by many. Every tool is attempting to dethrone the competition, coming up with yet another way to do the same simple yet infinitely elusive fucking goal: render a website. The whole ecosystem is fucked

ASalazarMX 5y ago

JavaScript was made in like ten days just to add missing interactivity to HTML. If Brendan Eich had known how it was going to be used today, the language would have been very different, if at all. Edit: it seems I don't have to wonder. Type coercion is one of the worst features IMO, and coincidentally one of his regrets: > "One of the notorious ones was, ‘I’d like to compare a number to a string that contains that numeral. And I don’t want to have to change my code to convert the string to a number, or the number to a string. I just want it to work. Can you please make the equals operator just say, Oh this looks like a two, and this looks like a string number two. They’re equal enough.’" > "And I did it. And that’s a big regret, because that breaks an important mathematical property, the equivalence relation property… It led to the addition of a second kind of equality operator when we standardized JavaScript.” One of the people who helped standardize JavaScript was Guy Steele, one of the co-creators of Scheme. “Guy said, ‘Don’t worry about it. There are Lisps that have five kinds of equals operators. We’ll just add another one.'" https://thenewstack.io/brendan-eich-on-creating-javascript-in-10-days-and-what-hed-do-differently-today/ https://thenewstack.io/brendan-eich-on-creating-javascript-i...

deckard1 5y ago
The problem with equality and dynamic typing is rather deep and intractable. Kent Pitman (of Lisp fame) has an entire essay about it: https://www.nhplace.com/kent/PS/EQUAL.html https://www.nhplace.com/kent/PS/EQUAL.html > If COPY can't be done properly, then neither can EQUAL. And, in fact, that's the case. There is no uniquely determined equality function for complex structures--there are only arbitrary ones. What Steele says about equality is true for Scheme. Everyone has seen the famous "Wat" video of adding "{} + {}" in Ruby or JS. But no one ever mentions Scheme or Lisp: scheme@(guile-user)> (eq? "test" "test") $1 = #t scheme@(guile-user)> (eqv? "test" "test") $2 = #t scheme@(guile-user)> (define x "test") scheme@(guile-user)> (define y "test") scheme@(guile-user)> (eq? x y) $3 = #f scheme@(guile-user)> (eqv? x y) $4 = #f Of course, if you read the RxRS specs then it's all documented and to be expected. But the same is true for JavaScript. As much as I hate typing the "===", there is precedence. > breaks an important mathematical property Even mathematicians get lazy and create new syntax and short cuts to express their ideas. Programming is ultimately a human UI. It's easy to see why automatic type coercion was once popular (and probably will be again, I can almost guarantee this).
- tialaramex 5y ago
  I was surprised that I was OK with that fact that in Rust a vector and an array with the same elements compare equal. It felt completely reasonable, and I definitely didn't feel that way about it in some other languages where that's true.
  - bsder 5y ago
    Erm, no, that doesn't work. I created a quick check in the Rust Playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=473a0c6db6ca709a11dd501e38f3f0dc https://play.rust-lang.org/?version=stable&mode=debug&editio... Do you have some more context? I suspect somehow things are getting coerced to slices and then compared.
    - Measter 5y ago

chain-- 5y ago

I like Javascript (mainly Typescript) and use it quite a lot. If you aren't a fan, I completely understand. However I don't understand why people feel the need to discredit something that they don't like. It honestly makes me not want to open HN threads about JS as I know I will be met with a barrage of negative comments about something that I enjoy. I'm all for open discussion of the downsides of the JS ecosystem but that is rarely what these comments are.

eweise 5y ago
They gave a laundry list of reason why it sucks so its a not a dislike based on personal preference. JS actually does suck.
jacquesm 5y ago
It is very well possible to like working in a language and to have a sincere dislike for its shortcomings. Language shortcomings are those things that repeatedly bite you in the backside or require work-arounds when there would have been alternatives known at the time of language design that would have avoided those particular pitfalls.
- chain-- 5y ago
  I completely agree with that, there are some things that would be nice to change that are unlikely ever to be changed due to the goal of being backwards compatible. But a lot of the OP's comment was unrelated to the language itself. > browser incompatibilities are still prevalent It's true, browser difference are a pain to work with. But what is the alternative, to only support a single browser engine? Note that this has improved a lot in recent years. As long as you don't need to support IE11 or below then you shouldn't come across many issues. You can find browser support using caniuse.com or looking at MDN docs. > even popular libraries are barely documented and you regularly have to wade through hundreds of wannabe tutorials on Medium/Hackernoon/... I don't think that incomplete documentation is is exclusive to Javascript by any means. It is quite possible that the standard for packages and articles is lower due to Javascript having a lower entry level. I think we saw a similar thing with PHP. > one compiler/transpiler, no, there are several... I personally don't see a problem with this? Usually they have different goals, pros and cons. Do we think that it would be beneficial to not create competing solutions? For example would it be beneficial to only have React and not have Angular, Vue, Svelte? Agreed that multiple solutions can be confusing for new users and generally I would direct new developers to all-in-one solutions so they don't need to deal with these things. > some things like imports might work in completely different ways I'm not quite sure what is being referred to here, maybe the difference between commonjs and es imports? I personally haven't encountered any issues but they are completely different. I might be able to point someone in the right direction if they clarify. Again I understand if you don't like having to deal with these things, but there are reasons for them that can't just be glossed over. Discussions are great! But I find it hard to have them when developers ignore the nuances and insist on approaching them from a negative angle.

austincheney 5y ago

Most of my career in the mega Corp world has enjoyed watching people struggle to really put the Java in JavaScript. Epic fail. There are many valid reasons to hate JavaScript but ignorant Java developers is not one of them.

spiralx 5y ago
Going from Java to JavaScript really does seem to be painful for developers who don't know other languages as well, I know what you mean... "A closure?" I'm sure it's an easier switch today but I've read a lot of awkward JS written by people who came from Java 5 and earlier.

greenhatman 5y ago

Have you considered a career change? I'm sure there are jobs that don't require JavaScript.

chrbp 5y ago

None of what you said is unique to JavaScript. Take a look at any language that has a similarly large adoption and you'll see similar frustrations. Half-baked frameworks and libraries, largely undocumented popular projects and build tools with steep learning curves. Why we have so many of the same thing that seemingly solves the same issues? Could it be because people have different needs and requirements that aren't already solved by these tools? Perhaps the tools over complicate things that could be simplified? From Grunt and Gulp, onto Webpack, Parcel and Rollup, and now Snowpack, ESBuild and WMR – Each solving a similar problem much differently from each other due to the new kind of applications and the problems that come with it. To provide a good user experience for a majority of people, there are a lot of things that has to be done to make that possible here and now. Browsers, unfortunately, don't update quick enough to provide the UX until the problem is big enough to warrant a built-in solution. That is how the web has been able to move forward; by peoples innovation in the space and the approaches they took to solve them.