
JavaScript: The First 20 Years - ngcc_hk
https://zenodo.org/record/3707008#.XtoRR-TEklQ
======
_hardwaregeek
I'm starting to develop a theory that a person's stance on JavaScript reflects
their ability to critique reasonably and therefore their maturity as a
developer (to an extent).

JavaScript undeniably has some problems. It's also undeniably useful and
eating the world. If you can hold both of these stances in your head and
reconcile them into a nuanced opinion, then that's a great sign. If your
viewpoint collapses into "JS sucks!!!" or "JS rules!!!" then you're not
providing an opinion as much as a dogma, often one that is regurgitated from
some other source.

I'm not saying that one should find JavaScript good or bad by the way. Someone
who abjectly dislikes JavaScript but also understands its utility is quite
useful. The creators of TypeScript, ReasonML, etc. all had to dislike
JavaScript in some form. But they had to dislike it in a productive, nuanced
manner.

~~~
willtim
> But they had to dislike it in a productive, nuanced manner.

No, they fundamentally rejected JavaScript, enough to build a whole new
language and set of tools. This was not a subtle dislike of a few aspects of
it.

Personally JavaScript absolutely terrifies me, it's a semantic mess, the
equality table is one such example: [https://dorey.github.io/JavaScript-
Equality-Table/](https://dorey.github.io/JavaScript-Equality-Table/)

~~~
namelosw
First, it's easy to fix by just using ===.

Second, It's more of a blub programmer thing. From multiversal equality's
perspective, almost every mainstream statically typed language is also a
semantic mess - you can even compare int to a boolean with == in a statically
typed language without having any type errors, despite the comparisons always
return false and 99 out of 100 that's not what people meant.

~~~
nyanpasu64
In C++, you cannot compare unrelated types unless there's an implicit
conversion or explicit equality operator (or something like that). In Rust,
you cannot compare same or different types unless you implement PartialEq, and
you can't compare an int with a bool. In Java, you can't use == to compare an
int and a bool (both primitives).

------
randombytes6869
I don't think its physically possible to read this in the time since its been
posted, but since people are commenting anyways I might as well join in.

I've been using JS since the JScript days, and let me tell you it was
horrible. Awful. I would rather use VBA, Perl, early PHP, really anything I've
touched besides COBOL. It was buggy, horrifically slow, had an even worse
standard library than it does now, didn't work the same way between anything.
I remember testing performance and getting 1000 integer increments a second in
an empty for loop. Even back then an alarm clock running C was orders of
magnitude faster.

But the massive popularity of the web has made it decent. Its a good example
of the (overused) axiom that you can pour enough money into anything and make
it good. With JS, this actually happened. Probably because the other choice
was transitioning the web to Flash, Silverlight, and Java Applets. The
proprietary solutions lost the battle thankfully, even though admittedly they
were better than JS for a long time after they died.

There's still lingering problems, some which may prove un-fixable. The
standard library is a joke. The 1 million line ancient Java monolith at work
pulls in less libraries, by count and space then create-react-app. And not
having threads is just terrible. People that don't know better ape over async,
not knowing that most languages have async, threads, sometimes fibers, and
fast shared memory between them. And NPM works decently but putting 5 million
files into my node_modules folder is absurd. NPM is the only reason I know
that most OS'es still have a path length limit. You would think the world
could standardize on putting libraries into a zip or something like even
ancient crufty languages like Java do. If it wasn't for SSD's modern JS
wouldn't even be usable. And can we just compile JS already? Minification
seems so normal that everyone's forgotten its a shitty hack. If you're going
to minify to the point that JS resembles bytecode why not just standardize a
format. People say "JS runs right away because its not compiled"... Well...
How long does your WebPack take to transmogrify 150MB of spaghettified JS into
a pile of chunks you can actually feed a web browser in prod? Probably longer
than it takes most languages to compile. If we just compiled to a reasonable
format like other VM languages, we wouldn't waste so much time parsing and
keeping these tools working with every semantics update.

Here's to the hope that money poured into JS will finally fix the remaining
issues. I give it another ten years and I'll finally enjoy most of my time in
JS land.

~~~
diegof79
After using many languages for a long time, and working mostly with
JavaScript/TypeScript in the last years, I agree with many things that you
said.

However, I think that is good to recognize the good things too:

\- JS function and object notation is very flexible and nice to work with.
Each time that I go back to Java I feel the pain.

\- PHP makes JS look nice and consistent by comparison (note I used PHP from
v3 to v5... so my comment maybe wrong today)

\- Adopting functional constructs for some parts of the std lib was good. Many
times I wished to have an equivalent map/filter/reduce in Python (the list
comprehension syntax is terrible)

\- NPM and small modules receives tons of criticism. But it allowed NodeJs to
thrive. Anybody can publish or get a lib with one command. By comparison doing
the same for Java was really hard in the past (you needed permission to
publish to MavenCentral... and if you were lucky you were allowed after many
days of mail exchanges). The situation in other languages is not better:
Python package management is a mess of options, Swift package management is
not mature enough.

\- JS doesn’t have threads... but some languages (eg Dart) moved away from the
classic threads constructs to adopt actors. If you did anything with mid
complexity using Java threads and dealing with synchronized/wait you start to
appreciate the simplicity of async / await.

\- Template literals existed in many languages (shell scripting, Perl, etc).
But in JS they can be easily extended with template functions.

\- I prefer any of the Node web server frameworks over the pain of Java (I
worked for many years using servlets, JEE, Spring.. and Java Rest API
frameworks).

I’m not trying to do a “what aboutism” argument, just highlighting that
besides the limitations there are also good design decisions in the JS
ecosystem.

~~~
randombytes6869
A lot of the newer stuff in JS is great. The baggage is what bothers me. For
all the flak Java gets for having ancient stuff, the old stuff in JS is way
worse.

Java cruft is better these days if you use 11+ with Lombok. Almost decent. You
can also use Kotlin which is honestly good, but unless you pay up for IntelliJ
support for it is mediocre at best. I really like Typescript's nominal typing,
wish Java chose that road.

I'm not a Python guy, but Java has Streams and RxJava which is great for
functional stuff. I'm pretty sure RxJS was originally a JS port of RxJava. The
same library has flavors in most languages now, you may be interested in the
Python version
[https://github.com/ReactiveX/RxPY](https://github.com/ReactiveX/RxPY)

Publishing to NPM registry is much easier, but everything else is worse. I
blame much of it on the lacking standard library. But JS not packaging
libraries in archives, plus using minifaction instead of a bytecode format
both suck. JS has a huge parsing problem, for some sites half the page load
time is parsing JS. VM's with an efficient code representation like C# and
Java avoid this. Java and C# package source, compiled code, and documentation
in a standardized (and efficient) way. NPM just isn't there yet.

Java is missing async await, but there's also grumbles about supporting it and
function coloring. Java has Akka, promises (CompletableFuture), parallel
streaming, and traditional threads. The problem with supporting async/await
without threads is that it doesn't solve for modern CPU's having more and more
cores. In Java/C# its trivial to use the whole machine and share structures.

You should try Vert.X, its very similar to Express. I would almost dare say
Express borrowed a lot from it.

There's some good design decisions rolling in, but still plenty of reasons I
avoid it when I can.

------
dang
See also [http://www.wirfs-brock.com/allen/posts/866](http://www.wirfs-
brock.com/allen/posts/866) for the interesting backstory to this paper.

------
garyclarke27
To appreciate the extraordinary power of modern Javascript, I think one must
also be proficient in HTML/CSS/SQL. Postgresql for shared state management +
Web components for code reuse/organisation + Web Sockets = blazing performance
without the overhead of huge frameworks. I love: functional JS, Async/Await,
Generators, Template Literals - Not so keen on Clases but if this makes it
accessible to Java developers that’s good. All we need now is first classs
status on IOS/Android.

~~~
giantDinosaur
What's 'extraordinary' about 'functional js', or async, or generators, or
template literals? They seem alright. Nothing particularly extraordinary,
though. They don't change the way I really think about problems which is what
I usually classify as extraordinary.

------
jolux
Sidebar to this: does anybody know if there's a full list of all the HOPL IV
papers with links anywhere? A lot of them sound really interesting but I can't
find them.

~~~
ngcc_hk
I tried to get hold of these but seems nearly all mentioned in this web site
(in Chinese but easy to read as very light in words) are in here. Still:
[https://zhuanlan.zhihu.com/p/113124925](https://zhuanlan.zhihu.com/p/113124925)

Others are seems to be referenced but embargoed (or need membership). If you
can access it, please inform:

[https://www.conference-
publishing.com/authors.php?Event=HOPL...](https://www.conference-
publishing.com/authors.php?Event=HOPL20)

~~~
ngcc_hk
Please note as mentioned by others and me that the javascript one discussed
here has a new version

------
forgotmypw17
Very grateful ``this`` was posted. I've been working on making my project
compatible with early JS, and ``this`` is a great reference.

------
randompwd
Link is outdated. Newer version(as highlighted & linked on page) is at
[https://zenodo.org/record/3710954](https://zenodo.org/record/3710954)

Newer filename is jshopl-preprint-2020-03-13.pdf (published 14 March)

Older filename is jshopl-preprint-2020-03-11.pdf (published 12 March)

> There is a newer version of this record available.

------
ngcc_hk
There are lots of comments and no doubt JavaScript really has its problem. But
one year still I watching this and how he used mainly JavaScript to
demonstrate how to think in clojure way. It is not that bad, guys

[https://youtu.be/vK1DazRK_a0](https://youtu.be/vK1DazRK_a0) (solving problems
the clojure way by Rafal Dittwald).

------
ngcc_hk
New version:
[https://zenodo.org/record/3710954](https://zenodo.org/record/3710954)

------
frandroid
A 190 page "paper" is usually called a book...

------
endgame
Let nobody ever again say, "we'll ship it now and fix it once it's in prod".

~~~
jimbob45
It’s not like Microsoft’s culture was any better. There are stories of
engineers sleeping under their desks during the browser wars. It’s a testament
to JS that most don’t even remember Microsoft’s answer to it (Hint: it starts
with a ‘J’ and ends in “script”)

[https://en.m.wikipedia.org/wiki/JScript](https://en.m.wikipedia.org/wiki/JScript)

~~~
ComputerGuru
I’m not really sure what the point you’re trying to make with this is? JScript
was just Microsoft’s implementation of the same spec, and was _by and large_
interoperable with JavaScript in both directions.

~~~
jimbob45
Parent poster said it’s bad to ship early and buggy. However, Eich won out
over MS doing exactly that.

