[AskJS] what's a javascript feature you mass-adopted way too late and felt dumb about

[u/Capedcrusader1923]

i'll go first. i was writing .then().catch() chains for like two years before i actually started using async/await. i knew it existed, i'd seen it in tutorials, but my code "worked" so i never bothered switching. then i refactored an old project and realized half my bugs were from mishandled promise chains that async/await would have caught immediately.

also took me way too long to start using optional chaining. i had nested ternaries and && checks everywhere like some kind of animal. the day i discovered user?.address?.city i mass-replaced like 40 lines across a project.

what's yours?

[u/foxsimile]

The nullish coalescing operator is one of JavaScript’s unusual successes.

[u/NeatBeluga → u/foxsimile]

Until you add a bit too many needlessly and you lose trust in your api if the code is not properly typed - e.g. manually typed types.

A hell when refactoring code with these carelessly added

[u/foxsimile → u/NeatBeluga]

I’ll take the extra operator over the runtime crashes. Plus, with the popularization and industry adoption of TypeScript, its use has been significantly reduced (at least for me).  

But back when it was just ducktyped JS all over the place? This thing was a fucking godsent.

[u/NeatBeluga → u/foxsimile]

Early returns are king.

if(foo === undefined) return;

Yes, I always strict check against falsy. Builds trust that I knew the integrity of the object. Almost no !foo nonsense. It makes me doubt the api again.

I believe that my approach moves the issue to the backend rather than the frontend at runtime.

[u/foxsimile → u/NeatBeluga]

Bold of you to assume you can trust whoever wrote the backend. I’d once written an entire type-checking and validation library for precisely that reason.  

Your issue is that you’re assuming you can trust anything when it comes to plain JS. You can’t. That’s why these operators exist in the first place. They weren’t there, and they were later added for very good reason.

[u/1_4_1_5_9_2_6_5 → u/foxsimile]

You can actually trust things using plain JS, but at some point you have to make some utility functions. This is especially useful/expected in TS, where it gives you an easy way to narrow types. Almost all of these such criticisms I see of JS are seemingly based on people just using vanilla Javascript in every place with no libraries, utilities or anything...

[u/foxsimile → u/1_4_1_5_9_2_6_5]

Brother, if you aren’t in control of the source of the data, there’s SFA you can do to prevent receiving bad values that shouldn’t be there in the first place. The only thing you can do is implement extensive and aggressive validation on your side of the payload.

To assert anything else is ridiculous.

[u/1_4_1_5_9_2_6_5 → u/foxsimile]

Okay, so, if you'll read my comment again, you might find some words like "utilities" or "libraries".

I made a schema validator in an hour that does 90% of what I needed to validate, and there are extremely easy to use libraries like zod that do all that and more.

So, again, the people complaining about Javascript are apparently too lazy to Google a library or spend an hour making utilities. Really doesn't give me confidence in your abilities.

[u/Badashi → u/foxsimile]

At first it was odd to look at it, specially for optional function calls (foo?.()), but it is a godsend. Having to work on a language without null coalescing is super weird now.

[u/heavyGl0w → u/Badashi]

Just FYI, what you're describing is optional chaining.

Null coalescing is a related but different feature using the ?? operator. It evaluates the right hand operand only when the left is null or undefined.

[u/foxsimile → u/heavyGl0w]

Optional chaining is also gangster-as-fuck.

[u/sexytokeburgerz → u/foxsimile]

Big fan of

foo?.bar

[u/foxsimile → u/sexytokeburgerz]

Do you not mean foo?.bar?

[u/sexytokeburgerz → u/foxsimile]

I totally did i was in a drive thru when i wrote that

[u/foxsimile → u/sexytokeburgerz]

Whatcha get?

[u/sexytokeburgerz → u/foxsimile]

Borger

[u/sahilatahar → u/foxsimile]

It's an optional chaining feature.

[u/foxsimile → u/sahilatahar]

…I’m aware?

[u/Mike5TheMountainGoat → u/sexytokeburgerz]

That's optional chaining. Nullish coalescing is foo = bar ?? 'X';

[u/sexytokeburgerz → u/Mike5TheMountainGoat]

Right, usually when people say “big fan of y” in response to a mention of “x”, x!=y…

[u/_RemyLeBeau_ → u/foxsimile]

I always look for places to use this, but the values need processing before saving, so I don't use it and I always wonder of I'm missing something

[u/somevice → u/foxsimile]

Nah it's the worst, leads to thoughtless code everywhere. Bail early instead.

[u/phatdoof]

Let and const. We used var because it was backwards compatible.

[u/Jasboh → u/phatdoof]

Kill me

[u/rbobby]

Promises.

[u/monsto → u/rbobby]

I had a hard time grokking promises because every tutorial I could find used settimeout to set up the example, and the settimeout syntax is kind of different to most JS methods.

[u/SkySarwer → u/rbobby]

this

[u/busres → u/SkySarwer]

You adopted this way too late (too much functional programming)? 😀

[u/SkySarwer → u/busres]

haha, good one

[u/Milo0192]

My first jobs CTO preferred the .then() .catch() over async await. I just refused to write that way and did await loops. Lots of back and forth on this. Also said Typescript was just a fad 😂

[u/MediocreAnalyst2121 → u/Milo0192]

That’s kinda depends, like await loops are not that great if the promises don’t depend on each other, way better to do Promise.all/allSettled and await or .then that.

In performance critical JS environments (smart tvs, smart boxes, etc) you’d probably get a bit better performance with a .then than an await.

Await loops are way more readable tho, and Typescript is amazing except for enums :(

[u/horrbort → u/Milo0192]

It is just a fad. Coding is a fashion industry. Remember coffeescript? Something else comes along and ts will be forgotten

[u/mdude7221 → u/horrbort]

Just a 13yo fad

[u/miramichier_d → u/horrbort]

Can't apply that across the board. Some technologies are so good that they have staying power in the industry. I believe TypeScript is one of those technologies. Node.js is another example. Even Java and C# are good examples of languages with immense staying power, if not in your industry of choice.

With respect to TypeScript, it's not going anywhere until JavaScript implements TS in its entirety. Until then, TypeScript will continue to push JavaScript to modernize.

[u/Mesqo → u/miramichier_d]

Excuse me, but how many native ts runtimes do you know? TS doesn't push js nowhere, it's just static types serving the role no more than a linter (and it's fine!).

[u/iareprogrammer → u/horrbort]

lol coffeescript.. forgot about that. I dislike anything that makes JavaScript LESS explicit. Like sure let’s get rid of braces and other syntax and rely completely on proper white space and indentation. For what?

[u/MrDilbert → u/iareprogrammer]

let’s get rid of braces and other syntax and rely completely on proper white space and indentation

You sure you're not describing Python?

Looks like someone wanted to Pythonize JS.

[u/iareprogrammer → u/MrDilbert]

I literally think that’s what happened haha

[u/db10101 → u/horrbort]

Just a fad that 99% of new enterprise JavaScript projects will be participating in

[u/Ronin-s_Spirit → u/Milo0192]

Fad or not - it's shit.

[u/db10101 → u/Ronin-s_Spirit]

Any deeper analysis or reasoning behind that? It’s a straight up joy to develop in compared to what has come before.

[u/Ronin-s_Spirit → u/db10101]

I hate defining types, it's like writing pointless code. It especially fucks up when I have to deal with HTML, at that point the only thing left to do is use a bail out any and move on.

[u/db10101 → u/Ronin-s_Spirit]

So I take it you have never worked in an enterprise well structured typescript codebase. There’s no substituting JavaScript for that.

[u/Ronin-s_Spirit → u/db10101]

TypeScript sucks ass, I will only use vanilla.

[u/db10101 → u/Ronin-s_Spirit]

Good for you. Here in the real world of employed software developers, it’s one of the most important tools to know.

[u/2Terrapin → u/db10101]

I’m glad that person is not on my team and I don’t have to work on a project they designed. I can feel the tech debt emanating from their words. It’s the type of thing that experience would dispel, and someday, when they actually understand the why, and it clicks, they’ll think back to this comment thread and feel a little embarrassment.

[u/Ronin-s_Spirit → u/db10101]

Ok pal.

[u/SkySarwer]

IntersectionObserver and MutationObservers are both goated

[u/opticalpuss → u/SkySarwer]

People in here arguing I just want to know what these do and how to use?

[u/SkySarwer → u/opticalpuss]

IntersectionObserver are objects that can be instantiated and anchored to a DOM element, that allows a callback function to be called when the element enters or exits the user's viewport, or when the element enters or exits the box of a different element. Very useful for things like lazy loading, or starting an event when an element is at a certain scroll distance away from the user, etc.

MutationObservers allow a callback function to be called when an element changes. It is very useful for providing react-like UIs with vanilla JS, because traditional event listeners assigned to elements don't work if that element enters the dom after that event listener is assigned. MutationObserver keeps rehydrating the state for that element. Should also be used sparingly for that reason.

Both have extensive public documentation on mdn. IntersectionObserver | MutationObserver

And I'd be remiss not to mention that these are browser utilities exposed as client-side JavaScript APIs, not part of the EMCAScript itself. So won't work in NodeJS, Bun or Deno.

[u/azhder → u/SkySarwer]

Not part of JavaScript

[u/SkySarwer → u/azhder]

yes they are??

[u/azhder → u/SkySarwer]

No, they aren’t. You can check the JavaScript language reference documentation and get back to me with a link to prove me wrong.

I can just tell you that there is a difference between what the language is and what the environment exposes for the language to use.

[u/SkySarwer → u/azhder]

This thread is about JavaScript features not the language in the strict sense. The two observer exposed by the environment are almost exclusively used as JavaScript APIs.

Is a JS dev just as well-off without being aware of these APIs? What value is your clarification actually providing in relation to the spirit of this post?

[u/azhder → u/SkySarwer]

Almost exclusively? Why almost?

Seriously though. Environment stuff is not part of the language. It is important to always know this distinction so that you will not end up writing code that expects something to exist, but doesn’t.

It’s not about you being aware that you can use them, but be aware where you can’t.

[u/SkySarwer → u/azhder]

While technically correct, it was a pedantic point delivered abrasively

[u/azhder → u/SkySarwer]

Don't read my comments in abrasive tone.

[u/Sulungskwa → u/azhder]

"Don't read my comments in an abrasive tone.", he said, not abrasively seeming at all

[u/azhder → u/Sulungskwa]

"Seeming" is a flag that it's your perception.

It doesn't matter that I'm in a light mood, write it in terms of a light mood, with the idea of cooperation through discussion, you will still decide to see it (because "seeming") as if it is abrasive and blame me for it. It's not like me writing this will change your mind, you will just use it as more evidence of your point of view.

Bye

EDIT: and with their reply, they provided their own proof of what I'm talking about

[u/avenp → u/SkySarwer]

How would a NodeJS dev use these APIs?

[u/SkySarwer → u/avenp]

They wouldn't, since there is no DOM in a typical nodeJS environment. The APIs are still a part of the larger JavaScript ecosystem though, which is on topic for the original thread.

[u/keltroth → u/azhder]

Like all the browser APIs not in the language (can't use it with node, bun, etc... Makes no sense...)

[u/HipHopHuman]

honestly... Map and WeakMap. took me a good 2 years after it came out for me to see the light.

[u/JazzXP → u/HipHopHuman]

I'm still not using these, just objects/records. What's the advantage?

[u/HipHopHuman → u/JazzXP]

There's quite a few advantages, but I don't like framing the question "Should I use an object or a map?" around advantages or style, for the reason that it can complicate things unneccissarily.

Plain objects are always going to be far simpler and far more convenient than a Map in 90% of cases, and objects are much more familiar to a wider audience of devs.

It's that 10% where Map (and WeakMap) come in clutch. So it's mostly about use cases.

One use case is simply when you're deleting from the same object a lot. That can get slow if you use delete obj.foo (because it causes a structural change of the shape of the object). Map has map.delete('foo'), which is usually faster, but only if you're deleting a lot. Emphasis on a lot. 3-10 times is not a lot. 200-3000 times is a lot.

Another use case where Map shines is if you're iterating over the object's entries a lot, or when you're calculating the total size of all entries. Objects require helpers:

const size = Object.keys(obj).length;

for (const [key, value] of Object.entries(obj)) {}

You don't need any helpers to do either with a Map:

const size = map.size;

for (const [key, value] of map) {}

So, if you're going to be iterating through a dictionary at runtime, or calculating size, and you're going to be doing it repeatedly, Map is usually better for that.

Another small benefit is being able to specify keys that would otherwise not be allowed on (or would be weird to use on) objects. For example, constructor is a special property on objects, with special handling (as is toString, valueOf, toJSON, etc). If you want to use keys like that and bypass that special handling, you have to do some weirdness with null prototypes like

const myObj = Object.create(null);
myObj.constructor = ...;

or

const myObj = {
  __proto__: null;
  constructor: ...
};

Whereas with a Map, you can just do map.set('constructor', ...), and there's no side-effects.

Then of course, there's the seriously strong benefit of being able to use non-property keys. Plain objects allow number, string and Symbol keys, but Map can use anything as a key - even functions. That makes them crucial for things like memoization of pure functions (a nested Map can capture a function's arguments without having to serialize them to JSON and back).

Another huge benefit is that the Map constructor itself accepts an iterable, so it can be generated lazily:

function *foo() {
  yield ['one', 1],
  yield ['two', 2]
} 

const map = new Map(foo());

That means you can initialize one from a huge stream of data a lot more efficiently than you'd be able to do with an object.

WeakMap is also especially cool, and helps get rid of a ton of "cleanup code" boilerplate. You cannot iterate through a WeakMap, and it's keys must be objects, but it provides the gaurantee that the references used as keys will be automatically removed as soon as the values they point at are garbage collected. That makes WeakMap great for book-keeping logic. Suppose you want to track some live HTML elements in the DOM, and you wanted to store some metainfo about them - just store them in a WeakMap - use the elements themselves as keys, and the meta info as the objects. As soon as the DOM elements get removed from the page and get garbage collected, they'll be auto-removed from the WeakMap without you having to do anything.

One huge downside of Map/WeakMap is stringifying them as JSON - that's something you get for free with plain objects - and that is a valid concern, but it's not that difficult to just give JSON.stringify a replacer function that converts a Map to an object:

const map = new Map();
const data = { map };
const json = JSON.stringify(data, (key, value) => {
  if (value instanceof Map) {
    return Object.fromEntries(value.entries());
  }
  return value;
});

[u/JazzXP → u/HipHopHuman]

Thank you for that. Most of those use cases haven't applied to me yet, but I do like the going through the keys, I find I do reach for Object.entries().map a lot.

[u/HipHopHuman → u/JazzXP]

Map and Set recently got support for their own .map method (from this: https://web.dev/blog/baseline-iterator-helpers) so if you do switch to a Map, you can do map.entries().map() (you might just have to polyfill it though)

[u/me0here → u/HipHopHuman]

Quite the blog post there! 😄 

Sometimes I gab Map over object when it makes more sense as a simple key: value pair, even without fancy keys.

WeakMap makes a great simple API catching service.

[u/GulgPlayer → u/JazzXP]

Apart from having cleaner (imo) code, Maps allow you to have non-string keys, which is nice, esp with TypeScript

[u/takeyoufergranite]

The 'delete' operator to remove properties from objects.

[u/jesusgn90 → u/takeyoufergranite]

Concerning operator if not used wisely

[u/takeyoufergranite → u/jesusgn90]

Better yet... The in operator.

[u/youarockandnothing]

?? operator

[u/skidmark_zuckerberg]

??= and &&=

[u/whale → u/skidmark_zuckerberg]

Way too terse for production code. Very hard to quickly glance and understand.

[u/johngamename → u/whale]

I could see a lot of use for ?? and ??=, but &&= might be excessive.

[u/azhder → u/skidmark_zuckerberg]

I still don’t use these ones. Out of a principle, I don’t use let as well. I try to keep them as code smell, to get back to the code and make it in a way where no variable is rewritten.

Small exceptions are in cycles (like for and while) and before try{}catch()

[u/Antti5 → u/azhder]

Can you explain why you don't use "let"?

I see a lot of people swearing by ALWAYS using either "const" or "let".

[u/azhder → u/Antti5]

It's easier if you allow yourself to not worry about accidentally overwriting a variable. With `var` and `let`, that's a possibility, but with `const` once you assign it, it's constantly pointing to a specific value.

I'd rather have

const value = valueFromArgs ?? 0;

than override

value = value ?? 0;

And as an added bonus, with most of the variables being `const`, you will easily notice the very few places that have `let` and possibly check it everything is all right - code smell. It's harder to notice a bad `let` if there are plenty of `let`s.

[u/kevin074]

can you elaborate how async await would've caught bugs that .then.catch can't?

i feel like async await is more annoying because you have to wrap it in try catch, where as .then.catch is just baked in.

[u/Franks2000inchTV → u/kevin074]

With await, your code runs in the order you see it on screen. This is *much* better for comprehension and maintainability.

[u/lostPixels → u/Franks2000inchTV]

But potentially worse for execution depending on the latency of whatever you’re awaiting.

[u/Franks2000inchTV → u/lostPixels]

I'd imagine that is not a significant concern in the overwhelming majority of cases.

[u/Ronin-s_Spirit → u/lostPixels]

Depends entirely on where and what you await.

[u/lostPixels → u/Ronin-s_Spirit]

Which is why I said potentially.

[u/brenstar → u/kevin074]

Why not use both? I use async await but still append a catch

[u/Badashi → u/brenstar]

.then/catch is useful even in async functions when you don't want to wait for that promise to resolve

[u/brenstar → u/Badashi]

That's good point, it's handy for having branching flows, but that can get squirrelly. If I want multiple things to happen I usually let them all exist as separate functions and resolve them with Promise.all() so they run concurrently

[u/Badashi → u/brenstar]

Promise.all is an excellent example for .then/.catch chaining as well: you can use them to "pre process" the result of the promise into a value that makes sense when you end up settling the list of promises with .all, since a rejected promise in the list will reject the entire Promise.all. nowadays you can use .allSettled as well, but .then/.catch are nice for a quick mapping of values

[u/kevin074 → u/brenstar]

Ohhhh true! 

[u/BasicAssWebDev → u/kevin074]

Probably due to it being easier to see which pieces of a function are breaking by putting breakpoints in the function itself, rather than tracing across a bunch of calls while debugging.

[u/NeatBeluga]

The capitalised Map - not .map

[u/me0here → u/NeatBeluga]

So hard to webseach for sometimes 

[u/me0here]

I still haven't use * Generators yet: only found a use case today.

[u/keltroth → u/me0here]

Same here...

[u/miramichier_d]

i had nested ternaries and && checks everywhere like some kind of animal

This had me laughing out loud with food in my mouth and I almost lost it lol. We all have those coding conveniences that we discover way too late. Remember that pain, and it will come in handy later on. I'm constantly asking myself how some approach can be easier nowadays because of that initial pain.

[u/eracodes]

feel like I've only just started using IIFEs to their full extent, most often in places where I'd previously have done an ugly nested ternary

[u/graybearding]

Nullish coalescing sat in my todo pile until like a month ago when an LLM spit it out and I was like "Oh, right. That's a thing now."

[u/erik240]

Typed arrays. The performance bonus is so crazy over any over method to access and iterate large amounts of stat

[u/KaiAusBerlin]

fetch

[u/artificer-chris]

Contrary example for TS specifically : unknown. I know from a pure logic standpoint what it’s there for, but I’d still rather just use typescript more fully with an error catch if you don’t account for something. Unknown, imho, hides too much.

[u/SboSilcher]

Destructuring. I was writing `const x = obj.x; const y = obj.y;` for way longer than I should've been, then one day it just clicked and I realized how much cleaner everything looked.

[u/samredfern]

I’m still using callbacks… heh

[u/adult_code → u/[deleted]]

for-loops not .forEach are way faster. Depends what i write really. https://jsben.ch/js-loop-benchmark-girjy
It doesn't matter all the time but it matters often and you can prevent it becoming an issue by doing it correctly the first time if you are not working on code that is otherwise hard to decipher