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

Ride down into JavaScript dependency hell

blog.appsignal.com

Post reply on HN
Print view View original

141–149 of 149 posts

Re: Ride down into JavaScript dependency hell

#141

Post by bostonvaulter2 »

awinter-py wrote: post #3

express (common web framework) seems to have only 51 deps in lockfile jekyll has 13 I don't disagree that lots of deps = supply chain risk But there have always been variations between projects & kinds of projects re how many deps they pull in. Try following someone's ipython data science tutorial, it's requirements.txt for days I think lack of a standard lib early on plus hipster functional culture made the '10s JS…

Express is a micro web framework, it is very small and not really usable on it's own (and it's not meant to be).

Re: Ride down into JavaScript dependency hell

#142

Post by jacobolus »

d_watt wrote: post #140
jacobolus wrote: post #134

Earlier quoted context omitted.

There is no way that any Javascript library function is "more optimized" than just using `n % 2`, which is also plenty descriptive. If this is very performance sensitive you can try using the somewhat more obscure (because many people have minimal experience with bitwise operators) `n & 1` instead. Given an integer input, thare are no "edge cases" to worry about here. If you expect floating point inputs, you need to…

It's funny, because in the case we're talking about, there appears to be edge case behavior if the number is a "safeInteger." While I agree in principle I would never import something as granular as "is-odd," just researching this specific package revealed an edge case someone ran into and solved, and you don't have to worry about as a dev if you take it off the shelf. https://github.com/jonschlinkert/is-odd/blob/mas…

Your "isodd" function should probably not be doing bounds checking and throwing an error when it encounters large even integers.

If you have a use case where you need to know if you multiplied two large integers and got a result larger than 2^53, then you should do it explicitly before you get to the point of checking if your number is even or odd.

Re: Ride down into JavaScript dependency hell

#144

Post by dmitrygr »

tmcw wrote: post #76

How to write a silly post about JavaScript dependencies: - Don't mention other languages, lest you reveal that most of them have similar dependency bloat problems. - Talk about devDependencies and dependencies without considering how they might be entirely different, say… one kind gets bundled, the other doesn't. - Always use npm, so you can highlight duplicates. Don't use yarn. - Adopt a narrow definition of 'depend…

> - Don't mention other languages, lest you reveal that most of them have similar dependency bloat problems.

no such problems in C, i promise you

Re: Ride down into JavaScript dependency hell

#145

Post by mschuetz »

filleduchaos wrote: post #131
mschuetz wrote: post #56

Earlier quoted context omitted.

Every separate package adds overhead and another maintainer that you've got to put your trust in. I'd rather have few packages of well trusted maintainers instead of a thousand packages from god knows who. Personally, I've made it a habit to not add anything that requires trivial one liner garbage packages, which amounts to not installing any dependency that uses anything from Jon Schlinkert (so no Webpack). Unfortun…

Have you considered using Rollup? I've personally found it delightful.

Already using rollup as a replacement for Webpack, but it seems to lag behind from time to time. Couldn't use certain new javascript features right away since it would throw an error.

Re: Ride down into JavaScript dependency hell

#146

Post by hn_throwaway_99 »

toyg wrote: post #135
hn_throwaway_99 wrote: post #38

Earlier quoted context omitted.

Java didn't have a decent date implementation until Java 8. > If somebody could just come up with a standard library for JavaScript that is really widely adopted I think the amount of packages can be cut back dramatically. As this article points out, I think that lodash is that for many people.

Java has had exact datetime implementations since what, 1.3? 1.2? Sometime in the ‘90s anyway. They weren’t fun to use but they worked fine, had the concept of multiple calendars etc... JS’s version of Date in comparison has always been a toy.

JS's version of Date is pretty much exactly the same as java.util.Date: just a thin veneer around a long representing ms since the epoch. Yes, Java has had Calendar and DateFormat for years, but the API is generally recognized as being pretty horrible (how many bugs were caused by Date and SimpleDateFormat not being thread-safe?)

So the Java community coalesced around Joda time, not unlike how the JS community coalesced around moment.js. The big difference is that yes, Java eventually rolled these lessons learned into the java.time API, but now you're effectively stuck with 2 standards, Joda and java.time. Not sure if that's much of an improvement.

Re: Ride down into JavaScript dependency hell

#147

Post by jessaustin »

parhamn wrote: post #136
jessaustin wrote: post #80

Earlier quoted context omitted.

It seems like a weird thing about React, or maybe how you're using it, that this is a problem. Most packages, and the language itself, handle multiple simultaneous versions of dependencies without issue. If packages are doing the old-fashioned "stick a property on window" thing instead of just getting required or imported browserify-style, they can step on each others' toes (and it's totally possible that React is du…

That’s not really relevant, right? No mater the loading/transpiration step, you lose a lot of language guarantees when you can load multiple of the same packages, including: - function/object identity checking I.e “package.func !== package.func” in many cases places. - module level singletons and registry (e.g createContext useContext) - single initialization - others I can’t think of That’s not typical and I was sur…

Loading multiple versions of the same package is just something that you can do in javascript. As complained about many other times ITT, any big node tool does this as a matter of course. Over on the browser, react isn't my favorite, but I'll admit that all that complexity serves some purpose. Maybe it would be nice if it were just a bit more complex so that global contexts could be backwards-compatible, but I guess it's not. Still, if you hire developers, they should be able to handle this sort of thing.

Re: Ride down into JavaScript dependency hell

#148

Post by stepbeek »

williamdclt wrote: post #54
tluyben2 wrote: post #42

I cannot understand how people work with this. I work with many different technologies and try to avoid JS, but some times I have to. The past weeks I have worked on a React Native project that was written by someone else; what a horror show. I mean it wasn't the worst code by the previous guy but even in a few months a lot is simply broken and not 'best practice' anymore. Compared to most other environments I work w…

I don't agree with you on this. The JS (or NPM) way makes it a pain to audit a project due to thousands of dependencies, but it's far easier to "have everything working". `npm i && npm start` is as good as it gets in terms of "getting started" friction (with version locking): python is worse, ruby is worse, PHP is worse, Java is worse. React-Native has more moving pieces indeed, but it's not really JS's (or NPM's) fa…

All our JVM projects use gradle. We run `gradle build` and it resolves all dependencies and runs all tests. I don't understand the claim that node has the least getting started friction.

Re: Ride down into JavaScript dependency hell

#149

Post by stepbeek »

mythrwy wrote: post #118
bob1029 wrote: post #97

Sometimes I feel like I am becoming increasingly out-of-touch with reality with how far this NPM/JS ecosystem nonsense has been taken. Is anyone still using this crap for de novo business applications that have real-world consequences? I have no problem if you want to build fantastical, sprawling node implementations for fun and potentially personal profit, but when your decisions start to involve other professionals…

Full page POST reloads on each data submission aren't going to fly with most users, even business users. Neither is reloading a page to get new data. My personal feeling about CRUD is this, you don't have to get fully on the crazy train and spend all your time with packages and build tools to achieve a nice product. Yarn is better for me. Very sparing package use. And a little light Vue with server side templating. N…

Fwiw I've found turbolinks gives me enough of an SPA feel that POST reloads aren't a huge problem. If we need a very dynamic experience then Vue would-be my go to tool,but for the other 90% this is fine.
Post reply on HN