The abundance of JavaScript libraries | Hacker News Reader

The abundance of JavaScript libraries

joonaspajunen.com

61 pointsvelmu46 comments

Probably a controversial opinion to post here (not in that I think it is unique, but rather that I think there will be a divide in people who agree strongly and those who disagree strongly), but I view the JavaScript framework/library situation as a damning indictment of how terrible the language is. A constant churn of attempts to build a solid foundation upon a bed of leaky sand, each ultimately failing because no matter how well they were engineered you can't get past the whole sand problem... and maybe the whole sand problem will solve itself by other means, but only at a very geological rate due to all of the committee politics surrounding browsers these days.

IOW, JavaScript is going to be great next year. Just like it was going to have been each year for the past 10 years or so.

Completely agree, and I say this having written mostly JavaScript professionally for the last several years. It's sad to think of the millions of engineer-hours spent trying to make JS usable for today's applications.

IOW, JavaScript is going to be great next year. Just like it was going to have been each year for the past 10 years or so.

ES6 might actually be ok, in the sense of "about as good as Python 2.3".

>IOW, JavaScript is going to be great next year. Just like it was going to have been each year for the past 10 years or so.

Well, ES6 wasn't available "the past 10 years or so", whereas it will be next year, and recent 6-to-5 transpilers make it a backwards compatible option too.

>ES6 might actually be ok, in the sense of "about as good as Python 2.3".

Well, it's more ubiquitus that Python, more dynamic, more modern (if you include ES6 features), tied to a more powerful environment (the web), and beats the shit out of Python regarding execution speed.

> Well, it's more...

None of these things are features of the language itself (except arguably "more modern", whatever that means). They're all byproducts of the fact that JS is the only language that runs in a browser. JavaScript has basically succeeded dramatically in spite of itself by piggybacking on the runaway success of the web/browsers.

>They're all byproducts of the fact that JS is the only language that runs in a browser.

So? The end result is the same, Javascript has these attributes and Python doesn't.

I was under the impression that all dynamic languages were converging around a similar set of core principles.

  - builtin type literal
  - closures and fp idioms
  - generators
  - asynchrony
  - comprehensions

closures are a horrible anitpatterb imo. abritrary anonymous state potentially from anywhere in your application - how can that be a deairable goal.

It's simple anonymous encapsulation. I'm fond of FP idioms so I may be biased but most of the time I'd take closure based combinators over Objects.

Well said. In many ways picking a direction with JS is as bad as choosing an ORM... big upfront costs, a brief honeymoon, followed by eventual remorse, and finally more costs to transition to the next thing. Sometimes the smartest move is to avoid playing the game.

True. In JS land, someone is reinventing module management, object/class model, property bindings, event handling, async helpers, and FP helpers every day.

If they didn't many of the best libs wouldn't' exits today.

Can you define this leaky sand or is just bullshit?

There is definitely a lot of churn, but slowly but surely you are seeing certain functional programming approaches winning out.

And the language is progressing so much faster than similar dynamic languages like Python.

> the language is progressing so much faster than

Because it was a haphazard design.

A lot of the progress is just Javascript catching up to thoughtfully designed languages like Python. That's a good and necessary thing, but the fact remains.

Python ground to a halt around the time Python 3 was released and last time I looked it was still barely progressing. Meanwhile JavaScript has ES6, ES7, TypeScript, npm, Ramda.js.

It's long past 'catching up'. It's a healthy ecosystem.

> JavaScript has ES6, ES7, TypeScript, npm, Ramda.js. It's long past 'catching up'

Javascript is definitely making great progress, but npm thrown in as an example of how it's "long past catching up?" That's like, bare-minimum required functionality.

I'm not trying to attack, but when JS evangelists cite something like npm as a zap-pow feature, skeptics roll their eyes - especially when they've been using pip/rubygems/cpan for a decade or two.

Edit: I realize now you were probably citing npm more as evidence of JS having arrived with a healthy ecosystem (true) than as evidence it's leapfrogged others.

I think we see so much churn in JavaScript because we've forced the weight of the entire client side web onto the back of a single language. JavaScript must satiate the technical needs of all organizations across every consumer facing device and operating system. Like all languages, JavaScript has its weaknesses, so its not surprising that we find JavaScript to be a less than optimal solution for certain types of problems, but since JavaScript is generally the only option available for scripting logic in the browser, it's pretty natural that we see an explosion of libraries and frameworks to compensate for the fact that the JavaScript hammer is the only tool that exists in the client web universe.

That's what I've been wondering - why don't the browsers add a few more scripting languages, like python? If IE didn't exist, Chrome and Firefox could do it, just for fun, they're very open to new features.

These days I'd be far less surprised to see Microsoft and Google co-implement something with regards to new scripting language support than I would be to see Mozilla get involved.

Mozilla is basically cultish about JavaScript's place as the One True Web Language.

JavaScript libraries are a bit like office politics for front-end web developers -- basically something that feels like work and "advances your career", while in truth it's just a way to avoid doing the real work with actual customers.

> libraries are a bit like office politics for front-end web developers -- basically something that feels like work and "advances your career", while in truth it's just a way to avoid doing the real work with actual customers.

That's pretty scary, if true. That sounds very analogous to academic research and the "publish or perish" state of affairs in academia today.

Office politics often will advance your career in any sizable organization. That's why people engage in it. If publishing libraries is an extension of that, then we should be worried about the precedent that's setting for software development as a whole (because it'd be silly to assume that this remains siloed to front-end developers).

Capitalism is actually a pretty efficient antidote to that. The way it works is that as a field ossifies into one where everyone is focused on looking good rather than actually being good, the potential financial returns to defecting from the consensus social order and doing something different increase. At some point, someone's bound to say "The emperor has no clothes!", do something that people actually want, and make out like a bandit.

> Capitalism is actually a pretty efficient antidote to that.

Ehh I'm not really sure how that applies here, especially since the market of "javascript libraries" is probably about as free as you can get (in many senses of the word).

There isn't much going on in the way of financial return in that market, probably because people are seeing the benefit of implicit financial return (via the "office politicking" we're discussing here) and banking on that.

In which case, I'm not sure how capitalism will help.

It works on a level outside the JS library ecosystem: if people are judging potential new employees by their GitHub profiles, and that is resulting in people publishing all sorts of crap on GitHub to make themselves more employable, then eventually the reputational value of having published a JS library will go to zero (possibly even negative). Instead, employers will look for better indications of programmer quality, perhaps "Does anybody use your library?" Eventually some of the savvier programmers will realize that, they'll work on targeting real needs more deeply and really solving them well, and the huge mass of mediocre JS libraries will be replaced by a few good ones.

I still don't understand these "too many frameworks" articles. Is there some power out there that I don't know about that is forcing devs to use the latest framework?

We're still allowed to use what we want, no matter how new or old it is, right?

"Is there some power out there that I don't know about that is forcing devs to use the latest framework?"

Yes, It's called the Internet. People read articles about how X is the best. thing. evar. And this is perpetuated through many blog posts and, well, a lot of developers actually believe it.

If these JavaScript developers are so gullible to the newest thing it says more about them than the hype cycle.

It's not just that the language sucks in some ways but that the users of it possess so little engineering rigor that they complain about TOO MANY options.

It's no longer "if".

It has becoming a reality slowly...

Let me just put here a notation about the vast majority of JS programmers that are not complaining about all the libraries/options. And there are whiny, bitchy people using other languages, too. It's easy to generalize, so I understand the impulse.

You're right, I am unfairly generalizing. Not everyone thinks this way. But I read more of these articles regarding JS than any other language.

That's a good point, and it certainly lends credibility to your claim. It makes me wonder what causes this. My instinct is that JS attracts more people to it from things like design, where people seem to fawn over (seemingly trivial) things like the meaning of certain kinds of ovals. And so I think it would follow that this kind of mentality bleeds over into some aspects of JavaScript.

>Is there some power out there that I don't know about that is forcing devs to use the latest framework?

Yes. Not all forcing is of the "gun pointed at you" kind.

There's also: peer pressure, fads, media coverage, changing demands from employers, etc.

Demands from employers may be considered forcing. The rest, not even close.

That's an ideology, that thinks that people are all 100% responsible for everything they do, can judge everything consciously, and cannot be manipulated to do stuff by things like advertising or peer pressure.

Sociological studies have proven time and again that this is not the case -- including in people that think that that's impossible for themselves (sort of like the Dunning–Kruger effect).

manipulation is not force. if you have to redefine words to make your point correct then you didn't make a point.

also, if you're going to assert there are studies that make your conclusion somehow not an ideology, then the actual citations would be good. and they'll have to be fairly interesting to convince me. sociology is full of outright fraud, without even considering all the papers suffering from poor experimental design and rampant conclusion jumping.

So like everything else in life then? For instance I just saw a TV commercial that said that Miller Lite is the best beer, but my past experience knows that that is not the case. Surely we can recognize hype and advertisements when we see them.

The only valid excuse here is your employer, but in that case you should be able justify why using X is better than Y. If your non-technical manager insists that you use something that you don't want to because its hip you should be running away from that employer as quickly as possible.

>So like everything else in life then? For instance I just saw a TV commercial that said that Miller Lite is the best beer, but my past experience knows that that is not the case. Surely we can recognize hype and advertisements when we see them.

Not really. That's some conscious processing that you did, and that we can do -- but only to certain degree. When we go and buy stuff, the advertisments we've seen affect us, not just in what brand we'll buy, but in the very basic act of buying something over nothing, and how much we'll buy of a product.

It's a whole, much studied, field with tons of tunable parameters, from the psychology of a tv, to the height of stuff in Costo's shelves, the colors and smells inside a supermarket (and lots of stuff for web shops too), down to the $x.99 kind of pricing.

> We're still allowed to use what we want, no matter how new or old it is, right?

Yes, but that means you may be on your own to support it, which means extra up-front work as well as maintenance.

For example, keep in mind that Javascript has changed execution environments and was also originally built without the concept of simply importing other JS files. So over the years, we have had various incompatible ways of packaging and even importing modules[0]. Yes, the situation is improving, and ES6 and polyfills sort of fix this, but let me tell you, it is not fun to deal with old code that assumes a different execution environment and/or build process than the one you're using[1].

[0] e.g. https://stackoverflow.com/questions/16521471/relation-betwee...

[1] I really don't want to turn this into a debate on the best way to package or import Javascript projects today - just to point out that yes, there is a cost to using old code, regardless of how good it was at the time it was written.

Not that I disagree with your basic point, but I also see no reason to assume that using something new/trendy like React or Angular 2 will be any better a year or two from now. It has always been the case that building around a framework trades off quick initial development and having reasonable defaults for a lot of common tasks against often making more specialised tasks harder and the risk that within the lifetime of your project the framework you rely on will no longer be supported and developed as actively as it was when you first adopted it.

Sure. You're allowed to use what you want... if you don't work with/for anyone who's sure that The Way Good Developers Do Things Now is DependencyInjectAllTheThings.js or MVVMVVM.js or Reflux.js.

I mean, you're passionate about keeping your skills updated, right?

In Java or C++, there's a reasonable expectation that common popular libraries will keep getting updated for quite a while after you start using them... mindshare doesn't hemorrhage rapidly.

Not remotely true with JavaScript. Something which got 2k stars on gitub this year might be on the way out in a year, and you'll be stuck figuring out whether it still works with the new version of d3.js, or on the newest Chrome... and if it doesn't you have to either move on or fix it yourself.

Javascript developers need to make a transition like php and others have to module based apps, where you import just the libraries you need.

With things like require its not like it would be difficult to role your own framework like you can with php and composer (+all the symfony / laravel modules)

That's what using Browserify with CommonJS modules accomplishes, and has wide adoption. ES6 also specifies a module system, but it remains to be seen how that gets used or when it becomes the norm.

Yes and no. Libraries like jQuery and Underscore are often the basis of new frameworks and have been solid for a while now.

Like in other languages there's some wait and see to adoption. Going all in on a project that's been on GitHub a month no matter how many stars is foolish. JS devs have to make their decisions this way.

What I'm amazed by is not the amount of javascript libraries (the more the better IMO) but the amount of under utilized ones. There are tons of awesome JS libraries, experiments and basically web toys out there without a real home.

Couple of learnings got crystallized for me from reading the post:

1) Learn to focus on the actual ideas and patterns behind languages, libraries, methodologies & concepts, instead of implementations

2) Observe how libraries, languages, methodologies & concepts get adopted & perhaps later rejected

Given that browsers, Node, and JavaScript are all rapidly evolving, lots of churn in the library and framework space is what I'd expect to see happening, and I'd argue should happen. The problem is bigger than just the rate of churn. It's that at the same time there are lots of newcomers into the field and they don't have time to sit down and thoroughly learn the tech from the ground up. Instead, they're thrown into a JR development role and told to swim or sink. Many do swim and learn the tech in the process, but only by "weathering the storm" so to speak.

Reply on news.ycombinator.com