
JavaScript: The Modern Parts - janvdberg
https://amontalenti.com/2019/08/10/javascript-the-modern-parts
======
vfc1
I think today the Javascript ecosystem looks much better than 3 years ago, at
the peak of Javascript fatigue.

What we had actually was tooling fatigue, and not language features fatigue.
Today, with CLI tools like the Angular CLI, we have a ready to use optimized
bundle via one out of the box CLI command, so no longer do we have to learn
how to configure Gulp or Webpack.

I'm very glad that I decided not to learn Webpack and stick to the CLI, now
Webpack is going to be replaced by Bazel transparently, and from a user
perspective, nothing changes other than getting an even faster build and a
smaller bundle transparently, without having to be a build tools expert.

I can now focus on developing the application and not the tooling, which is
awesome for me. There are only so many hours in the day and I like to focus my
learning budget on what moves the needle most.

~~~
siempreb
> at the peak of Javascript fatigue

Are you very sure the peak was 3 years ago? Based on what? IMAO the mess only
gets worse.

You just mentioned webpack is going to be replaced?? That's unfortunately very
typical for the JS eco system. 7 years ago we had Grunt, then about two years
later Gulp, then about a year later Webpack, now apparently Bazel?
Interesting, never heard of it, but I still feel fatigue. I spent quite some
time to master Webpack, and again I'll have to start all over for the 4th time
now learning the next bundler..

I just started with React Hooks some months ago. First we had mixins(about 5
years ago), that was replaced with Higher Order Components, then we had to
start writing React in the brand new ES6 classes, then we saw the Render
Props, the Pure Functions, etc.. and now ES6 classes and all the rest are
deprecated, because Dan Abramov had another idea for again a new design
principle that's just less than a year old: Hooks.. Oh, and we don't do that
in JS, that is not sane anymore, every job I get nowadays is Typescript.

I mean, think twice before you say the Javascript fatigue is past it's peak.

~~~
peruvian
While the JavaScript ecosystem is on the volatile side, learning new tools and
frameworks every few years is just part of our job. Only in very boring tech
jobs would you only have to learn new things maybe once every 5 years.

I wouldn't really bother wasting time "mastering" something like Webpack or
what replaces it - as the other commenter said we just end up using an
abstraction over it anyway.

~~~
jbverschoor
It’s not learning a new frameworks and tools. It’s the fact that these tools
are usually fragile, and quite frankly not very much new is in there.

Also, what’s your goal? To learn new tools over and over again? Or to crate
something that that people will use?

You sound like a music “producer” (read - tech hobbiest) who keeps switching
tools, synths, and hardware instead of just creating music.

~~~
dpau
Yes, I don't even think the most important issue is that we as developers have
js fatigue. The biggest issue is that we are developing web applications that
are outdated before they are even released. Our software relies on thousands
of dependencies that are constantly changing or even dying off. Updating an
application that was built two or even just one year ago is often not a
trivial task. So while the frameworks and tooling have thankfully improved, in
general the cost of developing and maintaining an application seems to be much
greater than in the past (e.g. PHP MVC app with some jQuery sprinkled in).

~~~
freehunter
It's blogs and sites like Udemy. Their business model depends on people
needing to learn new technologies constantly. So when they tell you "MVC is
dead" or "Rails is dead", there is a direct profit motive in it for them. They
tell you everyone is using Backbone.js, so you move. Then the next year it's
Angular. Backbone is outdated, no one uses it anymore. Then the next year it's
React.

The blogs drive the technology shifts in order to get clicks. And every time
the technology shifts, Udemy sells a million tutorial videos at $10 a piece.
Everyone gets up to speed on the new thing just in time for the blogs to find
new clicks and Udemy to find new videos.

Meanwhile the real world still runs on Laravel, Rails, Flask, and Postgres.

------
pixelmonkey
I'm the original author of this post. Was surprised to see this here this
morning -- as I expressed in this tweet:
[https://twitter.com/amontalenti/status/1165252347909607424](https://twitter.com/amontalenti/status/1165252347909607424)

Glad to answer any questions about the post here.

I am hoping to write a second part to this post eventually. It was honestly
sitting in my drafts folder for a solid 6-8 months, and then I finally cleaned
it up and published it two weeks ago. But I still have more thoughts!

~~~
CraigJPerry
it was a really enjoyable article, I bookmarked your functional js paper for
later too. Thanks for sharing it. </delurk>

------
DigitalSea
>Understanding webpack, and why it’s important

Not sure how Webpack is being attributed as being a part of Javascript here.
It's a bundler, with Javascript support being one small piece in a much larger
puzzle. It's not even the only bundler out there, JSPM is currently in beta
which goes in a different direction than Webpack, then you have Parcel and
other options as well.

>Understanding babel, and why it’s important

Eh. I haven't used Babel in years since switching to TypeScript.

This doesn't seem very focused on Javascript, seems like a lot of emphasis
being placed on tooling more than the language itself.

~~~
IggleSniggle
I agree with your assessment, but the “major” web framework ecosystem (React,
Angular, Vue) all use webpack as a de facto part of their toolchain. And
webpack, in turn, relies on babel. Other bundlers are commonly used as part of
plugin system.

Regardless of transpiler tooling, the tooling is how most people are confident
in using the most modern variants of JavaScript code. So it’s an important
part of the modern js story.

~~~
davnicwil
I agree, JavaScript the Good Parts was written in a time when there
essentially was no ecosystem in Javascript to speak of, so it was by
definition focused on nothing but the language.

In 2019 JavaScript comes as part of a much more developed (and useful!)
ecosystem that is completely tied in with tools such as Babel and Webpack and
the alternatives mentioned.

Even if you don't use or want to use any particular one of them, knowledge of
all of them, at least what they do, is more or less essential to work in
modern JavaScript to understand how the ecosystem fits together and how most
projects out there use the language.

------
lol768
>Whereas Java and C users may still have debates about where, exactly, open
source projects should publish their releases, that issue is settled in the
JavaScript community

I thought Maven Central was pretty much the canonical answer in Java land.
Nobody cares what tool you actually use to pull these down (SBT, Gradle,
Maven..).

>What this means, however, is that to do JavaScript development “The Modern
Way”, while adopting its new features, you simply must use a local transpiler
toolchain

Surely this depends on the browsers your application is targeting? And
presumably, the sort of feature you're using (can it be polyfilled or is it a
syntax feature?).

>In 2018-2019, several things have changed about the JavaScript community.
Development tools are no longer fledgling, but are, instead, mature. There are
built-in development tools in all of Safari, Firefox, and Chrome browsers

I agree they're decent, but there are still cases where they struggle -
particularly after code has been transpiled. I still run into issues these
days where the browser is trying to show a source-mapped JS file instead of
the actual bundle code which masks a real issue.

>And, for web frontends, it’s your only choice

[https://caniuse.com/#search=webassembly](https://caniuse.com/#search=webassembly)

If you don't care about IE11 (or you polyfill), it's hardly your only choice.
wasm is still far from perfect but there's no question you can start writing
some logic in languages other than JavaScript, and interoperate.

>If you’re the kind of programmer who thinks, “I code in
Python/Java/Ruby/C/whatever, and thus I have no use for JavaScript and don’t
need to know anything about it”, you’re wrong, and I’ll describe why.
Incidentally, you were right in 1998, you could get by without it in 2008, and
you are dead wrong in 2018.

>To be a serious programmer, you’ll have to know JavaScript’s Modern and Good
Parts — as well as some other server-side language, like Python, Ruby, Go,
Elixir, Clojure, Java, and so on

This reads to me as downright patronising to e.g. embedded software engineers
who might be writing hardware drivers in C/C++ day to day.

Perhaps this should read "to be a serious web developer with front-end
responsibilities" (JavaScript is sufficient, not necessary on the back-end and
- of course, subjectively - there are much better choices to use).

~~~
richardwhiuk
There's a bizarre, naive belief that all programming is web programming.

It's patronising and inaccurate, but it's common among people who think
Javascript is a serious language.

~~~
dreamcompiler
Javascript is a frustrating language. On the one hand it's more "serious" than
[legacy] C, C++, Java, and Python because it had first-class functions and
real lexical closures from day one.

On the other, it had imprecise typing, no multiprocessing, and no access to
the file system. Some of that has been fixed, but Javascript was designed by
one person in a week to script web browsers and that's still painfully
obvious.

~~~
Skunkleton
> On the one hand it's more "serious" than [legacy] C, C++, Java, and Python
> because it had first-class functions and real lexical closures from day one.

Why do closures make a language "serious"? To me languages are just languages.
Seriousness is defined the problem you are solving. Are flight controls
serious? Probably. Is yet another small scale CRUD app serious? Probably not.

There is a lot of "serious" code written in every major language. There is a
huge amount of "serious" code written in C and C++, and all of this without
first class functions or lexical closures.

~~~
dreamcompiler
Good question. I'll try to give my answer, but others will have their own
opinions. Computer languages move in the direction of supporting "good ideas"
as those ideas become generally recognized as being good. Usually those ideas
start in academia and gradually find their way to industry. Some examples:
Structured ("goto-less") programming, object-oriented programming, automatic
memory management, strong typing, lexical closures, first-class functions,
functional programming, automatic bounds checking, and prevention of memory
ownership violations.

A "serious" language is indeed partially defined by its fitness for the stated
job at hand, but also for how well it handles the often unstated requirements
of productivity, security, maintainability, and robustness in the face of
likely future needs. Languages that have more of the above features tend to do
better at these unstated requirements.

What is and isn't a "serious" language can change over time depending on what
we learn is important. C was a serious language for a while, but it has not
been one for a couple of decades because of its non-support of anything
remotely resembling security. C is still used because of its extreme
portability, but it probably should be abandoned.

Conversely, languages that support first-class functions, lexical closures,
and automatic memory management are now in the serious category because those
things present huge improvements in productivity, maintainability, and
robustness in the face of future changes. (I'll even go out on a longer limb
and say that programmers who learn to _think_ in terms of functional
composition become more productive coders in any language.) Pure O-O languages
are beginning to move in the non-serious direction because they cannot be
readily parallelized in an era when parallel computing is the only way forward
now that Moore's law is dead.

Javascript anticipated a couple of these features before other mainstream
languages, and now it's moving beyond web browsers. So yeah, with some
reservations I'd call it serious.

Nowadays I'd never write major code in a language that doesn't directly
support most of the "serious" features I listed above; it would be too much of
a hit to my productivity. It would feel like building a house with a hammer
and nails when nailguns were readily available.

If I were writing embedded apps like flight controls today, I'd use Lisp for
the high-level parts and Rust and maybe a bit of assembler for the low level
parts.

~~~
Skunkleton
I find the idea of viewing a language as "serious" to be fundamentally flawed.
Every project has a set of requirements and constraints. Usually the pragmatic
language choice is dictated by external factors. Things like library support,
developer expertise, and tool maturity are much bigger factors for most
businesses.

The "serious" professional choice for my company (an OS vendor, with a focus
on certifiable systems) is currently C. The tooling we use is for C, the
expertise within my company is in C, and the industry that we work with
understands and expects C.

At some point, the operating systems industry will transition to more modern
languages. Rust is promising, but it is a long way from being a serious
consideration for FAA certifiable projects.

------
EdwardDiego
> Yes, it has taken 20 years, but JavaScript is now just as viable a choice
> for your backend and CLI tooling projects as Python was in the past.

Considering how often Node projects break our build, I respectfully beg to
differ.

~~~
blondin
i agree with the sentiment. i was just thinking about it yesterday. what if
there was a pure javascript based system programming language? with none of
the event loop thingies?

i mean can we have a normal javascript that compiles to a x64 binary and calls
the OS?

~~~
ksherlock
JScript.Net compiles to .NET bytecode and has for the past 20 years or so.

------
shusson
To be clear, this has no association with the original "Javascript: The Good
Parts" by Douglas Crockford book.

------
misnome
It looks like an interesting light summary of the state of things. The
technical articles might be more useful, for me.

As a primarily Python/C++ developer who dabbled with JS in the early and late
2000s, can anyone recommend an efficient way to get started with modern JS
development for hints like interactive frontends with a different-language.
I’m comfortable with large language ecosystems, but there seems to be an
intimidating number of incompatible paradigms - and there’s both the
technology and toolings.

Easiest to start with one track e.g. react/tutorials and branch from there?
Good books that approach the problem efficiently and for a decent existing
programmer/scientist?

~~~
pixelmonkey
I'm the original author of the post. A friend who reviewed a draft of it asked
me the same question. I had the following recommendations:

1\. Solid recorded talk (on YouTube) on using npm run-script to automate local
builds:
[https://www.youtube.com/watch?v=0RYETb9YVrk](https://www.youtube.com/watch?v=0RYETb9YVrk)

2\. Modern JavaScript Explained for Dinosaurs: [https://medium.com/the-node-
js-collection/modern-javascript-...](https://medium.com/the-node-js-
collection/modern-javascript-explained-for-dinosaurs-f695e9747b70) \-- this is
a long post that goes into technical depth on the stuff that I covered at a
high level in my post

3\. Webpack -- The Confusing Parts: [https://medium.com/@rajaraodv/webpack-
the-confusing-parts-58...](https://medium.com/@rajaraodv/webpack-the-
confusing-parts-58712f8fcad9) \-- long post that goes into depth on Webpack,
in particular.

Aside from all of these, the book I have found the most helpful if you want to
zoom straight ahead to React is "Road to React": [https://leanpub.com/the-
road-to-learn-react](https://leanpub.com/the-road-to-learn-react)

It's 200 pages, oriented around real code, and straightforward.

------
manigandham
Javascript is not the only answer to frontends ever since WebAssembly arrived.
Microsoft is releasing Blazor for C# in a month (server-side first then
client-side) [1] and there are similar projects being worked on for Rust,
Java, etc.

1\. [http://blazor.net](http://blazor.net)

------
truth_seeker
JavaScript brief history and ECMAScript(ES6,ES7,ES8,ES9) features

[https://medium.com/@madasamy/javascript-brief-history-and-
ec...](https://medium.com/@madasamy/javascript-brief-history-and-ecmascript-
es6-es7-es8-features-673973394df4)

------
galaxyLogic
I have some ES6 compliant JavaScript to run on the browser. Now I would like
to compile it into web-assembly and serve that from a server to the browser,
to make it faster to run and download.

Is that possible with the modern JavaScript tools?

~~~
shepherdjerred
From what I've heard WASM isn't a viable alternative in the first place. It's
good for compute-heavy tasks, but the overhead involved in going from browser
to native to browser is too much to make WASM an alternative to what
JavaScript is usually used for -- rendering interfaces and making pages
interactive.

~~~
fold_left
> From what I've heard WASM isn't a viable alternative in the first place.
> It's good for compute-heavy tasks, but the overhead involved in going from
> browser to native to browser is too much to make WASM an alternative to what
> JavaScript is usually used for -- rendering interfaces and making pages
> interactive.

I don't think that's the case anymore: [https://dassur.ma/things/is-
postmessage-slow/](https://dassur.ma/things/is-postmessage-slow/)

~~~
snek
Article is unrelated. The overhead for Wasm is from copying structs into and
out of the Wasm's linear memory. Wasm only has ints and floats at the
boundary, so you have to copy everything into structures it can understand.

Note that there is work to improve this (interface types, anyref, etc), but
we're not there yet.

------
obituary_latte
>In that era, I wrote one of the most widely deployed pieces of JavaScript on
the web, and maintained a system powered by it.

Anyone know what he is talking about here? I searched google but couldn’t find
what he was talking about.

~~~
pixelmonkey
I'm the original author of the post.

I was talking about Parse.ly's analytics engine, where most of the data we
provide to our customers on first-party analytics around their audience stems
from some lightweight JavaScript code they embed in their websites. It's now
installed on thousands of high-traffic sites[1] and provides analytics on over
a billion web/mobile browsers per month (as described in this Strata talk[2],
for example).

I wrote a little bit about my experience writing that code in this HN comment:
[https://news.ycombinator.com/item?id=10206956#10207998](https://news.ycombinator.com/item?id=10206956#10207998)

It was a fascinating piece of code to work on because not only did it have to
be lightweight and fast across all browsers, but it also had to be tiny to
embed, and it needed to be x-browser tested all the way back to IE6 and
strange mobile browsers. Plus, at the time it was originally written
(2010-2012), there were hardly any good JS build tools outside of early
versions of uglifyjs.

Over the years, other engineers have improved the performance even further,
while retaining the kernel of the code. We even did a change last year which
improved client-side performance through a number of clever build/CDN tricks.
We've also had to hold our ground firmly on privacy, which it turns out is one
of the key areas third-party JavaScript started to take a turn in the wrong
direction, especially in the adtech universe. (We are a content analytics
company, with a similar SaaS business model to MixPanel for product analytics
and NewRelic for performance analytics. So, for us, privacy is paramount.) I
wrote about this here: [https://blog.parse.ly/post/3394/analytics-privacy-
without-co...](https://blog.parse.ly/post/3394/analytics-privacy-without-
compromise/)

[1]:
[https://trends.builtwith.com/analytics/Parse.ly](https://trends.builtwith.com/analytics/Parse.ly)

[2]: [https://conferences.oreilly.com/strata/strata-
ny-2018/public...](https://conferences.oreilly.com/strata/strata-
ny-2018/public/schedule/detail/69132)

~~~
obituary_latte
Very cool and interesting stuff. Many thanks for the reply and info.

------
randallsquared
Why "ES2017", specifically? ES6 is ES2015, and ES2019 was published a few
months ago and is well-supported in node.

~~~
pixelmonkey
I'm the original author. This is just an oversight -- the original draft I
wrote here was at a time when ES2019 wasn't yet published. Agree that you can
safely use any ratified (recent) standard with Babel.

------
Koshkin
JavaScript is fun, but I wish they had chosen Scheme - both for scripting and
instead of HTML.

------
tus88
What's the view that TypeScript is the modern Javascript?

~~~
IggleSniggle
TypeScript adoption has been swift and decisive. In 2019, the majority of js
developers that take surveys use TypeScript.

Edit: Mea culpa. I got my numbers mixed up, or whatever source I thought I
remembered just doesn’t exist. 46% in 2018 (state of js) says nothing about
2019, and is not a majority. That 46% is also backed up by a similar survey
that npm ran. It’s worth adding though, I think, that js devs benefit from ts
type inferencing and IDE support even if they aren’t using it directly

~~~
leeoniya
> In 2019, the majority of js developers that take surveys use TypeScript.

TS is quite popular, but this cannot possibly be representative of the general
population of js devs, not even close.

it's more like ES6 >> JSX >> TS >> Flow.

~~~
IggleSniggle
46% was the survey number, so I definitely misremembered the facts. But your
comparison here is inevitably necessary, since TS compiles to ES6/JSX, (as
does Flow)

~~~
leeoniya
what was the survey sample size and how was the sample selected? (46% of
0.001% is still 0%).

my assessment isn't what things compile to but what they are authored in.

~~~
IggleSniggle
Good question. The state of js survey was self-selected, with 20.2k responses.
The data is available if you’re interested. The npm survey, on the other hand,
was sent to 800k registered npm users and received 33.4k responses, and also
found 46% TypeScript usage. I imagine there is significant selection bias in a
number of ways. And, while the state of js survey found 46% “have used ts and
want to use it again”, the npm survey did not ask about preference. Still, a
decent number of responses that I think is pretty interesting, regardless of
your own preferences!

------
z3t4
No you dont need a transpiler. The new language features are exiting, but its
really just old concepts from other languages. And IMHO these old conceps are
not better and some of them are worse. JavaScript was lucky and got some
things right, like first class functions, prototype instead of classes,
function scope, no need for getter/setters. Node.js also got lucky with its
module system. JavaScript was lucky because it was async. Javascript got
adopted in more then just browsers because it was lightweight. Etc.

------
otabdeveloper2
The "modern" Javascript parts make me almost physically sick.

Gimme back my plain old browser Javascript. It was primitive, but at least it
wasn't actively harmful.

~~~
debaserab2
Care to elaborate?

"Modern" javascript runs just fine in your plain old browser.

~~~
s_Hogg
Parent is talking about all the vulnerabilities and slowness that can come
with it. Fair enough, it runs, but it can also open the door to fingerprinting
and other weird nasties. Particularly anything reliant on the `npm install`
way of managing dependencies is a potential risk from both server and client
point of view.

~~~
debaserab2
Where is parent talking about any of that?

What about today's javascript lends itself to fingerprinting any more than
javascript from twenty years ago?

~~~
mattlondon
Agreed - I don't see how adding things like "let" instead of "var" or the
spread operator (e.g "[...x]" instead of "[].concat(x)") makes fingerprinting
or anything nefarious any more likely, apart from making it more pleasant to
program so maybe more people will use it?

The "old" javascript was turing complete (as the article points out), as is
the current one. It is not like they've added
"Object.turnOnNefariousPrivacyInvasions()".

Granted, the browser APIs have evolved (e.g. webcam access, localstorage etc)
and are exposed via Javascript, but that is nothing to do with JS the
language.

~~~
SquareWheel
Those APIs also have a much stronger security model behind them today.
Browsers require things like TLS and user confirmation before sharing geo
information. Other actions like the clipboard API require user interaction
(eg. button clicks).

JS of the past was the wild west. You want to add a bookmark? Go for it! You
want to trigger a print dialogue? Why not!

~~~
krapp
>JS of the past was the wild west. You want to add a bookmark? Go for it! You
want to trigger a print dialogue? Why not!

Yeah. People forget that in the bad old days you could even do things like
redefine the global Array constructor[0].

[0][https://johnresig.com/blog/re-securing-
json/](https://johnresig.com/blog/re-securing-json/)

