Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On JavaScript's Weirdness

stack-auth.com

Post reply on HN
Print view View original

41–50 of 85 posts

Re: On JavaScript's Weirdness

#41

Post by smjburton »

mubou wrote: post #36
smjburton wrote: post #25

While interesting and possibly helpful to new coders, are these quirks of the language still relevant when most development in Javascript is done using a framework (React, Vue, etc) these days? How often do these "gotchas" factor into "modern" Javascript development, especially in production? These type of articles seem to critique mechanics of the language that don't come up as often in practice.

The issue with variables and loops that OP described is worse with React, since you create closure inside the render function for event handlers, and if that closure captures any state variables (rather than a getter function for example), then you'll end up referencing stale state. React relies on linters to protect against this, but that only goes so far and the API design makes it easy to screw up, so you have to…

That's a fair point. Adding that to the original post would help provide context about why some of these quirks are still relevant to consider even when using a framework. I believe the assumption is often that frameworks abstract the Javascript "weirdness" away.

Re: On JavaScript's Weirdness

#42

Post by masswerk »

skrebbel wrote: post #11

I'd like to understand why `document.all` is slower than `getElementById`. Couldn't any even somewhat decent optimizing compiler trivially compile the first to the latter? Like, I don't mean in weird cases like `const all = document.all; return all[v]`, or iterating over it, just the general one where someone directly does `document.all.foo` or `document.all[v]`, ie the 99.99% case. When faced with the choice to comp…

Regarding that choice: Given that this is really a different library (the DOM and its individual browser implementation), it's probably quite sane to just define a certain object to evaluate as falsy, as compared to any attempts to check for a certain implementation in this external library for any call.

(Even more so, since any access using `document.all` retrieves an object from a live collection, while the other access method is a function call, which is a totally different thing.)

Re: On JavaScript's Weirdness

#43

Post by brap »

I remember properly learning JS from “The Good Parts” book, which makes it known from the start that JS is a nasty language but if you ignore many sharp edges it can be nice and elegant. I think this is especially true with (a subset of) TS. All you need is a very, very strict linter, and then you get to pretend you’re working in a mostly solid language.

Re: On JavaScript's Weirdness

#44

Post by chuckadams »

pkkm wrote: post #38
chuckadams wrote: post #3

I've a few opinions on the content, but I'm most interested in which unicode analyzer tool generated that nifty text tree diagram. I can deal with JS's warts because the tooling is so much better. The other language I make my living with is PHP, and while it's much improved from before, the global function namespace is still a garbage fire, and you need extra linters like phpstan-safe-rule to force you to use sane wr…

Both JS and PHP are rather footgun-rich languages; have you tried Python, Java, Kotlin, or C#?

> have you tried Python, Java, Kotlin, or C#?

Yes, plenty of experience in the first two, but the last two are better contenders. At any rate I work primarily with TS when I do front-end code, it's very rare for me to write raw JS, so a lot of footguns automatically go away.

Re: On JavaScript's Weirdness

#46

Post by 0xbadcafebee »

I don't mind '0' == 0 when it's used for scripts and dumb stuff. That's literally how shellscript works, and I love shellscript, so I can't complain about that.

But I would never use shellscript to build an entire business's user interface with a giant shellscript framework. That would be insane. A language that was designed as a throwaway scripting thing for doing some miscellaneous tasks, and never designed for full application purposes? No sane person would use that for a business's core product.

Right?

Re: On JavaScript's Weirdness

#47

Post by sapiogram »

_old_dude_ wrote: post #40
sapiogram wrote: post #28

Earlier quoted context omitted.

I don't think it's fair to call Go and Javascript's behavior "implicit", they just always capture variables by reference. Rust variable capture is implicit though, but it can't cause the problems described in the article, since mutable references are required to be unique.

In JavaScript, a 'let' inside the initializer of a for loop is captured by value, all the others are captured by reference. I think it's fair to call that semantics "implicit".

No, that's a mistake in the article. The variable is still captured by reference, but `let` is causing it to be re-declared on every iteration of the loop, not mutated.

The following code prints 1, 2, 3. It wouldn't do that if the variable was captured by value.

    for (let i = 0; i  console.log(i));
        i++;
    }

Re: On JavaScript's Weirdness

#48

Post by fenomas »

nsonha wrote: post #15
larrik wrote: post #13

“JavaScript sucks because '0' == 0!” - literally everyone ever I never really understood the hate for this, given that everything is a string in HTTP, and that SQL does the same damn thing. There are far more annoying things about JS (both the language and the ecosystem).

The article didn't even mention it. If you actually read, it's more about things that are not necessarily too annoying from a programmer's pespective, but is very much for anyone working on the platform.

> The article didn't even mention it.

Literal first thing in the article - it's a block quote right under the title.

Re: On JavaScript's Weirdness

#49

Post by epmatsw »

nsonha wrote: post #16
chuckadams wrote: post #6

Earlier quoted context omitted.

Since I started using Prettier, I've moved permanently into the no-semicolons camp. Prettier catches ASI hazards and inserts semicolons where needed, and I've never seen it fail. Whichever camp you're in though, put it in your linter, don't leave it to chance. React code is full of array destructuring, that particular hazard is prone to bite you if you ignore it (tho it's still a little contrived if your usual style…

The rules are not that many, you can omit semicolons everywhere except 1. Before open square bracket 2. Before open parenthesis. That's it, those are the only 2 edge cases.

And yet, per the spec, new syntax features are allowed to break ASI:

> As new syntactic features are added to ECMAScript, additional grammar productions could be added that cause lines relying on automatic semicolon insertion preceding them to change grammar productions when parsed.

So really, the rules are “there are currently 2 exceptions and an infinite number allowed to be added at any time”. To me, that’s worth letting prettier auto-insert semicolons when I hit save.

Re: On JavaScript's Weirdness

#50

Post by Lerc »

_old_dude_ wrote: post #40
sapiogram wrote: post #28

Earlier quoted context omitted.

I don't think it's fair to call Go and Javascript's behavior "implicit", they just always capture variables by reference. Rust variable capture is implicit though, but it can't cause the problems described in the article, since mutable references are required to be unique.

In JavaScript, a 'let' inside the initializer of a for loop is captured by value, all the others are captured by reference. I think it's fair to call that semantics "implicit".

consider this

   for (let i=0;iconsole.log(i),30);
       i-=10
     }
Capture by value would print 10, 11, 12 that's the value when it was captured

Capture by reference would print 0,1,2

It's much easier to conceptualise it as

     for (const i=0;iconsole.log(i),30);
     }
which is fine because i never changes. It is a different i each time.

fancier example

    for (let x = 0, y = 0; y console.log("timeout",x,y),30);
        x-=10;
        y-=10;
    }
Post reply on HN