>hours complaining about the depressive current state of the web

That's pretty much most HN content about the web / front end development. I find HN al but useless for that topic now.

I've had this thought in the back of my head that a lot of content / comments are on HN are folks who do a little, not a lot, and are really annoyed that they have to do any front end development, so then we get rants about this and that... they're not fundamentally wrong, but as a web dev I find them a little skewed and completely useless / just negativity.

Like how many "I made this rando personal blog without a framework" and "there's too much javascript" (page includes lots of javascript) and etc that gets boiled down so far that it is pointless?

We're at the point a loading icon gets upvoted on HN to bitch about SPAs ... and I don't know about you but a hell of a lot of pages can sit at a loading icon that aren't SPAs. How disconnected is that?

Front end development discussion a land fertile for bike shedding and just about every topic can dip into it now, movies, music, all media really ... questions about who pays for the news, censorship, etc. Somehow it all gets pulled into the tech discussion as well.

Sometimes I just want to find a place to discuss it where we find neat things to do and less campaigning about every other topic.

There’s also is-even[1]. It has one dependency: is-odd

[1]: https://www.npmjs.com/package/is-even https://www.npmjs.com/package/is-even

183,453 weekly downloads — wth?

Now the only right thing to do would be for the maintainer of is-even to rewrite it to depend on is-odd.

That would be even odder.

This has to be a joke right?

isOdd and isEven pop up often but they and all those other packages were explicitly created for the sole purpose of boosting the author's profile.

https://news.ycombinator.com/item?id=29241943

too be honest, a comment of someone doesn't make it true. It could be he has actual use cases for these repositories. Just that someone thinks it should'nt be used like this, doesn't mean it's true.

It seems like a lot of people think they think how npm should work, while forgetting to see how npm actually works.

There's even an example of a well respected npm author that has repositories with just a few lines..

Y'all just love to hate on npm

The "joke" is that you can determime whether a number is odd or even with a modulo in half the code and a fraction of the storage space of a library. There is no use case for it because it's a built-in feature of the language, and in the age of inane web bloat, supply chain attacks and Javascript cargo-culting, I think laughing at stuff like this is perfectly warranted.

> you can determime whether a number is odd or even with a modulo

Or you could check the lowest bit. Better to abstract away from that implementation decision. ;)

That too, but I get the feeling those kinds of operations aren't in Javascript's standard library...

`my_number & 1 == 0` works.

JavaScript does have bitwise operators. Something I was surprised by was that numbers are stored as 64 bit while all of the bitwise operators operate on 32 but numbers. This means that every operation results in a number conversion first.

Not just 64 bit. 64 bit floating point. You can't just get the "low bit". You need to take the exponent into account to figure out which bit of the mantissa to grab. It's intrinsically more computationally difficult than is-odd on a real integer.

> It could be he has actual use cases for these repositories.

If that were true, it would be useful for the author to actually explain that in his repo documentation. As it is, concluding that this is a joke is by far the most reasonable response.

Yes, JavaScript is a joke for having such a barren standard library that the community has to do it for them.

Ok, which programming languages actually have an isOdd or an isEven function in their standard library?

Anyway, Javascript, like virtually every programming language, has "& 1".

Yes, the standard library is lacking and yes, that's a big issue, partly responsible for the huge mess that is NPM. No, it does not matter one bit here so this is off topic.

Gosh, never look at C. You'd break ribs.

That's what it looks like. This is one of the dependents on `is-odd`: https://www.npmjs.com/package/is-104 https://github.com/acappato/is-104/blob/main/index.js

I don't get the issue. You write a function to check if a number is odd. You seem to have this function in every project so you make a package for it so you, and others, can easily include it. This is exactly what npm is made for?

Testing whether a number is odd is done in 3 characters:

    n % 2

if you don't like the % you can also do it using a bitwise AND, this also handles negative numbers:

    n & 1

this is equal to 1 if the number is odd, 0 if it is even, and will be converted to true or false in a if statement. You don't need a library for this.

And you should not need a library to handle string conversions, you should be aware of the types you manipulates. If you do need to handle strings, that's still easy:

    Number(n) & 1

And Number(n) is a no op if n is already a number. But wait, no, actually, you don't even need this because % and & will auto cast the string to a number anyway. You can use parseInt(n) if there's a chance that your number is going to be non integer, but meh.

So n & 1 will cover everything.

All this is readable and idiomatic, there's no need to write a function for that, let alone a full fledged library with unit tests, package.json and all this crap that bloats the node_module folders of everybody.

isOdd = require('isOdd') and your entry in the dependencies of your package.json is going to be more verbose than isOdd = n => n & 1. Even "isOdd(n)" is longer than "n & 1". Nothing beats the "& 1".

If people are going to write libraries for all kind of similarly small and trivial things, soon we will need more than the Earth to handle our code.

Before reading your comment, I probably would have agreed with you that isOdd was overkill.

After reading your comment, I'm starting to think that isOdd is not only more readable but safer. I don't think I ever thought about n % 2 not handling negative numbers, and I'm not sure I would immediately recognize n & 1 as equivalent to isOdd. In languages without truthiness, n % 2 == 0 is longer than isOdd(n). Likewise, even with truthiness, n % 2 == 1 is longer than isEven(n).

I suspect that the real problem is the cost of adding dependencies, in terms of package size, performance, and security. All these problems could be solved using linking, inlining, and auditing.

But would you be sure that the implementation isOdd you are using is safe? To be sure you end up needing to try a few values, or to read the implementation, at which point you might as well write isOdd = n => n % 1.

That does not hold true for more complex stuff, but to test whether a number is odd, come on.

You'll test your code if it works anyway and if your odd test is wrong it will show.

But yes, you need to make sure on how '%' works in your programming language especially on negative numbers (and on non integers) because that can differ.

If you are testing whether a number is odd and that number can be negative, you'll probably think about it anyway.

That's a trap you should encounter once and then you are good.

You don't have to tell me how to calculate if a number is odd or even, that's not my point.

The thing is, n % 2, i need to do mental gymnastics do comprehend whats going on. Even if your function is just one line, I rather read isOdd or isEven instead of n % 1 of n % 2, remembering when 1 or 2 stand for even or odd is something I could have trouble with.

Telling you how to do it was not actually my point too, sorry if it sounded patronizing, that was not the intention. I was writing this for all the readers here, starting from the beginning for completeness' sake, at the risk of stating the obvious.

n % 2 or n & 1 is something you likely get used to if you encounter it frequently enough, and at least something you should recognize after the first time you encounter it. And most people should have encountered it at least once because that's one of the things we learn to do when learning programming (but I guess Ten Thousand [1] can apply). If you don't encounter it enough to be used to it, then the rare gymnastic should not be a big issue neither. You need to be able to recognize it because it's in the wild.

If having an isOdd or isEven function around makes the code more readable for you anyway it's fine, especially if the function can be inlined, but pulling an external dependency for this is overkill.

[1] https://xkcd.com/1053/

> if you encounter it frequently enough

That's a huge if!

So abstracting a one line in a function is actually good. Putting it up on npm is debatable.

those poor gymnasts do some truly impressive things, and then every little leap of basic thought is conflated with their work

well said :) sad but true

The issue is the idea of introducing an external dependency for a one line function that anyone with a rudimentary understanding of programming should be able to write in their sleep. The idea of sharing code isn't flawed here, but the risk / reward in these cases is very much out of whack.

The risk / reward of using npm is always there. It doesn't matter how big the package is. Any dependency is a risk? You're free to not use the dependency. Nobody is forcing you.

If someone wants a 1 line dependency, I say let them. I have zero issues with that.

Again, if you think something is not how it supposed to be, maybe YOUR view on what it supposed to do is whack instead?

How far do you take this: an `inc()` function? If we get to a stage where every piece of software in the world depends on one random person's ridiculous npm module, we'll be in a pretty precarious state.

First job title in 2007 was "web master". 15 years later and i feel more like a web dinosaur than a web master. sick of it all.

Computers are still exciting, the web is not. Now the web is just business, advertising and Javascript. It wears a suit, a fancy haircut and deck shoes. It looks like a crypto billionaire.

More like a web orchestrator these days, so maybe “web maestro”. ;)

It's funny, the package is-odd has dependencies itself. It depends on a package called `is-number`. Go figure.

I finally understand how `node_modules/` directories grow to 100s of megabytes for the smallest apps

Turtles all the way down.

It is a trade off.

In most other ecosystems such as Java, Python, PHP, etc if you have a dependency A that depends on B 1.0, and a dependency C that depends on B 2.0, you cannot have both of them installed, so you either pick one or the other, or some intermediate version which works in all cases, but many times you end up not being to use one of them or, worse, not able to upgrade either A or C because you cannot resolve all the dependencies anymore due to constraints.

In node you can do this, you can use both A and C even if they use their own, incompatible B versions. If both A and C depend on the same (or compatible) B version, then you only have one as in the other ecosystems. And you can always enforce and override what final version you want if necessary.

This, plus usually the inclusion of documentation, type definitions, source and transpiled code is why node_modules is usually pretty big.

But you don't ship node_modules "as is" to the browser (200MB node module does not mean a 200MB bundle). And usually this is not a problem for any modern laptop or server.

Is this better? Is this worse? Can't say, it is just a different tool with a different trade off.

But just "node modules 10Gb is bad" to me only tells the bad side of it, and usually comes from a lack of understanding of how this works and how it compares to other systems.

Anyone not committing the entire node_modules to their repo is in for a really bad time when npm goes down or gets compromised.

No, that's fixing the problem in the wrong way (by using your code version tool as an FTP more or less), complicating code reviews and unnecessarily growing your code repository.

If you want to be safe if NPM goes down, what you need is to keep an archive of built "binary" releases, either zip files, docker images, or whatever.

You can also have internal NPM proxies or caches too.

Committing external dependencies in the codebase is a terrible solution. And no, google doing it doesn't mean it is good for everyone else, probably more likely to be the opposite to what you need.

No one said committing to the code repo, deployment repos are a thing and if you're not revisioning your deployments then you are screwed anyway.

> No one said committing to the code repo

Yes, you did. Quoting: "...Anyone not committing the entire node_modules to their repo..."

> you're not revisioning your deployments

That's what I'm saying, quoting: "...If you want to be safe if NPM goes down, what you need is to keep an archive of built "binary" releases, either zip files, docker images, or whatever..."

Using Git/SVN/etc repository for this (which is what I kind of get from your responses) is just using the wrong tool.

> "You need to compile your assets" they say, just a cat *.css > site.css would do it.

The sassc CLI app is pretty good for this. It's a single binary, has a watch mode, and just compiles SASS to CSS. Although for a 404 page that probably is unnecessary (unless it's pulling in shared styles from somewhere else of course).

I for one have had enough and hopefully, in future projects, I can posit to just write basic HTML / CSS, maybe some JS, and not pull in everything else.

That said, I've been in the Go ecosystem for a while and while the language itself is fine, it's the associated mindset and catchy oneliners that have been more valuable to me as a developer.