
Ask HN: What you wish you'd known before getting into JavaScript? - cryptography
I want to learn JavaScript as my next language. I have been observing JS community for some time and it seems like there is too much noise out there with dozens of frameworks and language variations (e.g. CoffeeScript, TypeScript, JSX, etc). I plan to go through Mozilla&#x27;s JS docs and Vue tutorial, but not sure if it is enough to get up to speed with the modern JS ecosystem. Which resources would you recommend? Which framework should I stick with? What are some things that you wish you had known before getting into JS? Note: I am comfortable with Python (including Flask&#x2F;Django), Java, HTML and CSS, so picking up JS as a language won&#x27;t be a problem. Interested in your thoughts.
======
Zyst
I'm a senior web developer now, started with other languages. This is a bit
embarrassing but here goes:

1\. I wish I had known how asynchronous stuff worked before I got into JS. OR
studied it in JS a bit more formally. I had a couple of months where I was
confused as hell, because I didn't really understand how to do async, promises
weren't really a thing you could use if you had to do older browser support
back then.

2\. I really wish I had studied JavaScript. I didn't, at all. I was like "Yeah
front end is easy anyway, lets roll" and just got started developing. I did so
many stupid things, suffered so much, and really resented the language at so
many different points exclusively out of my own ignorance. Once I got my head
out of my ass, and actually studied the language in depth I felt like so many
things started making sense.

To conclude with 2, I remember having a distinct realization that it wasn't
JavaScript that was shitty. I had been a shitty developer for having not
studied it.

Anyway, if I can give some advice those two would be it, understand how
asynchronous flows work, and learn the language.

~~~
rhapsodic
_> 2\. I really wish I had studied JavaScript. I didn't, at all. I was like
"Yeah front end is easy anyway, lets roll" and just got started developing. I
did so many stupid things, suffered so much, and really resented the language
at so many different points exclusively out of my own ignorance. Once I got my
head out of my ass, and actually studied the language in depth I felt like so
many things started making sense._

Based on my experience interviewing candidates with years of alleged
"experience", I marvel at how many so-called professionals don't bother to
learn Javascript in any depth. I've had more than a few candidates that
couldn't demonstrate how to iterate through the elements of an array, for
example. Or correctly give the truth value of expressions like:

    
    
      "  ";
      "";
      undefined === null;
    

and on and on. These, to me, are dealbreakers. If someone can't rattle them
off, I'm not going to pay them the six-figure salary they claim they're worth.

I'm surprised at the amount of resentment this sentiment of mine generates
here on HN, of all places, but it does.

~~~
Nadya
If I need to test on such things does that mean I can write code like the
following?

    
    
        var a = [];
        a[0] = (a[0]+"")[1];
        a[1] = (a[1]+"")[2];
        `${a[0]}${(!"" + "")[3]}${(!"" + "")[1]}${a[1]}`;
    

Anyone who couldn't easily read it deserves to be fired on the spot.

~~~
rhapsodic
Nadya, I don't understand the vitriol in your reply. If you think I'm being
unreasonable not hiring someone who doesn't understand those basic aspects of
the Javascript language, I would be interested in hearing your reasoning.
Please share it if you don't mind.

~~~
Nadya
I was being very heavily tongue in cheek. Your knowledge tests that people
understand implicit conversions in Javascript to be able to find the
equivalent boolean values.

    
    
        !!( "  ")
        !!("")
        !!(undefined === null)
    

You probably want to test for _any falsey value_ though. So the interviewee
understanding the ToBoolean spec [0] would be what you actually want to be
testing for.

    
    
        if (!x) {
            // interviewee should be able to answer for which values of `x` this condition would run
            // this shows they understand which values are falsey and which values are truthy
        }
    

The knowledge being tested would be "the same" but in a different, and I feel
more direct, way. I felt your test was testing their knowledge of implicit
conversion and not truthy/falsey values, so I wrote purposefully confusing
code that uses implicit conversion.

"If everyone can easily understand what's going on, there's no harm writing
code like that!" /s

[0] [http://www.ecma-
international.org/ecma-262/6.0/index.html#se...](http://www.ecma-
international.org/ecma-262/6.0/index.html#sec-toboolean)

~~~
rhapsodic
Nadya, whether or not that's the best thing to test for is beside the point.
All I'm saying is that, in my view, a professional Javascript developer
_should know those things._ And apparently, a lot of people on HN disagree
with me.

~~~
Nadya
>Nadya, whether or not that's the best thing to test for is beside the point.

What you test on is almost as important as how you test on it. Interviews go
both ways after all. I think a majority of people aren't disagreeing that a
professional should know these things - but asking them to "rattle off an
answer to [question]" is looked down on. It reeks of the "reverse a binary
tree" or "implement [some sorting algorithm]" type of questions.

I consider myself a Javascript professional (in so much that I am paid
primarily for the Javascript work I do) and I had no issue knowing the answer
to the three items listed. If I was asked to rattle them off the top of my
head as some sort of Fizzbuzz Filter equivalent - I'd thank you for your time
and leave the interview.

I agree people should know the answers - which (as you've pointed out) _is_
the point you're trying to get across. But how you share that point, much like
which questions you ask, is important.

~~~
rhapsodic
I think you're reading too much into the phrase "rattle off". By that I simply
meant that the interviewee should know those things well enough to answer
correctly and confidently.

And it still amazes me that this position seems to be controversial here on
HN. There are people who have expressed unequivocal agreement, to be sure, but
a significant number seem to see that stuff as obscure arcana that a developer
would not typically need to know.

------
flaviocopes
> What you wish you'd known before getting into JavaScript?

JavaScript is fundamentally different than Python or Java.

Learn plain JavaScript alongside learning a framework - it won't bore you too
much with theory and you start right away building things

> too much noise out there with dozens of frameworks

Really, for the most part, it all boils down to React, Vue and Angular. Those
are the mainstream ones, then you have hundreds or thousands of alternatives,
but as a beginner, you'd better stick to the most popular ones, easier to find
help and libraries.

> (e.g. CoffeeScript, TypeScript, JSX, etc)

CoffeeScript is no longer widely used. As I see it, it was mostly a good
introduction to JavaScript for Ruby developers, but I haven't seen lots of
CoffeeScript projects after the recent ECMAScript releases (ES6-7-8)

Watch out for outdated tutorials: after 2015 JavaScript changed a lot.

JSX is not a language variation, but rather a different way to write
templates.

Avoid getting too picky with the tooling: if using Vue, just use Vue CLI. With
React, just use create-react-app

Rely on a code formatter: Prettier. Also, use ESLint to make sure you start
with the right foot on code best practices

Don't fall in the dogma and cargo cult traps: listen, learn, but pick your
choices

------
paulhodge
Use Typescript. Use async/await. Use ES6 classes, don’t do the other class-
like patterns. Oh and use ES6 features in general, like fat arrows. And don’t
write “var”.

Don’t use unnecessary compile-to-js syntaxes like Coffeescript since they will
just be a burden in the long run. TS and JSX is an exception, those are worth
it.

Don’t write “undefined” in your code, just write “null”, and treat those
values the same. Some programmers will assign different meanings to
“undefined” versus “null” but usually these meanings are arbitrary and silly.
In most situations you don’t even need _one_ kind of null, let alone two.

~~~
nothrabannosir
I advise the opposite of these points. Start with es5, at least for a few
days. Go through the old tutorials, especially for promises.

Make sure you understand these, in order:

1\. callbacks

2\. promises

3\. async await

And in the mean time :

1\. prototype chain

2\. classes

Understand them in their old school form, first. The reason being: this fancy
new async await and classes stuff is just syntactic sugar, which hides the
implementation and will confuse the _hell_ out of you. You will not in a
million years understand why you can

    
    
        return someAsyncFunc();
    

Instead of:

    
    
        return await someAsyncFunc();
    

... from within an async func, _unless_ it’s within a try { } !

But if you understand promises, and how async await is just the same stuff
different smell, you’ll immediately grok it.

And god have mercy on your soul if you try to debug code with classes and
methods, without knowing about the prototype chain.

JavaScript is, at its core, an incredibly simple language. But es6 introduced
a lot of smoke and mirrors, which only really makes sense once you understand
precisely the things they’re trying to hide. You can get by , ignoring it, but
there lies endless frustration.

It shouldn’t take long to get the basics. Invest the week, and proceed to use
the more powerful tools with open eyes.

(And typescript and jsx will also confuse the hell out of you if you don’t get
JavaScript yet. It’s so confusing and layered; make sure you start at the
bottom!)

That’d be my advice. But I’m a very “depth first search” kind of guy :)

~~~
mythrwy
Fully agree. Start with the old school basics.

And just a reminder. JavaScript isn't a subset of React. If you want to learn
JavaScript start by writing JavaScript. Then when you get that down, layer on
a framework or two.

~~~
iKSv2
If you want to learn JavaScript start by writing JavaScript.

This should really be like the first point of every javascript tutorial ever.
Honestly.

------
andrewstuart
I answered this specific question with this post a few years ago, and mostly
the advice holds true today.

[http://fourlightyears.blogspot.com/2015/05/an-incredibly-
bri...](http://fourlightyears.blogspot.com/2015/05/an-incredibly-brief-
introduction-to.html)

If I could offer one single piece of advice that would save you hours, weeks
and months of pain, it would be to use "create-react-app" which neatly
sidesteps ALL of the pain arising from using the JavaScript toolchain. This is
presuming you are going to use ReactJS.

create-react-app is a hundredfold more valuable than any other single thing to
the JavaScript beginner. Maybe 200 fold.

Without create-react-app you'll rapidly sink to the 9th level of hell where
the King Demon of JavaScript toolchains will torture you so unrelentingly that
you'll beg for mercy and return to the safety of Python and leave your
JavaScript goal to some other year.

~~~
andrewstuart
Also, as a Python programmer, you'll want to use "lodash.get" which is the
equivalent of Python's dictionary.get() function which is incredibly useful.
To install it you do "yarn add lodash.get".

There's lots of ways to get variables from objects/dicts in JavaScript, and I
almost always use:

    
    
      let foo = {"kingName": "edward"}
      get(foo, "kingName", null)
    

Thus you get a nice predictable null if there is no kingName.

Python does falesy well, JavaScript does not. In Python you rely on None alot,
in JavaScript there are lots of inconsistent falsey values. Thus in Python I
can do lots of code that is quite terse because it assumes a nice predictable
falsey value, in JavaScript I tend to verbosely type out all my comparisons
even if they are as simple as (variable === true) or (variable === false). By
always consistently doing explicit comparisons (i.e. stating what I expect on
both sides of the comparison) I can avoid alot of bugs arising from
JavaScript's weird falsely behaviour. That's just my personal taste.

Broadly speaking I try to return null in JavaScript where I would have
returned None in Python, and generally I'd rather be using lodash.get to force
a null return. I prefer to avoid programming around "undefined" in JavaScript.

In Python you do alot of iterating dicts and lists. In JavaScript the
equivalent is map/filter and find.

To answer the question of which framework to go with, it's a personal choice
of course. I choose ReactJS over Vuejs. It strikes me that VueJS is easy to
start with but that is because it lacks an overall architecture. Thus the
tradeoff is that you learned it fast but maybe you'll pay for the lack of
application architecture later. If you go with ReactJS you might find it
harder up front to grasp the architecture, but you'll be in a good position
when your application gets to the point of needing an architecture. If you are
an experienced programmer then you should not be afraid to learn ReactJS. The
other key difference IMO to VueJS and ReactJS is that ReactJS points in the
direction of immutability with its one way data flow which I think is
important. I must say my advice can be taken with a grain of salt though
because I have not programmed VueJS so I'm biased.

As a Python programmer, you'll generally feel pain as you learn JavaScript
because asynchronous programming pervades everything. At first I hated this
but after many years of async programming I'm glad I understand it. Python is
magnificently synchronous. For the Python programmer learning JavaScript I'd
suggest making a real effort over time to learn all the JavaScript asynch
programming techniques including callback, promises and async/await. Your head
will spin but when it falls into place you'll realise the power of
JavaScript's inherent async nature.

~~~
meiraleal
> Broadly speaking I try to return null in JavaScript where I would have
> returned None in Python, and generally I'd rather be using lodash.get to
> force a null return. I prefer to avoid programming around "undefined" in
> JavaScript.

Why not var kingName = foo["kingName"] || null ?

~~~
baranovxyz
> var foo = { kingName: '' };

undefined

> foo['kingName'] || null

null

~~~
meiraleal
'' defaults to null is a better default than '' been different than null (so
you would have 2 different nulls).

------
anonytrary
Avoid "full stack" frameworks with JavaScript -- they are all gimmicks. This
is something I wish I knew at first. Start with Node.js, because you will
eventually end up using npm, Webpack and Babel if you are doing serious web
development. I used learnyounode[0] to get familiar with the basics of async-
first programming. Even though you have tools like async+await and Promises, I
would recommend being comfortable with callbacks.

Avoid CoffeeScript and jQuery, they are obsolete. Make sure you are
comfortable with Webpack (build tool) and Babel (transpiler), since they are
essential in web programming today. I would go with React + JSX over Vue,
because I find it to be more elegant and intuitive.

[0]
[https://www.npmjs.com/package/learnyounode](https://www.npmjs.com/package/learnyounode)

~~~
jfk-in-sd-ca
Glad I read this because my impression was that JQuery Was still popular.
Doing a lot of optimizing websites and jquery is a big source of bottlenecks.
Seems like most plugins and themes for WordPress call a different version of
JS which I believe causes the majority of conflicts.

~~~
baranovxyz
You can actually use Vuejs instead of jQuery for simple cases (you can't use
React). [https://medium.com/js-dojo/vue-js-is-easier-to-learn-than-
jq...](https://medium.com/js-dojo/vue-js-is-easier-to-learn-than-jquery-
abbbb9c12cf8)

~~~
anonytrary
I'm confused. Why can't you use React?

------
mxschumacher
Be sure to understand the event loop. Javascript as an asynchronous language
often comes back to bite beginners. Here are two great talks to help you:

[https://www.youtube.com/watch?v=cCOL7MC4Pl0](https://www.youtube.com/watch?v=cCOL7MC4Pl0)

[https://www.youtube.com/watch?v=8aGhZQkoFbQ](https://www.youtube.com/watch?v=8aGhZQkoFbQ)

Your life will be easier if you learn to use Chrome Dev tools (or the Firefox
equivalent) early.

In the beginning, you don't have to worry about browser compatibility -
embrace modern JS (ES6+)!

~~~
jexah
I second learning the event loop. One of the most important parts of the JS
engines, though somehow missed by most commenters.

------
nadavami
I just want to preface this saying that most of the JavaScript I do is on the
backend.

> What you wish you'd known before getting into JavaScript?

1\. Start with plain JS. Before jumping picking and learning frameworks,
helper libraries (like lodash) make sure you understand what the language in
it's current form can do.

2\. Make sure your resources are current. Like @flaviocopes says, JavaScript
has changed a lot since 2015. If something seems ugly or messy check to see if
a cleaner syntax has been introduced in ES6+

3\. Pick a style and stick with it. JS is quite flexible in its syntax, I'd
recommend using a linter from the beginning. I personally enjoy using
Standard, but anything that is widely adopted will do.

------
ricardobeat
I'm gonna go with a bit more unconventional advice: start small. React, Vue,
Angular are massive projects with a ton of underlying libraries, patterns and
concepts that you will be discouraged to learn initially.

Start using a simple framework, reading the source code, maybe even writing
your own to understand how everything works. Suggestions:

[https://github.com/hyperapp/hyperapp](https://github.com/hyperapp/hyperapp)

[https://github.com/choojs/choo](https://github.com/choojs/choo)

Also check out this redux + vanilla js exercise by a friend:
[http://ramonvictor.github.io/tic-tac-toe-
js/](http://ramonvictor.github.io/tic-tac-toe-js/)

Learn ES6: [https://egghead.io/courses/learn-
es6-ecmascript-2015](https://egghead.io/courses/learn-es6-ecmascript-2015)

Once you get a good grip of the language, and are comfortable writing code,
you can jump into JSX, React, Vue, and later TypeScript. Enjoy!

------
revel
Since ES6 JS has been attempting to satisfy two radically different models for
software development: the classic Object Oriented Programming (OOP) style and
a Functional Programming (FP) approach. Some frameworks are better suited to
an OOP approach and others clearly expect you to use FP. Neither approach is
inherently wrong -- although you will certainly find passionate folks making
arguments to the contrary -- but if you mix and match approaches you will end
up with an unmaintainable mess.

~~~
mr-ron
I dont think this has only been the case since ES6. There have been plenty of
OOP approaches over the years. The 'Prototype' method alone has caused serious
confusion for me for as long as I had to work with it.

~~~
revel
I agree with you but I do think the problem has become significantly worse
since ES6.

------
geoelectric
Worth noting there are still a number of ES5 projects out there and some of
the ES6 changes can be more deeply understood as sugar around now-legacy ES5
concepts (async/await vs. fluent Promises and the class/object model in
particular).

While I agree with the advice to be very conscious of how modern a given
tutorial is, there's some value in knowing what the legacy code would look
like as well. Even projects that transpile ES6 to ES5 can have gotchas that
knowing ES5 helps avoid.

Re: TypeScript, etc., I'd recommend thinking of those as entirely different
languages for now, and learn a little vanilla JS--same with any of the major
application frameworks. JS is a great language to write more structured or
domain-specific languages in, and that's what most of these frameworks
effectively do.

------
raztogt21
I've been developing 3 years with JS almost exclusively. The best book out
there to start is 'Secrets of the JavaScript Ninja 2nd Edition' by John Resig
and Bear Bibeault.

I'd recommend you grasp the fundamental concepts of vanilla JS before jumping
between React, Vue or Angular.

Vue is a complete framework, great documentation and I'd prefer it over React
since is less verbose, not a big fan of JSX (the internal language to write
components of React) and I'd consider it less intuitive than Vue.

------
projectramo
This doesn't apply to newbies who don't know other languages, but since you
know python and java, there are two things that got tricky for me with JS as a
language.

1\. Learn about execution contexts early, and how returning functions is a
trick.

2\. The history of JS is the history of trying to get around single threaded
nature. So there are callbacks and promises and other constructs. Learn about
them.

~~~
WorldMaker
Re: 2: The history of language in general has included a lot of detours
dealing with asynchronous programming. Python, which the OP mentions as
familiar, has an almost even more convoluted history of asynchronous
programming patterns than JS.

Both languages have settled on the async/await keywords for the most part
these days, and the underlying components are relatively similar, though
Python's coroutines are a little more complicated/hands-on than JS Promises.

On this subject, I highly recommend finding an environment that lets you use
async/await patterns today. It makes working with Promises a lot
easier/cleaner, and also makes you aware of why Promises are so great and the
remaining other options such as callbacks should be wrapped with Promises then
otherwise forgotten. Babel has transpilation options for it, but personally
I'm strongly in favor of Typescript.

------
ArtWomb
Focus on mastering the DOM and Web APIs as you learn. You could even try
building a minimal, single page web application every day for the remaining 6
weeks left this summer ;)

The simpl.info site "provides simplest possible examples of HTML, CSS and
JavaScript" to help get started. Good Luck!

[https://simpl.info/](https://simpl.info/)

------
yayana
I would avoid frameworks but embrace transpiling and popular libraries.

es6katas.org is a nice starting point for newish es6 to look up in MDN.

After a couple years any es you are transpiling now will be usable directly on
websites so you then have more of a choice in direction.

Frameworks might not be any more stable in another 2 years but adapting with
them is much easier as you know more modern js.

------
gwbas1c
First, you really have to use some kind of a wrapper for the DOM. Very few web
development is done directly against the DOM, due to design flaws and browser
incompatibilities. (Unlike Windows / Mac / ios / Android where you just use
the API that the OS vendor provides, and it's usually decent.)

But, those various wrappers get outdated very fast. The UI APIs on Windows,
Mac, Android, ios, ect, change very slowly.

In Javascript, whatever framework / library / pattern / ect that you use to
manipulate the DOM seems to change every few years.

------
superasn
I think you should completely wrap your head around JavaScript's prototype
chain before learning anything else. Since you are coming from Python the
Javascript objects will be a bit of a shock. and regardless of the framework
you choose you will have encounters with this strange Javascript inheritance
(like angular 1 $scopes used it).

Personally I would recommend Vue once you're ready because you can get started
with it right away. Also like others said learning webpack, npm will be really
beneficial.

------
hluska
If I were in your shoes, I would start with vanilla ES 5 (no package manager
or framework) and build a simple project. In the beginning, you want to figure
out big concepts like the event loop and all the ansynchronous stuff. When you
first get started, all sorts of shit is going to be undefined, so log
everything to the console and pay attention to how variables go from undefined
to defined.

If you can't think of an idea, try building an accurate HIIT timer with
vanilla JavaScript. Have a simple backend where you can save/retrieve/edit
results and build an interface for that. But, don't get bogged down in package
management, Webpack, libraries or any of the other shit.

Once you're finished that, ideally, you'll be in a position where you feel in
control of your variables. You'll have some understanding of how JavaScript
chains together, and a sense of how things will happen under the hood.
Hopefully, you'll also be good with your chosen browser and its developer
tools, especially the JavaScript console. And, with some luck, you'll have
enough exposure to the 'interesting' parts of JavaScript that moving to ES 6
will seem like an actual upgrade.

At that point, you should be ready to start learning slightly more modern
JavaScript. Then, it would be wise to move into a framework. Currently, your
three big choices are Vue, React and Angular. I have little experience with
Vue, so I'll let more experienced people weigh in there. Angular seems to be
getting a little less popular, though it could just be because, since they
started using semver, they've seemingly released a new version every eleven
minutes.

------
senthil_rajasek
Surprised that no one has mentioned Douglas Crockford.

I would recommend his book JavaScript: The Good Parts
[https://books.google.com/books/about/JavaScript.html?id=PXa2...](https://books.google.com/books/about/JavaScript.html?id=PXa2bby0oQ0C&)

And his Google Talk,

[https://youtu.be/hQVTIJBZook](https://youtu.be/hQVTIJBZook)

This is for plain JS.

~~~
mxschumacher
after all the change the language specification and the various
implementations have experienced, you'd still recommend a beginner to read a
10+ year old book?

~~~
icc97
Yes, because it's a great book. Everything in the book is still relevant,
closures, currying, object binding.

If you use the syntax he suggests all your code will still work.

Just because let and const mean you can avoid some problems doesn't mean you
shouldn't know why we have them.

The Monads and Gonads talk [0] he gave is also great.

[0]:
[https://m.youtube.com/watch?v=dkZFtimgAcM#](https://m.youtube.com/watch?v=dkZFtimgAcM#)

------
egfx
Angular and React are two different beasts that do pretty much the exact same
thing. The learning curve of React is much easier then Angular. Versions
matter much more then you imagine at first. As in versions of Node, Angular,
etc. Never underestimate the power of jQuery still. Sometimes you just need a
short cut.

------
kace91
If you're coming from backend languages, perhaps you'd find it easier learning
node first, then going into the front. This way you won't have to learn both
the concepts of front end development and the new language all at once, you
can do language first then front end paradigms

------
m3tr0s
0) If you want to "get into JavaScript", don't even think about frameworks
yet.

1) Read JavaScript: The Good Parts first. _First._

2) Build things, don't just read. A complete industry wants to teach you only
React with infinite materials.

3) If you want to read, read the official documentation on MDN, not 3rd party
materials. Those become outdated quickly, also most of them are crap by
default.

4) Choose a framework with low barrier (yeah, it is Vue, not React, sorry),
and build something. Finish it. With the tools you chose first.

5) Stick with the framework you learnt. Always will be a better one.

6) Subscribe to related Cooperpress newsletters, and go through interesting
links regularly to stay up to date.

------
iKSv2
A lot of your (my problems) would be solved if you understand what is async
(as Zyst has already mentioned). This was a very very big problem for me
coming off PHP (which is sequential, statement 2 gets executed after statement
1). So when I started with ajax requests, I used to put in timeouts, for loops
which will wait for 1 second and see if operation completed or not and what
not.

That and not declaring variables in global scope unless completely required.

Also I wish I had known to start with Vanilla JS and stick to it unless
completely familiar then jump to frameworks. I started with jquery and the
withdrawal was awful but heavy learning experience IMO.

------
cbayram
Most of the confusion and frustration rises from lack of understanding of the
runtime execution and not the language; in case of JS:

\- execution flow and temporality of the code excecution(async, promises,
etc...)

\- interoperability and boundaries of JS with the DOM, styling and HTTP(WS)

This hold true for most languages; concurrency, parallelism, etc... The devil
and mastery is in the learning execution environment.

The static nature of writing code to represent dynamic, living state machines
presents a gap and confusion.

My advice is to learn core technologies really well; JS, DOM, HTML, CSS,
HTTP(S)/WS(S). Once you do this, you’ll quickly understand and debug
tomorrow’s frameworks.

------
headcanon
If I could pick one thing that I wish I would have known, it would be the
understanding of functional programming techniques. Adhering to FP principles
like functional purity and composition has made my applications infinitely
cleaner, more maintainable, and easier to test. My work mostly involves React,
which is very well suited to functional-style programming, so if you're doing
something with heavy graphics or some other application, YMMV. However for
react apps or anything that returns virtual DOM nodes as a response to state
change, FP is the way to go IMO.

------
gnarcoregrizz
Before? How an event loop works under the hood (select) so you understand the
single threaded nature (the benefits and pitfalls). Most resources cover the
effects of this pretty well, but it's always nice to understand how it works
by implementing a toy project with the syscalls directly

JS is a fun, but sometimes frustrating language to learn. The async-first,
functional model is eye-opening and interesting (depending on where you're
coming from!). I also find it more fun to program in than most other languages
for some reason. Enjoy.

------
octosphere
> Which framework should I stick with?

When starting out it's best just using vanilla JS, otherwise you are dependent
on frameworks to do the grunt work, and you will often wish a framework had a
certain feature (you are best cooking up your own methods in vanilla JS). As
for what frameworks to 'stick' with, I would go with something like Vue or
jQuery, but more often than not you will not need them (Using Vue as an early
entry to learning JS is like bringing a gun to a knife fight).

------
hinkley
That doing your backend in JavaScript means you never get a break from
JavaScript.

I didn’t know that was an issue until I had been using Node for two years. On
previous projects I’d jump on a story outside my usual wheelhouse every so
often for the variety. Even three or four weeks a year seemed to be enough.
But now I can’t get away from it, ever. I suspect this will end up being in
the calculus when I am explaining why I took a new job in a new vertical.

------
sunnykgupta
Make sure most of your tutorials are around the language and not specific to
some frameworks.

Being able to understand the underlying language has been key to finally get a
grasp on what happens under the hood with Modern Magical Frameworks.

Also, being able to understand the event-loop and how JS manages memory etc is
worth getting into once you have the basics clear. I recommend understanding
the internals of V8 at some-point down the line.

------
machiaweliczny
1) Watch this:
[https://www.youtube.com/watch?v=8aGhZQkoFbQ&t=1s](https://www.youtube.com/watch?v=8aGhZQkoFbQ&t=1s)
2) Understand how `this` binding works. 3) Understand async/promises. 4) Learn
debugging tools (`debugger;`, `$0`, how to turn on/off source maps etc.) 5)
You will have to learn compiltion tools (babel and webpack)

~~~
machiaweliczny
As an exercise I recommend implementing most of utility functions from lodash
library according to spec.
[https://lodash.com/docs/](https://lodash.com/docs/) (lodash is popular
utility library)

------
TheJoYo
I believe every language has something to teach us so I'm not dismissing
JavaScript, but why are you learning a language? The answer to that question
will promote some answers to your questions. If you are just learning
JavaScript to learn it you'll have a hard time getting the information you
find to stick with you. Having a project to implement will give everything
else you do purpose.

------
wishinghand
I wish I had known all of the objects on `console` besides `log()`. There is a
way to show data in a table, timers, nesting logs, and more.

------
jfk-in-sd-ca
I think the original question is pretty good one. Wish more time had been
spent answering it directly instead of having to wade through all the replies
to prove who's is bigger (brains) and who is more right.

The message is clear to invest the time upfront to learn it. What resources do
people recommend and does it make sense to focus on specific framework?

------
jorangreef
"What are some things that you wish you had known before getting into JS?"

You won't be able to program your hardware:

1\. No SIMD. SIMD is becoming important for anything fast.

2\. No instructions like `__builtin_ctzl` for counting the number of leading
zeroes (essential if you're working with bitmasks).

3\. No fast uint32_t. 32-bit integers in Javascript are much slower than
31-bit integers in Javascript because of boxing.

4\. No fast uint64_t. It's nearly here, but whether (and when) it will be
optimized remains to be seen. Say goodbye to fast hash functions for the next
few years.

5\. You won't be able to do Daniel Lemire's fast mod alternative:
[https://lemire.me/blog/2016/06/27/a-fast-alternative-to-
the-...](https://lemire.me/blog/2016/06/27/a-fast-alternative-to-the-modulo-
reduction/)

6\. Slow bridge to C, you can expect 20-25ns per call. This means that for
things like implementing a fast hash table, you could try compensate for the
lack of the above by using a native addon written in C. But even then, the
calling back and forth will cancel any gains.

Basically, the hardware is moving ahead, and languages like Javascript are not
keeping up.

You're going to be able to do a lot of these things in newer languages,
however.

Apart from that, Javascript is a fantastic language.

------
defertoreptar
Decide what you're going to do about importing and exporting code before
diving in. It's a whole can of worms.

------
derekp7
I think it is helpful to have some deeper programming language theory when
learning JavaScript, so you can recognize what it is really doing behind some
syntactic sugar. Specifically, first class and anonymous functions, closures,
the whole event driven model.

------
dyeje
It's actually not that bad if you stick to the basics. I'd recommend just
using Webpack + Babel to start so you can use the latest JS features and get a
feel for what vanilla JS is. After that pick whatever big frontend framework
clicks with you.

------
slipwalker
TDD. i wish i had a clear understanding of how much easier a dynamic not-typed
code became when you write your tests ( at all ) first !

( it was around 1998-2000... i guess there was _no_ unit-testing library for
JS by then )

------
backspaces
This is easy: check out D3's architecture. It is "near functional" and tosses
all the overly-complex (i.e. dangerous) parts.

And definitely read the still important "Javascript, the Good Parts".

------
Xeoncross
Javascript is not just a language anymore. It's the world's most complex and
complete ecosystem comprised of several languages and dozens of specialized
frameworks for multiple platforms.

Javascript Languages:

\- Javascript

\- Coffeescript

\- Typescript

\- (basically) Dart

Popular Javascript Language Additions:

\- JSX

\- Flow

~~~
mxschumacher
it's important to note that these specialized frameworks often are
abstractions over the web API, the DOM and JS.

E.g. lodash is a pure abstraction over JS, but React/Vue/Angular are much,
much more.

------
mabynogy
That I should have not spend time at all on the "ecosystem" (npm, typescript,
transpilers...). It works well out-of-the-box.

------
icc97
I wish I'd known more about functional programming. The great bits of
JavaScript are the functional bits.

------
scottmf
If you’re reading something which suggests you use CoffeeScript, it’s probably
terribly outdated.

------
whatsstolat
I wish I had taken js more seriously. Read something like "you don't know js".

------
_virtu
> I want to learn JavaScript as my next language.

Welcome!

> I have been observing JS community for some time and it seems like there is
> too much noise out there with dozens of frameworks and language variations
> (e.g. CoffeeScript, TypeScript, JSX, etc).

Yeah, this is a double edged sword. People are always looking to build the
next best solution, which is great for you as a consumer, but it's also
terrible for you, because decision fatigue sucks and your decisions can feel
like they're outdated in months, not years. Just make an informed decision
when you go out to pick something and stick to it as long as it works for you.

One thing to know is that a lot of this is caused by the challenges of trying
to hit the moving target that is web browsers. My biggest piece of advice for
cutting through the bullshit is to find your root problem, then pick the
handful of tools that actually solve it. Don't just use something because
everyone else is using it; no need for cargo cult mentality.

> I plan to go through Mozilla's JS docs and Vue tutorial, but not sure if it
> is enough to get up to speed with the modern JS ecosystem.

Go through the MDN JS docs, build fundamentals. Read through some library code
like jQuery or a utility library like lodash to get a flavor of some
interesting things that come up when building a frontend library.

> Which resources would you recommend?

Roadmapy resources:

\- [https://github.com/FrontendMasters/front-end-
handbook-2018](https://github.com/FrontendMasters/front-end-handbook-2018)

\- Ponyfoo has some great es6 resources as well

> Which framework should I stick with?

Find what works for you. Just try to avoid things that have so much tooling
you get paralyzed looking at how it works instead of doing something
interesting to you. If you start with react use create-react-app to figure out
the fundamentals. I'm sure there are equivalents to create-react-app that
correspond to create-<library>-app nowadays.

> What are some things that you wish you had known before getting into JS?
> Note: I am comfortable with Python (including Flask/Django), Java, HTML and
> CSS, so picking up JS as a language won't be a problem. Interested in your
> thoughts.

\- Learn about the different environments that js is run in and how this can
impact certain things like module definitions, e.g. why is there amd, umd and
commonjs?

\- Learn about functional programming in the context of js. It's a nice
mixture between the two. Learn when to use one with the other.

\- Understand the inheritance model, prototypical inheritance isn't that bad,
just get it out of the way.

\- Understand the runtime and event loop. This will inform you why you'll see
things like callbacks, promises, generators and now async/await. Here's a
fundamental breakdown of the event loop:
[https://2014.jsconf.eu/speakers/philip-roberts-what-the-
heck...](https://2014.jsconf.eu/speakers/philip-roberts-what-the-heck-is-the-
event-loop-anyway.html)

\- Learn about the browser lifecycle

\- Invest in learning the chrome dev tools or ff dev tools, they're both
wonderful and will save you hours

~~~
mxschumacher
I don't see the benefit of studying the jQuery source. I'm grateful for every
$-littered line of code I get to carve out of our projects

~~~
t3h2mas
Regardless of how you feel about $-lines, we can all learn from reading
project code.

------
jskulski
For context:

\- 2003, I needed to learn JS to move into a professional web developer
position (from systems eng). I started with mootools/dojo/yui and jquery, when
it came out in 2006.

\- 2009, apps started to get very complex and hard to maintain. Or I got
experienced enough to figure there'd be a better way so I started working with
backbone, (some) emberjs, and (a little) angular.

\- During this time, I also built a number of native javascript apps because
frameworks and tooling were eating up a lot of my time. I also wanted to
understand the language.

\- Eventually, I found elm because I started getting interested in type
systems. I _really_ liked elm but it was a hard business case to make for a
team. I settled into redux/react these last few years because it gets pretty
close.

\- The first project I 'did in' redux/react' was actually just plain
javascript. I naively implemented the react and redux api and patterns. This
was _incredibly_ helpful. Not only did I quickly gain a fuller understanding
of the tools I was about to use, I started to understand the muddier parts of
JS: the event loop, async, hoisting, scoping, etc. I was aware of them before
this, but I kinda just fiddled til things work. Afterwards, I knew what the
computer was doing.

So, to answer you question 'what do I wish I'd known':

I wish I knew how much of JS is choosing a platform/toolset. I also wish I
knew that that tool choice is just the start and doesn't guarentee anything.
You can write a clear and easy to work codebase with JQuery. You can also make
a hard as heck piece of junk in react.

I would suggest not too get hung up on it. It can be hard/impossible to choose
the right tool if you don't have experience with the tooling or the problem.

So, get ready to jump around. I would get ready to pick a tool for a few
months, then move onto another one. In my experience, there is not a great
answer for questions like 'what is better, vue or react?' The answer is
subjective, a choice that reflects personal and team preferences. You can be
productive in both, so it's more about sticking to one.

JS, like every other software project, still benefits from core engineering
principles: \- team dynamic and trust are !important! a framework will not
help if a team member feels they are not trusted/growing/learning/producing \-
prioritize readability, code is read more than it is written, \- prioritize
simplicity, break complicated stuff into small, composable pieces \- with all
due respect to the thousand of work hours put into webpack, it is still a pain
in the butt ;)

Good luck!

------
JAdamMoore
Create-React-App, RxJS, Styled-Components, and Rebass are my go-to helpers.

I would reccommend [Quokka]([https://quokkajs.com/](https://quokkajs.com/))
and [VSCode]([https://code.visualstudio.com/](https://code.visualstudio.com/))
for the fastest time-to-grok

