What to know about JavaScript

Hey fellow devs!

Last year I mostly wrote about JavaScript. I started with React, went over to Webpack and then did basic JS explanations after I noticed that they got the most attention.

I would like to continue doing so this year while interleaving the JS posts with stuff I'm interested myself right now (AWS, Reason. I still love JS tho!)

I had a few questions in my head when thinking about this.

If you are a JS-beginner: What do you find elusive in JS? What could be explained better?

If you are a JS-pro: What do you think are the core concepts? What are the things you just need to understand to work effectively with JS?

I often have the feeling I'm in too deep to find out what people need to know. :)

Comments

[Ryan Palo]

I'm never sure about what the "right" way is to setup for a small project. I'd like to use ES6 and modules, etc. but I've learned JS from so many different sources that it's hard to figure out what's out of date knowledge and what's current. I know that you can use a big build pipeline for larger projects, but I'd like to know what's recommended for a smaller project. It would be really nice to make a project, and know how to get some of those nice modern JS benefits without having a huge, scary node_modules folder.

[K]

So, you're more concerned about the ecosystem instead of programming JS?

[Ryan Palo]

Yeah, the language features and syntax I get (although I love reading posts about them, don't get me wrong). Coming from other ecosystems (Python, Ruby...), getting a project set up and going to the point where I can actually start using the syntax theory that I know is what trips me up. I generally get started and confused and end up reverting to the ES5 that I know will work.

[Meghan (she/her)]

On the beginner side, I would say don't let the elusiveness get you down. One of the things about JS even now is that I feel that no matter how much you learn about JS, there's always some API, or function, or piece of syntax, that you can learn about. AND, it could be something that is brand new, or some odd ball that all the browsers have been supporting since 1995.

On the pro side, I would say understanding that everything is an Object, as well as how just because JS doesn't have to be type-safe, doesn't mean you shouldn't be. On top of that, there's a lot of quirks in JS engines and learning about those can help you write not only cleaner code but faster code too.

Happy coding, and can't wait to read your new articles :)

[Jochem Stoel]

When writing for both beginners and professionals, I recommend talking about the different dialects in JavaScript, why they exist and when to use them. Many people with reasonable JavaScript experience on first glance have no idea what each other's code means, find it to be very unusual or start arguing against it.

I will write a post about it and get back to you here.

[K]

Now I'm intrigued, haha :D

[Jochem Stoel]

Hey K. I am kind of busy lately so I haven't had the time or energy to write a post about it but I feel it is polite to at least say something.

By dialects I mean the different notations/styles used by different people over time.

We used to have a readystate (for instance with XMLHttpRequests) and an onreadystatechange. We hang a function on the statechange event and see what the readystate is. Some developers don't use a statechange anymorebut implement onChange, onCreate, onError etc.
Since a year or two (three?) it has become common to implement the on() method.

Object.addEventListener('change', function(event) {
    // 
})

became

Object.on('change', event => {
    //
})

And of course there's Promises and now async/await. All of them ultimately doing the same thing but with different notation.

To a developer with a background in C++ or C# things the old notation comes very natural. (addEventListener) when people like this see the fetch API in modern browsers at first glance they are like "say what??". This is what I meant with developers getting confused by each other's code even though they both know the language quite well.

Another dialect example I can think of is what jQuery does with the function behavior depending on the amount of arguments given. (a single attr method for both element.getAttribute and element.setAttribute)

$('#element').attr('class', 'pretty') // set class = pretty
$('#element').attr('class') // return class value
$('#element').attr() // return all attributes (cheerio)

I hope this explains what I was getting at and gives you some useful info on things to talk about in one of your future articles. If you are writing one or have written one, by all means hit me up for any type of input/feedback. :)

[K]

I think I understand what you mean.

I came from PHP to JavaScript and besides some minor things, the whole syntax/gramma seemed reasonable to me.

But the semantics were completely different. The event-loop, the prototype chain etc. were things that didn't have equivalents in PHP.

Thanks for taking the time :)

[K]

True, but on the other hand this doesn't seem to be JS specific problem.