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

A JavaScript Nightmare

blog.ignaciobrasca.com

Post reply on HN
Print view View original

91–100 of 101 posts

Re: A JavaScript Nightmare

#91

Post by [deleted] »

fendy3002 wrote: post #71
stana wrote: post #22

Earlier quoted context omitted.

Stuff that gets pulled in when you do 'npm install' is scary for a more traditional server-side developer. Python for example comes with a lot of built-in libs maintained by the core python team. These could get you pretty far before you start pulling in libs from random authors.

Except for lodash, axios and dayjs (moment), I found that I don't really need much more core functionality for backend development. And if you want reproducible dependencies, use npm ci not npm install, or use yarn. Best combined with replicated self hosted npm repository.

[deleted]

Re: A JavaScript Nightmare

#92

Post by warkanlock »

lxe wrote: post #27

Why didn't you check the logs as the first thing to understand what's happening -- a standard operational practice? And then to prevent this, you just lock the dependencies via a lockfile -- a well documented solution. This is just another amateur "javascript bad" post.

did you read the article in the first place? this didn't expose any exception and it just keep loading to eternity until timeout

Re: A JavaScript Nightmare

#93

Post by fendy3002 »

rezonant wrote: post #90
fendy3002 wrote: post #89

Earlier quoted context omitted.

Hmm weird, I remember it changed on the older version though, which is why npm ci is introduced.

Yes I think you are right when NPM first introduced it, which was in NPM 5 [1]. At that time package locks were new. Node 16 shipped with NPM 8, and by then this was not the behavior any more. I don't remember exactly when, but I believe it might've been in NPM 7 when this changed. Node 15 would have been the first release to ship with at least NPM 7 [2] EDIT: Node 16.0.0 shipped with NPM 7.8.0 https://github.com/nod…

Woah thanks for very detailed answer! So yeah it's an old behavior then.

Re: A JavaScript Nightmare

#94

Post by phanimahesh »

flimsypremise wrote: post #21

This was very funny to read because as someone who is actually familiar with these JS builds I immediately guessed that a dependency had changed. That's literally the first thing I'd check if an app is behaving differently in a remote environment than it is locally. I'd recommend the OP learn some JS best practices and apply them rather than complaining that JS isn't C.

I'm honestly split on this. It is obvious that they are not experienced with js ecosystem, but is it fair to frame it as they obviously haven't been burned enough by the ecosystem to internalise the common issues?

Dependency silent upgrades and dependency hell and bloat are not unique to javascript, but it feels like the js community has a perverse fetish for fragile build systems and dependencies.

Ofcourse, the community is not one organised entity and this is merely the result of multiple individual decisions taken independently, but still. I can not help but empathisewith the author despite seeing that they aren't locking deps, not doing reproducible and rollback-capable deployments via docker or artifact tarballs, don't seem to have robust ci, or good work life balance..

Is it elitist to remark "haha, don't you know you should smerp the blergh?" Is it not atleast somewhat crazy that we normalise rube-goldberg-esque contraptions?

I don't even know what I'm getting at, at this point honestly. Js gives me very mixed feelings. I love the accessibility amd universally available execution runtime (browser), and understand why it hassome of the warts it does, but it is also honestly a scary ecosystem with hyper fragile tooling. I've personally burnt multiple full days on webpack config tweaks and it all feels so unnecessary and pointless.

JS almost gives me existential crisis at times.

Re: A JavaScript Nightmare

#95

Post by MichaelRo »

warkanlock wrote: post #77
MichaelRo wrote: post #12

I didn't quite understand why they had to debug on the spot, thus working like 36 hours uninterrupted or so. A sane working environment would file a priority 0 bug and address it during working hours. I'm not throwing a rock but oftentimes this sort of heroic behavior is self-inflected. Also why is heroic debugging required on something that is not production? The article mentions it was a "quick demo". Then who give…

OP here; thanks for reading everyone! While I agree with everything you have said, and it's been my motto since I read, "I'm sure you're joking, Mr. Feynman." The point of the post was to point out (maybe I did it wrongly) that those things you have described are pretty impossible given the ecosystem we have nowadays in Javascript (as a whole!). Of course, you can try to theorize and try to get a hypothesis on things…

Well your reply still doesn't explain the administrative (not technical) reason why you had to spend some 36 hours uninterrupted hunting for this bug. Particularly since it was 'a demo' and what broke was 'PDF export', while other exports still worked. Hardly the end of the world if you ask me.

Technically though, I have hardly met this dependency update problem with C++ simply because dependencies are rarely if ever updated. Android on the other hand was a nightmare. I had colleagues quitting in a rage and swearing to never again touch Android in their life. Probably half the effort was spent fixing crap that was broken by updated dependencies. Luckily I'm back to C++ now and hope never again will I have to touch such a crazy system. The whole 'update for the sake of update' seems to be a grave problem of the Android / Kotlin / Javascript universe. The mentality is like 'bread won't be sliced anymore, eggs won't hatch, sun won't rise if we don't absolutely have the latest bleeding edge alpha version of all libraries'.

Re: A JavaScript Nightmare

#96

Post by lukevp »

phanimahesh wrote: post #94
flimsypremise wrote: post #21

This was very funny to read because as someone who is actually familiar with these JS builds I immediately guessed that a dependency had changed. That's literally the first thing I'd check if an app is behaving differently in a remote environment than it is locally. I'd recommend the OP learn some JS best practices and apply them rather than complaining that JS isn't C.

I'm honestly split on this. It is obvious that they are not experienced with js ecosystem, but is it fair to frame it as they obviously haven't been burned enough by the ecosystem to internalise the common issues? Dependency silent upgrades and dependency hell and bloat are not unique to javascript, but it feels like the js community has a perverse fetish for fragile build systems and dependencies. Ofcourse, the comm…

I think the problem is, JS is actually quite a minimal language as far as standard library is concerned. Node is a good runtime (as is deno), but imho, they really missed the boat on building a standard library and making it a real ecosystem. .NET, Java, and Python, arguably the top most used languages besides JS, have an insanely more extensive standard library than JS does.

Packages built by 3rd parties are the Wild West, and unless they’re a full-on company of dedicated, experienced engineers, they’re gonna break semver best practices. They’ll also design bad APIs for interacting with their packages sometimes, and there will be a total lack of consistency across the ecosystem, which is what we have currently.

If I had more free time, building a stdlib for JS would be high on the list of “help the world” activities.

Re: A JavaScript Nightmare

#97

Post by leptons »

jillesvangurp wrote: post #28
leptons wrote: post #17

> One tiny version mismatch or breaking change can bring your mission-critical application to a standstill, as we painfully experienced. This is true in many other languages, not just Javascript. This isn't a "Javascript nightmare", this is a dependency nightmare.

In a statically compiled language, when APIs change, you get compile errors that show up at build time. It's usually pretty obvious. With dynamically typed errors, you get weird run-time failures that can be well hidden until you trigger a use case that actually needs the bit that changed. That combined with poor test coverage means a lot of potential for things to slip through build and QA processes. I use Kotlin, b…

>With dynamically typed errors, you get weird run-time failures that can be well hidden until you trigger a use case that actually needs the bit that changed.

Maybe you've never heard of "writing tests"? If you update a dependency, and the dependency has a breaking change, your tests will fail. It's really that simple, and this should be the same in any language, not just Javascript.

Re: A JavaScript Nightmare

#98

Post by rezonant »

warkanlock wrote: post #77
MichaelRo wrote: post #12

I didn't quite understand why they had to debug on the spot, thus working like 36 hours uninterrupted or so. A sane working environment would file a priority 0 bug and address it during working hours. I'm not throwing a rock but oftentimes this sort of heroic behavior is self-inflected. Also why is heroic debugging required on something that is not production? The article mentions it was a "quick demo". Then who give…

OP here; thanks for reading everyone! While I agree with everything you have said, and it's been my motto since I read, "I'm sure you're joking, Mr. Feynman." The point of the post was to point out (maybe I did it wrongly) that those things you have described are pretty impossible given the ecosystem we have nowadays in Javascript (as a whole!). Of course, you can try to theorize and try to get a hypothesis on things…

> The point of the post was to point out (maybe I did it wrongly) that those things you have described are pretty impossible given the ecosystem we have nowadays in Javascript (as a whole!).

That's the thing, nothing you have asserted as impossible actually is as you'll see throughout this thread. I have been writing JavaScript/Typescript professionally since for about the same amount of time and I am not intimidated or challenged by my projects in the way you lament about.

That being said, if you've been at it 12 years and this is still your opinion, fair enough, try something else then.

Re: A JavaScript Nightmare

#99

Post by warkanlock »

rezonant wrote: post #98
warkanlock wrote: post #77

Earlier quoted context omitted.

OP here; thanks for reading everyone! While I agree with everything you have said, and it's been my motto since I read, "I'm sure you're joking, Mr. Feynman." The point of the post was to point out (maybe I did it wrongly) that those things you have described are pretty impossible given the ecosystem we have nowadays in Javascript (as a whole!). Of course, you can try to theorize and try to get a hypothesis on things…

> The point of the post was to point out (maybe I did it wrongly) that those things you have described are pretty impossible given the ecosystem we have nowadays in Javascript (as a whole!). That's the thing, nothing you have asserted as impossible actually is as you'll see throughout this thread. I have been writing JavaScript/Typescript professionally since for about the same amount of time and I am not intimidated…

You don't have a mechanism of trust in Javascript. Typescript up to this point is just sugar syntax. npm is a dumpsterfire (see npm everything package)

If you are not intimidated by the complexities of this Babel tower, it's up to you. For me, this was just a personal catharsis in my personal blog that I wrote mostly for me (and I didn't share it here)

I believe there's no point on discussing this with particularly you since you have been commenting all around trying to just confirm your view instead of just comprehend that this is not sustainable for new developers (try to follow the conversations on packaging, lol)

It's simply too much burden just to maintain someone else mess. We will pay a high bill in the future for all of this.

Re: A JavaScript Nightmare

#100

Post by MrJohz »

stana wrote: post #22
MrJohz wrote: post #18

This is the second time I've ended up reading this post, and I confess I still don't exactly understand what was going on here. There's an issue with PDFs missing their contents, but also timeouts and a missing method exception? The problem seems to have come from upgrading some dependencies at some point, but the solution is also an upgrade, as far as I can tell? And then the cache issues at the end sound very much…

Stuff that gets pulled in when you do 'npm install' is scary for a more traditional server-side developer. Python for example comes with a lot of built-in libs maintained by the core python team. These could get you pretty far before you start pulling in libs from random authors.

But that's exactly the sort of thing I'm talking about. We find scary what we're unfamiliar with.

To be clear, I agree that the Javascript ecosystem isn't perfect, particularly when it comes to supply chain issues. But in a lot of ways it's more secure than Python's typical dependency setup. By default, NPM uses a lock file, which enforces that specific versions of existing packages are used unless explicitly updated. This means that you always know which versions of which dependencies you're currently using, it allows you to upgrade different parts of your dependency tree independently, it ensures that when you remove a dependency, all of its transitive dependencies also get removed, and it allows for different dependencies for production and development environments, and for different portions of a given project.

Doing all - or even part - of that in Python is difficult. There's no built-in way, and so people tend to adopt third-party tools or roll their own scripts. The roll-your-own process, in my experience, almost inevitably leads to some sort of failure, usually a certain updating unexpectedly and breaking everything, and then not being able to roll back to a previous version of that dependency. The third party tools (Poetry, Pip-Tools, etc) work better, but are often difficult to integrate more widely into the Python ecosystem.

I don't want to make this about Python vs Javascript - both are tools that make different tradeoffs and can be valuable in different ways. The point here is that, as software developers, we often end up with what are essentially superstitions about other programming languages - we describe things we don't know or don't understand as "magical" or "scary", because that's easier than admitting we're just not that well informed. And while it's okay not to be informed about everything, in situations like this, it can lead to bad outcomes.

In the article, the author ends up blaming the situation on the magic and weirdness of Javascript, but it sounds like the issue had more to do with them not understanding how best to do package management in Javascript.

Post reply on HN