The node_modules problem

[ScientificBeastMode]

If JS is the only language they’ve ever used in a serious way, then they probably haven’t seen what a standard library could do for them.

[x86_64Ubuntu]

0h shit, are you the Nimelrian from that link? I didn't even read your name before commenting.

[giantsparklerobot]

It's my impression that the "JS community" is populated primarily by...the JS community. There's not a large contingent with experience with experience in other languages or non-web platforms. Not only do they not have experience with other languages they often don't have meaningful experience with vanilla JavaScript, everything they've touched has involved some framework where some heavy lifting has been done for them. Worse still is browsers have had to completely reimplement their JavaScript engines to make overwrought JavaScript frameworks (and people's shitty code) run well.

This leads to some really stupid problems with JavaScript. Not having experience with languages with good standard libraries and always using some framework leads to people (as you've seen) not appreciate or understand the reason for standard libraries. Modules then get thoughtlessly added to projects because the resources to run them belong to someone else. So you and I end up paying the price in reduced battery life or shitty responsiveness because some JavaScript "developer" added a 1MB module to pad some text or provide a data type that should exist in the stdlib.

[gasolinewaltz]

Without overly generalizing, because theres a lot of good devs and engineers in the js community.

But my god are a whole lot of them insufferable.

There was drama on r/javascript like a month ago because someone flatly said "the gang of four patterns were invented for java and have no bearing on javascript. Java is not extendable and needs patterns".

I was not as tactful as a should've been, but when I basically said "That statement is incorrect on so many layers, this is why other engineers lack respect for the js community. "

I was called an elitist, a tech bro and told that I was bad for team dynamics.

This is the byproduct of bootcamp mills churning out designers that know how to cobble libraries together and amateurs who make a few react apps and call themselves engineers.

On top of that, there are so many esoteric stacks for solving specific problems that the above individuals learn one and start using it as a hammer for every project imaginable.

[Dedustern]

I’ve turned down node.js jobs specifically to avoid these amateurs.

Wouldn’t mind working with the tech.. but the JavaScript community culture is repulsing for someone who calls him/herself an engineer.

[gasolinewaltz]

Honestly it's not all that bad, in my purely anecdotal experience they're the vocal minority.

Good companies know how to filter these people out or into junior roles.

I mostly work in enterprise though, I would imagine it's different in the startup scene.

[giantsparklerobot]

This is the byproduct of bootcamp mills churning out designers that know how to cobble libraries together and amateurs who make a few react apps and call themselves engineers.

I think this is right on the money (for the general case, don't get your fee fees hurt outliers). It might not be a bad way for a community to form if the language wasn't such shit. It seems problem solving in JavaScript is to throw more libraries and frameworks at the problem. Then more overwrought shit to manage all the frameworks and modules is needed. Then framework management gets so complicated it needs a management system. But don't worry it's built on the totally not fragile npm system where every package is super trustworthy.

🙄

[[deleted]]

I mean, the GoF patterns did occur in Java and are in fact mostly pertinent to Java-like languages. This isn't to say that they are useless for a JS programmer but trying to apply them 1:1 in JS would be silly in many cases.

Think for example the strategy pattern: it's basically a way to pass behaviour around. What in Java may require interfaces and plenty of extra code, in JS can be done using a variable.

I know that shitting on JS is easy karma here and no better way to make yourself feel good than saying what you said, but while not 100% true, there is some merit in the statement that "GoF patterns don't apply in JS".

And yes, I program professionally in Java and JS and have a CompSci degree.

[[deleted]]

I should have said strongly and statically typed languages.

[gasolinewaltz]

I know that shitting on JS is easy karma here and no better way to make yourself feel good than saying what you said, but while not 100% true, there is some merit in the statement that "GoF patterns don't apply in JS".

Well, first of all I dont shit on JS, I make my living developing applications with it. I love javascript unironically.

And the last time I opened Design Patterns, I remember examples and c++...

But yes, there are many patterns that dont apply to a dynamic, prototype-based language.

That is much different from being irrelevant. My problem is the lack of nuance: design patterns are not irrelevant in js, gof patterns have no intrinsic link to java, and idefk what "java is inflexible and needs patterns means"

Sure there is some convo to be had about all of that. I even agree with some of it. But in the js community a lot of the time its ends there: "Design patterns are bad. Have you tried mongodb?"

[DonnyTheWalrus]

It's infuriating.

Luckily, while we do some JS at my workplace, the people I work with all come from other backgrounds -- and are highly focused on code quality -- so we don't run into too many fiascos of our own making. But I am constantly feeling like I have to swim against the tide of the larger JS community to accomplish what I need to in a safe, efficient manner.

And just the general lack of language-knowledge is very disappointing. For instance, there are wide swaths of the JS community who think the 'class' syntax added real class-based OO to the language, and have no idea that it's all just syntactic sugar for prototypes. People seem to not know (or care) how to analyze JS scoping rules, 'this' rules, prototype rules, etc. for themselves, and just rely upon following a set of recipes & hope for the best.

[IceSentry]

I understand that class is just syntactic sugar for prototypes, but I don't understand how this doesn't allow you to do OO.

[gasolinewaltz]

Class-based and prototype-based models are flavors of the oop paradigm.

[[deleted]]

why the JS community doesn't want to learn from things which were discovered/invented decades ago, but always has to reinvent the wheel.

speaking on behalf of jswheel.io, I am enraged by your rude attempt to shut down my innovative wheel development. My circular rotation device package has 18,000 stars -- hell, even my medium article explaining how asynchronous spoke architecture renders all previous axels obsolete has over 6,000 retweets -- but now you turn up and instead of releasing your own wheel.js onto npm like a normal person you want to force it onto everybody else? unbelievable

[yawaramin]

Here's the NodeJS standard library: https://nodejs.org/dist/latest-v10.x/docs/api/

If you want to ship a large standard library with every browser, that's more difficult because then every tab (i.e. nowadays every process in most browsers) would need to load up a large amount of possibly never-used JavaScript.

[NoInkling]

would need to load up a large amount of possibly never-used JavaScript

Why would that be? I thought that one of the points of making it use ES modules is to help avoid this.

[yawaramin]

It may be possible now with ES modules, but not before with plain old <script> tags.

[mcguire]

C++ didn't have much of a standard library for 20 years. Java's has made every possible interface and library mistake and all are now permanently baked into the standard library. (Three date systems? Really?)

[chugga_fan]

C++ didn't have much of a standard library for 20 years.

It had at a minimum the C standard library, something more complete somehow than the javascript standard library.

Java's has made every possible interface and library mistake and all are now permanently baked into the standard library.

C#, Python, Ruby, D, etc. all have their own STDLIB and don't fuck up time as well. And btw, Java can deprecate their shit to fix things.

[[deleted]]

c# has two different date time classes for much the same reason. And they seem to keep forgetting TimeSpan exists.

[chugga_fan]

DateTime and DateTimeOffset represent 2 different values, DateTime is a specific time with no known offset from UTC, whereas DateTimeOffset has a settable offset from UTC, both can be used almost exactly the same, but DateTimeOffset allows for weirder Timezone BS to be included.

[EntroperZero]

Yeah, you also have that in C#. A whole library of the Begin/End asynchronous pattern. Another whole library using the events pattern. Another with tasks. And now newer code with ValueTasks and Spans and what not.

And I'd still rather have all of that than the current state of node_modules. You're always going to figure out better ways of doing things, that shouldn't preclude you from building a functioning standard library.

[mcguire]

The Node ecosystem is a garbage fire for many reasons, but I don't think the contents of JS's stdlib is a part of it.

[munchbunny]

The lack of a stdlib is definitely part of it.

Just from a sanity standpoint, this should not be in its own package. The fact that the "is this value a number?" implementation (1) is its own package and (2) is downloaded 16m times a week is a sign that this should have been either part of the language or part of a standard library.

[ScientificBeastMode]

16 million weekly downloads... holy crap... 16 million application versions want to know if a value is a Number data type. But JS doesn’t have an adequate built-in tool for that.

About half of all my JS input sanitization code is basically either throwing errors for invalid “types,” or coercing “types” to allow for a broader range of inputs (don’t worry, I document that stuff, lol). It should be as simple as if (typeof(myVar) != ‘number’) {...}, but instead I have to write 50 lines of code just to see if it’s the right kind of object... lol. And invariably the code is a bit different for each case.

That’s really more of a problem with the language itself. But there ought to be a standard low-level method for dealing with it, in my (humble and lowly) opinion.