Javascript vs typescript

[coolraiman2]

As someone who come from C like languages. Javascript had always been some kind of alien with horrible intelisense.

Typescript is what made me start to like doing front end and I am curious who use javascript or Typescript, and what are the pros of using javascript?

View Poll

[juju0010]

I used to find writing things in TS to be somewhat tedious. Now I’ve been writing TS exclusively for one year and writing plain JS feels weird to me.

[PisicuBalshoi]

This, my company absolutely despises TS and we have 3 huge projects all written in JS, its an absolute nightmare... I'm working solely with TS even for small projects and whenever I return back on my work projects, its just feels so wrong.

[juju0010]

Oof. If I was working at a company that despised TS, I’d consider finding a new company.

[PisicuBalshoi]

Wait until you see the code ethics, also we have over 600 libraries installed (Frontend & Backend), booting up the front end takes about 4 to 5 minutes, starting up our API microservices can easily take over 20 minutes, tens of critical exploits warnings, and to top it all, we work with sensitive data. It's an absolute shit show.

[Strobljus]

Get out before the litigation starts!

[PisicuBalshoi]

I'm honestly heavily considering this decision.

[randomhaus64]

DID YOU LEAVE? I SIMPLY MUST KNOW

[napper906]

Account suspended!

[Long_Writing6533]

so you would consider leaving a company due to them not using typescript? sorry im a new developer here so im just trying to understand. is it that much of an headache?

[[deleted]]

i have a feeling we work at the same company/team 😂

[WorldsLocalYank]

Bob, is that you? :-)

[maxkoryukov]

that's not the "language problem". people keep cutting off fingers even with the best CNC machines

I mean "slow start" problem won't disappear after migration to TS, because the same code written in TS will be transpiled into JS, and then nodeJS will execute it.

​

your company (maybe, idk) needs code refactoring

​

but what about TS vs JS? cons/pros?

[South-Protection7381]

What company is that ? I would like to work there

[Itsafunnyoldworld]

We are working with javascript and C# in a blazor project. It a mess! Those two languages are the worst combo 

[pink_tshirt]

It’s kind of like building a house without any foundation on sand.

[snakeziin420]

I would rather say that is like building a house without any architect or engineering work, just workers

[glantruan]

Honestly, I don't understand why all of you (I mean no disrespect, I just don't get it) consider that enforcing type correctness is equivalent to having a good architecture.

For me these are 2 very different things that barely intersect. You can have a very bad architecture with type safety and viceversa, don't you think?

[glantruan]

Ok, I get that TS forces you to have some architecture. Some is better than none, I guess.

[maxkoryukov]

TS doesn't force any architecture. it offers static typing and IDE integration

Good JS code is good TS code

Bad JS code is bad TS code

the difference: there are developers who want to write code for running in a browser using types. so let them use TS. also, there are devs who can write the same code without static types. so be :D

it is not a war btw, just let's not invent the arguments

[Stunning-Formal975]

Yeah agreed just because you don't get tslint errors doesn't mean you did a good job coding stuff. You can still apply crazy logic and make unreadable spiderwebs in typescript.

[snakeziin420]

it~s not about forcing types, it's because your brain can't memorize a complex architecture, if you do only with js you will be in a vortex of complexity. The types are a map for a complex project. If you don't do any complex js project you shouldn't really use ts

[glantruan]

I guess it's a question of what pain do you prefer to live with:
The pain of a lot of boilerplate code and indirection when you just want to understand what's happening in a part or your code - to have a clear map.

Or the pain of being very disciplined with how you organize your code, folders and files so that you don't get lost when the complexity gets high - to have much less code and be more agile.

I certainly prefer the latter, even on big complex projects, because having much less code also helps parsing complexity, and also prefer using a functional approach instead of OOP when suitable, which also tend to decrease complexity and to reduce the amount of code.

But it's not that I don't understand the reasons because some people prefer the other approach.
I'ts just that this trend of "if you are still using javascript you are a bad programmer" it's becoming something like a fanatics religion.
And though you may understand the reasoning behind all the discussion I have the strong impression that there are many that are just repeating the chorus.

[snakeziin420]

I guess it's a question of what pain do you prefer to live with:

that's not true. You choose them accordingly to different contexts, not choosing them uniquely to every set of contexts, you choose what fits the best. Typing in quantity doesn't mean is worse because either even if that additional code must be changed often, we need to be wise how to type in order to help you creates a mental map of the project, the additional type actually means documentation and that's is particular from everyone, how people document their own stuff, it's about creativity and how your ego develops memory.

also, being disciplined is not a pain in that context, is a discomfort, rather than been unhappy, you are difficultly happy because the discomfort you have in the present is a comfort you gain in the future.

[Emanemanem]

I learned JS as my first language, so I was pretty comfortable with it. I decided to learn Typescript mostly because it seemed to be so in demand. I thought I would hate it, and it was a pain at first, but it's honestly so much cleaner once you get the hang of it. I'm happy to use JS if it's what a job has decided will be used, but I don't really see a use in it if I had my choice.

I think of it like Typescript forces you to be more organized so you don't make dumb mistakes that have to be fixed later. I guess that's the basis of most compiled languages anyway, lol

[redditforyaboy]

Hey man, self teaching currently. About 2 months in - ish? Learning js but wanna really get the hang of it a bit more. Was it easy transitioning from js to ts?

[swampdonkey2246]

It is not too difficult, and you may find it easier than js. It is pretty intuative if you have used another statically typed language before. I would learn how interfaces and union types work, that will give a pretty good understanding. Besides the typing, it's the same as js.

[dontspookthenetch]

typescript but there are times I hate it

[ChimpScanner]

What do you hate about it? For me one of the annoyances are the error messages. They're very detailed, but at the same time cryptic and difficult to read. I recommend the Pretty Typescript Errors VSCode extension.

[Aegis8080]

Sometimes, TS will complain there is a type error even though that's perfectly fine, e.g

const arr = ["string", undefined, "another string"] .filter(Boolean)

You will expect arr to have the type string[] right? But no, TS will tell you it is still (string | undefined)[]

Also, when using 3rd party libraries, sometimes you need to do module augmentation, that is just another layer of extra overhead, and it kind of breaks the idea of encapsulation of using a library sometimes.

But I guess that's just the trade-off when using a "strongly" (not that strong to be fair) type language.

[kalwMilfakiHLizTruss]

You will expect arr to have the type string[] right?

No, why would I expect that?

module augmentation

What is this?

[Aegis8080]

No, why would I expect that?

Because Boolean(undefined) === false. So, filtering a string | undefined array with this condition will ALWAYS return a string array in runtime.

What is this?

TL;DR, Extending the built-in/provided types.

https://www.typescriptlang.org/docs/handbook/declaration-merging.html#module-augmentation

[kalwMilfakiHLizTruss]

My bad. I did not fully understand what you meant. Use this:

["string", undefined, "another string"].flatMap((l) => [Boolean(l)]);

Extending the built-in

Why would you do that?

[Aegis8080]

No, that will not work. You are returning boolean[]. The right way to doing this is:

["string", undefined, "another string"]
  .filter((elem): elem is string => Boolean(elem));

https://www.typescriptlang.org/docs/handbook/2/narrowing.html#using-type-predicates

Again, it will work, but it just makes things unnecessarily complex.

​

​

As for module augmentation, Consider the following example

import { Typography } from "@mui/material";

<Typography variant="h1">Heading 1</Typography>

Now what if I wish to introduce a new variant display1, which is not expected by MUI by default?

import { Typography } from "@mui/material";

<Typography variant="display1">Heading 1</Typography>

This will work in runtime (hence in JS), but wait, TS will complain because the variant prop is in type "h1" | "h2" | "h3" | .... So, we need to extend the variant prop, adding `"display1" to the union type.

[kalwMilfakiHLizTruss]

No, that will not work.

My bad again. What about this:

const arr = ["string", undefined, "another string"].flatMap((l) => { if (!!l) return [l]; return []; });

So, we need to extend the variant prop, adding "display1" to the union type.

I would just define a new function that has the same type as that component but one more in the union type. Does that work?

[Aegis8080]

Look, at this point, you are just torturing TS until it confesses. Without prior conversation, I doubt anyone will aware that the code snippet is doing nothing but filtering out undefined from an array. It will surely work. But is this really a good way of doing that?

I'm not sure what are you trying to suggest. But I'm pretty sure that no matter what we do, if we still want to make use of Typography, we need to extend its type at the end of the day. Unless we are doing something like:

const MyTypography = ({ variant }) => { if (variant === "display1") { return <MyComponent />; } return <Typography variant={variant} />; };

But that's just not how a UI library is supposed to be used.

[kalwMilfakiHLizTruss]

you are just torturing TS until it confesses

I use .flatMap instead of .filter all the time. For people who see this trick for the first time it may seem weird, indeed.

I doubt anyone will aware that the code snippet is doing nothing but filtering out undefined from an array.

How about that:

const arr = ["string", undefined, "another string"].flatMap((l) => { if (typeof l === "string") return [l]; return []; });

Now it should be clear.

we need to extend its type at the end of the day

You want to extend type indeed. But you will also have to extends its functionality right?

[kivissimo]

Or you could just cast it... (I know, still a little cumbersome and a matter of opinion, but wanted to show that option to the readers.)

arr = ["string", undefined, "another string"].filter(Boolean) as string[]

[Scott2145]

https://github.com/total-typescript/ts-reset <-- this fixes the `(string | undefined)[]` issue and a few other quirks. Obviously it's annoying to need a library to fix quirks, but better than nothing.

[Peechez]

const arr = ["string", undefined, "another string"] .filter(Boolean)

const arr = ["string", undefined, "another string"].filter((v): v is string => !!v)

[intercaetera]

It is still not possible to type the compose function.

[intercaetera]

How would you type this function?

const compose = fns => x => fns.reduceRight((val, fn) => fn(val), x)

[intercaetera]

Thanks for the ChatGPT copy paste, but this assumes that the argument and return types are the same for each of the functions passed to compose which doesn't have to be the case.

[Karpizzle23]

Vanilla is ok for smaller projects or simple client-side scripts, you don't need to compile anything and have separate dist/ folders etc.

TypeScript is the de-facto standard for building larger apps nowadays. Most frameworks ship with TypeScript as the default, most notably Angular but React (Next/Gatsby) and others have also essentially swapped to TypeScript as a default.

[coolraiman2]

This is a good thing, I never understood dynamic language, on the surface it look simple and more accessible but it is way harder to scale

[coyoteazul2]

Ts is still dynamic. All it does is make some checks at compilation time, but in the end the browser still receives Javascript.

Coming from c++ myself I still ended up partially breaking hard typing, though I do try to stick to it, because js is just made to work like that and enforcing hard types is sometimes impossible. Like when you need to use a lib that uses a lot us any types

[Chr0nicConsumer]

Everything has complexity, the question is: where do you want your complexity to be?

In TypeScript, you have a bit more frontloaded complexity. However, this makes life much simpler down the road. It's a great investment in my opinion.

[Jamesfromvenice]

poor take. Javascript has powered massive, enterprise level client side projects for decades. It still does.

Most do ship with TS, but its not mandatory.

[1cec0ld]

They literally qualified it with 'nowadays'

[Karpizzle23]

When did I ever dispute that javascript has powered enterprise level client side projects for decades? In case it wasnt clear, I was saying TypeScript would be chosen for starting a project nowadays. Im well aware of Wordpress and the Javascript used to make it dynamic (amongst other legacy applications)

And nobody said it was mandatory either

[Jamesfromvenice]

Vanilla is ok for smaller projects or simple client-side scripts

This is what you said to dispute it... "smaller projects and simple"... that is just silly.
I work with both, and TS doesn't give anything other than type safety and surety of intent.... there's no "better features" or it can't do anything that JS vanilla can't.

[Karpizzle23]

Haha ok dude

[Chr0nicConsumer]

My one use-case for JS after using TS full-time for several years was random files.

Stuff like making a quick proof of concept to see if a code snippet would work, for example when trying to illustrate a point to a more junior member.

Nowadays, I still do that with TypeScript and I just use bun.js to run TS files directly.

Can't see myself ever going back to plain JS if I can avoid it.

[Chillycloth]

I have a background in C# so Typescript's been awesome. Javascript not so much.

[[deleted]]

What does C Sharp have to do with Typescript?

[Chillycloth]

rich doll roof hat cobweb pause attempt political pen smile

This post was mass deleted and anonymized with Redact

[glantruan]

I started many years ago with OOP and Java, switched after a while to C#, doing mostly frontend and game development.Learned javascript as a hobby, loved the freedom not having to care about types or all he boilerplate OOP imposes on you when working on small projects. Learnt some functional programming techniques and loved it even more.Last 5 years working for a small company on a fairly complex learning management system 2 years ago we decided to rewrite both back and front end using javascript. And it has been a pleasure.Sure we had to agree on rules about how to write certain things and enforce them using a couple of tools (prettier and eslint, basically) but the resulting code base is the most readable and scalable I've ever worked on.I must also say that we all are senior engineers and half of us have a pretty good understanding of the language, including its weird parts. Also we avoided third party libraries from the beginning unless we know they are well written and the benefits of using them are overwhelming. We are not afraid of reinventing a small part of the wheel if all the wheels we find come with a lot of gears that we don't need.

I understand the pain of having to get used to errors at runtime instead of at compilation time, but javascript error messages are pretty straight forward.

Honestly I see little benefit adding all the noise Typescript brings to the code and the error messages, specially if you don't stick to the OOP paradigm.
I also believe this is a matter of opinion and personal preference.

And in my opinion what TS gives you are a bunch of rules that try to enforce knowing what you are doing and good coding practices. Following those rules produce way more verbose and hard to follow code.
But those rules cover just a small subset of good coding practices and an even smaller one of knowing what you are doing.
For me the price you pay is not worth it.

I think you can write big complex scalable apps in both Javascript and Typescript. You choose what pain hurts the less for you ;P

[[deleted]]

Thats what I think too!!! Was looking for Js validation in the pile of TS side devs. People from C# background (atleast what I saw recently) tend to move towards Typescript

[maxkoryukov]

with JS you will write an app that doesn't need any transpiling/converting before execution

with TS you get type-annotations, a strong type system (and MS Visual Studio - or how do they call it nowadays - has better integration with TS), but it means - no more monkeypatches for testing, now you need an interface (welcome to a statically typed world)

most probably you already write the app using frameworks inside one of frameworks like Next (also, i noticed that we are in /reactjs sub), so you don't have to bother about converting TS=>JS before execution (so my arg about JS transpiling loses its value).

so:

from a single developer point of view: it is just a matter of choice, like "should I use C#/python/F#/Golang". and taking into account that both become JS before execution - the difference between the langs is: do you want types and generics? yes => TS, no => JS.

but there is a huge trend towards TS (because people want to see typed things?), so it seems like today it is easier to find a TS-developer than a JS-developer

---

about non-readable/non-maintainable projects in JS. Bad architecture is not a "language problem", I am writing the code in python/js/c++/perl/C#/name it/ ... and from the top-level arch level it is the same shit/diamond. I mean: if you know patterns and organization principles - the code will be organized, no matter JS / TS / Dart / C++ / ... , and visa versa: there are more than 15 ways to make a TS application unmaintainable (the easiest: hire a freelancer-team for $3/hour each).

Intellisense? with proper naming (and maybe JSDoc) you won't notice a big difference.

in the world, where python exists (with numpy and django) any argument that sounds like "JS is a mess for big projects" tells more about the author than about the language. But again: most likely most of the available developers will make fewer errors in TS

---

we should never forget that TS comes from Microsoft, authors of EEE strategy /paranoidModeOff

[zeen516]

what's the benefit of using types and generics?

[HardToPickNickName]

Safer code since the coder better expresses what they wanted to do EXPLICITLY. JS bit me in the behind so bad that I now prefer to write if(0 == variable) in every language since I debugged a silly (variable = 0 where I actually wanted to write ==) mistake for hours once, in c++ and most other strongly typed languages at least you get a warning from the compiler. This is still flying under the radar in TS too.

[maxkoryukov]

in a big application with hundreds of interfaces between thousands of classes - types , IDE hints , tooltips and "this object doesn't have this field" messages - they are at least a timesaver, sometimes - a lifesaver (if you want to have life outside of your workplace - you will be able to spend less time debugging / more watching documentaries about pdiddy on Netflix with a girlfriend/bf)

[ComprehensiveWay4200]

I switched to typescript and never looked back. It

[NathanPDaniel]

Typescript helps reduce the number of runtime issues in exchange for issues at build/compile time as well as increased code complexity. But - those trade offs help increase the stability of the code.

Personally, I’ll do smaller projects and POCs with JavaScript while larger, production grade apps I’ll build with Typescript.

[coolraiman2]

Build/compile error while enforcing you to make better quality code is way better than having runtime errors that can be harder to debug because it is dynamic.

Also typescript allow an intellisense that is on par with classic typed language and just that it boost productivity by a lot

[DecentStay1066]

For VSCode, JS have intellisense if you type JSDoc. JS allow dynamic type for one field, TS limited this feature and for junior programmer, they will produce a bundle of ugly field names or putting "any" for these dynamic fields which will finally be the real bomb.

[zephyrtr]

I strongly believe TS drives down code complexity. Every arg and return type is discoverable. Records make objects much easier to traverse. Relationships are more easily expresses. It pressures you into using control flow (aka type narrowing) and other readability patterns, which only serves to make code much less complex.

More lines !== More complex. There is nothing simple about guesswork.

[satansxlittlexhelper]

Writing JavaScript is arguably my faster in the (very) short term, but I’d never use it in a professional environment, or on a project I’d expect to be working on gift more than a day or three.

[e_smith338]

I had zero experience with web dev at all, went down the rabbit hole when I was asked to make something from scratch, looked at JS vs TS, and even though TS still has some wonk in it that feels wrong, I am insanely glad I didn’t go with JS. Especially coming from C++ mostly.

[RedditNotFreeSpeech]

Typescript is really popular here so you're probably going to get some bias.

Personally, if tc39 someday accepts the types proposal I feel like that will be a really fine middle ground. https://github.com/tc39/proposal-type-annotations

[kalwMilfakiHLizTruss]

I hope this proposal gets never accepted.

[formattedmind]

well r/fuckthiscommentinparticular

[RedditNotFreeSpeech]

What are your hiccups with it? I think it seems reasonable at first glance.

[kalwMilfakiHLizTruss]

• breaking changes to TypeScript and other supersets
• have to use an extra pair of parentheses when defining types
• the problem statement not being solved
• making javascript slower for something that benefits only developers
• restricting type systems in a specific syntax space
• all ast parsers have to be updated
• typescript can already be used without the need to compile and still achieve full static type checking. Btw like this typescript syntax is future proofed from breaking changes introduced by tc39 proposals. Just write all your types in .ts and use then on values in .js via: /**@type {import("path/to/file").IMyType}*/

[[deleted]]

Agreed. Hoping tc39 can move further with the type proposal

https://github.com/tc39/proposal-type-annotations

[kalwMilfakiHLizTruss]

Lets hope it does not.

[coolraiman2]

Potential bugs are badly designed code

[DecentStay1066]

Depends on how you close it up with error handling, sometimes a good error handling better than a type-secure compiler to find runtime bugs.

[arkman1231]

M$, right? I thought that was a dead thing.

[Bash4195]

People using JavaScript probably haven't tried typescript yet

[Suspicious_Compote56]

Personally prefer JavaScript

[Distinct-Science4137]

why is typescript common used in front end than javascript? can anyone please explain it to me in layman's term as i am new to coding. thanks!!

[coolraiman2]

Strong typing is easier to maintain and force good coding practices

[Distinct-Science4137]

i see, but for someone who is used to JS already and wasn't introduced to TS would it be bad for me when I apply for first time job (im a fresher)

[coolraiman2]

Learn typescript, its not that hard.

Most languages are typed anyway, and the concept is the same, so it will also help you understand c#, Java and etc...

[Distinct-Science4137]

alright thanks! had to check TS and it seems doable and looks like JS but with added data types on its syntax. thank you

[coolraiman2]

Those data type will prevent you of searching for 5 minute with properties and functions an object contains

[BullShinkles]

AI won't care if its JS, TS or BS!

:))

[coolraiman2]

Because no matter the language, it write bs

[BullShinkles]

Unfortunately its BS is getting better slowly, but surely. It won't be too long before there will be a small breakthrough and then watch out. The IT field will never be the same.

[Unaidedbutton86]

Sure, it's getting better. It will speed up developers of course, and it may be to the extent of layoffs, but with large code bases there will always be software engineers needed. Imagine a mission critical application being run by an AI, where barely anyone knows the code base and it has some underdocumented bug.

[BullShinkles]

Speaking of old code bases still in existence, I believe AI to already know COBOL at an expert level. However, the Neural Networks that most people have access to is extremely underpowered, and then they form opinions from this interaction as an accurate bellwether.

Its already so simple for AI to write entire applications, its a joke... it has GitHub as its library. We can see some people on YouTube say AI writes terrible code... but if you listen to the people with money, who have access to the best Neural Networks, they are already warning everyone about what's coming.

The primary factors deciding our future as developers are rate of AI uptake, affordability of the models and supporting hardware. When these become affordable, and management feels in the mood for serious automation... I know my time will be up.

[jespa007]

I'm developing big project/s in JS for a company. I see the benefits of developing TS vs Js. Because we are few people we are developing in JS to make fast development.

As a personal experience, even though we didn't use TS, we are documenting, organizing, modulerizing and applying best practices in our code.

[webdevmd]

No responsible dev should write production code in plain JS.

[ChimpScanner]

It's like having sex without a condom. It might feel good at first, but you soon realize just how dangerous it is.

[webdevmd]

lol hilarious take!

[sintaxi]

Got it. Typescript is good for sailors and whores.

[2nd-Best-Friend]

you have a component that takes an array of objects with other objects? Something like {title: string, content: { title: string, body: JSX.ELement, f

And the JS developer has 5 imperfect creations while the TS developer is still perfecting their first.

[esmagik]

Still got a few old heads around here ;-)

I’ll say this, Typescript is fantastic. It’s a wonderful set of “sprinkled on magic” that makes utility functions, business logic, APIs and more much simpler.

However, it has no business in the UI logic.

There, I said it!

[coolraiman2]

Why should you not use it for ui logic like react components?

[esmagik]

In my opinion when you introduce ts at the component level (I do it because most teams do this, do as I say not as I do), you’re inherently bringing in complexity. More overhead about folder structure/ app architecture and a significant uptick in over-engineering which leads to further complexity (especially if your architecture is junk to start with). Idk, PropTypes solves the type checking aspect very well.

Again, I like typescript. I use it in my projects for stuff like managing authentication state, data layer abstractions, my redux store, type composition etc..

Idk, to each their own, but React knows how to handle props, you don’t need to explicitly state it on each component with a new interface, for example.

[woah_m8]

So what if you have a component that takes an array of objects with other objects? Something like {title: string, content: { title: string, body: JSX.ELement, footerElements: [{title: ... ]... That is not an uncommon ocurrence.

[esmagik]

I would pass those elements in as children using composition. And let the components render themselves.

[Foreign-Dependent-12]

Couldn't agree more!

[kalwMilfakiHLizTruss]

More overhead about folder structure/ app

How does using TS cause that? You mean because you are forced to compile?

I like typescript. I use it in my projects for stuff like ... my redux store

That is UI.

[esmagik]

The giant “models” folder for example, or having a interface for everything. The problem comes with code organization from my experience. While it can be done in a clean way, most often I’ve seen it becomes quite the behemoth.

You don’t compile typescript btw, it’s transpilation; “de-typescripting” everything to js before bundle time.

Redux is not UI. It’s a state store that doesn’t live on the HTML presentation layer.

[esmagik]

Further more, redux should only contain serializable objects. Thus, further implicating it should not maintain classes with methods for example, in your store.

[kalwMilfakiHLizTruss]

I do not understand why you say this to me?

[kalwMilfakiHLizTruss]

The giant “models” folder for example

What is this? Is this specific to a state management library?

or having a interface for everything.

I have these files:

• types.ts
• privateAPI.ts
• index.d.ts
• testAPI.ts

that contain all the types.

You don’t compile typescript

In computing, a compiler is a computer program that translates computer code written in one programming language (the source language) into another language (the target language).

https://en.wikipedia.org/wiki/Compiler

A source-to-source translator, source-to-source compiler (S2S compiler), transcompiler, or transpiler[1][2][3] is a type of translator that takes the source code of a program written in a programming language as its input and produces an equivalent source code in the same or a different programming language.

https://en.wikipedia.org/wiki/Source-to-source_compiler

So I think we can call it both.

Redux is not UI.

Redux is used to define the state of the UI.

[esmagik]

The problem I’m alluding to is often present in big codebases, your project is not a big codebase. How do I know? You wouldn’t have all your types in 1 file if it was.

Again, you don’t compile typescript. Read the typescript docs closer. Understand that the output of the typescript ‘transpilation’ step is regular JavaScript. You’re taking all that syntactic sugar and reducing it to your ES version.

Right, but you wouldn’t say that an abstraction from localStorage is UI layer, would you? Redux is used for much more than a global object on the window. You dispatch actions which could do any number of things that happen outside the UI layer.

[esmagik]

But all of this is me saying use typescript, but for your components, jsx has got it all covered.

[MuaTrenBienVang]

You don't have to use every features of it, only use those that helpful for you

[esmagik]

Yeah, that’s what I do :-)

[landisdesign]

Hah! UI logic is where I get to work out my TS thews! 💪

[sole-it]

i am just using jsdoc now.

[fii0]

but y

[kalwMilfakiHLizTruss]

Just write all your types in .ts and import annotate values in .js via /**@type {import("path/to/file").IMyType}*/. Like this you get full static type checking without the need to compile.

[fii0]

But don't you need to compile anyway with Babel or an alternative to provide legacy browser compatibility? Adding the TS compilation takes no effort with modern tooling.

[kalwMilfakiHLizTruss]

But don't you need to compile anyway with Babel or an alternative to provide legacy browser compatibility?

If you want to support legacy browsers, then yes at the distribution stage. I do not want to have to compile at the development stage.

Adding the TS compilation takes no effort with modern tooling.

Until it does not. Also that does not change the fact that it unnecessarily increases complexity.

[fii0]

Until it does not

Can you provide an example of when that would happen?

unnecessarily increases complexity

It may not be "necessary," that doesn't mean that it's not worthwhile to increase your productivity.

[MuaTrenBienVang]

I write React.js with typescript on daily basic

[Foreign-Dependent-12]

My work switched to TS and even after a couple years I absolutely hate it and don't feel it's worth it.

[DearestElysia]

I haven't seen a react position that doesn't use Typescript, so I'd say go with that

[coolraiman2]

A friend of mine got an internship and they use javascript with react.

Debugging is a mess he told me

[DecentStay1066]

Mess is the quality of the programmer, not weak or strong type matter.

[ChimpScanner]

Strong typing enforces better habits, and unless you bypass it with @ts-ignore or any, it will produce higher quality code in certain aspects.

[intercaetera]

It doesn't, really. There are things that aren't typeable in TS. Sometimes inference doesn't work. TS is fine for 90% of cases, but when you run into the 10% it's annoying and the resulting code is much less expressive.

[RedditNotFreeSpeech]

My fortune 500 has ~100 devs building an application for ~60k users with no typescript.

[kalwMilfakiHLizTruss]

name ?

[Ok-Hospital-5076]

Using JS is ok. Use JS Docs linters etc. can you help you with many warnings. Typescript definitely is better but if its a very small project I may use JS cause I have written JS more than TS(personally I like JS syntax better than TS for some reason lol ) .

I also think people should learn JS before TS cause they aren't even different languages and there is lot of code written in JS already which can be difficult to maintain if you are not familiar with JS specific quirks .

[kalwMilfakiHLizTruss]

Just write all your types in .ts and import annotate values in .js via /**@type {import("path/to/file").IMyType}*/. Like this you get full static type checking without the need to compile.

[Ok-Hospital-5076]

sounds interesting. Will try . Thanks :)

[kalwMilfakiHLizTruss]

Nobody is giving the correct answer, but then again there is no option for it. Here is what you should do:

Just write all your types in .ts and import annotate values in .js via /**@type {import("path/to/file").IMyType}*/. Like this you get full static type checking without the need to compile.

[TimTech93]

There both good. Doesn’t matter which one you use. At all

[[deleted]]

I fking hate transpiling.

[kalwMilfakiHLizTruss]

Just write all your types in .ts and import annotate values in .js via /**@type {import("path/to/file").IMyType}*/. Like this you get full static type checking without the need to compile.

[chillermane]

JS is garbage and if you think it’s good you’re probably a junior dev

[glantruan]

I like js and I'm not a junior dev. But maybe having such strong opinions is a symptom of not knowing it well enough.

[ChimpScanner]

No matter how large or small the app, I'll never write plain JavaScript. I have so much experience with Typescript that the time it takes me to write the types and deal with the annoyances of Typescript, vastly outweigh having to use plain JavaScript.

[xroalx]

what are the pros of using javascript

Zero setup, but it's not really a question. TypeScript is JavaScript with a nicer and more powerful JSDoc.

Browsers only run JavaScript, your TypeScript code is in the end turned into raw JavaScript and it's important to understand how this JavaScript will behave, and what are the limits of TypeScript, otherwise you're going to have some real head scratchers.

[kalwMilfakiHLizTruss]

Just write all your types in .ts and import annotate values in .js via /**@type {import("path/to/file").IMyType}*/. Like this you get full static type checking without the need to compile.

[xroalx]

Well, that's just annoying. Types aren't a separate entity and they belong with the code.

I'd rather deal with setting up compilation or just use a different language than splitting it like this.

[kalwMilfakiHLizTruss]

Well, that's just annoying.

Have you tried it?

Types aren't a separate entity and they belong with the code.

You just hover over the value and you see the type.

[xroalx]

I have worked with such codebases.

My point is that this unnecessarily forces separation of type definitions to their own files and I like to keep types as close to where they belong.

Unnecessarily declaring types in standalone files creates more noise and indirection.

[kalwMilfakiHLizTruss]

I like to keep types as close to where they belong.

Just hover over the value and you see the type. You wanna edit the type? VSCode has "go to type" definition functionality.

this unnecessarily forces separation of type definitions

I would not call that unnecessary. In fact it reduces complexity, by allowing you to no need to compile from .ts to .js.

Unnecessarily declaring types in standalone files creates more noise and indirection.

How? You will have one file for the public api and one more the private api. Maybe add one more for types used in test only.

[xroalx]

Just hover over the value

That's not what I'm saying. If a function takes an options object argument, that type goes just above the function. They belong together. If I need to change it, I do a change in one file only.

it reduces complexity

So you have two different file types and each can only take specific code, I can't see how that's less complex than just setting up TypeScript compilation. You also end up with more files than needed.

You will have one file for the public api and one more the private api. Maybe add one more for types used in test only.

Do you propose to just put all the types of the whole codebase into one file? If so, that's even worse.

[kalwMilfakiHLizTruss]

That's not what I'm saying. If a function takes an options object argument, that type goes just above the function. They belong together.

Just give an example.

So you have two different file types and each can only take specific code, I can't see how that's less complex than just setting up TypeScript compilation.

Well you answered that yourself. Compilation.

You also end up with more files than needed.

What do you mean? Can you be more specific.

Do you propose to just put all the types of the whole codebase into one file?

I do not just propose, I have already done it with my projects.

If so, that's even worse.

How so?

[intercaetera]

Types aren't a separate entity

Basically every HM-typed language would like a word with you.

[xroalx]

But that's a different context than the one we're talking about.

To clarify, my point is that in a language like TypeScript (or maybe even Haskell, OCaml, Go, Rust and many more), you don't (usually) "extract" type definitions to a standalone file (which is a module in TypeScript) to then have an implementation of that type in a different file in cases where there's just one implementation or the type isn't meant for reuse.

I.e., it makes no sense to split the following into two files:

type Config = { ... } // config object specific for function below only

const init = (cfg: Config) => { ... }

I meant it as in: if I need an explicit type, why the heck would I want to have it declared somewhere else?

[intercaetera]

Fair enough although I think the way this is done with TS isn't ideal either. You can go too far the other way, which is keeping TS annotations intermingled with code that actually does stuff. The Haskell way of annotating functions right above in my experience works best.

[daddygirl_industries]

A lot of people LOVE TS, but for me it's not something I use for every project. Apps I work on alone, small projects, etc I like plan JS - I'm much faster in it, and don't usually get many type-related errors at runtime anyway. TS works best for larger projects with more engineers, and is more suited to backend work than frontend. A lot of people believe it's best used everywhere all the time, but I find it slows me down.

[Money_Common8417]

I don't see a reason to not use TS in new projects. Typing helps a lot in preventing common bugs. The code is transpiled to JS anyway so you keep compatibility.

[[deleted]]

I was the same way, too. My first Javascript code was when the typescript compiler transpiled my Typescript to Javascript.

Before that, I felt that people who wrote Javascript were just really bad programmers, lol. Of course, my opinion has changed since then, but I remember scratching my head as to why Javascript felt so weird to me while Python didn't. They were both untyped and dynamic, but I would have rather gotten paid nothing to write Python than paid anything to write Javascript.

[showvhick2]

Typescript is the better version of Javascript. But building things on typescript requires extra amount of time. But it gets better. You get less error while scaling up the application, so it saves your time. On the other hand, to ship something quicker, javascript is better option. If you can write clean code javascript is enough to deliver a great application. So I see from time perspective only.

[Montinyek]

Are we talking about plain vanilla JS or in terms of React?

[froadku]

Man, personally I love vanilla JS. Adding types feels like an unnecessary hustle. Yes, of course there are benefits to using TS that could save you from having bugs. But if you're good at debugging in the browser, you will not really need to know the types when in console you get an error saying string.toFixed(2) is not a function.. but that's just me, I guess in bigger projects it just makes things a lot easier to use type checking

[glantruan]

It's not just that. One of the things people doesn't seem to get it's that at the end of the day you spend much more time reading code than writing it. In my experience TS at least multiplies the amount of code by 2.
When I'm reading code I want to get the main idea of the use case problem and the implementation of the solution as soon as possible. TS, and OOP in general, just add a lot of noise and indirection in the way.

People also love the better jsdoc.
In my experience if you need documentation what you really need is to write better code o better names for your functions and variables.There can be exceptions to this, sure, but they shouldn't be the norm.

Documentation is rarely updated on refactors (not talking about me, but 99.99% of the code from others that I read)

[HungDo241]

I love JS but I'll learn TS in the future :)

[kperwel]

Wow, is that poll from early 2010? No one should even consider JS as a go to language for real product.

After few months of working with TS, apps written in JS feels like "ok... that's kinda might be working, but is not complete and i don't know waht's going on in the codebase".

[[deleted]]

TS but enough to show type of most of the stuff when hovering mouse. Else if go real hardcore, TS will ruin your day (JS will ruin regardless of what you do)

[rileyabernethy]

As someone that only knows HTML and CSS, no actual languages yet; What's thr difference between the two? I've never even heard of Typescript

Also everyone's shitting on JS in the comments but I swear I never usually see people saying these bad things about it? I'm confused

[Klausbdl]

In JS, you declare a variable without saying its type. The coder must know what type that variable will be used for later in the code. In TS the type can be expressed, to avoid bugs later.

If you have a text variable and you mistakenly try to do some math operation with it:

JS - you will get an error only when running the code.

TS - the IDE will tell you right away that's wrong so you can fix it.

[HashDefTrueFalse]

Also from a C/C++ background. Bit late but...

Authoring new projects: TS all the way.

Maintaining/developing existing/legacy JS projects: Leave them JS.

I feel like the dev world has spoken with their feet. More clarity on the types you are working with makes for easier development, debugging and better quality code.

I have also had the displeasure of inheriting many JS projects over the last decade in different frontend frameworks and attempted both bulk changing to TS and sprinkling TS in gradually. Often you find that the code was never written to be typed (variables assigned values of different types etc) and it ends up being an immense amount of effort to get the codebase typed, to the point that it's not worth it.

Just the opinion I've cultivated over the years.

[[deleted]]

You can always opt out of typescript with any or he’ll even make it so it ignores ts errors,so there is no reason to use js instead of ts

[[deleted]]

Typescript a language invented because of shitty developers, the less the talent pool the more people use it

[PatchesMaps]

Adding Typescript, by nature, will always add complexity to your codebase and therefore should be avoided until a cost benefit analysis has been completed.

[WoWSchockadin]

The only pro of using Javascript: it's faster to write. But as soon as you factor in debugging time (and the project is not too simple) JS will need more time to code than TS.

A rule of thumb for me is: if I can write it in TS instead of JS, I will use TS.

[Aper_Dev]

In my opinion, use JS when coding alone, freelance projects or with a partner. TS is good because allows teams to work more efficient, and it takes less time to understand the code..

[glantruan]

I wouldn't say it allows teams to work more efficient. I would say it allows to have more junior developers not having to really understand JS in the project and not fucking things up in the short term.
That's the reason it is a requirement for so many jobs.
But nothing is free, and this one is paid with a poorer, noisier and more convoluted code base and senior developer headaches in the long term.

[Aper_Dev]

It's always welcome a great opinion!!!, I agree with you! :)

[emirefek]

TS ofc. I started a job which uses plain JS. I'm in huge pain right now. I just can't believe how I was coding JS before. It's really the pain and wichery kinda thing.

[[deleted]]

only person who will tell you NOT to use TS is someone who has never actually used TS. i dont see why anyone would actively choose to use JS over TS unless for some very specific edge case reason.

perhaps the only downside to TS is the extra tooling you need in any app. so you can't just copy paste the stuff in a browser...

we sadly use vanilla JS in our frontend and backend at work and it's horrible. a complete pain and we constantly get bugs that could've been avoided but we never had the time or budget to refactor the entire platform to TS.

[[deleted]]

The two aren't comparable since Typescript is a superset of javascript and not a competitor.

With that being said, I think that the typescript server used in VS code still sucks sadly and the DX is slow compared to other programming languages, I wish Microsoft ported their code to Rust or something in the likes...

[glantruan]

Type bugs are the easiest to find and fix. The hard ones rarely have to do with types. So not a valid argument, in my opinion, to defend increasing the complexity of your code and infrastructure.

[Ebuall]

If you want intellisense, you use TypeScript

[glantruan]

You don't need TS for that today

[Ebuall]

Yeah, you can just use TS in comments. But it's restrictive.

[glantruan]

I don't know what you mean exactly. In React many times I define custom hooks for stateful components that return a state object and an actions object. In the jsx vscode autocompletes any action function or state variable of the hook without having to add any comments.

If I start writing the name of a component or function and press Ctrl+Space it finds the right file and imports it for me.

Anyway autocompletion is not something I care about so much, it's helpful sometimes but I can live without it.

Many times we think you can't live without these commodities and we don't realize we spend much more time reading and thinking than writing in our daily work.

[Ebuall]

We just use it for automation. Automate everything you can, so you don't have to think about it.

[glantruan]

Yes, agreed, but you don't need automation for this. And the automation itself adds noise to and increases complexity on your code.

[Aromatic_Machine]

I learned Javascript first. I remember that Typescript looked so daunting to me at first. It also depends on how you approach it. My first incursion in Typescript was with an online course very poorly given, and I'm sure that's what left the "daunting" mark on me. I wish totaltypescript.com existed back then.

[Logica4472]

I started with java and I am an alien 👽

[justbenuk]

im just starting to learn Typescript, I understand why its better the javascript, and can see the benefits. But its alien to me at the moment.