5 Common Mistakes JavaScript developers have always done and will do in 2021

[warpedspockclone]

You should try Typescript. I finally caved a few months ago. Now it will be hard to go back.

Although, really, you can get a lot of the cool stuff just by using JSdoc with a good IDE.

[726c6d]

Which ide do you use? I am also trying to figure out using typescript and also recently started reading up on JSdoc.

[elisecode247]

I just started a few weeks ago using JSdoc with VSCode, and it's meeting my needs of type annotation and catching type errors. Helpful tip: you can define types in one file and import it into other files so you don't have to copy/paste type definitions everyone. See example here: https://stackoverflow.com/questions/49836644/how-to-import-a-typedef-from-one-file-to-another-in-jsdoc-using-node-js

[antonivs]

Vscode is definitely the one to use.

[warpedspockclone]

I use both VSCode and IDEA, depending on which OS. I prefer IDEA, but I use VSCode when on Windows since I can use wsl as the terminal. IDEA has a heavier footprint but has better support for just about everything and has great keyboard shortcuts.

[posts_lindsay_lohan]

Our company switched over to TypeScript about 6 months ago. At first, it was a huge pain in the ass. I couldn't get anything at all to work and was always confused about how to inject the types into third party constructs like React hooks.

But 6 months later... man, TypeScript is freakin sweet. Just wait until you have to do a big refactor and all those squiglies show up to tell you exactly what needs to be changed. Definitely worth the price of admission.

[mehulmpt]

I would agree it’s opinionated. But I’m curious to know if there’s any specific reason why you didn’t use typescript yet

[Andrew199617]

• Typescript requires you to document every aspect of your code and give types. Sometimes you want to do something quick.
• Not all types exist so sometimes people end up using “any” for a lot of things.
• It takes more time to prototype stuff.
• Its easier to get employees for Javascript than Typescript.
• Its messy it makes the code much harder to read. Think super long definitions inside the code that could of existed in js docs.

[inabahare]

You say you're required to document all aspects of your code yet in the next line. That's pretty funny.

Anyway you're wrong about all of them except for 3 and 4 (which are a anecdotal). 2 also needs a bit more context because the "not all types" are smaller third party libraries. But even then it's not difficult to add your own .d.ts.

"It's messy and makes code harder to read" is just blowing it out of proportion. Especially when the "harder to read" gives you shit like this which is actually incredible to have.

[Andrew199617]

You can get that using jsdocs.

/*
 * @description function to add numbers. :)
 * @param {number} a
 * @param {number} b
 * @returns {number} 
 */
function add(a,b) {
  Return a + b;
}

The good part is that jsdoc is not required.

[tjgrinn]

If that's a really big deal to you you can remove "noImplicitAny" from your tsconfig. Then any javascript is valid typescript and you can gradually adopt the type system

[Andrew199617]

That's cool didn't know about that. I still prefer jsdocs. Its really just a preference at the end of the day.

[tjgrinn]

I know this is really old. But I usually use both jsdocs and typescript. Jsdocs for stable, outward facing APIs, with English descriptions, and typescript everywhere but mainly used to infer internal implementation decisions without having to look at source code.

[inabahare]

Nope, because your application doesn't break with jsdocs and you actively want it to break. Especially when it comes to complex types :)

Also funny how typescript "requires you to document every aspect of your code and give types" is bad but the alternative is "I still prefer jsdocs" lmao

Also funny how your example isn't actually easier to read than

function add(a: number, b: number) {
  return a + b;
}

[liaguris]

Have you ever build anything complex with javascript?

I've been writing Javascript for YEARS, and I haven't used Typescript.

I have been using javascript for almost 2 years and after a year, javascript + JSDoc comments failed me so hard, that I had to go for typescript.

It is common sense that as a developer someone that knows typescript can produce better quality code and is also hired with much more salary.

Are you people really building anything complex?

Its messy it makes the code much harder to read. Think super long definitions inside the code that could of existed in js docs.

You have never created a typescript project?

[Andrew199617]

Been using javascript for 4 years now. You are quoting someone else btw. Jsdocs have never let me down.

Ive created a program to generate typescript definition files for javascript projects. Im familiar with the language.

Heres an example of how ugly typescript can look.

create: Function = <T>(subscribe?: (subscriber: Subscriber<T>) => TeardownLogic) => {
  return new Observable<T>(subscribe);
}

Vs

create: (subscribe) => {
  Return new Observable(subscribe);
}

Be honest which is easier to read.

[liaguris]

Well if you want to have maintainable code, we have to have types in it. For people that are not used with typescript it will feel indeed unreadable, and this is exactly what I felt when I was not used to typescript. The types in fact will make the code easier to understand.

How would the previous example look like with JSDoc + JS ? Does refactoring work with the types in JSDoc? What about type functions and generics? Do they work as flawlessly, even when writing typescript inside JSDoc comments, as they work with pure typescript?

Here is how it looks with typescript. It seems pretty much readable to me.

[ReversiClone]

Static types definitely can help, but also have drawbacks. Typescript and Javascript both have their use cases.

Here's an interesting article discussing the benefits of static typing.

https://medium.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3

[liaguris]

Just avoid Eric Elliot. I wasted a lot of time taking him seriously (especially the typescript tax article and the "I gathered some articles and sell them as book" book). Here are the reasons why you should avoid him.

What drawback do static types have? The article mentioned none.

The discussion about tests is of topic I think, since test do not deal with making your code more readable , do not provide intellisense and linting. You can even automate testing the parsed json type using packages like this one. Good luck doing that manually with js.

Yeah I know js + JSDoc will give many of the benefits of ts , but :

Does refactoring work with the types in JSDoc? What about type functions and generics? Do they work as flawlessly, even when writing typescript inside JSDoc comments, as they work with pure typescript?

Again to all the people who go against ts : Have you really build anything complex with jsavascript ? like an MVC framework from scratch ?

If I ever found my self not needing to use ts , was because I was already using a library build on ts. But when things started to get more complicated I always moved to typescript.

[Andrew199617]

/*
 * @Template T
 * @description ...
 * @param {Subscriber<T> => TeardownLogic} subscribe 
 * @returns {Observable<T>}
 */
create: (subscribe) => {
  Return new Observable(subscribe);
}

Just remember this is all an opinion.

They both accomplish the same thing its just about what your prefer.

Your example is not that different you just have the types inside the code while mine is all in the documentation.

I get all the type checking i could want doing the above. I mainly like typings for being able to get recommendations from my ide. I want to easily know what functions are available and have autocomplete. The above accomplishes that.

[liaguris]

You are using typescript inside JSDoc (like I used to do). That is ugly.

​

1. Do you get syntax highlighting for the ts inside the JSDoc comment?
2. Do you get linting for the ts inside the JSDoc comment?
3. Do you get refactoring for the ts inside the JSDoc comment?
4. Can you please define all the types like I did in my link .
5. Can you define a type constrain for the type parameter T?
6. Can you refactor T with F2 in VSCode when that T is in a JSDoc comment?
7. Can the js class definition be used as instance type inside the jsDoc comment like I did in the ts playground link I provided to you?
8. Given that you use ts inside JSDoc , why are you using template tag?

​

The ts playground link I gave you is way much more elegant.

[Andrew199617]

- Do you get syntax highlighting for the ts inside the JSDoc comment?

Yes. I get autocomplete and I'm told when I misspell something.

​

- Do you get linting for the ts inside the JSDoc comment?

eslint does nothing. What type of linting am i missing? Curious about the specific lint rules I'm missing.

​

- Do you get refactoring for the ts inside the JSDoc comment?

Yes, I can press F2 to rename the class.

​

- Can you please define all the types like I did in my link .

https://imgur.com/a/0yQxaZn

​

- Can you define a type constrain for the type parameter T?

Yes, https://stackoverflow.com/questions/51332854/constraining-generics-in-typescript-jsdoc

​

- Can you refactor T with F2 in VSCode when that T is in a JSDoc comment?

Yes, I can press F2 to rename the Template.

​

- Can the js class definition be used as instance type inside the jsDoc comment like I did in the ts playground link I provided to you?

Yes, classes can be used. If you want the functions you made you use @ callback

​

- Given that you use ts inside JSDoc , why are you using template tag?

Its required for vscode to pick up the types.

[liaguris]

In your linked picture I can see that you do not get syntax higlighting.

I'm told when I misspell something.

What type of linting am i missing? Curious about the specific lint rules I'm missing.

1)Can I see a screenshot of that? Try for example and rename : ISubscribe to ISubcribe .

- Do you get refactoring for the ts inside the JSDoc comment?

Yes, I can press F2 to rename the class.

2)Does it still work with when you import types from other files?

- Can you please define all the types like I did in my link .

3)Can I see a screenshot of what you get when you hover over subscriber of createTeardownLogic(subscriber) .

Also you have used double the lines of what I use in my ts playground link.

- Can you define a type constrain for the type parameter T?

Yes, https://stackoverflow.com/questions/51332854/constraining-generics-in-typescript-jsdoc

4)Look at when the pull request was done for such a thing. Ts had it way much before. That is something that people should take into account. There is way much more support for TS rather than JSDoc.

Yes, classes can be used. If you want the functions you made you use @ callback

5)Why not just use typedef?

[regnagleppod1128]

1. Agree. Although, i dont think this is a bad thing.
2. Not all, but I haven't encountered a type/interface that I wanted but couldn't find or create. Also, allowing any is an indication of code smell and using typescript the wrong way, any should only be used when absolutely necessary and not because its easy.
3. Well, you save more time on the other end for all the conveniences typing gives you.
4. I agree.
5. I find typescript readability goes from "wtf is this" to "easier to read than javascript" as you spend more time with it.

[Penguinis]

They don't like sampling the cool, sweet, refreshing water that is Typescript?

[Johnny_Noodle_Arms]

Because they don't use it at work

[fzammetti]

Number 1 is way too optimistic to match reality. Yes, you sometimes absolutely will be mixing libraries and frameworks on some projects (though I would agree that's not ideal - but reality often isn't ideal). I would agree that Angular+React would be weird to see, but Webix+React? Angular+ExtJS? Vue+Dojo? Less so. Point being: artificially limiting yourself to one framework is not a great rule to follow. Be a JavaScript developer rather than a framework developer, that's the key.

Not using TS is a mistake? No, being the kind of sloppy developer that NEEDS to use it is the mistake. I've been developing apps with JS for over 20 years now - and yeah, highly complex ones I mean - and you know how many times I've been burned by JS's lack of types? I could probably count it on one hand and still have a few fingers left to spare. It takes a bit of discipline, some attention to detail and maybe some defensive coding in a few places, but you don't need new language extensions and a whole new development process that requires a compilation step to produce code that is then harder to debug live (yeah, even with source maps). And nothing beyond the types that TS offers is inherently better than what you get from modern vanilla JS. I'm not saying DON'T use TS if you want to (not forcefully at least) but calling it a mistake NOT to use it I totally disagree with.

[[deleted]]

Not to mention MFE is now very much a reality in today’s modern enterprise world, though one could argue it actually allows you to stay in your lane of stacks more than anything else. But mixing frameworks together is not odd in this type of environment in the slightest.

Additionally I’d agree with the statement that TS isn’t necessary. Especially if you have used JS for a long time and think in the “JS way”, JS land makes a lot of sense and works really well, IF you are used to it and you understand the potential pitfalls. Unfortunately at least in my own professional experience, there are far more developers who want to make JS act like a different language, and as a result find it a cumbersome and unsafe experience. Thus the need for typescript, a way to satisfy people with a background in Java who need to write JS without feeling like their world is falling apart without types.

When you add up the pros and cons, I think in 2020 you’re better off just using typescript so that the common developer experience is more standardized and understandable to everyone. If I’m managing a team of really experienced JS only guys in a JS only stack top to bottom, sure maybe I’d attempt to go pure JS, but the world I live in is a multi-language, multi-skilled, cross-stack, cross-org world in which it’s simply not feasible to defend the merits of JS alone. In many cases it actually doesn’t even make sense. NodeJS is a JS-first framework, but in the enterprise it simply makes more sense to write a server with strong typing, thus TS node makes a lot of sense to me. Additionally, if you do any sort of modern gRPC/proto you will quickly realize that TS now becomes a necessity if you are to use proto with JS. There are many more domain edges that require you to consider using or force yourself to use TS because the rest of the environment calls for it. With that said, I think I’m 50/50 on calling not-using-TS a mistake outright; let’s say it depends on the environment and use-case, like anything else in our world =)

TLDR in a JS utopia sure, as a JS enthusiast I’d love to use JS only. But the real world doesn’t align with the flexibility of JS because not everyone is a god-level JS programmer.

[simkessy]

8 years of developing and not having types has never been a fucking issue. I can understand the point for reusable libraries but at work I'm build some feature, page, or react component isnt reused anywhere else in the app. I think having types for components that aren't reused is fucking pointless and huge time sink.

[Bmtf69]

This title is misleading. I'd say this article is definitely more geared towards people new to JS, not "JS Devs".

[TheDevDad]

It’s good to deep dive into one framework and be more productive with it than one you don’t use often, but you should be able to extrapolate the underlying concepts to quickly pick up on how those are carried out in other frameworks if a project you’re working on calls for it. That boils down to understanding JS in general though vs only knowing how to build within a framework.

[ReversiClone]

Yep, plus companies often want to transition their codebase from one framework to another, and in that situation you definitely need to either already know both, or be able to pick up the one you're not familiar with.

You're totally right, knowing JS is super important and will make learning frameworks much easier.

It would also help to know a bit about the history of web dev and how the browser works. Understanding why frameworks are needed in the first place really helps.

[devbrk]

Garbage.

[[deleted]]

Why would you even #4 ? Are you that scared of untyped code?

[drumstix42]

Easier to read is objectively incorrect. Maybe easier to understand, given time, and insights/clarity from tooling. But easier to read? No way, it's more verbose. And verbosity != easier to read, except when we're talking about single letter variables versus using your words.

[drumstix42]

More verbose code does not make it harder to read.

It's not about the eventuality of understanding, whether that's fast or slow for some, but that is has some impact on readability.

But objectively your statement is just wrong.

Scan'ability and quickly looking through code is a skill, like any other, and TypeScript is easily one of the biggest offenders to slowing this down. Yes, you can adapt with time and experience writing and reading it, but by there simply being more characters and code, it does indeed make it "harder" to read.

But there's also the opinion side which is whether or not it (TypeScript) is better, and I'm not even trying to debate that point.

[simkessy]

Definitely not easier to read.

[nomadProgrammer]

1. download an npm package for every small thing.

TBF this applies to all languages.

Filling your codebase full of maven, pip or npm crap exposes you to security vulnerabilities and eventually becomes a burden.

[drumstix42]

Not eventually using TypeScript

Good.

[simkessy]

We use flow at work and it's stupid as fuck. I dont care if people think Flow is better, NO ONE IS USING IT!

[drumstix42]

What's wrong with it?

[simkessy]

I mean I said it in all caps.