DEV Community

What are your biggest struggles in learning JavaScript?

Yaphi Berhanu on July 13, 2017

What are/were your biggest struggles in learning JavaScript? This question can refer to specific code issues (like working with arrays) or learnin...
Collapse
 
perrydbucs profile image
Perry Donham

Tutorials and stackOverflow. For some reason Javascript tutorials often start with "In this tutorial we will write a simple ..." and, 12,000 lines later you can't remember what it was you were trying to learn.

And stackOverflow...OMG! Ask a simple question on SO like "Hey, these four lines of code are in an IIFE, where is variable foo visible?" and you'll get

  • 9 comments asking why you are using an IIFE
  • an argument regarding the use of the keyword var
  • 14 reasons you should be using Python instead of Javascript
  • a correction for a typo in one of your four lines
  • a correction to the correction that insists the typo is intentional and within spec (with a link to a Fiddle to prove it)
  • a complete refactoring of your four lines into ES8 to show how much simpler it will be
  • the history of foo, bar, and baz

New JS programmers spend a lot of time in the magical incantation stage, copying and pasting random code from the web that they hope will run correctly but that they can't explain how it works. Some never escape it!

Collapse
 
zzzzbov profile image
Timothy

As a 100k user I'm certainly biased, but I don't agree with this at all. What it sounds like is confusion over what Stack Overflow actually is.

It isn't a place to learn new languages like JavaScript. It's not meant to train people on languages or provide tutorials. It's meant to find specific answers to specific questions.

And with that, if someone asks another "I don't know how IIFEs work" question, I generally dupehammer them to "How do JavaScript closures work?", and scold them for not having done enough research.

Collapse
 
perrydbucs profile image
Perry Donham

I think that you just made my point ๐Ÿ˜‰

Collapse
 
zeropaper profile image
Valentin Vago

Yepa.

You just described the separation of concerns concept fairly well.

Thumbs up!

Collapse
 
albertdugba profile image
Albert

You're damn right

Collapse
 
yaphi1 profile image
Yaphi Berhanu

This is hilarious and true. Very well put.

Collapse
 
ben profile image
Ben Halpern

Beautiful description ๐Ÿ˜‚

Collapse
 
binaryforgeltd profile image
Bart Karalus • Edited

Back in the days, for me personally the most confusing thing was what 'this' actually is.
When I speak to many less experienced devs today, the most frequent struggle mentioned are 'scopes' and 'closures'.

Collapse
 
ben profile image
Ben Halpern
Collapse
 
daveblythe profile image
Dave Blythe (he/him)

this++

Collapse
 
binaryforgeltd profile image
Bart Karalus

Good one Ben! Or how Shakespeare would say... "This... or not this?"

Collapse
 
danwright profile image
Dan Wright

_self

Collapse
 
le_newtype profile image
Nicholas โ€•Mโ€•

Kind of silly, but sometimes knowing what some things are, but not knowing what they're called can be difficult or disheartening, especially in an interview or skill-building situation. Some examples that I've personally struggled with include, but are not limited to: closures, hoisting, various design patterns (module vs constructor vs API vs factory vs x100000 other ones), etc.

That feeling of inadequacy, followed by a realization that I actually knew what was being discussed all along (coupled with an "Oh, there's a name for that?") can take a while to shake off.

It can also be hard to discern "Is this a programming thing?" or "Is this a insert framework context here thing?" since JS is prone to having multitudes of vocabulary words being tossed around at any given time.

Collapse
 
inceptioncode profile image
Darrell Washington

I definitely agree and feel your pain on that one. I'm a young developer and I often times leave interviews thinking, "I just know how to code I don't know all these technical terms." It's so frustrating and I feel slow or lost at times.

Collapse
 
yaphi1 profile image
Yaphi Berhanu

That's one of the most frustrating things when you knew a topic all along but you just didn't know one of the terms for it.

Collapse
 
kspeakman profile image
Kasey Speakman • Edited

My entire dev career has been web, and I am really tempted to bash JavaScript here. :)

I will say that JavaScript has a lot of quirks which can bite you. Nowadays, a lot of libraries or preprocessors help by giving expressions of code which are more robust while staying on the happy path. But there continues to be a lot of churn in tooling and libraries around JavaScript to smooth out rough edges, especially given the (web) platform's popularity. So don't wear yourself out. I've put stuff into production on a lot of different platforms from pure JS to Angular that were "the new thing". Mostly to disappointment that the same problems were just in different places. Nowadays, I try to avoid writing JS code. For web UIs, I have been using Elm and my experience so far in maintaining its code has been very positive.

Collapse
 
inceptioncode profile image
Darrell Washington

I think Elm will be the norm soon. I haven't had a bad experience with it yet either. Even though I haven't used Elm for to long, I can't help but feel it's just the permanent way to go. I can't wait for it to be everywhere.

Collapse
 
kayis profile image
K

Can't see this happen.

Elm is awesome, but it's also rather different and self contained. Many (JS) devs sadly just don't like FP.

Thread Thread
 
kspeakman profile image
Kasey Speakman • Edited

Ironically, FP-ness is general and transfers even to OO languages. E.g. JS's Array.map, reduce, filter, lambdas, etc.

 
inceptioncode profile image
Darrell Washington

Yeah, I understand your point FP to me is great but I just started programming and didn't like learning OOP with JS. So it was easy for me to switch paradigms or practices a little. Everyone has there preferences though.

Collapse
 
mohannad profile image
Mohannad Najjar

I was going to say this and scopes, but since it's mentioned already, I will say: Compilers and Presets and Browser Support!

There is so many to figure it out, TypeScript & Babel & ES2015 & ES2016 & ES2017 . and the whole ECMAScript 6 Compatibility with browsers, See This Compatibility Table for example.

Collapse
 
eldelshell profile image
eldel$hell

Not sure for how long you've been working with JavaScript, but believe me, today, it's a bliss since most browsers (specially MS, although Safari is the new MSIE6) put their shit together. Just a few days ago some potential client kind of dropped the bomb about supporting MSIE-8 and all the nightmares came back.

Collapse
 
fezvrasta profile image
Federico Zivolo

If a client asks to support IE8 I just make him pay its support as a brand new project. That's it.

Thread Thread
 
fabth profile image
Mr Dude

We do exactly the same, old and non standard browsers are quoted as an extra and separate part of the project.

Collapse
 
willluce profile image
William T Luce • Edited

Lots of good answers here, but I'd like to add that, due to JavaScript's history, people don't learn it the way they do other languages.

In my experience, when people pick up languages like Python or any of the C family, they grab a book and work through it. Along the way, they're learning how the language works and the ins and outs of how to solve problems using that language. So, things like syntax, common patterns, and the quirks of that language are naturally introduced.

With JavaScript though, new people just start grabbing at tutorials that show them HOW to do some specific thing or HOW to use some new framework. At no point are they learning actual JavaScript.

Learning React, Angular, Ember, Lodash, or any other plug and chug tool is not learning JavaScript. Going through a "What's new in ES6!" blog post is not learning JavaScript. Even learning Node is not learning JavaScript.

Read You Don't Know JS, all of it and actually LEARN JavaScript.

Collapse
 
yaphi1 profile image
Yaphi Berhanu

You know, I never thought about it, but this makes so much sense. Fantastic points.

Collapse
 
sephcoster profile image
Seph Coster

When first starting out as more of a hobbyist one of the first things I struggled with was how best to use objects and the object structure to store and use data. When to use OLOO vs. a class-like structure to properly scope functions, when to use prototypes, etc. Much of this has been "figured out" or at least made easier in the latest versions of ECMA which is nice.

Working with promises / async and chaining multiple things together to ensure state came together properly (in the jQuery days) and you didn't get "undefined" for your variable that logged just fine in the console was the next annoyance. Abstractions for these are pretty high quality now and somewhat easier to use but I definitely recommend gaining understanding before using otherwise it will bite you eventually :)

this (as has been said) is also an issue for me. Can still bite but at least I know to think "hey which this is this?" now.

Testing. Testing is super important but all the frameworks out there do it slightly differently and figuring out how to mock async / nested / imported stuff from scratch can be super hairy and difficult. I would still kill for an awesome tutorial on JavaScript testing practices. I wish I had started my testing discipline earlier so I had better muscle memory here.

Collapse
 
fezvrasta profile image
Federico Zivolo

DOM APIs are probably the hardest part. You never know all the nuances of each of those methods...

For instance, just yesterday I found a bug in my library because I used .offsetParent to get the first "positioned parent node", and I discovered that this property will give me the nearest "table" element if no positioned parents are available...

Collapse
 
lindakatcodes profile image
Linda Thompson

One: I can follow along with a tutorial no problem, understand what they're saying, write it all myself (instead of copy/paste) and all makes sense. Go to apply it on my own, either starting with a new project or adding it to something I was already working on - and I get a type of paralysis. Applying it on my own, without someone walking me through it, is regularly a huge hurdle for me. It's almost like my brain just isn't really absorbing it. Or so much of the other code (their styling and html and such) is taken care of that when I mix in the new stuff I don't know how it plays with everything else, because I didn't have to think of that in the walkthrough. I normally work it out and I'm fine, but it often stops me for awhile.

Two: Setting up my own dev environment. This still gets me almost every time, though I'm getting better. When you're learning the language so much is guided and focused on the actual language and on using tools that handle most of the other stuff for you. Which is great, in it's way....it's just hard when you go out on your own to really find a flow that works and lets you see what you're changing as you go.

Collapse
 
garyfalkland profile image
Gary Fitzwater

As for point one exactly how I feel, I go along with tutorials but when it comes to working on my own I hit a brick wall.

Collapse
 
aswathm78 profile image
Aswath KNM
  1. As a complete beginner ,t he biggest trouble is finding the right guide(which or whose learning path should I follow ???).

  2. Angular or React or Vue???(which front end framework)

  3. ES5 , ES6, ES7 , ES8 ?????(How many things should I learn ???)

  4. Babel , JSX and how many more ?

Collapse
 
tifflabs profile image
tiff

I think you use JSX with React anyway. Just HTML in your JavaScript which is a React thing.

Collapse
 
maxart2501 profile image
Massimo Artizzu

Declaring a "class" with a function, and adding methods dynamically with this weird prototype object. How weird!

But really, learning JavaScript has been, fortunately, quite easy forward for me. I'm kind of puzzled of all the issues about it.

Collapse
 
fred_amare profile image
๐Ÿ‘‘ Fred Amare

Callbacks and closures

Collapse
 
tifflabs profile image
tiff

The easiest way I can tell you about what a callback is: it's just a function passed as a parameter to another function. jQuery uses callbacks a lot. Still trying to wrap my head around closures.

Collapse
 
ben profile image
Ben Halpern

Callbacks were impossible for me to wrap my head around when I was first getting into JS. Beforehand I had mostly been coding in Ruby and things are just not done that way (well, asynchronous programming in general is not really a Ruby things)

Thread Thread
 
fred_amare profile image
๐Ÿ‘‘ Fred Amare

Same as me... I started my coding journey with python. What a beauty that language is ๐Ÿ˜

Collapse
 
fred_amare profile image
๐Ÿ‘‘ Fred Amare

Ha! closures...

Thread Thread
 
tifflabs profile image
tiff

Right?

Collapse
 
eldelshell profile image
eldel$hell • Edited

Been using JS for... 17 years or so... and I still struggle with the different ways other developers find ways of doing stuff. I'm talking from formatting (2/4 spaces, double/single quotes) to OOP/FP/ES6 or weird patterns like jQuery plugins or JSX files.

Other languages (C/C++/Java/C#/Python/Go) seem to be teach on a more standard form and it's easier to read code written from a guy on the other side of the world from 10 years ago. You can't even find two JS code bases with the same formatting for documentation.

JavaScript developers really really need to get their shit together and follow some sort of standard. PEP, javadoc and go-fmt are great tools to look into.

Collapse
 
yaboibrooks profile image
Adincath • Edited

I also have issues keeping up with best practices. In ReactJS, I started with the create-react-app boilerplate. As soon as I got something concrete going for an app, my co worker was adamant that React Boilerplate because it's super efficient and ASYNC REDUCERS AND SAGAS WOW!

This compounds because React is just one part of the entire JS ecosystem and even just keeping up with it can be hard.

Collapse
 
val_baca profile image
Valentin Baca
  • Closures and 'this'
  • looping over properties
  • browser nuances
  • browser support. All these neat new features arriving in JS that I don't know if I can use or not
  • libraries that use .map(index, item) vs .map(item, index) (The latter is the better BTW)
  • var functions vs function declarations
  • naming conventions clashing between JS, CSS, and AJAX (camelcase, hyphen-case, and lowercase respectively)
  • funky auto-casting
  • double trouble 0.1+0.2 != 0.3
  • null, undefined, and undeclared
  • === and !==
  • "Optional" semi-colons
  • Frameworks that multiply like Tribbles

Each one on it's own is an inconvenience and every language has its issues. But put all of these together and it makes coding a terrible experience.

Javascript really is the English of programming languages. It's ubiquitous and it's surprising how much gets done in it, but it's not a beautiful or good language by any stretch of the imagination.

It makes me wonder everyday why Node.js was/is a thing that grew beyond just an April Fools joke.

Collapse
 
heroofcanton profile image
Ryan Welling

Where to begin. I come from a strongly typed, compiled background, and JS seems like a hodge podge of a dozen different languages. Every new ES version released seems like the try to pivot and make the core language more like something else. It's confusing to me when JS wants to be object oriented, and then doesn't. The whole idea of a DOM really confuses me, and don't get me started on 'this'.

Collapse
 
rhymes profile image
rhymes • Edited

I'm more of a "backend" web developer who actually loves JS, so I'm definitely not a JS expert but my biggest issue is time (or more precisely lack thereof) in small to mid solo projects.

The amount of tooling (though it seems lots of people are converging towards Webpack + Babel + ES6) required to setup any web framework with "modern" JavaScript is kind of ridiculous. Especially if you have a "legacy" jQuery + backend app that you want to slowly port over.

React seems fantastic but the learning curve is quite steep if you combine the tutorial, ES6, all the react-* libraries, your own brain that keeps asking "how do i do this jQuery three-liner in React" and so on.

I am super happy that the ecosystem is so vibrant and huge and it's harder now for a single person to keep all of this in their brain but I feel like that server technologies have more of a grip in the evergreen issue of "complex vs complicated". Most of the server side web frameworks now are immensely complex but are not complicated to use.

React to me seems both, and again, I'm not an experienced frontend developer so it might just be me.

Am I making sense?

Collapse
 
yaphi1 profile image
Yaphi Berhanu

I completely get what you're saying about the setup pain with all the tooling. It feels like a lot to keep track of for sure.

Collapse
 
imthedeveloper profile image
ImTheDeveloper

I used to be a full time developer in the early days of my career and I could spend hours testing out new things, reading up on best practice and spend time understanding so that the hours of pain became muscle memory fixes driving really efficient code. Heck I even spent time helping others out on a few select SO tags.

Now? I changed role and moved into IT architecture along with a wife and child I've now become a "hobby Dev" working on personal projects.

Why is this information important? Well I loved node and JS but now I really don't know.
I can spend a few months busy with life and suddenly the whole js world has changed. I can't keep up.

I no longer have a clue how to structure my code.

I have no idea which version of node I should be using.

I look at the cool framework I was just understanding and I see it's in ruins and deprecated.

I read a tutorial and everything but the inside of the function looks like it's written in another language.

I find I'm starting out all over again each time.

I load up my editor and after printing out to the console I look at the clock and realise my hour of coding time before worj is over.

The speed of node ecosystem movement is infuriating.

I won't be changing my preferred language anytime soon though.. theres something perverse trying to keep up with it all.

Collapse
 
khophi profile image
KhoPhi • Edited

Should I say I made a fool out of myself in an interview, when I was asked related to Javascript:

'What is the result of 3 divided by 0 (3/0) in Javascript?'

With my Python Ninja Hat still on, with lots of sprinkles of common sense, was quick to say, 'ZeroDivisionError, or an error similar.'

For once in my life, I felt 100% confident about an answer, except to JS, when you divide a number by 0, you're in Infinity.

smh

Collapse
 
tifflabs profile image
tiff

My first programming language outside of the modified BASIC language for some old hand-me-down I got when I was 12, was Ruby. I went to a meetup and learned some of it. Damn did I love it. But I kind of knew then I wasn't going to work with it. JS is pervasive and while it is certainly monolithic in terms of tooling and ECMA trying to figure out what JavaScript actually is (is it OOP? Prototypal? Functional? ยฏ_(ใƒ„)_/ยฏ) I like it.

I still have some trouble with it but all in all. It's a fun language. Well designed? Debatable. Ruby is beautiful. But I guess JS is the way forward for now. (Seems Elm and Web Assembly might be better options?)

Collapse
 
sreedharbukya profile image
Sreedhar Bukya

asynchronous nature in debugging and this

Collapse
 
laijoann profile image
Joann

ASYNCHRONOUS. Y E P. 100%. When I hopped from Java to JS, the fact that JS is asynchronous is definitely the biggest trip up.. ๐Ÿ˜…

Collapse
 
janguianof profile image
Jaime Anguiano

same here : )

Collapse
 
kav2k profile image
Alexander Kashev • Edited

Choice.

With modern Javascript being what it is, the question of what to learn becomes more problematic than how.

Collapse
 
aghost7 profile image
Jonathan Boudreau

Personally the biggest issue was learning how to structure my code. At the time when I was learning there wasn't really any idiomatic way to organize your codebase.

Collapse
 
luispa profile image
LuisPa

The 300 ways to do the same thing.

Collapse
 
ben profile image
Ben Halpern

Keeping up with patterns and best practices as the language and ecosystem evolves is a struggle for me. Other environments seem a lot less likely to change from under my feet.

Collapse
 
binaryforgeltd profile image
Bart Karalus

That is very true.
At some point I have realised how flexible this language is and the amount of surprising ways I have seen people using it so far only made me want to finally find those best practices for me.

Collapse
 
jess profile image
Jess Lee

Callbacks and promises!

Collapse
 
le_newtype profile image
Nicholas โ€•Mโ€•

These can be difficult for me sometimes too!

Collapse
 
fallenstedt profile image
Alex Fallenstedt

The biggest struggle I had was the transpiling craziness that is modern JavaScript. I found that I had to spend a decent amount of time setting up a transpiling environment just to start coding.

Collapse
 
chinjon profile image
Jonathan Chin

Graduating from basic loops to higher order functions.

Collapse
 
martin_adams profile image
Martin Adams

For me it's not about the language but more about the tool sets around it, things like Webpack. Lots of varied documentation styles and not enough working examples.

Collapse
 
evebanigo profile image
nemi.js

Algorithms! Those are my biggest issues with javascript. It's such a fun language to learn, but somehow, I've found it a bit daunting to solve common questions, whether with inbuilt functions or not.

Collapse
 
conanskyforce profile image
Kevin

endless frameworks and relative technical stacks.... ๐Ÿ˜‚

Collapse
 
jbmh profile image
JB

Everyone else already said "this" but I think it's classes and abstraction. So abstract!

Collapse
 
parthpower profile image
Parth Parikh

ASYNC CALLBACK FUNCTIONS WITH ARGUMENT YOU ARE SUPPOSED TO REMEMBER!!! BUT MOSTLY THE PACKAGE MANAGER, DEPENDENCIES, AND TASKRUNNER.
I MISS THAT PLAIN OLD JS WITHOUT THE NODE PREFIX.