Hacker News Reader

Comment by georgemcbay | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

Reply on news.ycombinator.com