
How it feels to learn JavaScript in 2016 - jjperezaguinaga
https://medium.com/@jjperezaguinaga/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.758uh588b
======
meddlepal
Just a couple days I got into a conversation with my coworker about UI stuff.
I had to test something against our dev UI. Last time I did UI work was back
when having index.html, img/, css/ and js/ directories with maybe a script or
two was the norm. I had to fucking run make and I still have no fucking idea
what was going on when I ran make which compiled a bunch of shit. There was
all this NPM shit going on (isn't NPM part of Node.js which is a server-side
framework? WTF?). I got it working and promptly noped the fuck out that horror
show.

The web is a giant fucking pile of dog shit in 2016.

~~~
Fuzzwah
I'm a content guy who knows enough web dev to be dangerous.

I made 3 manual edits to a css file to fix a couple of incorrect background
colours in our web content the other day. I was a good boy and made a pull
request for those same changes in the git repo.

Our developer explained that he doesn't actually edit the css file. He would
have to work out the change in the hue (as a percent of the base colour) and
update that in the sass file, then use gulp to compile a fresh version of the
output css.

He said that this was a simple build process to get set up on my machine so I
could do it myself in the future.

He uses a mac. I use windows.

4 hours later after hitting so many hurdles I finally got it working. I can't
even recall all the issues, but do recall that I side stepped them all by
moving to a particular version of npm which actually used a sane system for
storing the dependencies.

With out that version of npm this simple build process required 15,000 files
in my node_modules subdirectory in a structure so deep and convoluted Windows
couldn't create them....

Of course now that I'm armed with the toolset to make these changes I've
reverted to testing changes in chrome dev tools and emailing him requests.

~~~
LaxisB
a big problem with npm is, that a lot of package authors don't use the
.npmignore [0] which leads to EVERYONE downloading your source/, test/ and
docs/ folder even if only that one file in build/ is needed. That, combined
with the micromodule mindset, leads to insanity

[0]: [https://docs.npmjs.com/misc/developers#keeping-files-out-
of-...](https://docs.npmjs.com/misc/developers#keeping-files-out-of-your-
package)

~~~
pdimitar
That's a very bad way of handling it. When will people learn that you can't
rely on everyone being a good citizen? Is it really so hard to realize that
you need to make your technology sane from the very beginning?

------
alexmuro
If you are doing a simple project, there is nothing wrong with just using
jquery (or imho d3). If you know that your project is always going to be
pretty simple or especially if you are learning.

I have been teaching a number of people javascript at my lab lately and I
think its unwise to teach new javascripters using any of the modern tools or
transpiling until someone runs into one the problems that those tools solve.
Having been a javascript coder consistently from the jquery days until now, I
am not pining for the simple old days of yore.

It can be hard to learn everything that goes into a big front end app these
days but when used correctly all those tools are there for a reason.

~~~
mpwoz
This needs to be higher.

You shouldn't use any of these tools just because people tell you to. If you
can't see what problem something solves, then start at a simpler/lower level
of abstraction until you run into that problem, and can appreciate the tool
that solves it.

Of course, this advice doesn't apply if you actually need to write a
production app, and aren't just playing around for learning purposes :)

------
tibbon
This is pretty much why I don't do front-end. I'm fully capable of it, but I
just don't like keeping up with this flavor-of-the-week. It just doesn't feel
like programming to me, or at least not the programming I enjoy.

Strangely, I see so many new developers rushing toward the front-end, which
seems much more complicated in many ways than just building solid web API
services, analyzing data, etc.

~~~
choicewords
There is a money issue.

If you do keep up, you'll get amazing job offers.

If you manage to really be on the edge, you can give talks as well, expose
yourself as a consultant.

That's much easier in JS than with Ruby, Python or whatever else.

~~~
tibbon
Fair enough. I've hit a sweet spot now in having done Ruby for ~8 years, so I
can get away with saying, "having someone else deal with the front end. I just
want to talk about data".

The new problems I'm working to learn to solve are with ML, NLP, etc. I'd like
to step away from web services completely soon, and just live completely with
data.

~~~
gettersetter
I am curious, how did you transition into ml, nlp. I am thinking of
transitioning to ml, as work is getting kind of boring for me, but most job
requires at least a master in the relevant field. I am self studying right
now, maybe going back for a master, but I felt I lack alot of necessary
probability and linear algebra theorems. I can code svm, neural network from
nothing. I understand basic markov chain, bayes network, but that is really
just scratching the surface. Any recommendations?

~~~
thomasahle
The 2016 ml scene doesn't seem so different from the 2016 front-end wild west
I gather from this thread. Unfortunately. Machine Learning is in rapid flux,
the solid theory of svm and the like are getting abandoned for a lot of
techniques that seems to work some times. Certainly some people have a very
good intuition for what works, and how to make it scale, but there is no one
authority and you have to keep constantly up to date.

------
gadrev
This was actually a didactic piece.

While criticizing the current state of affairs, it gives a nice overview of
many of the emerging technologies and how they fit together, even if for some
tasks it feels retarded to pull such an entangled mess of dependencies.

You can then go insane diving into any particular one :)

~~~
pbh101
Being primarily a Java dev, it felt to me like half of this was critiquing the
churn rate of using different tools (warranted) and the other half was
lamenting the fact that people built tools to solve the common problems they
have when developing in large teams (largely unwarranted). Most of those tools
have direct equivalents in the Java ecosystem (and there is tool-churn in Java
too, just slower).

Facebook, Google, large startups, and the others which are building these
tools are doing so to solve the problems they experience in their teams'
front-end dev processes. Ironing out the kinks in the code assembly line. And
they are of course doing so in a path-dependent fashion: add tool N+1 to solve
problem N+1 given the existing toolchain. The result is a lot of tools and a
lot of context to imbibe at once, but it doesn't mean they are solving
nonexistent problems. Just problems you don't have, or don't know you have, or
don't have yet, or can afford to leave unmanaged when developing a small site
with just a couple people.

~~~
JustSomeNobody
Yes, it is called "Enterprising the sh __out of it ". And yes, Java (and
C#/.Net) has a huge problem with that and Javascript is well on its way.

Large companies love to get cool haircuts and wear torn jeans and talk about
building fast and being agile and yet, they continues to build
frankenprojects.

~~~
pbh101
I can't speak to other projects, but I know the additional pieces of tooling I
add to my buildchain are there to automate tasks that are otherwise
undocumented/uncaptured and thus easily forgotten (Joel Test, step 2). On a
team of ~50 core committers and ~100 intermittent committers across the globe
(which isn't that big compared to other teams), if it doesn't have a CI build
running and passing regularly, it will eventually break and stay broken.
Examples: code generation, database schema generation and checking, dependency
compilation, building artifacts. Other pieces of tooling I add to
orthogonalize and amortize common tasks, e.g. Dagger2, Immutables,
AutoFactory.

Again, I'm not familiar with flavor-of-week web dev stacks and I'm not
defending all of it, but there are clearly steady-state benefits to tooling,
even if the initial setup often ends up being a maze because it isn't in the
critical path of core developers.

I think there is huge benefit to be gained from projects considering the
aggregate bootstrap effort required to get the whole stack running. But I
still think this fragmented, modular approach, even with the downsides
discussed in this thread, is better than the likely alternative: depending and
waiting on a company like Microsoft to deliver a monolithic development
environment for which a Product Manager has spent literally years crafting and
honing the bootstrapping experience before release.

EDIT: wording

------
dhruvkar
I couldn't get through the entire thing. Even knowing that it's a
fun/sarcastic piece of writing, the portrayed pain is all too real, as someone
just starting to dive into the front-end.

In all honesty, can I still use jQuery for new projects without issues in
2016? Is there a real reason not to?

~~~
vinceguidry
Yes, you can. No, there's no real reason not to.

But honestly, I'd go with React if you can. The reason is, if the app starts
taking off, and you end up with a team maintaining your app, you're much less
likely to end up with an unmaintainable mess in two years than if you use just
jQuery.

All applications, especially websites want frameworks. The framework is
essentially a way to organize the massive amount of complexity boiled in. If
you just roll with libraries, then you end up cobbling together a framework on
top of it. You will then have to maintain this framework. This is fine when
it's just you, it will coalesce into a bunch of conventions that's fairly easy
for you to reason about.

But once you start involving others, then you're going to see your nice
conventions get rekd like a bull in a china shop. Not everybody sees problems
the same way you do.

If you pick the framework beforehand, then you don't need to maintain it, you
can let the nice people at Facebook / Google do it for you. And whenever you
finally get others involved, they're limited in the amount of architectural
damage they can do because they have to stick to the conventions of the
framework.

~~~
thatswrong0
I agree - I think React is simple enough that there's no reason not to besides
the overhead of JSX preprocessing (which I suppose isn't required but I would
definitely recommend). It really is more of a library than a framework, which
is great for starting out because there are fewer concepts to understand. Then
when you start adding more people and your application gets more complicated
and you need to manage your data flow in a more consistent way, you can add
something like Redux after the fact incrementally. As long as you don't let
components become too large, refactoring isn't too difficult.

~~~
andybak
React isn't _that_ simple. You still have all the package
manager/transpiler/build baggage. You still sacrifice pages that aren't blank
if javascript is disabled of fails and all the potential SEO/accessibility
costs of that.

And you suddenly end up with great globs of javascript in a page that might
not need it.

~~~
thatswrong0
None of those things has anything to do with the inherent simplicity of the
library itself.

~~~
andybak
Out of the two simplicities one has an actual impact on usage.

~~~
thatswrong0
I guess what I really meant to say is that you could levy the exact same
concerns on many other libraries / frameworks. None of that is specific to
React.

I guess I was also assuming that if the OP was considering using React in the
first place, that they were doing more with jQuery than just minor
interactivity improvements. But I suppose your concerns are valid if that
assumption isn't true. I'm thinking app, not blog.

~~~
andybak
Maybe he was but I do worry that anyone new to front-end is being pushed
towards frameworks rather than being told to start with the simplest approach
possible.

I saw a comment from someone a few weeks ago who knew angular but had never
used jQuery. I was rather baffled how that had come to pass!

------
adamrezich
Cross-posting my comment from reddit:

I don't know about anyone else, but the problem I personally have with the
crazy, messy JavaScript ecosystem is:

\- I am a relatively experienced amateur programmer (with limited [nine
months] professional experience)

\- I can learn any new programming language, library, methodology, or whatever
pretty easily

\- I don't have any formal experience using anything of this newfangled stuff;
like the author of the article, my frontend experience involves plain ol
HTML/CSS/JS, with a little jQuery to make things easier

\- nobody wants to hire me unless I have `n` years experience with newfangled
language/framework/methodology `x`, `y`, and `z`

\- I don't have a CS degree

Unless you're a massive operation like Facebook or something... just give me a
week to look through your website's codebase, I'll figure out how you guys do
things and I'll start being productive before you know it. If you're using
stuff that I've never used before, I'll learn it.

I _should_ be a _more_ attractive hire than someone who has `n` years of
experience _only_ using `x`, `y`, or `z`, because the way I think about
getting things done with computers isn't tied down to any one specific
framework... but it seems that this isn't how hiring works in the industry
right now... which is directly at odds with the rapidly-changing nature of web
development!

As a result, I don't feel inclined to learn any of this new crap. What's the
point? Apparently I should've learned it all `n` years ago, and it's too late
now?

~~~
nikdaheratik
It sounds like your gripe isn't with the knowledge base, but with the people
doing the hiring. The issues there are very real in that, if you're dealing
with a non-trivial codebase, there's no way to tell whether someone with very
little real world experience is a competent programmer or just "faking" until
you've got them working on it for a few weeks, and even then they may not be
worth the time you put into training them until a couple of months down the
line. And the people in HR for most organisations don't have a clue how to
tell the difference.

So they make up a bunch of gatekeeper requirements that allow them to filter
out anyone that doesn't fit the mold early in the process. They're still
likely to find someone who can do the work this way even if it means throwing
out a decent percentage of other candidates.

It's messed up, but it's kind of where the lack of technical knowledge in HR,
and the need to avoid any potential lawsuits have left us.

~~~
adamrezich
This has been my exact experience. I just had a week of phone calls and emails
about a very promising, well-paying frontend job opportunity. All of them were
with no-technical-knowledge buzzwordy HR types who were very friendly and
assured me that my resume and portfolio were great, and that I would be a good
fit for the job. The whole thing ended with a phone call that went something
like:

"Hi, so, your resume says you have nine months of experience?"

"Well yes, but I have countless personal projects under my belt, I designed
and built game engines with teams of students..."

"Yes, but this position requires four years of professional experience."

"Well I still think I'd be a great fit for your company, I have experience
with the specific technology stack you use, you can ask my previous
employer..."

"Yes, but this position requires four years of experience, so, I'm sorry, but
you don't meet the qualifications."

"Oh. Okay, thanks, bye."

Another story:

I got a call about a job I'd applied to. The guy on the phone said I looked
like a promising candidate, but my resume didn't list the start and end dates
of my previous job (nine months total), as I'd accidentally sent an old
version of my resume. I emailed the correct version of my resume, and nearly
immediately got an email back, saying, and I quote:

"Needed 1+Years of Experience so if you can change the duration time"

After a few minutes of consideration, I edited my resume to change the end
date of my previous job to be one year from the start date, saved it as a
separate copy, attached it, and sent it back. The guy immediately replied
asking me to verify that the 50k starting salary would work for me. (Before
anyone says 50k is too low, rent is due and I'm desperate.) This was just last
week and I haven't heard back since but this is the most promising opportunity
I've been able to find after months of searching.

\---

The thing is, I don't even _want_ to do frontend web development. I want to
work in game development, but apparently to get a start doing _that_
professionally, I need professional programming experience on my resume to
look good because those positions are so competitive. Okay, fine, I can do web
development, front- or backend, I thought. That'll be great for padding out my
resume, and, y'know, paying rent. But it turns out that landing one of these
jobs is also really difficult!

What frustrates me about all of this is not so much my own position, but about
the future of the industry. As time goes on, I think we're going to see more
and more people take the path I took of learning stuff on their own instead of
at college. Formal CS education is far from useless, but if this stuff's all
available for free online, people are going to download it, play around with
it, and learn how to use it... it just seems crazy to me that companies are
hiring just-out-of-college CS graduates over people who have made a ton of
stuff on their own over the years.

~~~
noxToken
Two things:

 _All of them were with no-technical-knowledge buzzwordy HR types who were
very friendly and assured me that my resume and portfolio were great_

I don't inherently agree that this is how it should be. I do understand that
businesses want to minimize risks (don't hire bad employees for 6 months)
while saving time (don't interview them in the first place). One of the
easiest ways to achieve the latter is by having minimum requirements.

The rebuttal to that is always having a good interview process that measures
the candidate on a personal level while also getting a feel for their
technical prowess. This is another problem. Some people think all-day
interviews are perfect for this. Others want to show up for an hour or two,
white board something relevant, and call it a day. Some want take home
project. Others demand that potential employers pay them if they're so keen on
giving a take home project.

I don't think there is a silver bullet. I think there are objectively better
ways than other when evaluating talent such as being flexible. For example, a
new graduate will almost never have 2 years of professional experience. A new
graduate may have an impressive GitHub profile filled with _completed_ , demo-
able projects alongside contributions to other people's projects. While not a
direct substitute, this is a damn good indicator.

No one can seem to agree on the entire process though, so we're stuck with HR
Henry and his checklist.

 _(Before anyone says 50k is too low, rent is due and I 'm desperate.)_

Depending on your location, $50k can be plenty, Where I live, $50k is great
salary for a single person. Also, pay isn't the only thing that makes a job
worthwhile. My starting salary was competitive, but definitely at the lower
end. The work/life balance, however, came slightly before salary.

------
trowawee
It continually shocks me how much whining developers do about sometimes having
to learn new things. The requirements for continued education are shockingly
low (read: non-existent) in our industry, compared to other, similar
intellectual/white collar industries - doctors in California are legally
required to do 50 hours of CME/2 years, lawyers in California are legally
required to do 25 hours of CLE/3 years, and those are both fairly standard.
There are a tremendous amount of jobs out there that won't require you to
learn anything new, ever, if you don't want to (think of how many thousand
brain-dead Java jobs are out there). There are plenty more that will require
you to learn one or two new things (any of the hundreds of consultancies and
companies that picked a fairly standardized stack and work with it all the
time). And then there is a tiny subset of companies that are actively working
with new tech and trying new things, and a tiny subset of people actually
using all of those new things. Whining about how "it's too complicated!"
because someone somewhere provided you with some new programming tools for
free because they thought those tools were useful and cool is an ugly look for
a profession that's so prone to patting itself on the back while loudly
proclaiming how forward-thinking it is.

~~~
brianvan5155
Learning in other industries is offered in institutional settings as part of
the profession.

Learning in the dev world consists of aimlessly screwing around with an
undocumented, unsupported, glitchy web/server stack for many many hours unpaid
after you've already spent 40 hours that week putting bread on the table.

The whining has less to do with the "learning" and more to do with the yak-
shaving part of it torturing us endlessly in the off-hours. And, unlike in
medicine and law, there is precious little professionally-written, detailed,
helpful literature to help us along the way. There's just "quick install" and
then a command/api reference. That is... not up to the level at which medicine
and law have their industry practices & standards documented.

------
sotojuan
I'm in a weird position where I like JavaScript and Node but dislike frontend
(or at least I am disliking it more and more).

With Node, I can get quite far with just a couple of dependencies that install
quickly. I don't need transpilation unless I want to use TypeScript or
PureScript and I can target any version I want. I find it very fun to mess
around with Node and a bunch of little modules.

I am slowly "transferring" back to server-rended pages using Node or Elixir.
Probably not good for my employment (even in NYC most JS jobs are frontend),
but whatever.

If I was learning JS right now and didn't care about employment I'd just learn
Node (which just means learning JS really) and experiment with stuff.

~~~
cycomachead
JavaScript, admittedly, has a few more quicks than the average language but I
quite like it. I know a lot of people who also feel the same way. (And as many
how, of course, hate JS.)

It still feels to me like we're in the early days of node and the dev
infrastructure for "modern" sites. Hopefully, things stabilize soon(ish).

------
patmcguire
Reminds me of "starting Rails today is like starting to watch a soap opera in
the 7th season"

[http://words.steveklabnik.com/rails-has-two-default-
stacks](http://words.steveklabnik.com/rails-has-two-default-stacks)

Be thankful, at least it's not 2013, the new-js-framework-on-the-front-page-
of-HN-every-day era.

~~~
gremlinsinc
yeah many old-timer rails folks will say skip rails and use Phoenix instead
lol.. for concurrency and all.

------
_Marak_
I've found using Babel / React / transpile tool-chain is actually fairly
impossible to use for the majority of developers. I've given up on it several
times in favor of plain-ole-javascript and jQuery.

The amount of time it takes to ramp-up on the technical knowledge isn't
insurmountable. The main issue is bloat in both code size and dependency chain
instability. On a slow connection, you might find yourself battling against
your tool chain for half the day. In the case you actually hit a code problem
with the underlying technologies, it's going to be hours if not days searching
Github for the patched version of the module. If you actually are able to path
the specific dependency, it will probably break something else.

I do have hope though. We are starting to see a lot of really cool Babel /
React components and projects. I think with a bit more time, we'll get
stability in the eco-system as there are less deltas to the underlaying code
dependencies and the browser vendors catch up with ES7 features.

------
hiester
Like a lot of 21-year-olds, javascript has gotten big and strong, but its
brain hasn't finished developing yet. It hasn't figured out what it wants to
do with its life. It engages in binge drinking a little more than is healthy.
It's sowing its wild oats. Didn't we all when we were 21 (or didn't we wish we
did)? It has 3000 Facebook friends. Last year it had a best friend, but now
it's hanging out with someone else and doesn't even talk to that other one any
more. It's kind of preoccupied with being cool and popular. Young adults can
be very self-conscious and anxiety-ridden. Constantly checking its status on
social media ("OMG, I wonder what I look like on iOS 10?") probably isn't
helping things. Still, it's really smart and helpful and has a lot of talent.
Give it time. Cut it some slack. It will find its way, make something of
itself, and make you proud. You'll see.

------
at-fates-hands
You also have to keep in mind a few things:

1 - I've never referred to myself as an "engineer" since I don't see myself as
one, nor do I have an engineering degree. This includes the fact I do not have
a four year CS degree either.

2 - Front end development has now split. Being a web "designer" means you know
HTML5, CSS3 which includes LESS, SASS, PostCSS and other CSS pre-procssors

3 - Being a web "developer" means you're more likely to be a Javscript
developer. Meaning you're familiar with Angular, Backbone (I know its soooo
2014 isn't it?), React and other JS frameworks. Every interview I've done in
the past two years has almost exclusively focused on JS and how well I know
standard JS. Closures, inheritance, debugging, etc. Nobody cares if you know
much else other than that.

~~~
Pherdnut
Where are you interviewing? All I get is Angular and React questions for
interviews where I stated up-front to the initial contact that I'm no expert
on either and have tended to stay focused on core technology developments when
studying on my own time.

------
okket
Loosely related: "The S stands for Simple"

[http://harmful.cat-v.org/software/xml/soap/simple](http://harmful.cat-v.org/software/xml/soap/simple)

~~~
mturmon
This is insightful. Of course, the OP is consciously playing off the earlier
app-deployment spoof ([https://circleci.com/blog/its-the-
future/](https://circleci.com/blog/its-the-future/)).

But this earlier spoof may well be based, intentionally or not, on the SOAP
piece you linked -- which was a hit on HN 7 years ago
([https://news.ycombinator.com/item?id=2079631](https://news.ycombinator.com/item?id=2079631)).

Thus prompting the observation and related question: These three areas -
front-end, deployment, RPC - seem to have engendered a churn in standard
approaches, and a corresponding cultish devotion to certain toolkits --
leaving them open for satire. But yet, there is also a need for a guru to
explain WTF to do, because a lot of practitioners need to get these jobs done.

So, what is the deeper parallel between the areas? E.g., a lot of corporate
resources suddenly poured into these problems, and everyone is funded to come
up with, and promote, their own solution?

------
laacz
As a person who has to build a relatively simple webapp from time to time,
it's tiresome. I usually take a look around - what's trendy. It results into
lost night, since I learn that everything requires two times more stuff than
six months ago.

In the end I go with vanilla JavaScript and whatever new APIs I can use and
polyfill.

No, wait. I made a webapp with React. While occasionally seeing Flux and
friends mentioned, I was strong. I went with vanilla ReactJS.

I mean, those web stacks just get obsolete too soon. Your super tuned gulp
setup will be obsolete in a year or two. What will you do then? Re-learn all
new things?

It seems to me that there is a frontend development stack bubble coming. When
I had to change bootstrap's base font size, I had to download and learn awful
amounts of stuff. Which is on my machine. And I will never use it again.

------
carsongross
If you are sick of javascript on the front end, but don't want to give up the
fancy-pants UI, you could do worse than my library, intercooler, which lets
you add AJAX to your app with a few HTML attributes.

[http://intercoolerjs.org](http://intercoolerjs.org)

Make REST work the way it was intended, supports CSS transitions, request
indicators, etc.

Good little library that eliminates a lot of complexity for web apps that
don't need all this junk (most of them.)

~~~
commentzorro
Just saw intercooler referenced in a post a couple days ago and took a look.
It does look refreshingly simple to get started.

I've got a basic app with JSON end points already created. I was going to give
VUE a go but after looking at intercooler I'm going to create an alternate set
of /IC/* URLS and send out HTML instead. I'll soon see how it works for this
task.

~~~
qohen
_Just saw intercooler referenced in a post a couple days ago and took a look.
It does look refreshingly simple to get started._

Aaaaaand...we've come full-circle now:

 _Intercooler depends on JQuery, version 1.10.0 or higher._

:-)

~~~
commentzorro
_> Intercooler depends on JQuery, version 1.10.0 or higher._

I don't have any real problems with jQuery being in the mix for intercooler.
Even with that, jQuery appears to be an underlying library used for
convenience rather than a library an intercooler coder would have to know and
code against.

I do appreciate the irony when taken in context with the original article
though.

------
buckbova
"It’s 2016 man, no one uses jQuery anymore, it ends up in a bunch of spaghetti
code. Everyone knows that."

I prefer "jQuery soup."

------
romaniv
And to think that I went into web dev precisely to avoid dealing with complex
build chains and horrible UI libraries...

~~~
Cthulhu_
That's because when you started, all of the complexity was in the back-end;
this has moved to the front-end, with backends becoming simpler and more
focused on providing data.

~~~
romaniv
The overall complexity was still order of magnitude smaller. There were no
transpilers, shims, or complicated multi-step builds, and I knew every single
library I was using.

------
vladimir-y
Article title is absolutely not correct, front-end developer is supposed to
build an entire UI and corresponding client-side logic, not just write some
abstract JavaScript code, code itself is nothing. So it's not about write JS
code, but about building maintainable and scalable applications.

All that stuff is actually required to build something maintainable,
especially modules. React is not a silver bullet, but nowadays SPA and
components approach should be familiar for any front-end developer. I like
Typescript was mentioned there.

------
imgabe
I guess I'm behind the times in that I still use jQuery. Is it really
worthwhile to go through everything described in this article to create a
simple filterable table?

~~~
brlewis
Yes, it's definitely worthwhile moving past jQuery, but no you don't have to
do everything described in this article. There's a lightweight framework
called Mithril that when used with MSX will give you the feel of React, i.e.
the state of your app flows in a straightforward way from the state of your
objects, rather than from a series of imperative jQuery operations.

Just start with this example and customize to what you want to do:

[https://github.com/insin/msx/blob/master/demo/index.html](https://github.com/insin/msx/blob/master/demo/index.html)

~~~
skipants
This comment is kind of ironic, isn't it? OP asked whether he has to use a
framework (albeit a seemingly-complicated one) and you suggest another
framework for him to use. Not saying you're wrong, or anything. I just found
it kind of funny.

~~~
brlewis
What comment are you referring to where someone asks whether he has to use a
framework? The comment I'm answering is this one:

 _I guess I 'm behind the times in that I still use jQuery. Is it really
worthwhile to go through everything described in this article to create a
simple filterable table?_

There's a vast difference between everything described in this article and
using _a_ framework.

------
rcarmo
Wow. 140+ comments and nobody mentioned the Python 3 jab :)

Seriously now, I gave up front-end stuff when it began requiring me to use
Node to bundle files together, and find it terrifying to see Yeoman used as a
code generator for non-JS runtimes and frameworks... building software atop
quicksand (be it frameworks or libraries) that shift every week is insane, and
it feels like the modern day version of just-in-time job security.

My use of thumb these days is to not use more JavaScript than what I can read
in one sitting, unless a) it's D3 or a similar single-purpose library and b) I
get a Docker container to run npm and all its funk inside that I NEVER have to
look inside of.

My dream is that JavaScript dies and that the industry moves to something like
Elm, ClojureScript or TypeScript, with a functional and/or hard typed
approach.

------
krylon
This makes me think of a sentence I read years ago: "We love to fight
complexity with complexity."

I think whoever said this referred to the various IPC methods on Windows, but
I do not remember for sure. Seems like some things never change.

------
jlas
Reminds me of [https://circleci.com/blog/its-the-
future/](https://circleci.com/blog/its-the-future/)

~~~
egwynn
FTA

    
    
       The following is inspired by the article “It’s the future” from Circle CI.
       You can read the original here (https://circleci.com/blog/its-the-future/).

------
istjohn
This was spot on for me as a hobbyist who has returned to JS after a hiatus of
roughly 3 years. On the one hand, it's exciting to see JS evolving into a
sophisticated language with dozens of new constructs specced out. On the other
hand, as a casual enthusiast I feel trapped between using a small subset of
the features available, or wrestling with a tangle of temporary crutches while
implementations catch up with the new standards.

------
tempodox
It's bad enough the facts on the ground make it a virtual impossibility to
circumvent JS altogether. The best we can do is always wearing gloves when
handling it and to never write it manually.

JS, for the oversimplified thing it is, is just systematically overextended
with the loads it has to carry now. No framework on earth will make that go
away. And neither will ES6.

------
egwynn
See also: [https://medium.com/@boopathi/it-s-the-
future-7a4207e028c2](https://medium.com/@boopathi/it-s-the-
future-7a4207e028c2)

~~~
btym
I knew I'd read this somewhere before!

------
dvcrn
I know the irony of introducing a new tool in the comments of this particular
blogpost, but a while back I decided to completely ditch javascript and go the
clojurescript route. I've been super happy ever since.

The syntax is stable, clojure is extremly well designed, the ecosystem a lot
clearer and tools - well you have lein as the main one and that's about it. On
top of clojure, you get google closure for free and can optimize the hell out
of it with advanced mode compilation out of the box.

And that's the 'vanilla' experience! No separate library required! You can
still interface with normal js and npm modules of course but you find yourself
using npm install a lot less.

All major tools have cljs wrappers that are just a joy to use (looking at
reagent (react), re-frame (redux), om (react+graphql)

------
avesus
Some parts of the article go too far (developers finding their own ways to
make things, continuously), but common idea of using Babel and writing in
modern JS is prevalent - because you have to use a bundler to concatenate
source code and import dependencies. But using a bundler feels like a compile
step - and it's so easy and desirable to add another step and enable modern
JavaScript ES2016+ in your web app. And this part is now a standard de-facto,
but some people use make, others gulp, I happy with npm run or just bash
scripts. But common idea of bundling and JS compiling holds true for all
developers.

Actually, not yet completely solved problems in terms of consensus how to do
things stay here: delay loading (login form/admin panel/main app code or
features separation), component assets dependencies, modular CSS, and, of
course, frontend and server side architectures with CycleJS, Elm, SAM, Redux,
Angular 2 as candidates but those yet have unsolved problems: either work slow
(and making simple app's size more than 1 MB zipped) or you have to write some
boilerplate of source code lines. And comparing side there, of course, ability
to componentise infinitely and hierarchically. And for accessing data GraphQL
emerges as hot modern technology. And a lot of other cool things to keep
tracking every day... It never stops, growing larger and allowing to reuse all
third-party dependencies (beside of components - every team mostly prefers
writing their own, because those play better with their chosen software
architecture) and constantly rewriting your own source code.

------
partycoder
Web development is _very_ volatile.

It is also a discipline that lowered its entry barrier a lot, and now coding
camps are producing a deluge of graduates, all of them attracted by the
promise of a 6 figure salary.

Even if pessimistically only 10% of them are good, they graduate every 14
weeks compared to 208 weeks for a CS graduate.

As of 2016, learning JavaScript might be very profitable, but I wonder for how
much longer.

------
StokeMasterJack
I have no patience for this kind of article.

Here is the fundamental essence of the article that drives me nuts: the
assertion that the reason someone would move to one of these new technologies
is because "it's trendy" or "everyone is doing it", "or angular is so 2015",
"it's for hipsters". This is the standard mantra of old people everywhere who
are too old to learn new stuff.

If the guy would have taken the time to learn the purpose of these tools,
their pros and cons, and why one would choose to use them or not use them,
that would be interesting. But that would take a bit more time. And actually
learning something new.

While I emphasize with old people who feel the world is moving too fast (I am
one of them), I have no tolerance for the basic anti-logic of the article: the
assumption that new technology only exists because of trendy hipsters who just
like change for the sake of change. This logic only exists to soothe the mind
of old people who don't want to learn new things.

------
glenndebacker
I don't use ES6 because of the cool kids, but because it makes some Javascript
things more tolerable.

One constructive thing that I would like to add is that the "You don't know
JS" book series has really taught me a lot about the common pitfalls of
JavaScript. Since then my JS stress levels have been reduced dramatically!

------
maxlambert
Hilarious article, but seriously, can somebody tell me where I should begin
learning all of this stuff?

What are the 2 or 3 top-priority things I should get started with, if I have
experience with Django/HTML/JQuery, and want to expand into more advanced
frontend programming?

~~~
threatofrain
Have you looked into stateless React + Redux? These libraries are interesting
in their suggestions for app architecture, and their api's are minimal.

One day perhaps React and Redux will be replaced by something else, but I
think the strategy of a GUI functional layer consuming a stream of events is
here to stay, and I wouldn't be surprised if it spread to native app design.

------
anta40
The last time I touch JS was probably many years ago, while learning web
development in the university.

I mostly write desktop+native mobile apps, and without doubt my JS skill is
very rusty :(

Any suggestions how to catch up with JS trend nowadays? JS for web dev is
pretty much unavoidable, right?

------
keymone
one thing i disagree with is how functional programming concepts are equated
to all the bullshit javascript ecosystem has grown to be.

~~~
ChoHag
I didn't think they were equated. I got rather a sense of exasperation that
javascript includes them at all.

------
drumttocs8
Psst... Meteor solves the entire build process for you... you can use React
with it now... it integrates with npm now... you can use Apollo with it to
connect to any type of database...

------
DiegoZoracKy
This article is very good and sums up very well a feeling that a lot of us is
having right now. However, i think that title is throwing an error, as the
article is not about learning JavaScript, but, only about learning Front End.
I wrote a little about it here:

[https://medium.com/@DiegoZoracKy/stop-blaming-on-
javascript-...](https://medium.com/@DiegoZoracKy/stop-blaming-on-javascript-
when-all-you-want-is-to-talk-about-front-end-73ff19fef861)

------
chajath
My advice would be to pick one tech stack that is prevailing in the market and
master it. Once you master one you will see similar concepts been largely
repeated in other frameworks.

------
OtterCoder
Takeaway: use Elm.

------
cycomachead
Slightly related, but if you're helping someone start out learning to code,
it's worth reading this:

[http://pgbovine.net/programmers-talking-to-
beginners.htm](http://pgbovine.net/programmers-talking-to-beginners.htm)

You don't _need_ react to build a cool site in 2016, but if you're dead set on
that, then this piece is a good intro to the set of questions that arise!

------
mgrennan
This is what happens when management gives up and turns IT to developers. And
I believe that happened when accountants took over because of Sarbanes Oxley.
The accountants had no idea what they where getting into. Then the Tech Bubble
happened and $$$ filled their eyes. Developers became GODs and now... This
happened.

------
gremlinsinc
I'm looking into react, and I fix things in legacy code, but that's still
mostly jquery, or native js. But backend I just get things done.. I much
prefer working on teams where there are 'specialists' who do all the frontend
and I just give them an API to feed into it.

------
geddski
I wrote a post that might help anyone feeling overwhelmed about all the things
to learn:

What Not to Learn [http://gedd.ski/post/what-not-to-
learn/](http://gedd.ski/post/what-not-to-learn/)

------
mwexler
I couldn't help but yell "Third Base!" at the end of this.
[https://en.wikipedia.org/wiki/Who%27s_on_First%3F](https://en.wikipedia.org/wiki/Who%27s_on_First%3F)

------
scotty79
I'm getting away with npm, webpack, typescript, babel and react (with jsx)
with some lo-dash.

Never learned browserify, barely grunt and bower, happily forgot thorough
knowledge of gulp. Actively pushed out all of the awfulness of angular.

------
realrocker
Ok, So I have only ever done backends and some android stuff,and been trying
to learn building UIs. It's been hard. This post finally cleared some of the
confusions I had but was afraid to ask.

~~~
voltagex_
I'm a (mostly backend) web dev, and I've been trying to get a simple Android
app up and running - it's definitely more challenging than I'm used to.

------
pdonorio
I was moving from Full Stack to Backend/DevOps without even noticing, in the
last six months. At least with this post I can now admit it to my self and
explain why to others on LinkedIn.

------
SadWebDeveloper
> Oh, like Bower!

> Oh, like Angular!

IMHO if you know about those you pretty much most of the terminology the "js
guy" is using, personally speaking i know Angular haven't used yet bower in
any project.

~~~
16bytes
If you used Bower and Angular in 2011 and disappeared for 5 years, then nearly
all of the stuff that the "js guy" talks about would be new to you.

------
jftuga
This has to be one of my favorite HN posts of the year.

------
resonantjacket5
This encapsulates my experience learning angular 2 and react these past two
years. Lol

------
Pherdnut
Our industry has been overrun by resume-bullet-point silicon-valley-framework-
coddling noobs/whores. I have always prided myself on staying up on the latest
in core web technology. It's the reason I know what a !@#$ing tragic waste
most of these idiotic frameworks are.

jQuery had the DOM covered and is in fact now redundant itself and could be
managed with a much, much lighter lib that spends a lot less time normalizing
assuming you're dropping support for browsers even Microsoft no longer covers.

LESS and SASS were good for vars and should have stopped there. Standard
browser support is finally in the works for that. But you certainly don't need
both and for FFS you're just making an unmaintainable styling mess using all
of the other features, especially (noob, please), nesting which needlessly
adds to selector count like nobody's business.

We do NOT need to ASP/JSPify the DOM. Keeping content/structure code separated
from the behavior code was the reason proper front end devs were running
circles around Java/ASP.net devs. What the fucking fuck is the point of adding
your own custom tags to HTML, which already had a perfectly serviceable
approach to binding behavior to it? Or creating an XML-like syntax you
mix/match directly with your JS?

Silicon valley noobs, please. I had lazy loading scrollable tables that could
handle 50,000+ lines of data back when Google Docs was choking on 2,800. This
shit is not hard. Stop wining and spend the time you apply to learning
frameworks with next to no core technology understanding to actually learning
the technology you have before you start adding pointless layers that solve
nothing on top of what's already there and you'll be shocked at how not-hard
it can really be.

Or let's not. Let's load a massive freaking ridiculous CSS and JS library by
the Twitter devs, because, yes, surely they know through their work with a
site that essentially boils down to a single text area, a great deal about
handling complex layout and UI concerns.

AMD for a web app? Okay, I can see it, certainly for non-trivial SPAs , which
NOT EVERY SITE NEEDS TO BE. But first, how complicated is this web app? If
not-very, why were people struggling with linking scripts in the right order?
Why did they need to link so many damn things to get the job done in the first
place?

And FFS, it's just "data-binding." Calling it "Two-way" is redundant and makes
you sound like a jackass who doesn't know what the fuck is actually happening.
And it's just a pattern. And not a very hard one to implement.

MVC and MV? are great. Really, whatever the fuck keeps data separated from an
app layer from your DOM-handling is fantastic. Frameworks that make it easy to
follow such patterns in a way that all developers can become familiar with are
great too. But sweet JavaScript Jesus why won't they just stop there?

We used to laugh at Java developers. What the fuck are we doing to ourselves?
Why haven't I gotten an honest to god core web technology or native JavaScript
question at an interview in like 3 years? We have indeed, ruined JavaScript.

Thanks a lot assholes.

------
StokeMasterJack
That article could have been shorted to: I'm old.

------
davidjnelson
My comment from the medium post:

I think the key takeaway here is: a) requirements suck always, b) figure out
what the real problem is that needs to be solved, c) fashion your solution to
the unique needs and culture of the team you are a part of.

Computers are hard.

I’ve been specializing in front end stuff for 4 years and it still took me a
month to master the react ecosystem. It’s better than anything that came
before it though by a landslide.

People whine a lot expecting everything to be easy. There is a laundry list of
classic cognitive distortions present in these types of articles.

If this is literally your only requirement and no new features will ever be
added: “create a page that displays the latest activity from the users, so I
just need to get the data from the REST endpoint and display it in some sort
of filterable table, and update it if anything changes in the server”.

Which I highly doubt, but let’s go with that premise. What you’d really want
is to be step back and look at the needs of the app. The real needs are
websockets for real time, and a way to tail the oplog of the database you are
using to get the latest data pushed without needing to have the websocket
proxy you’ll setup poll on the server side.

The front end implementation is fairly irrelevant here, IF nothing ever
changes ( yeah right ).

If that is truly the case ( it’s not, believe me ), then just use a jquery
datatable plugin which updates it’s data when new websocket data comes in.
That’s like 100 lines of code, done.

If you’re using mongo it’s not too hard server side because you tail the
oplog, the way meteor does. If you’re using something else you might have to
poll server side to get the new data, which is honestly the hardest part of
this problem. The front end of this is not the issue frankly based on the
requirements presented.

This is IF this is all a one off project that never changes and will never
need new features or bugfixes.

If it ever needs to be changed, you do benefit a lot from using more modern
technologies so instead of a lump of jquery spaghetti you have clean component
api boundaries which can be easily unit tested and modified in isolation
without breaking other areas of the app.

Every situation is different.

As presented, this is more of a server side problem than a front end problem.
What data stores are you using, how are you going to get that data in real
time, how are you going to set up a web socket server, how are you going to
scale said web socket server etc.

I think that blog post comes off as attacking the wrong problem and
complaining that computers are hard. It doesn’t appear the requirements were
clearly understood and evaluated. Picking the right tool for the job is really
a thing. Dogma is dangerous in software for sure. On that point, I agree.

------
ilostmykeys
If you stay on the surface and follow trends you will think front end web
development is insanity inducing. But if you go deeper, develop your own
thinking and deep patterns you will realize that the web platform is doing
just fine and is progressing better than most languages/platforms out there.

