
The Third Age of JavaScript - swyx
https://www.swyx.io/writing/js-third-age/
======
game_the0ry
Current front end dev, here. My employer pays me to write JS, have been doing
it for +4 years.

I've become comfortable with the fact that JS never stops changing (note the
use of the word _changing_ , not _improving_ ). I concern myself with
fundamentals, not framework-flavor-of-the-month. I encourage others to focus
on the same.

What I am _not_ comfortable with is the stubbornly-held strong opinions many
JS devs have. Much of the time, a particular JS dev will believe their way is
the one-true-way(tm) (which is a problem among a lot technologists in
general).

JS devs are the JS fatigue...not JS itself. I get bent when JS devs judge me
for not staying up to date - JS is my 9 to 5, not my life.

For all the JS devs out there who hate me right now - check out Elixir, its
the new "new."

FWIW, my personal projects are Spring Boot and Kotlin.

~~~
commandlinefan
> stubbornly-held strong opinions many JS devs have ... a problem among a lot
> technologists in general

Hmmmm... well, I might agree, but that would depend on the opinion. There was
a time when all programming was done using GOTO as the sole flow-control
mechanism until a guy with a stubbornly-held strong opinion named Djikstra
taught us that GOTO was considered harmful. Yet it's also the most natural way
to code: a lot of people argued with him (in fact, the reason beginners don't
use GOTO any more is just because it's not there, not because they've gotten
more sophisticated). It's also a stubbornly-held strong opinion among many,
but too few, developers, that global variables are also harmful. Unfortunately
they're also the simplest, most obvious way to code, so a lot of developers
default to using them.

If a developer has a stubbornly-held strong opinion, I usually give them the
benefit of the doubt to try to figure out why: often they have a good reason.
(On the other hand, sometimes the reason is, "it's easiest", like using public
static variables in Java).

~~~
jacoblambda
The GOTO topic is an interesting one because Dijkstra inadvertently started a
cult around the avoidance of GOTO. Dijkstra never intended this and one of the
main reasons this occurred was because Dijkstra's original paper "A Case
Against the Goto Statement" was editorialised as a letter to the author type
article to speed up publication which resulted in the famous title "Goto
Statement Considered Harmful".

This is a topic where both him and other prominent figures such as Donald
Knuth have since its publication repeatedly argued for moderation in use of
the GOTO statement and against the total avoidance of GOTOs.

My go to example for this is that in C and other languages that lack modern
comforts such as exceptions(for better or worse) and destructors, GOTOs can
largely simplify the handling of clean-up and error recovery code.

Another example is longjmp which is very useful in kernel-space or bare metal
programming, and in implementation details for exception handling however
outside of those niches, serves no purpose.

GOTO serves a very useful niche but can also make code nigh impossible to
follow. Most other structured programming statements have the same threat but
we have rules in place to avoid their abuse. The following cases can result in
code that is just as problematic:

IF/ELSEIF/ELSE: overly large, overly nested, or mutating variables.

SWITCH/CASE: complicated fall-through.

FOR: mutating counter variables, mutating termination condition.

TRY/CATCH/FINALLY/THROW: exception hell/deep uncaught exceptions.

These control flow mechanisms should definitely be preferred to GOTO in most
cases but they can be just as badly abused if you aren't careful. The big
difference I find is that people are taught how not to abuse these mechanisms
but most material about the proper uses of GOTO is almost taboo because of the
cargo cult around avoiding its use.

Sorry if this doesn't really fit into the discussion but it's interesting to
me how an initially very tame and rational counter-argument spawned a massive
cargo cult.

~~~
marcosdumay
> but they can be just as badly abused if you aren't careful

No, they can't. Old-school goto can create entire new problems in a codebase,
that aren't possible to replicate with the structured constructs. That's the
entire point of structured programming.

Of course, it's possible to use goto well. But eliminating it eliminates the
problem.

------
sheetjs
2020 feels like a new age because of the browser ecosystem. The actual
endpoint of the "second age" is probably the combined forces of:

1) Windows 7 Support officially ended

2) Edge now switched over to Chromium

With the exception of highly niche applications and markets, sites meant to be
consumed on computers can aim for Chromium support and developers can rest
assured they are covering the overwhelming majority of the market. Many
slower-moving enterprises are standardizing on Chromium-powered browsers. Even
NetFront (browsers used by video game consoles) is switching over to Chromium

The "Third Age of JavaScript" isn't marked by tooling or frameworks or code
structure, but rather by developers able to focus on one browser instead of
multiple. This new age will be marked by innovative use of APIs that people
disregarded in the past because they only worked in Chrome.

~~~
lhorie
> developers able to focus on one browser instead of multiple. This new age
> will be marked by innovative use of APIs that people disregarded in the past
> because they only worked in Chrome.

Ah, just like the good old days of `new ActiveXObject("Microsoft.XMLHTTP");`
;)

------
rl3
_The Third Era_ would've been far more dramatic sounding, especially when
spoken by Patrick Stewart.[0]

Sorry, I couldn't help but draw an _Elder Scrolls_ comparison here:

"Behold, in darkness, a doom sweeps the land."

"I have seen the gates of Oblivion, beyond which no waking eye may see."

"These are the closing days of the Third Era, and the final hours of my life."

Each statement could just as well have been spoken by your typical late 30s
web developer that's seen some shit. That's lived through innumerable
instances of framework and toolchain hell. That's probably being pushed into
management because they're almost 40.

[0]
[https://www.youtube.com/watch?v=JGhlg4JqvQw#t=0m44s](https://www.youtube.com/watch?v=JGhlg4JqvQw#t=0m44s)

~~~
_bxg1
"And Gandalf said: 'This is your realm, and the heart of the greater realm
that shall be. The Third Age of the world is ended, and the new age is begun;
and it is your task to order its beginning and to preserve what must be
preserved.'"

~~~
rl3
I stand corrected! _Equally_ dramatic-sounding. :)

Ironic that Gandalf was of course played by Ian McKellen in the films, and is
good friends with Patrick Stewart.

------
rememberlenny
I was surprised there was only a mention of frameworks.

One obvious shift I’ve seen is in the use of the WASM and Web GL compiled
applications. The likes of Figma and Superhuman are making incredible leaps in
user performance.

I suspect serious companies will make strides here.

~~~
Androider
That's super interesting, never heard that about Figma. Is the entirety of
Figma in WASM or just the core drawing engine?

~~~
rudi-c
Design document are stored, manipulated, and rendered in WASM and WebGL. The
surrounding UI (toolbar, properties panel, layers panel, etc) is written in
React.

It's done that way because documents can get really large and having more low-
level memory management helps a lot there. On the other hand, writing UI in
C++ is really tedious and React has served us great. For non-performance
sensitive areas, I'd much rather use TypeScript + React, despite being
comfortable writing C++.

So obviously we're big fans on WASM, but we don't expect nor want JS/HTML/CSS
to go away anytime soon.

------
RyanGoosling
3rd-Age: People will finally learn to effectively use vanilla JS, DOM API,
HTML5, and CSS3 and will stop relying on transient abstraction tooling. They
will actually learn the standards rather than rely on a Tech team's rendition
of the next new thing.

Roast me

~~~
ng12
Roast you? How about this: a version of this comment is posted on just about
every JavaScript post for the last five years and it hasn't changed much.

~~~
yc12340
> a version of this comment is posted... _for the last five years_

Sounds like he is right and you are too old and averse to change to admit it!

------
janitor61
Meanwhile, jQuery is still used on 74% of all websites [1] despite being part
of the 'first wave' obsoleted in 2009. If all this Javascript evolution is
failing to gain traction across the whole of the web, is it really
transformative, or is it just innovation for its' own sake?

[1] [https://w3techs.com/technologies/details/js-
jquery](https://w3techs.com/technologies/details/js-jquery)

~~~
dntrkv
React is not a replacement for jQuery. I've seen many codebases that are
written in React, but still include jQuery for some legacy function in the app
that references $.param or similar. Using this stat to say anything other than
"jQuery is bundled on X% of sites" is pointless.

If you could determine which sites are built using jQuery as the primary
"framework", that would be informative. But even then, jQuery is just a
library of utility functions, comparing it to React/Angular/Vue is pointless.

------
_bxg1
I think this is spot-on, and I'm 100% here for it. Here's a secret: even JS
developers don't like all the frameworks and build complexity. We like what
they afford us, but the overhead has been a symptom of an immature ecosystem.
I think most of us are glad to finally see the cruft starting to get shaken
out as it matures.

------
0xDEEPFAC
My prediction - the third age of Javascript will be the same as the second
with tooling headaches, "transpiling", and fractured dialects. Except in this
age we are all forced to use it as major companies sandbox away powerful APIs
in favor of more control of their stores.

Dark times are ahead. The future is chrome.
[https://www.youtube.com/watch?v=_SCfNhyIo_U](https://www.youtube.com/watch?v=_SCfNhyIo_U)

~~~
thepaulstella
> Dark times are ahead. The future is chrome.

Nothing strikes fear into my heart like this does.

~~~
RyanGoosling
Reminds me of that one Spongebob episode where everything was chrome.

~~~
hinkley
I was thinking more Fury Road myself.

------
Hokusai
My guess: WebAssembly and the birth of the polyglot web. C#, Rust or C will
life and interact with HTML and JavaScript.

------
wwweston
Definitely does feel like something new is in the air. I got into front-end
(after a few years of back-end) during the rise of jQuery and CSS layout,
remained super excited about it even with the problems through the backbone
years, checked out in disgust and retreated to the back end after my first few
Angular apps. Apparently missed whole sub-eras (have no idea what Prettier and
Parcel are). Svelte and Deno are both pretty interesting, React at least seems
stable and oriented around a smallish number of straightforward concepts,
seems almost safe to come back into the water. Almost :)

Still wondering, though, if there aren't a lot of cases where a document-
oriented approach (moving markup rather than JSON, progressive enhancement,
good old standards) wouldn't serve an application domain better...

~~~
schwartzworld
parcel is a bundler.

Prettier is an optional part of developing in JS that is hard to live without
once you're used to it. instead of worrying about perfectly formatting your
code, just write it and let prettier fix the formatting.

------
gorpomon
The third age of JS is going to be really exciting. People treat JS-land as
something that has a first class language that can build major production
tools and applications. Cloud providers support JS for nearly all aspects of
their large platforms. The one place where I anecdotally see a decrease is in
full-stack JS apps, but that's because the entire premise of a singular back-
end app is under scrutiny by the cloud ecosystem itself. JS just never had a
chance to get more established as a back-end language before that happened.

~~~
JSavageOne
What? Node.js is as strong as ever. With Next.js it's never been easier to
create a full-stack JS app. I don't see what any of this has to do with the
cloud.

~~~
gorpomon
My comments were an observation based on what I've seen recently, and none
were intended to be a value judgement on any work being done in JS-land. I
just don't see a Rails-esque competitor rising from JS land anytime soon and
gaining enterprise market share. Cloud has to do with it because Cloud is
increasingly how applications are created. Instead of a large framework to
create an application with a language (Spring for Java, Rails for Ruby, Django
for Python), applications are now mishmashes of cloud functions, no sql
tables, sql data stores, message queues and auth wrappers, all of those
without a specific language requirement. Like I said in my original comment,
it forces every language based framework to question it's (comparatively)
monolithic nature. This isn't a fool proof prediction by any means, but with
the rise of cloud architectures I really don't foresee any languages birthing
a monolith anytime soon. I'm sure lots of folks will use Next.js or something
else, and it will be good a tool, but my bet is that even more companies will
increasingly utilize the cloud to create less monolithic architectures.

~~~
jagannathtech
Rails-like for JS is coming via RedwoodJS and blitzJS. How much successful
they will be? I have no clue.

~~~
Can_Not
AdonisJS and FeathersJS has been pretty successful.

------
uryga
> _the Third Age is about clearing away legacy assumptions and collapsing
> layers of tooling._

i feel like the bit about "clearing away legacy assumptions" wasn't
substantiated very well – basically just "CommonJS isn't necessary anymore
because ES Modules are a thing now". which is true, but i feel like a sweeping
statement like that needs a bit more. and if that assumption is where other
"legacy assumptions" stem from, it'd be nice to expand on it a bit

~~~
Androider
My take is that we're never going to see ES Modules in the wild in web apps as
we know them today, outside of some tutorials or open source apps. There's too
strong business incentives to the contrary, legitimate or not.

~~~
RyanGoosling
Business incentives like supporting Internet Explorer for clients $$$?

~~~
Androider
Obfuscation. If web app companies could, they'd send your browser a binary
instead of HTML and JS.

~~~
uryga
isn't minification good enough at obfuscating the code? what does CommonJS add
here?

(that's a legit question – i've sifted through webpacked JS a few times, and
it mostly just added a bunch of

    
    
      (function(module, require, ...) {
         <your module here>
      })(...)
    

around the code. tedious to read, but not much in the way obfuscation)

and i guess if ES Modules turned out to be more performant (bc the module
stuff is handled by native browser code, or maybe some HTTP/2 magic with
loading), that could be an incentive for adoption

~~~
RyanGoosling
I've combed through minified JS a number of times. Not enough if you want to
prevent someone from going through your shit.

------
sarsamurmu
Like vite and snowpack, I've been also working on a project which aims to
provide fast development experience. Unlike vite and snowpack, it supports
CommonJS too and it's somewhat more configurable. Dropping it here, just in
case someone finds it useful -
[https://github.com/sarsamurmu/reboost](https://github.com/sarsamurmu/reboost)

------
zubairq
at yazz we have bet on javascript when many others are moving away. why?
because javascript is here to stay as the defacto Browser language. Show me a
Mainstream browser that plans to drop JavaScript support and we will Drop
JavaScript too

~~~
pedalpete
I used to take this same perspective, but if you look at how you are coding
javascript now, you're building and bundling, so though browsers may continue
to run Javascript, that doesn't mean your code will always be written in
Javascript.

We moved to Typescript two years ago, and now that I'm comfortable with that,
and compiling to JS, I wouldn't be surprised to see good compilers for Rust or
other languages become the standard in the future.

~~~
zubairq
Good points. If typescript becomes the standard then for sure we would
consider whether we should move our product to typescript

~~~
pedalpete
Typescript is becoming VERY popular. I Deno (the potential replacement for
Nodejs) is written in typescript.

I hadn't worked with types before, and hated it when I first started, but once
I got used to it, it's a nice experience.

------
jonahss
maybe.

but also, there’s a classic pattern of articles which look back and describe a
timeline of “past, present, future” where future starts tomorrow due to this
thing I’m excited about today.

