
Modern JavaScript tooling is too complicated? - praveenscience
https://changelog.com/jsparty/89
======
siempreb
Yes, but if only the tooling was too complicated, it would not be too bad.
IMAO the entire front-end JS world is one big pile of MISERY, complicated is
not the word or the problem at all.

Not 1 year you can write the same kind of code (professionally), every month
new libraries you have to use, always a new framework or cloud service on the
horizon, always a new hype in the making. And if all the new things in the JS
world would be great solutions it could be awesome (maybe). But the reality
learns that it only gets more complex and tiresome every day. Juggling with
design patterns, not because they are a better solution than the design
pattern you were using before, no, it's because some famous JS artist came up
with an 'idea' and the entire JS herd is following it blindly. Think you can
still write in the old fashion? Nope, PR declined! You protest? Beware of the
company politics, the herd always wins.

Oh btw, I guess the title is inappropriate, JS is deprecated, it's Typescript
now! Not sure for how long, but the jobs where you can write JS are
disappearing. So web developers are now forced to write in another language,
with all it's brand new issues and pain points. Nice! Did I have problems with
types in JS? Hardly, but that doesn't count, I now write about 20% more code
to get the same result and regularly spend a few hours to get a basic line of
code working because the TS compiler complains. It goes on and on, really,
unbelievable.. Web development took all the love I had for programming away..
And I acknowledge it is a great recipe for burn-out, if you fancy that.

I originally came from C++ and recently went back to it after 8 years of web
development. I totally unexpected rediscovered my joy for programming. I can
code things again that actually work and are understandable, without all those
black boxes of magic that are pure hell when something goes wrong. I gave up
on it, it's not for me.. But still, I can imagine when you're young you can
kind of enjoy the JS(TS) world with all those new and exiting things.

~~~
hliyan
Also originally from C++, now been working with the likes of React for about
five years. After grappling with Redux, React Router, Immutable, Typescript,
Flow Typing and a hundred other libraries, my solution was to go back to
basics: build applications with vanilla JS, using a bare minimum of libraries
and a lot of standard browser APIs. In my case, basically React only. How do I
do client-side routing? addEventListener('hashchange'). Type safety? Unit
tests. Mapping actions to components? onClick: dispatch(new
CustomEvent('foo')) etc.

Edit: Parcel for module bundling and transpile, but I'm waiting for JS native
modules. Eventually React too, will go away in favor of Web Components.

~~~
rhacker
That speaks a lot towards React - it's "the basics" now. It's basically
supplanting what Jquery was known for.

~~~
hliyan
I totally agree, but that it's "the basics" _now_.

I remember a time when jQuery was considered so standard that every
StackOverflow question about "How do I X in JS?" had as the top voted answer
"Use $X() in jQuery". All that accumulated knowledge is now essentially a
graveyard. I feel React too will be supplanted by something more closer to a
WHATWG standard in the future.

~~~
dclowd9901
But jQuery was just syntactic sugar on top of a broken API. For all intents
and purposes, React _fixes_ HTML and DOM. The reason we _have_ such complexity
in the front end these days is because _we can_. We've eschewed all the
bullshitty parts of web development (global styling, unpredictable browser
APIs, hand-holding DOM through complex interactions) and opened ourselves up
to actually writing applications.

The problem, as I see it, is front end developers are still expected to churn
out features like they used to in large scale organizations, but we've matured
as developers. It's no longer throw a .js file, a .css file and an .html file
at a browser and woo hoo you have a site. It requires more time and
bootstrapping, but the promise is code that breaks less often and is easier to
maintain. It also means we have front end developers that are now specialists
in different facets of frontend, such as builds, data layer, typing, feature
development and framework design. Notice these are meta jobs.

In order to meet the demands put upon us by our former velocity, we often have
to resign ourselves to blackbox libraries and such, which don't always
contribute positively to one's stack. Just today we ditched a node module we'd
been using because the owner refused to update it. We should be building more
internally than we do.

~~~
benbristow
Building your own frameworks and libraries is always a minefield. Too often
I’ve seen it done badly.

Unless you’re a big company best to use what’s already out there if you can
reasonably

------
electrotype
I use server side generated HTML pages with progressive enhancement using
JQuery (I prefere it to plain Javascript). Not complicated and works very
well.

Of course this is not popular/cool, though.

~~~
robertoandred
It's not complicated because you're not doing anything complicated with it.

~~~
csande17
In practice, a lot of complexity in front-end development comes because front-
end developers only solve problems by adding layers of abstraction, never
removing them.

Like, in vanilla JavaScript, you have a single global tree representing the
state (the DOM), and you write event handlers that manipulate that tree. But
that isn't a good fit for every use case, so you introduce React, which
encapsulates all your functionality into components.

But that turns out not to be a good fit for every use case, so you add a
state-management library like Redux on top. With Redux, you have a single
global tree representing your state (the Redux store), and you write actions
that manipulate it.

Congratulations, you are now back where you started, but you've introduced two
third-party library dependencies (probably more, if your libraries need
separate adapter libraries to work with one another) and a bunch of overhead
and complexity.

See also: client-side navigation. "Pages on my website load slowly because the
browser has to run all the JavaScript I wrote. How can I solve this? Oh I
know, even more JavaScript!"

~~~
igornadj
Are you proposing using the DOM for state management? (of data, not document
elements)?

~~~
Udik
Why not storing local state in the components themselves? Why do you need
global state management at all, except for the very rare cases in which many
totally unrelated components need to tap into the data?

~~~
krzepah
Because some complex application have multitude of variables that need to be
passed along various components and that's exactly what is doing redux. In
these cases it is much simpler to work with the tools that the community
built, and as soon as you actually understand how redux and connect work, you
are usually rather happy about what it does for you.

~~~
Udik
Yes. I think that some applications, with multitudes of variables that need to
be shared between unrelated components, will benefit from a store that manages
_only_ those variables.

For all the other cases, I don't see any reason to use one, and my experience
of the same application developed, by different people, with and without a
reactive store, tells me that the solutions without a store are generally much
simpler and look way more maintainable.

------
aphextron
Webpack is a _godsend_. Do you not remember Gulp?

Or....Gradle...?

Modern JS is a dream to work with. The days of pre-transpilation and
modularization with hundreds of script tags and giant IIFE's and worrying
about cross-browser was a total mess. It finally feels like the web has
matured as an application platform and I've been waiting for this day for a
long time.

~~~
Aeolun
I could understand what was going on before transpilation. There was just
Javascript, and while some functions might not exist in different browsers,
the core was the same.

Now I have to figure out the difference between: ‘umd’, ‘commonjs’, ‘esnext’,
‘es2015’, ‘es2018’, and a whole bunch more.

I don’t want to keep up with JS politics just to be able to develop with the
latest version.

~~~
commandlinefan
Just about the time Chrome and Firefox came out with working debuggers for
JavaScript, everybody rushed onto non-debuggable bandwagons, so we’re back to
the bad old days of using “alert” to debug...

------
tlrobinson
Blanket statements about "web development" are not reasonable to make because
there's such a wide variety of applications.

Is using TypeScript, Webpack, React, and 20 other external libraries "too
complicated" for a static marketing site? Probably. For a 200,000 LOC complex
productivity tool? Probably not.

~~~
barberousse
Seriously, it's just poor professional discretion. I work on a cross-browser
multimedia sequencer, no fucking way you're hand writing all necessary DOM
management code. You absolutely need React for that to prevent that kind of
shit show. This custom video player project the team got assigned? Probably
can write those on our own. To be fair though, framework and library marketing
tends to be fairly disinterested in talking about suitable and unsuitable
problem cases. I don't think that's completely intentional, but front-end
tends to have more engineers with non-CS and other untraditional software
education backgrounds in situations where they feel pressure to "get shit
done"

------
namelosw
A lot of people complaint about Webpack.

But most other languages only provides up to Grunt and Gulp equivalent, namely
Gradle, Fake etc.

As who had maintained large Gulp scripts, those Scripts would eventually
become a huge pile of non-standard and ad-hoc scripts.

Webpack is complicated, I admit. But it's much better than Gulp I my
experience, so why is everyone complaining?

It turns out the problem Webpack or JavaScript solves are more complex than
other language solves. JavaScript is the center of the Web, you cannot expect
let CSS bundling itself, so do images and fonts. Let alone compression,
prefixing, and giving fonts and stuff size thresholds to in-line them in
JavaScript.

There would definitely better tools in the future like Parcel and Pika are
trying but the problem doesn't go away.

I'm looking forward to see other languages facing the same issue in WASM age.

------
JMTQp8lwXL
JavaScript itself has a complicated, hairy history. It's hard to write a
single line of code without wondering, must I query
[https://caniuse.com](https://caniuse.com) to be sure this API is supported by
all of my organization's targeted browsers? It shouldn't be all that
surprising, that in order to rectify the lack of parity, we have to accept
come additional levels of complexity in our tooling.

Sure, I could import all of corejs and call it a day. Everything would be
polyfilled, but then I'd be wasting precious bytes and negatively impacting
page load times. Some will even say the concern is no more than bikeshedding.
But if you give little thought to bundle optimization, your carelessness will
add up, and materially impact TTFB. It's a death by a thousand cuts.

My personal answer is no. Whether it's Stockholm Syndrome or not, you can
conquer the complexities of shipping web applications written in modern
JavaScript.

Becoming aware of the nuances has made me a stronger developer. Developing a
deep understanding of polyfills, bundlers, transpilers, module formats (CJS,
SystemJS, UMD, ES Module) and which browsers support which APIs has made led
to me being more thoughtful in the code that I write. For people just looking
to solve a business problem, without understanding the more tedious parts of
JavaScript, it absolutely is too complicated for them. I empathize. But if you
want to be a skilled front-end software engineer, it's in your interest to
tackle these tools with some zeal.

~~~
xthestreams
> But if you want to be a skilled front-end software engineer, it's in your
> interest to tackle these tools with some zeal.

I guess what we are saying is that there must be a better, not yet invented
way to do frontend, without having to deal with this huge complexity that is
unique to this specific field.

~~~
JMTQp8lwXL
You can make it zero-config, polyfill everything, apply all babel plugins so
everything is transpiled to support IE 7, for all you care.

But everyone has different needs. So tools like Babel and Webpack allow you to
pick-and-choose what polyfills and transpilations are necessary.

------
vikingcaffiene
Seeing a lot of hate here for modern JS workflows. The truth is you can make a
mess no matter what ecosystem you buy into. I’ve encountered some absolute
trash fires of complexity in Java, PHP, C, and (yes) Javascript code bases.
They all suffered from the same problem: lack of communication and planning.
This is a framework agnostic problem IMHO.

~~~
hliyan
Different perspective: In Java, PHP and C (I've worked with each), comes very
close to "no assembly required" to get a simple project running: install,
write code, optionally compile and then run. In JS, unless you're doing
vanilla JS, you need to select and bolt together a lot of different third
party tooling first, or you have to use a boilerplate, of which there are many
versions to choose from.

~~~
mffnbs
I see you've never developed in Java if you think that comes 'no assembly
required".

~~~
gnusty_gnurc
definitely - having recently started working in Java it's far from "no
assembly required" for certain things but feels _much_ more sane the types of
problems I'd encounter in web/mobile dev land

------
libria
Is there transcript for the hearing impaired? Otherwise people are just going
to respond to the title.

~~~
tyingq
Not sure it would help as:

 _" it’s 1v1v1 with Mikeal reppin’ team Yep, Divya on team Nope, and Feross
sitting in the middle on team It Depends."_

That is, the transcript, if it existed, is just 3 people reacting to the
title.

~~~
maltenuhn
Thanks, you saved me 20 minutes :)

------
spankalee
I hope someone pointed out that it's legacy JavaScript that's too complicated.
Very modern JavaScript is quite a bit _less_ complicated.

~~~
moon2
IMO, there are two big problems with Javascript:

\- there are too many ways to do something: it's hard to understand patterns
(they change with every framework, for example), many different standards that
aren't compatible with each other.

\- javascript delays failure and fails silently: it makes software prone to
bugs as well and it also makes the language hard to debug.

NodeJS, npm, yarn, millions of frameworks and libs just add complexity to the
language.

~~~
bstar77
All of this can be addressed with best practices. Just enforcing lint rules
can mitigate the majority of your complaints. Flow and Typescript can take
that even further. Webpack will streamline your process.

My primary complaint would be that working in Javascript is absurdly difficult
for the beginner. It's ridiculously hard to understand the fundamentals when
they have been a moving target since the early 2000's.

~~~
reaperducer
_All of this can be addressed with best practices_

The problem is that "best practices" changes every day, and from one employer
or team to another.

~~~
eropple
I don't agree with this. Over the last few years I've watched the JS universe
coalesce largely around three points:

\- Structural, optional typing is good. Use it. TypeScript seems to have de
facto "won", but _just use something_ ; the very act of thinking about input
and output types tends towards better code and you always have the
flexibility, within your module boundaries, to go outside the type system if
need be.

\- Structured, functional-or-mostly-so view libraries make your system less
fragile. Use them. React, Vue, whatever. They discourage your developers from
making tag soup; this is a good enough reason. (Yes, there are some people on
the "vanilla JS" train, but there are reasons it's a minority group--it's
harder, you run the very real risk of making a worse thing, and there's less
out there to bail you out if you get yourself into a corner.)

\- Do the work up front: lint aggressively, format consistently, run coverage
tests, and so on. It's an investment in correct code, and get in the habit
early.

What you use matters less in putting into effect good practices. Why you use
it and what they do matter much more.

~~~
hoten
I'm afraid the "javascript sucks" meme has taken hold. The infection is
terminal now. At least, in the minds of most developers judging web
development from the outside.

~~~
eropple
I mean, from the outside I get it. For a _very_ long time I avoided frontend
jobs because JavaScript _did_ suck. And I'd say that JavaScript-as-it-was--not
writing ES6, not polyfilling browsers, not using a sane framework--sucks
today.

These days I write pretty exclusively NestJS serverside and React/React Native
on clients, using TypeScript through the whole stack and Swagger-generated
clients for plumbing, and it definitely no longer sucks. But I had to 1) have
a reason to get into it, and 2) spend a _ton_ of effort to weld together a
consistent environment that values developer time.

There probably _is_ too much nonsense going on at any one point in the
JavaScript ecosystem. I mostly work in infrastructure/devops roles, where it's
just expected that you know ten thousand little things that are arbitrary and
stupid but will eventually bite you; having to hold an entire stack in my head
and understand how to pivot and manipulate it is kind of what I do everyday,
but it's not a standard programmer skill. If you don't have somebody who can
do that--and it's a mixture of human communication and empathy, technical
skill, and a certain kind of technical taste, so it's not as common as one
might like--I still, today, see why somebody might say that JavaScript sucks.

------
Justsignedup
Honestly. I used to build the buildmaster for Ant builds back in the day. They
could actually be quite incredibly elegant (if you used Ant-contrib). The
reason was actually a lack of magic. SURE, ant was very verbose compared to
modern build systems, but it did a lot of things relatively straightforward.
You invoke tools in the chain you want.

Today it is very different. There is a huge chain of auto-wiring tools with
very cryptic error messages. To just build a basic ES6 javascript webpack
project with React I need over 800 libraries, many of which are automagically
invoked via convention.

I literally have no idea what my build does, and hope my lucky underwear
actually works today. Most of the time I am browsing through weird bug reports
trying random snippets on the internet because there's no sane way to debug
anything.

So the point is, explicit is a huge virtue. It is code you can trace and
debug. Sure it adds a bit of time, but it is time up front that saves A LOT
down stream. Meanwhile today's tools are built to save time up front and waste
time downstream. You either follow the exact formula the original developers
wanted or you're shit out of luck.

------
barberousse
Everything terrible about the front-end is a consequence of scale and demand
for warm bodies pumping out code that targets the world's largest networked
application runtime: upper- and middle-management everywhere exerting downward
pressure to ship for the cheapest rates facilitating code bootcamps, etc to
pump out more non-traditional CS educated labor, meaning less shared
generational communal knowledge that normally standardizes names for things
like patterns, etc. Devs are thus even more interchangeable and we see less
opportunity for mentoring, yet another means of transferring generational
knowledge (and software engineering is _not_ a science), and people regularly
leaving companies after 1 - 5 years. None of this really has anything to do
with the question of whether JS tooling is too complicated save for the
implication that professional _discretion_ has less and less reason to be
cultivated - grab a framework/library and glue it together to meet the
deadline that isn't a deadline but it's actually a deadline

------
cutler
Most young Javascript devs have no experience of hacking "DHTML" for Netscape
Navigator and sundry incompatible versions of IE back in the late 90s. That
was the real low point of front-end development. Nothing comes close to those
life-sapping days so enjoy the immense resources you have today, particularly
evergreen browsers following a standard.

~~~
timw4mail
And yet, with a little thought, we could use those hard-won compatible apis
more directly, and for the vast majority of websites, write less code,
configuration, etc.

But we still act as though the very basic DOM functionality is some arcane art
that has to be "fixed" by a library like jQuery, or as is more common now, an
entire stack of large tools.

Having done paid work with React-stack apps, and personal projects with
vanilla JS, I still see more advantage with less code on the vanilla side.

------
alex78
I agree that a lot of mainstream tooling and frameworks are too complicated.

But there are simple tools out there for building your typical business
applications. Stateful apps with NodeRun.com
([https://noderun.com/docs/concepts/stateful-
apps](https://noderun.com/docs/concepts/stateful-apps)) make development
similar to what VB used to be like back in the day (but for JavaScript). There
is a Visual drag-and-drop designer for the UI and inherent database
integration. I find that building normal database-driven apps is 10x easier
compared to rolling your own HTML, CSS, React, Angular, Express, etc.

------
zamadatix
No more than you choose to make it over complicated.

------
mbrodersen
The answer is simple: Don't use a tool if the benefit doesn't outweigh the
cost. Also, only use tools that are "market leaders" in their segment. So that
there will be plenty of fixes/tutorials/help available to get you over bumps
on the road.

------
pictur
Javascript libraries are good at creating problems other than problem solving.

