JavaScript Is Weird (jsisweird.com)

https://www.destroyallsoftware.com/talks/wat

There could definitely be improvements, but trash seems to be taking things too far.

I don't understand what this actually contributes to the discussion beyond it being a tired, beaten-down programming meme.

JS is a great programming language with a lot of quirks and footguns, most of them easily avoidable by enforcing good coding styles, using easily available and widespread tooling.

And most language have linters or compilers that issue coding-style related warnings, including C, so this is not specific to Javascript.

JavaScript has a bunch of quirks, but it's still great. In the StackOverflow survey, JS reliably ranks highly in the list of "most loved" languages. https://insights.stackoverflow.com/survey/2020#technology-mo...

Node.js is a thing because people liked JS so much that they wanted to use it on the server side. You may think they're all fools, but it's actually pretty nice. I like the latest version of Node better than working in Python (mostly because node_modules are better than virtualenvs, IMO.)

You can use TypeScript to address many of the quirks described in TFA, but you can also reliably avoid them just by never using == and always preferring ===, using String() before using + to concatenate, and using Number() before subtracting.

I basically never encounter situations like the ones depicted in TFA in real code, because I never try to add two arrays or subtract two strings or what have you.

> how can we make progress if things are not perceived as they are?

People aren't blind to JavaScript's failings. The evolution of JavaScript has been a mix of adding new features and fixing what they got wrong before, e.g. the way it has two different isNaN functions. [0]

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

It's odd, there are developers who make the language they work part of their identity and see attacks on that language as attacks on their identity.

I don't get it, but it is what it is. If you call javascript trash, you will offend people.

Basically, it was meant to be a dialect of Scheme, but with map and array data structures at the bottom, as opposed to lists (hello, Clojure!). Suddenly, the last-minute decision was made to add Java-like syntax and OOP to this language and rebrand it as 'JavaScript'. Brendan Eich did the best he could in the limited timeframe to implement this. Then in 2015 'design-by-committee' approach was accepted and horrible feature creep started. We can then investigate every feature and how it pushed individual company's agendas while compromising the integrity and vision of the language, but that's a typical design-by-committee story.

Ty for bringing it to attention. Indeed a cool feature to create emphasis and structure. Haven't bothered with it yet but will consider it. Another cool one is using console.groupCollapsed (as long as you are staying in a callback context).

First time i ever see a form behave like that oO

"What, are you going to check if the results are accurate? Go ahead "

But if you open it console while doing the test, it says:

"Hey, stop cheating! "

> Even if you're a JS developer, most of this syntax is probably, and hopefully, not something you use in your daily life.

So I think you should look at this site more as something fun you might not have known if you're an js developer than as criticism of js.

That being said, the !!"" isn't that weird of a syntax is it? I see and use the double exclamation mark all the time.

More accurately it's a binary problem. 0.1 and 0.3 have non-terminating representations in binary, so it's completely irrelevant whether you're using fixed or floating point.

Any number that can be represented as the sum of powers of 2 and 5 have a terminating decimal representation, whereas only numbers that can be represented as the sum of powers of 2 have a terminating representation in binary. The latter is clearly a subset of the former, so it seems obvious that we should be using decimal types by default in our programming languages.

Oh well.

[1, 2, 3] + [4, 5, 6] // -> "1,2,34,5,6"

[,,,].length // -> 3

https://stackoverflow.com/a/23465314

For me it’s only rows [[]], [0], [1], i.e. array-unfolding related, but all others are regular weak-typed comparisons like in perl and other dynamic semantics. <snip> Edit: just realized “if (array)” is okay, nevermind.

Carmack-like people utilising this stuff for good are few and far between, for your everyday joe programmer this is a footgun, a very-nonobvious and non-intuitive one (hence footgun moniker) that they write in crunch, it slips past reviews because reviewers are just joes with couple extra years, if at all, and then whrn things break after deployment, its an absolute pain to debug.

I mean:

    !!!true

https://dotnetfiddle.net/qTiq6U

That is the whole premise of the site, though. They even say that these examples aren't common syntax or patterns before you start.

> that's a floating point problem. Plenty of languages will have the same issue.

yes, many (most) other languages do have the same floating point issues, but that doesn't make them less weird. JS numbers are IEEE floating point numbers, therefore floating point issues/weirdness are also JS issues/weirdness :)

> Calling these things weird is fair enough but I can't help thinking this is code you'd never actually write outside of the context of a "Look how weird JS is!" post.

the verbatim code snippets in particular, yes, you're completely right. but the underlying problems that these snippets exemplify are still there on actual "real" running code. they just look less suspicious on the surface.

> Just be moderately careful about casting things from one data type to another and all these problems go away.

true. but still, these things can happen, and when they happen, they tend to sneakily manifest as weird UI bugs, like rendering "NaN" or "undefined" on the screen (we have all seen those... there's plenty of meme images about them too), instead of noisily breaking with an exception, which is way more noticeable and actionable for us programmers when doing introducing these bugs in the first place hehe.

it's true that they are not the most common kind of bugs, i'll give you that, but when they happen, they can be incredibly frustrating in my experience, because you may only realize after they have been affecting user for a looong time (maybe years), but you just didn't know because JS decided it was a good idea to carry on after one of these nonsense operations like adding an array to a number, giving you nonsense results instead of useful (runtime) type errors.

story time!

i remember an ugly case of this which involved some search filters on a big-ish system. the JS code was quite generic in how it handled filters, and looked fine. for some time, all filters were single-value, as simple strings, but at some point the system started handling multi-value filters, which were encoded as arrays of strings. well, the programmers who implemented the UI for multi-valued filters just tried sending array of strings as filters to the existing filtering system, and it seemed to work correctly in the results it yielded, so they assumed the code was prepared for that too (it looked generic enough), and so they shipped the feature that way.

it was only years later, when i was porting some of that code to typescript, that typescript complained about invalid type operations. i was converting between languages pretty willy-nilly and assuming the existing system worked correctly, so i suspected typescript was being dumb with that type error. but no, it was actually complaining about an actual bug. when passing arrays of strings as filters, the underlying filtering system was at some point coercing those arrays to strings by accident. so ['apples', 'oranges'] became 'apple,oranges'.

the search results were always right when the multi-valued filters had only one value (because ['apples'] coerced to string is 'apples') and kinda right in some naive cases of multi-valued filters (because of how the text search engine worked), which was probably why the original programmers thought it was working correctly and didn't give it much more though or more thorough testing. but the search results were definitely not correct in most non-naive cases of multi-valued filters.

so our users had been affected by this bug of multi-value search filters basically not working for years, and we only discovered it by accident when porting some of the JS code to typescript because typescript was kind enough to tell us about this nonsense operation statically, without having t...

If a user does need to do scientific computing, they could use a "# use-floating-point" pragma or something so that literals get interpreted as floating point. Otherwise, we map them to rationals.

Of course, doing rational arithmetic is much slower (for example, Gaussian elimination is exponential for arbitrary precision rationals, while it's famously O(n^3) for floating point), so there's a danger of people accidentally using it in triply nested loops etc., but I have a feeling that if you need to do that kind of thing you know that you might run into performance issues and you think twice.

We consider >70% passing.

In a language like Java you have objects and classes at the bottom of the language. How would you add maps to the language? Well, you create a Map class, implement put, get, has methods, etc.

Now imagine a language where you have functions and maps as your basic primitives, but you don't have classes and objects. How do you add objects and classes to the language? You can do something like this: objects are maps, information about their basic class is saved in 'prototype' property, constructor is a function that returns an object, etc. That's how JavaScript works. You can read about this in more details here https://exploringjs.com/impatient-js/ch_proto-chains-classes... , if you keep the basic idea in mind the details are easy to follow.

C, C++, Perl (oh, Perl!) allow you to do weird things, too, so do lots and lots of other languages.

A certain knowledge of this weirdness is very helpful, though, in avoiding it.

You can (and sometimes will) run into instances of this without noticing, because while you won't explicitly write

  true++

  x = someFunction()
  x++

Anyone who worked with a sufficiently large JS codebase ran into one of these cases and got unexpected results at some point due to this.

- you have to package your complete runtime in the Wasm binary, this leads to a large binary and memory footprint

- DOM manipulation requires calling Javascript code, and calling JS from WASM is costly

JS may be weird, but the kind of weird that works well enough and is rather easy to pickup and maintain with reasonable rules in place. When it comes to JS my empirical experience has often been: most of the time, the issue is situated somewhere between the keyboard and the chair.

But guys who control web standards resisted for decades to suggestions for other languages, though it was fine to have flash/activex for the same period of time, until Apple killed it for good. Even JS “2.0” (a theoretical better but incompatible version of itself) had no chance, because reasons.

Javascript is okayish generally, but its unusual parts come from the times when it was used as a glue between textual inputs and some~ data structures.

Stroustrups’ phrase is just a stockholm syndrome (in his case self-induced).

Edit: webassembly support is not really required to transpile anything to a browser, see asm.js

Javascript got popular because it was here first, so developers used it and became able to work with it. When this happens, javascript had inertia which is impossible to stop. Javascript allows one to deploy anything on any platform with a web browser, without copying files.

Webassembly is great, but it's not easy to build WASM files, the toolchain software used (compilers linkers etc) are not mature (only rust can build to WASM natively), and it requires that all language compile to wasm, so compiler developer need to implement a WASM compile "target", which takes time and is not always possible depending on language (python comes to mind, because of its large library, global interpreter lock, etc).

Also, WASM doesn't have access to the DOM or webGL, meaning that you still need to make JS calls to interact with a webpage.

Pure JavaScript is definitely a bit too loose for my liking, but I thought Swift went a bit too far in the other direction.

https://github.com/tc39/proposal-slice-notation

https://github.com/tc39/proposal-pattern-matching

The reason is that JS is dynamically typed and thus functions are free to return multiple result types. So you might run into one of these and get unexpected results because at some point in your code one of the functions returned an empty array instead of a number or a boolean, or divided by zero, or...

It's good to at least be aware of these edge cases so you can avoid them.

So you never did something like this:

  x = performCalculation(getParam1())
  y = performCalculation(getParam2())
  sum = x + y

  function f(x) {
    if (x >= 0) {
      return Math.sqrt(x)
    } else {
      return false
    }
  }

Sure, you won't explicitly write "true + false", but "f(x) + g(x)" is not uncommon and might indeed evaluate to "true + false".

  x = checkFoo()
  y = checkBar()
  z = checkBaz()
  if (1 === (x + y + z)) {
      ....
  }