today the backend dev told me that he was trying to setup typescript for the company for so long and the company resisted him but he was super proud of his achievement of getting typescript into the project and i told him. sorry I agree with the company, you're stupid
i didn't tell him he was stupid ofcourse but i told him why i thought it was an unnecessary dep
i asked him are you doing a lot of number crunching? he said no
and i told him, most of the data you're going to recieve is in a string format or in json strings
very rarely are you going to get number data
and you can easily coerce the data into whatever you want

So every variable is a string? Every function or method only accepts one string parameter and returns a string parameter? There aren’t any objects with property names subject to being misspelled when accessing the object property? There aren’t any asynchronous tasks? No risk of forgetting to await a function return? There aren’t any other developers coming into the project who may appreciate not being clueless without type definitions?

Reading your rant it’s hard to judge how badly the project needed TS, but I have a hard time imagining it was a stupid move.

It doesn't matter, whether you have JSON strings coming in. Before you can do anything with them, they have to become meaningfull structures. And that structures you can guarantee to be of the correct type before passing them anywhere with TypeScript. Whenever you parse JSON, declare the output as of being of the unknown type and properly verify its and its content type before you pass it anywhere. Avoid the any type and TypeScript will help you catch bugs before the users see them.

@red-knot no you just coerce the types as you need them, you use parseInt() or typeof in your functions if you absolutely need them. typescript only serves to make projects bigger and harder to make progress on, you should be typing less code rather than more code. also you should use a linter, and misspellings are a thing of the past.

I don't there are cases where typescript won't help

@Meleeman the amount of code doesn't matter, ability to understand and make changes that are correct at a good speed is what matters

@Crost idk man, i've been told i'm a faster dev by those who really like typescript. less code == less mistakes. easier to read. easier to maintain. you don't need to know the types in web development unless you're working with data that requires it, and in many cases you don't. and if you do its not the main basis of the application, or you can pass it off to a language thats better at such things like php or python. node.js is probably the only place typescript should be

@Meleeman I find the majority of mistakes I make are because I have a typo in a property name, or a contract was changed slightly in one place but not another. In a team setting those are also the bugs I usually see the most often. Anything that gives me more IDE support and build time errors instead of runtime is a good thing for me.

@Oktokolo depends on the type of data you are recieving on the json right? if you're not doing a bunch of number crunching you don't need typescript. you're going to be receiving string data from users, most likely, and it will be in a json object or some other similar format. if you're recieving things like telemetry data from a rocket or weather balloon, then yeah you might want to use a language with types otherwise your code will be polluted with parseFloat or parseInt

@Crost you should use a linter then. i recommend you and your team use eslint

@Meleeman I don't believe that a linter will help because it's not the coding style that is wrong but just incorrect property names. But yes we should use a linter too lol

@Crost eslint has caught misspellings and missing semi-colons especially if you enforce style that deffo helps with code quality.

@Crost for example, you may get a linting error that says "undefined variable getrequest on line 98" and you might be like "wtf getRequest exists and i defined it" OH its GetRequest, not getrequest.

oh lol check this out.

https://npmjs.com/package/...

Setting up a spell check plugin and constantly changing the config if it doesn't know a word sounds like more work and than TS

And still doesn't save you from e.g. accessing properties of an undefined/null variable

@Meleeman why the fuck is typescript used for "number crunching"? It's still just compiled to javascript and run in the JS runtime. Number crunching? You need python or C++...

You have a "stringly typed" code base... That's more a "you" problem. Same happens in python when people pass around structured dicts instead of dataclasses. You're not coding in the language of your problem domain. I'm guessing you've got some abstraction breakages too.

@Meleeman No, it doesn't depend. You get the string, deserialize it into unknown, do explicit type checks and maybe soem more parsing - and then the whole beast is known to be of a specific type and you can pass it to other code which knows exactly what it gets. TypeScript ensures that what you think is the type of the data at any point actually is the type of the data (if you don't use the any type).

The core benefit of TypeScript is the static analysis at transpile-time. It is similar to Psalm or PHPStan for PHP - just as an extension of the language and therefore with less-awkward type annotations. The other features of TypeScript are basically syntactic sugar, which is nice to have.

Having any static type checking makes the code less habitable for the related bugs classes. It is like having automatic memory management in that regard.

@atheist abstraction breakage? what are you talking about? yeah you only need to work with strings in most cases. there are very few cases unless you are doing number crunching where you need types, if you're returning functions or any other data type most of your needs can be handled with typeof, or parseInt or Float and you only need to do it in a couple places depending on the project. the one instance i wish i had type script was when i was doing a stock ticker application where we basically ran calculations on string data, and even then there was one instance where type conversion was really handy. for example comparing js time strings works based on how js does math on strings. having typechecking would have made that project go a lot faster.

@Meleeman its not only for number crouching but for any complex data like arrays of objects or similar.

Sure for small hobby projects it might be overkill but having worked with js since IE2 I would go with ts every chance I have.

Especially if its more than one person on the project or it will live for more than a few weeks.

@Oktokolo uh yes it does. you already know the type will probably a string, within an object property especially if you pulled it from form data. and in most cases when building software you don't need to check for numbers. maybe you're doing reliability engineering, and accounting for a .1 percent case it won't be. but if you simply pull in ts in every project you are committing the sin of over engineering. know what data you're dealing with, and deal with it accordingly, js already give you tools to enforce types if you want to, and you need it in fewer cases than you think.

\_(^_^)_/

Not worth replying on this thread more. OP made their mind up.

@Voxera literally all you need is map, reduce and filter, potentially other array functions for doing things like dom diffing, and place your conditions to check for types using typeof. you don't need typescript for this. I can see the argument of perhaps enforcing a sort of intermediary schema to be received or sent for each object however in a lot of cases this is also unecessary. and my projects last longer than a week, i don't understand where you get the idea that software is fragile unless you have a million deps in your project, which would make sense considering you need to have @ts version for all your packages.

@Meleeman who needs strings, why not just work with binary data?

You're missing the point. The strings *represent* something. If you code in the domain of your problem, if you use structured types that reflect the structure of the domain you work in, you will have a more maintainable and easier to understand code base. Otherwise, why not just use "a" and "b" etc as common variable names?

That's where the abstraction falls over.

But honestly, I kinda feel like you're just a troll, so I'm out.

@Meleeman I write web applications, that means a “page” can consist of thousands of lines of js code with objects meaning users or products with dozens of properties, sometimes multiple levels deep and with a fair number of boolean and numeric fields.

Using typescript lets the editor provide intellisense and warns about types.

Sure you can use coercion BUT i have to often seen that backfire resulting in the wrong coercion happening especially if there is 5-6 different developers involved.

And then you have performance, coercion costs performance since not only is it extra processing steps but it also prevents optimization that can be done using stricter types.

And no one likes a slow site.

@Voxera youre going to have to coerce the type anyway, after all user input isn't to be trusted. so it doesn't matter you're going to type more to accomplish the same task, and then when you have to add or change it, type even more than i will to get it done. i too have worked on codebases, and quite a few actually that relied on type coersion, not all of them were good i will admit, but i've worked on such projects that were thousands of lines long and i myself have maintained js code without a framework for thousands of lines. my last project that didn't use typescript was a pain only because we were doing number crunching on the frontend thus the components were filled with parseInt and parseFloat to keep things working smoothly. didn't really run into perf issues. but we were also using vue so. idk at what scale you think this matters but i've yet to see what you describe, and i've only worked with 4 at once and never really had any major issues save for one project

@Meleeman I was going to protect your side, but your additional explanations state an objectively wrong stance, which only causes more issues in the long run.

@iiii i highly doubt you were but which part of what i'm saying is wrong?

@Meleeman pretty much everything. Your stance is opposite to what a developer should strive for to make the software robust and reliable.

Try a different career. With such stance you ahve no future in software development.

@iiii I get things out the door. I'm the person that replaces you when you can't get things done. That's my future in software development

@Meleeman funny indian man is funny

I’ve been thrown into projects that were developed by dudes who coded fast, got things done quickly and who _knew_ in their heads what data they were working with. Those projects were unstable and bug ridden. I didn’t know what I was working with. Hence my velocity was slow… until I got to the point were I had added enough typings by progressively migrating over to TS or by simply adding JS doc in as many places as I could.
And oh what a surprise, bugs started dropping like flies and my velocity went skyrocketing. Also I could easily come back to parts of the code that hadn’t been worked on in months without scratching my head asking myself: wait, what type of data am I working with here?
Short term velocity should not be your goal. Investing time in the initial phase to lay solid grounds (with TS) will impede your velocity at first. But the ROI in terms of time saved in the later stages of development will definitely be worth it, for you and anyone else coming into the project

@red-knot i don't think you understand my philosophy here. less deps == more reliable faster running code. less code is better and easier to read. typescript is antithetical to that. There are cases where it helps but most cases i deal with i and others who have worked on my projects never complained about it being vanilla js. because i can write less code my development is faster. that doesn't necessarily mean i'm not aware of types. People who know me respect what i'm able to accomplish without using typescript.

@Meleeman you just stated my point once again when you said "that doesn’t necessarily mean I’m not aware of types".
YOU know the types. People working on the project after you are most likely going to be lost. So you’ll keep on working fast while they fiddle around to get things done
People not complaining about your work doesn’t mean they’re happy about working on it. A lot of work relations have to remain cordial and its often difficult for colleagues to verbalize these things. The fact that your colleague went ahead and migrated to TS actually says a lot about the situation at your workplace. Your colleague wants to add quality and is pretty much dismissed as being stupid for doing so.
Plus your point about slower code with more deps is wrong if we’re talking about TS: typescript is compiled to plain JS. It’s that plain JS that’s going to be executed at runtime, and it’s going to be as fast as your vanilla JS

@red-knot ig nobody knows how to read the git history anymore, yeah i'm aware how typescript works. i've used it before. he didn't need to put it in there and its an unnecessary dep. typescript does not necessarily mean quality, ive seen bad codebases with typescript. plenty of unnecessary abstractions can be made. anyway i know exactly when and where i would choose to use typescript and most people overuse it, and overstate its marginal benefits

@Meleeman of course TS like anything else can be misused. It doesn’t mean it should be avoided. Maybe if you used it consistently you would actually learn how to use it well and understand the huge benefits it has to offer (intellisense to name only one).
I’ll give it to you, I hated TS at first. It seemed like it was there only to add obstacles and it definitely slowed my productivity down at first. But now that I have a decent grasp, it’s a delight to work with and it allows me to work faster and more reliably

@Meleeman

less deps == faster running code is absurdly wrong when it comes to typescript.

TS is a transpiler. You get regular good ol' js. Running on good ol' regular V8.

You *don't* (and this is not open to debate, it's a fact) pay any runtime cost for having TS.

@Meleeman typescript has no dependencies once compiled, it compiles to real js, and modern broswers can use the fact that types are fixed and not coerced to optimize the jit.

Yes there is a dependency when compiling but not when running.

I really hope I never have to work with you or anyone like you ;)

But since I am one of the people doing interviews its unlikely.

@Voxera likewise and those were the deps i was talking about, i am currently working on such a project and it is a bit frustrating