JavaScript's ecosystem is heading into the wrong direction. Thoughts? | Hacker News Reader

JavaScript's ecosystem is heading into the wrong direction. Thoughts?

5 pointsaligajani17 comments

The Javascript pendulum has swung from restrictive, monolithic frameworks to modular, boilerplate-hindered libraries.

I personally know many newbies who find it extremely hard to dive into the React/Redux realm because there is a serious learning curve.

I think we need to strike a balance. Too much of an unopinionated ecosystem can do more harm than good. What are your thoughts?

View on HN

Javascript for a while was full of MVC/MVVM frameworks, and React came along and only gave you the V and some basic hooks, expecting you to supply the rest yourself. This worked well for some specialized use-cases, but you couldn't replace Angular/Backbone/Ember with it, which is what people also want.

Speaking as someone who started off as being dismissive of 'enterprisey' programming but later went on to write a lot of Java, problem domains are actually fairly complex, and a framework is designed to restrict the things you have to think about so you can get work done.

When you chain minimalistic libraries together, you have to do all the work yourself; and some newbies are put off by this. On the other hand, it makes most quickstarts really simple, so I think it hits both ways.

I think having a choice of high-quality libraries is nice; some are backed by big corporations unlikely to disappear overnight; some are hobbyist projects crafted by a loving community. I believe React+Redux is a good thing, causing people to think about all the complexity that goes into MVU, MVC, MVVM and is generally hidden beneath a monolithic framework.

That's the problem. Most 'people', such as budding developers, do not want to wire-up the internal components. They don't want to think about the complexity.

Independently discovering that you need 'foo' when you start off dismissive of 'foo' is a great way to learn. And in many ways, is natural. Applications evolve in complexity, just as our understanding of them does.

Until you need a tool that your current toolchest doesn't offer, you're fine, and likely benefited from having simple, easy-to-understand tools. Switching to a different toolchest will not be trivial, but it alters which problems are easy, and which are hard.

I understand what you're getting at, but there is real architectural choices right now that didn't exist in 2012. It's true that React enjoys good mindshare and attracts new talent based on name-recognition alone, but there already is a next wave of alternatives to React (like Vue, Mithril, Aurelia) that are borne out of lessons learned from React and Angular/Backbone/Ember. If someone discovers that React doesn't in fact meet their needs, there's others to turn to, organically.

Valid point.

Configuration boilerplate isn't always so necessary. For those who want to have their cake and eat it, too:

1. https://github.com/facebookincubator/create-react-app 2. https://github.com/mozilla/neo

Sweet tooling. But I mean the ideas behind this whole new ecosystem, like the reactive paradigm. Multiple tools for transpilation, Babel/Buble etc. Just adds a layer of confusion.

The transpilation thing is actually an entirely separate concern from your original post. It's a subpar solution to an unfortunate situation that people want to use the latest version of the language, but not all target platforms run it yet.

For lack of a better term, treat ES.Next like a compiled language, and Babel as your compiler. It's the status quo until the platforms we run code in catch up to natively executing the code JS devs want to write.

I know, I just didn't mean to deviate away from my original post. By the way, I use Buble with Webpack. Buble has a cleaner output than Babel. https://gist.github.com/angus-c/feea4e4cd0b853dc04c71fa4e7d2...

Care to suggest a better solution?

What do you mean?

> I personally know many newbies who find it extremely hard to dive into the React/Redux realm because there is a serious learning curve.

As opposed to… classical OO frameworks where it's easy to dive in and build something that no one in the can maintain six months later? The failing in this this scenario is actually exactly the same as in javascript's unopinionated tools:

Training.

I wouldn't expect a new developer to be adequately prepared to contribute effectively to any system and in some cases I wouldn't expect an experienced developer to contribute effectively to a complex system that they are new to. So what do we do? We standardize training. A walk through the code base that every new developer partakes in upon joining the team. Required reading, a document detailing the architecture of the system with pointers to files which implement the pieces which are critical to understand and code reviews.

Another critical part of training, or perhaps just learning how to get around the world in general, is that at some point you have make a call and use what's right for you. Here's the kicker: this decision that so many want someone else to make for them, the down sides of making that decision poorly aren't that bad. Don't want to spend time forming your own opinions about how to go about using otherwise unopinionated tools? There are opinionated tools for you! Ember and Angular are both great frameworks. If they happen to be wrong for your application will the project just flat out fail? No, of course not. It'll get done. You'll bend the rules(which are only opinions) in a few places and get what you want in the end.

I'm a React user myself but my experience has given me the understanding and empathy to know that it's not for everyone. I wouldn't recommend it to someone who is truly new to JS or software engineering in general. I'd hand them something that would guide them up the ladder.

Nice point about training!

If you want to know what the future of Javascript looks like, look at the present of Java.

It's a monster language with maximum bureaucracy, but it's not going anywhere, since most large companies already have legacy systems built with Java.

But I also am not a fan of this direction just like you. My personal thought is, JS will never lose its dominance just like Java, and it will grow and grow until it becomes a monster like the Java ecosystem, and it will become shittier and shittier.

But that is only until something disruptive comes along that will decimate the influence of the desktop web browsing experience as we know it.

It's worth noting that WASM will (eventually) enable other languages to run in the 'browser VM' and this loss of JS' monopoly (whether as a source language or a compilation target) will cause some of the pace of innovation to shift away from JS and onto WASM.

Right now, the ecosystem has a lot of churn for exactly three reasons:

- browser vendors keep adding 'web platform' APIs that are only callable through JS

- new spins on paradigms are popping up on how to structure single-page applications

- the JS language itself is getting new features after being stagnant for years

When any one of these quiets down, the churn will slow.

Why should an ecosystem be judged exclusively on how well it caters to newbies?

If an ecosystem is approachable to more people, it could increase the likelihood of innovation in the industry.

Does that outweigh other considerations, like how well the ecosystem helps professionals get work done and/or maintain projects?

Reply on news.ycombinator.com