
JavaScript for People Who Hate JavaScript - ingve
https://zachholman.com/posts/javacript-haters
======
cel1ne
Background: I learned Javascript 1997 and kept up.

I have extensive experience in ES6/React for the browser and Java/Kotlin for
Server-, Desktop- and Mobile-Apps.

A week ago I switched a fairly new project from the usual setup
(react/babel/webpack) to Kotlin-code only. My IDE compiles the Kotlin to JS
now and webpack serves it as usual.

Writing the react-bindings took me an hour, after that my productivity went up
by about 10.000%. It's finally on par with my productivity on server and
desktop. No type errors, fast refactoring, no "undefined" errors and all the
goodies (extensions) of Kotlin.

Removing the complex eslint settings and babel-setup from webpack and
package.json felt triumphant.

My JSX looks like this now and is completely typesafe:

    
    
        val LieferungenList: (props: ListProps) -> ReactElement = {
            Datagrid {
                div {
                    className = "..."
                    ...        
                }
                TextField {
                    source = "date"
                }
                TextField {
                    source = "produktname"
                }
                EditButton {
                }
            }
        }
    

I even get compiler-errors when I nest HTML-tags the wrong way (h1 inside h1)
or so.

I couldn't be happier. I'll never touch plain ES6 again.

~~~
bitL
Any good tutorial for Kotlin as a JS replacement? I am one of those people
hating JS (and I did some very advanced JS web apps pushing technological
possibilities) and would love to have something sane before WebAssembly can
completely obliterate JS and I can switch to whatever language I like. Thanks
for any hints!

~~~
flavio81
> before WebAssembly can completely obliterate JS and I can switch to whatever
> language I like.

This is exactly what I'm waiting for.

------
sametmax
TL;DR: JS with a ton of make up and tooling to not write JS is not as horrible
as it used to be.

Well. That doesn't make it awesome either.

You just traded some problems for others.

Like the damn source map never working correctly, the build time being longer
and longer, and the never ending list of plugins you expend every day after
stumbling on yet another small-minuscule-not-that-important-I-swear detail.

The tool chain you spend more and more time on, despite all the "5-minutes"
bundles provided by facebook or on githubs.

Explaining things to new comers has never been as difficult as it is now.
Teaching is a pain.

Choosing your stack is a dangerous bet, and the odds and steaks are changing
all the time.

If you opt-in for a flux architecture, you will soon write Java-as-in-the-90
on the frontend instead of Javascript, with so many adapters and design
patterns as layers you will become angry.

If you don't (you-totally-don't-need-redux-to-use-react-guys) then most
documentations and tutorials will not answer your questions, and you are own
your own solving every single problems. Even the simplest ones, like
redirecting on a route after data changes and closing a panel at the same
time.

"Libs, not framework" means you need to relearn everything, rewrite a lot of
code, tests and doc and renew maintenance for each new project. Meanwhile
nobody agree on what a the proper stack is.

JS, despite all the paint on the rust, still has the old gotchas. This is
still weird. ";" is still auto inserted. "==" still compares like nothing
else. Errors come in different so many different forms it's not funny. Basic
maths assumptions like commutativity are out of scope. Still no namespaces,
but instead we use monstrosity like webpack and incompatible import systems to
encapsulate things. Stdlib still doesn't have essential things like hashing,
string/date formatting or encoding. Even basic operation like removing an
element from an array using an index is a pain.

No, I'm sorry, JS has not become awesome. We just arrived to a point were we
accepted we have everything to built with it and agree to pay the huge price
for it. That's all.

Projects like vue.js makes me think there is still hope we end up with elegant
tools from people who care. But right now I just embrace the madness and make
money with it: all those poor customers don't realize the trap the current
mindset lead them to, and I have so many solutions to the problem they should
never have had to sell them.

~~~
cookiecaper
>No, I'm sorry, JS has not become awesome. We just arrived to a point were we
accepted we have everything to built with it and agree to pay the huge price
for it. That's all.

Yep, this is the crux. ES6+ has finally made JavaScript look more or less like
the languages we were using in the mid-90s, so I appreciate that, but it's not
like it's some glorious boon to the developer community.

Any gains from the new semi-tolerable semantics are quickly overwhelmed by
requiring layer-upon-layer-upon-layer of crap, including hundreds of dangerous
random modules from GitHub to compensate for the virtually non-existent
standard library and a "build pipeline" that consists of several unrelated
runners, bundlers, transpilers and transformers to make code that's actually
usable in real environments.

JavaScript is a tragedy for the development community from start to finish,
and its increasing prominence should disabuse us of the notion that
development is dictated by meritocracy or any such fantastical nonsense like
that. Marketing and groupthink have just as much pull here as anywhere else
(if not more because so many of us egotistically believe we are immune to it).

~~~
hajile
Everyone complains about the build tools, but they simply haven't thought
through the issues.

Let's say you were writing the web using Python. New browsers run v3.x, but
old ones run 2.x or even 1.x. Further, features in newer versions of v3.x
won't work on older versions of v3.x. New browsers could include all three
runtimes, but old ones would be SOL.

How do you use v3 features and target v2 or v1? You must transpile knowing
that newer browsers also have v2 and v1 engines included too.

You have hundreds of Python files in your system. Delivering hundreds of files
is simply not practical on HTTP/2\. You combine them and now you have webpack.

What about libraries? As big as the standard lib is for Python, it doesn't do
everything. You use pip or conda and now have npm/yarn.

What about code consistency? The solution is pylint.

What about testing? Add that to your chain as well.

It's the unique issues of the web -- NOT Javascript -- that makes the build
pipeline what it is. Until a few short years ago, these things weren't even
possible. Today, if you know node/npm, webpack, babel, and eslint, you know
the overwhelming majority of build processes.

I'd finally add that make, Jenkins, etc are far more complicated to learn than
the JS systems.

~~~
sametmax
The original crappy design is definitly a problem with JS: the typing/testing,
the lack of namespace import, the emptyness of the stdlib. Half of the
problems we have today are directly correlated with this.

Most of our tools are not here to make things better, but to avoid sucking too
much.

So yes, forward compat is an issue. But that's hardly the one I'm complaining
about. I'm really ok with not being able to use spread, but I can live with
it. I'm not ok with having to use npm + webpack to download, install, isolate
and bunddle a remote lib to do a leftpad.

------
twii
Omg, so this guy thinks he knows why I'm hating Javascript? Well, it's
definitely not because of the lack of types, or because without Prettier my
code looks shit, neither would it be the lack of E6/ES7 features since I'm
using Coffeescript 2. No, I hate Javascript especially for it's conitnuously
changing ecosystem being forced upon you. You named Dan Abramov? Ah, the guy
who deprecated almost all flux in favor of his own idea (Redux), or by
deprecating React Mixins, because he thinks Mixins are bad, Higher Order
Components is the new holy grail?

If I am looking for a job as a Javasript developer at the moment it is not
about my coding skills, it is about my willingness to adopt all those hyped
technologies, and the author of this article is just making it worse.

I also hate Javascript for all those people reading this that think I don't
understand it yet, and are going to explain me how great ES6/ES7, Promises,
and/or Typescript are. Please don't.

~~~
pluma
> If I am looking for a job as a Javasript developer at the moment it is not
> about my coding skills, it is about my willingness to adopt all those hyped
> technologies

If you're looking for a job as a developer I hope it's _always_ about your
ability to adopt to changes and new technologies. Because that's what
distinguishes a developer from somebody's "nephew who's really good with
computers" and is willing to work for scraps.

Any formal education worth its salt is about giving you that ability rather
than just teaching you the status quo. If you want a stable ecosystem that
doesn't change, try specializing in legacy technologies. There's still a ton
of software written in languages that are well past their prime and large
companies will pay good money for people willing and capable of working on
that.

Maybe you should stay away from JavaScript for the next 20 years and come back
when people consider it quaint and archaic and don't try to apply new ideas to
it anymore. This isn't hyperbole, this is an honest suggestion.

~~~
blub
Sure, but adapting as a JS developer is mostly about relearning how to do the
same thing using different libraries and frameworks.

As an embedded developer I am able to build upon my existing knowledge and am
deepening my skills in embedded, Linux, C++, etc. I'm not learning new
programming languages and operating systems every couple of months.

And this is how it should be, otherwise you'll end up being always average, no
matter how much you learn.

~~~
slfnflctd
> relearning how to do the same thing using different libraries and frameworks

This is hell to me, such nausea-inducing inefficiency. I feel like I'm wasting
my time and cluttering my brain needlessly in those scenarios and it drives me
mad. What if you were a woodworker and every few months all the tools and
equipment in your shop changed in various subtle ways? It makes very little
sense to me in the long run. True mastery depends upon some amount of
consistency in your environment. It's the only way you can build on what you
knew before (because it didn't change when you weren't looking) to do more
complex and interesting things.

~~~
snerbles
But think of all the sweet conference talks you can give after inventing the
latest new shiny woodworking tool!

------
pmlnr
Don't compare JS (or any language) to any other language - or any language to
another language. People wrote a lot about it (Your language sucks because...
- type things). JS is just another language.

The JS ecosystem is wild and moving way too fast, but even that is not really
the trouble with it: it's that it's being overused.

He mentions DHTML at the beginning, which was the perfect example of using too
much of something: mouse trailing bouncy balls with falling snow, my, I don't
really miss those days.

Yet we're here in 2017 and React & Co. is crippling the web. Plain simple news
or a blog site rendering with JS? AMP, loading megabytes of Javascript,
claiming to speed up the web? When your product is text, how about you serve
text and maybe only boost it or do analytics with JS? I know it's not fancy,
but for a lot of sites out there, JS based rendering is completely unneeded.

In case of web apps... A little while ago I listened to a talk of front end
colleagues, claiming that we'll speed up the site by async calling some
blocks, so the initial content will get down fast and the less important ones
will follow. When I asked if we're measuring the very end render time - the
one that heats the CPUs, because you offload the rendering to the client,
which can get quite stressful - the answer was 'no', mostly because nobody
knows how to do it. I also asked about how screenreaders will work with this,
and they thought I'm talking about mobile, which is extremely sad, and no, I'm
unaware of any screenreader-friendly JS based app. (Screenreaders are the
programs literally reading out the text for visually impaired.)

Google and FB offers fallback, HTML-only solutions to their services, because
the realised their things don't work on slow connections and/or slow devices.
Maybe this should be taken as a sign.

~~~
prawks
2 quick points:

\- The paradigm shift in writing interactive web pages in the React "write
your app like a game that re-renders every frame"-style is extremely
compelling. You are correct that there are plenty of largely static sites that
do not need JS-based rendering, but for people wanting to develop single-page
web apps or other interactive content, that mindset is a godsend.

\- We recently re-wrote an ecommerce site with React and it is WCAG 2.0 AA
compliant. To our knowledge, and to the independent firms that have audited
our application, screenreaders have no problem with it. You still have to go
through the diligence of all of the standard a11y-friendly techniques like
semantic markup and thoughtful keyboard navigation, but React at least does
not get in the way.

~~~
straws
Another compelling use-case of React is the ability to use it as a better
templating language ― treating HTML as a data structure instead of a string,
better composability of the units of your UI, and the ease of rendering to a
string.

It's an interesting question whether the tendency to overcomplicate a largely
static site by implementing it as a single-page app should be attributed to
the average developer or to the creators of the library though.

------
pbowyer
I've gone through the same experience this year, having picked up modern
JavaScript, Angular2, TypeScript and RxJS for a project.

For me it was TypeScript that did it. I came to appreciate strong typing. And
ES6, fixing the 'this' scope problems and with a conventional class syntax (I
understand prototype inheritance is clever, but it's not the way I've been
trained to think). I didn't get to use async/await for various reasons, but
that looks to remove my third pain point (callback hell/promises/observables).

RxJS remains a mystery (I swear the API wasn't designed for humans) I use and
hope it works, and combining code that use Observables with those that use
Promises still wakes me up in a cold sweat.

But now going back to old territory (PHP, Symfony) I miss it. Yesterday's miss
was union types. TypeScript has spoiled me.

~~~
5trokerac3
I left React for Angular 4 this year, because I came to the realization that
once I made the decision to leave the loosie-goosie world of default JS, there
was no reason to have my framework be loose either.

I'm really loving the confines of a "one way to do it" framework like Angular
4. It makes teamwork much easier, speeds up development once you've gotten
over the learning curve, and is damned impressive when it comes to app
performance.

I'm really looking forward to the day when TypeScript platforms like Angular 4
compile down to WebAssembly and performance goes through the roof.

~~~
kneedeepclunge
how well does Angular perform on production?

as far as i know, React is used more widespread

~~~
pbowyer
We used Angular inside Ionic for an iOS app. Performance is OK, but I can't
tell you if a different JS framework would be faster, or if it's a
device/Ionic limitation. The main problem has been with rendering large sets
of data (say 100+ items) in a scrolling list.

------
golergka
It looks like the author didn't mention the main reason many of us hate
Javascript: weak typing.

Weak typing is great for small-scoped project without a lot of business logic.
But when there's a lot of data, a lot of assumptions about it, and, most
importantly, these assumptions change A LOT during development - which happens
all the time in game development, for example - strong typing is a godsend.

When I make a change in a strong-typed language, I deliberately make it in
such a way that the code won't compile unless I complete it. If I can make
something a compile-time instead of a run-time error, I do it (and that's why
I dream of switching to Rust one day - on some game engine two generations
from now, unfortunately). When I refactor something, I know that compiler will
let me know if I forget to change it somewhere.

Compiler is my dearest friend. Compilation errors are his gentle hints that
make my code better and prepare it from failing in user's hands. Without it, I
feel lost and always on my toes. I have to write tests instead. I have to
launch the project (which, when it uses a lot of resources, always has
overhead) and test everything by hand. When I write a big project in
Javascript, I feel like a minefield, unsure of what's broken and what's not.

I can't understand how people write serious, big projects in weak-typed
languages.

~~~
mathw
Me neither. It just seems really fragile and unwise.

I've had people tell me that tests deal with all the issues I would fix with a
decent type system, but this seems to involve writing tests to see if things
are passing the right types around, which is code the compiler of any strongly
typed language already has in it that you don't have to write.

I don't even find dynamic languages faster to get started with, but maybe
that's because I'm so used to static ones with good type systems. If you can
call C#'s type system "good", that is. It's mostly adequate!

------
agentultra
I was a Python developer for about 10 years before joining a startup that
works almost exclusively in Javascript. I had to swallow my pride and make the
best of it. I had a huge, smug chip in my shoulder.

ES6 has made the language tolerable. Enjoyable even. It has even been a decent
medium for mentoring more junior developers who haven't had any exposure to
functional programming in school. I can show them combinators, functors,
applicatives without all of the usual ceremony in a more pure language. For
that JS has been quite nice.

However for my own projects I just use GHCJS or Bucklescript and compile down
to JS. Google Closure and Webpack are fine tools for shaking out the unused
code and bundling everything up.

~~~
ajford
Current Python dev here. I've found the same thing. I really didn't like
Javascript prior to using ES6. Now it's fairly tolerable. I'm currently
building an app with a React based front end and a Flask-based API for data
exploration and QAQC.

The "where does the semi-colon go" game is really annoying, but I'm getting
better at it, and ESLint will let me know when I mess up. But I do enjoy a lot
of the features in ES6 that make JS (EcmaScript will never sound right to me)
nicer to write.

My huge pet peeve is that it feels like it takes so much work to set up an app
compared to my experience in Python. But maybe that's tooling. I do have some
boiler-plate code to get things working, such as setup.py templates and
YouCompleteMe for code completion, and I use VirtualEnv and Pip to manage
dependencies. I guess that's basically Webpack and NPM and
package.json/webpack.config in JS development.

Who knows. My issues with JS/ES might be all in my head.

~~~
agentultra
I'm one of those people that just trusts ASI. Once you stop inserting them you
stop noticing so much.

After introducing an ESLint configuration to my team I still can't get the
semi-colon lovers to consistently insert semi-colons. I made semi-colons a
warning only just to see since ASI will insert them anyway. The worst
offenders are the die-hards.

I was originally a semi-colon person but that's only because I listened to a
talk by Crockford once and never thought to draw my own opinion. As a Python
programmer I thought semi-colons were silly already and this talk only
entrenched the unfounded idea that _Javascript was bad_ in my mind.

I use them at work because when in Rome... but in my own projects there's no
need for them.

Currying is a nice effect of the fat-arrow syntax for lambdas. Currying in JS
is still neutered compared to OCaml or Haskell where it's the default but it's
still nice. Function composition is greatly enhanced by it. Python requires
special help to do currying.

As for tooling... it's the same deal in many languages despite all of the
marketing. It might feel painful to get a good development environment set up
for a Javascript project but it can be equally painful to setup a Python
environment if you haven't done it before (or a .Net, Java, etc, etc). I'm not
a huge fan of excessive configuration. But that's what you get with
programmers. We're a fickle bunch.

What Python does well though is to absorb good ideas into the implementation.
Function decorators, iterators, and soon mypy; when you go with the grain,
Python is a wonderful language.

------
TazeTSchnitzel
I disliked JavaScript, but then I read _JavaScript: The Good Parts_ , and I
saw that with a bit of discipline* there's something quite pleasant
underneath. It's a book that, rather than being focussed on telling you what
not to use, instead shows you various approaches to programming with what you
should use. If nothing else it'll give you food for thought and unlearn you of
your worst beginner habits. Mind you, it's a dated book and ES6 added a lot to
the language.

*don't listen to every suggestion of Crockford though; e.g. having to hoist your variable declarations is as obnoxious an idea in JavaScript as it is in C

~~~
dmitri1981
How is hoisting your variables obnoxious?

~~~
pluma
It mixes implementation concerns with functional concerns.

He recommends hoisting the declarations because that's how `var` scope works
in JavaScript. Normally you'd want to introduce variables where they're
actually used to provide context for them.

A variable definition at the beginning of a function implies the variable is
important to understand the general flow of the function. This can be
especially misleading for temporary variables like counters which only matter
within a particular loop.

Additionally assigning values halfway into the function implies they had
different values before, leading you to go back and check whether they were
assigned anything else (and used for anything else) or just declared without a
value.

Of course these problems can be avoided by simply using the new let/const
variables which are block scoped, but even here Crockford would likely
advocated for hoisting within the same block because of the Temporal Dead Zone
(i.e. a block scoped variable exists from the start of the block but
referencing it before it was declared is an error).

~~~
cerved
This is in line with his philosophy to eliminate things that produce little or
insignificant value but is a potential source of bugs. In this case variable
hoisting.

Of course you don't have to follow all his rules of what are good/bad parts,
some of which feel a bit Byzantine at times, but he has a point and usually
for a very good reason.

Check out the JsLint Google+ page for his views on more recent additions

------
eecc
Meh, all I got from this article is that this guy is writing a calendar app.

Perhaps that's the whole point of this post. ;)

~~~
jmull
Yes, but I thought it was pretty funny, so I forgive him his little
commmercial.

Anyway, I doubt there's room in the world for yet another calendar app... so I
also want to give him a break because I feel bad about him likely wasting his
time.

------
mhd
My problem with the current Javascript culture (which definitely includes the
React infospace) is basically the inverse how I felt about C++ back in the
day. Then, in the early years of the second age, I felt that the libraries and
frameworks I was using should use more of the then-current standard, like the
STL, RTTI or whatever was hip and promosing back then.

These days, it seems that every feature that is semi-supported in at least one
transpiler isn't just used (in various ways) but in fact begets a whole slew
of libraries. Especially when we're talking about ways to circumvent the
async-hole.

Other transpiled languages will either have the equivalent features, use lots
of inline JS or ditch large parts of the ecosystem. While the latter would be
possible if NewLangs standard library is big and good enough, I'm not feeling
particularly optimistic about that.

Quite likely that C++ history will repeat itself: Just use the core language
and a minimal library and do everything yourself (back then that was e.g.
C++/Win32/ATL, not sure what it'll be for my future browser-based projects.
Modula-3, I miss thee.).

------
inopinatus
I've gone through a similar experience with Rails 5.1 which has, having
ditched jquery, gained support for webpack, babel, yarn, and vue.js (& react)
instead; and thereby made writing JavaScript an order-of-magnitude less
painful for me.

I feel that ES6 is a palace built on the ruins of a garbage dump and an odd
stink still leaks through from time to time, but like the author, I can work
with it now without loathing what I'm doing.

------
GeneralMaximus
I primarily built frontend applications, so JavaScript is pretty much the only
programming language I use on a daily basis. I'm not in love with it (although
post-ES6 JS is quite pleasant to write), but I don't mind it as much anymore.

The reason? I feel like JavaScript is heading in the same direction as Java.
The core language is highly flawed, which has resulted in the community
developing build-time tooling and editor niceties to keep things sane.

In the future I expect to see more tools like Flow and Prettier, and existing
tools and editors becoming smarter. I'm excited for improvements to JS as a
language, but these days I'm more excited for new tooling.

~~~
simonlc
What are the flawed parts of the core language?

~~~
christophilus
The comparison `==` is basically something you should never use. `this` is
confusing for most people, etc.

That said, it's fairly easy to avoid these problems.

~~~
dbbk
> The comparison `==` is basically something you should never use.

This doesn't feel unique to JavaScript though? It's the same with, say, PHP.

~~~
cosarara97
And PHP is usually regarded as even more flawed than Javascript.

------
kreetx
This probably comes off as said from an ivory tower, but I don't think it's
the people from other untyped languages who hate JavaScript nowdays. ES6+
looks pretty good compared to Python/Ruby/PHP perspective, _and_ it works in
the browser!

~~~
amiga-workbench
I don't hate javascript for its quirks or implementation details, I hate what
it has done to the experience of browsing the web, and now what it is doing to
desktop software.

~~~
ztjio
You don't think a blinking cursor should use half your processing power, and a
handful of small text files shouldn't use all of your RAM? Pfft.

~~~
simonlc
That was actually a css bug in chrome.

~~~
plopz
And why should a css bug in chrome affect my text editor?

~~~
amiga-workbench
This is your text editor on meme tech stacks.

------
skocznymroczny
I switched to Dart few months ago, it actually makes JavaScript bearable. I
never get to see the actual generated JS code.

~~~
christophilus
Dart is surprisingly nice, considering how little I hear of it. I picked it up
recently as a target for my hobby project (a Clojure interpreter). Dart's VS
Code integration is phenomenal. Its VM is pretty efficient from a resource
consumption perspective (especially compared to the JVM). It's worth a look,
for anyone who hasn't bothered with it yet.

------
sAbakumoff
I really enjoyed the writing style of the article - "hottest shit on the
street", "It’s just a yarn install away", "DHTML was totally rad, like how the
Budweiser frogs were rad."...just brilliant! Also gave me a good nostalgic
feeling about DHTML..

~~~
0xffff2
I wonder what the split on this is. I gave up on the article pretty early on
specifically because of the writing style.

~~~
sAbakumoff
I am not a native English speaker, maybe that :-)

------
simonlc
Lots of people relate ES2015 to giving us a better javascript, but the core
language remains the same; the changes are just additions.

Building a tool chain can be an extreme pain in the ass because everyone is
still experimenting, and trying to make the web better. Things like web
workers, hot module reloading, and code splitting are relatively new, and
don't have mature tools or patterns. Yes it's hard to learn, and yes it takes
a lot of time, but once you learn a few tools you can keep using them over and
over. I've been using gulp and browserify since 2011, and recently switched to
gulp+webpack for code splitting, and HMR, and the switch couldn't have been
easier.

------
finchisko
I'am huge fan of JavaScript and personally don't like both Ruby and Python,
but would never write an article titled: "Ruby/Python for People Who Hate
Ruby/Python". I just don't use them. Writing such a article is IMO arrogant
and bad for your karma. I understand some programmers are forced to use JS
against their will (because there is not other person for the job), but if you
hate JS and you're not forced to use it, please just don't use it and then you
don't have to write such a negative and opinionated articles.

~~~
goatlover
JS is more on par with Ruby & Python these days feature-wise, but I just don't
see why one would prefer it. Ruby & Python are better thought out languages
from the get go. Go listen to Brendan Eich discuss how he had to rush JS out
the door as compromise between Sun & Netscape, and then how he couldn't fix
the language warts even before ECMA.

------
manx
I also started learning JS in the DHTML era and wrote small games and toys for
IE4. I did PHP stuff for almost 10 years and it was my main programming
language. But at some point I stopped doing webdev, since the whole thing was
a big mess and didn't seem to get better. I hated it. After a long break I
decided to do another web project again and worked with Scala in the backend
and Angular and ES6 in the frontend (about 2.5yrs ago). At first it seemed to
be a lot better, but we ended up with another working but unmaintainable SPA.
Adding new features required a lot of knowledge and was a pain. In this
project I tried and failed to implement a solid Graph Library in JS. This
motivated me to look at ScalaJS and write this library part of the app in
Scala. It worked very well and I was amazed by the JS interop. From this point
on I develop new web-apps with Scala in the full stack and am very happy with
it. I suggest to try it yourself for the frontend, since it has a very similar
syntax to JS. The type safety avoids most runtime errors and therefore painful
debugging time. Compile times became a lot better recently.

[http://www.scala-js.org](http://www.scala-js.org)

The real power comes when you share your data structures and algorithms with
the backend, get a type safe REST API and macro-based high performance
json/binary serialization.

------
DonHopkins
The best way to truly hate something is to know it very well.

------
rcarmo
I've been using Node 8 again after a few years of staunchly avoiding it, and
the pain of selecting the right kind of libraries to use async/await sanely
without having to massage promises (and .then()) is still there - in that
sense, I feel very much like that cat with the strawberry beret on the article
heading...

~~~
dbbk
Why are you having to bring in libraries to use async/await? What does the
native implementation not provide?

~~~
rcarmo
I'm not bringing in libraries. I'm trying to put together a set of libraries
that work well with async for my purposes (custom net I/O, databases, etc.)
without having to wrap them or fiddle with resolving promises on my own.

~~~
epicide
Is there something in particular that you do not like about Promises?

~~~
rcarmo
Yeah, having to deal with inconsistency across libraries inside the same
project.

~~~
epicide
I don't really see how Promises leads to that... do you mean the fact that not
all libraries support them out of the box?

Bluebird (probably my favorite Promises implementation) has nice features to
interface pretty easily between callbacks and Promises.

------
mr_ali3n
Sorry, not trying to be a d*ck here but I don't get the point.

You said you don't like the NodeJS eco system as you need to install thousands
of packages to get your work done whereas on the other hand, your find CRA
which uses tons of NodeJS packages to get the work done.

Secondly, code splitting, Babel, bundling has nothing to do with CRA, they are
just standalone packages which works well together.

Third, "What’s more, updates are great. It’s just a yarn install away.", Isn't
this something which NPM does as well?

Syntax - Again, nothing to do with ReactJS, it's babel which comes with
polyfills.

So am just curious here to understand that how exactly CRA changed your mind
where 90% of what you are doing is pure JS and has nothing to do with ReactJS?

------
vmware513
Interesting, because Create React App is fairly new tool, however Ember CLI
gives you the same thing for years now... so JavaScript World was always cool,
at least for Ember.js developers. ;)

~~~
shime
Ember CLI is a cool tool that preceded CRA, since it was inspired by Rails'
CLI tooling. Unfortunately that's the only good thing about Ember, since it
comes with the "batteries included" mindset making it one of the most bloated
JS frameworks.

------
tchaffee
One thing I like about the more quirky languages like JavaScript and PHP, or
even the far less quirky but still dangerous C language, is that they force
you to write good tests. You don't get the false sense of confidence some
other languages give you. I'm still not positive if static types are a poor
man's test suite, or if a test suite is a poor man's static types, but I find
tests are far more flexible and great at describing intent.

------
swlkr
The latest js tooling is certainly light years ahead of where it was last
decade, but it's a double edged sword, because now it takes a lot more effort
to get something going.

Indie hackers like myself are still better served by vanilla rails +
turbolinks, it gets you something that feels fast wtih a lot less effort.

------
tambourine_man
This guy's got a great sense of humor. I pissed my pents with the linked[1]
1x1.gif article.

Or maybe I'm just as old as he is.

[0]
[https://zachholman.com/posts/only-90s-developers/](https://zachholman.com/posts/only-90s-developers/)

~~~
w4tson
I enjoyed that bit too. I wondered how many people on here would have
experienced trying to layout a webpage with 1x1.gif up your sleeve

------
lopatin
> [Prettier] It’s basically like gofmt for JavaScript.

Gotta mention jsfmt, which is actual gofmt for JavaScript. Awesome tool,
hasn't been updated in a while though. RIP Rdio.

[https://github.com/rdio/jsfmt](https://github.com/rdio/jsfmt)

------
peterbe
Yes, CRA is a Huuuuuge step forward. [https://www.peterbe.com/plog/10-reasons-
i-love-create-react-...](https://www.peterbe.com/plog/10-reasons-i-love-
create-react-app)

------
vitomd
If React or Vue.js don´t click for you try Riot.js
[https://github.com/riot/riot](https://github.com/riot/riot) It´s a
minimalistic js library with a lot to offer. I made a tutorial some time ago,
I think it could give you a glimpse about what you can do
[http://vitomd.com/blog/coding/hello-riot-js-quick-
tutorial-a...](http://vitomd.com/blog/coding/hello-riot-js-quick-tutorial-
about-this-awesome-lib/)

------
dmitriid
Javascript is only going to get worse. Much worse. TC39 proposal "process" is
driven by a never-ending self-congratulatory circle-jerk. Any concerns are
dismissed with "people on TC39 discussed it, they know better, how dare you
question their wisdom".

While there's still time, escape to TypeScript (though it will be flooded by
crap from TC39 soon enough), ClojureScript, Kotlin, Scala.js, Elm, Purescript

~~~
ztjio
Don't worry, Web Assembly (or something similar) will soon be ubiquitous and
having one, thoughtlessly tossed together, horribly "designed" language which
constantly receives updates that are wholly ignored where it really counts
will no longer be the reality of web targeted development. If there is one
good thing about web dev today it's that adoption of new tech in the client
space is really fast.

Of course, personally, I solve this problem by refusing any job that requires
me to use JavaScript more than twice per complete solar eclipse. That's worked
quite well now for over a decade.

~~~
tempodox
> ...refusing any job that requires me to use JavaScript...

I'm getting jealous. Most job offers I see conflate software development with
web development and even jobs earmarked “backend” come with JavaScript
baggage.

~~~
menckenjr
Native mobile app development is the exception here if you can weed out the
"we need an iOS developer with a strong understanding of Angular.js and HTML5"
jobs or the React Native jobs that some consulting company talked a hiring
manager into thinking they need.

------
pluma
Nitpick: I'm guessing you mean 10,000% and English isn't your native language.
In English the period "." is a decimal separator, not a thousands separator,
so 10.000% means 10%.

EDIT: Holy cow, at least four downvotes so far. I hope the downvotes are for
nitpicking and not out of disagreement. As cakemuncher seems to disagree
(which doesn't mean they downvoted) this seems like a great learning
opportunity about decimal separators and non-native speakers:

The parent is most likely German (the example code uses German so that usually
means Germany, Austria or Switzerland) which uses the comma as decimal
separator and period as thousands separator. I'm German too, so I'm sensitized
to this mistake.

Here's the Wikipedia article for reference:
[https://en.wikipedia.org/wiki/Decimal_mark](https://en.wikipedia.org/wiki/Decimal_mark)

The US, the UK, New Zealand, Australia and English-speaking Canada all use the
dot as decimal mark. South Africa is the only major English speaking country
using a comma instead, but they use a space as thousands separator rather than
a period.

The parent clearly intended "10.000%" to be read as "ten thousand percent" so
that leaves the following list of countries which according to Wikipedia use a
comma as thousands separator:

Argentina, Austria, Bosnia and Herzegovina, Brazil, Chile, Croatia, Denmark,
Germany, Greece, Indonesia, Italy, Netherlands (currency), Portugal, Romania,
Russia, Slovenia, Spain, Sweden (not recommended), Turkey

Exactly zero of these countries are predominantly English speaking. So in
other words, in English 10.000% means ten percent (with a precision of three
digits after the decimal point), not ten thousand percent.

~~~
lopatin
Didn't downvote or anything, but come on .. we all know what he meant. This
thread is not the place for a "a great learning opportunity about decimal
separators and non-native speakers".

~~~
esolyt
> We all know what he meant

Having your mistake corrected can be educational even when you were
understood. In the future, inanother context, the same mistake could result in
confusion.

~~~
cel1ne
OP here. I agree.

~~~
pc86
Well since we're all being pedantic, OP means "Original Poster" which is the
person who started the thread (page, not this particular thread, which you did
start).

~~~
lopatin
I think that the meaning of OP depends on context. In general, you're correct.
But cel1ne can be reasonably be referred to as the OP in our convo, since our
discussion really doesn't have anything to do with the content submitted by
the Original Poster of the whole page.

------
davidreiss
People either hate javascript with a passion or they love it with religious
zeal.

Maybe it has to do with the fact that it's used mostly for web programming?
But geez, there seems to be no middle ground when it comes to javascript.

But it doesn't come close the division over Perl. Yikes.

