
How it feels to learn JavaScript in 2016 - objectiveariel
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.l8ak5j3gz
======
okket
Previous discussion:
[https://news.ycombinator.com/item?id=12628921](https://news.ycombinator.com/item?id=12628921)
(19 hours ago, 108 comments)

------
marrs
In my experience, the developers who fall into this trap of despair almost
always do so because they aren't consciously choosing what tools to use;
instead they are letting the tools choose them.

They see job descriptions demanding AngularJS or ReactJS and they think that
they must learn it, or someone posts an article here and they don't want to
feel left behind.

Choose a library or tool because it improves your development process. If it
doesn't appear to improve it, don't use it (at least not unless external
forces compel you to). Especially don't use it if it appears that it will
retard your performance ( _cough_ Angular _cough_ ).

For example, after months (years?) of finding ever more efficient ways of
enforcing object interfaces (or even basic types) at runtime, I eventually
reached the limits of what JS and unit testing alone could acomplish and found
myself researching Typescript, Flow, and the like.

That's not to say I'm a user of either of those, but if I do choose to adopt
one in a project, I will know exactly what performance gain I am expecting
from it. I'm still very productive without them.

In fact, I've successfully avoided a lot of fads in the industry for most of
my career. It turns out that being able to explain why I _don 't_ use a tool
makes me look like I know what I'm talking about and not just cargo culting.
Employers quite like that.

Incidentally, this isn't unique to the front-end. I've seen the same thing
happen with the SQL->ORM->Mongo->Couch->SQL nonsense, or the myriad of
templating engines written for PHP, a language that itself _is_ a templating
engine.

~~~
hemancuso
How would you suggest developers actually figure out what tools to use? It is
next to impossible to make an informed decision without digesting a good
portion of what the OP is talking about. You need to start somewhere.

~~~
cloverich
Where the OP falls off is with stuff like "OMG don't use jQuery" or "no one
uses HTML anymore". There's nothing wrong with using those -- and frankly
using plain old javascript and HTML is fine. Remember we reached for jQuery in
the first place because the browser lacked features we wanted, and because it
handled cross browser stuff for us. That is, it simplified things _we were
already doing manually_. So the trap is bad advice like "use these 58
libraries" combined with an inexperienced person making the architecture
choices. I'd say instead (if you're the inexperienced person) just start
building stuff. Then every time you said "this is repetitive, I wish there was
a library that did this for me" \-- there will be. Go out and get it, and
you'll then understand why it exists.

~~~
mathgeek
I've been to more than one interview where I defaulted to jQuery and was
immediately disqualified, based on the looks on the interviewers' faces. As a
ruby developer, it certainly feels like keeping up-to-date on JS takes more
work than the other 90% of languages that I'm familiar with.

~~~
lloyd-christmas
Interview question: "iterate over an array":

    
    
      angular.forEach([1,2,3] ...
    
      $.each([ 1, 2, 3 ], ...
    
      [1,2,3].forEach(...
    

One of these things is not like the other. I hire people that know javascript,
not ones that only know the tool we use. The tool we use today may not be the
tool we use 6 months from now. I've never asked a javascript question that
required framework knowledge unless it was explicitly about concepts of the
framework. Someone taking the time to include jQuery is instantly out the
door. Walking through people's code demonstrates whether or not they default
to other people's solutions than their own.

This isn't to say your experience didn't happen, I'm just pointing out that
there is a lot more that goes into it than just which framework the cool kids
are using nowadays.

~~~
marrs
I have to say, this strikes me as an odd way of filtering out bad developers.
jQuery is a time-saving library.

It seems like you're presuming that they must lack proficiency in the DOM if
they're choosing to use jQuery. Perhaps you're trying to say you want to see
them demonstrate that they're not just copy/paste coders.

Given your code example above, I wouldn't want a candidate to know the
difference between each `forEach` method, but I would expect them to know that
each provides a means of iterating over a set of values.

~~~
lloyd-christmas
> I have to say, this strikes me as an odd way of filtering out bad
> developers.

I don't use this in my interviews, and I'm surprised everyone took this
literally given that we have a weekly blog article about the villainy of
technical interviews and how they destroy the very fabric of software
development. I'm using a hyperbolic example to demonstrate what I perceive as
a negative trait; A reach for unnecessary tooling to solve simple problems. My
hiring experiences have pointed towards it being indicative of a comfortable
one-trick-pony.

> Given your code example above, I wouldn't want a candidate to know the
> difference between each `forEach` method, but I would expect them to know
> that each provides a means of iterating over a set of values.

Likewise. However, if I'm hiring someone for a back end role, I'd expect them
to be able to know basic SQL and not just their language's ORM. I'd expect
them to be able to type `cd` and not just navigate through their IDE. I don't
think there is anything different between that and the relationship of
jQuery/angular and vanilla js. jQuery isn't written in jQuery. Debugging
rarely stops at the script tag/require statement.

~~~
mathgeek
My original comment was actually in the opposite direction: the interviewers
were looking for comfort with a framework other than jQuery that showed that I
knew more than vanilla JS. That was the frustrating part.

------
TamDenholm
I'm a web dev, been doing this 11 years. But i totally feel past it, granted i
code less and less nowadays so i havent kept up with new technologies.

I've hired people that are much better at web dev than me and let them
accomplish a task with pretty much whatever tech they want to use, because i
believe you shouldn't constrict a developer if you dont have to. Even for a
simple app that it'd take me 20 - 30 hours for me to create in basic jQuery,
bootstrap and simple PHP/MySQL, the tendency is to pull in Angular, Laravel,
gulp or grunt, composer dependencies and a whole host of code for doing
something really simple. It ends up becoming a frigging nightmare to maintain
and deploy, i just want to do a git pull and thats it deployed, but instead
i've gotta do artisan commands, migrations, grunt commands etc etc etc.

Anyway, i tell myself that what their doing is a better way of doing things
and i'm just someone with outdated knowledge, because when i do it, i use
basic tech and accomplish the same task in less time and with WAAAY less lines
of code. While its maybe not the best practices, its simple.

I still feel like a bad coder because i'm not doing it their way. :(

~~~
mehwoot
_Even for a simple app that it 'd take me 20 - 30 hours_

If your entire job is doing small apps that take a week of work, these tools
are not much better than the previous generation (personally I'd use Rails but
that's just one generation on from PHP/MySQL). Especially when you add in the
cost of non uniformity if you let everyone choose their own slightly different
flavour of the innumerable javascript tools available.

But as part of a team that has migrated a 5 year old codebase from Rails to
React in the last year, whilst I was skeptical at first, React has been an
absolute godsend. Everything we build now is so much more modular and much
closer to how non tech people view our website (and so how they ask for
features), which makes it easier to develop. React isn't designed to help "I
need to build this 20 hour website quicker".

I think the problem is mostly cargo culting. Smart and outspoken developers
use these tools, but they're also the ones dealing with complex problems at
their jobs, not everybody needs to solve the problems they are solving. And
"Honestly Rails is good enough for this app" doesn't make for a very sexy
meetup presentation.

~~~
enraged_camel
Sorry, I'm confused: what do you mean by "migrated a 5 year old codebase from
Rails to React"? What are you using as your backend?

~~~
problems
Just one of the many ways that modern Javascript baffles me - people pretend
the client and server are equivalent.

~~~
mehwoot
The more technical details you include the more people pick up and discuss
minute technical details instead of the point of what I was trying to say,
which is that my experience with a large codebase was these modern javascript
tools have solved a lot of problems we had.

If you want all the gory details here they are: it was a Rails 3 app using
Postgres and Elasticsearch that we migrated to React + node.js + webpack +
babel, elastic search as the data store and using Keystone.js for backend data
manipulation (which uses mongodb). Rails was indexing its data in
Elasticsearch already so we could start serving data through node.js
immediately without having to migrate all the data backend, which is being
slowly moved to keystone.js.

------
throwmenow_0139
It's easy to show how complex those systems are. It's easy because they _are_
complex. And that's pretty normal. Let someone talk about Java Enterprise
development, the symptoms of your body and their diagnoses or just try to
explain how to build a pencil
([https://en.wikisource.org/wiki/I,_Pencil](https://en.wikisource.org/wiki/I,_Pencil)).

We're professionals, after all, and TypeScript and React were not build by
some teenage hackers.

I think the problem is that everybody remembers how they build that one
website using jQuery in the early 2000s and now wonders why everything's so
complex now. The reason is that we started to build complex applications
instead of enhancing grandma's blog using jQuery.animate, get over it.

And if a software developer talks about all of this tools in the same manner
you've described, he has poor social skills, nothing related to the tooling.

He could also talk about the intricacies of scaling web services using k8s and
OpenStack and you'll find another bunch of tools and concepts. If someone
would actually talk like you've described it, he would play buzzword bingo in
any domain of expertise like medicine students who want to sound smart using
latin words.

~~~
raverbashing
> We're professionals, after all, and TypeScript and React were not build by
> some teenage hackers.

Overall correct

> The reason is that we started to build complex applications instead of
> enhancing grandma's blog using jQuery.animate, get over it.

And this is where we disagree

Complexity is needed sometimes, needless complexity only brings the overall
value down

If I want to do a website using Django I need to get: Django. Period.

I may need some other libraries, but they're much fewer than any basic node.js
project, even with things like Flask

I have one package manager: pip. It works

With express.js you need a library to _parse an HTTP request body_ ffs.
[https://github.com/expressjs/body-parser](https://github.com/expressjs/body-
parser)

~~~
veeti
> I have one package manager: pip. It works

Funny, because this is not the general sentiment in the Python community. See
links like [1], [2], [3]. Thankfully, things are improving.

[1] [http://lucumr.pocoo.org/2012/6/22/hate-hate-hate-
everywhere/](http://lucumr.pocoo.org/2012/6/22/hate-hate-hate-everywhere/)

[2]
[https://www.reddit.com/r/Python/comments/zrm3h/there_have_be...](https://www.reddit.com/r/Python/comments/zrm3h/there_have_been_a_string_of_posts_on_packaging/)

[3] [https://blog.ionelmc.ro/2015/02/24/the-problem-with-
packagin...](https://blog.ionelmc.ro/2015/02/24/the-problem-with-packaging-in-
python/)

~~~
witty_username
I found Python packaging very easy. pip install works for tons of packages.

------
Lxr
Thank god we have all these libraries. I mean remember the days when the back
button worked, pages rendered quickly without 3-second ajax spinning
animations, the browser remembered where you were when you clicked back, your
phone didn’t randomly jump around the page when you’re trying to read
something, and a syntactical fuckup didn’t prevent your entire site from being
rendered? Oh, and you could scroll normally too. And crawlers other than
Google could index your content, and blind people could listen to it. But
right, javascript is awesome, I probably just don’t understand enough yet.

------
Kequc
I feel like knowing which tools are useful, which ones are currently
dominating, and which ones are going to continue being supported in the future
is the best place to start learning JavaScript. This is difficult because the
ecosystem is so wildly fragmented and insane. You'll get a lot of different
opinions if you go searching for them, so here are mine.

ES2015 is the place to start, it is a finished stable release of the latest
version of JavaScript. It represents the single largest update to the language
in a long time and includes many features that make development easier. It is
being phased into web browsers natively and is the future of the language.

For maximum browser support you need a transpiler, this would be a matter of
preference because it isn't for you, it's for the computer. TypeScript however
is a very very clean transpiler and it offers optional features which are for
you, should you choose to use them.

Once you have that setup, you really don't need anything else. You don't need
jQuery unless you're trying to support IE8, which is a tiny proportion of the
browser market and that will gum up your code significantly.

Speaking of gumming up your code, nearly every single library out there is
bloat and can or should be avoided. React is very popular but it suits one
very specific use case, it should be used almost nowhere else. Particularly
since it is still new and evolving, it is going to cause more headaches than
it will resolve. Webpack is an enormous bloated nightmare for example, it
messes with even static html for little or no perceivable benefit and honestly
just avoid all of it if you're trying to learn JavaScript.

If you want the full-stack experience, Node.js is rapidly becoming the largest
JavaScript community on the net. You'll have your questions answered quickly
and there are modules for everything you want to do. Choose a markup tool for
html and css, such as pug and less.

There you go. State of the art front end JavaScript with two tools. Full stack
with five. If it wasn't for the whirlwind massive chaos of the JavaScript
community currently, fewer new developers would feel discouraged from becoming
involved.

~~~
lucb1e
> React is very popular but it suits one very specific use case, it should be
> used almost nowhere else.

Which use case?

I've never worked with React but from yesterday's stateofjs.com I got the
impression it's currently the go-to framework for everything.

~~~
Kequc
It gives you components. If your webpage is loaded and significantly complex
with a need for different things all over the place then it's for you. It was
built for Facebook, which has stuff everywhere on every page.

If all you want is a normal webpage, like a blog, like all of the websites out
there I'd say you do not need components. Just build your own object. That is
a lot of stuff just to do something that has been done for decades without it,
battle tested so to say. Another one of the problems with the JavaScript
community currently is the number of people who treat their favourite tool
like a religious experience.

React is a large hammer being used quite often to close a twist tie. The
ecosystem of tools which have sprung up around it is far worse than React
itself. Each one a larger amount of overkill than the last.

~~~
Ambroos
I'm sorry, but once you feel comfortable using React there are very few things
that React would not be a good fit for, however small the task.

I started coding in JavaScript two years ago, right at the point React was
gaining popularity. I made a gamble going for it 100%, and since then both the
company I was working at back then and the one I started working at recently
have fully switched to React for all new front-end development after seeing
how much easier it is than anything they'd ever used before (jQuery, self-
rolled prototype-based things, Backbone, Angular 1, Ember).

Yes, sure, you have to get the basics set up every time, and yes, sure you
have to package React on every page. But as a gigantic win, you get a uniform
way of dealing with the DOM every single time. React has well-defined best
practices by now. When every Javascript coder in your workplace is familiar
with React, it's usually best for you and for them to simply continue coding
in React.

~~~
Kequc
I feel that you are marginalising the amount of complexity you are adding to
projects which might not need it. There are multiple routes toward completing
the same task in development. My concerns surrounding additional complexity I
feel are well founded, there are costs associated with such a thing.

If all you are doing is DOM manipulation, without doing a huge amount of it,
that isn't such a complex task that it should require an entire framework. If
you're doing more than that it outscopes what React can do.

~~~
Ambroos
That's just it. If all your developers are familiar with at least the basics
of React and Webpack, you aren't adding any complexity. Once you know how
things work, a simple Webpack configuration with Babel and 2 presets isn't
complex anymore.

What would be complex, however, is introducing DOM logic in yet another way.
We're all used how you just define the desired state in React and letting it
figure out the transitions. When you suddenly ask your developers to write
code that manually manipulates the DOM and has to take care of all the
transitions between states, you end up with complex, unclear code that takes
everyone a long time to understand.

~~~
Kequc
Webpack alone requires hundreds of dependencies. You are populating your
node_modules directory with megabytes of code, any of which could stop
working. If you plan to maintain your code for years into infinity then it's
no problem. Otherwise the shop down the street doing the same thing without it
will be much better off.

------
awestroke
I have no trouble at all "keeping up" with the "insanity" that is front-end
development. If you're confused learning new things, it means you're learning.

At my company, we have moved a lot of our front-end code to eslint-checked ES6
with some plugins, writing react/redux powered interfaces. New hires generally
learn the codebase fast, you're well protected from shooting yourself in the
foot thanks to type checking and linting and the absence of globals. Our team
is many times more productive with this stack than with the es5 + knockoutjs
code we built with before.

If you're building a hobby project, just start with a <html> tag with inline
ES5 and css, and refactor and iterate from there. Use server-side templates.
"keep it simple". But when building client-side interfaces at a higher
complexity level, React is king.

~~~
coldtea
> _I have no trouble at all "keeping up" with the "insanity" that is front-end
> development. If you're confused learning new things, it means you're
> learning._

This naive view though assumes that all learning and all stuff to learn is
created equal and is all good.

That is, that the IT industry can't possibly produce junk for people to learn
("busywork", programming fads, over engineered platforms, oversold
technologies, etc).

People who have been through the J2EE-hell of mid-noughties, which even its
creators condemned and abandoned several years later, but which at the time
was touted as "THE WAY" to build enterprise software, and you just had to "man
up" and learn it, respectfully disagree.

------
k__
JavaScript is a very special language, I think.

When I learned it in 2011 it was already strange to me, coming from years of
work with PHP. Also, Java and C in university.

It was nerver meant to build big applications and had a few issues that many
people tried to assert.

Old implementations which needed stuff like jQuery to normalize the APIs, no
native module system so everyone implemented their own stuff (ExtJS, CommonJS,
AMD, etc.), strange scoping rules forcing variable aliases and wrapper
functions all over the place, functions as first class objects intruducing
people to a new world of possibilities with ideas from FP, prototype based OO
which comes with a different set of problems than class based OO.

The whole "we want new stuff now" movement forced many tools onto us to build
our software, which before could simply be run in a browser without
compilation. So we got rid of a few problems with a whole set of new problems.

------
peterbraden
I know it's super fashionable to hate on javascript, but I'd be very
interested to see a similar rant on another area of software. I'm pretty
convinced this is just how the industry works.

~~~
pjc50
The same _kind_ of rant applies to things like automake, but only Javascript
has this incredibly high rate of churn. Possibly it's easier to build a new
toolchain than to understand someone's existing one.

~~~
nkassis
That's been my annoyance too. Instead of iterating on what's there everyone
makes their own thing and tries to reinvent build tools, frameworks, web
components, module loaders, transpilers, package mangers etc... It is
improving somewhat. Some tools seem to be winning out and clearing the orbit
around them but were still in the primeval js solar system with a few planets
forming.

------
sotojuan
Occasionally designers seem to seek credit merely for possessing a new
technology, rather than using it to make better designs. Computers and their
affiliated apparatus can do powerful things graphically, in part by turning
out the hundreds of plots necessary for good data analysis. But at least a few
computer graphics only evoke the response "Isn’t it remarkable that the
computer can be programmed to draw like that?" instead of "My, what
interesting data".

\- Edward Tufte

------
shados
People writing these kind of articles are really not looking at their current
stack objectively.

If I'm doing backend, I have to pick from various languages, I often will
still need build tools (often more complicated) for various reason), you need
to spin up a server (or make an AWS account....maybe use S3, maybe not!), you
still have dependency management, etc etc.

Remember when Maven picked up, the bitchfests that surrounded it?

And debugging a server side app in production by picking at memory dumps,
profilers, etc? Its not exactly easy.

The difference is that those problems are understood, and everyone knows the
barrier for entry is higher.

The web platform used to feel like it had a low barrier for entry because it
was so limited and there was only so much you could do. Those barriers were
removed, so now its just as hard as anything else, except its not quite as
understood (the barriers were removed recently). So all of the peanut gallery
goes in thinking they can change the world in JavaScript, then realize they
actually need to learn to engineer.

A good example of that problem is all of the big companies and startups hiring
"full stack" engineers, which is code name for "pure backend engineer who has
10+ years of experience doing backend...and has heard of HTML".

Of course, that kind of people won't go far.

------
Scarblac
The worst is, if you don't keep up with this, good luck getting a web job five
years from now, you'll be the equivalent of a Cobol programmer. Can't get off
the train.

~~~
treehau5
And the best is, if you have a fundamental understanding of _plain, vanilla
javascript_ all these new frameworks are pretty easy to pick up. I went from
jQuery -> Angular 1.x -> Ember 1.6 -> Ember 2.0 -> React and Redux in
basically no time. It really wasn't that hard.

~~~
deckiedan
There's some truth to that.

My own experience was in writing a lot of vanilla JS, being pretty happy with
it, and then wanting to grow bigger I investigated some of the frameworks. At
the time, Angular 1.x was considered _the_ thing, so I implemented a project
in that (multiple drag and drop lists, items from lists into other lists, and
so on), and tried to follow best practices as far as I could tell. DRY,
decoupling, etc. It was pretty horrendous. I ended up with so many different
services, service providers, components, dependency injectors, and all kinds
of (to me) really quite complex abstract boilerplate that had nothing to do
with the actual business problems.

I eventually got it all working, and thought I was doing pretty good. I then
took a break from that project and came back to it 2 months later, and
couldn't make head nor tail of it. So many angular-specific concepts and
terminologies.

I've since come across mithril.js, and found it (for me) perfect. It's
designed to let you build stuff really fast, and modularise things around your
business logic, rather than have the whole of you application design enforced
from the framework. Leo's blog posts [https://lhorie.github.io/mithril-
blog/](https://lhorie.github.io/mithril-blog/) are fantastic, and I think made
me understand a lot more of javascript itself, and how to design applications
in much more 'well designed, but not framework specific' ways.

------
jbb555
I do feel that the javascript people have made C++ look simple. Not so much
the language perhaps, but making programs in it..

~~~
nkassis
I dunno I think they are on par as far as toolchain goes. autotools, cmake
etc.. are no worse or better than gulp, webpack etc...

------
cjhanks
I spend my time in C++ and Python land the majority of the time. I have had to
jump in to fix front end bugs a few times... This page reflects my experience
fairly well. I spend hours trying to find the magic incantation of bower,
grunt, less, npm and/or make, shell, versions to make one line of JS change.
And I sincerely hope it gets better. I _want_ to develop web sometimes, but
every time I approach a new code base, I feel like I am starting from ground
zero.

------
raverbashing
Very accurate

And if you go for X instead of Y you're obviously a non-hipster loser that
hasn't been up to this week's fad

~~~
jomamaxx
The later part of your point is salient: the weird hipster 'magpie' culture in
front-end programming has a lot of drawbacks.

~~~
talmand
The part I find funny is considering how often the "latest great thing"
changes so quickly is that it shows a decent developer can shift to another
thing in the ecosystem quickly. Making the "if you aren't using Brand X, then
you're behind" attitude seem kind of silly. Considering the response can
easily be "give me a few hours and I'll be using Brand X". I've shifted
through a dozen or so "latest thing" in my career without much trouble at all.

------
petetnt
As these rehashed JavaScript versions of
[http://harmful.cat-v.org/software/xml/soap/simple](http://harmful.cat-v.org/software/xml/soap/simple)
are on front page of Hacker News every other day, I can't even begin to
imagine what kinds of rants we will see in the next 15 years or so.

~~~
majewsky
"How it feels like to learn Machine Learning in 2025" (9 years from now, 671
upvotes, 158 comments)

------
paradite
In defense of JavaScript, there is an article that appeared here not long ago:

[http://mrmrs.io/writing/2015/07/27/too-many-
tools/](http://mrmrs.io/writing/2015/07/27/too-many-tools/)

Basically all these new terms come out because people are constantly trying to
improve the ecosystem and make it better according to their own standards, be
it more modular, more robust, or more scalable.

Eventually winners will emerge and the losers will die out. Give it a few more
years and it will stabilize.

------
alistproducer2
I've always been of the mentality to use a tool only when the efficiency gains
outweigh the learning curve. This is, of course, impossible to judge without
spending a lot of time understanding exactly where your efficiency bottlenecks
are.

The truth is, a complex application is going to be complicated no matter what
tool you use. I look at application programming like this: the more
complicated it is, the more likely it is that you've missed key requirements
early in the process. This means you will likely need to refactor, rearrange,
add/remove features, etc. Choose tools that make this inevitable process as
quick and painless as possible. For me that's the number one goal.

I reject tools that make picking a project back up a week or two difficult
because of dependencies or weird hacks, syntaxes, or configurations that
worked fine when they were fresh in your mind but required an hour of your
life to retrace how you got there using the tool.

For example, I chose to use a library that used generators to eliminate
callback hell in a screen scraping project of mine. I did this for no other
reason than it was too hard to modify the scrapper when everything was nested
8 levels deep. I didn't know what generators or coroutines were before that,
but I had spent enough time with my problem to know that I was going to hit a
serious maintainability wall unless I found a more clear syntax to write my
app. In that case, it was worth the inital overhead of learning new parts of
ES6 and programming language concepts.

------
thght
Unfortunately this is pretty accurate..

------
GrumpyNl
I can not emphasize this enough. Keep it simple. I see to many software
written through solutions just because they are a hype. Pick the right tools
for the job.

------
oolongCat
In my experience the whole complex JavaScript comes when you try to build the
entire thing using JavaScript.

If you are developing a web app, restrict JS to the client side only, get
something like react to do it.

On the server side I stick with Go(lang). This separation helps me and my team
think of these two separate problems, well.. separately. Isomorphic this
isomorphic that is when things start to go all in sane.

tldr; JS for front-end. Go for back-end.

------
tkubacki
And that's way I feel much more comfortable in Dart ecosystem:

\- sane SDK and sane - not surprising - lang without _this_ hell

\- jquery like functionality built in

\- one package manager and package repository

\- can be used on server as well

\- nice tooling (WebStorm-IntelliJ, VisualStudio Code)

~~~
kingmanaz
Would have preferred that Google had put their resources behind something like
GopherJS instead of yet another C#/Java-like, feature-creep prone language.

~~~
tkubacki
their reasoning was AFAIK - lang needs to be C#, Java like to reach mainstream
web devs

------
scottmf
Funny, but it's not quite that complex.

How about "Here's a link to a CLI utility or git repo which will give you a
working project in 2-3 hours"?

I took a break from web dev for some years and had barely used any JS
frameworks besides jQuery, until June, when I began working on an ambitious
project and quickly got up to speed with the state of JS.

I'm using React/Redux/Sagas/Webpack/etc. for the client, and Express (with ES6
and what have you) for the API.

Developing with these new technologies has been a delight, especially compared
to hacking bits of jQuery together.

Sure I've had to learn a lot of new concepts, particularly after being away
from this world for so long, but this has always felt like a continual
learning process to me.

We are the early adopters, the cutting-edge types. If you want to work with
aging technologies there are plenty of companies invested in them.

Otherwise you can learn React in a few hours. What's the big deal?

~~~
lucb1e
> which will give you a working project in 2-3 hours

> you can learn React in a few hours. What's the big deal?

Assuming we are still using the same example (filling a table with some data
and filtering it), I think 2-3 hours is a good example of how long it takes to
write that in plain Javascript and testing it on every browser back to IE6
while having lunch in between.

~~~
erelde
Funny, I actually had that last year in a 2 hours midyear exam, access to
Internet authorized. I was the only one to complete the exam and had the best
mark, didn't use internet, just my own code lying around my pc, finished in
half an hour, vanilla js/php LAMP.

But many of my class couldn't do it.

------
programminggeek
Sometimes jQuery is all you need. Sometimes you don't even need that.

------
HugoDaniel
Lucky for him he didn't ask about tests :)

------
holtalanm
"I need to display data on a page, not perform Sub Zero’s original MK
fatality."

This sums up my opinion of the whole
React+Redux+Webpack+SatansSeventhCircleOfHellLib combination.

------
chriswwweb
I think people that don't like to constantly learn new stuff shouldn't be
developers in the first place ... personally this is the part about web
development I like most. I love to write prototypes and experiment with new
stuff.

Second JS is not changing so fast imho and there are not so many frameworks
that stand out of the crowd. Yeah there are lots of frameworks and libraries
on github and even this is a good thing because it shows JS has a vibrant
community that loves to create stuff. But it's not like you need know all of
them, if you are really lost and don't know what to choose, just ask other
developers around you or check out websites like
[http://stateofjs.com/](http://stateofjs.com/) and you will notice that there
are not that many frameworks that get used by a lot of devs.

------
jpalomaki
A common problem when I try to switch to platform that I haven't been paying
close attention to. It is very difficult to quickly figure out what is the
current stack of libraries and tools you should use if you are starting now.
For example jump to the .NET and it is not so obvious should go for Core,
Asp.net Core, how to do data access, which version of EF to use and so on.

Usually it is very difficult to find this information from anywhere. Articles
and blog posts get outdated fast. Material produced by vendors is usually a
bit biased. You get to see all the good things, but they might forget to
mention stuff that is still under development. If you are new to the field,
you don't know the right people and right blogs.

~~~
shados
And that's why no amount of good will and side projects will make up for hard,
real world experience.

------
jiaweihli
There's no need to jump straight into the deep end of tooling.

An iterative approach works really well here - do a brief survey of what tools
there are and what problems they solve. Then, when that problem starts soaking
up a lot of time, you can read up on the available tooling in greater detail.

There _are_ a vast amount of libraries in the js ecosystem, and it'll take
time to fully understand all the different pieces. It took me nearly 2 years
to achieve an understanding of most of the buzzwords in that article (and even
then, there are some I still haven't worked with directly).

In my personal experience, learning JS is very much a BFS process.

------
nbevans
Very accurate. The web is still highly immature and the rate of change is
proof of that. Very much looking forward to WebAssembly (and its full adoption
by web browsers) so then we can end this madness once and for all.

~~~
brunoc
I hear this a lot, but I don't get it. How would this help make things simpler
or stop "this madness"? If anything it opens up the possibility for even more
crazyness. The only difference is you (maybe) get to pick your favourite
language instead of learning new ones.

~~~
nbevans
It's not so much about picking your "favourite" language. That's what drove
NodeJS to exist. But more about picking a more _appropriate_ language that has
a well engineered base class library and third party libraries. They will
come. This comes down to choosing the best tool for the job at hand.

JavaScript developers have been able to, in recent years, benefit in some ways
by being able to write their server-side in JS as well (see NodeJS). There are
various buzzwords to describe this capability. WebAssembly will help normalise
this so that other languages can also have this capability. By being able to
share types between the server and web browser client, there are large
productivity and program correctness gains to be unlocked.

~~~
bobajeff
People are hyping up webassembly way too much. Don't get me wrong it's going
to be awesome being able to compile C++ and C programs that run on the Web
runtime.

But it's not going to be without it's own issues. For one developers will
likely have to wait for things like simd, pthreads or 64bit ints until later
versions.

Also it won't magically make compiling your language of choice to the web less
painful unless it's C++ or it fits into the C++ language model. Even when it
gets the ability to hook into a garbage collector (I wouldn't count on it
happening any time in the near future) it will likely have to fit in with the
way js engines expect.

------
clebio
The frontend frameworks wars are pathological. It's useful, to me, to remember
_why_ that's the case: because web sites/apps have to support every browser
make and model out there. But how do we know that? Presumably from testing. So
its funny that there's isn't any mention in the article about browser testing,
or harnesses, or what-not. So now there needs to be another iteration of this
series where we step through PhantomJS, Selenium, AWS Device Farm, etc. etc.
(and shout-out to Quirksmode and Caniuse).

------
mckoss
Loved the Trump-ism buried in the middle of the dialog.

------
zengid
JavaScript devs have an embarrassment of riches when it comes to
tools/frameworks. It is overwhelming yes, but this anecdotal ranting is
counterproductive. JQuery still works excellently, and so does ReactJS if you
have the patience and time to learn it. One just needs discretion when
distinguishing the tools of the avant-guard from the tools of the pragmatic
workhorses.

------
triplesec
Why I Hate Frameworks (2005) is climbing back up the charts, probably because
of this very news thread. Here's the link to that:
[https://news.ycombinator.com/item?id=12635142](https://news.ycombinator.com/item?id=12635142)

------
interdrift
No seriously it's crazy. I tried doing some MEAN stuff for a while(I'm backend
and can do some WPF UI MVVM ). Anyway it was insane I'm not doing any
javascript development. Why would I ? Come to .NET we have cookies.

------
drewpc
To me, this topic highlights the difference between a developer/programmer and
a software engineer. As a small business owner, If I'm hiring a
developer/programmer, I'm looking for specific skill sets in a given
language/framework. I don't expect to hire a PHP programmer and throw them
into React/Mobx/Webpack/Gulp/Babel/Websockets without a tremendous amount of
training. Frankly, I don't even expect them to know SQL in any sort of
advanced way. I'm paying less for that person and getting less in return. I'm
taking on the challenge of "growing" them into what I want them to be in the
future or letting them go if our project pivots

When I hire a software engineer, however, I'm paying more and getting more
(hopefully). I expect software engineers to understand engineering principles
and be able to work in almost any language. At a foundational level, they
understand the basics of compiled vs interpreted languages, OOP vs functional
programming, client vs server, optimization, testing, databases, networking,
software release life cycle...and how to employ all of those. I expect to give
them a business problem and have them develop an entire technical solution
using whatever tools are best suited for that job.

In most cases, projects are a good mix of both software engineers and
developers/programmers. The two can balance each other out and produce amazing
things.

Lastly, everyone should be looking to improve their knowledge of their own
industry. If you are a developer/programmer/software engineer, you should be
looking at what is new/upcoming in the industry. You need to remain fresh or
you become obsolete. In a very small example, the move from Python 2 to Python
3 has been a long road. If you are not aware of the improvements in Python 3
over Python 2, how can you actually determine if Python 3 is a good choice for
your project? How can you take advantage of the improvements? What about Go vs
Python 3? How does Erlang/Elixir fit in to the equation?

------
vlunkr
I feel like everyone needs to be reminded that this post is probably more of a
joke than anything. Not criticizing JS so much as a buzzword-iness surrounding
it

------
beardicus
Holy shit these articles are truly tiresome.

I am learning Javascript in 2016. I also learned it in 1998. It was a simpler
time back then, sure, BECAUSE YOU COULDN'T DO MUCH. Rollovers, alerts, scroll
some annoying text in the status bar of a browser. This was about the extent
of it.

I can do SO MUCH COOL STUFF with 2016 Javascript. Much of it comes with a
complexity cost, but of course I'm free to code "raw" Javascript in the
browser just like I used to. Instead, I choose to learn some new tooling,
because the leverage it gives me to execute my ideas is worth the effort.

------
Globz
Damn I feel so far away from reality..I am still using vanilla JS (plain old
JS not the framework) & JQuery....yet I have no problem.

------
buremba
"-Ever heard of Python 3?" (go to top)

~~~
lucb1e
People love to joke about Python 3 and I totally get it. But compared to
Javascript, the mess is _nowhere nearly_ as great.

To make python 2 code compatible with python 3, a few things need changing.
For 99% of the code it's very simple, and for the 1% big changes, well, you
just need to go through it and refactor some of your code. People have been
postponing this but we are well on our way. During the transitioning period,
new stuff gets written in py3 and old stuff still runs with the py2. People
have both installed. No big deal.

Now Javascript. There is plain javascript with slight variations for every
browser. There are a million frameworks, a new one that becomes majorly
popular about every two years, and they all work very differently. There is no
single, straight upgrade path, it's almost like using completely different
languages. There is no "we are nearly done with the transition". Instead there
is five new frameworks to look at every year, each of which uses five others
as dependencies (angular 2's tutorial is a good example, last time I checked)
and one of which will become popular next year, by which time you're outdated
if you haven't tried all five. The only new thing that needs explaining in
py3, as far as I know, is byte objects vs string objects. Then a few syntax
changes (I think OOP changed a little bit) and you're done.

~~~
buremba
I totally agree that Python is much less problem compared to Javascript but I
think that it's not fair to compare a backend language to a frontend language.
My only complain is that Python is not great at async operations so people
have to create unstable async libraries such as gevent and it's usually cause
trouble in production. Luckily Python 3 solves this problem but backward
compatibility is one of the most important things that is important in a
programming language. People usually develop backend services once and
maintain it for years but frontend is subject to change more often.

~~~
falcolas
> My only complain is that Python is not great at async operations

For most asynchronous IO operations, the old standby of threads works an
absolute treat. There are certain pathological corner cases where a single
thread can be blocked, but for the other 99.9% of use cases, it works
fantastically.

Build your synchronous and stateless web code and throw it into a thread.
Done. Even the more complex cases of a single worker needing to make multiple
asynchronous calls can be handled easily without even having to leave the
standard library.

Now then, this falls apart a bit when you have to deal with global state (and
the assorted locks and deadlocks), but most web backends aren't too hard to
write statelessly.

~~~
greenshackle2
But spawn enough threads in Python and you risk entering scheduling hell,
thanks to the global interpreter lock. EDIT: if you are CPU bound at all. If
you are really really IO bound it's not a problem.

Event-driven programming is my go-to for nontrivial backend async in Python,
and in Python 2 you almost certainly want to use a third party library for
that.

(But maybe I'm just lazy. I try to avoid the headache of threads in python if
I can.)

Python 3 has asyncio, which looks good, though I havn't used outside of toy
projects at this point.

------
mountaineer22
My favorite line from the article:

"I need to display data on a page, not perform Sub Zero’s original MK
fatality."

------
grif-fin
The picture on the top sums it up.

------
jdauriemma
How it feels to learn parallel parking in 2016

"I want to parallel park in that parking space."

You'll need a car first.

"When I was a kid I just walked into the parking spaces."

Yeah, but that's not really parallel parking, you were just walking into a
parking space.

"Oh ok. So I'll get a car then."

Well, it's not that simple, you have to actually get inside the car in order
to parallel park.

"What? Can't I just push the car?"

No way! First you have to unlock the car, start it and put it in gear.

"Oh. OK, how do I do that?"

First take out your key.

"What's that?"

It's a small attachment that should have come with your car. Then press the
unlock button.

"I unlocked it and am sitting in the seat. Ready to park?

"Not quite. first, you need to put the key in the ignition"

What is an ignition?

"It's the small hole on the side of the steering wheel. Now turn it. No, the
other way.

"OK, let's parallel park!"

Hold on now, you need to adjust your seat, rearview mirrors and side view
mirrors to ensure that you can drive safely.

"But I don't want to drive, I just want to parallel park!"

It doesn't work like that.

"Fine. How do I get these side view mirrors to adjust?"

Well, first you have to select which mirror you want using the switch to your
left, then push the directional arrows until it's at the correct angle.

"How do I know what the correct angle is?"

There are lots of opinions about this, just search Stack Overflow.

"This seems like a good angle. Let's park!"

Hold your horses, first you have to put the car in Drive...

...

Some things that we take for granted as simple really aren't and never have
been. Within a generation the above will be completely outdated knowledge and
you'll get a car from point A to point B using an app, with its own
complexities and absurdities at which we can poke fun in blog posts.

~~~
dasil003
Just because you put words in that format doesn't make this a good analogy.
You can teach someone to drive, including parallel parking in a couple of
hours and then they just have to practice. The javascript ecosystem is
legitimately complex. You can't just hand wave that away with a rhetorical
flourish.

~~~
jdauriemma
Part of the reason why people can learn to drive in hours is because they have
been riding in cars as passengers since birth. Though new at driving, they
have lots of contextual knowledge and awareness. If you took someone who grew
up on a desert island and taught them to parallel park, it would take
considerably longer.

Likewise, experienced web developers have years of contextual knowledge of
CLIs, documentation and coding. An experienced dev can reasonably be expected
to bootstrap a JavaScript app within a few hours, even if they only used
jQuery in the past.

~~~
dasil003
Also because we have evolved with complex spatial awareness as an innate
trait. Yes, I have been developing websites since 1994, and I have been on the
bleeding edge most of that time. Of course I can come up to speed with
whatever stack du jour the kids are fawning over these days, but that doesn't
make it simple.

------
mirap
This article looks like some dialogue taken from Fallout 1. :)

------
serhat
JS should have stayed where it was, in the browser ;D

------
inputcoffee
Still laughing but if you want to know what:

1\. people use

2\. people are happy with

Try the results of this survey:

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

------
jlebrech
i miss the days of Borland where the IDE would just run darn the thing.

------
throwawayReply
This misses the point.

It's about the unit test.

jQuery is easy to develop with but difficult to unit test.

React is slow to develop with but easier to unit test.

For small projects, jQuery is better.

For large projects where the all the persons writing it tomorrow might not be
here today, pick the testable one so they have a chance of future refactoring.

~~~
nkassis
Unit tests is not the primary way to choose one frontend framework or another.
It's one aspect to look at but i don't think this boils down to unit tests at
all.

------
forthefuture
It's so interesting to me that so many people complain and no one does
anything.

If Javascript is so bad just make any other JIT compiler run in browsers.
Defeat the argument with action.

I'm comfortable with my build process. I have a package.json and a
gulpfile.js. I run npm i, then gulp dev. For every new project this is
automatic.

Don't follow trends if you don't want to, but I don't believe anything in the
OP was difficult if you understand why you're doing it and learn it properly.

~~~
grabcocque
The proliferation of frameworks _is_ people's attempts to do something about
it. But then XKCD 927 applies.

~~~
kzisme
Link for the lazy: [https://xkcd.com/927/](https://xkcd.com/927/)

------
spion
> What's wrong with HTML?

Its impossible to share data between JS and HTML without reimplementing parts
of JS in HTML from scratch, or rather, implementing a HTML-like template
engine from scratch in JS. The model just isn't designed to do what we want it
to.

Web components are working on this, except they're reimplementing every
modularity feature that JS already provides (HTML imports, shadow dom) from
scratch, and then they're implementing every feature that React gives you
(custom elements) from scratch. But its still too early, and most tutorials
don't show how it works beyond the simplest examples (I would be convinced if
I see a data grid component demo with custom item rendering per column which
supports passing table data from JS)

------
frigo_1337
I'm getting tired of these pointless non-specific rants. You could write an
article about "How it feels to learn C++ in 2016" and make it all about the
complexities of operating systems, linking, compilation, text editors and the
QWERTY keyboard layout, and you'd still be as accurate.

All you need to "JavaScript in 2016" (as a beginner) is a config file and one
or two commands. That's it. If that's too information or too hipstery for your
taste, then follow the footsteps of other programming languages and use an IDE
with a button that can hide that complexity for you.

~~~
justinsaccount
> All you need to "JavaScript in 2016" (as a beginner) is a config file and
> one or two commands

And 3 months from now in 2017 those 2 commands will be deprecated because no
one uses those programs anymore.

~~~
frigo_1337
As far as beginners are concerned, that shouldn't really matter.

Hide all that complexity in a `./build.sh` or `make` and hand them a config
and a README. The author of the article is a web designer with a slightly
technical problem to solve. He didn't even need to know about gulp, or grunt,
or webpack or babel. Those tools are (should be) as relevant to his domain as
the tools used to manufacture the circuits that run them.

~~~
justinsaccount
Not everyone is a beginner web designer. Some people are trying to build
things from scratch using JS.

"Just use this magic build.sh!" sounds a lot like "Just use this magic starter
kit!" or "Just use yeoman!"

Who is supposed to write this 'build.sh' in this scenario of yours?

Without fail, every single magic build system or magic starter project I have
ever used is now deprecated and abandoned.

    
    
      Makefiles? No one uses those anymore, use Grunt!
      Grunt?  No one uses that anymore, use Gulp!
      Gulp?  No one uses that anymore, use webpack!
    

I have a react app that I built on top of a starter kit that I now need to
rebuild using create-react-app because the build process broke when I tried
updating something.

Meanwhile, I can pick up a python project I worked on 10 years ago, or a go
project I started 4 years ago and everything works exactly the same.

