
JavaScript is Eating the World - bhalp1
https://dev.to/anthonydelgado/javascript-is-eating-the-world
======
shados
The fact that JavaScript and the web platform kind of sucks while at the same
time being "unavoidable" is why it's so good.

It forced a lot of very smart people and a lot of eyes onto the platform to
try and find solutions within the extremely restrictive "box" to these
problems.

How do you solve the API issues when you don't control the platform?

How do you solve for perf when things can't be installed?

How do you solve the API when you can't force people to upgrade?

How do you solve the language when you only have one language as a compilation
target?

Out of these we got React and other vdom style view layers. FP paradigms got
into the mainstream.

It exposed the mass to newer type system features

We got a toolchain that while complex, can do almost anything.

We got some test tooling that are ahead of other mainstream languages.

And every last bit of these went through tons of iterations (sure, javascript
fatigue, whatever), and have had an immense amount of eyes on. You totally can
look at any of the things I pointed out and say "Language X did it first!",
but no one forced Language X on so many people, while JS was, so these things
got a lot more exposure.

In short, I love the JS ecosystem precisely because it sucks so much.

~~~
DonbunEf7
I bet you love pugs, bulldogs, and dalmatians too.

~~~
abjorn
All dogs are good dogs.

~~~
subway
Of course. You certainly can't fault the dog for the questionable ethics
leading up to it's existence.

------
hood_syntax
The more time goes by the more I feel crazy for missing whatever would
motivate people to use js for anything more than is strictly necessary. Single
threaded server??? I mean come on man, I understand you don't need parallelism
for a lot of use cases but even if that fits your situation why javascript? It
can't be that hard using a different language. I refuse to believe that.

~~~
mschuetz
With ES6, JS became a really nice scripting language. Personally, I'm glad to
see more and more projects that use javascript outside of web browsers and
I've also added V8 to my most recent C++ project. The only major drawback in
my opinion is, that it's not statically typed.

~~~
flavio81
The deeper problem is that JS is not _strongly_ typed. Typescript gives you
static type _checks_ but the runtime is still weakly typed and will still do
all sorts of weird type conversions.

~~~
monsieurbanana
Theoretically, to what extend could the weird type conversions be prevented
with the use of a strict linter? My intuition would be all, but I haven't
thought much about it.

~~~
flavio81
Once code reaches a certain complexity level (and mind you, the threshold is
rather low), you'll need dynamic generation of code and data (or else, write
10x the amount of lines of code). For this to happen in a safe way, you
really, really, do need the runtime to be strictly typed.

~~~
0xffff2
Are you making this claim about JavaScript or as a general statement? I've
probably written less than 1000 lines of JS ever (and that only for hobby
projects), but I would strongly disagree with this statement as applied to
C++, Java, etc.

~~~
thehardsphere
I'm sorry, I'm confused by the way you expressed that. The argument was you
need strict typing for large projects. C++ and Java have strict typing. What
exactly is the basis of your strong disagreement?

------
krapp
I feel like it's less Javascript that's eating the world and more Node and
NPM.

It seems as if it's impossible to publish a Javascript project without taking
for granted that the developer has, or even _wants_ , a package manager with
dependencies, arbitrary toolchain and transpiler along with it.

Maybe I'm just a dinosaur for not wanting my "build process" for javascript to
be more complicated than including a script tag. That's probably what it is.

~~~
alayek
The way to look at it, is that browser is a target runtime platform.

When you write code in a team, you optimize for readability, maintainability
etc. You spread your code over 5 directories, 50 subdirectories, 3000 files.

When you want to run this in a browser environment, it needs to be optimized
for delivery - faster download, less time-to-be-interactive. You need to split
your JS codebase as per routes in your app, and load chunks as per user
demand.

Not just JS, you'd have to compile and inline your CSS, base-64 encode your
images to data-urls, generate image stripes.

Before all these, you'd have to lint your code, and run unit tests on your
code.

I fail to see how you can do all these with just a script tag. You need some
sort of a compiler / transpiler; and a task runner that gives you a handy
interface to these.

The package manager has no dependency, other than the Node runtime itself.

As for arbitrary toolchain, the metadata is codified with semantic versions in
your package.json. You're one install step away from downloading all the
necessary packages.

One thing I think lot of Node project misses, is to not add which Node version
is to be used. It's not because it's impossible to do that - there are two
well documented ways to do that (via .nvmrc and "engines" entry in
package.json)

~~~
tedunangst
This sounds a lot like how it's possible to fit a square peg in a round hole
if you have the right drills and grinders and so on.

~~~
enraged_camel
That's exactly what it is.

The fundamental issue is that the overwhelming majority of interactive
websites today don't actually need to be interactive, and may even be better
off as old-fashioned HTML pages served by the server.

But people love over-complicating stuff, and when the end result is complex
the toolchain has to be complex too, not just for one person but the whole
team. Then you end up with developers who spend more time wrestling with
webpack et al than working on actual features.

~~~
ryanmarsh
I wish this "the web is over complicated" meme would die. The web at one point
was only for hypertext. It is still fine for hypertext but it is now also an
application platform and the browser a runtime and app container.

Your solution to the JS ecosystem is to make news websites less interactive. I
see why you long for simpler times but I don't see how that fixes things.

For those of us who are building applications we need the complexity. It
solves problems that come from the fact that the web has evolved from a
hypertext system to an application platform.

~~~
bigtunacan
The issue is not that "the web is over complicated". The bigger issue is that
people are allowing themselves to be brainwashed into thinking that everything
is a "web application". Some sites offer benefits as web applications; GMail
and Pivotal Tracker come to mind right away as good examples. Other websites
like CNN should not be applications and would do end users a disservice by
over-complicating things by making them JavaScript based.

One of the trends I'm seeing is that a lot of developers once they have built
one web site as a SPA they seem to start thinking everything should be built
this way. More consideration should be given to deciding which is appropriate.

~~~
free_everybody
I think this sums up the most poignant complaint against the javascript/node
trend. It's not that we don't need SPA's. SPA's are awesome. But sites like
Reddit and Hacker News prove that they don't need to be implemented
everywhere.

------
eloff
I think ES6 javascript is actually a decent language. But the way it's used is
terrible. Slow transpilers that give all the disadvantages of a compiled
language - but with the type safety of a dynamic language. Asynchronous code
that is slightly better with promises and async/await, but horrifying to debug
with stacktraces that are often completely useless. NPM with its plethora of
low-quality packages - yet it's not uncommon for packages to have hundreds of
dependencies. And when you try digging into those packages to understand what
they do, because there's no documentation, you find a mess of javascript
magic. Globals, nested closures, "coroutines" using yield and function
references and a dozen magical libraries that are nearly impossible to
untangle. I found the development experience to be slow and extraordinarily
painful. I actually find PHP easier to work with (but more soul crushing to
write.)

I would much rather use Go or C# or C++ or Java (well Kotlin, because I don't
like to write Java) the development experience is just so, so much smoother.

------
jchw
JS has the appeal that it's something a lot of people already have good
amounts of experience with. And ES2015+ features add to the learning curve,
but also give some much needed aid to existing problems; it's easy to pick up
on async/await when you already know how promises work.

Meanwhile, trying to find Go developers can be a challenge. And the learning
curve is low, but there's plenty of low-level gotchas like dealing with
concurrency and memory usage. (Yes, even in a garbage collected language, this
manages to be a problem.)

In Node, you run into less issues because if you have a problem to solve you
just npm install something.

That being said, my enthusiasm ends there. Every experience I have with trying
to tie a database into Node has been horrible. Also, I think event loop based
programming is missing the mark even if it beats out previous methods; I think
Go and other CSP based languages like Erlang have the real right answer. I
think if we really start seeing huge core counts, it will become apparent that
a single thread event loop eventually starts to become a bottleneck. Also, NPM
has an insane number of packages, but the quality is extremely variable - much
more than PyPI, though I'm not saying everything on PyPI is magically
production ready.

I guess what I'm saying is, maybe I should start learning Rust.

~~~
talmand
I'm beginning to think npm has joke potential like regex.

"I had a problem. I started using regex and now I have two problems."

Becomes...

"I had a problem. I ran npm install and now I have 21,735 problems."

~~~
falcolas
It bothers me that I have to agree with this. I watched an NPM install once,
and noticed that one particular library was downloaded and compiled somewhere
around 40 times (and each compiled version was different).

Think about that for a moment: one library, 40 versions downloaded and
compiled to fill NPM dependencies. What if there was a vulnerability in a
version of that library - how do I audit that? Can I even fix it myself
without hosting my own NPM registry? Bandwidth? Computation costs (a thing
again, with cloud computing)? Disk space costs?

It makes me glad we just use Docker; so I don't have to try and make sense of
the NPM madness from day-to-day. Just Docker's own brand of madness.

~~~
alayek
Personal experience: NPM can be mind-bogglingly slow in Windows. In my
previous day-job, an NPM install on Windows 7 could take hours, for some
reason. That's NPM 3 with about 20 dependencies on a small project.

NPM on Windows also had other problems such as Python path is wrong or C++
compiler is missing.

Then we switched to Yarn. Uncached install took about 2-3 minutes, and cached
install would finish in seconds.

Recently, NPM 5 has been released, and it's been competing well against Yarn.

~~~
jchw
Still a bigger fan of Yarn here. My personal tests have Yarn running a bit
faster still, but I also like that Yarn's command syntax is easier. NPM seems
content with making a million aliases of everything and it's annoying. I think
they even added 'add' from Yarn.

Also, Yarn's run command can be used to run locally installed NPM binaries,
not just NPM scripts. i.e., you can do `yarn run -- webpack` and it will run
the local copy of Webpack. This is handy imo, and as far as I know NPM doesn't
do it.

~~~
fahrradflucht
FWIW npm 5 comes with npx [0] which basically does similar things. If you run
npx webpack it would use the local copy of webpack or even install one run it
and discard it.

[0] [https://www.npmjs.com/package/npx](https://www.npmjs.com/package/npx)

~~~
eliaslfox
That's not the same thing. Npx is for running commands you install from npm,
and yarn [command] allows you to run scripts defined in your package.json
file.

~~~
fahrradflucht
npm always did this. The OC said that he likes that yarn can also run local
binaries that are not a npm script.

------
nerdwaller
Most of these examples aren't "moving off Java to Node" as the post tries to
conclude, it's simply breaking out the view layer to "a right" tool for views.
If anything, it's simply adding a supplement to existing systems.

In many large orgs devs still use a homogenous tool for the existing systems
(e.g. my guess is at Netflix all new business logic services are still Java
based to plug into the Spring+NetflixOSS stack).

------
cdnsteve
JavaScript has eaten my time. It's a really frustrating ecosystem to work in,
all the deps, toolchains, build process is extremely fragile.

I'm pushing everything to Python these days and some light front-end in JS
where needed. Couldn't be happier!

~~~
mmirate
Python is still dynamically typed, though at least it is less weakly-typed
than JS.

While the benefits of moving any distance away from JS's weak-typing are
certainly obvious, why stop at Python rather than a language which is both
strongly and statically typed?

~~~
quacker
They didn't mention anything about typing as reason for switching. They said
"It's a really frustrating ecosystem to work in, all the deps, toolchains,
build process is extremely fragile." They switched to python for the ecosystem
and tooling.

~~~
always_good
I don't understand the distinction.

JavaScript tooling is notoriously complicated on the front-end, not the back-
end. And I doubt they're saying that they switched to Python on the front-end.

~~~
quacker
_> I don't understand the distinction._

The distinction was that cdnsteve was motivated to switch to Python due to
issues with the toolchain and build system, not that JavaScript was weakly-
typed.

 _> JavaScript tooling is notoriously complicated on the front-end, not the
back-end. And I doubt they're saying that they switched to Python on the
front-end._

You have a good point, though you still have to pull in dependencies and deal
with NPM when running JS on the server-side (especially if the server is doing
non-trivial stuff). Idk, maybe an approach with server-side rendering using
Python did away with much of the JS usage which made things nicer.

~~~
TheDongIsYou
I still don't see the point, you'll probably need to pull dependencies whether
you use is or any other language.

And as for build tools, people like to complain way too much, maybe they
prefer just using bash scripts instead..

~~~
quacker
Maybe python's dependency management (pypi/pip) is nicer than NPM? (I think it
is, at least)

------
phaedryx
Summary: "Javascript is eating the world because 5 huge companies use NodeJS"

Not sure I buy the argument.

~~~
g00gler
Right. The following could be written as "Netflix uses Node to render React
components" which is pretty much a given.

> Java still powers the backend of Netflix, but all the stuff that the user
> sees comes from Node. In addition to Node, Netflix is also using ReactJS in
> their stack.

------
fao_
The other day I managed to freeze my computer -- such that I did not even have
access to the SysReq key, by stupidly running

    
    
      while (true) { var d = new Date; e.textContent = d.toLocaleString(); }
    

I immediately realised my stupidity, and closed the tab. Shortly after, my
mouse froze up, then my keyboard access, and eventually my entire access.
Rather than just freezing Xorg as I had initially suspected, it froze my
_entire_ computer access. No SysReq, no switching to a tty, nothing.

I was an idiot, but at the same time, an unprivileged process should not be
able to consume resources like that without a dæmon coming in and
pausing/killing it. And the Javascript should not have been allowed to execute
once I had closed the window.

Truly, Javascript is eating the world.

~~~
Sacho
I tried your code snippet on my inferior Windows OS and inferior IE Edge
browser. The tab stopped functioning. I opened a few other tabs and continued
to work. Eventually IE showed a notice that the tab had stopped responding - I
had the option to close the tab or recover the webpage. I clicked 'recover
webpage', the page was refreshed and I could continue using it. Truly,
Javascript is eating the world.

Or perhaps the language has nothing to do with your problem.

~~~
fao_
Do you deny that implementations are part of the language? If the Javascript
specification left this out, what other implementation gotchyas exist for them
to exploit?

~~~
sk5t
Few but you likely consider the implementation part of the language.

~~~
fao_
C explicitly states what an implementation should and should not do. The same
with C++, FORTRAN, and other standards. Javascript is a standard written by
committee. So why can't it tell implementations what is good behavior and what
isn't? Other languages do.

~~~
sk5t
I think there's a distinction to be made between the language spec (e.g.,
interesting Javascripty details like what is the result of `"" \+ 1`) and
integration issues like what to do when the browser window detaches, how many
threads the browser will devote to running Javascript, what to do when some of
those threads appear to be blocked, or how should the runtime/VM attempt to
recover from deadlock or OOM.

------
rdtsc
Maybe. Callback / promise hell in a language that needs a book like
"Javascript the good parts" is probably not eating the world.

Yeah it is cool, npm package system is (was?) one of the easier ones to use.
It is a good starter thing for someone who has only learn or done frontend
development before. But I have not had a good experience with it on the
backend.

~~~
flavio81
The road to software hell is paved with ease to use.

------
voidhorse
I think a few aspects of the language contribute to this:

1\. It is relatively easy to comprehend and pick up and play around with.

2\. With the advent of node.js, and later electron, it is incredibly relevant
whether you're developing web apps, servers, or now, even desktop apps.

3\. Some of the newer features, such as arrow functions actually make writing
javascript a lot of fun!

JS has come a long way. I do think there are negatives to its popularity but I
think it has also probably done wonders in terms of lowering the barrier of
entry to get into programming. It's honestly a great language to start out
with these days imo. It's easy enough to learn the basics (excusing the quirks
of the language that do remain), easy to practice it developing whatever
project you want to work on, and, even though it has problems of its own, node
is a solid and, again, easy to use (I think it might be becoming clear what
aspect here I think is key to JS popularity) tooling system for the language.

It still has its detractors, but all in all I'd say JS is pretty great.

Now, does that mean so many companies should jump to using it right away? No,
of course not. But you can see why they are tempted. Because JS code is
typically easy to use, comprehend, and manage, and because of its ubiquity it
makes sense to use it so that as the composition of a team shifts and changes
it's fairly easy to pass work along or pick up where someone else left off.

~~~
sametmax
Take away the web platform, would you still use JS for anything ?

~~~
mschuetz
Yes. I've added V8 to my recent C++ project since JS is my favourite scripting
language and it does wonders. JS has become a joy to use with ES6.

~~~
sametmax
Compared to Ruby, Python or even Perl 6, I fail to see how anything in JS can
be considered a superior option for scripting. Even for simple things like
map/filter, reading a file or parsing script args ES7 scores just average. And
I'm not even talking about debugging and error handling.

------
adjkant
We really need to stop putting Javascript on the back end when there are so
many other great options that won't be any different to the front end in most
(all?) cases. I think working on full fledged Javascript solutions for the
front end that address load time and page size is great. It still amazes me
why anyone would use Javascript on the back end willingly.

------
pards
Using the same language on both the front-end and back-end is never a good
idea. Java Applets, anyone?

It may sound appealing to management, but the front-end and back-end are
different paradigms requiring different skills and language features.

------
tjwds
For anyone who's searching for more quantitative data, there's always the 2017
Stack Overflow Developer Survey [1] which seems to reflect that js (& node)
are still growing.

[1]
[https://insights.stackoverflow.com/survey/2017](https://insights.stackoverflow.com/survey/2017)

~~~
jerf
Yes, in a survey that returned that 72.6% of the respondants consider
themselves "web developers", it turns out that Javascript usage is going
strong.

It is the opposite result that would be surprising.

Javascript isn't eating the world, it's just escaping from its multi-decade
browser-only shackles and spreading its wings, which means JS is moving into
some niches it previously had no access to. From 0, there's nowhere to go but
up! If you're a primary-JS developer it may feel like suddenly the world is at
your command, compared to where you could take your skills before. But it's
not eating the world and it's not going to, because there aren't any niches
anymore for it to conquer that aren't already colonized by other quite good
competition. JS itself is nothing particularly fancy next to Python or Ruby.
And there are a lot of very important niches that are simply unavailable to
it.

If Javascript were something other than a fairly standard dynamic scripting
language, it might find itself with some new opportunities. But it's not, and
while it was locked in the browser, the other dynamic scripting languages
pretty much took over everything that a dynamic scripting language can. I'm
sure JS will develop parallels to some of that stuff, it already has, but it
isn't going to be growing into uncontested space.

------
onion2k
What you build is infinitely more important than what you built it with. If
someone writes a better Google the users won't care if it's using Javascript,
Rust, or QBasic. They'd still be all over it.

~~~
tomascot
I had a client that asked me to rewrite our software in JS. He didnt know
anything about programming but said he preferred JS.

~~~
infinisil
I haven't ever written professional software, but I just took a software
engineering course and what I learned is that what technology stack to use is
none of the clients business.

~~~
acuozzo
> what technology stack to use is none of the clients business

Until your client is unable to find competent programmers to hire to do
maintenance after you're gone because you chose to use something esoteric.

A big reason why there are so many JavaJobs™ is that there are so many
programmers with Java listed on their résumé/CV.

Your client needs to look ahead and plan for the possibility of his/her entire
dev team being poached on the same day.

------
randallsquared
Virtually contentless.

~~~
chickenfries
Literally just an excuse for a bunch of people (many of whom don't even write
javascript) to rehash the same old complaints about flaws and tradeoffs.

------
heheocoenev
We live in dark times.

~~~
busterarm
It's okay. Javascript may be eating the world, but the Javascript world is
eating itself.

~~~
flavio81
best comment !! and true to reality.

------
edoceo
ARG! The floating point handling in JS bites (bytes?) me almost daily. I code
in JS every day but I hate this number "bug" the most. Having to frob back and
forth with "int" to make it not totally broken.

Am I the only one?

~~~
frandroid
Crockford proposes DEC64: [http://dec64.com/](http://dec64.com/)

------
pyrophane
I think this is more reflective of the shift in how code and development teams
are being organized rather than JavaScript "eating the world."

Now that many shops have separate back-end and front-end focused teams, a lot
of API development is moving to node so that the front-end focused JS
developers can maintain the APIs they consume themselves.

Also, while languages like Java are very good at helping large teams manage
equally large codebases, deploying microserves and organizing code into
smaller-more self-contained pieces make it easier to use things like
javascript for individual services.

------
rdoherty
Reminds me of a 'future' talk about how JavaScript took over the world as a
language even though no one actually programmed in. This was because as long
as you could transpile to ASM, you could get native performance via JS.

[https://www.destroyallsoftware.com/talks/the-birth-and-
death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)

(Worth watching no matter what your background is, it's funny and informative)

------
YSFEJ4SWJUVU6
I think it's interesting in its own right to point out that the trendy editors
of today implemented in JavaScript are able to edit (and even view) files
larger than about a megabyte because they are not any more fully implemented
in JavaScript says something – and I'm of course not talking about the
framework.

------
crimsonalucard
Node scales well in terms of performance. However does it scale well in terms
of code complexity and readability?

~~~
kin
Because it's not opinionated, it all depends. IMO the code base where I work
is very complex but it's very easy to onboard new engineers with it. This is
due in part to enforcing documentation and code style guidelines.

~~~
crimsonalucard
Is that a good thing? I would argue that enforcing guidelines can make any
type of code base workable.

The holy grail is a language that enforces guidelines itself, for example: a
type system.

~~~
kin
I think static vs. loosely typed both have their pros and cons but that's the
thing that's great about the Javascript community. It's not opinionated on
things like this. So if you want statically typed, then you can code in
Typescript.

This is in contrast to something like Rails which is super opinionated and
doesn't give you much of a choice if you as a developer or even as a company
as a whole were to disagree with these opinions.

~~~
crimsonalucard
Also rails is not a language, it is a framework, aka an opinion. Languages
should lean towards being opinion agnostic while frameworks by there very
nature should be opinionated.

~~~
kin
I think we're on the same page here. Javascript as a language is pretty
opinion agnostic. Same with Node, it's just a runtime.

All I'm saying is JS is more than capable of scaling in both complexity and
maintainability.

------
markbnj
Certainly eating all my inodes, anyway.

------
drabiega
Not sure I understand the usage attributed to Netflix? Sounds like the writer
is saying that front end is node, but that can't be right?

Can someone who knows what they're using node for go into a little more
detail?

~~~
alayek
Other than their front-end build process, Node is also used in their user-
facing servers. Basically, when your Netflix app makes a HTTP request to fetch
any data from its backend servers, the request first hits a Node JS server.

Something like this: [https://medium.com/the-node-js-
collection/netflixandchill-ho...](https://medium.com/the-node-js-
collection/netflixandchill-how-netflix-scales-with-node-js-and-containers-
cf63c0b92e57)

------
brandonmenc
DOS ate the world once too. Worse is better, installed base, etc etc...

------
pier25
And here I am desperately looking for an alternative to Node.

~~~
thehardsphere
What's wrong with everything that came before it?

~~~
pier25
PHP, Java, .NET, C++, Ruby, Python?

No thanks.

I'm looking at Go, Rust, Erlang, and Crystal. Go seems like the best choice so
far.

~~~
thehardsphere
That's not actually an answer, but OK.

------
fundabulousrIII
What they don't say in this panegyric to node is that.. 1\. The language (js)
is absolutely horrific. 2\. node is single threaded and non-blocking/async in
I/O for some operations but when blocking requires libuv and gymnastics. 3\.
It moves too fast for stability. I've encountered huge memory leaks with node
at various versions that are terrible to debug. 4\. It is designed to the
lowest possible specification for development: web developers. 5\. js package
mgmt and build tools are a running joke.

~~~
woah
There are languages that I like better than JS. However, JS servers power
trillions of dollars of business. People who grasp for reasons to hate on JS
are a little like people who get into flame wars about video game franchise
rivalries. It's symptomatic of deep unmet emotional needs in that person's
life.

~~~
tomc1985
> It's symptomatic of deep unmet emotional needs in that person's life.

Pretty sure pronouncements like that are the real indicator of unmet emotional
needs.

The way this community needles dissenting opinions needs to change. If you
don't like the HN flavor of things, the resulting swarm of nitpicking, self-
righteous commenters blots out the sun.

~~~
always_good
Eh, scroll through the comments in every submission that mentions JavaScript
(like this one) and you'll see a bunch of people lambasting anyone that uses
JavaScript.

"Ugh, why would _anyone_ use it on the server? Idiots!"

"Lol web developers only know one language. Sad!"

As if anybody that chooses a different set of trade-offs is incompetent, not
just comfortable with a different set of trade-offs.

~~~
collyw
Maybe they say that because they have used better languages, rather than unmet
emotional needs.

~~~
Can_Not
Languages that are a minimum of 1 year of maturity behind nodejs for the
specific use-cases that nodejs is typically used for.

------
mark024
npm and the huge number of dependencies scares me, I remember in WordPress
plugins would get hijacked and you would get an update that backdoors or
inserts some vulnerability, other than this, I spend 3-4 hours 2 days ago,
trying to merge 2 json datasets by doing some averages, and simply could not
do it, the numbers were in string format, and it would work for some and get
NaN for other, or would just concatenate them as string, I was working in
typescript and using "number" was concatenating, weirdest thing ever, I just
gave up.

~~~
swiley
I stop reading READMEs as soon as I see npm.

------
holydude
My personal opinion is that what applies to big companies offering "free"
products applies in tech as well.I call it the good enough concept. The
product is not exceptional but it is good enough when you consider all things
involved (price in case of big companies (it being free) and performance in
case of javascript.

So for a lot of people web apps are good enough. They do not need native apps.
The same applies to developers. Sure you can avoid transpiling to JS but JS
also became good enough for people to just stick to it. And while they were at
it they found out it is also good enough on the backend (nodejs) and on the
mobile (react native) and also on the desktop (electron).

Only time will tell if it is or was the right choice.

------
megamindbrian
We should all speak JavaScript.

------
nilved
What a depressing idea. I don't take JavaScript seriously at all.

~~~
alayek
Sorry to say this, but this kind of statements don't really add anything to
the discussion. _Only a sith deals in absolutes_.

Recently, JavaScript has adopted lot of language feature from C#, Ruby etc.,
that make it really useful for most common tasks. And the community moves
really really fast, hence adoption of new language syntax is quite fast.

JavaScript has some killer platforms / apps, that are being used in production
by high-traffic companies.

You can do cross-platform Desktop app in Electron (Slack, VSCode, Atom etc.
are written with this).

Front-end build tools are written in Node JS, and they do lot of heavy lifting
as well. Babel is a transpiler, Webpack is a bundler.

These days, native mobile apps (not hybrid apps) in JS are also gaining
traction, via React Native.

From open source communities to big behemoths are behind this.

I would like to hear what about JS turned you off so much?

~~~
crimsonalucard
It's not the technology surrounding the language, it's more of how the core
language itself is flawed.

~~~
mmargerum
I'd argue the opposite. ES6 is s pretty decent language, but setting up the
tooling is a PITA.

------
adamnemecek
JavaScript you say? What a fresh opinion. I'm just like wow, the thought
leadership of this post is defo palpable.

