There's a slight difference between type annotations and Typescript. Many front end frameworks use Typescript for much more than just adding type checking. There's tooling with a huge ecosystem built around TS, there's type inference, there's also optimization and compilation which are necessary to a lot of projects. I don't see how adding type annotations could eliminate the need for all the advantages that TS provides but either way it would be a great improvement to other projects that don't require TS in the first place.
Typescript allows you to use future Javascript in older browsers and allows to use things like JSX. JSX will probably never be in the browser natively because many frameworks compile it in different ways like JSX runtime, SolidJS, InfernoJS
In my opinion they should not implement optional types in Javascript, because it will just make Javascript parsing time slower, they should instead allow to transform the file on the fly so you can use esbuild, flow or any other build tool easily and if you are worried about performance you should use a bundler anyways
@@IronCandyNotes They will not create a new type system but only make JS able to ignore type annotation with some keywords (like interface and type) and with some special syntax (like colon after a variable). This proposal will be based on the typescript syntax, since is the most established solution for JS.
I think this is the way yes. that’s how python did it and frankly as a Java developer coding in python type annotations was really fun it felt like I actually had to care about how I declare my functions.
I work with large corporations and deadlines are a thing. I have never worked in a project with 100% perfect test coverage. When project deadlines are tough, unit tests are the first things to get dropped. The build step has always saved us from someone unintentionally removing/renaming/refactoring something that will only be apparent at runtime.
I think a lot of complaints about TS come from people designing their code like it's still dynamically typed. Like Fireship's code example at 1:53. Why would you make the value parameter in your callback either T or an empty array? And the function either returns void or another function? Union types should be used sparingly because you're introducing a lot of complexity, and now you have check all of those values in runtime
I love TS because once you tell it what type something should be, it will proactively prevent you from making a mistake. These mistakes can cost you hundreds of man-hours if we're coding in untyped JavaScript...
Dynamic types are great for enabling speed at development, it removes a layer of complexity from writing code. The problem with that is when a codebase becomes large enough, refactoring and debugging becomes much more difficult. Types also add a level of self documentation about the code. Having worked on >100k lines JS codebases, and having to debug type casting issues 7 function calls deep, I would much rather have types declared. But hey, whatever works for you is the right choice.
Because some functions are generics and you intent to use them with pretty much any data type. Like for example how arrays can be formed from any data type, so a function performing an operation on one could receive any data type at all. I don't want to write 5 duplicate definitions for the same function.
Svelte is a great example of how to move away from TS based on well-defined engineering reasons, with clear communication, and in a graceful way that maintains compatibility. Turbo is a great example of how to ditch TS based on pure vibes, with terrible communication, and not even bothering to think about compatibility.
TS and ES6 class hierarchy were introduced basically for web developers coming from strong types langs like Java and C# who want to migrate their code patterns to js instead of learning the lang well. In my opinion the worst thing that happened to js env
@@OnePluskynah, classes in JS are a cool way to abstract the internals of the prototype chain and make the language more friendly, as async/await did the same with promises that did the same for callbacks when ES6 was released.
I love that JS developers are beginning to enjoy the journey of madness that C++ developers experienced in the 90's when everyone turned into an architecture astronaut and started templating the shit out of everything they did
@@yeicore Interfaces are based and singletons would be all right if there was a sane syntax for it. But the 'extends' keyword is the single worst feature of the whole language and needs to be deprecated entirely.
everyone complains about advanced language syntaxes that are only required when writing something very general like a library and wants a solution that can work even for a child but nobody has come up with one. Maybe it's about time that we recognize writing a library is inherently difficult and actually try to improve one's language skills.
I went to the MS Build conference where TS was first introduced. it was intended to be a temporary measure until types in javascript were a part of the language standard. I really blame the JS committee on this one for letting it take so long. if you're doing type gymnastics, it's probably a huge code smell that what you're doing is overly complex and you need to shuffle around some responsibilities or do better dependency injection and resolution
"shuffling around dependencies" will not solve typing problems. Think of config objects - I'd much rather have "type gymnastics" in the type definition than "config: object".
I tend to hate those "you're doing something wrong" type of responses, but yeah, everytime I had to do some overly complex type bs, it was because I used something incorrectly or I just didn't think about what I'm doing. It's also why ditching types is the worst move ever. You're just setting yourself up for a rude awakening.
I have had occasions where writing an API I could either not get the adequate types for consumers or I could engage in type gymnastics... It's honestly a difficult thing to manage sometimes
@@okie9025 dependencies are not responsibilities. you're still dependent on a domain class to do the work, but if your domain class is doing too much and crazy abstraction into generic types is your goto solution, it's time to sit back and think about the architecture of your classes and the responsibilities that they hold and maybe move those around and flatten the hierarchy. what a lot of people aren't understanding about type safety is that the IDEs are much better at finding duplicate code blocks than ever before and you don't get that with vanilla JS. to be clear, i'm for type safety. i've worked in too much duck typing codebases to see the nightmares it causes in esoteric bugs
Good luck assigning a workable type to higher order functions without at least some type gymnastics and heavy doses of generics. Shuffling stuff around a bit is fine if your codebase is object-oriented, but there's a lot of codebases out there that aren't.
Type gymnastics mostly happen when you try to marry React (or similar component based frameworks) with TS, but outside of the view layer realm TS works like a charm. If TS and React were designed with each other in mind, I think there wouldn't be such push back
and react brings it‘s own oo language on top of javascript: functional components instead of classes, useState() instead of attributes, hooks instead of methods.
Yeah, type gymnastics with TS is real. TS helps but it also brings lot of headache. So in the end it feels like it's just different kind pain. ECMA optional types and JSDoc looks like quite decent approach. Thumbs up for dropping TS!
@@netify6582 Type gymnastics only exists because not everything is typed. If you actually type everything, there are no gymnastics. Part of the gymnastics is actually people just writing bad code :)
I can't imagine throwing away type safety in a project. I get the build step isnt fun but I can't see the build step and type gymnastics being a bigger headache than the errors that you open yourself up to when going vanilla js.
I feel like the build step thing is way overblown. 99% of people writing code in TypeScript will not be impacted by the 3 seconds it takes to compile your code. During local development, using something like ts-node completely obfuscates the build step anyway. Use cases like the ones Rich Harris has with Svelte and SvelteKit are so niche that there is zero reason for most normal application developers to even pay attention to it.
@@JoRyGu build step argument will go away fast since development of alternative Rust based TS compilers continues. For ex. i switched to SWC compiler and it takes 300ms to compile my project when it was 30s on ts-node.
The build step is a problem for libraries, not applications. Tsc can still type check your JavaScript with types in JSDoc so you get to keep type checking and get rid of the annoying build step. Again, this only applies to libraries. There is absolutely no reason not to use TS for applications
And for the Next decade he's gonna be fighting AJAX form submissions with the Remix experiment. Because form actions are a "web standard" and AJAX isn't.
It took him a whole decade to learn that weak, dynamic typing in a general-purpose programming language is a Bad Thing? Damn. I've literally never met a weak, dynamically typed language that I actually liked. Either they're arcane, verbose, or they have TABLES (sorry, the Lua hate just popped out). There's no middle ground anywhere.
You know, I really appreciate that in C++ it's a question of if we can get away with C++20 or if we still have to use C++14. I'm not joking, web dev is just madness even after a decade of proper applications written with this tech.
It’s as mad as you want it to be. You don’t have to follow the masses who feel the need to rewrite their codebase entirely for the third time this year because they just read a new medium article and don’t want to do actual work.
🎯 Key Takeaways for quick navigation: 00:15 📜 TypeScript's adoption journey: TypeScript initially faced resistance but gained popularity, especially with Angular 2, and became widely used in the early 2020s. 01:41 🧩 Reasons for ditching TypeScript: Some open-source projects like Turbo are moving away from TypeScript due to concerns about code pollution with "type gymnastics." 02:37 🏗️ Using JS doc for type inference: SvelteKit is transitioning to plain JavaScript but still benefits from type inference using JS doc, which generates types and provides IntelliSense in editors. 03:18 🤔 Future prospects: There's an ECMAScript proposal for optional type annotations in JavaScript, which could reduce TypeScript's relevance in the future, but TypeScript remains integral for some frameworks like SvelteKit and Next.js. Made with HARPA AI
@@maxwellwellmanWhoa whoa whoa. I always used esbuild and I know and love that it is way faster than Webpack and many other bundler. But is it really faster than tsc?
@@aloysiuskurnia7643 if you use esbuild without vite it will be a lot faster than all alternatives, but if you use Javascript plugins like babel the performance will be almost the same because plugins slow down the bundler
So many noobs haven’t had the intense misery of debugging a large Python or vanillaJS project and it shows… they just hate that they lack the skill to get their code to compile. Well your bugs are still there, they’re still gonna bite you later, and it’s gonna be like pulling teeth to find them. Good luck with that
@@aloysiuskurnia7643 it actually is orders of magnitude faster, mostly because it's written in Go (tsc is written in TS), and because it doesn't do type checking.
The key with Typescript has always been to use it intelligently. I used to think I never needed it, hated on it, just learnt my API's inside out instead from being so deeply engrained in a project and refused to use it. I took a couple of contracts where I was forced to start to embrace it and then saw the obvious benefits for teams. Teams is the most important part here, anyone can go and build something by themselves, be engrained in it and therefore believe they don't need anything more than that, but if you're collaborating on a passion project, a work project or a library, tools like TS make it a billion times easier to see where and when you fuck up. I wouldn't give up those red squiggly lines lightly now. Caveat: I still hate it when someone writes a ridiculously complex type, I personally always think there's a better way of abstracting things before it gets to that stage.
Indeed. The problem is that people try to do smart code which requires amazing type acrobatics. If that happens, one needs to take a step back and think whether a function that has everything including the kitchen sink is proper.
Ohh man, best comment about TypeScript here! Recently I had to get into projects written in TypeScript written by someone else. One of the most amazing things about it is that when it is not your project it's far far cleaner to read from zero to knowing the codebase. When you write the code for yourself it doesn't matter what do you use as long as you have some coherence.
>I still hate it when someone writes a ridiculously complex type the thing is, with TS there's always a natural pressure to trend in that direction by default.
copilot does it automatically 😂, don't need to learn it. I use typescript only in my editor, in my code ❌, any ms to my build is a waste of resources ⚡
I NEED type annotations on regular JS. TypeScript is a pretty elegant solution meanwhile, though. (Oh, and I want pipe operators too, while we're making wishlists.)
Destiny operator, please! My dream wish recently is to get declarative UI code working in plain JS without a framework. Imagine if there was a standardized way in the browser to do things like Svelte allows you to do. Why can't that be a thing like all of the other specs?
@@highiqandrational('true' == true) => false isn't in my head, though. Nor is ([ ] == [ ]) => false. Nor ([0] == [0]) => false. (I picked the worst possible examples)
Bingo. I'm a huge mypy Stan, but even I am in favor of omitting type hints (in exchange for detailed docstrings) on a function where I would need to perform "gymnastics" to get the compiler not to complain. I also very much appreciate Python's use of Protocols and TypeAliases to allow you to have your cake and eat it too-that is, if type checking is important but would distract from the code flow, you can define a "DuckLike" Protocol in some file out of the way that articulates the exact way the parameter is supported to quack.
@@jbird4478 Well keep in mind that Python is not just a programming language but is meant to be used interactively-and static types in a REPL would be a nightmare.
Types in code aren't just syntax; they're your roadmap. They clarify intent, serve as inline guides, and are the building blocks for exponential growth in your projects.
Picking Kent Dodds as an example of someone making good choices is questionable, he changes his mind more frequently than his socks. We even used to joke about it in a previous workplace, "Kent *_C_* Dodds said everyone should switch to X, so it'll probably be abandoned soon." He's right in this case, though. Flow was technically superior, but never reached stability, and types eliminate a huge amount of potential bugs (and unit tests). At this point I can't even imagine going back.
one of the best things about TS is that I can compile my code to any version of JS while writing it using the latest syntax. I don't have to know whether I'm writing codes for Nodejs or browser, its almost like, "Write once, run anywhere" kinda thing.
@@Luke5100 you are right that the core is weak but you also have to respect that JavaScript was programmed in roughly 10 days 😂. Plus, I wouldn't blame JavaScript so much for the lack of missing features because it was never intended for this. People just started bending and extending JS to make it fit in their projects. I suspect that there might be some deeper reasons why type support is not yet available in JS.
@@julessteiner9172 A scripting language isn't a programming language. A "program"ming language is used to define a "program", a scripting language is used to define a configuration for an existing program in order for it to do what needs to be done.
In the case of Turbo, sacrificing the user experience (library consumer) in favor of the developer experience is a cardinal sin of software development. DHH should know better.
I think native optional type annotations are a great idea, python also has that and it makes understanding your code after a week of not looking at it much easier
@@ajaygcoA couple of days, maybe too soon. But down the line, weeks or months after, when your brain has switched gear to a different project, all those annotations will help.
i frequently program in both. And i will choose having type annotations any day of the week. My JS project are either 1. Code within a block. Which you should keep to a minimum, i know setting up the compiler+bundler is a pain in the ass. But when your stuff grows. TypeScript is the answer. 2. Legacy code. Yeah our old engineer, who lefet the company has written 90% of the infrastructure to in plain JS. With no type annotations whatsoever. I maintain this, and add type annotations. Each annotation can take almost an hour to infer. digging through callstacks and parameter transfers with ctrl+shift+f.
That kind of decision might work best for a library kit project (React, Svelte, etc), because they don't really run code as much as act as a base framework below a ton of unknown scenarios. Their codebase, while significant, is typically small, relatively speaking. A large end-user application would be silly to drop TypeScript.
You have it precisely backwards… with a stable library API, why not add types, it’s easy. The reason you don’t want types is because your library design is hot garbage and you keep piling more garbage on top with breaking changes.
Where is the boundary line between large small project? In a large project you can use Web Assembly and have more performance with a secure control over the data's type.
@@jackzugna5830 "this only works on a small project" is a nonsense argument young people use when they aren't familiar with something. This video is fake news anyway so it doesn't really matter.
I feel like JS will take a page out of Go's book in the future, variables will assume a type and stick to it unless you declare specifically a type. Saves so much time if you do, and people taking this option can compile it.
@dzzzzz3366 because TS was invented by a huge evil anti-open monopoly named Microsoft, and because it's ridiculous to "compile" a script language into another script language when compilation should be into a performant format closer to bare metal performance. TS is still JS whether anyone wants to admit it or not, and the real solution is to face the music and create a new universal language for the web. During the transition period, fix the rot at the core, don't build on top of it like TS does. Fix JS.
Typescript has always been r*tarded af, I have no idea why everyone jumped on that bandwagon. I've been programming for 20 years and can count on one hand the number of times I've tried to do math on a string by accident. It's a bad solution to a non-problem. The simple 4-liner screenshot at 1:53 is quite possibly the dumbest thing I have ever seen.
As much as I love TypeScript, I get what SvelteKit is doing. I can't speak for the rest of them, but TS is one tool among many. It's a meaningful engineering task to select the right tools for the job based on the software you're writing, the team you have, the audience you're writing for, and the technical realities of the rest of the project.
Problem starts when you have big project with undocumented types, parameters, you never know what the return type is (unless you check the implementation or console log) JS should have introduced types long time ago.
@@arturschroeder2430 JS was made not to have types... adding types is like going back... Why use types of a language that was made not to have any types to begin with. Big projects dont require types. Types are only necessary in project which require a lot of complicated functions. I have entire social networks with React and NextJS with pure JS and have no trash boiler plate code. It depends on the priject, not its size.
My guess is that optional types will at some point arrive to JS, just like variables and nested selectors were added to CSS... But may also take time and it will probably not be as robust as Typescript. Really, I believe TS usage will just continue growing and it will stay in the market for many years to come.
ts isn't going anywhere. Library creators are ditching it because they, unlike the users of their libraries, live in generics land where types aren't as useful anyway.
Optional types are better than nothing, but even those of us who appreciate type systems will often be lazy and omit them when they’re not required. Oh I know what I’m doing, it’s fine… hubris and a lack of consideration for the next person to work on your code are the undoing of us all
@@JohnDoe-my5ip They're just switching to jsdocs where instead of writing: fun(param: string) {} You write something like: /* params: param: string */ fun(param){} So they types are in the comment. Considering this is typescript and not an actual type safe language, you get all the same benefits without all the absolutely insane type gymnastics that are often seen in ts libraries.
I personally love having to explicitly type all my variables. It’s a lot easier to know what you’re dealing with. Especially if you use a lot of interfaces and extend them, you can easily go to the interface definitions to see the members. But it’s true that’s sometimes it can be a bit too much, especially combined with ESLint rules, and you end up having to use any or unknown. But for me, it should be really thought before putting that. Like a last resort.
I love TS because once you tell it what type something should be, it will proactively prevent you from making a mistake. These mistakes can cost you hundreds of man-hours if we're coding in untyped JavaScript... People who hate typescript are those who dont see the value of a strongly typed language.
I have a deep appreciation for typescript because it made javascript projects more maintainable and facilitated safer refactorings. I've worked with typescript daily since Angular 2 released in 2016 so I know my way around it pretty well. Having been a .NET dev before that and since then in a full-stack role, it's hard to be satisfied with Typescript when you write a lot of code in C# and Go. The type safety you get with those languages make Typescript feel like a hack. I'm even toying with the hot take that typescript IS a hack to make javascript more usable. Still, though, typescript is the best way to write web apps today.
I think you’re correct in your analysis. But I think it is also good not to compare Typescript with other types languages. It acts differently and serves different functions. You can do some really amazing dynamic things with typescript that is not possible in typed languages, like Template Literal Types. So I think it is beneficial to view it as a different tool altogether, and it has advantages over other typed languages, precisely BECAUSE it is built on top of an untyped language.
I actually feel the opposite way about C# vs TypeScript. TS does so much more inference that C# feels like I'm repeating myself constantly. With C#, I kinda see why the dynamic people hate static typing so much, though it has improved its inference capabilities a lot over the years. With TS, I feel like I get the best of both worlds: good type checking without all the repetition. It's almost as good as F#
@@majahanson311 C# dev here, and I really wish they'd never introduced var (statically inferred type). Often times during a peer review when I see the result of a method assigned to a new variable of type var I end up having to call the dev who wrote it to ask what type that particular instance of var is.
I've always found if you are being forced into things like type gymnastics so often its causing headaches, most likely you have a code design problem. I learned static typed languages before JS/TS so learned to love and rely on strong typing. And as with anything there's always more than one way to skin a cat so if I'm being forced to do tedious stuff to keep the compiler happy that's a sign I need to take a moment and think about the design of my code. More often than not there's a perfectly elegant solution I just hadn't thought of yet.
I think what he meant is that using TypeScript, you have to spend additional time thinking about things like what to name the types and whether or not you should have two different interfaces/types to represent two variants of the same input for different functions or just have one interface with optional properties... There are thousands of situations like that where TS forces you to think about the type of things or all the various ways to skin a cat (to borrow your own words) which can be distracting compared to JS where you are 100% focused on pure logic and automated tests; just go straight for the meat...
I ALWAYS thought Typescript was a useless invention. My thinking was "It comes from Microsoft and seemed to be some new way to make people unnecessarily dependent on yet another invention from them." Most of my apps have 30-50 lines MAX in Javascript, and even that is too much already. Typescript is DEFINITELY NOT NEEDED for that. I'm just not that TYPE.
The time I spend writing types saves me far more time down the line. DHH's blogpost reads like someone who tried TS, didn't like it, and now bases decisions off of that one experience. The face that the PR was merged within a few hours of being opened despite the relevant objections is hilarious.
These types of programmers measure code quality on how little code they have to read and write, not in how easy it is to maintain. Rails code often results in unexpected behaviors that are difficult to debug, but at least it looks pretty!
I use something similar to JSDoc for Lua called EmmyLua. It's nice, but I'd still prefer a typed alternative like Luau at times because sometimes the IDE doesn't realise two data types don't match until it's actually tested. At a poece of code where other languages would have flagged it before you even tried to run it.
Was gonna say, this sounds a lot like when Roblox adopted Luau as the default (haven't touched Roblox Studio in years, but I kept up with the dev blog). Any time that types aren't directly built in to the fundamental syntax of the language, you're gonna have Undefined Behavior no matter how careful you are, especially once you get into user-defined types (the Instance gameobjects in Roblox) and trying to operate on them directly in code...
@@WackoMcGoose I've heard the language is decent just a shame most games and apps still use Lua even something like Wren or Squirrel would be more preferable at times for the same performance
Type annotations proposal doesn't make typescript obsolete, it tries to remove the build step. You still have to typecheck those annotations, that's what typescript is for. The proposal just provides a standard type annotation syntax for implementations to erase.
É importante considerar que, mesmo diante da desaprovação de algumas pessoas em relação às decisões dessas empresas, grande parte do debate em torno deste assunto parece ser motivado mais pelo fanatismo do que por argumentações concretas. O TypeScript, em muitos casos, tornou-se quase uma marca, semelhante à popularidade da Apple, onde muitas pessoas o utilizam sem realmente compreender completamente os motivos. É fundamental lembrar que a escolha entre TypeScript e JavaScript deve ser baseada em uma avaliação criteriosa das necessidades do projeto, em vez de seguir tendências cegamente. Flexibilidade e adaptabilidade são essenciais para garantir que a tecnologia escolhida atenda de fato aos objetivos e requisitos específicos de cada desenvolvimento. Eu fiz um post no inicio do ano sobre o porque eu não utilizo Typescript e porque a empresa onde eu trabalho resolveu retirar o Typescript do projeto. Acho no mínimo interessante ver que outras pessoas/empresas estão adotando a mesma medida.
Many people in the comments forget that typescript is not only giving you types features but whole lots of other features like enums, extended class functionality that reminds other OOP languages, attributes and so on and on...
yeah but enums are an antipattern in TS. have fun trying to extend/implement/compose enums. Not that you can do that in many languages, but if you simply use string literal unions instead, you get all the benefits of enums and all the extra power of normal TS types.
@@highiqandrational Thats an idea out of the blue with 0 arguments to support it. OOP helps to solve a lot of fundamental problems. Its reliable, secure (access modifiers in compiled languages), reusable. Pros list can go a long way...
My understanding of that proposal is for js to ignore type declarations so tools like TS can appear in vanilla JS. Not that it would absolutely remove the need for a type manager
You still won't be able to ship typescript to the browser as the proposal only allows for colon delaminated type declarations on variable declarations and function parameters. You will still have to configure a build step to strip out every other type-related construct. your type definitions, type casts, as const, etc. In addition, this proposal as it stands would preclude the addition of true types into javascript in the future. The syntax will already be in use, and turning these types from runtime ignored to runtime enforced / optimized would break any code utilizing them where the declared types and actual types have drifted apart over time. Types should only be added to javascript when they are intended to be a full first-class addition.
Doing "gymnastics" to please the compiler is like writing bogus tests to please the coverage check. The types are there for a reason. You will be type-checked, either in production or during compilation, when you have an incident in production, you'll regret not having a compiler warn you there was a bug in your code.
FML. We're doing object oriented coding, no now we're doing functional programming. We're doing MVC patters, wait now we're doing components. Don't put your styles inline with your HTML, nevermind ONLY put your styles in HTML with TailwindCSS. People obsessed with patterns are demented.
The problem isn't JavaScript, the problem is you people using JS in the backend... It wasn't meant for that and it's so freaking obvious, if your code base is large enough you need a language that actually enforces types at compile time, we have use Java Spring Boot without hiccups for over a decade.
I personally think it is time for JS itself to move forward. Things like optional types, better class support, loaders, annotations etc. should be added to vanilla. I overall really love to work with JS, but the basic feature-set is not up to date. Mixing TS features into JS would be out of my dreams. But at the pace that JS is evolving this may sadly take a decade at least.
@@htspencer9084 It is like we got ass language like english to "lingua franca". Started from island where we got some latin, anglo saxon, old norse and gaelic mixed.
Javascript runtime bugs is the reason many backends have stopped using node.js and javascript, and you can't say "just write better code" in teams of multiple devs, who'll extend and modify your code.
It's not going to make TS obsolete because this ecma proposal introduces only syntax for adding types, but js engine will treat it as a comment. You'll still need TS for type checking
Which is a great combination. The type checking can then run in parallel while you develop and you don't have to wait for the latest compile to finish before testing.
My biggest issue with all of this, is that some of these projects are just dropping all type systems entirely. JS is extremely hard to use if you don't have types to reference because the LSP doesn't really expose the APIs. So rather than looking up definitions of the API functions/objects you have to either go to docs or read the code directly. Its clunky for a modern library/project. Drop TypeScript, but implement some kind of type system like jsdocs to make it so that people can easily use your APIs without having to leave their text editors. I don't especially like typescript but the turbo 8 decision is especially stupid.
Awesome name "type gymnastics", didn't think too much about it. But now that you mention it, I spend more time than I'd like to admit just trying to figure out what kind of type I have to write in order to make the red squiggly line to go away. That being said, I still love Typescript and I feel naked when trying to code with vanilla js
Didn't know about the jsdoc standard for doing types and I can see why someone would move to it. I love Typescript and am sticking with it. I don't see the compile step as being that laborious personally. I spend way more time thinking through coding problems that waiting on compilers. But to each their own, if a project wants to remove the compile step while keeping most of the goodness of Typescipt I can see that.
I'd like to see you debug a million lines long javascript project. when you can't understand what type a particular variable is until you skip to the part where the variable is used/put some data into, you'll know the pain. Static typing is also why C/C++/Java can be used for humongous projects and still are fairly debuggable and understandable by reading
I'm a firm believer in freedom, but I think modern workflow adds too many layers of abstractions. I do like controlling my code, but for many projects the setup and maintenance take more effort than the core code itself. never liked TypeScript or seen a need to use it, so I am glad to see big names make it clear again that not all of us NEED to use TS
Problem is that people do not want to write tests, they prefer to "compile" their amazing Typescript code because they don't have to write meaningful tests, because amazing green icon on build step said their code is perfect.
@@ex-xg5hh You would be surprised what PRs I have seen from "fellow" developers on my team. They have different opinion and typescript compile is already more than they would normally use. (I guess normally is just putting the code straight to production)
Using TypeScript generics in *application code* to perform type gymnastics is generally straightforward. However, using generics in *library code* often requires an additional meta level of mental abstraction resulting in the _twisties._
@@alanschmitt9865 Because you need to support so many more different types in your generics for a lib than when you write application code. Take the example of `const sum = (a, b) => a + b;` it might seem obvious at first for a and b to be numbers, but then you could also add strings to concatenate them, or support number-like protocols for a and b that are not the default number type of javascript... The example is minimal on purpose, but in a library, you have to make types stay out of the way. The app can be overly restrictive on the types it can use in its functions, but the library has no idea of the purpose it's being used for, so it has to be more generic, eventually leading to type gymnastics.
@@alanschmitt9865 In an application you generally know the details of what you're passing around whether it's a user object, log event, or db connection. For much of the code you don't need to use generics because all your types are known ahead of time. With library code, on the other hand, you often times have no idea what crazy wacky stuff users might try passing into your library. The challenge is for your library to allow the user's IDE to infer useful type information even though you've never seen the user's type definitions.
That's true. The most optimal development performance and quality are achieved when using JS + .d.ts + JSDOC. This is especially true for projects that do not have a clear roadmap and requirements change frequently, which is common in agile teams. There is no need to type absolutely everything, but only public interfaces, and this can be done not immediately, but after you are sure that the implementation will end up in the final product. Typing in JS should be considered purely as documentation and not as a strongly typed programming language. As documentation, the .d.ts file is just wonderful. You don't need to search the source code for exports and declarations or run the IDE to understand what's in the modules. You don't need to filter types in your head when you're looking at the logic of your code, which often takes up more space than the code itself. I think the ideal thing for JS would be optional typing built around decorators. This way types could be checked statically by a linter in the IDE, and validated at runtime using the same type meta data.
People who hate strong typing never do debugging, especially on the big and complex project. It's true that is easier and faster to code without any strong typing, but it will take its toll when it's time to debug.
I have to refactor a huge PHP project with no type hinting, no interfaces and just passing random variables of any type around in multiple 1000+ line function collections. Arrays with unpredictable random keys that are only set somewhere in dozens of different functions that pass it around to each other makes it impossible to know what you have. God, I can't even rely on it actually being an array, I might suddenly get an object or a string back... that made me start also using JSDoc to its extreme inside our vanilla JS when there's no build step possible. All I really need added in JavaScript is strong typing, because nobody adding any way to track types anywhere is the primary cause of all our projects disasters.
There's Typescript for css now, to make css "type safe". Soon they'll introduce Type safe emails and type safe Coca Cola and then debate how we managed the two without "type safety". I've seen more frontend webdev teams focusing on type gymnastics instead of things that actually matter - ux, accessibility, performance, functional tests, the fucking output.
@@gregor3099the svelte team very explicitly does not care about "code pollution" or whatever, jsdoc comments are a lot more verbose than regular typescript type annotations. but as a library, not an app, they care about productivity and one thing you can do in javascript is just open the node_modules/ folder and edit a file there. and if you use a package manager like pnpm (maybe regular npm works for that too i don't actually know) for local development, you can link your dependencies to local directories and any change you do in the node_modules/ folder is directly reflected in the actual repository, and at no point do you have to have tsc --watch command or something running in the background. also if you only have type checks on commits instead of literally any change ever you can quickly test something that would error normally (due to not-yet-defined types or whatever) but doesn't matter because it doesn't have to compile to run
It's not particularly useful when building libraries full of generics because you end up with more type definition code than actual code. It's just a hassle unless you like thinking and debugging through things like: "Handler extends LocalHandler, Schema extends TypedSchema" And that's a pretty simple example from a small and specialized library. It get's out of hand quick.
Nothing to see here. "Big libraries ditching TypeScript", proceeds to show Turbo [no, not the Vercel one], Svelte and Drizzle. I haven't even heard of two of those and I'm pretty confident those aren't used THAT MUCH in big, complex projects. Content like this is silly. The JS community is fragmented/undecided enough as it is, without videos like this adding fuel to the fire. Cheap sensationalism at best.
i always felt scripting languages should be strict enough that your code runs, but loose enough to use in a repl or console for R&D and fast prototryping. JS and Python are so fun for that reason. I think TS had its place for development teams with green programmers or projects that plan on a long shelf life, but if i can replace it with jsdoc id rather do that then have a whole new language people have to learn.
I always just saw Typescript as a huge obstacle. It really just slows down development for me. If you write good enough tests while developing and keep things neat and simple, vanilla js is great.
I always just saw writing tests as a huge obstacle. It really just slows down development for me. If you write good enough code and use type safety of TypeScript, life is great.
Agree. I use a system approach that I call BETLL. It's babel + eslint + testing + logging + lodash. And you have a perfectly stable, performant and maintainable app with pure JavaScript!
Yep, a library I feel is a write implementation once sort of thing, ie you can’t refactor constantly without worrying about breaking changes, so you need to write a new version or a new method or class to extend functionality. So JSDoc is probably acceptable vs an application where it’s just faster to write and export types.
This is great to hear. As a very pragmatic programmer who impulsively rejects any unnecessary semantic mess, I HATED using typescript. Yaahsuure, compile type checking... preventing some issues.... blah blah I have spent DAYS chasing down a skinning-the-yak madness exercise of fixing types just to get an extra parameter added to a function which would have been a minutes long exercise in JS. And the extra always confusing build system... come on. Keep it simple!
Writing types is like writing tests. You can skip the types/tests and save a tiny bit of your own time, but someone else might spend much more time making changes later. Alternatively, you can spend a little extra time writing types/tests, which could save tons of time for others , helping your colleagues and bettering the world. Whether you choose to use typed code or not, it reflects the kind of person you are.
JSDoc just isn't nearly as powerful as TypeScript's type system. I can never go back. I'd rather write type ceremony code that is more complex than my actual code than deal with the uncertainty you get when not using TypeScript.
I'm not sure if I'd understand the reasoning of the Turbo devs, but Svelte put it really nicely. As an inhouse working on the framework, I would fight that decision a _little_ bit, but only a little. As an contributor, I would be weirded out, but I think I'd ultimately appreciate it. And as a user, I'd like it-straight up.
How would adding type annotations to native JS solve the type gymnastics problem? Wouldn't that just mean you have to do the same gymnastics, but now in native JS?
I was using JS doc way before being forced to use TS at work, tbh yeah I can understand that type gymnastic thing, I do see the point of TS, I doubt it'll die, but I'll be leaning more toward native JS for personal projects, and keep using TS because my work require it and only for that reason
Typescript is purely for the anal-retentive types that enjoy spending more time writing definitions than actual code. JS is not a strictly typed language, TS is a false sense of security. TS is a nightmare when it comes to doing what JS is mostly used for, consuming web apis, and it makes promises twice as convoluted. I am pro optional doc blocks. End to end type safety just means you are updating types in 15 different places when you add an optional parameter to your request parameters. Your code should serve you, you should not serve your code.
If you code complex domains, still Typescript is the king. Literal types are the key to achieve parse don't validate principle. Also, types are great for applying always domain model.
I feel like the main reason they want to ditch TS is because by trying to fix JS, it made it worse. Perhaps it would be better to focus more on Webassembly instead of keeping JS
@@BuyMyBeard I mean worse on some points, like the compilation step, messing around with types, etc... I'm still on team typescript, but more and more I think we should ditch it for more stable programing languages. Typescript is a band-aid on a severed limb. It"s better than nothing, but we could go straight to a protesis instead. Now webassembly can be compiled from nearly any languages, including javascript and typescript, and it also improve stability and compile time error checking instead of runtime errors
@@RustyNova to be fair it really is the best case scenario if javascript becomes typescript honestly. Javascript needs to stay a simple and easy dynamically typed language, but also support static types and detect problems with those. The thing is I don't think that will ever happen, so Typescript will probably be there to stay
What is funny to me is, when I see all the examples of type “gymnastics”, all I can see are people that don’t like to use TS, using TS. For example, why isn’t your “Subscribe” function referring to a named type, and or the callback? You’d be able to reference/reuse them and they’d also improve readability. Also for recurring types like EmptyFunction you can create it once and reuse across the project. Turbo’s removal of TS was a sole individual affecting the entire community, which was against and he knew it, simply because he didn’t like it.
Typescript is a pain late at night when you are using new libraries and you get a boat load of typing errors. It is a annoying and draining. We just need something fast and quick to put in production so we can proceed to writing test.
Well if JavaScript receives native typings, did TypeScript really die or has JavaScript become TypeScript?
I think the difference is that js will still not being checked at one more compiler step. Typescript is still valid even when js with types comes in
There's a slight difference between type annotations and Typescript. Many front end frameworks use Typescript for much more than just adding type checking. There's tooling with a huge ecosystem built around TS, there's type inference, there's also optimization and compilation which are necessary to a lot of projects. I don't see how adding type annotations could eliminate the need for all the advantages that TS provides but either way it would be a great improvement to other projects that don't require TS in the first place.
Turns out Embrace, Extend, Extinguish is still the MO.
From Microsoft's point of view it died.
Typescript allows you to use future Javascript in older browsers and allows to use things like JSX.
JSX will probably never be in the browser natively because many frameworks compile it in different ways like JSX runtime, SolidJS, InfernoJS
optional types in vanilla js would be amazing honestly
@@IronCandyNotesnot gonna recheck but I think it's supposed to be in comment format as well
In my opinion they should not implement optional types in Javascript, because it will just make Javascript parsing time slower, they should instead allow to transform the file on the fly so you can use esbuild, flow or any other build tool easily and if you are worried about performance you should use a bundler anyways
@@IronCandyNotes They will not create a new type system but only make JS able to ignore type annotation with some keywords (like interface and type) and with some special syntax (like colon after a variable). This proposal will be based on the typescript syntax, since is the most established solution for JS.
Fable with F# is a hidden gem ..
I think this is the way yes. that’s how python did it and frankly as a Java developer coding in python type annotations was really fun it felt like I actually had to care about how I declare my functions.
I personally use TypeScript for the compiler, so that I can catch bugs without losing money at production, because of my terrible code
1) typescript can't help you with logical financial error
2) there are better ways to write financial code
That's stupid
@@aberbawhat does this have to do with what he said 🤔
@@aberba well that's not the point, it's that you can catch errors before production in the first place
I work with large corporations and deadlines are a thing. I have never worked in a project with 100% perfect test coverage. When project deadlines are tough, unit tests are the first things to get dropped. The build step has always saved us from someone unintentionally removing/renaming/refactoring something that will only be apparent at runtime.
I think a lot of complaints about TS come from people designing their code like it's still dynamically typed. Like Fireship's code example at 1:53. Why would you make the value parameter in your callback either T or an empty array? And the function either returns void or another function? Union types should be used sparingly because you're introducing a lot of complexity, and now you have check all of those values in runtime
I love TS because once you tell it what type something should be, it will proactively prevent you from making a mistake. These mistakes can cost you hundreds of man-hours if we're coding in untyped JavaScript...
Dynamic types are great for enabling speed at development, it removes a layer of complexity from writing code. The problem with that is when a codebase becomes large enough, refactoring and debugging becomes much more difficult. Types also add a level of self documentation about the code.
Having worked on >100k lines JS codebases, and having to debug type casting issues 7 function calls deep, I would much rather have types declared.
But hey, whatever works for you is the right choice.
Folx just want to write crappy code and then blame TS that it resists
Because some functions are generics and you intent to use them with pretty much any data type. Like for example how arrays can be formed from any data type, so a function performing an operation on one could receive any data type at all. I don't want to write 5 duplicate definitions for the same function.
@@Leonhart_93 you could create an alias type as the union of your 5 types and only write the function once
Svelte is a great example of how to move away from TS based on well-defined engineering reasons, with clear communication, and in a graceful way that maintains compatibility. Turbo is a great example of how to ditch TS based on pure vibes, with terrible communication, and not even bothering to think about compatibility.
By the way Svelte 4 out now already is using JSDoc, no need to wait for Svelte 5
TS and ES6 class hierarchy were introduced basically for web developers coming from strong types langs like Java and C# who want to migrate their code patterns to js instead of learning the lang well. In my opinion the worst thing that happened to js env
@@OnePluskynah, classes in JS are a cool way to abstract the internals of the prototype chain and make the language more friendly, as async/await did the same with promises that did the same for callbacks when ES6 was released.
@@OnePlusky Tell me you're a noob without telling me.
Turbo’s explanation was basically “Typescript prohibits us from writing shit code and It gives us headaches so we remove It”
I love that JS developers are beginning to enjoy the journey of madness that C++ developers experienced in the 90's when everyone turned into an architecture astronaut and started templating the shit out of everything they did
*Java devs using interfaces and singletons as of there was no tomorrow*
@@yeicore As a java dev, I can confirm I make an interface and a class for every line of code I write.
@@yeicore Interfaces are based and singletons would be all right if there was a sane syntax for it. But the 'extends' keyword is the single worst feature of the whole language and needs to be deprecated entirely.
@@salvatoreshiggerino6810what singletons are you referring to?
something tells me it's not the design pattern
everyone complains about advanced language syntaxes that are only required when writing something very general like a library and wants a solution that can work even for a child but nobody has come up with one. Maybe it's about time that we recognize writing a library is inherently difficult and actually try to improve one's language skills.
I went to the MS Build conference where TS was first introduced. it was intended to be a temporary measure until types in javascript were a part of the language standard. I really blame the JS committee on this one for letting it take so long. if you're doing type gymnastics, it's probably a huge code smell that what you're doing is overly complex and you need to shuffle around some responsibilities or do better dependency injection and resolution
"shuffling around dependencies" will not solve typing problems. Think of config objects - I'd much rather have "type gymnastics" in the type definition than "config: object".
I tend to hate those "you're doing something wrong" type of responses, but yeah, everytime I had to do some overly complex type bs, it was because I used something incorrectly or I just didn't think about what I'm doing. It's also why ditching types is the worst move ever. You're just setting yourself up for a rude awakening.
I have had occasions where writing an API I could either not get the adequate types for consumers or I could engage in type gymnastics... It's honestly a difficult thing to manage sometimes
@@okie9025 dependencies are not responsibilities. you're still dependent on a domain class to do the work, but if your domain class is doing too much and crazy abstraction into generic types is your goto solution, it's time to sit back and think about the architecture of your classes and the responsibilities that they hold and maybe move those around and flatten the hierarchy. what a lot of people aren't understanding about type safety is that the IDEs are much better at finding duplicate code blocks than ever before and you don't get that with vanilla JS. to be clear, i'm for type safety. i've worked in too much duck typing codebases to see the nightmares it causes in esoteric bugs
Good luck assigning a workable type to higher order functions without at least some type gymnastics and heavy doses of generics. Shuffling stuff around a bit is fine if your codebase is object-oriented, but there's a lot of codebases out there that aren't.
You got me with the "It's not easy to be self employed" 😂
Glad I wasn't the only one who caught that 🤣
Yeah, I relate too much to being my harshest critic…
came here for this comment !
Saw it coming a mile away, but still chuckled
When you're self employed, Nobody hates you more than yourself.
Type gymnastics mostly happen when you try to marry React (or similar component based frameworks) with TS, but outside of the view layer realm TS works like a charm. If TS and React were designed with each other in mind, I think there wouldn't be such push back
Angular is a React designed with TS in mind
and react brings it‘s own oo language on top of javascript: functional components instead of classes, useState() instead of attributes, hooks instead of methods.
Yeah, type gymnastics with TS is real. TS helps but it also brings lot of headache. So in the end it feels like it's just different kind pain. ECMA optional types and JSDoc looks like quite decent approach. Thumbs up for dropping TS!
I used React + TS for at least 2 years and didn't notice and so-called "type gymnasitc". What do you even mean by that?
@@netify6582 Type gymnastics only exists because not everything is typed. If you actually type everything, there are no gymnastics. Part of the gymnastics is actually people just writing bad code :)
🎯 Key Takeaways for quick navigation:
00:00 📆 2023年9月7日，许多年前Kent C Dodds不使用TypeScript。
00:29 🔄 近期，很多大型开源项目选择放弃TypeScript，回归到原生JavaScript。
01:13 ❓ 许多人疑惑为什么一些人会在使用了TypeScript后再回到原生JS。
01:41 📚 DHH表示放弃TypeScript的主要原因是它使代码充斥着“类型体操”。
02:37 🚀 Svelte已决定不再使用TypeScript，而是采用JS doc注释方式。
Made with HARPA AI
Useless
I can't imagine throwing away type safety in a project. I get the build step isnt fun but I can't see the build step and type gymnastics being a bigger headache than the errors that you open yourself up to when going vanilla js.
I feel like the build step thing is way overblown. 99% of people writing code in TypeScript will not be impacted by the 3 seconds it takes to compile your code. During local development, using something like ts-node completely obfuscates the build step anyway. Use cases like the ones Rich Harris has with Svelte and SvelteKit are so niche that there is zero reason for most normal application developers to even pay attention to it.
@@JoRyGu build step argument will go away fast since development of alternative Rust based TS compilers continues. For ex. i switched to SWC compiler and it takes 300ms to compile my project when it was 30s on ts-node.
@@JoRyGu This! Are the people at Svelte working on Windows XP notebooks? How is the compile step a significant blow to productivity for them?
The build step is a problem for libraries, not applications. Tsc can still type check your JavaScript with types in JSDoc so you get to keep type checking and get rid of the annoying build step.
Again, this only applies to libraries. There is absolutely no reason not to use TS for applications
thats bc it does not do any type checking...@@guramguram6706
"You have to be open-minded and be able to adapt"
Of course. Only took the guy the better part of a decade to adapt. Absolute adaptability.
Adaptability of a tar.
@@ultimaxkom8728tar can adapt to any situation, maximizing it’s ability to ruin everything
And for the Next decade he's gonna be fighting AJAX form submissions with the Remix experiment. Because form actions are a "web standard" and AJAX isn't.
It took him a whole decade to learn that weak, dynamic typing in a general-purpose programming language is a Bad Thing? Damn. I've literally never met a weak, dynamically typed language that I actually liked. Either they're arcane, verbose, or they have TABLES (sorry, the Lua hate just popped out). There's no middle ground anywhere.
@@mage3690hey! No hate towards Lua or its tables! 😠
I'm a simple man: I see a Fireship notification and I leave the flight cabin, take my parachute and watch it.
😂😂😂😂😂
10 minutes later response, I hope you remembered to open the chute in time.
Fireship notification in flight?
@@ChrisCarlos64You guyz have shutes!😮
I'm more of a productivity guy and skip the parachute step!
You know, I really appreciate that in C++ it's a question of if we can get away with C++20 or if we still have to use C++14. I'm not joking, web dev is just madness even after a decade of proper applications written with this tech.
It’s as mad as you want it to be. You don’t have to follow the masses who feel the need to rewrite their codebase entirely for the third time this year because they just read a new medium article and don’t want to do actual work.
🎯 Key Takeaways for quick navigation:
00:15 📜 TypeScript's adoption journey: TypeScript initially faced resistance but gained popularity, especially with Angular 2, and became widely used in the early 2020s.
01:41 🧩 Reasons for ditching TypeScript: Some open-source projects like Turbo are moving away from TypeScript due to concerns about code pollution with "type gymnastics."
02:37 🏗️ Using JS doc for type inference: SvelteKit is transitioning to plain JavaScript but still benefits from type inference using JS doc, which generates types and provides IntelliSense in editors.
03:18 🤔 Future prospects: There's an ECMAScript proposal for optional type annotations in JavaScript, which could reduce TypeScript's relevance in the future, but TypeScript remains integral for some frameworks like SvelteKit and Next.js.
Made with HARPA AI
If your project is large enough for the compile step to take too long, it is large enough to necessitate type safety.
or you can use esbuild instead of tsc
@@maxwellwellmanWhoa whoa whoa. I always used esbuild and I know and love that it is way faster than Webpack and many other bundler. But is it really faster than tsc?
@@aloysiuskurnia7643 if you use esbuild without vite it will be a lot faster than all alternatives, but if you use Javascript plugins like babel the performance will be almost the same because plugins slow down the bundler
So many noobs haven’t had the intense misery of debugging a large Python or vanillaJS project and it shows… they just hate that they lack the skill to get their code to compile. Well your bugs are still there, they’re still gonna bite you later, and it’s gonna be like pulling teeth to find them. Good luck with that
@@aloysiuskurnia7643 it actually is orders of magnitude faster, mostly because it's written in Go (tsc is written in TS), and because it doesn't do type checking.
The matter is very simple.
Types exist no matter what.
You can put them:
- in your code
- in your mind
It's up to you which one is better.
In you mind, you are more valuable as a software developer
mind is way more expensive resource then cpu/ram, so only real option is more broken code or types in code.
Only if you work alone. The "in your mind" version breaks down with teams.
code.
@@LukasLiesis typescript does not run at runtime u silly goose
The key with Typescript has always been to use it intelligently. I used to think I never needed it, hated on it, just learnt my API's inside out instead from being so deeply engrained in a project and refused to use it. I took a couple of contracts where I was forced to start to embrace it and then saw the obvious benefits for teams. Teams is the most important part here, anyone can go and build something by themselves, be engrained in it and therefore believe they don't need anything more than that, but if you're collaborating on a passion project, a work project or a library, tools like TS make it a billion times easier to see where and when you fuck up. I wouldn't give up those red squiggly lines lightly now. Caveat: I still hate it when someone writes a ridiculously complex type, I personally always think there's a better way of abstracting things before it gets to that stage.
Indeed. The problem is that people try to do smart code which requires amazing type acrobatics. If that happens, one needs to take a step back and think whether a function that has everything including the kitchen sink is proper.
@@PanduPoluan couldn't agree more.
Ohh man, best comment about TypeScript here!
Recently I had to get into projects written in TypeScript written by someone else.
One of the most amazing things about it is that when it is not your project it's far far cleaner to read from zero to knowing the codebase.
When you write the code for yourself it doesn't matter what do you use as long as you have some coherence.
>I still hate it when someone writes a ridiculously complex type
the thing is, with TS there's always a natural pressure to trend in that direction by default.
It'd be amazing to see a JSdoc tutorial exploring the various options available
copilot does it automatically 😂, don't need to learn it. I use typescript only in my editor, in my code ❌, any ms to my build is a waste of resources ⚡
There's like 5 options altogether, no need for a tut.
THE STOCK FOOTAGE OF PEOPLE BANGING LAPTOPS WILL NEVER GET OLD
I NEED type annotations on regular JS. TypeScript is a pretty elegant solution meanwhile, though. (Oh, and I want pipe operators too, while we're making wishlists.)
pipe operator is at stage 2
do you know how compilers work
Destiny operator, please! My dream wish recently is to get declarative UI code working in plain JS without a framework. Imagine if there was a standardized way in the browser to do things like Svelte allows you to do. Why can't that be a thing like all of the other specs?
So you would pipe functions together that you couldn't normally dot chain?
@@highiqandrational('true' == true) => false isn't in my head, though. Nor is ([ ] == [ ]) => false. Nor ([0] == [0]) => false. (I picked the worst possible examples)
Optional typing in python is so convenient. I just type whenever typing is not obvious or can't be inferred
Optional typings in Python is a third of the reasons why the ecosystem is so terrible
@@NatoBoramCompletely agree
Bingo. I'm a huge mypy Stan, but even I am in favor of omitting type hints (in exchange for detailed docstrings) on a function where I would need to perform "gymnastics" to get the compiler not to complain.
I also very much appreciate Python's use of Protocols and TypeAliases to allow you to have your cake and eat it too-that is, if type checking is important but would distract from the code flow, you can define a "DuckLike" Protocol in some file out of the way that articulates the exact way the parameter is supported to quack.
Optional typing is excuse for bad typing system
@@jbird4478 Well keep in mind that Python is not just a programming language but is meant to be used interactively-and static types in a REPL would be a nightmare.
Types in code aren't just syntax; they're your roadmap. They clarify intent, serve as inline guides, and are the building blocks for exponential growth in your projects.
no, they're just syntax
Overrated
@@monad_tcpif your project is big enough you'll cry for those semantics
@@monad_tcp No its just syntax
and that's exactly why svelte is not dropping types, they are just dropping the typescript language and using jsdoc
Picking Kent Dodds as an example of someone making good choices is questionable, he changes his mind more frequently than his socks. We even used to joke about it in a previous workplace, "Kent *_C_* Dodds said everyone should switch to X, so it'll probably be abandoned soon." He's right in this case, though. Flow was technically superior, but never reached stability, and types eliminate a huge amount of potential bugs (and unit tests). At this point I can't even imagine going back.
We moved to TS because it's type enforced and you catch type bugs earlier in the development process rather than at runtime.
one of the best things about TS is that I can compile my code to any version of JS while writing it using the latest syntax. I don't have to know whether I'm writing codes for Nodejs or browser, its almost like, "Write once, run anywhere" kinda thing.
Can't you do that with Babel?? Just need to specify your target, node and/or browser. JS to JS.
write one javascript, write twice typescript...
@@andrefig822 You can, yes, but that reintroduces the compile step.
Thats like what any bundler does, parcel, esbuild, even raw swc
Errr, have you only written JS after TS came out? Babel does exactly this for native JS.
Having all the basic features of typescript in vanilla JS would be a huge gamechanger.
@@Luke5100Js IS a proper programming language
@@Luke5100 bro just stop your bs , why is it always some elitist with his R opinions
@@Luke5100 you are right that the core is weak but you also have to respect that JavaScript was programmed in roughly 10 days 😂. Plus, I wouldn't blame JavaScript so much for the lack of missing features because it was never intended for this. People just started bending and extending JS to make it fit in their projects. I suspect that there might be some deeper reasons why type support is not yet available in JS.
@@Luke5100scripting language is a programming language
@@julessteiner9172 A scripting language isn't a programming language. A "program"ming language is used to define a "program", a scripting language is used to define a configuration for an existing program in order for it to do what needs to be done.
In the case of Turbo, sacrificing the user experience (library consumer) in favor of the developer experience is a cardinal sin of software development. DHH should know better.
He’s a narcissistic dbag like Musk…he does not care
so you should know better when user won't even use anything about turbo code, they just import the library and that it bro
I think native optional type annotations are a great idea, python also has that and it makes understanding your code after a week of not looking at it much easier
If you need to "try" to understand your code after a couple of days, you did not write it properly in the first place.
@@ajaygcoA couple of days, maybe too soon. But down the line, weeks or months after, when your brain has switched gear to a different project, all those annotations will help.
I really don't like the way it's done in python. I also don't understand why being forced to include types is such a terrible thing.
@@PhthaloJohnson I also thing python type annotations are ugly. I really like how it's in C#
@@ajaygcotell me you are junior programmer without telling me you are junior programmer
i frequently program in both. And i will choose having type annotations any day of the week. My JS project are either
1. Code within a block. Which you should keep to a minimum, i know setting up the compiler+bundler is a pain in the ass. But when your stuff grows. TypeScript is the answer.
2. Legacy code. Yeah our old engineer, who lefet the company has written 90% of the infrastructure to in plain JS. With no type annotations whatsoever. I maintain this, and add type annotations. Each annotation can take almost an hour to infer. digging through callstacks and parameter transfers with ctrl+shift+f.
Sounds like an absolutely horrible job. Hope it doesn't drain away your love for programming
Sure thing, if your project is full of implicit or explicit any, you should definitely ditch TypeScript. It's not good for ya ;)
Well i fucking hate typescript since day one no need for wink emoji.
@@ahmedmagdy-qg3tbstunning and brave 👏
@gregor3099 this comment made my day😂 thx
That kind of decision might work best for a library kit project (React, Svelte, etc), because they don't really run code as much as act as a base framework below a ton of unknown scenarios. Their codebase, while significant, is typically small, relatively speaking. A large end-user application would be silly to drop TypeScript.
yep, libraries are pretty static, well defined and testable, but not general applications.
What? The end-users of libraries depend on types to understand libraries. This is an awful take.
You have it precisely backwards… with a stable library API, why not add types, it’s easy. The reason you don’t want types is because your library design is hot garbage and you keep piling more garbage on top with breaking changes.
Where is the boundary line between large small project?
In a large project you can use Web Assembly and have more performance with a secure control over the data's type.
@@jackzugna5830 "this only works on a small project" is a nonsense argument young people use when they aren't familiar with something. This video is fake news anyway so it doesn't really matter.
Seatbelts are uncomfortable, restrict my movement and take time to put on before I can start the car. Remove seatbelts from cars!
I feel like JS will take a page out of Go's book in the future, variables will assume a type and stick to it unless you declare specifically a type. Saves so much time if you do, and people taking this option can compile it.
@dzzzzz3366 because TS was invented by a huge evil anti-open monopoly named Microsoft, and because it's ridiculous to "compile" a script language into another script language when compilation should be into a performant format closer to bare metal performance. TS is still JS whether anyone wants to admit it or not, and the real solution is to face the music and create a new universal language for the web. During the transition period, fix the rot at the core, don't build on top of it like TS does. Fix JS.
Won't. Different domains mostly. Plus Go has advantages that makes it a perfect solution for very stable back-end. Different niche.
Typescript has always been r*tarded af, I have no idea why everyone jumped on that bandwagon. I've been programming for 20 years and can count on one hand the number of times I've tried to do math on a string by accident. It's a bad solution to a non-problem.
The simple 4-liner screenshot at 1:53 is quite possibly the dumbest thing I have ever seen.
Just a clarification, DrizzleORM did not drop TypeScript! They were trolling...
Had to scroll way too far to find this.
Good one. Drizzle ORM is all about TypeScript and is beautiful.
As much as I love TypeScript, I get what SvelteKit is doing. I can't speak for the rest of them, but TS is one tool among many. It's a meaningful engineering task to select the right tools for the job based on the software you're writing, the team you have, the audience you're writing for, and the technical realities of the rest of the project.
Problem starts when you have big project with undocumented types, parameters, you never know what the return type is (unless you check the implementation or console log)
JS should have introduced types long time ago.
@@arturschroeder2430 They use jsdocs so parameter/return/whatever types are still visible on hover and error checked in IDEs
@@arturschroeder2430 JS was made not to have types... adding types is like going back... Why use types of a language that was made not to have any types to begin with. Big projects dont require types. Types are only necessary in project which require a lot of complicated functions. I have entire social networks with React and NextJS with pure JS and have no trash boiler plate code. It depends on the priject, not its size.
@@maximiliandmcbecause obviously it was a mistake, the vast majority of bugs is type related which is insane.
@@PanosPitsi I find it insane how programmers cant handle basic typing bugs and cant make decent code without type checking.
My guess is that optional types will at some point arrive to JS, just like variables and nested selectors were added to CSS... But may also take time and it will probably not be as robust as Typescript.
Really, I believe TS usage will just continue growing and it will stay in the market for many years to come.
Just like python uses type hint for static type analysis
ts isn't going anywhere. Library creators are ditching it because they, unlike the users of their libraries, live in generics land where types aren't as useful anyway.
Optional types are better than nothing, but even those of us who appreciate type systems will often be lazy and omit them when they’re not required. Oh I know what I’m doing, it’s fine… hubris and a lack of consideration for the next person to work on your code are the undoing of us all
@@JohnDoe-my5ip They're just switching to jsdocs where instead of writing:
fun(param: string) {}
You write something like:
/*
params:
param: string
*/
fun(param){}
So they types are in the comment. Considering this is typescript and not an actual type safe language, you get all the same benefits without all the absolutely insane type gymnastics that are often seen in ts libraries.
It will be more robust than Typescript but will have less features.
I personally love having to explicitly type all my variables. It’s a lot easier to know what you’re dealing with. Especially if you use a lot of interfaces and extend them, you can easily go to the interface definitions to see the members. But it’s true that’s sometimes it can be a bit too much, especially combined with ESLint rules, and you end up having to use any or unknown. But for me, it should be really thought before putting that. Like a last resort.
I love TS because once you tell it what type something should be, it will proactively prevent you from making a mistake. These mistakes can cost you hundreds of man-hours if we're coding in untyped JavaScript... People who hate typescript are those who dont see the value of a strongly typed language.
I have a deep appreciation for typescript because it made javascript projects more maintainable and facilitated safer refactorings. I've worked with typescript daily since Angular 2 released in 2016 so I know my way around it pretty well. Having been a .NET dev before that and since then in a full-stack role, it's hard to be satisfied with Typescript when you write a lot of code in C# and Go. The type safety you get with those languages make Typescript feel like a hack. I'm even toying with the hot take that typescript IS a hack to make javascript more usable. Still, though, typescript is the best way to write web apps today.
I think you’re correct in your analysis.
But I think it is also good not to compare Typescript with other types languages. It acts differently and serves different functions.
You can do some really amazing dynamic things with typescript that is not possible in typed languages, like Template Literal Types. So I think it is beneficial to view it as a different tool altogether, and it has advantages over other typed languages, precisely BECAUSE it is built on top of an untyped language.
I actually feel the opposite way about C# vs TypeScript. TS does so much more inference that C# feels like I'm repeating myself constantly. With C#, I kinda see why the dynamic people hate static typing so much, though it has improved its inference capabilities a lot over the years. With TS, I feel like I get the best of both worlds: good type checking without all the repetition. It's almost as good as F#
Go only recently introduced generics and still seems to lack behind in terms of versatility
@@majahanson311 C# dev here, and I really wish they'd never introduced var (statically inferred type). Often times during a peer review when I see the result of a method assigned to a new variable of type var I end up having to call the dev who wrote it to ask what type that particular instance of var is.
@Luke5100 lol I’m 32, but I live in Atlanta, Georgia and .NET is king here. It seems like every tech company is a .NET shop here.
You can put as much lipstick on the pig as you want but at the end of the day it’s still JavaScript
I've always found if you are being forced into things like type gymnastics so often its causing headaches, most likely you have a code design problem. I learned static typed languages before JS/TS so learned to love and rely on strong typing. And as with anything there's always more than one way to skin a cat so if I'm being forced to do tedious stuff to keep the compiler happy that's a sign I need to take a moment and think about the design of my code. More often than not there's a perfectly elegant solution I just hadn't thought of yet.
well if, your solution is to use Any than so be it, just don't throw the baby out with the bathwater.
I think what he meant is that using TypeScript, you have to spend additional time thinking about things like what to name the types and whether or not you should have two different interfaces/types to represent two variants of the same input for different functions or just have one interface with optional properties... There are thousands of situations like that where TS forces you to think about the type of things or all the various ways to skin a cat (to borrow your own words) which can be distracting compared to JS where you are 100% focused on pure logic and automated tests; just go straight for the meat...
Who the hell cares about Sveltekit, turbo, etc. ... these are peanuts anyway ... why should we care what they do ...
I ALWAYS thought Typescript was a useless invention. My thinking was "It comes from Microsoft and seemed to be some new way to make people unnecessarily dependent on yet another invention from them." Most of my apps have 30-50 lines MAX in Javascript, and even that is too much already. Typescript is DEFINITELY NOT NEEDED for that. I'm just not that TYPE.
The time I spend writing types saves me far more time down the line. DHH's blogpost reads like someone who tried TS, didn't like it, and now bases decisions off of that one experience. The face that the PR was merged within a few hours of being opened despite the relevant objections is hilarious.
He just hates types period
its also really help in team projects, i can understand other people code easily by just looking at the types
He comes from Ruby, so yeah, that would explain a lot
dhh has always been like this and it's not surprising he did this. He's an insufferable prick.
These types of programmers measure code quality on how little code they have to read and write, not in how easy it is to maintain. Rails code often results in unexpected behaviors that are difficult to debug, but at least it looks pretty!
We just need to ditch JavaScript now
😂
maybe in an alternate universe
what's the alternative? (if you say rust or go you're stupid)
Honestly, I can ditch JavaScript but can't even think about ditching typescript. (For now) 😂
Please!
I use something similar to JSDoc for Lua called EmmyLua.
It's nice, but I'd still prefer a typed alternative like Luau at times because sometimes the IDE doesn't realise two data types don't match until it's actually tested. At a poece of code where other languages would have flagged it before you even tried to run it.
Was gonna say, this sounds a lot like when Roblox adopted Luau as the default (haven't touched Roblox Studio in years, but I kept up with the dev blog). Any time that types aren't directly built in to the fundamental syntax of the language, you're gonna have Undefined Behavior no matter how careful you are, especially once you get into user-defined types (the Instance gameobjects in Roblox) and trying to operate on them directly in code...
@@WackoMcGoose I've heard the language is decent
just a shame most games and apps still use Lua
even something like Wren or Squirrel would be more preferable at times for the same performance
Type annotations proposal doesn't make typescript obsolete, it tries to remove the build step. You still have to typecheck those annotations, that's what typescript is for. The proposal just provides a standard type annotation syntax for implementations to erase.
É importante considerar que, mesmo diante da desaprovação de algumas pessoas em relação às decisões dessas empresas, grande parte do debate em torno deste assunto parece ser motivado mais pelo fanatismo do que por argumentações concretas. O TypeScript, em muitos casos, tornou-se quase uma marca, semelhante à popularidade da Apple, onde muitas pessoas o utilizam sem realmente compreender completamente os motivos. É fundamental lembrar que a escolha entre TypeScript e JavaScript deve ser baseada em uma avaliação criteriosa das necessidades do projeto, em vez de seguir tendências cegamente. Flexibilidade e adaptabilidade são essenciais para garantir que a tecnologia escolhida atenda de fato aos objetivos e requisitos específicos de cada desenvolvimento. Eu fiz um post no inicio do ano sobre o porque eu não utilizo Typescript e porque a empresa onde eu trabalho resolveu retirar o Typescript do projeto. Acho no mínimo interessante ver que outras pessoas/empresas estão adotando a mesma medida.
Many people in the comments forget that typescript is not only giving you types features but whole lots of other features like enums, extended class functionality that reminds other OOP languages, attributes and so on and on...
yeah but enums are an antipattern in TS. have fun trying to extend/implement/compose enums. Not that you can do that in many languages, but if you simply use string literal unions instead, you get all the benefits of enums and all the extra power of normal TS types.
@@handlechar568 I agree on this one. As a TS developer you have flexibility to choose 💪
@@highiqandrational Thats an idea out of the blue with 0 arguments to support it. OOP helps to solve a lot of fundamental problems. Its reliable, secure (access modifiers in compiled languages), reusable. Pros list can go a long way...
@@highiqandrational
Your
Reasoning
Is
Garbage
My understanding of that proposal is for js to ignore type declarations so tools like TS can appear in vanilla JS. Not that it would absolutely remove the need for a type manager
You still won't be able to ship typescript to the browser as the proposal only allows for colon delaminated type declarations on variable declarations and function parameters. You will still have to configure a build step to strip out every other type-related construct. your type definitions, type casts, as const, etc. In addition, this proposal as it stands would preclude the addition of true types into javascript in the future. The syntax will already be in use, and turning these types from runtime ignored to runtime enforced / optimized would break any code utilizing them where the declared types and actual types have drifted apart over time.
Types should only be added to javascript when they are intended to be a full first-class addition.
Doing "gymnastics" to please the compiler is like writing bogus tests to please the coverage check. The types are there for a reason. You will be type-checked, either in production or during compilation, when you have an incident in production, you'll regret not having a compiler warn you there was a bug in your code.
FML. We're doing object oriented coding, no now we're doing functional programming. We're doing MVC patters, wait now we're doing components. Don't put your styles inline with your HTML, nevermind ONLY put your styles in HTML with TailwindCSS. People obsessed with patterns are demented.
The problem isn't JavaScript, the problem is you people using JS in the backend... It wasn't meant for that and it's so freaking obvious, if your code base is large enough you need a language that actually enforces types at compile time, we have use Java Spring Boot without hiccups for over a decade.
Amen brother!
Look who's back, it's AI Jeff ❤
I personally think it is time for JS itself to move forward. Things like optional types, better class support, loaders, annotations etc. should be added to vanilla. I overall really love to work with JS, but the basic feature-set is not up to date. Mixing TS features into JS would be out of my dreams. But at the pace that JS is evolving this may sadly take a decade at least.
JS evolving slowly is a feature.
@@Toleich Only for slow people.
Js was shite on arrival, how it grew to become the defacto language is... Depressing.
@@htspencer9084
It is like we got ass language like english to "lingua franca". Started from island where we got some latin, anglo saxon, old norse and gaelic mixed.
@@gruntaxeman3740 as a native English speaker: agreed! English is scuffed AF.
Javascript runtime bugs is the reason many backends have stopped using node.js and javascript, and you can't say "just write better code" in teams of multiple devs, who'll extend and modify your code.
So jsdoc helps with function calls, but what about variable declarations that cannot be reasonably done with inference alone?
The simplest and most productive solution would be to leave JS altogether and move to a more sophisticated language like C#.
It's not going to make TS obsolete because this ecma proposal introduces only syntax for adding types, but js engine will treat it as a comment. You'll still need TS for type checking
Which is a great combination. The type checking can then run in parallel while you develop and you don't have to wait for the latest compile to finish before testing.
My biggest issue with all of this, is that some of these projects are just dropping all type systems entirely. JS is extremely hard to use if you don't have types to reference because the LSP doesn't really expose the APIs. So rather than looking up definitions of the API functions/objects you have to either go to docs or read the code directly. Its clunky for a modern library/project. Drop TypeScript, but implement some kind of type system like jsdocs to make it so that people can easily use your APIs without having to leave their text editors. I don't especially like typescript but the turbo 8 decision is especially stupid.
Awesome name "type gymnastics", didn't think too much about it. But now that you mention it, I spend more time than I'd like to admit just trying to figure out what kind of type I have to write in order to make the red squiggly line to go away.
That being said, I still love Typescript and I feel naked when trying to code with vanilla js
0:22 "you have to be open minded" - took that guy 6 years to be open to TS lmao
People here in the comments don't seem to understand that they dont ditch type checking, they are exporting type checking to jsdoc instead.
Didn't know about the jsdoc standard for doing types and I can see why someone would move to it. I love Typescript and am sticking with it. I don't see the compile step as being that laborious personally. I spend way more time thinking through coding problems that waiting on compilers. But to each their own, if a project wants to remove the compile step while keeping most of the goodness of Typescipt I can see that.
Typescript is productivity killer
I've found the exact opposite.
I'd like to see you debug a million lines long javascript project. when you can't understand what type a particular variable is until you skip to the part where the variable is used/put some data into, you'll know the pain.
Static typing is also why C/C++/Java can be used for humongous projects and still are fairly debuggable and understandable by reading
I'm a firm believer in freedom, but I think modern workflow adds too many layers of abstractions.
I do like controlling my code, but for many projects the setup and maintenance take more effort than the core code itself.
never liked TypeScript or seen a need to use it, so I am glad to see big names make it clear again that not all of us NEED to use TS
Problem is that people do not want to write tests, they prefer to "compile" their amazing Typescript code because they don't have to write meaningful tests, because amazing green icon on build step said their code is perfect.
Tests do not replace typescript tho, unless you are willing to test each line of your code base for all possible TypeErrors
@@ex-xg5hh You would be surprised what PRs I have seen from "fellow" developers on my team. They have different opinion and typescript compile is already more than they would normally use. (I guess normally is just putting the code straight to production)
I: person: dont: present-emphatic-verb, negated think: intransitive verb people: object realize: verb how: start-subordinate clause unreadable: adjective type-hints: plural noun make: verb Python: noun unreadable: adjective.
Using TypeScript generics in *application code* to perform type gymnastics is generally straightforward. However, using generics in *library code* often requires an additional meta level of mental abstraction resulting in the _twisties._
I’ve never had the pleasure of writing a lib… how exactly does that change things vs an app?
@@alanschmitt9865 Because you need to support so many more different types in your generics for a lib than when you write application code.
Take the example of `const sum = (a, b) => a + b;` it might seem obvious at first for a and b to be numbers, but then you could also add strings to concatenate them, or support number-like protocols for a and b that are not the default number type of javascript...
The example is minimal on purpose, but in a library, you have to make types stay out of the way. The app can be overly restrictive on the types it can use in its functions, but the library has no idea of the purpose it's being used for, so it has to be more generic, eventually leading to type gymnastics.
@@alanschmitt9865 In an application you generally know the details of what you're passing around whether it's a user object, log event, or db connection. For much of the code you don't need to use generics because all your types are known ahead of time. With library code, on the other hand, you often times have no idea what crazy wacky stuff users might try passing into your library. The challenge is for your library to allow the user's IDE to infer useful type information even though you've never seen the user's type definitions.
That's true. The most optimal development performance and quality are achieved when using JS + .d.ts + JSDOC. This is especially true for projects that do not have a clear roadmap and requirements change frequently, which is common in agile teams. There is no need to type absolutely everything, but only public interfaces, and this can be done not immediately, but after you are sure that the implementation will end up in the final product. Typing in JS should be considered purely as documentation and not as a strongly typed programming language.
As documentation, the .d.ts file is just wonderful. You don't need to search the source code for exports and declarations or run the IDE to understand what's in the modules. You don't need to filter types in your head when you're looking at the logic of your code, which often takes up more space than the code itself.
I think the ideal thing for JS would be optional typing built around decorators. This way types could be checked statically by a linter in the IDE, and validated at runtime using the same type meta data.
People who hate strong typing never do debugging, especially on the big and complex project. It's true that is easier and faster to code without any strong typing, but it will take its toll when it's time to debug.
I have to refactor a huge PHP project with no type hinting, no interfaces and just passing random variables of any type around in multiple 1000+ line function collections. Arrays with unpredictable random keys that are only set somewhere in dozens of different functions that pass it around to each other makes it impossible to know what you have. God, I can't even rely on it actually being an array, I might suddenly get an object or a string back... that made me start also using JSDoc to its extreme inside our vanilla JS when there's no build step possible. All I really need added in JavaScript is strong typing, because nobody adding any way to track types anywhere is the primary cause of all our projects disasters.
There's Typescript for css now, to make css "type safe". Soon they'll introduce Type safe emails and type safe Coca Cola and then debate how we managed the two without "type safety".
I've seen more frontend webdev teams focusing on type gymnastics instead of things that actually matter - ux, accessibility, performance, functional tests, the fucking output.
Basically in front-end. In the back-end, if you need to do a lot of type gymnastics I believe you need to review your abstractions.
As far as i understood, Svelte is still using typescript but inside d.ts files and JSDoc comments. All they changes is the syntax not the toolset
@@gregor3099the svelte team very explicitly does not care about "code pollution" or whatever, jsdoc comments are a lot more verbose than regular typescript type annotations.
but as a library, not an app, they care about productivity and one thing you can do in javascript is just open the node_modules/ folder and edit a file there. and if you use a package manager like pnpm (maybe regular npm works for that too i don't actually know) for local development, you can link your dependencies to local directories and any change you do in the node_modules/ folder is directly reflected in the actual repository, and at no point do you have to have tsc --watch command or something running in the background.
also if you only have type checks on commits instead of literally any change ever you can quickly test something that would error normally (due to not-yet-defined types or whatever) but doesn't matter because it doesn't have to compile to run
Typescript is most definitely not a hype train only, it is extremely useful for developing big applications
It's not particularly useful when building libraries full of generics because you end up with more type definition code than actual code. It's just a hassle unless you like thinking and debugging through things like:
"Handler extends LocalHandler, Schema extends TypedSchema"
And that's a pretty simple example from a small and specialized library. It get's out of hand quick.
@@gileeeDid you see the PR where he removed typescript from the library? honestly he is just bitching about nothing because of his TDD fetish
@@omri9325 Yeah. But I honestly understand why they'd want to skip typescript in their use cases.
"my boss will abuse me physically and emotionally if I don't code up to his standard"
"It's not easy being self employed" 😂😂😂 I'm so dead
Nothing to see here. "Big libraries ditching TypeScript", proceeds to show Turbo [no, not the Vercel one], Svelte and Drizzle. I haven't even heard of two of those and I'm pretty confident those aren't used THAT MUCH in big, complex projects. Content like this is silly. The JS community is fragmented/undecided enough as it is, without videos like this adding fuel to the fire. Cheap sensationalism at best.
I love this. The world is kinda hell bent on making softwares slower than ever.
i always felt scripting languages should be strict enough that your code runs, but loose enough to use in a repl or console for R&D and fast prototryping. JS and Python are so fun for that reason. I think TS had its place for development teams with green programmers or projects that plan on a long shelf life, but if i can replace it with jsdoc id rather do that then have a whole new language people have to learn.
best comment here, and sadly ignored by everyone
I always just saw Typescript as a huge obstacle. It really just slows down development for me. If you write good enough tests while developing and keep things neat and simple, vanilla js is great.
I always just saw writing tests as a huge obstacle. It really just slows down development for me. If you write good enough code and use type safety of TypeScript, life is great.
Someone's never worked on an enterprise project
Agree. I use a system approach that I call BETLL. It's babel + eslint + testing + logging + lodash. And you have a perfectly stable, performant and maintainable app with pure JavaScript!
Theres a huge difference between library code and application code.. the benefits of js are more important for library code
so true
Yep, can't imagine jsdoc being practical for a big project.
Yep, a library I feel is a write implementation once sort of thing, ie you can’t refactor constantly without worrying about breaking changes, so you need to write a new version or a new method or class to extend functionality. So JSDoc is probably acceptable vs an application where it’s just faster to write and export types.
This is great to hear.
As a very pragmatic programmer who impulsively rejects any unnecessary semantic mess, I HATED using typescript.
Yaahsuure, compile type checking... preventing some issues.... blah blah
I have spent DAYS chasing down a skinning-the-yak madness exercise of fixing types just to get an extra parameter added to a function which would have been a minutes long exercise in JS.
And the extra always confusing build system... come on.
Keep it simple!
How is it okay for people to say “doing it this way is too hard” and be lionized? Hard things are the only f-ing things worth doing give me a break.
Writing types is like writing tests. You can skip the types/tests and save a tiny bit of your own time, but someone else might spend much more time making changes later. Alternatively, you can spend a little extra time writing types/tests, which could save tons of time for others , helping your colleagues and bettering the world.
Whether you choose to use typed code or not, it reflects the kind of person you are.
JSDoc just isn't nearly as powerful as TypeScript's type system.
I can never go back. I'd rather write type ceremony code that is more complex than my actual code than deal with the uncertainty you get when not using TypeScript.
I'm not sure if I'd understand the reasoning of the Turbo devs, but Svelte put it really nicely.
As an inhouse working on the framework, I would fight that decision a _little_ bit, but only a little.
As an contributor, I would be weirded out, but I think I'd ultimately appreciate it.
And as a user, I'd like it-straight up.
How would adding type annotations to native JS solve the type gymnastics problem? Wouldn't that just mean you have to do the same gymnastics, but now in native JS?
it's two different reasons from two different teams
The solution isn’t ditching Typescript. It’s adding type annotation to ECMAscript/vanilla JS.
I was using JS doc way before being forced to use TS at work, tbh yeah I can understand that type gymnastic thing, I do see the point of TS, I doubt it'll die, but I'll be leaning more toward native JS for personal projects, and keep using TS because my work require it and only for that reason
Can't believe how fast I clicked this video notification 😂
Same 😂
Typescript is purely for the anal-retentive types that enjoy spending more time writing definitions than actual code. JS is not a strictly typed language, TS is a false sense of security. TS is a nightmare when it comes to doing what JS is mostly used for, consuming web apis, and it makes promises twice as convoluted. I am pro optional doc blocks. End to end type safety just means you are updating types in 15 different places when you add an optional parameter to your request parameters. Your code should serve you, you should not serve your code.
Where do you get your videos, gifs and memes from? Is there a specific website you use?
I laughed too hard at 1:29
Idk from where you get these videos man. Never stop posting new videos!
If you code complex domains, still Typescript is the king. Literal types are the key to achieve parse don't validate principle. Also, types are great for applying always domain model.
I feel like the main reason they want to ditch TS is because by trying to fix JS, it made it worse.
Perhaps it would be better to focus more on Webassembly instead of keeping JS
I don’t think they made it worse when you look at how people perceive Typescript in the Stackoverflow surveys
@@BuyMyBeard I mean worse on some points, like the compilation step, messing around with types, etc...
I'm still on team typescript, but more and more I think we should ditch it for more stable programing languages. Typescript is a band-aid on a severed limb. It"s better than nothing, but we could go straight to a protesis instead.
Now webassembly can be compiled from nearly any languages, including javascript and typescript, and it also improve stability and compile time error checking instead of runtime errors
@@RustyNova to be fair it really is the best case scenario if javascript becomes typescript honestly. Javascript needs to stay a simple and easy dynamically typed language, but also support static types and detect problems with those. The thing is I don't think that will ever happen, so Typescript will probably be there to stay
It's time for CoffeeScript to shine
🤮
😏All these type kiddies don't know about CoffeeScript.
What is funny to me is, when I see all the examples of type “gymnastics”, all I can see are people that don’t like to use TS, using TS.
For example, why isn’t your “Subscribe” function referring to a named type, and or the callback? You’d be able to reference/reuse them and they’d also improve readability.
Also for recurring types like EmptyFunction you can create it once and reuse across the project.
Turbo’s removal of TS was a sole individual affecting the entire community, which was against and he knew it, simply because he didn’t like it.
Typescript is a pain late at night when you are using new libraries and you get a boat load of typing errors. It is a annoying and draining. We just need something fast and quick to put in production so we can proceed to writing test.