Today’s JavaScript, from an outsider’s perspective (2020) • Hacker News Board

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

#261

Post by trivialsoup » Fri, May 27, 2022, 2:33 PM UTC

lodovic wrote: post #173

Gigachad wrote: post #83

Earlier quoted context omitted.

I'm also sympathetic to the author but don't really see it as a problem. NPM modules are not apps on the App Store. They aren't intended to just be run by regular people quickly. The steps described in the article show someone hitting Node.js with a hammer until it gets closer to doing what they want without any understanding of what is going on. Which is fine, that's what people do often, but it isn't a failing of t…

Sure, but that is how it's sold: NodeJS and Javascript are marketed as super easy, perfect for beginners. They're not, in my opinion.

If you listen to marketers fast cars make you younger and handsomer and give you a full head of hair.

Don’t look at how things are sold, look at how they are. In this case it’s code, of course there’s complexity.

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

#262

Post by samsquire » Fri, May 27, 2022, 2:36 PM UTC

jiggawatts wrote: post #147

vaughandroid wrote: post #73

Earlier quoted context omitted.

You've obviously thought about this quite a bit... Do you have any ideas as to how projects could avoid this problem?

I have, but to be honest I've forgotten a lot of the specific debates and their finer points. I don't have a single, definitive, clear solution -- as pointed out by others -- nobody does. It's not a simple problem. That doesn't mean that steps can't be taken to improve the situation, perhaps dramatically in some cases. 1) Enforced MFA to publish a crate -- credential theft is semi-regularly seen as an attack vector.…

One of my thoughts (see my profile) is "library mesh". You could register your code (or the parts that integrate) as a reverse dependency on what you depend on and they should build your code as part of their build to see if anything breaks.

Refactoring breaks everything - just look at Python 2 to Python 3. Part of the problem is having a bill of materials and having accurate tracing of the ingredients of a build, such as reproducible builds. But the time investment in these is hard work.

Computers are good at cross referencing. If you indexed everything in a graph database. It should be a simple graph Search to find dependencies of a git commit hash, binary sha256 installer file. And a web of sha256 relationships. And mapping between them and commit shas. It would be useful for security too but also interested in things being robust and reliable. Like you say it's a monorepository but not one.

Tooling is what's needed

The python packaging experience and ruby bundler and npm and other version manager experiences simply leads to common breakage.

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

#263

Post by fendy3002 » Fri, May 27, 2022, 2:39 PM UTC

donatj wrote: post #256

gernb wrote: post #31

sounds like the same experience I have with pretty much every language I'm not used to. I just want to try this C++, download, unzip, oh it's windows so .project file. Fine, redo on windows , oh it's 3 versions of vstuido old and says it wants to upgrade , okay. Hmm errors. Try to fix. Now it's getting linking error. repeat the same with xcode and any project in c, c++, objc, swift okay how about ruby? oh I have old…

I have been writing JavaScript professionally for nearly 20 years. I try my damndest to keep up, but the fact of the matter is the ecosystem is garbage. It’s really not a not-knowing-the-language thing. It’s a legacy of years and years of incompatible tooling requiring even more tooling to work around nightmare scenario. Node modules not working in the browser without translation was the original sin that kicked the…

> Node modules not working in the browser without translation was the original sin that kicked the whole nightmare off

Uh what? It's literally the name itself "node"_modules, it's designed to be used with node. The fact that it use same language and can later be used by browser is another matter. Thankfully we can easily bundle the whole thing using webpack nowadays.

There are also countless boilerplate project with webpack setup already so you can get reference from there.

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

#264

Post by mhuffman » Fri, May 27, 2022, 2:41 PM UTC

Merad wrote: post #228

jquery_dev wrote: post #123

Earlier quoted context omitted.

I've started programming around 10 year ago without any Visual Basic code. There are so many more resources nowadays to get started programming, back in the day there was no way in hell you'd get something like repl.it where you don't even need to install anything. What stops you from creating the most simple html page and playing with CSS? That counts as programming to me, there's also scratch for people who are com…

Not to be an ass, but playing with css and html isn't programming. At all. It's making web pages. The web is so universal today that many people conflate "making web pages" and "programming". And there's nothing really wrong with that _if your goal is to learn to make web pages,_ but I'm pretty sure there are still more than a few people out there who want to solve problems with code, or just learn to code, with litt…

>Not to be an ass, but playing with css and html isn't programming. At all. It's making web pages.

... except you can literally make desktop and mobile applications now by "playing with css and html"! ^electron -- shudder!^

Part of the reason for the JS mess (which people have been bitching about for years and years) is how easy it is to dip your toes into. Match that with how easy it is to create a "gui" now with HTML and CSS, stir in an endless bunch of half-baked support libraries built by people that just learned JS last month and you get the perpetual hell of the JS ecosystem.

And now that it has been adopted by startups and traditional companies, it is here to stay for a while.

Half of my development time when dealing with a new JS project is un-fucking some JS dependency that I never wanted that lives deep in the bowels of npm_modules.

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

#265

Post by the__alchemist » Fri, May 27, 2022, 2:43 PM UTC

The examples in the article are all realistic, but I'd like to add something important: This is using the NPM ecosystem and JS dependencies.

A language's tooling and ecosystem are arguably part of the language itself for practical purposes. So, the article is a fair assessment. I'm making this distinction because you can use JS in what it accels at without invoking build tools and dependencies: As an imperative language making DOM manipulations without the IO-induced latency of querying a server and waiting for a response, JS gets the job done.

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

#266

Post by corrral » Fri, May 27, 2022, 2:43 PM UTC

chiefalchemist wrote: post #175

BlargMcLarg wrote: post #159

Earlier quoted context omitted.

I'd like to see more of this. It astounds me that software dev, historically seen as a field with and for "poor communicators", somehow believes its interviewers can do what top psychologists consider almost impossible to do. Same happens across almost every industry, but really, tech? "Cold hard logic" tech somehow became "yeah we can totally psychoanalyze someone in 30 minutes by talking"? Worse, the lack of struct…

Or perhaps the interviewers are under-experienced, under-perpared and/or under-trained? True story: I had an interview a couple of weeks ago. I was interviewed by two people who were younger than me, and relatively less experienced than me. My CV has a number of links to repos for various side projects and such. Best I could tell, neither of them looked, at least not more than a minute. Not a single "Your ____ repo l…

> Best I could tell, neither of them looked, at least not more than a minute.

I once interviewed a guy with a nice, short 1-pager résumé—not from lack of experience, just a solid, terse document. Not just out of school. Had three or four tech jobs in his history.

He listed one research paper near the bottom, that he'd co-authored in grad school.

I found the paper, skimmed it, and asked him about it in the interview (a lot of times in interviews I just ask candidates about stuff that it seems like they'd know about, that I don't know about, to satisfy my curiosity—I have no idea whether this is good or bad interviewing technique, but my intuition is having someone teach you about something you don't know, that they do, is probably at least as good as asking them to tell you stuff you already know) and he told me I was the only interviewer who'd ever brought it up at all.

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

#267

Post by krapp » Fri, May 27, 2022, 2:43 PM UTC

korijn wrote: post #202

krapp wrote: post #197

Earlier quoted context omitted.

>Is node.js giving the author bullshit or did they knowingly step into a field they are unfamiliar with, getting themselves involved with a package manager, a javascript runtime, a browser, and a local fileserver? Node.js is giving the author bullshit. They were not unfamiliar with the field. They knew what a package manager was, they already had NPM installed. They were familiar with the architecture of the web and…

Well, I disagree with everything you say (especially calling this gatekeeping). You simply are unwilling to learn about the tools you're working with. I'm sorry we couldn't work it out. Best of luck!

It isn't ignorance - the people who complain the loudest about the JS ecosystem are the people who use it the most.

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

#268

Post by [deleted] » Fri, May 27, 2022, 2:45 PM UTC

spaniard89277 wrote: post #155

alexb_ wrote: post #118

Earlier quoted context omitted.

Have you ever actually tried to do this? Programmers are extremely opinionated people. If you somehow manage to get past the barrier of "pretending to look smart so you can even ask a question without getting flamed to hell and back (hello, stackoverflow!)" you will be met with people suggesting different things, which quickly devolves into a giant argument about which thing is better and why this guy is so stupid fo…

I'm one of those learners and this is true to an extent. But there's fantastic people in r/learnprogramming for example. Even better than the Discord of the self-paced bootcamp I'm doing... But the complexity is real. I'm learning Django, which is supposedly easy, and it's a completely different beast than learning the in and outs of a language. And Django has good documentation, for some libraries it's a mess.

[deleted]

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

#269

Post by marpstar » Fri, May 27, 2022, 2:45 PM UTC

fendy3002 wrote: post #263

donatj wrote: post #256

Earlier quoted context omitted.

I have been writing JavaScript professionally for nearly 20 years. I try my damndest to keep up, but the fact of the matter is the ecosystem is garbage. It’s really not a not-knowing-the-language thing. It’s a legacy of years and years of incompatible tooling requiring even more tooling to work around nightmare scenario. Node modules not working in the browser without translation was the original sin that kicked the…

> Node modules not working in the browser without translation was the original sin that kicked the whole nightmare off Uh what? It's literally the name itself "node"_modules, it's designed to be used with node. The fact that it use same language and can later be used by browser is another matter. Thankfully we can easily bundle the whole thing using webpack nowadays. There are also countless boilerplate project with…

Not that I agree with the GP, but I think it’s easy to conflate “node”_modules with “modules from NPM”. Bower was once the recommended package manager for front-end assets, but NPM overtook it. I use Node daily, but 90% of my packages are front end.

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

#270

Post by donatj » Fri, May 27, 2022, 2:47 PM UTC

fendy3002 wrote: post #263

donatj wrote: post #256

Earlier quoted context omitted.

I have been writing JavaScript professionally for nearly 20 years. I try my damndest to keep up, but the fact of the matter is the ecosystem is garbage. It’s really not a not-knowing-the-language thing. It’s a legacy of years and years of incompatible tooling requiring even more tooling to work around nightmare scenario. Node modules not working in the browser without translation was the original sin that kicked the…

> Node modules not working in the browser without translation was the original sin that kicked the whole nightmare off Uh what? It's literally the name itself "node"_modules, it's designed to be used with node. The fact that it use same language and can later be used by browser is another matter. Thankfully we can easily bundle the whole thing using webpack nowadays. There are also countless boilerplate project with…

> It's literally the name itself "node"_modules, it's designed to be used with node.

That’s the problem. It’s not JavaScript. It’s not any part of the ECMA standard, it doesn’t work in runtimes other than node (read: the browser) yet it lives in the .js files making them not truly JavaScript. You have split the language.

The syntax isn’t part of the language and was designed in such a way that it cannot be polyfilled. This lead to a thousand packagers that would not be necessary at all if a sane syntax had been chosen. The creator of node himself has said making node incompatible with the browser was one of his biggest mistakes.

https://medium.com/@imior/10-things-i-regret-about-node-js-r...

> There are also countless boilerplate project with webpack setup already so you can get reference from there.

That’s literally the other problem! People just copying boilerplate without understanding it. That’s not a proper solution. That’s not a maintainable project, that’s copying other peoples homework and getting yourself in over your head.