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

71–80 of 101 posts

Re: A JavaScript Nightmare

#71

Post by fendy3002 »

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.

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.

Re: A JavaScript Nightmare

#72

Post by grujicd »

rezonant wrote: post #68
grujicd wrote: post #56

Earlier quoted context omitted.

Granted, I'm a novice in TS/JS world after decades in strongly typed environments so it's possible that I'm doing something wrong. I'm not talking about npm, I experienced these issues in my own code. It's mostly related to ts transpilers. They're fast, they're used in build systems which should be latest and greatest (e.g. Vite), but they're not robust, they don't always catch type changes in dependent files. And no…

Sounds like you are talking about frontend development. In that case you are trading off speed for accuracy. Some dev server tooling has this issue. Most systems built on Vite though do check across files, so likely that's just a bug in the build system you were using. A bug that is likely fixed. One thing you can be assured of is that when you actually build your app (hopefully using CI), it will find those problems…

Yes it's for the frontend, but it's not really related to hot reload thing. Is there a way to really compile tsx? I couldn't find any, tsc doesn't support it so you have to use some of the transpilers, and they don't perform full type check across files. So there's no way to perform real "full build" when tsx files are used, even if you don't care about build duration. If there is, I would love to hear about it.

Re: A JavaScript Nightmare

#73

Post by fendy3002 »

rezonant wrote: post #64
zaSmilingIdiot wrote: post #15

Earlier quoted context omitted.

I agree with this. But dont just use `npm ci`on prod builds since that would typically include all the dev dependencies as well in your production builds, which is not usually desirable. It might be possible to add the `--only=production` flag to npm ci? But otherwise, as pointed out, pinned versions are needed for all dependencies.

"npm ci" omits dev dependencies by default. However, "npm install" also adheres to your package-lock.json, and does not update things on you. npm ci is just npm install with a few tweaks that make it better to use for CI and builds, see here: https://docs.npmjs.com/cli/v8/commands/npm-ci

Last time I know during node 16, npm install updates your package-lock.json, but for patch version number (unsure about minor version) only and if the package.json is using relative version number. Definitely use npm ci or yarn if you want to adhere to lock files.

Re: A JavaScript Nightmare

#74

Post by atoav »

number6 wrote: post #70
atoav wrote: post #45

Earlier quoted context omitted.

Jup, and if your employer doesn't stop you or even expects such behavior that is called a bad work culture. Sure, I would also do long programming sessions on my own things every now and then, but those happen because I am in the flow and it feels like more work to come back into it the other day. But those are my own projects. I don't owe this to my employer. If they want that they could offer me double my current s…

How would the employer know?

In my case my superior comes by in my office or sees I made a commit and tells me I should stop working (I tend to forget to look at the time if I am in a flow).

But I also live in Europe and my superiors want me to come in with a fresh mind, instead of burning myself for things that should be normal work.

Re: A JavaScript Nightmare

#75

Post by fendy3002 »

wiseowise wrote: post #40
PUSH_AX wrote: post #32

Earlier quoted context omitted.

This was a runtime issue in a third party lib, so no.

If the library used TypeScript, it wouldn’t have the issue. The point still stands.

What I get on the issue is that library a using library b which is different version. In this case yes it will solve the issue during tsc or build, only if skipLibCheck flag is turned off.

Re: A JavaScript Nightmare

#76

Post by fendy3002 »

rezonant wrote: post #39
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.

Agreed, when they popped out this "such and such isn't a function" I lost the thread. You would know about that before you even started if you just read some logs. Unless they don't have logs, in which case a choice of language isn't going to solve their problems.

Or not handling uncaughtException or unhandledPromiseRejection, which may be common mistakes.

Re: A JavaScript Nightmare

#77

Post by warkanlock »

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 and then try to prove those, but it's just too hard to keep track of everything.

In addition, we are using lock files and good practices but it's just too much to handle for our small team (small startup) so we will plan to migrate onto a more stable platform.

It's really funny the heated arguments this post generated but I have been using Javascript for 12 years to these days, still this looks as a nightmare to me.

Tsdoing has a good video trying to install React from scratch, that's exactly how I felt during this debugging process

Another random story from this week: we have been using `nanoid` to generate IDs internally for an internal tool. Apparently, they did a breaking change release, and now you cannot use it anymore on commonJS env. See my point? where's the hypothesis we can make? It's hours and hours spent tinkering with code and other people's dependencies, and if, as you said, put a theory that theory won't match if you think how real systems work (the networking section on the blog post)

Re: A JavaScript Nightmare

#78

Post by rezonant »

fendy3002 wrote: post #73
rezonant wrote: post #64

Earlier quoted context omitted.

"npm ci" omits dev dependencies by default. However, "npm install" also adheres to your package-lock.json, and does not update things on you. npm ci is just npm install with a few tweaks that make it better to use for CI and builds, see here: https://docs.npmjs.com/cli/v8/commands/npm-ci

Last time I know during node 16, npm install updates your package-lock.json, but for patch version number (unsure about minor version) only and if the package.json is using relative version number. Definitely use npm ci or yarn if you want to adhere to lock files.

> if the package.json is using relative version number

What do you mean by this? You can specify dependency versions using "^" which means "I accept new minor and patch versions" or "~" which says "I accept new patch versions", or a bare version to say I want an exact version; but none of those have anything to do with a bare "npm install" command. They are relevant when you install a new package, with "npm install ". That is a totally different operation, and it absolutely can update versions when needed.

However, when you just do "npm install" it does not update your package-lock.json to the latest version that matches your semver requirements in package.json. That will only happen if you install a new package that needs it or you use `npm update` or some other command.

This is easy to test but it's also intuitively correct- you don't expect to run `npm install` and have an uncommitted change to `package-lock.json` appear, and that does not happen in normal usage.

It is kind of unfortunate that "npm install" and "npm install " use the same verb of "install" for two different things- other package managers don't make this mistake and it avoids the sort of misconception we're running into here.

Re: A JavaScript Nightmare

#79

Post by [deleted] »

grujicd wrote: post #72
rezonant wrote: post #68

Earlier quoted context omitted.

Sounds like you are talking about frontend development. In that case you are trading off speed for accuracy. Some dev server tooling has this issue. Most systems built on Vite though do check across files, so likely that's just a bug in the build system you were using. A bug that is likely fixed. One thing you can be assured of is that when you actually build your app (hopefully using CI), it will find those problems…

Yes it's for the frontend, but it's not really related to hot reload thing. Is there a way to really compile tsx? I couldn't find any, tsc doesn't support it so you have to use some of the transpilers, and they don't perform full type check across files. So there's no way to perform real "full build" when tsx files are used, even if you don't care about build duration. If there is, I would love to hear about it.

[deleted]

Re: A JavaScript Nightmare

#80

Post by jillesvangurp »

rezonant wrote: post #69
jillesvangurp wrote: post #66

Earlier quoted context omitted.

That's why I use kotlin-js. It's like typescript with the training wheels removed. I always joke that typescript is a bit of a gateway drug for web developers that know javascript to actually get into other languages. Kotlin-js is a bit of a niche thing of course and soon going to be obsoleted by Kotlin's wasm compiler. But kotlin-js actually works very nicely. Just like typescript, it's a transpiler. Unlike typescri…

Fun, all the power to ya on that. I've done a bunch of Kotlin for Android and although I initially didn't like a lot of how it does syntax, it has grown on me a lot. It is definitely a language that is focused on correctness and convenience. That being said, there isn't too much about Kotlin I miss when I write Typescript in strict mode. > Unlike typescript, it does not really have a non strict mode (except for the d…

Strictness should not be optional. A lot of typescript projects don't use all the features. I've been on projects where people were just working around those features to do all the crazy hacks javascript is famous for; or to be able to use libraries that use those hacks. It's a constant fight to push back that madness. With Kotlin, that's just much less of a concern. Having a language that just says no to all of that is valuable. IMHO typescript could just remove the option to turn off the strict mode and always be strict. It would be a better language. It's impractical of course because a lot of stuff would break. That's the problem with it. Don't get me wrong, I've actually used typescript and don't mind it. But I prefer kotlin.

I do indeed do a lot in Kotlin-js rather than using javascript libraries. We make a few exceptions for libraries like map-libre for which we have a very thin hand crafted Kotlin facade. Things like react we simply don't use at all (we use a pure kotlin framework called fritz2). We actually use a lot of Kotlin multi platform libraries as well. And even some wasm libraries (e.g. sqlite). Most of the foreign code dependencies in our codebase are not javascript libaries.

Post reply on HN