
The JavaScript phenomenon is a mass psychosis - dbalan
https://medium.com/@richardeng/the-javascript-phenomenon-is-a-mass-psychosis-57adebb09359#.efr6s0vle
======
taco_emoji
> I’ve been writing web applications for over a decade and it’s utterly
> shocking how little JavaScript I know!

I'm glad he admits this, but then what exactly makes him qualified to opine on
the language?

Look, Javascript is not great, and I'm perfectly open to the thesis that
Node.js in particular is a Bad Thing -- I'm C# junkie, for crying out loud --
but supporting that thesis with a series of assertions from someone with
little relevant knowledge is not terribly convincing.

~~~
voidr
> I'm glad he admits this, but then what exactly makes him qualified to opine
> on the language?

The fact that he has been using the language for a decade.

> Look, Javascript is not great, and I'm perfectly open to the thesis that
> Node.js in particular is a Bad Thing -- I'm C# junkie, for crying out loud
> -- but supporting that thesis with a series of assertions from someone with
> little relevant knowledge is not terribly convincing.

Why are you so worried about the person who states the argument? If he would
claim that he is an expert who knows everything, would you just automatically
believe him?

I personally would verify his claims regardless of who he is. If you just
watch the referenced video, you might get an idea of where he is coming from.

------
yamalight
> As most people well know, all programming languages have their faults. ...
> However, JavaScript is especially bad.

> I’ve been writing web applications for over a decade and it’s utterly
> shocking how little JavaScript I know!

I've noticed that most people slamming js either have zero or very little
knowledge of the language itself as well as environments it works in. Maybe,
just maybe, it's worth learning a bit more about how and - more importantly -
when js works.

~~~
sli
I can only speak for myself, but I practically never run into any of those
popular Javascript "gotchas" after using the language for so long. I've fallen
into plenty of PHP traps, they tend to be a lot more subtle (especially that
older one where a missing quote would error on the next line containing a
quote), but JS's tend to be pretty avoidable, even in larger apps.

------
inputcoffee
Theory: Javascript is bad not because of its syntax but because front-
end/back-end is a new way of coding on the web and we have to redesign a lot
of things (Json format, API, etc) in order to figure out the best way for it
to work.

I am not saying I don't hate the syntax as much as the next person, but syntax
is only so annoying.

The real issues come up with, for instance, execution contexts, callbacks etc
because they are created for this new environment we find ourselves in.

(For those who say: hey, we have had client-servers for years, and we didn't
face these issues, I think we have to start pointing to actual code, the
problems, and the attempted solutions.)

~~~
smt88
I actually like JS syntax. It's pretty bland and, with const/let block scoping
+ await/async, it's easy to understand.

What sucks about JS is its lack of a type system, type coercion, and lack of a
standard library. And those things really, _really_ suck (and lead to terrible
code). There's a reason MS, Google, and FB have all moved to static-typed JS
(TypeScript, TypeScript, and Flow, respectively).

~~~
inputcoffee
Well, the syntax has this one issue that I just cannot forgive: multiple
exceptions to rules.

Like why should a beginner have to figure out when the semi-colon is optional,
required, and to be avoided?

For anyone who says it is easy and then launches into an explanation, please
compare your explanation to that in, say, Java and realize the error of your
ways.

~~~
maw
When are semicolons to be avoided in JS? I assume daft styleguides pushed by
people desperate to show how smart they are don't count.

I agree with your broader point, of course; certainly making them optional
hasn't helped matters.

~~~
sli
I don't know of a single instance where it's advised to omit a semicolon, nor
one where a semicolon is strictly required. They are always optional. About
all I've seen is Standard's guideline to put a semicolon before your entry
point closure:

    
    
        ;(function() {
            // .. snip
        })()
    

And even that isn't required, it's just a function of another guideline:
"Never start a line with (, [, or `." But still, that is only relevant to
Standard, not to Javascript in general. It's completely self-enforced by
deciding to use Standard if you want. I can't remember ever needing to put one
of those characters at the start of a line outside that particular instance,
anyway.

~~~
maw
I think the reason was to work around too simplistic minifiers and
concatenators.

------
megous
Someone who knows little JS writes a few bad words about it, without much
detail, and provides alternatives he knows. He also attributes the fact other
people don't write in languages he knows, to psychosis, despite not being a
psychologist.

------
mcphage
Um... what's with the NSFW picture at the top of the article?

~~~
duwease
Seriously. I'd like to share this, but with that picture attached it limits my
ability.

------
drinchev
JS still puts the bread on my table. Not the perfect solution, but it is in
high demand.

FE:

I'm surprised the OP didn't mention Elm [1]. Elm is not ( maybe yet ) popular
enough for production uses ( at least outside of Silicon Valley ) and the
better alternatives ( TypeScript, Flow ) are actually JS with sugar.

Frameworks

BE:

NodeJS is much more than JavaScript itself. It is quite easy and cost-
effective. Because of NodeJS we have "full-stack developers" again ( I'm
coming from Perl CGI Scripts - when everyone was "full-stack" back then ).

Go is super strict about it's formatting, so you practically have ES/JSLint in
the compiler itself. I don't see a big problem in this sense.

> I won’t regurgitate the web only to say that a simple Google search will
> reveal JavaScript’s many internal inconsistencies and traps that literally
> make JavaScript a “digital minefield.”

Sorry, but I know the JS traps and I'm pretty well paid, because of that. I am
not in psychosis and I love what

1: [http://elm-lang.org/examples/hello-html](http://elm-
lang.org/examples/hello-html)

~~~
k__
Same here.

    
    
        - Servers? Node.js
        - Web apps? Browsers
        - Cross-platform desktop apps? Electron
        - Cross-platform mobile apps? React-Native
    

Will it deliver the best possible solutions (performance, size, etc.)?
Probably not.

Will it deliver economically acceptable solutions? I think so.

Most of my customers don't even care which language I use, they just want
their app idea implemented somehow. And many react positively when I say
JavaScript, because they know a bunch of people developing in it, so when I
get hit by a meteor, they don't have to find one of those rare Qt C++ gurus.

~~~
swah
Is your motivation for writing backend code in Node.js code sharing or just
avoiding the mental burden of changing languages?

~~~
k__
A bit of both.

I seldom write my own libraries I could share, but I use many 3rd party
libraries on client and server.

So using the same language AND the same libraries helps a lot to minimise "the
mental burden" of developing in general.

------
padseeker
I disagree with the premise of the article. Javascript is what it is. I think
at least most JS developers recognize that.

We use javascript because it does what no other programming language can do
which is make the browser come alive. And we're done our best to minimize the
displeasure of using javascript. I am not thrilled with the language, but I'm
enthralled by what javascript can do.

To paraphrase Douglas Crockford unless you are going to revive Java applets
you don't really have a choice if you want a dynamic web app.

The move to Node.js is a double edged sword. I like using Ruby on Rails and
adding enough javascript to make the app more pleasant to use without
constantly requiring a page reload. But the advantage of writing code on the
server and the client in the same language is hard to pass up on. Trying to
decide what to put which logic on the server versus on the client is a
perpetual stress point.

------
apeace
While I agree there is some level of mass psychosis surrounding JavaScript, I
think there is a lot more nuance to what's going on.

I don't think the onslaught of new frameworks and transpilers has been due to
JavaScript's weaknesses as a language. I think it has been due to the rapidly
changing landscape of _what users expect from web apps_ and the corresponding
changes we need to make in the way we develop.

FRP is a great example: many of the recent shiny new toys have been different
approaches to implementing this concept in the browser (React, Vue, Elm just
to name a few). But this isn't just a trend because web developers are fickle,
it's a trend because web applications are growing in size and complexity, and
we're all sick and tired of implementing the same boilerplate to make the
value of an input get assigned to some variable, or to make the changing of
some variable trigger a change in the DOM.

I think there is some overlap, but in general conflating changing development
practices with the problems of JS as a language, is drastically over-
simplifying it.

Where I do see a psychosis is in the choice of JS as a configuration/build
language. Systems like Gulp and Grunt make no sense to me. Why would you want
a build script to be in a language with asynchronous I/O and callbacks? Build
scripts are always one step at a time, feeding the result of one thing into
another. JS just doesn't fit that kind of workload. I see that as a psychosis,
and as the result of more junior devs wanting to choose a tool they are more
familiar with, as opposed to the one that does the job better.

EDIT: Another example of a psychosis has been recently discussed on HN: the
choice of embedded web browsers for implementing text editors[0]. Again: other
than 'psychosis' mixed with the desire to pick a more familiar tool, what
makes a web browser a good tool to build a text editor? Nothing!

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

~~~
smt88
> _I don 't think the onslaught of new frameworks and transpilers has been due
> to JavaScript's weaknesses as a language._

I whole-heartedly disagree. TypeScript, Flow, and Babel are all ways to
address JavaScript's weaknesses. You could argue Babel is a result of out-
dated browsers, of course. But fragmentation of targets is certainly an issue
of the language -- earlier versions didn't have to be so poorly designed.

Would we have all these transpilers if we were using a fully-formed, general-
purpose language for the web from the start? No. If JS had a type system,
there would be no TypeScript, Flow, NativeScript, PureScript, etc. If JS had a
sane way to handle parallelism from the beginning, Babel wouldn't be nearly as
useful.

Yes, it's true that JavaScript wasn't designed for what it's being used for
now. That doesn't mean it's a good language (or ever was).

------
ajamesm
I was most surprised by this CEO who goes around messaging randoms on LinkedIn
to start friendly conversations. Does that happen?

------
thelazydogsback
As a language, JS is what it is - therefore you can use or ignore parts of it,
target it from a transpiler, etc. It's Node, its de-facto execution
environment on the server side, that's the travesty - a hardly-glorified
version of the browser's execution environment. Sure, a well-designed Node
app. is better than your average long-running, thread-holding CGI script from
1998, but there have been servers for ages that can do async thread
sharing/pooling like Node (and with proper language support, if you want it)
but don't _force_ you into this model if your task happens to require true
task parallelism rather simple asynchrony, which require hacks that range from
just ugly to truly horrid.

------
carsongross
The designer/engineer identity and personality disconnects are definitely a
big part of the story of Javascript in the last five years.

SF (design) took over as the bleeding edge when Javascript finally burst on
the scene, and Palo Alto (engineering) faded.

The interesting thing to me is the amount of identitarian-style thinking that
I see around the arguments in technology (macs, linux, javascript, etc.) where
it is obvious that in-group/out-group factors nearly completely dominate
discussions, rather than technical issues and trade offs.

------
payne92
JavaScript has many challenges, but I think the biggest by far is the lack of
"batteries included" standard libraries.

Without those, ecosystem fills the vacuum with a large, evolving mix of
overlapping libraries that don't interoperate.

How often have you considered library X, but then found it doesn't work with
your project's other libraries and frameworks?

~~~
megous
I don't think so. PHP has batteries included, yet there's bazillion of
frameworks too. People just like to create their own stuff, doing ever smaller
improvements, or disimprovements if they overengineer because of being
dogmatic about OOP, patterns, etc.

Libraries you can't avoid. There will be always something missing that someone
needs.

------
dllthomas
> What other modern programming language is so bad that a linter is most
> recommended for safety sake?

Python, for one.

------
Cpoll
As someone who doesn't use Node: Do most of these arguments apply to Node?
(Silent failures, callback hell, weak typing brokenness).

I acknowledge that most of these are very bad in the browser, although I have
good things to say about Typescript.

~~~
smt88
> _Silent failures_

Yes

> _Callback hell_

No, if you're using a version of Node released in the last few years. The most
recent versions support async/await syntax in addition to promises, which fix
callback hell.

> _Weak typing brokenness_

Yes

------
apricot13
please add NSFW to the title on this!

