
JavaScript frameworks and topics to learn in 2017 - kp25
https://medium.com/javascript-scene/top-javascript-frameworks-topics-to-learn-in-2017-700a397b711#.5ld817l5v
======
dictum
> Webpack: The most popular bundler for standard JavaScript look for simple
> starter kit/boilerplate config examples to get things running fast

Unless you're already familiar with a tool, I'd suggest starting with the very
_Hello, world_ basics.

For Webpack, that's creating an empty project and incrementally adding config,
starting with just an entry point (use a simple script importing some modules)
and an output filename. Add one loader/plugin at a time. Move into
boilerplates once you're familiar with the basic concepts.

(I wish more projects had a Concepts page like Webpack now has:
[https://webpack.js.org/concepts/](https://webpack.js.org/concepts/))

A boilerplate is another person's code, and while it's good to avoid NIH,
unless it's superbly documented, it contains tricks and workarounds that only
cloud real understanding.

\---

Eric wisely started the article with JavaScript & DOM Fundamentals. For people
like me, who were familiar with pre-ES6 JS but weren't actively writing JS
lately, the basics themselves have changed a bit.

~~~
d2xdy2
> For Webpack, that's creating an empty project and incrementally adding
> config, starting with just an entry point (use a simple script importing
> some modules) and an output filename. Add one loader/plugin at a time. Move
> into boilerplates once you're familiar with the basic concepts.

I attended a General Assembly bootcamp last year (to great success afterward
for me), and the pervasiveness of jumping right into a generator / boilerplate
really caught me the wrong way.

I felt like going the path you describe, starting with relatively low
complexity and building on top of it, was/is the right way.

Even talking to co-workers who have been doing this stuff for years, there's
little incentive to jump into a boilerplate, if only there's then two learning
curves... one for the boilerplate / its layout, and one for the tooling
involved (React or Angular, etc).

> A boilerplate is another person's code, and while it's good to avoid NIH,
> unless it's superbly documented, it contains tricks and workarounds that
> only cloud real understanding.

This caused a lot of headaches with other students in my class (and classes
afterward).

My idea to "solve" it was to incrementally build out my/our own boilerplate so
we'd be able to at least use that confidently, as well as maybe have some
understanding into how someone else built their boilerplate. It got shot down
due to time constraints, though.

Whenever I'm asked to come in and mentor newer students for their projects,
this is something I try to impart, though.

~~~
matt4077
You're all selling this as if it were some sort of philisophy. But it's not.
Webpack just happens to be a piece of software that for reasons nobody will
ever fully understand ended up being the de facto standard, all while being
the most miserable to configure piece of software seen by mankind. (I. e.
4-level depth nested configuration with no indication of errors, a few
different common patterns – ph, and there are two versions of webpack and the
documentation rarely mentions which one it's talking about)[0].

Webpack is, essentially, a compiler. It, or something else, will mature to the
point where you don't configure it any more except for maybe a debug flag. At
that point learning it's internals will be as useful to a web programmer as
learning LLVM's (by which I don't mean "not useful", but probably not worth
neglecting whatever the trade-off may be).

[0] I think it was mostly developed by a single guy with a day job, and it has
had more impact than any software I have or probably will ever build, so it's
not meant to be insulting. Annoyances such as these are the price of a fast-
moving field.

------
eranation
Learn programming, not just frameworks. Frameworks will come and go, but the
core programming concepts (good design, algorithms, cleanliness, simplicity,
data structures, architecture) will tend to stay relevant longer. Learn the
principles of Reactive Programming, not just RXJs, learn the philosophy of
Redux, not just its syntax. You won't be able to keep up with it otherwise.
Source: a guy who was an actionscript guru 15 years ago.

~~~
sgdesign
This is a nice-sounding programming mantra but it doesn't make much sense in
the real world, in my opinion. Learning the "philosophy" of Redux is a natural
by-product of learning how to actually use Redux.

To me this is the equivalent of saying "learn molecular chemistry, don't
follow recipes" to someone who's trying to learn how to cook. It may be true
that the most experienced chefs have a deep understanding of chemistry, but
it's much more practical to start from the surface and dig deeper, compared to
overwhelming newcomers with "principles" and "philosophies" right off the bat.

~~~
k__
That's a bad analogy.

Cooking is much less complex, so learning it without much background works
rather well.

Just look what your philosophy brought us, a horde of 'developers' who thought
JavaScript is jQuery.

~~~
kutkloon7
Programming is not complex. Frameworks make it complex, in the sense that they
force you to use nontrivial concepts (I'm not against frameworks as a whole;
when you're trying to do something complex it may be hugely useful to use
one).

------
fenomas
> Learn [Vue.js] after you have learned React or Angular.

Hugely disagree with this. I really like Vue - but in my (very limited)
experience, its appeal is that even though it's not as powerful or flexible as
React or Angular it's _way_ easier to learn and get moving with. Fewer new
concepts, less new tooling, no ecosystem of related stuff to consider, etc.

I'd have suggested learning Vue first, and sticking with it until you outgrow
it. If you start with Ng/Rx, and get to where you're comfortable and have a
tooling/workflow around them that works for you, then sure you could still
learn Vue afterwards but I'm not sure what it gets you.

~~~
stephenhuey
I'm with you. I went with Aurelia for a new project (which is unfortunately
missing from his list) and would recommend it for everyone who wants to code
an application using web standards. I briefly considered Vue but in this case
needed a little something more and I found Aurelia to be more straightforward
than React and Angular, especially after 14 years of application development
in a variety of languages.

------
moxious
Yeesh. In fairness it's a fine list, but you can be an excellent JavaScript
developer and know less than one third of what's on that list. Ambitious JS
lifers maybe can get to most of that, but for people who value some breadth of
knowledge across tech, I'm not sure even pursuing such a list is a good idea.

~~~
faceyspacey
Ambitious JS lifers lol

------
daenney
> Node lets you use JavaScript on the server, meaning your users can store
> data in the cloud and access it anywhere.

I don't see how using Node server-side has anything at all to do with user's
capability to store data in the cloud.

------
alistproducer2
My 2 cents. I would consider myself a JS expert as I have writen AngularJS and
RequireJS clones. Personally, I don't agree with the path that OS JS dev has
gone in recent years. The reliance on build systems and transpilers are
fundamentally anathema to the spirit of simplicity and low barrier to entry
that attracted me to the language and ecosystem inn the first place.

I understand that as we have moved from web pages to web apps the increase in
complexity was inevitable, but I question a lot of the tools being used now.
For one thing, once we moved to creating full applications using JS, one of
the concerns that tooling moved to address was maintainability. This is why
MV* caught on and destroyed JQuery as a viable option for many projects. That
being said, Angular pretty quickly swapped one kind of maintainability problem
(refactorability) for another (over-abstraction and cyclomatic complexity).

As for the dev tooling (webpack and company), one of the reason I avoid a lot
of them is in my experience they can get in the way of maintainability. For
example, I recently tried to pick up a 3 month old project in Android Studio
and it took me around 3 hours just to get it to compile again because of
updates and other tooling complexity. This NEVER happened using Eclipse. The
same thing is happening and will happen when the apps being built today get
dumped on some poor sod 3-5 years from now.

Lastly, an example from my job. I was recently asked to update the verbiage on
a sign in form built ~13 years ago. The devs decided to use some java
framework that had buzz at the time named JATO. Jato literally doesn't exist
anymore and building it is basically impossible. This is to say nothing of
modifying it as all documentation has literally disappeared from the web. The
devs picked JATO b/c they thought it would be easier to modify and maintain.
Exactly the opposite has happened. They could easily have written the form
(literally two input boxes and a submit) using plain JSP. If they had, that
code would still be useful today.

------
heavenlyhash
I want a javascript framework that allows me to update a page incrementally,
but also _always works correctly and contains full content_ from the first
server-side page load.

Are there any options for this? Are there even keywords I can search for that
discuss this?

Sure, this files under "anything is possible", but honestly, I'd like a
javascript framework that doesn't _actively fight me_ also having static
content. Any of these libraries that put their document derivation logic front
and center are ipso facto refusing to compose well with a simple static first
page load that renders fast and then gains progressive enhancement from the
JS.

~~~
DougWebb
I'd really like to see this too. Most of what I've seen is something like "use
node.js on the server and make use of the framework's server-side rendering
capabilities". For me that's a problem, because I don't want and can't use
node.js on the server.

These javascript frameworks ultimately produce, at the end of the first page
load, a DOM structure with event hooks attached. The DOM structure could be
100% created using html markup from the server, so if the framework provided a
way to just hook up the events and then manage the DOM from that point on,
you'd get the best of both worlds. It's possible to do this with native
javascript jQuery by putting either classes or data attributes in the markup
to indicate where the hooks go and then running an init method to find them.
Bootstrap components work this way, for example. One of the earlier SPA
frameworks, Knockout, worked this way too.

~~~
niyazpk
>> don't want and can't use node.js on the server

I don't understand, you want a javascript framework to do server-side
rendering, but don't want to use node?

~~~
DougWebb
No, I want to do server-side rendering using whatever I want, and have the js
framework take over once it is clientside.

~~~
bigmanwalter
Please please please look at jQuery-Pjax. It does exactly this. If you have
any questions about it, feel free to ask!

~~~
DougWebb
That's basically the pattern my company is already using, implementing using
our own plugin. We render the full page server-side (using ASP.Net MVC, which
is hooked into our server-side Enterprise Application Framework), and then we
hook up javascript handlers to manage client-side events. Those handlers can
make AJAX requests for content updates, which we deliver either as pure data
or server-side rendered html (which are rendered using the same partial
templates that the initial page used.)

Depending on the page, we can go anywhere from old-school full-page-refresh to
a complete single-page-app design. Mostly we do Enterprise back-office
interfaces and customer web portals, both of which tend to have a lot of data
grids. So a very common feature of our applications is a data grid that
supports paging-in-place, along with server-side filtering and sorting of
large datasets. So we'll do that SPA-like, even if the overall site is more of
an old-school design where each link loads a new page.

Our plugin does more than just fetch a url; the client side and server side
are designed to work together to allow standard options to be passed up to the
server along with the request, standardized error handling and content in the
response, and standardized ways of handling the response when it gets back
client-side.

~~~
bigmanwalter
Nice, I work on similar sorts of projects, but I run a Python shop :)

------
doomtop
Great list! But I was perplexed by the text editors mentioned. Author claims
to be looking at trend data, but seems to have a bias against Subljme Text
editor. I don't know if there is some connection to Atom or VSCode, but it
seems easily verifiable that Sublime and vim are vastly more popular than
other editors mentioned, yet Sublime is inexplicably absent and vim is
mentioned last and sort of offhand as more of just a tool you have to know for
ssh sessions.

~~~
ericelliott
Sublime is absent because a lot of previous sublime users are now Atom users,
and it is now the more popular editor by a large margin. Those comfortable
with Sublime will find Atom very inviting.

~~~
Can_Not
Except when you need to open a file more than 100 lines, atom is nicer.

------
aeosynth
Is anyone using Tern as an annotations-free type checker?

~~~
ericelliott
Yes.

------
jaseemabid
The only issue with the blog post is that most of those tools will be obsolete
before you finish reading.

JavaScript as an ecosystem needs mature robust solutions rather than a new way
to do things every other week.

~~~
coltonv
That's simply not true. I'm kind of tired of hearing about this kind of stuff
said about JS. This comment adds absolutely nothing to the discussion about
this article.

Did you even read the article before making this comment? It would appear you
didn't since this is just a classic, low effort javascript bashing comment
that mentions no evidence from the article.

Every single thing he marks as important to learn is either

1\. a mature library that has been around for years and is used in production
at hundreds of companies (React is 3 years old and Angular is 6 years old,
Lodash is 4 years old, Node is almost a decade old)

or

2\. is a fully specced and largely implemented feature of the Javascript
language.

How is Ajax gong to be obselete before you finish reading? How is Node, a
nearly decade old, battle hardened runtime going to go out of style in 2017?
By literally any definition JS builtins, functions, closures, callbacks,
Chrome Dev Tools, React, Angular, Tern, ESLint, npm, git, Redux and Promises
are all "mature robust solutions". They've all been around for years and are
thoroughly tested and used. Many of them are used maturely in other languages
as well, for example Futures in C# are basically the same thing as Promises.

The author does mention some newer things like async/await, generators, and
ES6, but all these are now _official parts of javascript_. They simply can't
"go obselete", and all of these share ideas with other languages which are
also, by any definition, mature and robust.

The author does mention some libraries which are new and less proven, like
RXJS, Angular2, MobX, Vue, Yarn, Typescript, and Flow, but did you notice how
every single one of these has an asterisk? Which he specifically states means
"strictly optional": Cool things to try out that may be useful tools, but not
essential. Even most of these are several years old and perfectly mature
anyway.

Yes the javascript community moves quickly. Yes JS programmers enjoy trying
out flavor of the month frameworks, but it seems I'm one of the only people
who sees this as a great thing. People try out lots of new things and learn
lots of new strategies, and in the end the ideas of these get incorporated
into existing mature frameworks, making them better and more robust.

~~~
bkovacev
From my personal experience what the parent comment stated is actually very
true.

As someone who is actively trying to get into the JS world coming from the
back-end side it is extremely hard to find best practices that do not change
every other week. In the beginning of the year, tutorials were made with
grunt, yarn, yeoman and the likes, then they were written to use gulp, bower
and now it's webpack and what not. I can't even catch up on what the tutorials
have used. To be extremely fair, every other week there seems to be a new tool
I _need_ to know and I can't even catch up on why I should learn or stop
learning/using the previous. Every tutorial/documentation does something
differently - there is no unique set of tools and instructions that do not
change over time. I cannot find the best practices docs, because everyone has
their own opinion of something and bashes the other guy for having an opinion
in the first place.

I know it might be a bad analogy - but I usually compare the state of the
principles of RESTful APIs to the state of principles of the front-end stack.
They are design principles and you have set of instructions/best practices you
_should_ follow regardless of the language, framework etc. Thus I can make
RESTful APIs in Python, Go, Ruby etc. On the other hand, Javascript is very
opinionated framework. I cant seem to find the principles wrapped in a talk,
book or docs. Offer me a choice, let me make it, do not make it for me. Let me
make a mistake, let me learn how it does not add up to the whole picture.

Every JS documentation assumes something or fast forwards through an important
part of the process - the set up. Why the heck do I need to use something, and
why is it good with another tool you have in this stack. Why shouldn't I use
something? Don't just copy the gulpfile or any other js file I need, explain
it.

You said it is a good thing to try a new thing every month - how do you have
enough time to observe it and test it properly in production or wherever? I
don't see a new framework every month as a good thing, the frameworks don't
mature in your environment and neither does my deep understanding of the
framework. That makes for constant struggle to optimize a way. People in the
JS world, at least to me seem like, hmm, this does not sound cool anymore
let's change it up with this.

I hope I don't come of as a hater, I'm just speaking as a front-end newbie.

~~~
Can_Not
I followed a gulp tutorial, continued using it. When webpack came out, the
gulp community seemed like it's was just as alive as before. When webpack came
out I didn't rewrite all my gulp code to webpack. I'm not sure how you got
different results.

------
Kiro
I vote for React + MobX as the goto stack of 2017.

~~~
thomasrognon
Seconded. React+MobX+Typescript+Node is my preferred fullstack.

------
andretti1977
I must be honest, my experience with node was very short but this article
suggests me that working with js may be really more complicated than working
with java. Too many frameworks (which often lives too shortly), too many
things to learn, it's overwhelming...sometimes it seems to me that working
with js has become so difficult that working with java and jquery is still
easier and better (i know lot of people will throw me hate for this comment!)

~~~
tambourine_man
I have no problem with difficulty (if interesting), but I get completely
blocked by, what seems to me, needless complexity.

The will to learn vanishes completely.

~~~
jim_d
I think the interesting thing is that for 90% of what is being built most
tools are overkill and JQuery is really good enough. I say that as someone
that started using React/Flux almost 2 years ago, and as someone in the midst
of moving from Flux stores to Redux. The power of these tools is when there
are large teams involved, when the complexity of the state on the FrontEnd is
extremely high, and when you absolutely need a Single Page Application. Most
of the time all 3 of those conditions aren't true, and in those cases you're
better off using something like jQuery which is boring, easy to reason about,
and everybody already knows it well.

------
andrew_wc_brown
MithrilJS. Such an underated js framework.

~~~
roryisok
I've never even heard of mithril. Very easy to be a developer and read threads
like this and suddenly think "oh crap I don't know ANYTHING!"

~~~
pluma
Just remember that attention is a limited resource and there are very likely
things you know that would trigger similar reactions in others.

We tend to compare ourselves with the extreme outliers and even then we
overlook their deficiencies and assume they additionally know everything we
do. We also tend to conflate all the people we see talking about things we
don't know as if they were all the same person.

It's okay not to know things. It's okay to make trade-offs. It helps to have
some spatial awareness what else is going on outside your sphere of interest,
but pick a handful of things and focus on them instead of trying to learn
everything.

------
ExpiredLink
Or wait another year and pick the winner of the JavaScript framework war. It's
unlikely that we will see new and relevant(!) JS frameworks over the next few
years as we have seen in the past. 20 - 25 years ago dozens of Windows
frameworks appeared on the market. Eventually VB won. History is repeating
itself.

------
adamnemecek
You should check out cycle.js [https://cycle.js.org](https://cycle.js.org).
I'm always surprised it's not THE js framework du jour.

------
ClayFerguson
TypeScript is definitely by far the most important thing mentioned in the
article. And no I didn't even read the article. I just searched it for the
word TypeScript to see what it said. However, the author apparently is pretty
clueless because he implied TypeScript has something to do with Angular. It
doesn't. TypeScript is needed ANY time the runtime is JavaScript. Namely, in
the browser. The only other technology TypeScript has ANYTHING do to with is
JavaScript itself.

~~~
ericelliott
If you click through the links and actually read the content, I have plenty
more to say about TypeScript, and why I consider it optional learning for JS
developers.

~~~
ClayFerguson
Well you've definitely misguided everyone by suggesting TypeScript is in any
way related to Angular. There is absolutely no relation. You should fix that.

------
voltagex_
Highly recommend spending at least a few hours on
[https://javascript30.com](https://javascript30.com) if you get a chance.

~~~
mathgeek
Even as someone who knows enough JS to work in it when necessary, I found js30
to be a ton of fun. Highly recommend it.

------
jim_d
I'm curious what people think about type checkers in JS. I've been doing full
stack development for the last few years and BE development before that. Type
safety has always been worth it to me, we adopted Flow and haven't looked
back, although some FE developers aren't big fans of it.

~~~
ericelliott
See "You Might Not Need TypeScript (or Static Types)"
[https://medium.com/javascript-scene/you-might-not-need-
types...](https://medium.com/javascript-scene/you-might-not-need-typescript-
or-static-types-aa7cb670a77b)

------
macpete
Learn in order to unlearn one year later - welcome to .js !

~~~
amelius
It might keep the brain healthy :)

~~~
mathgeek
It might also be the path to burnout. Really depends on where you are in life
and what type of personality you have.

There are many other factors involved in brain health.

------
jgord
Agree Vue and mobx look promising ...

I would say Ramda.js is most deserving of much wider adoption.

------
catshirt
ugh- how is Angular so popular?

~~~
weremine
Because it solves real world business problems. Some people need to build
large systems in a SPA framework and Angular is good at this.

Not everyone is building a cheap hackathon twitter clone in their spare time.

For some of us the JS framework is solving business problems, not hobby JS
side projects using the latest hip JS frameworks.

~~~
wwweston
> Because it solves real world business problems. Some people need to build
> large systems in a SPA framework

This sounds...circular. "AngularJS is a framework for building large SPA
framework systems solves the real world business problem that business need to
build SPA framework systems."

Frameworks don't solve business problems, practically by definition; they're
_potentially_ the common factor across software systems that solves part of
the _technical_ problems of developing an application.

That's assuming a framework is any good, of course, but we're talking about
Angular, so by all means: tell us what development problems Angular solves for
you.

And if I were defending Angular, I don't know that I'd invoke the problems of
fashionability and the bleeding-edge of change, because it's hardly insulated.

------
na85
I'm going to make my 2017 enjoyable by not working with JavaScript at all.

~~~
douche
If only I could. I may try to call the banners for a campaign to start using
Typescript, though.

------
enraged_camel
Half of the items on this list - basically, anything not under "JavaScript &
DOM Fundamentals" \- will probably be invalid by April 2017. :P

------
FrancoDiaz
I'm looking for a React Admin/Dashboard template. There's various themes at
[https://wrapbootstrap.com/](https://wrapbootstrap.com/) but haven't been
totally satisfied with the React offerings.

------
d13
The article recommends learning both pure functions AND closure? So is the
point of learning to use closure is just so that you know why you should never
use it?

~~~
uryga
afaik, and based on my limited experience, closures are used quite often in
pure functional programming.

