
Modern JavaScript Explained for Dinosaurs - pavel_lishin
https://medium.com/the-node-js-collection/modern-javascript-explained-for-dinosaurs-f695e9747b70
======
wwweston
> The bad thing was that it was annoying to find and download new versions of
> libraries every time they would update.

This goes back to one of the key complaints about front-end culture, though.
Exactly how often should this be a problem? Seems to me that actual library
code should be stable and updates would be on an infrequent basis.

One general response is "well, this is what happens when you don't have a
solid/broad standard library," and that's one of the complaints about JS that
kindof sticks for me, but if that were what this was all about, I might expect
to see a handful of standard libraries pop up over time and stabilize instead
of a fine-grained and deep transience-ridden dependency tree that requires a
package manager...

~~~
chickenfries
> I might expect to see a handful of standard libraries pop up over time and
> stabilize

What makes you think this hasn't happened? jQuery and underscore/lodash are
some examples of libraries that have a lot of traction. Why is JS having
package management seen as a downside? It's an upside in every other language
community, but for some reason we should try to avoid using one in JavaScript?

~~~
wwweston
underscore is a good counterpoint. jQuery is a great library, but I think it's
arguably not what people mean when they talk about standard libraries, which
has more to do with the question of why in the world there's a leftpad
package.

> Why is JS having package management seen as a downside? It's an upside in
> every other language community

FWIW I'd say that thinking of package management as an _unqualified_ upside in
any language or environment is a mistake, though getting deep into that
argument is not on my to-do list for the day, as convincing anybody who isn't
naturally amenable to it would probably require going over the groundwork
involved in groking JWZ's famous quote about regular expressions ("Some
people, when confronted with a problem, think 'I know, I'll use regular
expressions.' Now they have two problems.") and some philosophy about
automation and the attention economy.

But package management is convenient for sure, and there's any number of
situations in which I use it and am happy about it, particularly when I'm
installing things where I'm primarily a user rather than a developer. The
specific complaint about JS is based on the observation that the dependency
tree seems to be fine-grained and transient in what seems like an unusual way
to me. In that situation, I suspect the problems that come with any other pm
system are likely magnified, including developer dependency on it, which moves
from convenience towards necessity.

------
_pdp_
I've been a huge fan of JavaScript since 2005. My roots are in Fortran,
Pascal, C/C++, ASM, later Perl and Python and Java. JS is by far is the most
convenient language I've ever worked with and thanks to BabelJS it is even
better.

Yes JS is not perfect and it has a fair dose of inconsistencies but 99% of the
time it just feels right and it works well. Also thanks to NPM the community
is alive and healthy, surpassing the success of Perl's CPAN and Ruby's Gems
and Java's Maven and what not.

If you haven't tried JS yet, you should!

EDIT:

P.S. I talked to HD Moore back in the days during the Metasploit rewrite why
Ruby was chosen for the next iteration of Metasploit. The reason was that Ruby
was so much closer to Perl then JS and I don't think Node was around. I wish I
tried harder to make my case as it would have been a huge asset now.

~~~
BrandoElFollito
My roots are the same as yours (except Java). I am not a professional
developer, but rather code to simplify my work, so some projects or write as a
hobby.

I like JS but one of the things which are horrendous is debugging. Pycharm
allows me to debug Python code in a simple, intuitive way.

I still need to find a setup in JS where I can debug the same way (there is
always something which does not work, between the IDE and Chrome and
DevTools). This is really the ONE thing which is pushing me away from that
otherwise nice language.

~~~
cjoy
It seems a bit unfair to blame the language for the added complexity that is
introduced when debugging a browser script. Pycharm (or any of the JetBrains
IDEs with JS support) offer a very comparable debugging experience for server
side Javascript.

~~~
BrandoElFollito
Not being a professional, I tend to see a language through holistic glasses :
the ease and versatility, the libraries, IDE support, debugging, etc.

I was mostly referring to front end JS, where I sometimes managé to debug in
my IDE and sometimes not (and I then need to have DevTools open).

------
ourmandave
_The goal of this article is to provide a historical context of how JavaScript
tools have evolved to what they are today in 2017._

...

 _We went from plain HTML and JS to using a package manager to automatically
download 3rd party packages, a module bundler to create a single script file,
a transpiler to use future JavaScript features, and a task runner to automate
different parts of the build process._

 _Definitely a lot of moving pieces here, especially for beginners._

 _Modern JavaScript can definitely be frustrating to work with as it continues
to change and evolve at a rapid pace._

 _But even though it may seem at times like re-inventing the wheel,..._

------
Animats
All this build and packaging machinery makes sense if you're building
something like a CAD system or a virtual world viewer that runs in the
browser. But for the typical web site? It just runs up load times.

~~~
mercer
While I think that many websites don't need much JS in the first place, you
pretty easily hit a degree of complexity where a package manager is very
useful. And the whole build thing is in part precisely to keep load times
down.

(That said, I'm a front-end dev who is leaning more and more towards good old
back-end rendering and something like TurboLinks perhaps, for many situations
where previously I'd automatically go for React or Vue.)

------
krapp
Preface: I am a dinosaur. I know I'm a dinosaur, with a tiny dinosaur brain.

But I couldn't help but wonder as I read this whether much of the complexity
of the JS ecosystem isn't a consequence of the fact that whatever Node.js uses
isn't _really_ javascript. It's apparently a fork of javascript that has
includes and is intended to run natively.

Now, modern javascript packages _for the web_ also use includes because it's
part of NPM and the Node ecosystem. And as a result, there _has_ to be a
transpiling/build step to convert "Node" javascript to "frontend" javascript,
or some other language to frontend javascript.

But, to me, includes shouldn't be part of the "code", because they aren't
really part of the language - that should be separated to the packaging
directives and handled entirely by the package manager. Javascript package
management meant for the web would just pull in javascript, maybe minify it,
and dump it into a file. No need for transpiling, building or webpacking.

Although I suppose you _could_ if you wanted to, but that should be the
exception, not the norm. But, no. We have to have a million packages written
in pseudo-js or typescript or coffeescript with a single function each and a
separate test suite and build step for each.

I appreciate that the modern JS ecosystem works, and works well for many
people, but... I still feel like it doesn't _need_ to be as complicated as it
is. It could be much, much simpler and still be better than just pasting in
script tags. Not that there's anything wrong with that. In the end, that's
what happens anyway.

Sometimes the ways of the warmbloods confuse and infuriate me.

~~~
natecavanaugh
I'm the same kinda dinosaur, but I have to disagree with the following:

> Now, modern javascript packages for the web also use includes because it's
> part of NPM and the Node ecosystem. And as a result, there has to be a
> transpiling/build step to convert "Node" javascript to "frontend"
> javascript, or some other language to frontend javascript.

At first, I would agree, but with ES2015+ the import system isn't too
different or at least shares a lot with CommonJS.

Since that's the future of JS modularization, I think it's important to
embrace it. However, there is one area where the TC39 committee, along with
browser vendors/Node, really messed up is the releasing of the module system
with so much undefined or all over the place.

For example, the lack of a bundling strategy. Every person I've talked to
about this has just said "oh, http2 will take care of it". Really? Even if
http2 supports multiple connections, there will either need to be multiple
round-trips to the server for further dependencies (which, physics puts a
limit on the speed that can happen at), or you need to calculate on the server
and send over what's needed.

So I think these module bundlers are essentially doing that at build time
(which sucks for runtime dynamic inclusion of resources).

Then there's the whole .mjs fiasco with Node.

Since committees are so often slow to update (for valid reasons, many times),
and miss many valid use cases, I think the new world of frontend development
will include some sort of tooling like this.

It should, God willing, start to simplify (maybe kind of like how npm scripts
are becoming more preferred to gulp and the like).

------
WhoIsSatoshi
This is a well written explanation of the different layers one will encounter
when writing JS. It's a bit frustrating at first but once you get past the
hill, it's very satisfying.

------
dreta
The fact that you have to know a dozen major technologies just to make basic
UI that breaks half of the time should make you feel awful as an engineer.

~~~
Can_Not
I see this quip a lot but never any honest side-by-side comparisons
illuminating how much easier/simpler some other fullstack +crossplatform
ecosystem is.

------
maere
Very good synthesis ! Whatever everyone'd wanna say or think about JS, it's
hard to be in web development and not ear the bells. Better know what you ear
and what's'all about :)

I still have a tickle, you conclude with 3 so-called "modern features" from JS
... Both the 3 thing you quote come from Clojure and amazing work from google
nerdz, and was ported to JS later :p

------
0x4f3759df
my workflow is

npm to get the packages in VS2017 called from package-mgr console

gulp to move the package from node to wwwroot

system.js.config declares the packages

system.js to load the package

npm get the @types files (so typescript knows how to compile and I get
autocomplete)

and then I do a typescript import

\--- real pain in the neck to setup but now its really not bad at all

~~~
wereHamster
VS Code will automatically pull type definitions from npmjs.org, so you get
code highlighting and inline errors for free (not sure how much such
automation is included in VS2017).

Many npm modules come with their own typings. Those which don't usually have
them in the definitelytyped repo. For those 'npm install <foo> @types/<foo>'
should be enough so that typescript can find both the code and corresponding
type definitions.

The rest of your setup seems to be related how you build and bundle the files.
I use webpack and a typescript loader, and there is literally nothing more
that I have to do after installing the packages, I can just import (or
require) them in my code.

------
Exuma
This is actually really well written. I learned a few things about the history
that I've always been wondering (CommonJS, etc)

------
nodesocket
npm is so 2016 (being sarcastic).

~~~
Exuma
What do you propose using instead?

~~~
nodesocket
yarn.

~~~
pavel_lishin
Honest question: what advantages does it have over npm? As far as I see, the
only cool feature is the license check.

------
binaryapparatus
JavaScript programming and more importantly JavaScript way of thinking is
quickly becoming equivalent of company in need of hiring few good programmers
and solving it by hiring more HR 'professionals' first.

Let's solve this pile by throwing more useless stuff on top of it.

Yes, I do have badge that says I can say stuff like that. You know I am right
even if you can't agree in public. /rant

~~~
pavel_lishin
What badge?

~~~
binaryapparatus
"Gentleman wearing this badge can speak freely and name things as they are",
you know, usual.

~~~
pavel_lishin
what

------
mattmurdog
Most developer bros still think modern JS is Jquery but unnecessary. I've had
"Senior" engineers ask why we need Webpack because it's too complicated and
unnecessary and wanted to take it out. Others who think Angular is the same as
Bootstrap which is a UI framework. And those who doesn't even know what ES6
is.

