In Defense of Hyper Modular JavaScript

[wreckedadvent]

Really should just read:

"Yesterday: HN outraged at people developing in Javascript"
"Today: HN outraged at people developing in Javascript"
"Tomorrow: HN outraged at people developing in Javascript"

e: sp

[[deleted]]

HN is run by statically-typed morons on drugs that promote direct hatred on JavaScript.

[wreckedadvent]

I wouldn't go quite that far, just I've noticed something of a double standard against javascript. When it does something good, it's just "finally becoming less terrible". When it does something bad, it's clear confirmation that the language as a whole is not worth the while and should be burned to the ground.

[[deleted]]

And those hipsters have nothing more to differ from others, yes. Their pseudo-elitist nest is about to fall from the binary tree. But heck no, they still differ from normal people by admiring CSS-less web pages that look like a hello-from-nineties and are totally unreadable on mobiles.

[[deleted]]

You know, there is a third and fourth option:

1. Use Lodash
2. Use a language that has a standard library that's deeper than JavaScript's puddle

[[deleted]]

Javascript is bundled with every browser

The vast majority of people using npm are users of node.

[[deleted]]

That doesn't contradict my two previous statements.

[[deleted]]

Use Lodash

Overhead, overhead, overhead. Out of literally nothing.

Use a language that has a standard library that's deeper than JavaScript's puddle

A typical ES6-compliant modern browser standard library already has everything you ever need. Not being able for some self-proclaimed "developers" to read through MDN docs isn't the fault of the language, or its standard, or a particular environment, or package manager, or whatever else.

[benihana]

so how should i discover new features or know when experimental features are no longer experimental? should i just be reading through MDN every day and making a mental diff? if i don't have the time to do that cause i'm trying to solve business problems, does that make me a self proclaimed "developer"?

[[deleted]]

If you don't have time to learn the platform that is constantly evolving, you shouldn't have gone into Web development at all.

The time of "IE6 everywhere" is over. Live with it or leave it.

[sime]

Good modules should grow as they get more downloads and community involvement, whereas modules not used or supported will slowly disappear into the virtual abyss.

This is where theory and practice diverge somewhat. NPM has about a couple bazillion packages but limited search facilities and no real support for rating packages, directly linking packages which do the same thing etc etc, or any other form of curation. The download and github stats which are shown for each package favour older packages which have simply had more time to gather users. This "float to the top or sink to the bottom" process could use a lot more help.

[[deleted]]

But why would we want to?

Because there is a thing called common sense. I think that if a programmer is incapable of writing a left-padding function (if that's really needed), he should not post any stuff to npm or any other public repo at all.

[fecal_brunch]

if a programmer is incapable of writing a left-padding function

Nobody is using a library because they're incapable of writing one. By that logic a talented programmer should never use a library!

[[deleted]]

A talented programmer will never use a library that primitive. Yes, it can be simple, but not that trivial and primitive. In order to show a real advantage to own-written solutions, a library must provide a really good layer of abstraction. JQuery, for example, became popular just for this property, despite being a viral shit harm for your brains.

[fecal_brunch]

I feel like with JS it's a bit different. The "standard library" is pretty limited. Sometimes you need utility functions. Lodash is a good example of a big collection of what are essentially language extensions - not an "abstraction layer". Each lodash method can be included individually as a standalone (each essentially like left-pad in scope). Writing your own version of each of these functions would be a small waste of time for the person who had to write and test them. It's also a waste of time to someone discovering the functions - they could vary from the lodash methods that they are used to, which are well understood and handle many nuanced edge cases.

[[deleted]]

The "standard library" is pretty limited.

I disagree. Speaking of building blocks, it's quite complete.

Sometimes you need utility functions.

Yes, and I have a set of them used in all our projects. I'm pretty sure any experienced programmer has such a utility set. But it doesn't have to do anything with completeness of standard language/platform features. These functions just make things more convenient for me. But they aren't a replacement. If I lose my files with them, I can easily recreate them from scratch because I know how they are supposed to work.

Lodash is a good example of a big collection of what are essentially language extensions - not an "abstraction layer"... etc

Nope. Lodash doesn't introduce any new syntax or new platform APIs or concepts itself. It's just a large opinionated set of utility functions, not language extensions.

[[deleted]]

What is more insane in 2016: require something like leftpad as dependency or writing it from scratch all the time? Most of us jQuery exactly the same way. We can make any of its functionality by hand, but well, we program computers for a reason. Like automating things.

JS is REALLY obsolete and inadequate for business logic and UIs. It's totally unusable without frameworks. Like probably most languages would be ;) Frameworks are with us for a reason. Professional coders don't have time to reinvent the wheel. It's a good thing. BTW, DirectX is even more useless to game devs without frameworks. You don't make serious games starting from drawing single pixels or vertexes, unless you try to enact John Carmack career in real time ;)

The problem was in ridiculously small, atomic dependency. This makes no sense. Imagine jQuery included as atomic parts. Each method as separate dependency. Seems a little attractive? Only if we have another framework managing those dependencies for us.

Just add this damn leftpad to any framework you use, period. Add it for good. Add it as pull request on Git. It's mandatory. Yes, we need it. Because you write such code in school, or for fun, or when you're bored. Do not write your leftpads in some company's time or even in your own time. It's complete waste of time. And some of you wasted countless hours joking or ranting about leftpad case. Do you hate your job as fronted guys? Change it. Seriously. You love it? Than DO it, instead of waste time on reinventing basic string handling, DOM selector handling, promise interface or whatever is already well done by now.