
JavaScript's ecosystem is heading into the wrong direction. Thoughts? - aligajani
The Javascript pendulum has swung from restrictive, monolithic frameworks to modular, boilerplate-hindered libraries.<p>I personally know many newbies who find it extremely hard to dive into the React&#x2F;Redux realm because there is a serious learning curve.<p>I think we need to strike a balance. Too much of an unopinionated ecosystem can do more harm than good. What are your thoughts?
======
niftich
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.

~~~
aligajani
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.

~~~
niftich
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.

~~~
aligajani
Valid point.

------
namuol
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](https://github.com/facebookincubator/create-react-app) 2\.
[https://github.com/mozilla/neo](https://github.com/mozilla/neo)

~~~
aligajani
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.

~~~
niftich
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.

~~~
aligajani
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...](https://gist.github.com/angus-c/feea4e4cd0b853dc04c71fa4e7d2f83f)

------
wwalser
> 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.

~~~
aligajani
Nice point about training!

------
cocktailpeanuts
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.

~~~
niftich
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.

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

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

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

