
JavaScript is Good, Actually - skellertor
https://ashfurrow.com/blog/javascript-is-good-actually/
======
wruza
Semantics and configurability is what what makes a language great. JS doesn’t
have function environments, i.e. every unlexical lookup goes to global/window
and that cannot be redirected. It doesn’t have green threads (at least). There
are generators, but one cannot just yield without marking all the functions
generators too (async/await in modern terms). Stack traces are lost when
generators throw(). JS has no good introspection — you can do some Reflect,
but cannot e.g. write a module that has a function, that when called
enumerates all functions in a caller module and exports them by specific
criteria. JS can’t properly substitute objects with proxies. It can catch
simple existing key accesses, but can’t enumerate keys or arrays. There _was_
handler.enumerate, but it was deprecated. Vue, which was written by no fools I
think, cannot “app.array[3] = v” or “app.newkey = v”. It cannot dynamically
watch an entire app too, all structure has to be defined before Vue().

Other problems exist, which are just stupid (null/undefined, in/of, ===, ;,
this, etc) or minor design choices like coersion and lexical rules. But these
above are stoppers for turning JS into something great. It is now a BASIC-
level language with scoping and sugar. Yeah, you can write like that snippet
presented in an article, but you are forever stuck with doing all things by
hand, from asyncing to orm, from exporting to update scheduling. I don’t find
that great in any way, especially when that is the only semantics you have in
a browser.

~~~
slikts
The generators or async/await in JS are 'shallow' coroutines because you can
only `yield` or `await` in the direct scope of a generator or async function,
but the benefit of shallowness is that the control flow is explicit; you don't
have to consider whether a function call will suspend the calling context's
execution or not. I find the explicit clarity to outweigh the reduced power of
shallow coroutines.

As an aside, there exist green threads in JS, namely node-fibers, although
it's only a Node.js extension.

You actually can reflect on module exports and dynamically change them with
node modules; you can't do it with ES modules, but that has the significant
advantage of enabling static analysis.

Proxies absolutely can trap the property assignments you mentioned, but Vue
can't take advantage of this because Proxy can't be polyfilled in older
browsers.

As for the enumerate handler, it would only have worked with for-in loops,
which are a legacy feature. The iteration protocols used by for-of are a much
more flexible solution. It might seem silly to have both for-in and for-of
loops, but the context of the language is that it can't just go and break
older websites. Same goes for == and ===, etc. Linters come in very handy for
dealing with this.

Your criticism is better than most, which usually just point out some "wat"
moments with mis-features like implicit coercion, but you didn't really make a
case for having to do "all things by hand" in JS.

~~~
wruza
Thanks for node-fibers, that is something I missed and it looks promising,
should try it server-side at least. But I'm not sure what you mean by "reflect
on module exports", since there seems to be no way to enumerate all functions
(in node), except those exported by hand. I workarounded it via
"autoexport(module, x => eval(x))" and "// @export" tags, but it feels dirty.

I also bet that I couldn't make 'in' work for proxy with empty abstract
target, but maybe it's just me. Btw, 'in' and 'of' are two separate iterators,
one iterates array elems and the other iterates object's keys -- something
essential to metaprogramming. My whole point on in/enumerate is that it
considered legacy by someone special.

And on Vue: I didn't know that, but if Vue can't take advantage of Proxy, can
I?

~~~
slikts
eval() has no legit use case in JS, and I really don't understand what the
point of "// @export" would be. You can't reflect on module or function
scopes, but that's a feature and gives you encapsulation.

for-in is a legacy feature; due to dynamic inheritance, it's generally not
safe to use without also calling Object#hasOwnProperty() every iteration. for-
of is not for "array elems", it uses the iteration protocols that are
implemented for all built-in collection types, not just Array, and some DOM
types, and can be implemented for any user types. Protocols are a much more
flexible and clean approach to metaprogramming than overloading the for-in
looping construct would be.

You can't use Proxy if you need to target legacy browsers like IE9, and Vue
needs to, since it's about 15% of all browsers.

------
onra87
This is a lot of lines for not saying much. I was expecting much more from a
"world-class software developer"(see About section) :)

Saying that the community is more advanced in the JavaScript ecosystem than it
is in the iOS world is a nonsense to me. Don't we have more JS developers than
iOS developers ?

Moreover, saying that JS syntax is really good with tools like TypeScript is
another nonsense. You can also write Swift code and use another transpiler to
get JavaScript code from it and you would say that JS is great.

Last but not least, giving a state of the art of JS without event talking
about tools like npm, babel or webpack is like scratching only the surface of
the subject. I mean come on, JS is not only about == and === in 2018

~~~
sloxy
That's interesting because I also picked up on that: "I am a world-class
software developer living in New York’s East Village"

and I just thought, hmm, here's this guy with ~5 years of ~professional
dev(mainly with iOS) and he self qualifies himself as world class.

Looking at his bio, I see he's worked for 3 companies doing quite ordinary
things.

I would love to know what gave him the confidence/ignorance to describe
himself as such.

~~~
ZvG_Bonjwa
Oh, come on. So the guy uses some harmless exaggeration when selling himself
on his own personal website & you're taking him to programmer jail over it?

Do you frequently launch into personal attacks on authors whose articles you
disagree with?

~~~
sloxy
If a medical doctors classifies himself as world class and then posts articles
about medical matters, then my expectation would be his world class-ness is
evident.

This guy's not writing an opinion piece about which brand ketchup tastes best.
He has published an opinion piece in which he speaks authoritatively about
matters related to the domain he claims he's a world expert in.

As for the harmless exaggeration, it's not harmless. It's poison to my chosen
profession.

~~~
mkirklions
What does world class mean?

That you are good enough that people would accept your work in the United
States?

~~~
ben509
It's typically used in sports and means an athlete or team has won
championships in an international league, or a person is an Olympic athlete.

Coding is less explicitly competitive, but there is an element of competition
to it. If you were a major contributor to a project that had displaced
multiple international competitors, that'd clearly be world class. For
example, Linus is a "world-class" coder because Linux is used all over the
world and has displaced many operating systems.

------
cm2187
To me JavaScript is very similar to VBA. Based on its own merits it’s a pretty
average language with lots of design flaws. But it has a monopoly for what it
does (browser/cross platform vs ms office scripting) and most of its users
never really got a chance to solve the same problems with a better language.
And like VBA, it is probably the only language known to the bulk of it user
base (semi-amateur web designers vs ms office business users).

I care less about the performance benefits of web assembly than the fact that
it will open browser/cross platform scripting to other languages and I’d be
curious to find out if we are still talking about JavaScript in 10 years.

~~~
daliusd
Atwood's Law: any application that can be written in JavaScript, will
eventually be written in JavaScript. (2007)

I personally find all programming languages limiting in one or another way and
I use almost daily C#, Python and JS (sometimes I use other programming
languages as well).

~~~
alkonaut
> Atwood's Law: any application that can be written in JavaScript, will
> eventually be written in JavaScript. (2007)

Funny you should mention it. Excel will now support JS scripting.

~~~
Sharlin
That’s appropriate: it is also the case that any application that can be
written as an Excel spreadsheet will be (and has probably already been)
written as an Excel spreadsheet.

------
worldsayshi
Switching back to Java after having spent a long time in JavaScript land with
modern standards made me realize how great JavaScript had become.

The biggest reason for JavaScripts greatness to me is JSON. I couldn't
understand how Java developers put up with such bulky ways to deal with data.
After some time in Java land I've come back to appreciating its strengths
again though. Code completion is nice. I'm kind of hoping for more typescript
in the future.

~~~
realharo
You should try Kotlin. It solves exactly this pain point - creating classes
for data structures is very terse and easy.

You can have a one-liner class like

    
    
        class Person(val name: String, val email: String, val yearOfBirth: Int? = null)
    

Or you can make it a `data class` and get automatic `equals` and other things.

~~~
worldsayshi
Thank you for telling me. I've been hovering around this possibility since I'm
using Intellij and am the primary owner of the code. Although I'm also keen on
this code being as accessible as possible for the rest of the organisation and
few has even heard of Kotlin.

When I suggest switching to Kotlin everyone's always smiling dismissively like
"ah, you with your crazy ideas again".

Might do it though. Maybe.

~~~
ben509
Don't ask, do it. Asking is a great way to get shot down. Write something
smaller in Kotlin, then show people what it looks like. It is heavily
interoperable with Java, so you could move some of the boilerplate heavy
classes over.

------
yedava
Code spends most of its time being in production and not in development.
During that time in production, developers will leave the team, bugs will show
up, major enhancements will be made. So it is important that the codebase is
easy to reason about, easy to refactor and easy to debug.

If you take a language like Java and an IDE like Eclipse or Intellij IDEA, it
is trivial to find from where a particular piece of code is called from.
Whereas in JavaScript, particularly in huge codebases, you can't easily tell
how a piece of code ends up getting called. You will need to run the code,
make some educated guesses and put breakpoints or console.log statements to
verify that yes, this particular line does end up getting called on this
particular action.

Refactoring is also a joy in a language like Java. You can easily modify a
method signature and the IDE will take care of updating all the places this
method is called from. Now imagine you add a new argument to your JavaScript
function and want to update all the places where the function is called from.

So judging JavaScript on these factors, it isn't such a good language.

~~~
mistercow
You can always cherrypick advantages and disadvantages to make a language look
"bad", or make another language look "better".

~~~
gameswithgo
what can you cherry pick from javascript to make it look good?

~~~
hajile
Comparing with Java or popular languages like those at the top of tiobe?

Lambdas, First class functions, and closures are a great feature missing in
basically every other popular language (things like Javas lambdas or function
pointers aren't even close in real world use).

Proper tail calls is another feature missing from that list and despite some
browsers refusing to honor the spec they ratified, it's still implemented in
Safari/javascriptCore, XS6, duktape, node 6-7, etc.

The interplay between js dynamic objects and closures is difficult to
describe, but a thing of beauty when fully understood. Object literals are
also basically unique to js on that list as well.

There's a lot to love about most languages and JS is no exception.

------
icc97
Personally what I love about JavaScript is that it brought the basics of
functional programming to the masses.

Obviously it's far from pure FP, but I think it's much more at the heart of JS
than it is say Python. The Scheme parts of JS are the good parts.

I think some of the resurgence of FP is down to JS. The wealth of libraries
available is pretty impressive [0]

[0]: [https://github.com/stoeffel/awesome-fp-
js](https://github.com/stoeffel/awesome-fp-js)

~~~
JepZ
Seeing JS as a functional programming language is actually the way of learning
how to use it properly.

------
peterbraden
Oh man, I hate these articles as they bring out the trolls.

Javascript is a great language because it allows you to develop incredibly
fast (scripting language) for a platform that runs everywhere (the web).

It used to be far simpler, but IMHO, insecurity because of all of the FUD that
this sort of article prescribes, has meant that the language has bloated to
incorporate all sorts of syntax improvements and new patterns.

It's not a systems programming language, so all the comparisons against typed,
compiled languages are moot. Introducing transpiling as a mandatory pattern
for JS development was a mistake.

The reason JS has won is because the web has won. Arguing about its merits
misses the point.

~~~
macspoofing
>It's not a systems programming language, so all the comparisons against
typed, compiled languages are moot.

No they are not 'moot'. At least not if you're building applications with
100k+ LOC. For dinky websites and small projects I'm with you.

>Introducing transpiling as a mandatory pattern for JS development was a
mistake.

Again, what are you building? A dinky website, or a large application that
you'll have to maintain for the next 10 years?

~~~
hungerstrike
No, they are moot. I've built several 100k+ LOC apps with JavaScript. You have
no clue what you're talking about.

~~~
Sharlin
How many of them have you had to maintain for several years?

~~~
hungerstrike
Three of them.

------
kuon
I have been working with elm for 2 years now and shipped 4 projects.

I can say a lot of good thing about elm, but the most important one, and
something that outweight a lot of thing is maintainability. Each time I had to
change something in a shipped app it was painless, stressless (I know I won't
add regression) and fast.

I won't say JS is bad, but the absence of a compiler makes it much more
fragile, especially when working on old code.

~~~
bgorman
Almost everyone writing JavaScript these days uses a compiler like Babel,
webpack, browserfy etc..

~~~
alangpierce
I think by "compiler", they really mean "typechecker", which is much more
important for maintainability than code transformations.

JavaScript does has two good typecheckers, TypeScript and Flow.

~~~
kuon
I worked with typescript for a project, but the compiler don't help a lot
compared to the elm compiler.

------
dpwm
I'm an outsider to the JS world but find it absolutely fascinating the
direction the language has taken. It's clear that a lot of the new language
features enable more concise functional programming. I see this as a good
thing.

I'm really surprised that whilst the language on the one hand gives nice tools
like the object spread syntax, the last time I checked it didn't make it easy
to make the interpreter enforce immutability.

It seems strange to me that the language evolves in this way to recognise
foot-guns but doesn't give you the tools to turn them off. Object.freeze
looked like it would do the trick, but it's shallow. Freezing doesn't survive
the spread syntax, which makes perfect sense because it freezes the original
object, and of course the whole point of immutable objects is to create a new
object.

It feels like you're able to program in this style, but the language designers
didn't really consider it very much and were just introducing the syntax to be
consistent with the other spread syntax.

~~~
sibeliuss
Again, tooling: [https://github.com/jhusain/eslint-plugin-
immutable](https://github.com/jhusain/eslint-plugin-immutable)

------
simula67
> But here’s the thing: every language is weird

I recommend that you read :
[https://www.lesswrong.com/posts/dLJv2CoRCgeC2mPgj/the-
fallac...](https://www.lesswrong.com/posts/dLJv2CoRCgeC2mPgj/the-fallacy-of-
gray)

------
themacguffinman
I don't mind ES6+ syntax. I'd even say that the syntax alone makes for a
pretty great developer experience, but I still wouldn't say it's a great
language altogether.

I think a fundamental problem with the language is that it's not particularly
memory-efficient, and it's hard to make it memory-efficient. The V8 team has
done a lot to make it better but they are still limited by the design of the
language.

That's particularly painful in mobile where memory is constrained, and on the
desktop it's making the typical 4 - 8GB of RAM less and less sufficient.
That's important when discussing why Javascript is still an issue when using
stuff like Electron and React Native.

~~~
roman_g
One of the richest companies in the world with very good engineers made a
supercomplex engine which nobody understands and looks like they cannot make
it better and we use it happily as given - something's wrong here.

~~~
kevindqc
I don't understand what's wrong? People use software without knowing how it's
coded under the hood all the time? The V8 code is here if you want:
[https://github.com/v8/v8](https://github.com/v8/v8)

------
sgentle
I don't think anyone benefits from watering down the definition of "good" to
the point where it describes Javascript. Javascript – sorry, modern Javascript
– sorry, surfing a compile-to-JS liferaft atop a thick and constantly shifting
foam of tooling and libraries disgorged by literal person-millennia of
community effort – can be surprisingly decent if you're careful.

Any meaningful definition of good has to draw a line between things that are
and things that aren't. The definition here is broad enough to include
basically any language that is popular. C++ is also good because it has a good
syntax for the things people use C++ for, a big community that builds tools
for it, and it has quirks but come on every language has quirks.

"Just because you disagree with the decisions doesn't make the language bad"
is a funny way of describing absolute bald-faced mistakes like typeof null ==
'object', the baggage of 20 years of browser quirks (JS tristate logic: true,
false, and document.all), and "no that was totally intentional minimalism"
oversights like the lack of coherent collections and iteration primitives.

When I think about good, I think about Rust's memory model, Erlang/OTP's
supervisor trees, Java's standard library, Clojure's immutable data
structures, Python's syntax, .NET's LINQ, Haskell's type system, Idris's type
system, Go's mascot, or Elm's delightful mix of programming language and solo
performance art piece.

Despite the author's attempt to head this criticism off, the reason we use
Javascript really is just because it's in the web browsers. Web developers had
to use it, so we made the best of it. We wrote libraries and tools to make it
bearable, we built new languages on top of it so we didn't have to deal with
its bullshit, and once Ballmer quit ruining the internet we built those
improvements back into the language itself.

But is that _good_? Layers upon layers of accreted improvements, each with
more legacy carve-outs than the last? "We can never throw away a bad idea" is
a one-way complexity ratchet that precludes unqualified goodness unless there
were no bad ideas to begin with. With Javascript, that is not the case. The
best it will ever achieve is that it has good parts.

If INTERCAL was the de facto language of the web, we'd be writing Medium posts
about the benefits of Automatic PLEASE Insertion and how excited we are for
ASYNC COME FROM to land in INTERCAL2018. And, hey, it's not perfect, but it
gets the job done, there's a good community, and at least it's not Objective
Malbolge. Who are we to criticise?

~~~
wruza
>how excited we are for ASYNC COME FROM to land in INTERCAL2018. And, hey,
it's not perfect, but it gets the job done, there's a good community, and at
least it's not Objective Malbolge.

That made my day and next few mornings, thank you.

------
tannhaeuser
I think it's useful to differentiate between JavaScript the classic language
for adding limited interactive behaviours to otherwise static Web pages and
JavaScript the language for full-blown MVw web apps and JavaScript the
ubiquitous portable script language.

For the first and third use case, really not much has changed since ES3/ES5:
if you want portable JavaScript and appreciate simple "press reload button"
workflows without babel or other complex transpilation steps, then ES6+
features don't add any essential capability, and I tend to avoid them.

If OTOH you really need to develop SPAs with massive code bases and third-
party libs, then ES6 and in particular ES7 with async/await is a big win.

But I can't help wondering if the tension between these language profiles is
going to work well for JavaScript in the long run. IMHO for full-blown apps
there are much better alternative back-end languages available, and in any
massive ES6 code base I've come across the desire to introduce types and type
metadata is very much noticable (Angular and Typescript come to mind).

------
fefe23
I think we have a case of Stockholm Syndrome here.

He claims on one hand that Javascript is great and then cites the awesome
tooling like Typescript. Well, a great language would not need Typescript, now
would it?

I think the most obviously damning thing about Javascript is how the rest of
the world bends over backwards and speaks JSON now because it's less trouble
if we adapt to JS than if we adapt JS.

Well, yeah, if you change the problem to fit your programming language better,
then your programming language will feel convenient and like it always fits
well. Duh.

~~~
adjkant
I don't think JSON is a signifier of that - we had XML before and you're
always going to need plain text types of files like that. Python also plays
well with JSON. It's just Java/C++ types that don't play easily with JSON
unless you want a lot of translation and processing.

That said, I agree with the rest of the points. I do love JSON though.

------
ajeet_dhaliwal
My developer friends do have opinions on JavaScript that are in my view
outdated, modern JavaScript is my favorite peogramming language due to the
ease of expressivenesss and joy to write it. I started out with C, C++, Java,
Objective-C and C# before ever seriously using JavaScript (other than tiny
snippets of front end browser dom manipulation) and may be I’m just getting
old but... I’d love to use JavaScript for everything if I could.

~~~
atomicnumber1
I find swift and python to be more elegant in terms of expressiveness. Only
issue with swift is that it's ABI isn't stable yet and still not official
support for windows (I think, will need to check this).

~~~
WorldMaker
At this point the only thing I feel like I'm left missing from Python in
semicolon-free ES2015+/Typescript are list/generator-comprehension syntax [0]
and slice notation [1].

[0] The Pipeline Operator Stage 1 proposal is currently the closest proposal
to making something like that happen: [https://github.com/tc39/proposal-
pipeline-operator](https://github.com/tc39/proposal-pipeline-operator)

[1] Stage 1 Proposal: [https://github.com/gsathya/proposal-slice-
notation/](https://github.com/gsathya/proposal-slice-notation/)

------
analognoise
This post even argues against the very idea that JavaScript is any good.

{Garbage code example} "Syntax is just syntax". "Tool writers are neutral,
then get to work fixing this terrible language".

Really?

~~~
rootlocus
Regarding the same code example

> You may have noticed that the code above isn’t even JavaScript, it’s
> TypeScript, which brings me to my next point.

Which kind of invalidates the entire premise of the article.

~~~
the_duke
Not really, Typescript is mostly a superset of ES2015 and is compatible syntax
wise.

It has almost no new "features" (apart from enums and namespaces, I think) and
only contains a typing + visibility system and related syntax on top.

The only part that is not ES2015 in the given code example is the ' as
ConsignmentSetup' cast.

~~~
repolfx
By that definition C++ and C are the same languages. But everyone knows they
aren't. And both C/C++ are statically typed languages! You can't just drop a
static type system into a scripting language and claim it's an irrelevant
difference!

I agree with the other posters - there are probably good defences of
JavaScript that can be written, but writing an article about how great
JavaScript is and then showing a code sample from a different language just
reinforces the idea that JavaScript developers probably don't have much
experience with other kinds of programming.

------
Grue3
When someone makes a statement like this, it raises the question: compared to
what? What other languages does the author have experience in to proclaim that
Javascript is good?

Also I never seen anyone complain about Electron apps because of the language
they're written in. The main complaint is that it's a tremendous waste of
computer resources. If your chat app needs more than 1gb of RAM, I don't care
what language it's written it, it sucks period.

------
hardwaresofton
I think javascript shines only depending on which languages you compare it to,
and what you're doing with it.

Also JS + Typescript is a force to be reckoned with (the added safety is
great), and once a multi-threaded runtime like Chakra[0] takes shape, it'll be
even better. JS's early introduction of concurrency primitives (callbacks,
futures/deferreds, promises) will make javsacript developers much productive
much faster than the equivalent ruby/python 2 developer with not as much early
exposure to managing concurrency.

~~~
Clubber
Typescript is the only reason I would consider Javascript "good." Without the
type safety and the refactoring tools that type safety makes possible,
applications may be easy to write initially, but unbearably difficult and time
consuming (read expensive) to refactor and maintain an application of even
basic to moderate complexity.

~~~
hardwaresofton
What about:

\- easy accessibility of higher order functions (AKA functions as a first
class object from the get go)

\- graceful inclusion/addition of concurrency-handling functionality despite
the language being single threaded (this might be much more to do with the
context javascript was to be used in)

I agree with your sentiments on the value of type systems and compile-time
type checking, but so many languages are in the same boat as JS in this regard
-- it even applies to a bunch of lisp dialects (CL does have the `declare`
form), and not many could consider lisp a "bad" language.

~~~
zaarn
1\. We've had higher order functions since 1960s, it's not a new discovery
that is singular to JS, that award goes to LISP and Scheme.

2\. Concurrent execution has also been introduced in the 1960s (Dijkstra
1965), Ada and Erlang supported that behaviour since the 80s.

3\. LISP has a type system and basically any LISP runtime will yell at you for
comparing strings with numbers just like that. SBCL can do this check at
compile time even.

Additionally LISP lets you add a type system on top using macros and other
tricks (some going as far as implementing a Haskell-like typesystem in LISP).

~~~
hardwaresofton
> 1\. We've had higher order functions since 1960s, it's not a new discovery
> that is singular to JS, that award goes to LISP and Scheme.

My point wasn't that javascript invented higher order functions, it was that
making them first class isn't something all languages have chosen to do, and
is clearly a good choice.

> 2\. Concurrent execution has also been introduced in the 1960s (Dijkstra
> 1965), Ada and Erlang supported that behaviour since the 80s.

My point was not that concurrent execution was somehow invented by javascript,
that would be an asinine claim. My point was that javascript has done
surprisingly well to introduce these concepts to it's users (perhaps out of
necessity given the runtime environment it's in), whereas concurrent
programming is considered an advanced concept in other languages and isn't
taught till very late if not at all.

> 3\. LISP has a type system and basically any LISP runtime will yell at you
> for comparing strings with numbers just like that. SBCL can do this check at
> compile time even.

this depends on the dialect of lisp you're using. SBCL will certainly do basic
type checking and even advanced if you make use of `declare`. I'm not sure
what I implied that would make you think I am crediting javascript with
inventing type systems (?). I know lisp is great -- that's why I mentioned it
as a language people highly regard, but is not compile-time typechecked
depending on the dialect you're using, but people wouldn't say that makes it a
bad lanaguage.

It's like you read my comment and decided that I said javascript was the best
language ever invented. My point was that it's made some choices with some
good outcomes. Java as a language consciously chose not to have first class
functions for the longest time (1.1 to 1.8 IIRC), yet people from Java will
continuously bash JS as being the worst language they've ever seen.

~~~
pjmlp
> people from Java Java will continuously bash JS as being the worst language
> they've ever seen.

Rightfully so.

What positive things can we say about a programming language where this is
valid code?

[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!!)

Just a snippet, more fun can be had at
[http://www.jsfuck.com/](http://www.jsfuck.com/)

Or the community tradition of writing one liners as npm packages?

~~~
hardwaresofton
> What positive things can we say about a programming language where this is
> valid code?

Just because it parses doesn't mean anyone would ever write it in a serious
project.

Also, I've seen worse in Java (AbstractSingletonProxyFactoryBean), the only
difference being that someone wrote the code with good intentions -- not as a
joke. "Idiomatic" Java code is often bloated, and people who write it have
been trained to defend the bloat until their dying breath.

> Or the community tradition of writing one liners as npm packages?

I'd pick npm over the hellscape that is maven +/\- gradle and managing the
class path anyday.

I honestly think in about 5~10 years, something like Golang is going to be
more common at most forward thinking companies than Java, with or without
generics.

~~~
pjmlp
Go is good as better C replacement for all use cases still being written in C
that could actually be done safely in a GC enabled language, as they aren't
targeting stuff like 16KB PICs.

For anything else, we have seen the future.

------
martin_drapeau
I forgive Javascript any "language flaws" it might have. Why? Because the
truly beautiful thing about Javascript is that you can write a program, send
anyone a URL and they can run it. No compilation, no installation - just open
the URL in any browser. No other language in the world can do this in such a
universal way. Simplicity is bliss.

~~~
dsego
Yeah, because people usually compile their programs before running them.

~~~
kbp
> Yeah, because people usually compile their programs before running them.

The developers do, yes; with Javascript, they don't have to worry about
compiling for multiple platforms like, say, a C developer would, they could
even just ssh into a server and edit a single text file while everybody across
Windows/Linux/MacOS/iOS/Android/etc can run the new version as soon as you
save the file (mod browser compatibility issues, of course). I think their
point was that Javascript is the only language that can do _end-to-end_
simplicity like that.

------
maga
As a long time JS dev I don't claim expertise in other languages, but every
time I go back to check out new features in C++ or Java they feel more and
more like JavaScript with types than "C with classes".

~~~
paulhilbert
Actually C++ these days is moving more towards strong typing and immutability
- imho the exact opposite of JavaScript...

~~~
johannes1234321
Due to auto and templates large parts of the strong typing can be moved to the
compiler. When writing modern C++ one can be quite fast (not as fast as
JavaScript) but get some verification, by the compiler, which fastens
development time (i.e. typos in identifiers are located easily, whereas in JS
you need to run the tests and then have to find the root cause)

------
vinayms
I am primarily a C++ dev and had to use JS for web development. Having no
previous scripting experience, I was gobsmacked at the ease and freedom it
offered, especially wrt string processing. You need to have been a monolingual
C++ dev to appreciate what I said.

I don't hesitate to say I like JS. These days I try creating any small
experimental programs I need in JS and run them in FF instead of starting the
whole build process with C++ code. If there is file i/o needed, I use an
extention that I have created for this purpose. When necessary, converting
this prototype into C++ code is not a big deal.

As for its flaws, well, which language doesn't have flaws. Part of being an
experienced dev is to learn, respect and avoid the shortcomings of the
technology you use, aka paying attention. Its arguable that some flaws in some
systems are worse than some flaws in other systems since the design factor
comes into play, but with something as pervasive and monopolistic as JS, there
is a clear choice to be made - create something better for the community or
shut up and live with it. I am sort of doing both. (To pull off the first one,
I need some serious credeitials, which I hopefully earn in the near future.)

~~~
spdionis
Why not use node so you can avoid the browser and the extension?

~~~
vinayms
Because there is usually a need to input data or parameters and I prefer a GUI
textbox more than file based or command based approach. I also prefer visual
inspection and debugging. Browsers make all this simpler.

~~~
hajile
Consider bootstrapping a simple Electron instance. You get the whole browser,
but you get the great node stuff too.

[https://electronjs.org/](https://electronjs.org/)

~~~
vinayms
May be I will try it when writing full fledged server side node code, but as
of now a browser suffices for what I want.

------
marsrover
> I’m not going into more detail because syntax is… well it’s not that
> important to a language. Syntax is (I’m waving my hand dismissively here)
> just syntax

Tell that to Brainfuck.

Sure, JavaScript is a great language if you ignore all the shitty parts.

------
adjkant
I see a lot of people that are pro-JS are coming from Java/C++:

Re the Javascript advantages of JSON and quick writing: Python! It too has its
flaws, but so many fewer and writing in it is a breeze. Python 3 is only
getting better to, so if you do start, take the time to start in 3, not 2.

Javascript is indeed pushing more function programming type stuff, but if you
really want that, go with a Lisp/Scheme or Haskell IMO. It's simply what I've
been exposed to, but Racket is a great language for quick little programs. You
can also go functional in Python easily enough as well.

------
qaq
JS is ok, TypeScript is pretty good. Still I would rather use say Elixir for a
large project on the backend, but for a small project node is not a bad
option.

------
btbuildem
The great thing about JS is how accessible it is. A child can start tinkering
with it and build stuff.

The problem is, the children did do it, skipped going to school to learn the
basics, and now we see clearly reflected in the evolution of the ecosystem
their efforts to slowly re-discover and re-invent everything.

------
hn0
Forced OOP model [1], lack of types, highly redundant syntax (ES6 whyyyy).
After years I’m still fighting with the language, not to mention the browser
with it’s frankensteinian api.

Browsers should have just created a Lua dialect, which is like a more sane
version of JS, and throw JS back into the nineties-fads hellscape that spawned
it. Perhaps in an alternate dimension Eich will have done a non experimental
port of Scheme or would just have done WASM from the start. I’m pretty sure at
least there every PC would just boot into Netscape by now.

It’s true that the infrastructure around JS has gotten a lot better, but
that’s _despite_ the language. If anything I should thank it for popularizing
FP which will hopefully eventually slay the chimera that is OOP.

[1] Or, more specifically, “POOP” to emphasise its prototypical nature.

------
dandare
> equality in JavaScript is a bit bizarre

That flux capacitor diagram is super interesting but I think it is missing a
point. The bizarre equality happens due to truthy and falsy evaluation, which
is a very practical concept that saves you a lot of time when you actually
want to get shit done.

------
blauditore
The fact that the author omits semicolons in JS somehow fits the theme of this
post...

~~~
cesarb
There is a school of thought that semicolons in JavaScript should be omitted
except where they can't:
[https://github.com/standard/standard/blob/master/RULES.md#se...](https://github.com/standard/standard/blob/master/RULES.md#semicolons)

~~~
blauditore
I'm well aware of "Standard"JS, and it's highly controversial to put it
mildly.

The fact it was named "standard" is quite infuriating, as it's just a bunch of
random people churning out an arbitrary set of formatting rules. This is not
how standards are acquired. Now, many devs unfamiliar with JS use it because
they google "javascript standard formatting" and obviously find this.

------
eptcyka
> JavaScript is good, actually. If you use Flow and Typescript which are not
> Javascript.

That's like saying that Java is good, actually, if you use Kotlin. But not
really, because the UX of using Kotlin is 100x nicer than using transpilers.

------
kapv89
For me, as a founder of a young startup, the overarching benefit of being
proficient in modern JS and sorrounding tooling is that I can use the same
language for my whole stack(servers, web, Android, iOS), and spend more time
thinking about the product and business. In the possible future where the
company grows enough where it needs a distributed server software, the only
part of the product that'd be changing would be the backend, and I'd probably
look at Java for that. For the rest, React(& react-native) + graphql + a
typesystem is a pretty good stack for UI software.

------
Blackstone4
JavaScript has continuously evolved and probably at a faster pace than many
other languages. I'd interested to see whether those who used ES5 and didn't
have a good experience, would enjoy using ES7 with async/await.

The JavaScript ecosystem is large and this question can be broken down into:

\- Is JavaScript good on the browser for the front-end work?

\- Is JavaScript good on the server?

Also for those interested, I create a Poll HN: favorite web server language
and front-end submission over here:

[https://news.ycombinator.com/item?id=17081114](https://news.ycombinator.com/item?id=17081114)

------
partycoder
A programming language where almost everything is mutable is by design not
good.

JavaScript is popular because the learning curve is low and it was good enough
for the web. Otherwise it is pretty mediocre even when just compared to
scripting languages.

Then, the "about" page of that blog is very concerning: "I am a world-class
software developer". A world-class software developer would be people like
John Carmack, Linus Torvalds or Dennis Ritchie.

~~~
alephnan
> A programming language where almost everything is mutable is not good.

That's a weird criticism. Object-oriented programmers are premised on
mutation. As for JavaScript itself, mutations can be avoided. 'const' to
prevent reassignment, using Object.freeze, or just applying functional
programming principles and keeping functions pure.

~~~
rootlocus
> Object-oriented programmers are premised on mutation

I'm a Java OOP developer, and I make everything I can immutable. It's a design
decision adopted by most of my colleagues.

~~~
rpastuszak
Good point. The same practices are common in JS. Arguably, point free style,
currying, functional composition, etc... are easier to achieve in JS (esp.
with types). I do enjoy writing java in somewhat functional way, and have seen
badly written OOP Scala (mostly by developers, who just started experimenting
with FP), and I think it’s difficult to discuss a language without the broader
context of its common practices/developer culture/discourse around it.

~~~
partycoder
Immutable objects are not common in JS. You can conceptually treat them as
immutable, but they are mutable, because their base type is mutable and by
extension everything is mutable.

~~~
williamxd3
At least there is Immutable.js

------
skywhopper
I never felt the author got around to describing what makes Javascript good. I
mean, hey, it's indisputable that lots of people love it, and it's fine to
write up an article defending its quirks. But the existence of good tools, an
OSS community, and reasons for the quirks don't sum up to a reason to try
Javascript. I was hoping for some more insight into the language itself, but
that was never touched on.

------
xntrk
I would have liked to have seen some comparisons. Showing javascript syntax
but then not showing anything else and then saying its good is not really an
argument.

And aren't frontend dev essentially forced to use javascript since we can't
compile to anything else at the current time? _yes webasm is coming_ and yes
there are languages that compile to js

------
ianamartin
This article’s reasoning seems really confused to me.

He seems to be saying, “Hey, this ting that everyone calls a shit sandwich
isn’t really a shit sandwich. Let me tell you why.

I go to this nice restaurant and eat things that are not shit sandwiches. And
they are fantastic. But they all end up as shit eventually, so it does t
matter. Therefore JavaScript is not a shit sandwich.”

------
zaarn
The syntax example didn't look any different to what I'd see in modern Java,
C#, Go, Rust, LISP, etc. The syntax can make or break the language for some
(Rust for me) but in the end, if you sit down and look at it, most languages
in use today will be similarly easy to read (except Haskell).

It's not better that the example isn't even JS itself but rather the only JS
dialect I don't refuse to work with since it has a type system that is more
solid than wet tissue paper.

As the author themself admit, syntax is not important, so why bring it up?
That genuinely seems like a way to A) bring up the argument and B) in case
anyone refutes the argument being able to simply say "well it didn't matter
anyway".

\---

Toolchains are another bad point. VSCode doesn't only exist for JS, it has
support for other languages as well and I very rarely make use of it as JS
IDE.

If I need a third-party toolchain to fix up the most basic mistakes of the
language's design I don't think the language under that mess will be terribly
good.

Other languages don't require an entire toolchain to provide a minimum of
coding safety.

People agree that writing in C is something hard and dangerous, it also needs
an entire toolchain to achieve a minimum of "not segfaulting on startup".

I should be able to simply take the first party language tools and use those
to get to a point where my application starts and the correctness of my code
not being coerced to false.

\---

While it is indeed commendable that JS has such a big community, I think the
community still has lessons to learn. The churn in the ecosystem is beyond
fantastical levels, not in a good way.

When I pull in sqlite3 for my project I can be reasonably sure that this
project will be maintained for the next 20 decades and I will be able to use
sqlite3 in 20 decades without much problem.

With JS dependencies I will always ask myself subconsciously if they're going
to be maintained next _week_.

I don't write software that runs for next week, software I write is intended
to function for the next 20 decades. Of course it'll get patched and
maintained but I don't want to switch out my underlying framework because
Google decided that their JS code has become too boring after 4 months of
work.

The GraphQL examples is just an example of this. The tech is barely 5 years
old, the tooling in all languages other than JS was extremely immature last I
checked. Why should I bet on something like that to work and be maintained in
20 years?

\---

I'm getting a bit rant-y but I'll take this last paragraph to disagree with
the conclusion too. Most languages have some bad design. Usually that is fixed
in the language or by first party tooling. That's not my problem with JS.

My problem with JS is that the moment I write JS I have to involve myself with
the community of JS, a community that has laughed (!) and scoffed (!) at me
for suggesting that I want to maintain software for a long time beyond
$CURRENT_YEAR.

The ecosystem and community of JS are rotten and flawed, that's why I don't
use JS where I possibly can and if I do it's vanilla browser JS pushed through
the minimum installation of typescript I can get away with.

------
tannhaeuser
It just struck me that TFA is published exactly ten years after Douglas
Crockford's "JavaScript - The Good Parts".

------
api
JavaScript is IMHO not a bad dynamic language, especially for rapid
development of typical web, UI, glue, and scripting stuff... in other words
most of what you use dynamic languages for.

We are moving to Go for our backend because dynamic languages don't scale with
complexity or team size, but that's another matter.

------
edem
This is very relative. If you compare it to Cobol, then yeah, it is good! If
you compare it to Kotlin or Clojure? Not so much. See, everything depends on
your viewpoint and your viewpoint depends on what you know. If you only know
javascript than it may be good.

------
snarfy
What's old is new again. Electron feels very much like the old gui systems
like ToolBook, VB6, and other 'RAD' tools. It's not so much about the language
as all the 'batteries included' toys that come with it.

~~~
proginthebox
except that the old gui system ran on 650Mhz processors and 256MB RAM.

~~~
lghh
And took forever to write and were hard to change.

~~~
Volt
VB6? Really?

------
holstvoogd
TL;DR: JS is great if you like it and know it well!

I'd say that holds for pretty much any language. The blog starts with an
example to show how clear and concise etc the syntax is. I, personally, find
the syntax unclear, verbose and I have no clue what that code does at a
glance.

But I guess that is actually the crux of it: if you enjoy Js and are
productive with it, great! Just don't ask me to work on your code, I'd make a
mess :)

------
bytematic
Javascript is fine for projects of small to medium size, as is any scripting
language.

------
AndrewSChapman
I also wouldn't call JavaScript great. It's adequate and tolerable. Typescript
makes it better. Languages I'd call great include: Kotlin, C# and D.

------
luord
I agree with the general idea and I like js... But don't like electron or jsx
because they're wasteful and too much of a mix of stuff, respectively.

------
EtienneK
JavaScript is Good, but TypeScript is better.

------
quantumofmalice
Javascript is the Chauncey Gardiner of programming languages.

It was there.

------
gaius
This is the argument that x86 must be a great ISA because look at all the
tools people have written so that they don’t need to deal with it directly!

------
megaman22
No, it is bad. It is a pox on software development that we've had to fight for
two decades just to get back to where we were. Everytime I see _new innovative
thing_ that is a retread of 1980s unix development, I die a little inside.

------
interdrift
Almost puked a little in my mouth

