
How it feels to learn JavaScript in 2017 - eropple
https://medium.com/front-end-hacking/how-it-feels-to-learn-javascript-in-2017-a934b801fbe
======
seanwilson
It can be a pain getting the build system up and running but once you're
writing typed JavaScript code with modern features like async/wait and ES6
modules along with live + hot reloading, it's impossible to go back. It's
really trendy to complain about JavaScript changing too fast right now but the
last few years have brought some great changes to JavaScript.

~~~
aphextron
>It's really trendy to complain about JavaScript changing too fast right now
but the last few years have brought some great changes to JavaScript.

I'd say they've made JS development _bearable_ , but great is really
stretching it. We still don't have a type system, static analysis, multi-
threading, first-class IDE support, or any of a myriad of other features that
are standard in any modern programming language in 2017. I'm hopeful that
projects like Blazor[0] and other efforts being made toward bringing _real_
languages to the web via native WASM will put JS to rest once and for all.

[https://github.com/SteveSanderson/Blazor](https://github.com/SteveSanderson/Blazor)
[0]

~~~
seanwilson
Do you actually code in JavaScript? TypeScript addresses many of these issues
and even statically checks for null variable usage which puts it ahead of some
mainstream type systems in my opinion. I don't hear people making fun of
Python for example and that has a huge following.

~~~
mod
I mean, I do occasionally, but I think one big difference is that nobody is
forced to use python. If they want a feature a normal language doesn't have,
they can easily choose another.

That's simply not true for JS.

~~~
seanwilson
> I mean, I do occasionally, but I think one big difference is that nobody is
> forced to use python. If they want a feature a normal language doesn't have,
> they can easily choose another.

Most domains heavily constrain your language choice though...C/C++ for games,
Java/Kotlin for native Android, Swift for native iOS,
PHP/Node/Python/Java/Ruby for server-side. The libraries you need constrain
the choice even more. I'd love to use OCaml everywhere if I could but there's
just no support for it.

Anyway, my point is complaining that vanilla JavaScript is bad is a real
disservice to modern JavaScript. What's so bad about it if you use TypeScript?

~~~
nojvek
I love JS and especially the variety of tools available.

It's a double edged sword. But once you have your tools is great.

I love webpack, vscode, Typescript, npm, preact and mocha. All great tools to
solve a specific problem.

So much better than a number of other language. Have you ever dealt with the
horrors of package management with pip because it's inconsistent installs.

~~~
seanwilson
> So much better than a number of other language. Have you ever dealt with the
> horrors of package management with pip because it's inconsistent installs.

Personally I'm surprised the null/undefined checking feature of TypeScript
isn't raved about more which is missing from many typed languages.

------
revscat
We have recently implemented Angular4 in our project, and have started to pick
it up. Recently picked up a story that was adding a simple confirmation modal
to a page: "Alert" text in the top, body with some warning text, and a yes/no
button.

This was my first experience with modern JavaScript frameworks and TypeScript.
I wanted to do it right, so worked closely with team members who were more
versed in this stuff, and followed the various recommended best practices.

By the time all was said and done the PR for this thing had 27 files in it.

For a modal.

This seems ludicrous to me. The frustration, somewhat humorous, expresses by
TFA is completely understandable, though. While I came to appreciate TS, I'm
still skeptical about this JS framework stuff. They seem overly complicated to
me. (While I have only read casually about React, it seems similar in this
regard.)

~~~
0xFACEFEED
> This seems ludicrous to me.

Why?

UI is hard dude. UI on the web is especially hard because the technology has
been growing progressively for over two decades.

~~~
ktRolster
_UI is hard dude._

It's been a solved (and re-solved) problem for decades.

~~~
mercer
But has it been solved if you take into account the various
constraints/issues:

\- clients that range from tiny phone screens to full desktop screens

\- incompatibility when it comes to _what_ features clients support, and even
_how_ they support it

\- a foundation not meant for UI's that is pretty much required to be
abstracted away leakily (HTML, browsers)

\- serious limitations in payload file size for the entire UI codebase

\- much of the UI depending on asynchronous operations. The only 'UI' that I
can think of that is similar is when I SSH into my server. All other user
interfaces are mostly 'local'.

\- backend systems that are not optimized for these kinds of things

I am a relatively 'young' programmer, so maybe I'm utterly wrong about
thinking that, considering the above, we're in kind of uncharted territory. By
all means correct me!

All that said, I do get the feeling 'we' in the javascript world reinvent the
wheel more than necessary. But perhaps that's because none of the historical
solutions are 'complete' enough to get enough mindshare in the way that, say,
Ruby On Rails was, or jQuery.

Also, personally I'm becoming more convinced that until all this stabilized,
many of use (or at least I personally) might benefit from just not aiming that
high when it comes to UI. If I'm honest with myself, an 'old-fashioned'
backend that produces HTML with perhaps a few dynamically loaded components
(as just HTML fragments, even) is perfectly fine and I truly doubt it would
have a negative impact.

(hey carsongross, this is where you bring up intercooler.js!)

~~~
user5994461
Have you ever done desktop UI?

It does your checklist for 2 decades.

~~~
mercer
I've done stuff with Delphi back in the day, but I'm not too experienced.
Would you mind explaining point by point how desktop UI 'does' this?

For example, I can't really think of a desktop app where most of the crucial
app/UI logic is reliant on async communication with a server. Most data is
stored locally and permanently.

I'd actually really like to hear because I have been eying native development
lately!

~~~
vturner
Young developer here too, but I started about a decade ago with
robotics/desktop development. Thus, I can sympathize with the comment earlier
that desktop UI has done all this:

clients that range from tiny phone screens to full desktop screens -- Desktop
UI could support this if developers wanted to its just resizing a window. You
just don't see it because devs assume the existence of a mouse which allows
easing panning in a scroll bar window.

\- incompatibility when it comes to what features clients support, and even
how they support it - Desktop UI has or had solutions: Swing, JavaFX, QT,
Adobe's Flex.

\- serious limitations in payload file size for the entire UI codebase: There
have been desktop XML UI for so long. The oldest I can recall would be Adobe's
that went along with ActionScript to build Flex apps.

\- much of the UI depending on asynchronous operations. The only 'UI' that I
can think of that is similar is when I SSH into my server. All other user
interfaces are mostly 'local'. -- The desktop analogy here is some long
running process. Whether that is a slow disk, long computation, or some
network access, desktop UI solved this a long long time ago with a rendering
thread and worker threads.

\- backend systems that are not optimized for these kinds of things - not sure
what you mean here.

~~~
mercer
I think we're talking cross purposes. I'm not saying that there we never came
up with better things; far from it!

Rather, disregarding how we got here, the situation we're in _now_ provides
challenges that sort of justify the complexity and confusion we're in _now_.
Maybe this comment better expresses what I'm saying:
[https://news.ycombinator.com/item?id=14218425](https://news.ycombinator.com/item?id=14218425)

------
alayek
A refreshing read. Was expecting a satirical negative take on the complexity.

However, this only covers a small part of front-end development with VDOM
based approach, and a few ES6 constructs (destructuring, arrow functions, let-
const).

The author misses out on mobile development, Node JS and NPM modules, server
side, and Electron-based desktop apps.

It's a good thing to take the positive approach, and get introduced to some
interesting, low-barrier-to-entry items. At the same time, it would be prudent
to keep in mind what lies ahead.

~~~
andybak
I sense that the target audience is probably people who are already developers
but have a negative view on the current js ecosystem.

They are likely to be fairly happy with their existing approaches to desktop
and server development and want to learn to use javascript where it is
currently unavoidable.

------
eropple
I submitted this after 'brlewis linked it (it's his piece) in a comment
because it really hit home. Like, I've never used Mithril, but I dove into
React (both web and React Native) this year and it reminds me of when doing
web stuff was _fun_. Which, for me, was _before anyone was actually using
JavaScript_.

There are a lot of skeptics about modern JS frameworks, and I get it (my
inclination in every programming environment I've ever worked in is to avoid
frameworks, etc. until I know I need them), but _boy_ is this a big, and
awesome, change.

~~~
aaron-lebo
You know a lot of people are terrified of change and new stuff because it
might mean their skillset is obsolete.

That's a lot of what this backlash against JS is. Some of the criticism is
warranted, but a lot of it isn't, it comes from people who have never done
anything other than sneer at the language, and for every issue JS has, you can
find a matching issue in another language that either a) isn't a problem
because there are idiomatic solutions or b) everyone in the choir knows it's
dumb but they don't say it to outsiders, because why advertise your
weaknesses?

JS today is very expressive (more expressive than Python simply due to good
lambdas - not to pick on Python but it's a language that doesn't get the hate
of a JS or Go), it's been fast for awhile, it's got a dozen new interesting
frameworks, the tooling keeps getting better, etc. This can either scare you
or represent opportunity.

We've got a 5k line JS app. It was written by people who weren't programmers,
in a jQuery/d3 ball (it was still an impressive interface). Over the summer
we've converted it to Mithril and modern JS, now it's half the size, our dev
environment is setup with a simple npm install and npm start, we have reusable
components that multiple people can grok and use, it only takes a 20 line
webpack file to do this all, and before the summer started none of us had used
the framework.

It's amazing what it has enabled us to do and how simple the whole stack is.
I've been building desktop apps and small intranet web apps for a decade, they
don't hold a candle to what's possible if you harness this stuff. People can
complain all they want but this is what progress looks like. Someone might not
think it's cool that you can write an interactive single page application in
50 lines of code that anyone in the world can access, but isn't that what we
wanted?

It takes a day to grok this stuff, a week to build interesting stuff in it.
It's worth the investment, you might actually learn to do things you couldn't
before. That's fun.

~~~
thehardsphere
> You know a lot of people are terrified of change and new stuff because it
> might mean their skillset is obsolete. That's a lot of what this backlash
> against JS is. Some of the criticism is warranted, but a lot of it isn't, it
> comes from people who have never done anything other than sneer at the
> language, and for every issue JS has, you can find a matching issue in
> another language that either a) isn't a problem because there are idiomatic
> solutions or b) everyone in the choir knows it's dumb but they don't say it
> to outsiders, because why advertise your weaknesses?

I think a lot of the "sneering" is less about fear of "new" things and more
about frustration that old ideas that they previously considered are now being
presented as "new" by a generation of people who either did not see themselves
or did not ask an oldster about the old ways.

The tell for me, is in what things get the most sneered at. Node and npm tend
to get a lot of sneering, because they're essentially attempts at solving
problems people had already solved before. People don't sneer as much at other
things like React (except for its license and large number of dependencies,
and the latter is really npm/language sneering).

~~~
eropple
I think this is a pretty good analysis. NPM, to me, is a pretty consistent
string of "you did _what_ and _why_?" reactions. But once I get away from
that, to stuff like React, my attitude changes to "oh, yeah, this is good
stuff."

------
serpix
Having used only re-frame and Clojurescript for two years now every time I
look at where the Javascript guys are I roll my head.

Is nobody even slightly wondering how OOP has infiltrated modern JS
development?

Old school Java web development has fully seeped into Javascript with JSX
replacing JSP, OOP everywhere.. It looks exactly like the bells and whistles
of early 2000 web development.

~~~
twhb
That OOP is only skin deep. Look at the way data flows, which pieces of code
need to understand any given data structure. Look at the preferred way of
extending classes - composition. I think what we have now is not old-school
anything, but cherry-picked good parts together forming a New Thing.

~~~
serpix
Thank you for the clarification and insight!

------
raldu
The whole story felt sarcastic and also a little nauseous. Not exactly sure
whether there is intended sarcasm or not.

The process looks quite complicated where you have to figure out _lots_ of
"buts," "whys," and "gotchas," while keep telling yourself, "What the hell?"
all the time.

~~~
tonysdg
It's likely because it's a reaction piece to this article [1], which is almost
entirely sarcasm.

[1][https://hackernoon.com/how-it-feels-to-learn-javascript-
in-2...](https://hackernoon.com/how-it-feels-to-learn-javascript-
in-2016-d3a717dd577f)

------
vturner
"I have to confess, the build setup is the most intimidating part of modern
web development for me."

Here here.

~~~
tangue
I feel sorry for the generation who didn't experienced the "drop file on ftp
client, it's on the internet" experience. No setup, no build tools ...

~~~
ng12
I feel worse for the me of eight years ago maintaining an SPA codebase where
everything was thrown on window with dozens of global stylesheets.

------
cabaalis
I had a dev write some "modern" Javascript in a project. We neglected to test
in slightly out-of-date safari on Mac. Took forever to figure out that "let"
keyword was not supported.

~~~
aaron-lebo
You're probably aware of this but that's why you put everything through Babel
or Typescript to convert it. That setup is easy enough.

~~~
trynewideas
Assuming they read the post, they're not only aware of it but also read the
post's author warning their fictional subject about the performance problems
of using transpilers in production, and shrugging it off for the example
because it's just a learning exercise and "easy to change later".

~~~
troygoode
The warning in the content is (correctly) against performing the transpilation
in the client; the fix is to run the transpiler on your server, preferably as
part of your CI build process.

------
d--b
I was expecting another rant about how painful it is to navigate the hundreds
of framework out there.

Nice to see that people who dropped JavaScript a while get to find that things
are actually better today than they were.

------
briantakita
Want a library faster than mithril, no runtime download, & handlebars syntax?
Try Sveltejs.

Rollupjs also has "treeshaking", meaning your transpiled bundle only includes
the functions that are referenced allowing you to organize your code into
large modules or even use a monorepo.

~~~
chx
I am too old and I wrote an AJAX chat before AJAX was called that and before
jQuery existed. This left a mark on my soul manifesting in a very hostile
attitude towards JS.

But of course as JS spreads I am looking, reading and mostly just shaking my
head. But man, Svelte _makes sense_. For the first time in about 15 years, a
JS framework makes sense.

------
z3t4
you _don 't have to_ make a monolith web app, or use React, Angular et.al, or
transpilers, not even JQuery. State can be managed by observable pattern or
event listeners. example:

    
    
      app.on("new_private_msg", updateMsgBadge);
      app.on("new_chat_msg", updateMsgBadge);
    
      function updateMsgBadge() {
        this.badge.newMessages = 
          PRIVATE_MSG.reduce(msg => msg.unread)
          + CHAT_MSG.reduce(msg => msg.unread);      
      }
    

Parts of the app can be abstracted into micro-services. For example the signup
can be it's own micro-service. Or using the plugin pattern each widget can be
independent/untangled.

------
chrisweekly
Fantastic post. Best thing I've read on FE dev in many months. Bravo!

------
tomxor
I think a more appropriate title is what it's like to learn front end web
development in 2017, not much of the discussion has anything to do with
language details and everything to do with MVC and html.

------
alexchantavy
Helpful post! Glad to see actual instructive examples rather than a thinly
veiled "I hate js" piece.

------
dankohn1
That's a very impressive demo. I did Javascript development full time from
2012-2014 (Node.js 0.8 and Angular 1.0) and it's amazing to me that
essentially none of the constructs he mentions were available then. It wasn't
that long ago!

------
jgalvez
That article is focused on React/JSX. Having coded Nuxt/Vue apps I seriously
can't relate. With Nuxt you don't even have the build/setup pains. It just
works. It just builds.

~~~
mmcnl
You haven't read the article, apparently. It focuses on Mithril (not React).
And Nuxt simply abstracts the build step away server-side, so it's still
there.

------
Kiro
It's too bad they don't address state management. Right now it's just showing
how to bootstrap a static app without state changes. How do you even update
your data in Mithril?

~~~
brlewis
Static? That's half true.

    
    
      let planets;
      let planetFilter = planet => true;
    

The planets variable is static in this example, but planetFilter changes. The
"Voila, it works" link near the bottom of the essay leads to a live demo:
[https://brlewis.github.io/2017/planets.html](https://brlewis.github.io/2017/planets.html)

Was there a particular aspect of state management you want to hear more about?
I'm thinking of a follow-on post. Not sure whether the next one should be
state or build system.

~~~
Kiro
Oh, you're right. The state management was so subtle that it actually didn't
click when I read it. I don't understand how it knows to rerender though? From
what I can tell you're just setting the variable planetFilter and that's it,
while with React you would have to do a setState to register it.

~~~
aaron-lebo
You write your templates to handle the state changes, like:

    
    
       m('div, {style: `display: ${status ? 'block' : 'none'}`)
    

Mithril's diffing engine does the rest. If status changes it knows to rerender
that section.

~~~
Kiro
But how does Mithril know that status changes? How does it know you just
changed the variable?

~~~
pygy_
By default, Mithril redraws the app after DOM events fire (in this case
`onchange={filterHandler(func)}`), and when ajax requests are complete (using
the `m.request()` XHR wrapper).

You can also manually trigger a redraw by using `m.redraw()`, but it is rarely
needed.

------
williamle8300
The author should have mentioned Preact[1]. I'd argue it's better than
InfernoJS

1\. [https://preactjs.com](https://preactjs.com)

------
RandyRanderson
One day, with a lot of work, Javascript will have all the features languages
like C++, Java, and C# had before JS existed.

------
k__
Well, at least it's a web project.

I'm doing mobile projects at the moment, and it feels like going back 10
years.

------
abledon
Love the babel include in the src at the top. Great strategy for introducing
beginners to modern js.

------
ertucetin
Run away.

