Live data from Hacker News

Today’s JavaScript, from an outsider’s perspective (2020)

lea.verou.me

21–30 of 391 posts

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#21

I can feel the author, in particular about the mess that is node_modules resolutions (and the fact that it sounds like 99% of "tutorials" - or even package READMEs - about Node seem to be written by someone that didn't really think things through). Anyway: I think the underlying problem is that it has been hidden that Node is NOT JavaScript. It uses (some) of the JavaScript syntax, but it doesn't use its standard lib…

I think the reason it's worth it (to the extent that it is) is not that it's good for novices, it's that it can leverage V8 and libuv.

If your claim is "you're on the backend, you have saner options" then I would agree, but this isn't really about beginners.

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#22

All he had to do was run `node index.mjs` or `npm run start` to have his index recognized as a module. Node DOES not read package.json, npm (node package manager) does. Node is not the package manager, so of course changes to package.json won't affect running `node index.js` However, node recognizes the file extension mjs as a module and will execute it as such. So renaming the extension of the script would work. Alt…

It only makes sense because you understand the decisions behind it. Try teaching JS to someone with little experience — they don’t care that the browser wants one kind of module and Node wants another. They don’t know what a module is, they just want their code to run

[deleted]

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#23
post #7

All he had to do was run `node index.mjs` or `npm run start` to have his index recognized as a module. Node DOES not read package.json, npm (node package manager) does. Node is not the package manager, so of course changes to package.json won't affect running `node index.js` However, node recognizes the file extension mjs as a module and will execute it as such. So renaming the extension of the script would work. Alt…

Can't tell if you're being sarcastic or needlessly abrasive. Anyway, it doesn't really matter how supposedly intuitive something is if the actual experience of using it results in the pain expressed by the author's friend. It's called usability because it's about the user. FWIW I've been writing JS for 12+ years and I resonate a lot with the post. Taking random error strings and plugging them into google often takes…

I have been across the block, from x86 asm to front-end and back-end JS stacks 20 miles high with preprocessors and dependencies. I haven't ever always done JS. I've dabbled in everything, so that hiatus you talk of, I've taken it many times over. I know the hell well that you speak of when learning some new vertically stacked artifact like the JS ecosystem.

But I have no sympathy here because of the fundamental lack of cursory research or attempts done to grok what the node command does, versus the npm command. Jumping right in is a fine method but it doesn't call for complaints or a blog post. One should have an implicit understanding that jumping in without preparing, means a lot of stupid mistakes are going to be had.

Get used to going from first principles would be my advice. Elon Musk did a lot by following that maxim. The same technique cuts through all the ecosystem bullshit when you stop letting the confounding and confusion depress and unravel oneself.

"Perhaps I could best describe my experience of doing mathematics in terms of entering a dark mansion. You go into the first room and it's dark, completely dark. You stumble around, bumping into the furniture. Gradually, you learn where each piece of furniture is. And finally, after six months or so, you find the light switch and turn it on. Suddenly, it's all illuminated and you can see exactly where you were. Then you enter the next dark room..." Andrew John Wiles

Dealing with these ecosystems is very similar to that. But all the dark rooms are similar to each other in spirit of shadows and highlights - so the more dark rooms one acclimates to, the less the future ones cause complaining, stress, or vitriol.

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#24

Earlier quoted context omitted.

It only makes sense because you understand the decisions behind it. Try teaching JS to someone with little experience — they don’t care that the browser wants one kind of module and Node wants another. They don’t know what a module is, they just want their code to run

The article is making the whole thing sound arcane and unreasonable when the distinction between package managers and runtimes has been the case for decades. Expecting package.json (a package manager file) to alter the behavior of node (the executable runtime) shows a lack of even first principle knowledge of computer languages, runtimes, or package managers. I don't feel bad in the slightest, because math feels like…

> shows a lack of even first principle knowledge of computer languages, runtimes, or package managers.

it's more that the author has the expectation that a computer scientist (well versed in computer science) should be able to immediately discern the intricacies of software construction and engineering.

The complexities of a software system is distinct and different from that of computer science. It's like saying that a physicist would be able to do the job of a construction civil engineer, because they know the physical theories of forces.

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#25

Earlier quoted context omitted.

> This isn't rocket science and honestly makes perfect sense. it only makes sense if you understand all the differences between ES modules and node modules that exists purely for historical reasons. Node modules are not part of ES specification at first place.

The module stuff is a different story and that's its own rabbit hole. I don't think its the crux of the blog post or even my comment. The purported issue was that changing the package.json type to module didn't fix things. That expectation is beyond amateur and I don't think there's really anything to complain about if one expects to bootstrap into a new programming language with package management, without understan…

Well, they expected it because it's what node told them to do.

from the article:

John runs node index.js

Node:

Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#28

I always go into these things hoping the outsider will be an Amish farmer or professional welder, but it always turns out to be just another programmer.

in what scenario an amish farmer, a professional welder, or, well, anything but a programmer, would know anything about this "javascript" thing?

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#29

Module resolution is quite a mess in JS at the moment. With the steady move to ESM, hopefully things will get better soon. In this transition period, it's painful. Even for those that deal with JS everyday, most don't actually understand the intricacies of CommonJS & ESM.

That's funny, every time I think that I should invest a bit of time to actually learn JS, someone comes along and says "a mess in JS at the moment". I can hack something to a working state but I never feel I have a full grasp of what's happening... But I grew up on assembler 35+ years ago so all this magic is unnatural. :-)

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#30
post #15

Module resolution is quite a mess in JS at the moment. With the steady move to ESM, hopefully things will get better soon. In this transition period, it's painful. Even for those that deal with JS everyday, most don't actually understand the intricacies of CommonJS & ESM.

I use JS/TS every day. I tried to understand the intricacies in module/import issues. Just reading about it gave me a headache, and tempted me to just rewrite my entire project in Rust. I'm still tempted some days. It's beyond painful. It's infuriating.

It is not going to convince you that ESM modules are well designed... but this post explain a lot of the intricacies

https://jakearchibald.com/2021/export-default-thing-vs-thing...

Post reply on HN