I think a large part of the increase in TypeScript usage is a social phenomenon. I've had the opportunity to work with some C# developers who had switched, either partially or fully, to doing front-end, and they seem to really love TypeScript, and also Angular 2+. My guess is that when more folks were coming from Python, PHP, and Perl backgrounds to JS, they didn't desire types, because their previous language did not have, or at least require, types. Now, I see a lot more C# and Java devs migrating to front-end, and the ones I worked with, almost to a person, are adamant about "needing" TypeScript. It's neither good nor bad, but all our intellectual arguments may be irrelevant to whether TS is good for JS. It may depend more on the background of your team.
This guy is awesome. I feel the same way In many cases. I think TypeScript and hardcore linting have their place, but I am a big fan of getting work done.
P.s. You also mention "i can code faster without TS", does that matter if your code is not correct and not easily maintainable? Like sure.. if you write your personal blog or whatever.. noone cares. If you create anything that is maintained by more than 2 people, speed doesn't matter as much. Do you also consider how often you will have to go back to fix little things you missed on parts of the code you didn't write because no one (as in the type system) complained about it? Idk about you but also, i write maaaybe 50 lines of code per day on average. figuring out where the bug came from takes sometimes half my day when working in JS.
I think typescript is a huge advantage if you write code for other programmers. You just bake 90% of the documentation right into the code. It isn't to make your own life easier but for everyone else who ends up using your code. I guess it doesn't work well for the frontend because the end user cares little about what datatypes you accept ;)
Actually in frameworks like react, typescript works really well. Or in any functional style UI framework. The whole UI code is f(state) -> Elements composed out of tens or hundreds of similar functions. Typescript gives you the safety when you are composing those functions, passing and returning the correct arguments and values etc. It helps a lot especially in frontend bcoz you need to save+rebuild+wait for the browser to re-load your changes and see the errors, using typescript you can see the errors as red squiglees right in your IDE before you do save+rebuild+wait for browser to re-load. GAINS!!
I appreciate hearing this. I'm a huge advocate of TypeScript, but it isn't for everything. I recently had a mail provider suddenly refusing to send mail from my Node server app, but since I had made and used a MailProvider interface, fixing that was literally a 1 line change - swap out a variable for a different class which implements MailProvider and deploy. Everything just worked. I certainly wouldnt have been confident in doing that with a JS app. But, for frontend, tooling and linters and all the other burden of setup make using TS a more difficult decision.
Typescript: agreed!! Linters: I agree that you don't want to waste your time adding spaces, changing let to const etc.. just to please the linter and get the dopamine hit - however if you set it up to "auto-fix on save" then all the fiddly stuff just disappears when you ctrl-s - leaving you to focus on the red squiggles that might actually cause you a problem.
I use Typescript in every project now. Just today at work, I did a lot of refactoring on a project we're using Typescript in and it made my life super easy. Could easily find what broke. The type-checking, documentation and autocomplete it provides are priceless. Once you go deeply with Typescript, you'd never go back
Can someone link to what Adam was talking about, where someone who may or may not have been Brendan Eich saying that, after doing a huge TypeScript project, will never do it again? Thanks!
I like type safety because it enables better tooling to be built around it, features like code completions, doc-hovers, finding references etc. have always worked better for me in type safe languages, and these things do save time. I do agree with what was said about code reviews.
The thing is once you get over a bump of configuring the ts linter, I feel that typescript vs javascript is getting into the idea of strong types vs duck typing and looking at implementation details is different for everyone. For me typescript is about intellisense, and building larger applications with more confidence in what is being returned especially when mutations become complex. The reality is that front end apps are now more complex and data mutation can be complex in a frontend app - Typescript gives me the ability to build a larger app with greater ease whilst being able to fall back to duck typing when I need to - this is great for creating mocks when testing for instance.
Typescript interfaces are really nice so you don't have to remember everything but when you have to chain together map, filter, reduce, etc., be ready for a fight.
A good type system is not about fixing / preventing bugs, it's about declarativity and readability. Good, functional type structures, like languages like Haskell, scala, kotlin provide, don't primarily fix bugs, but they let you think about your code in a different way. Concepts like immutability, interfaces, algebraic data types and typeclasses are a lot more relevant when you have a strong type system.... But that doesn't really help in frontend development. Frontend is rarely about managing amd analysing loads of data structures, that's what the backend is for. For frontend, types don't help as much. And typescript/flow are just bad implementations, because they introduce overhead. In languages like kotlin, Haskell, scala, the types don't really introduce overhead, because the concept of data flow doesn't work without them, they are integral to working. You can write code that speaks and tells you about it's purpose without ever writing actual functions, just by declaring your data. Afterwards, the only thing you'll need to do is connect the dots between those classes and objects. I think type inference, and concepts like data-classes / case classes, and furthermore concepts like pattern matching, are the key to a good and actually helpful typesystem. It's a different way of thinking, which does make less sense in web frontend than it does when doing your backend
@@insertoyouroemail big amounts of typing and verbosity. Typescript really Lacks on the Syntax front.. It needs some better way of having null-safe Actions (the proposed js ? Operator would fix this), and it needs some better Support for functional programming. The way you declare types for const foo = () => bar() is just hideous. I think the sweet-Spot for Web-frontend languages is Elm or purescript (depending On how much learning you want to do)... The Problem is that Javascript, being dynamically typed, doesnt Use that Feature to it's full Potential. To See dynamic types done right, try clojureScript
8:52 if you have to tell it to shut up, you are not using TS properly, you are trying to write JS in TS. Also yes, you can "enhance" your typings for ages, but who honestly does that ? i've written C# professionally for about 7 years, i don't just go create object hierarchies (and other complexity) just for fun, i do it when and where it's needed.
The part that Adam refers to is the prototyping phase, when you are trying things out, figuring out APIs etc. Having code-checking tooling at this part of the process just ends up being a huge distraction for me personally, and makes it harder to solve the core problem. If you're not easily distracted by things, I think you'll like TS a lot more - I personally is more of a minimalist, when I have complicated tools I just get distracted and I'm much more effective when I am able to focus on one problem at a time.
I really tried hard to change my mind but meh still in love with TS and linters 😅 few comments : 1- Linters are not only for catching bugs. to me their biggest value is code style. here is the rule: does it matter? if yes, make it clear and show the squiggly line. if not, then don't you dare comment about it on my PR. This alone saves A LOT of time wasted on useless, pointless discussions. 2- The ROI of 'setting up' linters is huge if you work in a 50+ developer environment. 3- they are NEVER expected to replace humans! Actually, my time is valuable so before I see your damn PR I want to make sure my input is as useful and effective as possible, linters take the 'lint' off so we can focus on the good stuff like logic. However, I do see the point of disabling linters in Editors. Not sure I can do it though 😁
Hey MPJ! Big fan. There is a NodeJS framework called Nest that is written in Typescript, though it works just fine with vanilla Javascript. It makes heavy use of Typescript decorators, which really helps to make writing server side services clean, and legible. See for yourself at their official docs: docs.nestjs.com/controllers A full stack framework that is starting to become popular is Angular as the front-end, and Nest as the back-end. Nest was actually heavily inspired by Angular, and a lot of the programming idioms carry over from Angular. This opens up the doors for front-end devs to contribute to the back-end, adding more agility to a team. Front-end devs can modify the servers data model and write their own GraphQL resolvers for example. The tooling and dev experience using VSCode + Angular + Nest I find to be amazing! Sometimes you want strict, contractual agreements. Using Typescript for both the front and back-end allows you to share a single interface between the two, finally solving the problem of bridging types for client-server communication. Typescript has its place guys. MPJ is just super zen about minimalism... and we all love him for it. ^_^ For those interested in this tech stack, the easiest way to get started is by using Nx: nx.dev/getting-started/getting-started
Tried both TS and Nest, I don't see any other reason to use something like Nest only if you come from something like java or C#) Using it feels like it so much overcomplicating and overengineering stuff just for so little improvements. Just my opinion and my experience.
I'm sorry, but this API seems horrible. Classes everywhere for things that have no business being classes, misunderstanding completely the functional nature of JavaScript. It seems like the worst part of TS - appealing to C# developers that want to write JS like C# instead of learning the nice parts of JS. :(
Great episode! I agree with the diss on linters but not typescript. typescript is awesome, i agree there is a learning curve and spending time on writing the types can feel a lot but in the end, you get REAL benefits apart from typesafety like readability and easy refactoring.
Nobody is claiming those benefits don't exist, we just both feel that the time invested is not quite made up by those benefits. Others disagree with us though so it's not clear cut.
Agreed 100%. Some folks get more out of Typescript than others, but I personally loathe inheriting a vanilla JavaScript project these days. It’s just not maintainable the way Typescript is. When people say they don’t see an ROI from it, they’re actually announcing they only build MVPs and pet projects
@@funfunfunction Yeah, there is a strong divide in the community. But can you give me a real world example from your work? I don't see how you would spend drastically more time on writing types in any project that may be at any scale. What would be your guess about the % of extra time you spend on writing types and using? 5%, 10%, 20%?
Ha, it never occurred to me that gamification/dopamine release triggers would influence what dev tooling is popular, but of course it would. So far in my experience, Typescript is a lot of overhead and I'll wait to see what benefit comes from it but if I had to venture a guess, I think it's being applied in because we have so little control elsewhere in the codebase - a comforting illusion to forget the mess around it. Also, I'll always choose iterative over perfect, and especiallly over being tricky & clever - I can't even keep clever code straight enough in my head to write it in the first place. Also also, human code reviews remain the best way I have found to flip your mind into the right sort of challenge, "wait, why did I write it this way?" I've caught so many typos, logical errors, and omissions in the read-through/writing the description prior to posting a PR - just the threat of human scrutiny is helpful for better revision.
Love this channel, long time subscriber and this is the only video that I have ever disliked, sorry for that. Personally love TypeScript , I think it gives much more advantages for the initial time cost of defining types/interfaces. Ok, so some quotes from the video that I disagree with, that were kind of just thrown in there like jokes maybe or just to diss on typescript, I don't know: 1. "You can typescript all day and actually not get anything done"; 2. "Iteration over perfection"(I guess because typescript slows down iterations); 3. "In frontend it's(typescript) a terrible choice"; Lets say we have a mid size to big...ish frontend app, it uses fifty or so REST endpoints, there is close to a hundred js services inside and a few hundreds of components. One day a task pops up from a good old backender: "For a very very very veeeeery important reason 'transaction' object .id property needs to be dropped and .uuid will be introduced". This is the central object of the whole app, a lot of stuff depends on it and nobody touched it in two years. So let's do this. JS app version: Two frontenders start to have heart palpitations ant take a few sick days off immediately. None of the junior devs can take this task because you need to know 'all the internals' to not break something 'by accident'. You need to find the most senior of the seniors who should know everything somehow(usually that person doesn't exist in real life), he ooooh he is definitely up to the challenge. Poor guy spends half of his day just checking and checking and rechecking where the hell transaction object is used. Tracking everything from services to components to templates... everything...by hand. By the end of the day he changed maybe 10 lines of code. Then the pull request reviewer does basically the same to be sure, but even after all of this, are they 100% sure? This PR looks so small, but it's so important. He approves. You need to deploy now. But you don't want to deploy. But you do deploy.... Now you watch your company chat app support channel like a maniac for the rest of the day, you don't blink, revert command is entered into terminal, your shaking sweaty finger is on ... You drive home, one eye on the road, the other eye - on support channel. You go to sleep...haha....what sleep, let's keep an eye on that support just in case. Your life shortened by a year that day. And for what? Such a simple change should not require this kind of work. Thats where TS comes in. TS app version: You find Transaction type/interface, you change it according to the task, 50ms later you see in your terminal a list 10 lines in 10 different files that need to be updated. Senior dev could do this task, junior dev could do this task, and probably an intern that came in this morning could do it. And everybody moves on to more important things in minutes instead of spending hours tracking what function calls what and how throughout the entire app. That's why you use this TypeScript thingy. To cut hours into milliseconds. To feel calmer, to sleep better:) So to get back to the quotes: You don't typescript your code just for fun or to perfect something for perfection sake. You do it to create connections between your code in such a way that TS compiler will tell you what your simple change can break... immediately. TS lets you iterate to new versions of your app without fear that you will break something. And most importantly not just you, but every single developer on your team can do quite complex changes to the app because in every single file they know how to use all the functions and what shape all the objects must have(IntelliSense), again, without fear that they might miss something somewhere in the process. So IMO its the opposite of 'terrible for frontend'. When these apps are getting bigger and bigger every day, TypeScript is a brilliant choice for frontend.
Preach, brother. I've never really understood the "extra" time cost argument for writing types. Everything you write in JS implicitly has those types; you're just keeping that type info in your head, where no one else can use it.
I'd agree with your example but the problem is that not every site/app is of such scale. In fact, I'd wager most projects are much smaller than where TypeScript would provide this advantage and so I think the debate is really defined by the scope of the project.
Or you just Use Elm or purescript. Not only can you be 100% confident in your types, but also any other changes you DO, while not actually having to Deal with any overhead introduces by that. Herman milner type-inference and ML Syntax to the rescue
Typescript slows me down tremendously. I generally don't use it when rapidly prototyping, but do if it's a team requirement and the use of it can be baked into task estimates 😆
@@error.418 Yeah? Might depend on the work or could be I'm stuck in my ways after 15 years in JS. My experience though is I'm *constantly* fighting with the tooling as Adam mentions. For the FE, the overhead of these problems outweighs the ROI - at least for quick UI-based projects and iteration between one or a couple of devs. That said if you're in multi-team projects, having devs follow a good set of guidelines, linters and Typescript are a good way of keeping quality at a serviceable and maintainable level.
So if TS and linters are too destructive for you, I think you should make configuration less restrict, so you will keep autogestion via IDE and other things which improve the development experience :)
This is a good point - during the periods where I found that linters ate murderous amounts of time for me, it was usually because the configurations were really encompassing, picking on spacing between function and parens and the like. Moving that kind of concerns into prettier made linters able to focus on actual errors and their value rose a lot. Unfortunately, I don't find that TS lends itself well to the same treatment - there is no minimal config and while typings are sort-of optional in TS and Flow I constantly feel like I'm not really doing things ideomatically when I try to keep types minimal.
When someone ask me how much time for that feature I reply: 2 o 3 days for dirty code. 5 days for cleaner code. 10 days with typescript. 20 days with tests. What I meant: *Dirty code*: Usually rushed, "productive" code without a statically typed language. You don't care too much about clean code, future maintainability, SOLID principles, etc. *Cleaner code*: Code that works and is also clean, "refactorized", well documented with proper function names, reusability in mind, trying to achieve SOLID principles, etc. Basically, not rushed code. *With Typescript*: Typescript and any other statically typed language usually makes you lose a lot of time for "non productive things", but in the long run it has less bugs and it's more maintainable. *With Tests*: Oh well writing tests.. I worked for a startup for the last decade and we never wrote them because the company didn't want to spend money on that. Our services are pretty solid considering we don't have any tests. Refactoring might be painful but we are very very careful. Anyways its a company decision. For my personal projects I never write tests because I don't feel productive but this may be a personal issue I have because my work experience. Software development is crazy, you can make something that works in 2 days or 20 days. That's 10 times more expensive. I want to add that python, php, ruby, javascript or any other dynamically typed language was invented because we needed a more productive way of coding. The statically typing trend going back feels weird, because clearly, it will take more time. Maybe big corps that already serve their web services with JAVA think that they needed typescript (because you can't avoid javascript) and continue being more stable and less productive.
Types don't make you unproductive. Bad, unproductive type systems do. Java does introduce a lot of overhead, because classescome with loads of boilerplate. Languages like kotlin really change that. Types don't take more time, because defining them is incredibly simple and declarative. For frontend they don't really help, because oftentimes you only use some datapiece once, so defining a type for it is annoying. But when working with data repeatedly it helps. And it allows things like algebraic data types / sum types which make code more readable
I like to use typescript for personal projects all the time. I also love C#. I really HATE rushing code. BUT, the sad truth no one tell you is that a lot of companies, especially startups, wants you to produce code as if you are a construction worker doing brickwork. Writing good code, clean code, good naming, extracting functions, SOLID principles, using types... all of that takes more time sadly even tho I really enjoy it. When I rush a feature because I feel like I wont deliver it ontime, good luck when you try to ask them that you need one more week to refactor that mess.
Yeah, in Swedish it's "Tor". It's hard to pronounce correctly for Americans so Thor was a natural adaptation. The sound for the Scandinavian o has no equivalent in English - "tour" is the closest that I can think of but still off.
I'd kinda like to know what you guys think about using heavily object-oriented frameworks like Angular considering you generally dislike TS. I know mpj said in one of recent twitch streams something along the lines that Angular is weird, but that's bit too broad. I'm asking because I'm working with this dude who has been programming about 15 years in OOP PHP and when he sees component-based JS frameworks (React, Svelte..) he claims they are just toys which he wouldn't use in huge enterprise apps since they lack things like DI containers, services, official support for MVC structures and instead of separating logic into multiple pieces they just bundle it into a single component. These are just the arguments I remember, there was more of these. I'm feeling bit down ever since I had this discussion with him since it's a person I respect and mentored me a lot in the past and it's a great guy in general. It's just that I don't know what to think of it anymore.
I prefer writing JS with latest core-js + flow over TS. So I configurate eslint to extend 'standard' rules and to use 'babel', 'flowtype', and 'json' plugins (got some little modifications to 'standard' and 'flowtype'). I also set the 'flowtype' plugin to only validate files with // @flow annotation. This means I can use type annotations where I want but you don't need to be absolutely perfect when starting to write some new code, and can later turn on eslint validation to get things cleaner. Being able to write type annotations can really save time (when not striktly linted), cause you can decide faster about function parameter names. When things get more complex, those names can remain simple without loosing 'context'. I'm using vscode, eslint auto fix on save ofc.
This is one of the more interesting comments here I think - many people just cite "but what about typescript benefit X" completely ignoring the we agree that static typing has benefits. In my mind, the question is how we get 80% of the benefits of TS type checking with 20% of the hassle that TS adds, and your approach might be a good step in that direction (I especially like your note on not strictly linted). I'll think about giving it a whirl!
One of the benefits of Javascript is that you can be super productive. Adding Typescript slows down the process and kind of goes against this. If it's a large system where security is imperative however, it can be a useful tool... provided it is acknowledged that it will slow down productivity.
only if you work alone in less than 1000 lines of code. as soon as people start changing stuff, and you don't have over 90% test coverage (most places have very few if any tests). then strongly typed languages shine. the bigger the codebase the bigger the advantage. static typing can answer questions like "is anyone in this project using this function/model/class". and if you decide to rename any of those it tells you right away what breaks instead of finding out you forgot to rename that function call in 3 obscure files. also with static typing you can distinguish between functions that reside in in different classes/files/modules but are called the same way. so when you ctrl+f stuff, there is less chance of error. It also allows you to create a function call map of what calls what where :)
I think we have to accept JavaScript as it is, so the same thing we have to do with all other languages. Not trying to adopt habits of previous language to a new one. Here is a good point about it: th-cam.com/video/QHs55-5FzgA/w-d-xo.html
If your job is mostly making videos and working on little short-term throwaway/demo projects, I can see TypeScript getting in the way. Especially considering with these projects the spec is is never changed after you start. But for anything big/serious/long-term, there's a reason that it's so popular, and why very few devs working on real projects go back to plain JS once they've got over the learning hump of TS. All the "it doesn't save that much time" arguments are very unscientific... it's super obvious to you when you're wasting time on TS stuff, but it's quite hard to measure the time it saves in the long term... because you're comparing the current fewer-problems reality (thanks to TS) to a fictional reality you just made up in your head, or memories from the past when you were still learning TS. These arguments are no different to the arguments made against docker, OOP, unit testing, CI, config management and pretty much anything that's new which takes time to learn. Programmers love talking about how things they don't know well are a waste of time. I know I've been guilty of it myself many times. TypeScript reports a lot of problems that have nothing to do with typing, and you can use as much or little TS as you like with the right tsconfig settings. Also intellisense/autocomplete is completely useless in a large project without TS. Without TS I either would have gone back to PHP or moved on to another language. One huge gain with TypeScript is how easy it makes refactoring... not just the "it's easier now" part... but it being easier means that you're much much MUCH more likely to refactor things rather than just not bothering at all. I did some refactoring yesterday in a couple of hours that likely would have filled a week at least otherwise. I find myself doing FAST improvement refactors quite regularly without breakages, that I just plain never would have bothered even trying to do without TS. So my long-term projects can easily stay sane and be maintained well, rather than becoming legacy piles of crap that feel like they should to be rewritten from scratch a few years later. Linters can be a waste of time, especially if they're nagging about pedantic syntax stuff like whitespace etc. But that's very different to TypeScript.
Just to be clear here - I worked for 5 years for one of the largest JavaScript codebases in the world (Spotifys desktop player) that changed around like crazy. I would also love types if I could get them without of all of the distractions that I think they bring with them. I have no problem with Docker, unit testing, CI etc (I do think OOP can be a massive procrastination timesink of epic proportion though) so putting these in here is making a straw man. I think both Docker and Unit Testing have very clear productivity wins. TypeScript, however, is just one of these things that I just don't find as clear cut. But I understand that people disagree, and that's fine, we're all different.
@@funfunfunction Fair enough, we all have our own priorities and preferences. I can see TypeScript being less important on frontends. Maybe my perspective is a bit skewed having done more backend stuff in the past. Wondering if you've worked on any big projects that did use TypeScript, in order to make the comparison? How long did you use it for? You mentioned working without it for 5 years, but not sure what you're comparing it with? That's what I was getting at with the analogies. I had a few doubting moments in my first couple of months using TypeScript, but can't imagine going back now. But fair enough for others not to agree. Big fan of your videos. I'm always learning new things from others, so I just like to know how they came to their conclusions in order to get the context, which further helps me learn more from them, and how relevant it might be to what I'm doing. And I've learnt lots from your videos, so I really appreciate your opinions. Also wondering if you would consider doing a video about Svelte, or more broadly the compiler -vs- runtime framework concept? I know you don't really do framework-specific videos generally, but the broader topic of the paradigm shift to a compiler is quite an interesting one, love it or hate it. Looks like Angular is doing something similar with Ivy too, so seems like a good topic about where some (even if only small) part of the JS ecosystem could be heading. So could be a good trending topic to talk about?
I think a large part of the increase in TypeScript usage is a social phenomenon.
I've had the opportunity to work with some C# developers who had switched, either partially or fully, to doing front-end, and they seem to really love TypeScript, and also Angular 2+. My guess is that when more folks were coming from Python, PHP, and Perl backgrounds to JS, they didn't desire types, because their previous language did not have, or at least require, types. Now, I see a lot more C# and Java devs migrating to front-end, and the ones I worked with, almost to a person, are adamant about "needing" TypeScript.
It's neither good nor bad, but all our intellectual arguments may be irrelevant to whether TS is good for JS. It may depend more on the background of your team.
This guy is awesome. I feel the same way In many cases. I think TypeScript and hardcore linting have their place, but I am a big fan of getting work done.
great to see your comment here, brad.
P.s. You also mention "i can code faster without TS", does that matter if your code is not correct and not easily maintainable?
Like sure.. if you write your personal blog or whatever.. noone cares. If you create anything that is maintained by more than 2 people, speed doesn't matter as much. Do you also consider how often you will have to go back to fix little things you missed on parts of the code you didn't write because no one (as in the type system) complained about it? Idk about you but also, i write maaaybe 50 lines of code per day on average. figuring out where the bug came from takes sometimes half my day when working in JS.
I think typescript is a huge advantage if you write code for other programmers. You just bake 90% of the documentation right into the code. It isn't to make your own life easier but for everyone else who ends up using your code. I guess it doesn't work well for the frontend because the end user cares little about what datatypes you accept ;)
Actually in frameworks like react, typescript works really well. Or in any functional style UI framework. The whole UI code is f(state) -> Elements composed out of tens or hundreds of similar functions. Typescript gives you the safety when you are composing those functions, passing and returning the correct arguments and values etc. It helps a lot especially in frontend bcoz you need to save+rebuild+wait for the browser to re-load your changes and see the errors, using typescript you can see the errors as red squiglees right in your IDE before you do save+rebuild+wait for browser to re-load. GAINS!!
I appreciate hearing this. I'm a huge advocate of TypeScript, but it isn't for everything. I recently had a mail provider suddenly refusing to send mail from my Node server app, but since I had made and used a MailProvider interface, fixing that was literally a 1 line change - swap out a variable for a different class which implements MailProvider and deploy. Everything just worked. I certainly wouldnt have been confident in doing that with a JS app. But, for frontend, tooling and linters and all the other burden of setup make using TS a more difficult decision.
I know I'm quite randomly asking but does anybody know of a good place to stream newly released series online ?
@Keanu Brooks I watch on FlixZone. You can find it on google =)
@Alejandro Nelson yup, have been watching on flixzone for years myself =)
@Alejandro Nelson thank you, signed up and it seems like a nice service :) I appreciate it !
@Keanu Brooks happy to help :)
Typescript: agreed!! Linters: I agree that you don't want to waste your time adding spaces, changing let to const etc.. just to please the linter and get the dopamine hit - however if you set it up to "auto-fix on save" then all the fiddly stuff just disappears when you ctrl-s - leaving you to focus on the red squiggles that might actually cause you a problem.
I use Typescript in every project now. Just today at work, I did a lot of refactoring on a project we're using Typescript in and it made my life super easy. Could easily find what broke. The type-checking, documentation and autocomplete it provides are priceless. Once you go deeply with Typescript, you'd never go back
Can someone link to what Adam was talking about, where someone who may or may not have been Brendan Eich saying that, after doing a huge TypeScript project, will never do it again? Thanks!
I like type safety because it enables better tooling to be built around it, features like code completions, doc-hovers, finding references etc. have always worked better for me in type safe languages, and these things do save time. I do agree with what was said about code reviews.
The thing is once you get over a bump of configuring the ts linter, I feel that typescript vs javascript is getting into the idea of strong types vs duck typing and looking at implementation details is different for everyone. For me typescript is about intellisense, and building larger applications with more confidence in what is being returned especially when mutations become complex. The reality is that front end apps are now more complex and data mutation can be complex in a frontend app - Typescript gives me the ability to build a larger app with greater ease whilst being able to fall back to duck typing when I need to - this is great for creating mocks when testing for instance.
Typescript interfaces are really nice so you don't have to remember everything but when you have to chain together map, filter, reduce, etc., be ready for a fight.
Using a linter is like stabbing yourself in the eye with a sharp stick because it feels good when you stop.
This is rad, as would Adam tweet.
You guys have such chemistry when talking about various topics, hope to see more from you guys
A good type system is not about fixing / preventing bugs, it's about declarativity and readability. Good, functional type structures, like languages like Haskell, scala, kotlin provide, don't primarily fix bugs, but they let you think about your code in a different way. Concepts like immutability, interfaces, algebraic data types and typeclasses are a lot more relevant when you have a strong type system.... But that doesn't really help in frontend development.
Frontend is rarely about managing amd analysing loads of data structures, that's what the backend is for. For frontend, types don't help as much. And typescript/flow are just bad implementations, because they introduce overhead.
In languages like kotlin, Haskell, scala, the types don't really introduce overhead, because the concept of data flow doesn't work without them, they are integral to working. You can write code that speaks and tells you about it's purpose without ever writing actual functions, just by declaring your data. Afterwards, the only thing you'll need to do is connect the dots between those classes and objects. I think type inference, and concepts like data-classes / case classes, and furthermore concepts like pattern matching, are the key to a good and actually helpful typesystem. It's a different way of thinking, which does make less sense in web frontend than it does when doing your backend
Very interesting perspective,thanks!
What overhead is introduced by TypeScript?
@@insertoyouroemail big amounts of typing and verbosity. Typescript really Lacks on the Syntax front.. It needs some better way of having null-safe Actions (the proposed js ? Operator would fix this), and it needs some better Support for functional programming. The way you declare types for const foo = () => bar() is just hideous.
I think the sweet-Spot for Web-frontend languages is Elm or purescript (depending On how much learning you want to do)...
The Problem is that Javascript, being dynamically typed, doesnt Use that Feature to it's full Potential. To See dynamic types done right, try clojureScript
@@leonk6950 ok, I'm with you a thousand percent on that. Only use purescript for personal projects and we use Elm+Haskell at work.
8:52 if you have to tell it to shut up, you are not using TS properly, you are trying to write JS in TS. Also yes, you can "enhance" your typings for ages, but who honestly does that ? i've written C# professionally for about 7 years, i don't just go create object hierarchies (and other complexity) just for fun, i do it when and where it's needed.
aliensarefromspace agreed.
The part that Adam refers to is the prototyping phase, when you are trying things out, figuring out APIs etc. Having code-checking tooling at this part of the process just ends up being a huge distraction for me personally, and makes it harder to solve the core problem. If you're not easily distracted by things, I think you'll like TS a lot more - I personally is more of a minimalist, when I have complicated tools I just get distracted and I'm much more effective when I am able to focus on one problem at a time.
I really tried hard to change my mind but meh still in love with TS and linters 😅
few comments :
1- Linters are not only for catching bugs. to me their biggest value is code style. here is the rule: does it matter? if yes, make it clear and show the squiggly line. if not, then don't you dare comment about it on my PR.
This alone saves A LOT of time wasted on useless, pointless discussions.
2- The ROI of 'setting up' linters is huge if you work in a 50+ developer environment.
3- they are NEVER expected to replace humans!
Actually, my time is valuable so before I see your damn PR I want to make sure my input is as useful and effective as possible, linters take the 'lint' off so we can focus on the good stuff like logic.
However, I do see the point of disabling linters in Editors. Not sure I can do it though 😁
Prettier formats the code on every save... just love it!
Hey MPJ! Big fan. There is a NodeJS framework called Nest that is written in Typescript, though it works just fine with vanilla Javascript. It makes heavy use of Typescript decorators, which really helps to make writing server side services clean, and legible. See for yourself at their official docs: docs.nestjs.com/controllers
A full stack framework that is starting to become popular is Angular as the front-end, and Nest as the back-end. Nest was actually heavily inspired by Angular, and a lot of the programming idioms carry over from Angular. This opens up the doors for front-end devs to contribute to the back-end, adding more agility to a team. Front-end devs can modify the servers data model and write their own GraphQL resolvers for example.
The tooling and dev experience using VSCode + Angular + Nest I find to be amazing! Sometimes you want strict, contractual agreements. Using Typescript for both the front and back-end allows you to share a single interface between the two, finally solving the problem of bridging types for client-server communication. Typescript has its place guys. MPJ is just super zen about minimalism... and we all love him for it. ^_^
For those interested in this tech stack, the easiest way to get started is by using Nx: nx.dev/getting-started/getting-started
Tried both TS and Nest, I don't see any other reason to use something like Nest only if you come from something like java or C#) Using it feels like it so much overcomplicating and overengineering stuff just for so little improvements.
Just my opinion and my experience.
Angular is not becoming popular... 2018.stateofjs.com/front-end-frameworks/overview/
I'm sorry, but this API seems horrible. Classes everywhere for things that have no business being classes, misunderstanding completely the functional nature of JavaScript. It seems like the worst part of TS - appealing to C# developers that want to write JS like C# instead of learning the nice parts of JS. :(
Great episode! I agree with the diss on linters but not typescript. typescript is awesome, i agree there is a learning curve and spending time on writing the types can feel a lot but in the end, you get REAL benefits apart from typesafety like readability and easy refactoring.
Nobody is claiming those benefits don't exist, we just both feel that the time invested is not quite made up by those benefits. Others disagree with us though so it's not clear cut.
Agreed 100%. Some folks get more out of Typescript than others, but I personally loathe inheriting a vanilla JavaScript project these days. It’s just not maintainable the way Typescript is. When people say they don’t see an ROI from it, they’re actually announcing they only build MVPs and pet projects
@@hawtpawkithero yes, a huge vanilla js project is an eye-sore at first sight, especially if it does not follow strict coding practices.
@@funfunfunction Yeah, there is a strong divide in the community. But can you give me a real world example from your work? I don't see how you would spend drastically more time on writing types in any project that may be at any scale. What would be your guess about the % of extra time you spend on writing types and using? 5%, 10%, 20%?
Linters help when a team has new engineers and more experienced ones - linters save time of the latter.
Ha, it never occurred to me that gamification/dopamine release triggers would influence what dev tooling is popular, but of course it would.
So far in my experience, Typescript is a lot of overhead and I'll wait to see what benefit comes from it but if I had to venture a guess, I think it's being applied in because we have so little control elsewhere in the codebase - a comforting illusion to forget the mess around it.
Also, I'll always choose iterative over perfect, and especiallly over being tricky & clever - I can't even keep clever code straight enough in my head to write it in the first place.
Also also, human code reviews remain the best way I have found to flip your mind into the right sort of challenge, "wait, why did I write it this way?" I've caught so many typos, logical errors, and omissions in the read-through/writing the description prior to posting a PR - just the threat of human scrutiny is helpful for better revision.
I love how natural this was!
Thanks for this video! I was setting up exactly this today.
Love this channel, long time subscriber and this is the only video that I have ever disliked, sorry for that.
Personally love TypeScript
, I think it gives much more advantages for the initial time cost of defining types/interfaces.
Ok, so some quotes from the video that I disagree with, that were kind of just thrown in there like jokes maybe or just to diss on typescript, I don't know:
1. "You can typescript all day and actually not get anything done";
2. "Iteration over perfection"(I guess because typescript slows down iterations);
3. "In frontend it's(typescript) a terrible choice";
Lets say we have a mid size to big...ish frontend app, it uses fifty or so REST endpoints, there is close to a hundred js services inside and a few hundreds of components. One day a task pops up from a good old backender:
"For a very very very veeeeery important reason 'transaction' object .id property needs to be dropped and .uuid will be introduced". This is the central object of the whole app, a lot of stuff depends on it and nobody touched it in two years. So let's do this.
JS app version: Two frontenders start to have heart palpitations ant take a few sick days off immediately. None of the junior devs can take this task because you need to know 'all the internals' to not break something 'by accident'. You need to find the most senior of the seniors who should know everything somehow(usually that person doesn't exist in real life), he ooooh he is definitely up to the challenge. Poor guy spends half of his day just checking and checking and rechecking where the hell transaction object is used. Tracking everything from services to components to templates... everything...by hand. By the end of the day he changed maybe 10 lines of code. Then the pull request reviewer does basically the same to be sure, but even after all of this, are they 100% sure? This PR looks so small, but it's so important. He approves. You need to deploy now. But you don't want to deploy. But you do deploy.... Now you watch your company chat app support channel like a maniac for the rest of the day, you don't blink, revert command is entered into terminal, your shaking sweaty finger is on ... You drive home, one eye on the road, the other eye - on support channel. You go to sleep...haha....what sleep, let's keep an eye on that support just in case. Your life shortened by a year that day. And for what? Such a simple change should not require this kind of work. Thats where TS comes in.
TS app version: You find Transaction type/interface, you change it according to the task, 50ms later you see in your terminal a list 10 lines in 10 different files that need to be updated. Senior dev could do this task, junior dev could do this task, and probably an intern that came in this morning could do it. And everybody moves on to more important things in minutes instead of spending hours tracking what function calls what and how throughout the entire app. That's why you use this TypeScript thingy. To cut hours into milliseconds. To feel calmer, to sleep better:)
So to get back to the quotes:
You don't typescript your code just for fun or to perfect something for perfection sake. You do it to create connections between your code in such a way that TS compiler will tell you what your simple change can break... immediately. TS lets you iterate to new versions of your app without fear that you will break something. And most importantly not just you, but every single developer on your team can do quite complex changes to the app because in every single file they know how to use all the functions and what shape all the objects must have(IntelliSense), again, without fear that they might miss something somewhere in the process. So IMO its the opposite of 'terrible for frontend'. When these apps are getting bigger and bigger every day, TypeScript is a brilliant choice for frontend.
Preach, brother. I've never really understood the "extra" time cost argument for writing types. Everything you write in JS implicitly has those types; you're just keeping that type info in your head, where no one else can use it.
I'd agree with your example but the problem is that not every site/app is of such scale. In fact, I'd wager most projects are much smaller than where TypeScript would provide this advantage and so I think the debate is really defined by the scope of the project.
Or you just Use Elm or purescript. Not only can you be 100% confident in your types, but also any other changes you DO, while not actually having to Deal with any overhead introduces by that. Herman milner type-inference and ML Syntax to the rescue
Conceptual vs Reality is like Wing Chun Kung Fu vs MMA.
Typescript slows me down tremendously. I generally don't use it when rapidly prototyping, but do if it's a team requirement and the use of it can be baked into task estimates 😆
Weird, it speeds me up since it offloads a lot of thinking as I go...
@@error.418 Yeah? Might depend on the work or could be I'm stuck in my ways after 15 years in JS. My experience though is I'm *constantly* fighting with the tooling as Adam mentions. For the FE, the overhead of these problems outweighs the ROI - at least for quick UI-based projects and iteration between one or a couple of devs.
That said if you're in multi-team projects, having devs follow a good set of guidelines, linters and Typescript are a good way of keeping quality at a serviceable and maintainable level.
So if TS and linters are too destructive for you, I think you should make configuration less restrict, so you will keep autogestion via IDE and other things which improve the development experience :)
This is a good point - during the periods where I found that linters ate murderous amounts of time for me, it was usually because the configurations were really encompassing, picking on spacing between function and parens and the like. Moving that kind of concerns into prettier made linters able to focus on actual errors and their value rose a lot. Unfortunately, I don't find that TS lends itself well to the same treatment - there is no minimal config and while typings are sort-of optional in TS and Flow I constantly feel like I'm not really doing things ideomatically when I try to keep types minimal.
When someone ask me how much time for that feature I reply: 2 o 3 days for dirty code. 5 days for cleaner code. 10 days with typescript. 20 days with tests.
What I meant:
*Dirty code*: Usually rushed, "productive" code without a statically typed language. You don't care too much about clean code, future maintainability, SOLID principles, etc.
*Cleaner code*: Code that works and is also clean, "refactorized", well documented with proper function names, reusability in mind, trying to achieve SOLID principles, etc. Basically, not rushed code.
*With Typescript*: Typescript and any other statically typed language usually makes you lose a lot of time for "non productive things", but in the long run it has less bugs and it's more maintainable.
*With Tests*: Oh well writing tests.. I worked for a startup for the last decade and we never wrote them because the company didn't want to spend money on that. Our services are pretty solid considering we don't have any tests. Refactoring might be painful but we are very very careful. Anyways its a company decision. For my personal projects I never write tests because I
don't feel productive but this may be a personal issue I have because my work experience.
Software development is crazy, you can make something that works in 2 days or 20 days. That's 10 times more expensive.
I want to add that python, php, ruby, javascript or any other dynamically typed language was invented because we needed a more productive way of coding. The statically typing trend going back feels weird, because clearly, it will take more time. Maybe big corps that already serve their web services with JAVA think that they needed typescript (because you can't avoid javascript) and continue being more stable and less productive.
Types don't make you unproductive. Bad, unproductive type systems do.
Java does introduce a lot of overhead, because classescome with loads of boilerplate.
Languages like kotlin really change that. Types don't take more time, because defining them is incredibly simple and declarative. For frontend they don't really help, because oftentimes you only use some datapiece once, so defining a type for it is annoying. But when working with data repeatedly it helps. And it allows things like algebraic data types / sum types which make code more readable
I like to use typescript for personal projects all the time. I also love C#. I really HATE rushing code. BUT, the sad truth no one tell you is that a lot of companies, especially startups, wants you to produce code as if you are a construction worker doing brickwork.
Writing good code, clean code, good naming, extracting functions, SOLID principles, using types... all of that takes more time sadly even tho I really enjoy it.
When I rush a feature because I feel like I wont deliver it ontime, good luck when you try to ask them that you need one more week to refactor that mess.
Hol'up, it's Thor (Thur) not Thor (Thor)? This is amazing
Yeah, in Swedish it's "Tor". It's hard to pronounce correctly for Americans so Thor was a natural adaptation. The sound for the Scandinavian o has no equivalent in English - "tour" is the closest that I can think of but still off.
I'd kinda like to know what you guys think about using heavily object-oriented frameworks like Angular considering you generally dislike TS. I know mpj said in one of recent twitch streams something along the lines that Angular is weird, but that's bit too broad. I'm asking because I'm working with this dude who has been programming about 15 years in OOP PHP and when he sees component-based JS frameworks (React, Svelte..) he claims they are just toys which he wouldn't use in huge enterprise apps since they lack things like DI containers, services, official support for MVC structures and instead of separating logic into multiple pieces they just bundle it into a single component. These are just the arguments I remember, there was more of these. I'm feeling bit down ever since I had this discussion with him since it's a person I respect and mentored me a lot in the past and it's a great guy in general. It's just that I don't know what to think of it anymore.
I prefer writing JS with latest core-js + flow over TS.
So I configurate eslint to extend 'standard' rules and to use 'babel', 'flowtype', and 'json' plugins (got some little modifications to 'standard' and 'flowtype'). I also set the 'flowtype' plugin to only validate files with // @flow annotation.
This means I can use type annotations where I want but you don't need to be absolutely perfect when starting to write some new code, and can later turn on eslint validation to get things cleaner.
Being able to write type annotations can really save time (when not striktly linted), cause you can decide faster about function parameter names. When things get more complex, those names can remain simple without loosing 'context'.
I'm using vscode, eslint auto fix on save ofc.
This is one of the more interesting comments here I think - many people just cite "but what about typescript benefit X" completely ignoring the we agree that static typing has benefits. In my mind, the question is how we get 80% of the benefits of TS type checking with 20% of the hassle that TS adds, and your approach might be a good step in that direction (I especially like your note on not strictly linted). I'll think about giving it a whirl!
@@funfunfunction Nice to hear that, thanks! :)
One of the benefits of Javascript is that you can be super productive. Adding Typescript slows down the process and kind of goes against this. If it's a large system where security is imperative however, it can be a useful tool... provided it is acknowledged that it will slow down productivity.
In practice, I completely disagree with you. TypeScript speeds me up since it offloads a lot of thinking as I go.
only if you work alone in less than 1000 lines of code. as soon as people start changing stuff, and you don't have over 90% test coverage (most places have very few if any tests). then strongly typed languages shine. the bigger the codebase the bigger the advantage. static typing can answer questions like "is anyone in this project using this function/model/class". and if you decide to rename any of those it tells you right away what breaks instead of finding out you forgot to rename that function call in 3 obscure files. also with static typing you can distinguish between functions that reside in in different classes/files/modules but are called the same way. so when you ctrl+f stuff, there is less chance of error. It also allows you to create a function call map of what calls what where :)
I couldn't agree more with everything said in the video!
Relevant South Park clip - th-cam.com/video/fv2ZMN3T18E/w-d-xo.html
I think we have to accept JavaScript as it is, so the same thing we have to do with all other languages. Not trying to adopt habits of previous language to a new one.
Here is a good point about it: th-cam.com/video/QHs55-5FzgA/w-d-xo.html
Really interesting thoughts to listen to!
If your job is mostly making videos and working on little short-term throwaway/demo projects, I can see TypeScript getting in the way. Especially considering with these projects the spec is is never changed after you start. But for anything big/serious/long-term, there's a reason that it's so popular, and why very few devs working on real projects go back to plain JS once they've got over the learning hump of TS.
All the "it doesn't save that much time" arguments are very unscientific... it's super obvious to you when you're wasting time on TS stuff, but it's quite hard to measure the time it saves in the long term... because you're comparing the current fewer-problems reality (thanks to TS) to a fictional reality you just made up in your head, or memories from the past when you were still learning TS.
These arguments are no different to the arguments made against docker, OOP, unit testing, CI, config management and pretty much anything that's new which takes time to learn. Programmers love talking about how things they don't know well are a waste of time. I know I've been guilty of it myself many times.
TypeScript reports a lot of problems that have nothing to do with typing, and you can use as much or little TS as you like with the right tsconfig settings. Also intellisense/autocomplete is completely useless in a large project without TS. Without TS I either would have gone back to PHP or moved on to another language.
One huge gain with TypeScript is how easy it makes refactoring... not just the "it's easier now" part... but it being easier means that you're much much MUCH more likely to refactor things rather than just not bothering at all. I did some refactoring yesterday in a couple of hours that likely would have filled a week at least otherwise. I find myself doing FAST improvement refactors quite regularly without breakages, that I just plain never would have bothered even trying to do without TS. So my long-term projects can easily stay sane and be maintained well, rather than becoming legacy piles of crap that feel like they should to be rewritten from scratch a few years later.
Linters can be a waste of time, especially if they're nagging about pedantic syntax stuff like whitespace etc. But that's very different to TypeScript.
Just to be clear here - I worked for 5 years for one of the largest JavaScript codebases in the world (Spotifys desktop player) that changed around like crazy. I would also love types if I could get them without of all of the distractions that I think they bring with them. I have no problem with Docker, unit testing, CI etc (I do think OOP can be a massive procrastination timesink of epic proportion though) so putting these in here is making a straw man. I think both Docker and Unit Testing have very clear productivity wins. TypeScript, however, is just one of these things that I just don't find as clear cut. But I understand that people disagree, and that's fine, we're all different.
@@funfunfunction Fair enough, we all have our own priorities and preferences. I can see TypeScript being less important on frontends. Maybe my perspective is a bit skewed having done more backend stuff in the past.
Wondering if you've worked on any big projects that did use TypeScript, in order to make the comparison? How long did you use it for? You mentioned working without it for 5 years, but not sure what you're comparing it with? That's what I was getting at with the analogies.
I had a few doubting moments in my first couple of months using TypeScript, but can't imagine going back now. But fair enough for others not to agree.
Big fan of your videos. I'm always learning new things from others, so I just like to know how they came to their conclusions in order to get the context, which further helps me learn more from them, and how relevant it might be to what I'm doing. And I've learnt lots from your videos, so I really appreciate your opinions.
Also wondering if you would consider doing a video about Svelte, or more broadly the compiler -vs- runtime framework concept? I know you don't really do framework-specific videos generally, but the broader topic of the paradigm shift to a compiler is quite an interesting one, love it or hate it. Looks like Angular is doing something similar with Ivy too, so seems like a good topic about where some (even if only small) part of the JS ecosystem could be heading. So could be a good trending topic to talk about?