ProgrammerHumor
watchHowILoveToDeclareEveryInterface
I do kinda love it though. My IDE knows what properties and methods the object should have.
Discussion
Typescript is GOATed. I love knowing what my functions require and what they will return. I love knowing what types my variables are.
Refactoring is where strict typing really shines.
You basically just start breaking shit and the red lines tell you what to fix.
LOVE IT
Every JavaScript/typescript/python meme in this subreddit read like someone who's never written anything with more than 3 function calls before.
Real talk
If those people here could read, they'd be very upset right now.
Typescript is a solution to a problem which should have never been there. Decoupling the types from the code was and still a bad idea but its better than nothing
Can you explain what does that mean in context of js/ts
"JavaScript should've had types to start with" is all the original commenter is really saying.
More specifically, JavaScript is pretty object oriented. It's multi-paradigm, but still, a lot of what we're doing is reading /writing objects.
Handling objects without a type system is just kind of insane. Everything from code smells (relatively minor bad practices) to major issues comes from not having a type system.
Like literally just now, I had to adjust some touch events in an old codebase that uses an old version of jQuery. I have to fly completely blind, do a ton more Googling, and make a lot more errors / work significantly slower than I would if everything was typed and if my LSP could do more to guide me.
js has dynamic typing, and type issues only come up once the code is run.
Compare that to other languages that check typing at compile time and catch issues before the code is even run.
ts alleviates it somewhat by adding type annotations that enable some form of type checking, but you can still get type errors on execution since they’re only annotations and compile down to js in the end.
Just how it is when you don’t have strict typing.
similar issues with python ? pydantic is a fake typing as well
yes
But I still love using django and it’s amazing paired with drf . Most of the things are battery included battle tested , ain’t no way I’m going to use some sprint boot crap for my mvp where I have to ship fast. Typing doesn’t bother me, if we are testing them apis for correct behaviour right
But I do like Typescript for my nextjs frontend , good ability to detect when we change types or things can break ( too easy to find that out in runtime using javascript )
Imagine JS as TS, but you can only use type any
Typescript's goal is to trick you into believing it knows things at runtime that it actually doesn't, no matter how many times you have to remind yourself that it's all JavaScript underneath.
If it's tricking you, then you're doing it wrong. Typescripts goal is to allow the programmer to declare what he/she knows about things at runtime. It's a developer tool, it allows you to declare to yourself what you know about the code and how it should behave. It's only saying back to you what you have said to it.
Every problem with a language is one that makes it easy to use it wrong.
No language knows the runtime. You may compile with libraries that are missing at runtime. But you mean if you put any and ! all over the place you may end up tripping yourself?
Some people like decoupled types.
It's best to see them like unit tests.
Typescript is amazing. The only issue i have with it, is when people bloat their project with types from all these code gen tools. It is down right the most horrible experience to work on a project that have multiple code gen tools that have generated close to 1 million types and you now have to wait 30-60s on every single auto complete to trigger
That sounds like a nightmare
Thats my current job haha
I get a lot of people aren't fans. I kinda love it, but I also use it in a very different way- it gives you a pretty clean, modern, object-oriented scripting language with an actually really robust type system (including decorators that can actually execute code when a type comes into context, replace members, etc), great IDE support including sourcemaps that work with a visual debugger, and it can transpile all the way down to ECMAScript 5. It can probably go lower, but ECMAScript 5 is important.
There are lots of native libraries, including some really small ones with basically no external dependencies, that can run ECMAScript 5 (but not 6!) really fast, including even precompiling it.
If you're developing an application that needs object-oriented scripting support (ex: a game engine), it's an extremely strong contender with a basically unbeatable combination of language features and portability (and not too shabby on execution speed if the transpiler output is precompiled to an interpreter-specific bytecode.)
Wait, if you hate typescript because of types...but thats the basics
Data types are essential and a core concept in programming, thats like admitting you just hate programming
Also, how about you just use javascript then lol
Use type inference and rely on types/interfaces as needed. Unless you are authoring a library or using decorators, most of what you need to do in TypeScript can be accomplished with functions and typedefs only.
Functions are 90% of my type definitions, including interfaces for params/returned values
It's like Stockholm Syndrome, but for your codebase. And it actually helps.
You guys support untyped based languages ? Count me out
I love you in a prison of your design though. When you get out you break my code.
What I love about C++ in Unreal Engine is because all the types are there, any time I see something in the codebase that's new, I can easily navigate to it in my IDE and discover how it works better and sometimes I even learn a cool new trick in how to do something in my games.
I cannot understand how people can work with every variable is var or let.... I can't even read it.
What do you mean "prison of your own design"? You always living in your design. Strict typing is just clearly shows your design back to you.
You should wear a blindfold for a day
I switched from TypeScript to JSDoc because working on a large project with limited hardware causes problems. Take 2s or even 10s to get LSP suggestions completion, or get infer type. I love typescript, but I hate how slow LSP is, and I hope TSGO will fix this.
Idk what the hype is about. Idk why it’s so important that I type “any” anytime I wanna declare something.
I have mixed feelings about TypeScript. On the one hand, type safety and smarter IDEs are obvious advantages. On the other hand, in all my years of JavaScript development, I've almost never had a bug that turned out to be a type issue, so it seems like a bunch of extra code to solve a problem I rarely have, especially when working in microservices where I can hold the entire thing in my head. I'm trying desperately not to be the old man who says, "Back in my day, we didn't have your fancy smart IDEs. We coded in Notepad++ AND WE LIKED IT!"
The bars are always there. I see them while coding. You hit them on the runtime...
I just can't wrap my head around the idea of voluntarily refusing strict typing.
Sounds more like skill issue
"TypeScript: because who needs freedom when you can have strict type checks and existential dread!"
I get way more existential dread from the runtime errors that dynamic typing creates.
With typescript, because there is no runtime typechecking, you can have both!
If it is to suffer... Js + Jsdoc >>>> typescript.. if you disagree. Skill issue.
TypeScript offers more functionality.
So you basically prefer a workaround to define what typescript supports out of the box. Js doc does its things pretty good but it is INSANE to type more advanced types (and don't get me even started on how to define the entire comment section just to template something...).
I see Ren, I upvote
My problem with TypeScript isn’t that I object to the concept of type safety in JS, my problem with TypeScript is that it’s fuck ugly.
Really? It looks like a sexy version of Java to me.
That's why I write JS instead. I use jsdoc on things like functions to know what they want from me, and to occasionally leave a comment on some elements of the program - the main benefit is that I'm not obligated by typescript do add all these annotations for everything every time.
I won't understand people that prefer js doc over typescript. You are doing something that requires even more work to do and is more limited than typescript. You're only getting type hints with those comments that might be ignored by anyone (type is not enforceable at all and might be outdated). Typescript enforces some rules that can't be broken that easily unless you tell it to - and once a signature changes then you will now have errors in other parts of the code you can search for and update.
I literally said it's because I don't have to be limited by typescript forcing me to make a formal writeup for my every action. I don't want those weird constraints adding more friction and boilerplate. Jsdoc is just a comment, the js environment can ignore it, I can ignore it, and I am not obligated to mark everything with it.
I could accept typing in a language that consistently verifies typing for it's programs, but that's not how typescript works. Typescript is a JS preprocessor that only works for your code, it doesn't guarantee anything for runtime resources and it especially doesn't guarantee anything for addon code like libraries and packages and stuff.
People who complain about typing in Typescript are just bad at writing software and you can’t change my mind
You should know what every function expects as an input and output and you should know what every variable will be. Not sure why this is controversial to so many devs lol
I go through onto a ~12k LoC tsx codebase and it was truly abysmal the number of “:any “ and “as unknown as T” I saw. To the point where we even had the api definition in redux defined as “const api: any = createAPI”. Some Typescript developers hate types so badly I wonder why they even bother
Add a
"@typescript-eslint/no-explicit-any": "error"to their eslint rules, and let them train themselves to be better.Then watch each new file that you open become red and throw infinite linter errors, I love doing that
Add pre-commit check to throw an error if there's linting errors, done.
Yeah i did that and another dev proceeded to add literally hundreds of eslint disables, why you ask? Because he couldn't figure out how to cast errors to Error
pretty sure all these typescript memes are from people that dont have a job yet where you have to think about maintaining software and not just 420 blaze it a hackathon project in a day
hAvInG tO aLwAyS dEfInE tYpEs sLoWs dOwN dEvElOpMeNt tImE
Well, it does. A lot. But it saves much more maintenance time than the dev time cost.
I actually disagree. It also speeds up development time when you reuse the code. It speeds up both.
Especially when working in teams, but also when reusing code you wrote.
It’s the same argument for unit tests - unless you’re a gigachad that gets everything right the first time, having a few tests for each change speeds up dev time.
Also, you need to be a perfect predictor of what the future needs of the software will be. Nobody can be that lucky.
The improvement to code completion from typing alone can probably save more time than relying on dynamic typing.
If you are forgetting what types your functions need and output while you are developing a new feature, you are doing too much at once (or need to see a doctor!)
Once your working prototype of your feature is proven, thats the best time to put in types and unit tests. Otherwise you are creating railroads as you go and it’s discouraging you from doing rapid rewrites and direction changes during prototyping and discovery - and if you DO need to change direction often you are likely writing (and rewriting) more lines of types than code per hour. So, empirically when writing a new feature that needs experimentation, you will take a lot less time if you dont type it as you go.
Thats not to say thats a good thing or the right approach, its just simply what will happen.
There are better techniques to use when developing large features from scratch though, and typing as you go is probably one of the least effective of them.
When you do fully complete your feature and merge it in, you 100% should have it fully typed and unit tested though!
What lol? This is incredibly common. I’ll barely remember functions or features I wrote 1-2 years ago. Nobody remembers everything they programmed. Especially if they end up working for different companies, handling different codebases. To be honest, the only person that would say they don’t forget their code is someone that is too new to the industry to forget
I barely remember features that I wrote a few hours ago tbh
Im talking about while you develop a feature for the first time (eg make a button that sets something). For maintenance of old code, it should be already typed. Maybe read the comment again?
You're 100% right, I'm saying this as someone with 15 years of web experience.
I sorta agree with his current post now too, but it’s not what he posted an hour ago lol. Everything past the first paragraph is new. Also, in no way does his edited post of his current coding style conflict with typescript so I don’t know why he’s arguing against typescript in this case
No edits have occurred on my post, you can check. Maybe your app bugged out?
Bruh you’re actually trolling, you just edited your comment after my post 😂 I’m done with this
Maybe you responded to the wrong comment? My comment hasnt been edited, you can check.
Who goes back over their code after they're finished to add types - that's crazy.
Your types shouldn't be changing meaningfully while re-writing your code, I don't understand what you're talking about. I have no point of reference for the experience you're describing.
But I have, many times, started a new day by coming back to a piece of code I was working on the previous afternoon and had no recollection of what I was doing or why. I don't think that's indicative of me needing to see a doctor. Of course it'll come back to me - but types and docstrings are my best tool to get back to 100% productivity at the start of the day. Write your types, tests and documentation as you go, it's much much faster.
How bout an example?
Say I am developing a feature that takes an array of hashed strings for a store of some kind.
I build the feature and its supporting functions during the day/week and then realize i need to change the entire tree of functions to support an array of objects instead to store more things, like subscribers/etc.
How much types have i written yesterday that are now invalid?
Imagine that the functions change significantly over a daily basis while i figure out how to solve my problem.
Isnt it quicker to just solve the problem first?
For starters, I don't think that's a very common issue. You should generally work out the entities you need before writing any code, and so you should know if you need an object or not before starting. It seems unlikely your store changes from needing a single hash, to a hash plus metadata. But regardless, we've all been there at least once, so I'll engage with the example.
You need to alter one type. Only one type is invalid.
Reuse your code. If you have a type that describes a specific entity for a store, even if its just
string[], abstract it into a named type in a types file. So your code shouldn't look like:it should look like:
Now, when you need to refactor SomeStore you just edit the one type, you don't need to go back through every function that ever called it. And now, if you miss something during the refactor that still treats arg like an array of strings you'll get a helpful red squiggly to point out "Hey! You missed this bit of code!". And that will speed up your development too.
What in the actual fuck are you on about. Do you make every feature out of 100% new code? Have you literally never made a utility function? If you are developing a large feature and you cannot reuse any of it, then you just suck at programming (with some rare exceptions). And if you don't type it as you go, then you aren't making its components reusable.
Also the bigger it gets the more typing helps you keep it on track.
Jesus how much time do you all spend typing to where this is a problem? My job is mostly reading documentation, working on the code design, running tests on my software and then maybe an hour a day is actually spent physically writing or modifying the code.
I don't even type that fast.
If you are in a no-agile workplace (like shape-up) you will spend a large proportion of your day writing code - which is lovely
Yeah it’s like objecting to having an enforced code style guide or unit tests. It’s a bit suspicious if a dev takes such strong issue with these things because if they really interfere that much with their development process they were probably writing crap to begin with
I mostly work in Java, so when I have to do stuff in typescript I’m obviously bringing some bias with me, but I can’t stand it. Everything about the way the language is structured seems to move against the current of strong typing. It feels like trying to jam a star shaped box into a little rectangle hole; squeeze enough and you can get the corners situated in there where they need to be, but it’s a pain to do so and the end result looks ridiculous.
I mean, TS is bringing types to JavaScript. I don't think one should hold JS's bullshit against TS.
Writing types is the closest to TDD i will ever get, and i like it this way
I'm so good at this part that I don't even need typescript!
But it's an extra build step!!!
< You should know what every function expects as an input and output and you should know what every variable will be. Not sure why this is controversial to so many devs lol
/>/People who use 'Auto' or something like that Award
Not only that it's like the easiest type system of all. It infers things so well. Spend a week in Rust and tell me how "annoying" TypeScript is.
Agreed.
My only complaints about typescript are the artifacts it has from being designed to transpile to JavaScript.
I think the issues are with generics, where a function expects an argument to be a key from object T, but then you get the object keys using Object.keys, which returns an array of strings. TypeScript starts screaming at you that your string is, and never will be, a key of T. And you're like, “But it's right there, I promise!”
Then you realize you also need deep nested keys as dot paths for Lodash's set and get functions, so you use a NestedPaths type helper. But you notice that your interfaces loop back onto themselves, causing TypeScript to scream “To Infinity and beyond!” at you.
So, you fix up the NestedPaths type helper with a Depth generic. You then realize that using Ag-Grid was a terrible idea and you probably shouldn't have used nested paths to begin with—but you're in too deep, and any changes you make will require not only rewriting your code but also all your types.
You then go jumping from interface to interface in a caffeine-induced trance, ripping out and replacing your type scaffolding to use a cellRenderer function to call the value of a field, instead of using nested path strings.
Also it is far better while reading, even using python i do use type notations. Since i have few braincells i will forget about it next day so i want to quickly see what that func will get and return
What i hate in TS is the ability to assign many types in something. Something can be an array or an object or an attack helicopter. Then you have to check which one is it. This is what feels like a prison of my own design 😅
Where let's say in C# you have to be more robust with your types. And if something should be able to get two different things potentially make a function overload or something along those lines.
You can use eslint to disallow union types in your code if you prefer. That said creating a type that can be almost anything is just bad design and I’d reject a PR if I saw that.
What I will say is that it’s much easier to write bad code in typescript compared to c#.
This is one of many reasons why I love Java
I just hate the aesthetic.
Personally I think it comes from being used to Javascript as kinda loosey goosey. Suddenly you can't just let it infer everything.
editing this because apparently people don't understand my comment is referring the "people who complain about typing" in the previous comment. I'm saying they may have started out with js before moving to ts and they have to adjust how they do things.
I'm not complaining about typescript, I love it as the meme says.
"Inferring" is all TypeScript behind the scenes. Back in the day... You had to guess it. The editor wasn't telling you shit. You were lucky if it knew the methods for global objects. People who complain about it never lived without TypeScript in the first place.
Yeah I mean that’s how things break in production haha
Typescript is really just better JavaScript. I originally was opposed to TS when I switched over from JS but that was because I used to be a way worse software engineer than I am now lol
And that means you’re a bad programmer :) no offense, maybe you’re just very junior, and that’s totally fine. But anyone who was ever done serious work on a large code base knows that typing is essential.
I mean that’s kind of what OP is saying. I think you misinterpreted.
I wasn't even talking about me. I'm talking about people who start with Javascript and move on to typescript and it's different. Try not to be so rude.
Apologies for being rude, I didn’t mean to. But I do want to forcefully reiterate: it is my strongly held opinion that if you don’t see a big difference between typescript and JavaScript, and “kinda prefer the latter”, then you know nothing about software engineering (maybe simply due to being junior, but still)
Man I'm glad I dont care about the opinions of internet strangers
Yeah that's why you posted this here right?
Because you don't care about people's opinions on the post.
good!
I don’t disagree with your concepts. I just like to have no build.
What percentage of your day is spent waiting for Typescript to build? I hear this complaint all the time, but I write Typescript instead of Javascript every time, and I spend less than 5 seconds out of every 10 coding hours waiting for Typescript builds.
So what the fuck are you waiting for?
If given the option not to use typescript, I basically always turn it down. JavaScript's typelessness is annoying, but the documentation and stack overflow for typescript is like five times harder to google. And maybe I am bad at writing software because I rely on googling how to do things all day; but it pays the bills, and people are happy with my work.
Yes but the mistakes you make with typescript still requires you to understand the language you are writing in.
I can't the number of times people think that typing a string as a number converts it under the hood. It really bothers me that people think that because they know typescript they'll make less mistakes... they just make different mistakes.
Plus in the codebase I'm working on we are under the tyranny of any.
Personally I prefer to just turn off TS and just knock out the code but the untangling of TS errors is a larger headache. I had some issues last week where typescript couldn't understand an array I was spreading into a knex.where() and I defined it as only 2 or 3 items in the array and keeps saying the types were wrong.
A side effect of my team getting on TS is people stopped attaching debuggers to the node-server because no one really wants to learn how the node args map to to these layers of developer tools... or develop inside a docker container to debug a cloud environment :\
That’s because typescript is not a great solution. It’s a bandaid around JavaScript. The industry needs to move to typed languages from the beginning (hot take but I love dart and flutter web has a lot of promise if Google actually did something with it)
Share your array issue cause it seems like something that should be no issue
I would for now it's got a spicy
@ts-ignore.The block was just like
const query = knex('table').select({...}); const wheres = []; if (primaryKey) { wheres.push([{ id: primaryKey }]); } if (status) { wheres.push([{ status }]); } else { wheres.push(['status', '!=' 'hidden']); } if (wheres.length > 0) { wheres.forEach((where, i) => { query[i === 0 ? 'where' : 'andWhere'](...where); }); }The forEach is very cranky. I worked with Chat-GPT with minimal code samples and couldn't figure it out. It ended up with the same error even when I give an explict type.For now I'm chaulking it up to not being able to upgrade TS in our codebase but I imagine this would have been frustrating to deal with before it was updated... I just ignored and moved on.
First thing that stands out is that your array is going to be typed as an empty tuple, so pushing values i to it wont work as expected.
Ya I made a Type that reflected exactly that went into it.
As it is it doesn't run the forEach block. Either way wasn't worth spending the time to fix it.. I did TDD on it even with empty array and no problems. Just a false positive.
Typing a string as a number will atleast throw an error immediately instead of unexpected behaviour... which is entirely the point.
No Like people think using ` as ` is the same as parseInt/parseFloat
Everytime I point this out I have to have a conversation about how typescript only protects the buildtime.. not he runtime.
Oh yeah okay i can see how that could come up, though doesnt TS complain about no type overlap and require casting through unknown?
I'm not sure.
As a consultant I'm honestly horrified everytime I join a team and I see ` as number` spammed thinking its syntax magic really bothers me.
Other times I got people discouraging instance of checks not understanding that instanceof is a better test than trusting TS.
Because their online course didn't teach them