DEV Community

5 things that might surprise a JavaScript beginner/ OO Developer

Chris Noring on July 08, 2020

Follow me on Twitter, happy to take your suggestions on topics or improvements /Chris TLDR; this is not a critique against JavaScript, it's just a...

Read full post

Comment hidden by post author - thread only accessible via permalink

David • Jul 9 '20 • Edited

Well-written and well-explained. I haven't written JS in production in over two years, but JS is still a foot-gun when not doing TS. My favorite foot-gun when doing ES5 that is devoid of a set or map in its standard library is having to employ objects as dictionary-like data types:

// membership checking
var memberCount = {
   'b': 0,
   'a': 2,
   'd': 5
}

var member = 'b';
if (memberCount[member]) console.log(memberCount[member]);

The foot-gun here is that 0 is falsy and we won't get 0 printed. And objects have been used to maintain locations in arrays which are zero-indexed, so when going to check for membership about whether some character exists at index 0 results in, well, an unexpected result...

willparr • Jul 8 '20 • Edited

In the section about block scope, I found it interesting that you explained it like this:

Block statements, if, for, while etc, don't create a local scope.

Is there a reason that you decided to explain it that way? Compared to explaining that var doesn't adhere to local scope and let does? I just thought it might give more clarity that it's the variables rather than the actual blocks that are concerned with scope.

I really enjoyed how you explained the this issue that people run into when learning JS. It is extremely common and the solutions you gave are spot on! I remember banging my head against the wall trying to understand it!

Chris Noring • Jul 8 '20

hey Will.. I've seen many articles referring it as if, for, while, doesn't create a new scope but function does, here for example scotch.io/tutorials/understanding-.... I mean I totally see your way as well, especially with MDN saying this about let, let allows you to declare variables that are limited to the scope of a block statement. Yea I'll see if I can amend this in a good way, appreciate the comment :)

maowtm • Jul 10 '20 • Edited

You should probably also mention that

for (let i = 1; i <= 3; i ++) setTimeout(() => console.log(i), 100);

gets you 1 2 3, whereas

for (var i = 1; i <= 3; i ++) setTimeout(() => console.log(i), 100);

will output 4 4 4. IMO this is one of the major reason why scope of loop variable matters.

Mike Bybee • Jul 15 '20

The You Don't Know JS series of books (soon with a second edition called You Don't Know JS Yet) by Kyle Simpson should be required reading for any JS dev, for these and many more reasons.

Also (don't @ me, TypeScript devs), treat JS like a statically-typed, class-based language at your own peril. Do enforce (and document) types as needed. Do not waste too much time on static type checking that's just going to disappear in the transpiler. Do learn prototypal inheritance, and definitely do not try to force or hack JS into class inheritance.

Chris Noring • Jul 15 '20

I agree on Kyles books, they are great. I think it's important to be inclusive and let people use what they want.. but I also agree it's important to learn the foundations of the language. As for TypeScript itself: There are a lot of TypeScript devs that don't use classes. TypeScript is also well supported for React, Vue and Angular. I find personally it pays off in very large codebases... Sounds like you had some bad experiences using TypeScript.

Mike Bybee • Jul 15 '20 • Edited

I appreciate some of the things TS has pushed forward in ES, but classes are IMO a concession to devs who couldn't handle not having them, and never should have made it into the spec (sugar or otherwise).

My biggest beefs with TS are:

Trying to treat JS like it's C#
- Creating a false sense of security with static types and classes
- Obsessing over type checking, when it already exists (just dynamically and documented as easily as writing JSDoc params)

And possibly worse than the false sense of security:

Adding far more to the learning curve for junior devs, when I need them to focus on learning the actual language

Mike Bybee • Jul 15 '20 • Edited

Basically add in every point (Node.js and Deno creator) Ryan Dahl made recently in explaining why Deno moved away from TS internally.

I've been warning about all of these points regarding TS for years, even while using it and appreciating some of its features when doing so.

Ryan Ameri • Aug 10 '20

Deno moved away from TS... But moving to Rust. An even more strict statically typed language.

Mike Bybee • Aug 10 '20

The difference is that Rust is strictly typed by default, not a layer on top trying to hack the underlying language into behaving like a statically typed one.

David • Jul 30 '20 • Edited

Hard to admit? No, I'm not that type. If my example is wrong, I'd amend it. My example is a valid foot-gun. But I'm sure my example flew over your head as your console.log uses back-ticks and interpolation which isn't a feature in a JS version that you don't seem to be familiar with. Your suggestion would be a terrible idea. I even gave you credit for suggesting it, because although it works, the intent is unclear. But if you want to go with personal attacks, so be it. You're on your own. I'm sure you're quite the team member. "We can lead a horse to water, but we can't make it drink". Cheers, matey!

Robert Myers • Jul 9 '20

This is not really surprising if you come from a C/C++ background. You are then used to referencing counting, if some part of the code is no longer referencing something it is garbage collected.

You might want to replace C/C++ with C#. Neither C nor C++ have native reference counting or garbage collection.

Chris Noring • Jul 9 '20

fair.. I must have been thinking about Objective-c..

David • Jul 29 '20

Whoops — misread. I don’t see any reason anyone would write code like this. Moreover, your particular example doesn’t even quite express to the next programmer reading it why this is even needed. The exception being that you are debugging and wondering about what values are falsy. For the scenario that I illustrated, it’s better to write an if-expression checking the object key’s value for zero leaving absolutely no ambiguity

David • Aug 1 '20 • Edited

What sort of twisted world do you live in, Petar? You seem to want to construct a world in which you can make wrongful assumptions, craft lies, so that you can play hero. I've learned nothing but how much of an asshole you seem to be. I'm glad I don't have to maintain any code that you write. Perhaps only the most purist of JavaScripters that are all-knowing like Petar can team with him.

First you blamed the tool, then the spec was wrong, then my quick/dirty solution was wrong

The tool is worth blaming - show me another language where you have to do the "hack" you've done. And you can even only do your hack when you're aware of it in the first place. So my bad if you're a "JavaScript Ninja". I'd rest my sword first. I try not to pick fights I cannot win. Ever read the book, "JavaScript - The Good Parts"? Wonder why it is even titled that way? Probably not. The tool is always right in your world? Humble yourself, Petar. Don't bark at every dog that passes by alright? Could you cite where I blamed that the spec was wrong? Yeah, I didn't think so. You read specs? Nah -- didn't think so either. You write libraries and contribute to open-source? Nah, didn't think so either. You know why I say all this? There are people that write good code behind closed doors, but I highly doubt that you're one of them sharing such an absurd example that does more harm than good. Moreover, because of your lack of community contributions, I am pretty certain that you rarely take others' accounts into consideration. You write code as you please that only fits in your warped understanding of the world that no one else can maintain. That's fine -- people do that. But don't come at me spouting your bullshit and making shit up just so you can start a fight. Not cool

In your world, it's always something/somebody else's limitation/fault...never yours

Wow! Hell of a stretch, dude! You've obviously missed the entire premise -- that there is a pitfall here. You decided to butt in here with a "smartass" remark about how someone can print falsy values which is completely divorced from what I'm pointing out -- that most people will end up shipping code in an older version of JavaScript (ES5 which I clearly specified) and not realize that there's a bug or don't even know where to look if you're "dabbling" in JavaScript. Most JavaScripters know that 0 is falsy, but forget about it in certain contexts, so you're just being a complete smart-ass and an asshole for driving the conversation away from that. The only way that they can use your example is 1. that they are aware of this scenario or 2. they found the bug and employ this as the fix. No other language that I work with does this and that's a lot of them.

Again, I rest my case -- you must have many friends in your confrontational warped view of the world. Don't forget to pray at the ECMAScripten altar before you sleep tonight. Light some incense while you're at it... I heard you fart. Happy to entertain. I do it pro-bono. I get kicks out of it, too -- it's probably the most social interaction you've gotten in the past few months.

And lastly, I really don't mind if I'm wrong -- I encourage people to call me out when I'm wrong. In fact, I've made many many mistakes in my code before -- wrong assertions, wrong abstractions, each with their own learning lessons, but this was purely entertainment. I swallow my pride from time to time, but I try not to disseminate poor and uninformed advice and certainly don't insult people unless I'm insulted first such is the case here.

Tilak Madichetti • Jul 8 '20

Object.freeze(person) will alone not freeze the person object(even top level properties). It returns a new object whose top level properties are frozen.
Please verify before posting.

Chris Noring • Jul 8 '20 • Edited

I don't agree.. Try this code

const obj = {
  a: '1'
};

Object.freeze(obj)

obj.a = 2
console.log(obj.a);

You will see it outputs 1. I.e I'm unable to change the code... so I'm not sure what you are talking about to be honest? See MDN even developer.mozilla.org/en-US/docs/W...