Sure, just spend 5x more time creating complex type definitions and then having to edit them on every tiny change in functionality, only to realize it's just tacked-on complexity that provides zero real type safety because it's still just javascript and you still have to validate all your inputs anyway. Then you go to debug your garbled mess and you don't have the real source, you have a transpiled monstrosity where line numbers don't line up half the time. Yay!
@@laztheripperIt doesn't take 5x as long, that's a huge exaggeration. And it's far less time than the amount of time saved from bugs. And as long as you generate source maps, the line numbers always line up. And you have to check types on the input, but only external input, and that's far less points of contact.
Isn't that the point though? That the lines often *don't* line up, among the other things I mentioned. Points of contact, come on, you're on the side of adding an entire compiler that analyzes every line of code and shuffles it around to a point where the source resembles in no way the output, and requires all of the type defs in the source itself. Seems like those exceed points of contact, they're welded together. Edit: If you really need your language to tell you how to do things, go ahead, but even then you have JSDoc which has none of the disadvantages and all of the (supposed) benefits. That said, would be nice if IDE's would be smarter, not the languages. If you coerce something to string, the IDE should be able to say "this is a string" and therefore know some very basic things about how it can be used. @@shockthetoast
Big advantage of TypeScript is when you're starting to work with a new codebase, it's super easy to follow the chain of types back to the exact definition, and see what arguments are being passed to a function and how to access a parameter you need. And you're less likely to break unfamiliar code because it'll become very obvious if you don't know what you're doing.
@klisgiarc"you see actually self documenting code that requires small amounts of extra work is actually bad what you actually should do is just memorise everything and know everything by heart" that's how you sound you have no argument so you make bs
@@RichardRemer buddy, I have so little formal training that if you're drawing conclusions about "TS people" from anything I said, you're the one going wrong. 🤷♂️
@@RichardRemer you're right, but the result is the opposite of the point you seem to be trying to make. (i.e., your personal experience is valid but limited, so you can't speak more broadly than that without real data)
I don't use type script but I have used python, java, and javascript. I don't know if its mainly because I dealing with JSON but I don't seem to be running into any bugs rn. Probably jinxed myself.
@@sggbuffistrash3445 Wait until you scale a product to having a main website, a user admin portal, an iOS/android app, all communicating with the same backend, without any types or type hinting between the backend and frontend. A strongly typed OpenAPI/Swagger generated API client is a GODSEND.
I think that's just called the beauty of Open Source. You don't like how things are done? Fork it. I think the same can be said with C and its derivatives.
@@nukebarbarbarian3735The only language invented to fix Java was Kotlin, the rest are standalone languages that simply take advantage of the Java Virtual Machine as a compilation target. By contrast, every language made to fix JavaScript compiles to it and it alone. Try again
I refuse to believe that anyone who isn’t either extremely high level or has never even written an even mid sized application actually thinks that dynamic typing is better. It’s a nightmare and my literal least favorite thing in language design
Depends on application type. Our team did a few large projects in PlayCanvas which uses vanilla JS to create custom script components. The key is to isolate each script as much as possible and pass data between them via centralized store and events.
Same, only I started with python 4 years ago. Then a year ago I started to learn C++ and other languages. And I also realized how useful static typing is.
yeah i had to do a course in julia and it was insane how i could change basically nothing and very quickly julia would decide if my vector was going to become a matrix of functions
@@StinkyCatFartsgenuinely this is such a dumb way to think. Like I guess if you're just doing small individual projects, but as soon as you're collaborating, you'll appreciate typing
@@evanbelcher I work with strongly typed and dynamic typed languages. It literally makes zero difference to me as a software engineer. If your only worry is pushing code to prod where your code breaks with a malformed type, you clearly have no business being in the craft. Learn how to use unit testing properly, have proper code reviews, implement a robust DTAP work flow. And for god sakes read the fucking documentation.
It was there since TS was not even a thing. Then MS created TS to temporarily patch this void till ecma comitee finally put it into JavaScript. Almost 12 years later, they still have not a lot of progress with that.
It think it's only time since most developers will argue that typing their code in a collaborative settings helps even thought they have to write more code. Take python as an example. It's not perfect, but their typing support has matured over the years and there's so many new tools built around it now it's became natural to type everything there.
The real solution is to replace JavaScript with a language actually meant for writing complex apps. Even the language creator has said it was never meant for the things we use it for.
In most cases, the time spent getting your code to pass typing constraints pre-compilation is way less than the time spent debugging code that wouldn’t have had a bug if it had been strongly typed. The problem with TypeScript to me is that you can’t do what you need to do sometimes because of silly constraints that don’t help. It’s weird sometimes. I’m truly hoping that one day I can write everything in Go and compile to WASM
Yeah that's exactly right. Honestly in my opinion, the biggest problem with Typescript isn't the types, it's the Javascript. JS is just a poorly designed language with a tiny stdlib and all sorts of issues and annoyances.
Sometimes u need dynamically typed languages. Theres a reason no frameworks like laravel or nextjs or something similar exist in rust and is actually used
I have reasonable large projects in JS, it's just a matter of making all obvious so types are not needed (in the specific case of web TS vs JS, of course in general I prefer types)
@@neko6 and debugging in 100 times the time, 10 times more often. dynamic types don't promote a maintainable code base. It attract rookies like rotten meat the flies. It favours poorly designed code that will fail in prod, costing a lot in the most unpredictable ways at the worse possible times. If you're a contractor and never deal with prod then, well... thug life.
i use js for like 2 years until i knew about ts, and i absolutely loved it. i felt intimidated at first but its really nice. especially to be able to define the object returned from a function and get the autocompletion from that object felt really really good.
My productivity, debugging skills and the maintenance have greatly improved once I started using type hints in python, now everytime I write code, type hints are by default part of the code and I cannot skip them however hard it's get. Often times, if something is becoming harder to type hint, that's when I know that it's time to simplify the code
I honestly feel like types get you into the flow state way way better. Because you would be thinking about your code in types to get the thought training going and then actually program it with those types
@@MasayaShida This is what I don't get. With TypeScript, the types are already defined. By creating your variables, you've done the entire work of documenting what a variable/function/object field should even receive as a value. But with JSDocs, you have to _manually_ describe every parameter, of every function, in every file, in every npm package. On top of that, if the parameters change what type they are supposed to accept, you must update the JSDoc AGAIN. You're telling me that _that_ is easier than simply typing all your symbols???
@@jonathanalonso6492his argument is more for svelte core library teams tho... when someone find bugs on that, theres more than often he cannot replicate that bug in his system, as the they have different config... and as you know, enforcing single ts config in library as big as svelte core is just not possible(we are talking hundreds of people with each different taste to program js here)... so yeah... jsdoc is the way to go in this particullar case...
Using types allows to do a lot of checks on the correct use of interfaces statically. This reduces the number of errors in the code and the number of tests to write to check whether your code is correct. Also you read way more often your code than you write it. Thus, writing a little bit more code is not the issue. Still you should do TDD as in design, write tests, write module, check the module.
Like as someone who honestly doesn't mind Ruby as far as dynamic languages go (and hasn't used Rails at all yet), I can't stand most of what DHH says. Dude is an insufferable tool online, and I don't like how intertwined he is with the Ruby web dev ecosystem, and it's one of the things that actively kept me from a rather nice language. It jsut seems like he's constantly trying to stay controversial just to try and keep Rails relevant in an era of a million other web frameworks saturating that market. He acts like systems programming is the devil I stg lol. I hold many other people's opinions higher than his, as much as he contributed to both the web dev and Ruby ecosystems. Hate typing all you want, but removing the option of typing from a platform just out of spite is a move in line with him.
@@MrGriefCreep types are great, but TS types are another beast altogether. If you just write apps, it's fine and dandy and you can type everything pretty easily, but it's insufferable when you write a lib, especially if it's a large one.
Considering my experience, all flaws that are caused static types you can fix(except boilerplate code but it's not that big of a deal), but ones that is caused by dynamic are unfixable
I recently worked on a project using plain JS with JSDoc (i was instructing a class and didn’t wanna deal with module bundlers), and lemme tell ya JSDoc is no replacement for typescript. There’s still so many dumb mistakes you can make without it, it’s not worth it.
@@okie9025 /** @import { Foo } from "another-file" */ /** * @template {string} [T = "Hello world"] * @typedef {{bar: Foo }} Bar */ This is the equivalent of: import type { Foo } from "another-file" export type Bar = { bar: Foo }
When ur project gets bigger, TS is a time saver. Just keep it very simple and don't try to make it to generics. Otherwise, it will be very hard to modify it later, especially generic classes.
you just debug more at compile time, and wait till you end up having to change your code and types later, its a huge pain. also its more to look at and makes the codebase harder to read
I wish people would not focus on the “write” part. Most IDEs can easily spew just about any amount of repetitive drivel with a few clicks. The issue is READING the extra repetitive drivel. Some (most) love the safety net, but for some (albeit a minority) of us, it slows down the process of “binary searching” the code to find the part causing today’s problem. At least TS has the decency to put the type noise AFTER the identifier (so you can skim the left margin for names), rather than crowding names off to the right, so it doesn’t suck as much as reading Java.
Typescript is what javascript should have been. Either way its high time browser start adopt a new type of scripting language other than javascript. I'll put my money on c#
Types, it does slow downs the development, but its better to spend a few hours one day trying to figure out the right types than dealing with production app crashes bc you didn’t have the warnings.
Modern programmers are extremely lazy And it’s resulting in both bad code and bad languages. It feel like EVERYTHING nowadays has to be optimized for a quick tutorial turnover. Who cares about “boilerplate” in actual real world applications? It’s only annoying if you’re churning through tutorials and i think that’s were we find the reason for most of this nonsense
With large loops, languages that allow no type variables like python can be painfully slower than using types. That's because the runtime checks the type of each variable at every iteration. Which can accumulate to exteremely long periods of time, especially when dealing with large amounts of data and variables.
Python does not check the type of a variable on each loop. Python's type checking -- just like every duck-typing language do -- happens when an attribute is invoked. Python's slow loop is because it's basically a heavy protocol that invokes an object's iterator repeatedly until the object returns with a StopIteration.
"Types or no types?" Optional types. It would be like TS, but in reverse: it's dynamic by default, but when you want the variable to be only of the specific type - you explicitly state it. I think there's a proposal for that in the new ECMAscript version, but I might be wrong.
You described TypeScript. Also the proposal is not about adding types to ECMAScript, but to add comment labels after declarations, in the form of `: `. The runtime only sees them as comments, and ignores them, whereas tools can use the comments to do static analysis and can skip elimination steps during transpilation.
Doesn't TS automatically infer the type of the variable by default based on the first value it was assigned ? That should skip most type definitions. But, I think for the compiler to be more OP, having a defined type interface will be faster than what TS initially infered
The number of people that upvoted this shows that one of the problems with TypeScript is that it’s simply not fully understood by the average JS developer what TypeScript does for you. You can set in the compiler rules to not warn on “implicit any”. Which means that it will say nothing if you don’t set types, and if it can’t automatically figure out the types it will just assume it’s type “any” and get out of your way. You can really configure TypeScript to be what you need when you need it.
but that's literally useless in the long run. If you can type some parts of your code, but not others, you literally gain no benefit from types. Types should be mandatory, and there should be no way to opt-out of types like using "any". TS inferences are more than enough of a shortcut for writing types, but it's really not that difficult when you need to write types.
I can't believe that the developers would prefer dealing with all the javascript error bs than the extra typing that you do in TS. Just shows some developers are truly lazy.
It's not about extra typing, it's about how badly TypeScript integrates with pretty much everything in the JS ecosystem. After other strongly typed languages like Java or Rust, TypeScript often feels like a half-baked temporary fix for a problem. It can cause a lot of trouble on big projects, especially if they consist of multiple packages. And the fact it can be really slow on big codebases (both compiler and language server) doesn't help it either.
I wrote a lot of JS and TS, and from my experience, writing TS boilerplate is more time consuming, than fixing bugs coming from wrong types. I'm gonna try hybrid approach, since I still find useful, script that queries through backend endpoints and returns schemas, that I can use as type after fetched data. Then, when backend devs change some schema, for example: id: number; emplyeeId: number; into id: number; employeeIds: number[]; new schema (and type on frontend) will be generated, and every frontend place that uses this data, IDE will show me, where this backend change will break my frontend code. But besides frontend backend schema communication, types on frontend takes more effort than gives value, IMO, and I'm thinking about dropping Typescript.
Code is primarily a form of communication between humans, with machines still requiring translation to binary. Essentially, coders describe system specifications using a language that should be unambiguous, both for other humans and machines. Types play a crucial role in providing an additional layer of detail and clarity. Use types if the code isn’t disposable, especially if others are expected to read or maintain it.
I use mainly C++ so I use types all the time and not a single time have I ever said to myself "I can't focus on my code because of all this boiler plate stuff." I just code and don't worry about "optimizing efficacy" and all that crap. I'm trying to write good code, not bad code faster.
I've done large projects in both JS and TS and I absolutely never want to touch or refactor anything in those JS projects because I could easily break something without knowing
Traffic lights are called “go lights” for a reason. When we are cycling perhaps lights don’t matter but soon as we’re in the highway with all cars going at 100-120km/h, the lanes matter. If the traffic lights aren’t there in a busy junction in the evening forget about going home for dinner on time. Typescript is a productivity improvement tool just like the lanes and traffic lights on the road. Simple.
i like the comparison because of course if there's barely any use for this *crossroads*, you don't need *traffic lights*, things can kind of just sort themselves out and it will be faster too it's just that in big things where it matters, you need to cover your ass
The cool thing about typescript is that it can infer types, so you don’t have to actually write them all the time, just write your javascript javascript and then infer their return types to use elsewhere
I’ve been working on a project without TS for a while now, and I dropped TS due to having a tight deadline so I wanted to get the job done faster. I learned about the importance of types the hard way when I had several bugs that took me literally hours to solve each; these bugs and many more could’ve been avoided if I had TS enforce typing.
The hard thing about typescript is all the extra stuff. ts-node, ts-jest, resolvers, transpiling some node_modules and not others. mjs, cjs, compiling libraries. Holy crap. Typescript itself, as a language, is fantastic
I like types better. I find it makes the code a lot more legible and understandable. I find dynamics can get the job done for smaller stuff, but that's also just because it's harder to introduce a bug into a smaller codebase (in my experience at least)
Correction: typescript doesn't add static types to javascript, it adds glorified IDE type hints I prefer using jsdoc comments and "//@ts-check", it gives 95% of the benefits of TS without all the hassle And on critical parts of the system where types shine, I just use Go
Thank you, well said. My IDE is really good at type inference, but sometimes I have to load JSON from “elsewhere”, so I have an accessor with a JSDoc about the return data, and I’m back on track. There’s something to be said for working on an MVP app with about 10,000 lines of Express and Vue (“data driven”) code and another 3,000 lines or so of JSON metadata, and being able to restart the app in under 1/5 second. I try to stay more FP, and less OOP when I can, though.
why on earth do people act like Java is state of the art when it comes to typed languages when it couldn't be further from the truth. The cluelessness honestly grinds my gears a bit
I learnt to program in java, some time ago I decided to give it a try to JS but I find it so messy cause you can't define types, I hate it, but there are still things I have to learn before I jump to Typescript, hopefully it will make me feel more comfortable when working on the frontend
@@kfizzle3920 Types only exist in computers. Soon there'll be human to computer interpreters, functioning full with human language, and all of you will drop types
So people want to spend their 5-6 hours extra time for removing bugs in their code using JavaScript but do not want to spend 2 minutes extra per file on giving types and writing extra code that saves them from bugs in Typescript 😒😒.... I dont know why but humans seem even more fascinating now.
Can you explain that? As someone comming from the low level languages (c, c++). I pretty much find types necessary to know what is going on during debugging. They get more important as your problem complexity increases. So I'm curious why someone would like dynamic languages, maybe there is a perfectly valid reason I don't know yet
@marsimplodation Here in 2023, programmers all use an IDE. You can examine variables while coding and during debugging, with lots of rich information (including types). For web programming, algorithms (and sometimes data structures) are way more important for performance than whether a number is an int32 or int16. Heck, numbers are serialized out of strings in lots of use cases. The runtime value is much more important than the type. The problem with TypeScript is twofold: First, it adds a LOT of boilerplate code, which doesn't come free. It costs dev time to write and to maintain, and it takes me out of the important coding tasks. A good shortcut for cognitive load on a new piece of code is SLOC, and TypeScript can easily double the size of my PR. The extra code is more to think about and to maintain, meaning that I'm actually introducing risk (as all new code does, which is why web programmers strive for brevity when possible). And, in my opinion, that additional risk more than counterbalances the couple times that TypeScript has saved me from accidentally assuming the wrong type for a variable (which, TBH, I would have caught while testing my code or running unit tests). Second, TypeScript actually messes up the IDE! So here we are, trying to save ourselves from bugs by offering type assurance. In the meantime, the IDE, which can _actually_ save us, now has trouble showing and linking to variable and function usages. This makes it _harder_ to prevent bugs, not easier, since it's harder to follow logic chains and function/class hierarchies while reasoning about a block of code, esp when that code stretches across files. To top it all off, I now have close to double the files to track, adding additional cognitive load and additional chances for Git merges to have issues, causing me actual dev time. In our Python code bases, we actually have _less_ bugs, and I attribute that, in great part, to the decreased cognitive load and smaller footprint. Sorry for the long message. I guess you hit a nerve. 😆
Jeez I always try to be type-safe but if in some certain specific situations is really too hard and the type-safety issue is encapsulated you CAN go with "any".
Types are not just for you, it's for people who never seen your codebase so they can quickly pickup what's the object type and make modifications immediately.
@@SnazzieTV Why the fuck are you exposing people to a code base without any documentation. Every excuse I hear is from people who are Node script kiddies lmao.
When I finally converted to TS after 6 years of JS (its been 2-3 yrs since) I finally understand why types are so important when I find myself back in the JS wild west
"the soul of JavaScript" ah yes I love it when my website prints out "NaN" or "you are undefined years old" on the front page because of a simple type error.
Try a real language that isn’t Python or JavaScript, give typescript a week try to make a simple iPhone app try to make a simple 2d game in unity or something. You will understand that for anything more complicated then putting text inside of an html file types save you time even if you don’t need to work with anyone. The main selling point is how easier it becomes to use third party libraries.
@@PanosPitsi to be fair, it's not an issue with modern state of js libraries. Most of the popular (and even not so popular) ones today are either typed via @types/* package, provide their own d.ts definitions, or written in TS from the very beginning. Libraries without type definitions are usually ones which stayed there without maintenance for 5+ years, and you probably should think twice before using such outdated solutions.
if you use unknown instead of any, many IDEs will require you to check if the given variable is in fact what you want. EG: try {} catch(err: unknown) { console.error(err.message) } here you should get a hint, that err has no message, therefore you have to check which kind of instance it is (if(err instanceof Error)). Feels still bad, but is better than "any" since you are forced to be sure. usage of "any" is just an excuse of own laziness.
Downside to types is flexibility. I had a plug-in that expired and another new plug-in wich is the same as the old one but it's objects are not the same type. Migrating plug-ins wich is non editable since it's reference plug-in makes it hard to use existing code from the old plug-in if types are enforced.so yeah my solution was to use any as my type and create a wrapper to handle both plug-ins at the same time. Force to use any since it can come from either old or new plug-in object.
personally i felt the issue is while trying to use some 3rd party libraries typescript is very difficult to integrate and throws lots of errors and requires some refactoring
Dynamic typing sucks specially if you need to use a library you didn't write. I remember writing x=10056734567 (or some such) and it was working for weeks until one time when it stopped. I had a hard time debugging out why. Until I realized that I should have used x="10056734567" Apparently one part of the library silently converts x to a string while another part does not. I am not going to say which well known library this is bec there remains the possibility that I may be mistaken here. But I find languages with dynamic typing or which describes types in terms of objects very difficult to use.
I started my career in vb3, which was an untyped language in that, anything not declared as a specific type was created as a variant (essentially the same as 'any'). This caused any number of bugs at runtime when variable types would clash or values got put into a new variable that was created on the fly due to a misspelling. It led to having compiler options to force explicit variable declarations and strict typing. Sounds familiar? Seems JavaScript didn't learn VBs lessons from 30 years ago...
Their is to different things 1=> TS used in production apps 2=> TS used in libraries its hard af you have to do so much mambo jambo for little to no reason.
What as a 3rd year undergrad I don't get is why we moved from languages like c++ to javascript in first place. It had types to begin with and we went full circle.🤔🤔
there are a lot of people who aren't smart enough to use these languages. The top level for them is to use JS. In the worst cases they even complain about TS.
C++ is kind of a death trap - I know the type, IF that’s what’s still at this address. Compared to the Pascal stuff we learned in the early 80s in college before switching to C. There would only be one or a few languages if there were not trade offs.
Hot take: flow state is just that boiling point when the caffeine overcomes tiredness. You're not actually more productive, just racing through minor movements faster. It Feels great, but it's measurably and realistically not any more productive than just sitting down and doing the work.
The bigger thing for me personally is that typescript, at least not with tsc, is not checking your types at runtime nor is it *actually* "compiling" your code, so it doesn't have nearly the understanding a compiler would have of how a type is being used. It being a glorified linter that you have to spend so much time pandering to (e.g. because a library dev defined a strict type for a country code or something that `string` now has "no overlap with") really pushed me to learn other languages (in my case specifically Java and Gleam).
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
"What's your type?"
"data: any"
🤣🤣🤣🤣
This woke af
😂😂😂
BigInt
"@typescript-eslint/no-explicit-any": ["error"]
Handling types isn't as time consuming as debugging your code for type-related issues.
Anyone complaining that type related boilerplate is tedious hasn't spent 2 days looking for a type related bug.
If you have type related issues then you need to learn how to architect your code better.
Sure, just spend 5x more time creating complex type definitions and then having to edit them on every tiny change in functionality, only to realize it's just tacked-on complexity that provides zero real type safety because it's still just javascript and you still have to validate all your inputs anyway. Then you go to debug your garbled mess and you don't have the real source, you have a transpiled monstrosity where line numbers don't line up half the time. Yay!
@@laztheripperIt doesn't take 5x as long, that's a huge exaggeration. And it's far less time than the amount of time saved from bugs. And as long as you generate source maps, the line numbers always line up. And you have to check types on the input, but only external input, and that's far less points of contact.
Isn't that the point though? That the lines often *don't* line up, among the other things I mentioned. Points of contact, come on, you're on the side of adding an entire compiler that analyzes every line of code and shuffles it around to a point where the source resembles in no way the output, and requires all of the type defs in the source itself. Seems like those exceed points of contact, they're welded together.
Edit: If you really need your language to tell you how to do things, go ahead, but even then you have JSDoc which has none of the disadvantages and all of the (supposed) benefits.
That said, would be nice if IDE's would be smarter, not the languages. If you coerce something to string, the IDE should be able to say "this is a string" and therefore know some very basic things about how it can be used. @@shockthetoast
Big advantage of TypeScript is when you're starting to work with a new codebase, it's super easy to follow the chain of types back to the exact definition, and see what arguments are being passed to a function and how to access a parameter you need. And you're less likely to break unfamiliar code because it'll become very obvious if you don't know what you're doing.
Spoken like someone that hasn't worked on any significant size project.
@klisgiarc"you see actually self documenting code that requires small amounts of extra work is actually bad what you actually should do is just memorise everything and know everything by heart" that's how you sound you have no argument so you make bs
@@RichardRemer buddy, I have so little formal training that if you're drawing conclusions about "TS people" from anything I said, you're the one going wrong. 🤷♂️
@@RichardRemer publish your research, let's see the data. 🙂
@@RichardRemer you're right, but the result is the opposite of the point you seem to be trying to make. (i.e., your personal experience is valid but limited, so you can't speak more broadly than that without real data)
Abandoning TypeScript to save time is like deciding to stop wiping your ass because it’s takes precious time and your ass will just get dirty again.
😂😂😂
bro wtf 😂😂😂😂
I don't use type script but I have used python, java, and javascript. I don't know if its mainly because I dealing with JSON but I don't seem to be running into any bugs rn. Probably jinxed myself.
@@sggbuffistrash3445 Wait until you scale a product to having a main website, a user admin portal, an iOS/android app, all communicating with the same backend, without any types or type hinting between the backend and frontend. A strongly typed OpenAPI/Swagger generated API client is a GODSEND.
😂😂😂
I'm always amazed by how many languages were invented just to fix javascript. Failure has never been so inspiring!
Well you'll be surprised to know how many languages were invented just to fix Java 😂😂
I think that's just called the beauty of Open Source. You don't like how things are done? Fork it. I think the same can be said with C and its derivatives.
@@nukebarbarbarian3735The only language invented to fix Java was Kotlin, the rest are standalone languages that simply take advantage of the Java Virtual Machine as a compilation target. By contrast, every language made to fix JavaScript compiles to it and it alone. Try again
@@nukebarbarbarian3735 java’s not a broken language, it just needed to be improved
I’ve moved to c#/blazor … tired of this JavaScript bs
I refuse to believe that anyone who isn’t either extremely high level or has never even written an even mid sized application actually thinks that dynamic typing is better. It’s a nightmare and my literal least favorite thing in language design
Depends on application type. Our team did a few large projects in PlayCanvas which uses vanilla JS to create custom script components. The key is to isolate each script as much as possible and pass data between them via centralized store and events.
I've been a JavaScript dev and types aren't needed with modern IDE
@@troooooper100 show me your code
@@troooooper100with a modern IDE that ….. infers types? 😂
@@troooooper100How does having a modern IDE help???
I came from C and Kotlin when I started with JS... at this moment I understood how valuable static typing is.
Same, only I started with python 4 years ago. Then a year ago I started to learn C++ and other languages. And I also realized how useful static typing is.
yeah i had to do a course in julia and it was insane how i could change basically nothing and very quickly julia would decide if my vector was going to become a matrix of functions
@@pyp2205 Types weren’t the problem, you were just bad a coding lol.
@@StinkyCatFartsgenuinely this is such a dumb way to think. Like I guess if you're just doing small individual projects, but as soon as you're collaborating, you'll appreciate typing
@@evanbelcher I work with strongly typed and dynamic typed languages. It literally makes zero difference to me as a software engineer. If your only worry is pushing code to prod where your code breaks with a malformed type, you clearly have no business being in the craft. Learn how to use unit testing properly, have proper code reviews, implement a robust DTAP work flow. And for god sakes read the fucking documentation.
That's why I'm hoping that JS eventually integrates native types. Pretty sure there's a proposal for it already
It was there since TS was not even a thing. Then MS created TS to temporarily patch this void till ecma comitee finally put it into JavaScript. Almost 12 years later, they still have not a lot of progress with that.
@@mikumikuareka Yeah, not expecting it anytime soon myself.
True but it's going to take time for all browser's to adopt it 😢.
There’s a proposal I guess, maybe by 2055 we have them
It think it's only time since most developers will argue that typing their code in a collaborative settings helps even thought they have to write more code.
Take python as an example. It's not perfect, but their typing support has matured over the years and there's so many new tools built around it now it's became natural to type everything there.
The real solution is to replace JavaScript with a language actually meant for writing complex apps. Even the language creator has said it was never meant for the things we use it for.
imo static typing is the only way to go. even in languages that have inferred typing, i always opt to be explicit
having static typing also makes code much more legible. Yeah, there's more boilerplate and it's more verbose, but that's not always a bad thing
type system is really crucial for mid - big size project
Data: any hides in my closet at night and haunts me while I sleep.
I feel that writing the types also helps us to understand what we are doing
Typing your code really forces you to focus on what you’re actually writing. I love it.
In most cases, the time spent getting your code to pass typing constraints pre-compilation is way less than the time spent debugging code that wouldn’t have had a bug if it had been strongly typed. The problem with TypeScript to me is that you can’t do what you need to do sometimes because of silly constraints that don’t help. It’s weird sometimes. I’m truly hoping that one day I can write everything in Go and compile to WASM
Yeah that's exactly right. Honestly in my opinion, the biggest problem with Typescript isn't the types, it's the Javascript. JS is just a poorly designed language with a tiny stdlib and all sorts of issues and annoyances.
hoping for the same but Rust
Types or no types - I'm going with Rust.
😂😂😂
It is way more satisfying too.
Sometimes u need dynamically typed languages. Theres a reason no frameworks like laravel or nextjs or something similar exist in rust and is actually used
@@echoptic775you can make everything and more with statically typed languages as you can with dynamically typed.
How’s your flow state working out with that?
I'm going with Hindley-Milner type inference (HMTI). You can just declare some with types and the rest are automatically inferred for you.
once you start typescript, there is no going back. It is a must for large projects.
not really, but okay
Just don't have large projects lmao
I have reasonable large projects in JS, it's just a matter of making all obvious so types are not needed (in the specific case of web TS vs JS, of course in general I prefer types)
I think it's desirable, but definitely not a must
the ones that hates Types are the starters but when you get more into the programming world types are mandatory
Laughs in void*
@@12345damnthetorpedoes public void
Not necessarily. I started with Java and learned to love JS much later for letting me get things working in 1/10th of the time
@@12345damnthetorpedoesType punning is Undefined Behaviour, so make of that what you will
@@neko6 and debugging in 100 times the time, 10 times more often. dynamic types don't promote a maintainable code base. It attract rookies like rotten meat the flies. It favours poorly designed code that will fail in prod, costing a lot in the most unpredictable ways at the worse possible times. If you're a contractor and never deal with prod then, well... thug life.
i use js for like 2 years until i knew about ts, and i absolutely loved it.
i felt intimidated at first but its really nice. especially to be able to define the object returned from a function and get the autocompletion from that object felt really really good.
🎶I ain't got no type...
...bad code is the only thing that I write!🎶
😂😂😂
music.ruclips.net/video/wzMrK-aGCug/видео.html&si=Lc5NF3BbFm9vGwPw
My productivity, debugging skills and the maintenance have greatly improved once I started using type hints in python, now everytime I write code, type hints are by default part of the code and I cannot skip them however hard it's get. Often times, if something is becoming harder to type hint, that's when I know that it's time to simplify the code
Also, `Protocol` is simply great!
Compile C# to JS and everything will be fine ;)
this is disgusting
WASM is far better for this, which is already done with C# and also other languages. It has much better performance than JS.
I honestly feel like types get you into the flow state way way better. Because you would be thinking about your code in types to get the thought training going and then actually program it with those types
It all actually started when Richard Harris dropped TS from Svelte
He dropped typescript but kept types via JSDoc. Svelte/kit is still typechecked
Just to clarify for anyone reading his. Svelte team dropped TS but still uses types with JS doc
@@MasayaShida yep 👍🏼 thanks for making that more clear 😁
@@MasayaShida This is what I don't get.
With TypeScript, the types are already defined. By creating your variables, you've done the entire work of documenting what a variable/function/object field should even receive as a value.
But with JSDocs, you have to _manually_ describe every parameter, of every function, in every file, in every npm package. On top of that, if the parameters change what type they are supposed to accept, you must update the JSDoc AGAIN.
You're telling me that _that_ is easier than simply typing all your symbols???
@@jonathanalonso6492his argument is more for svelte core library teams tho...
when someone find bugs on that, theres more than often he cannot replicate that bug in his system, as the they have different config...
and as you know, enforcing single ts config in library as big as svelte core is just not possible(we are talking hundreds of people with each different taste to program js here)... so yeah... jsdoc is the way to go in this particullar case...
Using types allows to do a lot of checks on the correct use of interfaces statically. This reduces the number of errors in the code and the number of tests to write to check whether your code is correct. Also you read way more often your code than you write it. Thus, writing a little bit more code is not the issue.
Still you should do TDD as in design, write tests, write module, check the module.
Typescript is the way you notice the Q in "some.long.prop.chqin" when in a hurry and save 15 minutes debugging a random runtime error...
Wow what a surprise that the guy who practically single handedly revived a mostly dead, dynamic language doesn’t like writing types
Like as someone who honestly doesn't mind Ruby as far as dynamic languages go (and hasn't used Rails at all yet), I can't stand most of what DHH says. Dude is an insufferable tool online, and I don't like how intertwined he is with the Ruby web dev ecosystem, and it's one of the things that actively kept me from a rather nice language. It jsut seems like he's constantly trying to stay controversial just to try and keep Rails relevant in an era of a million other web frameworks saturating that market.
He acts like systems programming is the devil I stg lol. I hold many other people's opinions higher than his, as much as he contributed to both the web dev and Ruby ecosystems. Hate typing all you want, but removing the option of typing from a platform just out of spite is a move in line with him.
I am not sure if it was the right or wrong thing to do but i believe the intention is right.
@@MrGriefCreep types are great, but TS types are another beast altogether. If you just write apps, it's fine and dandy and you can type everything pretty easily, but it's insufferable when you write a lib, especially if it's a large one.
Not true. He helped push Ruby, then a new language, into widespread usage, especially for solo devs and new startups.
@@alchemist_one Ruby wasn’t a new language, it had been around for 10 years by the time rails first came along
I think optional types with dynamic as default would be the best
Types for going big, no types for quick jobs
Considering my experience, all flaws that are caused static types you can fix(except boilerplate code but it's not that big of a deal), but ones that is caused by dynamic are unfixable
I recently worked on a project using plain JS with JSDoc (i was instructing a class and didn’t wanna deal with module bundlers), and lemme tell ya JSDoc is no replacement for typescript. There’s still so many dumb mistakes you can make without it, it’s not worth it.
JSDoc is a replacement for typescript, they have 100% feature parity in type checking
@@ex-xg5hh let me see you import an generic interface from another file and define type constraints using jsdoc.
@@okie9025
/** @import { Foo } from "another-file" */
/**
* @template {string} [T = "Hello world"]
* @typedef {{bar: Foo }} Bar
*/
This is the equivalent of:
import type { Foo } from "another-file"
export type Bar = { bar: Foo }
So you don't use @ts-check in the file. TypeScript literally works with JSDoc.
When ur project gets bigger, TS is a time saver. Just keep it very simple and don't try to make it to generics. Otherwise, it will be very hard to modify it later, especially generic classes.
As a Python developer with 5 years of experience: Definitely types
Turbo: its hard to satisfy the typescript compiler!
Rust: *chuckles*
Types. Definitely.
Types: great.
Typescript: awful.
@@sacha9593 the alternatives (jsdoc, flow, etc.) are even worse, so i'll stick to TS.
@@okie9025 The true alternatives are the myriad of natively statically typed languages.
Refusing to use typescript and casting everything as Any on libraries is just peak toxicity
"I have to write more" guys are you serious? If yes, then go ahead debug more
you just debug more at compile time, and wait till you end up having to change your code and types later, its a huge pain. also its more to look at and makes the codebase harder to read
@@Meleeman011 > debug at compile time
This is a heck of oxymoron
@@Meleeman011 ok ok we get it, you’re an amateur.
@@theseriousaccount We get it you don’t do unit testing
I wish people would not focus on the “write” part. Most IDEs can easily spew just about any amount of repetitive drivel with a few clicks.
The issue is READING the extra repetitive drivel. Some (most) love the safety net, but for some (albeit a minority) of us, it slows down the process of “binary searching” the code to find the part causing today’s problem.
At least TS has the decency to put the type noise AFTER the identifier (so you can skim the left margin for names), rather than crowding names off to the right, so it doesn’t suck as much as reading Java.
I like types, it makes code look organized and there is less probability to have bug issues related to types
Typescript is what javascript should have been. Either way its high time browser start adopt a new type of scripting language other than javascript. I'll put my money on c#
Since I started using typescript, I never went back to plain js
Typescript is 100% where it's at. If you don't know, now you know
Tell your browser this
Types, it does slow downs the development, but its better to spend a few hours one day trying to figure out the right types than dealing with production app crashes bc you didn’t have the warnings.
Modern programmers are extremely lazy
And it’s resulting in both bad code and bad languages. It feel like EVERYTHING nowadays has to be optimized for a quick tutorial turnover. Who cares about “boilerplate” in actual real world applications? It’s only annoying if you’re churning through tutorials and i think that’s were we find the reason for most of this nonsense
Let’s import an npm package calling, another npm package, because I’m too lazy to write a simple replace function
With large loops, languages that allow no type variables like python can be painfully slower than using types. That's because the runtime checks the type of each variable at every iteration. Which can accumulate to exteremely long periods of time, especially when dealing with large amounts of data and variables.
Python does not check the type of a variable on each loop. Python's type checking -- just like every duck-typing language do -- happens when an attribute is invoked.
Python's slow loop is because it's basically a heavy protocol that invokes an object's iterator repeatedly until the object returns with a StopIteration.
"Types or no types?"
Optional types. It would be like TS, but in reverse: it's dynamic by default, but when you want the variable to be only of the specific type - you explicitly state it.
I think there's a proposal for that in the new ECMAscript version, but I might be wrong.
This is how TypeScript works. Your unchanged ES is valid TS, until your config forces you to use types.
You described TypeScript. Also the proposal is not about adding types to ECMAScript, but to add comment labels after declarations, in the form of `: `. The runtime only sees them as comments, and ignores them, whereas tools can use the comments to do static analysis and can skip elimination steps during transpilation.
Doesn't TS automatically infer the type of the variable by default based on the first value it was assigned ? That should skip most type definitions. But, I think for the compiler to be more OP, having a defined type interface will be faster than what TS initially infered
The number of people that upvoted this shows that one of the problems with TypeScript is that it’s simply not fully understood by the average JS developer what TypeScript does for you. You can set in the compiler rules to not warn on “implicit any”. Which means that it will say nothing if you don’t set types, and if it can’t automatically figure out the types it will just assume it’s type “any” and get out of your way.
You can really configure TypeScript to be what you need when you need it.
but that's literally useless in the long run. If you can type some parts of your code, but not others, you literally gain no benefit from types. Types should be mandatory, and there should be no way to opt-out of types like using "any". TS inferences are more than enough of a shortcut for writing types, but it's really not that difficult when you need to write types.
Answer is simple. Types, but no ts. Dart on frontend, dart/go/rust/swift/kotlin/c# on the back.
No types = potential bugs. Don’t be lazy.
Depends on the application size. Smaller and even medium codebases will be just fine with javascript.
Making terrible language choices is just what DHH does best
These videos are just getting better! Good job man. Also congratulations on getting married!
I can't believe that the developers would prefer dealing with all the javascript error bs than the extra typing that you do in TS. Just shows some developers are truly lazy.
i shouldn't have to write data schemas for my code. thats what the database is for. you wanna know the properties then jsdoc it
@@Meleeman011 soydev energy
It's not about extra typing, it's about how badly TypeScript integrates with pretty much everything in the JS ecosystem. After other strongly typed languages like Java or Rust, TypeScript often feels like a half-baked temporary fix for a problem. It can cause a lot of trouble on big projects, especially if they consist of multiple packages. And the fact it can be really slow on big codebases (both compiler and language server) doesn't help it either.
You don't have errors in JS (or any language, really) if you have good test coverage
I wrote a lot of JS and TS, and from my experience, writing TS boilerplate is more time consuming, than fixing bugs coming from wrong types.
I'm gonna try hybrid approach, since I still find useful, script that queries through backend endpoints and returns schemas, that I can use as type after fetched data. Then, when backend devs change some schema, for example:
id: number;
emplyeeId: number;
into
id: number;
employeeIds: number[];
new schema (and type on frontend) will be generated, and every frontend place that uses this data, IDE will show me, where this backend change will break my frontend code.
But besides frontend backend schema communication, types on frontend takes more effort than gives value, IMO, and I'm thinking about dropping Typescript.
Code is primarily a form of communication between humans, with machines still requiring translation to binary. Essentially, coders describe system specifications using a language that should be unambiguous, both for other humans and machines. Types play a crucial role in providing an additional layer of detail and clarity.
Use types if the code isn’t disposable, especially if others are expected to read or maintain it.
I use mainly C++ so I use types all the time and not a single time have I ever said to myself "I can't focus on my code because of all this boiler plate stuff." I just code and don't worry about "optimizing efficacy" and all that crap. I'm trying to write good code, not bad code faster.
I've done large projects in both JS and TS and I absolutely never want to touch or refactor anything in those JS projects because I could easily break something without knowing
Traffic lights are called “go lights” for a reason. When we are cycling perhaps lights don’t matter but soon as we’re in the highway with all cars going at 100-120km/h, the lanes matter. If the traffic lights aren’t there in a busy junction in the evening forget about going home for dinner on time. Typescript is a productivity improvement tool just like the lanes and traffic lights on the road. Simple.
i like the comparison because of course if there's barely any use for this *crossroads*, you don't need *traffic lights*, things can kind of just sort themselves out and it will be faster too
it's just that in big things where it matters, you need to cover your ass
The cool thing about typescript is that it can infer types, so you don’t have to actually write them all the time, just write your javascript javascript and then infer their return types to use elsewhere
I’ve been working on a project without TS for a while now, and I dropped TS due to having a tight deadline so I wanted to get the job done faster. I learned about the importance of types the hard way when I had several bugs that took me literally hours to solve each; these bugs and many more could’ve been avoided if I had TS enforce typing.
The hard thing about typescript is all the extra stuff. ts-node, ts-jest, resolvers, transpiling some node_modules and not others. mjs, cjs, compiling libraries. Holy crap.
Typescript itself, as a language, is fantastic
Types or no types?
Types.
Just ditch javascript
I like types better. I find it makes the code a lot more legible and understandable. I find dynamics can get the job done for smaller stuff, but that's also just because it's harder to introduce a bug into a smaller codebase (in my experience at least)
types
JS Docs
I agree. Some people just like creating problems instead of solving them just so they can have an excuse for more work.
Correction: typescript doesn't add static types to javascript, it adds glorified IDE type hints
I prefer using jsdoc comments and "//@ts-check", it gives 95% of the benefits of TS without all the hassle
And on critical parts of the system where types shine, I just use Go
Thank you, well said. My IDE is really good at type inference, but sometimes I have to load JSON from “elsewhere”, so I have an accessor with a JSDoc about the return data, and I’m back on track.
There’s something to be said for working on an MVP app with about 10,000 lines of Express and Vue (“data driven”) code and another 3,000 lines or so of JSON metadata, and being able to restart the app in under 1/5 second.
I try to stay more FP, and less OOP when I can, though.
Devs who don't mind drinking coffee while on debug call at 3am on Christmas eve won't mind dynamic types either. lol
I like how developers are loving this meanwhile they've been hating Java. 😂
Java is a language for adults and the programmers grew up
....typescript has yet to force me into committing Lovecraftian atrocities....like java has.
@@hanro50 yeah yeah, tell it to the factory’s factory.
@@theseriousaccountJava is pretty terrible too
why on earth do people act like Java is state of the art when it comes to typed languages when it couldn't be further from the truth. The cluelessness honestly grinds my gears a bit
First programming language for me was C++ and it was honestly harder for me to unlearn using types than it was to learn to use them
You all seem to have forgotten that TypeScript adds a compilation process which is ridiculously bad for an interpreted language
which is easily solved by using Vite which compiles your code and reloads it in the browser in real time.
What's so bad about needing to compile code exactly? It's worth it for the additional safety.
js is actually JIT compiled iirc
I learnt to program in java, some time ago I decided to give it a try to JS but I find it so messy cause you can't define types, I hate it, but there are still things I have to learn before I jump to Typescript, hopefully it will make me feel more comfortable when working on the frontend
No types (I use vs code btw)
Beginner
Types exist, the difference is if they're in your head or on the page.
@@kfizzle3920 Types only exist in computers. Soon there'll be human to computer interpreters, functioning full with human language, and all of you will drop types
@@greendsnow LMAO sure. Every new language released is literally adapting types. Even "your" python
So people want to spend their 5-6 hours extra time for removing bugs in their code using JavaScript but do not want to spend 2 minutes extra per file on giving types and writing extra code that saves them from bugs in Typescript 😒😒.... I dont know why but humans seem even more fascinating now.
I love type - Ts forever ❤
This should be in every programming 101 class
My vote? No types.
Can you explain that? As someone comming from the low level languages (c, c++). I pretty much find types necessary to know what is going on during debugging. They get more important as your problem complexity increases.
So I'm curious why someone would like dynamic languages, maybe there is a perfectly valid reason I don't know yet
@marsimplodation Here in 2023, programmers all use an IDE. You can examine variables while coding and during debugging, with lots of rich information (including types). For web programming, algorithms (and sometimes data structures) are way more important for performance than whether a number is an int32 or int16. Heck, numbers are serialized out of strings in lots of use cases. The runtime value is much more important than the type.
The problem with TypeScript is twofold:
First, it adds a LOT of boilerplate code, which doesn't come free. It costs dev time to write and to maintain, and it takes me out of the important coding tasks. A good shortcut for cognitive load on a new piece of code is SLOC, and TypeScript can easily double the size of my PR. The extra code is more to think about and to maintain, meaning that I'm actually introducing risk (as all new code does, which is why web programmers strive for brevity when possible). And, in my opinion, that additional risk more than counterbalances the couple times that TypeScript has saved me from accidentally assuming the wrong type for a variable (which, TBH, I would have caught while testing my code or running unit tests).
Second, TypeScript actually messes up the IDE! So here we are, trying to save ourselves from bugs by offering type assurance. In the meantime, the IDE, which can _actually_ save us, now has trouble showing and linking to variable and function usages. This makes it _harder_ to prevent bugs, not easier, since it's harder to follow logic chains and function/class hierarchies while reasoning about a block of code, esp when that code stretches across files.
To top it all off, I now have close to double the files to track, adding additional cognitive load and additional chances for Git merges to have issues, causing me actual dev time. In our Python code bases, we actually have _less_ bugs, and I attribute that, in great part, to the decreased cognitive load and smaller footprint.
Sorry for the long message. I guess you hit a nerve. 😆
Jeez I always try to be type-safe but if in some certain specific situations is really too hard and the type-safety issue is encapsulated you CAN go with "any".
I've been coding for 35 years and have never had a single instance where I needed types.
For real, people are delusional all I’m seeing is bad developers that rush things to production if the lack of typing is causing them problems.
Types are not just for you, it's for people who never seen your codebase so they can quickly pickup what's the object type and make modifications immediately.
@@SnazzieTV Why the fuck are you exposing people to a code base without any documentation. Every excuse I hear is from people who are Node script kiddies lmao.
Sounds to me like you simply had bugs that you didn't know would've been caught by the compiler if you'd used a typed language.
@@alexjeffrey3981 Sounds like you don’t do any unit testing
When I finally converted to TS after 6 years of JS (its been 2-3 yrs since) I finally understand why types are so important when I find myself back in the JS wild west
I prefer dynamic typing, static typing kills the soul of JavaScript.
I'm with you 100%
You love never knowing what type something is? Ok
"the soul of JavaScript" ah yes I love it when my website prints out "NaN" or "you are undefined years old" on the front page because of a simple type error.
@@okie9025 JavaScript is like jazz, it's the notes you don't play.
@@okie9025Typescript prevents divide by 0 errors, or referencing a global which has not yet been initialized? Impressive, if it were true.
Ever for back end developers (Java /C# ) getting started with TS is much easier than going with native JS
no types. types are stupid for solo devs
Exactly
LMAO that's why I had my brain crying after writing a library
@@KrzyZabyou and the op are still beginners and have a lot to learn
Try a real language that isn’t Python or JavaScript, give typescript a week try to make a simple iPhone app try to make a simple 2d game in unity or something. You will understand that for anything more complicated then putting text inside of an html file types save you time even if you don’t need to work with anyone. The main selling point is how easier it becomes to use third party libraries.
@@PanosPitsi to be fair, it's not an issue with modern state of js libraries. Most of the popular (and even not so popular) ones today are either typed via @types/* package, provide their own d.ts definitions, or written in TS from the very beginning. Libraries without type definitions are usually ones which stayed there without maintenance for 5+ years, and you probably should think twice before using such outdated solutions.
Now that copilot is being used so much, it can really shrink down the amount of boilerplate you have to actually type out
After a month i have changed my stance, turbo was written for rails and rails is moving from importmaps. Tge browser doesnt know about types anyway
Depends. If it takes you more time to debug type related issues than actually writing types the you should use ts
It's funny when people say start programming with Javascript 😂😂😂
Have you ever used jsdoc? A very powerful tool to type your js without any compilation
if you use unknown instead of any, many IDEs will require you to check if the given variable is in fact what you want.
EG: try {} catch(err: unknown) { console.error(err.message)
}
here you should get a hint, that err has no message, therefore you have to check which kind of instance it is (if(err instanceof Error)). Feels still bad, but is better than "any" since you are forced to be sure. usage of "any" is just an excuse of own laziness.
Downside to types is flexibility. I had a plug-in that expired and another new plug-in wich is the same as the old one but it's objects are not the same type. Migrating plug-ins wich is non editable since it's reference plug-in makes it hard to use existing code from the old plug-in if types are enforced.so yeah my solution was to use any as my type and create a wrapper to handle both plug-ins at the same time. Force to use any since it can come from either old or new plug-in object.
personally i felt the issue is while trying to use some 3rd party libraries typescript is very difficult to integrate and throws lots of errors and requires some refactoring
Dynamic typing sucks specially if you need to use a library you didn't write. I remember writing x=10056734567 (or some such) and it was working for weeks until one time when it stopped. I had a hard time debugging out why. Until I realized that I should have used x="10056734567" Apparently one part of the library silently converts x to a string while another part does not.
I am not going to say which well known library this is bec there remains the possibility that I may be mistaken here. But I find languages with dynamic typing or which describes types in terms of objects very difficult to use.
Type coercion technically is distinct from merely dynamic types. But, yeah, the type coercion aspect of base JS is a real pitfall.
I started my career in vb3, which was an untyped language in that, anything not declared as a specific type was created as a variant (essentially the same as 'any'). This caused any number of bugs at runtime when variable types would clash or values got put into a new variable that was created on the fly due to a misspelling. It led to having compiler options to force explicit variable declarations and strict typing. Sounds familiar? Seems JavaScript didn't learn VBs lessons from 30 years ago...
Their is to different things
1=> TS used in production apps
2=> TS used in libraries its hard af you have to do so much mambo jambo for little to no reason.
I love type ❤
The complex it gets the more I love.
But I hate any. Hate it more when I have no way other than using any 😢
What as a 3rd year undergrad I don't get is why we moved from languages like c++ to javascript in first place. It had types to begin with and we went full circle.🤔🤔
there are a lot of people who aren't smart enough to use these languages. The top level for them is to use JS. In the worst cases they even complain about TS.
C++ is kind of a death trap - I know the type, IF that’s what’s still at this address. Compared to the Pascal stuff we learned in the early 80s in college before switching to C.
There would only be one or a few languages if there were not trade offs.
If you need types in your JavaScript code, you don't understand JavaScript well enough.
With genAI, writing the boilerplate code will be easier, addressing the issue.
Great typescript video!
I have encountered and fixed so many issues with a codebase I inherited that are easily avoided with typescript. I will never go back.
Hot take: flow state is just that boiling point when the caffeine overcomes tiredness. You're not actually more productive, just racing through minor movements faster. It Feels great, but it's measurably and realistically not any more productive than just sitting down and doing the work.
I prefer typed langs, but for fast prototyping, dynamic ones are just faster to use
Absolutely types. Debugging untyped code is a freaking nightmare.
Good code reviews, competent developers, automated tests, and simple comments can solve this.
The bigger thing for me personally is that typescript, at least not with tsc, is not checking your types at runtime nor is it *actually* "compiling" your code, so it doesn't have nearly the understanding a compiler would have of how a type is being used. It being a glorified linter that you have to spend so much time pandering to (e.g. because a library dev defined a strict type for a country code or something that `string` now has "no overlap with") really pushed me to learn other languages (in my case specifically Java and Gleam).