Thanks for that presentation. Very clear and interesting. I loved how you went out of your comfort zone too and added entertainment to the information. Great stuff!
@@Cognitoman do you really think it slows down development? I have found my JS development to be much faster. I don't use the strictest type settings. It prevents lots of not immediately apparent errors that slow down development. I've also found it makes the code more changeable. Because you don't have to refamiliarise yourself with old code ro interface with it safely.
@@Cognitoman The tradeoffs are worth it. Unexpected behaviours are common mistakes even advanced programmers encounter, whereas changing your mental model and writing TypeScript is a learning experience that can make development faster and more confident.
While typescript does make it easier to scale your code, it does come at the cost of not being able to do some of the really wacky things. For example, it doesn't like to have circular references in namespaces which is something that would be extremely useful to ensure people hooking into typescript is able to use the importing style that they prefer. It also makes it difficult to lazy load modules as typescript likes to load things at startup which can slow down the startup load time of your module.
Lazy loading modules works great with dynamic import or React lazy with TS. Like in an async function just go with const module = await import(‘some/package’); and your good. Or within your TSX file with React lazy in combination with Suspense is good too.
The talk itself is quite nice, but I', still not sold on Typescript. Overhead is huge and the example Brie gives can (and should) be checked by unit tests. Typescript in no way not replacing unit tests, and people who are selling it continues to sell it as some kind of magic wand to solve all the problems, so if you are using TS you don't need to write tests. Which is just straight bad. From the other hand, TS gives you some kind of design principles you've got to follow, and with time you start to write Java instead of JS. For example, try to type any higher order function - there is simply no way to do that without having bloated and overcomplicated code. We change beauty and elegance of JS for bloated and unnecessary TS. People, wake up!
TypeScript is really liberating to use when you're working with a team. I really think that It actually makes most tasks faster because of the auto-completion & refactoring features. With React 16.8+ you're not really manually typing things much anymore. A lot of types are already inferred and those that don't are stuff you probably should be self documenting anyways such as asynchronous fetches and props (which you probably already do through the PropTypes package). TypeScript is a great safeguard for avoiding most common errors (e.g. team members using functions made by other team members and expecting different return types). Refactoring also becomes 100x easier. Autocompletion is a godsend as well because it eliminates the need to remember all the properties on objects, meaning less mental strain on keeping a bunch of. Jump to definitions are also great. Also do remember that your projects don't have to be 100% in TypeScript. You can use "any" to stub types if you don't know what they are, or, more crudely, use "// @ts-ignore" I know you mentioned higher order components, just as a reference we use the following syntax: "export default function withHOC(WrappedComponent: React.ComponentClass) {...}"
I tend to disagree, slightly. I'm part of a fast-moving consulting team that pumps out a lot of blockchain proof of concept projects in javascript. Javascript is usually one of the first languages that are supported on open source blockchain platforms (or open source blockchain interaction libraries). Teams usually aren't very big and pressure is quite high. I've seen people come and go (mostly young people between 20 and 25). I've tried to keep everyone on a certain baseline of code styles and code quality but I notice that, due to a lack of attention or skills, these styles and qualities don't last long if they don't stick. We're trying to fix it with free and easy solutions, sometimes devops pipelines, but unfortunately, there isn't always budget or time to do a completely bug-proof setup. We haven't moved to typescript yet, but I do see that my own code sometimes has undiscovered edge cases that weren't handled correctly. I personally think typescript is more beautiful than javascript because it gives me a more satisfying feeling of knowing that everything (be it parameters, return types, etc) are all checked from start to finish. I feel more comfortable relying on the typescript compiler than my own tests (since I'm not the best tester or don't know what needs to be tested).
I don't know how much you've used TypeScript in the past, but it seems to me that you've got the wrong impressions from somewhere. TypeScript by no means replaces unit tests, but can replace the need for runtime type checks (given that you're working with private APIs or projects, that are going to be consumed by TypeScript) I have used TypeScript, and migrated TypeScript-very similar to the strategy that AirBnb chose-and we have seen many benefits from it, albeit a less than steep learning curve for newcomers. It's inevitable that you will run into unexpected behaviours such as undefined values, etc., which TypeScript makes easy to discover and fix. On top of that, we decided to not think about TypeScript as a way to add extra inheritance. We embrace composability and TypeScript works very well for us in that regard. We use it for both our frontend (React + Apollo) as well as backend services and our other shared packages-all of which have (and are required to have) unit tests, integration tests and end-to-end tests. It really helps with understanding the data you work with, without having to consult to external (and sometimes out-dated) documentation. It makes us more confident in the code that we ship won't break a build. Regarding typing higher-order functions, I don't know what your frustation is with it, as you didn't provide an example. TypeScript has even added better typing support for functions like pipe, compose, etc. with arbitrary amount of functions passed to arguments. I would recommend you to go check out the official documentations, follow the growing community and make sure that you listen to the right people (like the people who create TypeScript and its features) before making up your mind.
I will not say it is there to replace test cases, but help you write less yet better test cases, test cases that will test the logic, of course some of the examples she gave we can catch it when running test, but isn't catching it during typing code is better than have to wait until we can only discover it run the test cases? Again, using typescript or any static typed language doesn't mean we wont have to write any test cases.
Thanks for that presentation. Very clear and interesting.
I loved how you went out of your comfort zone too and added entertainment to the information. Great stuff!
Absolutely phenomenal talk. I shared it with all of my students and junior devs.
Man everyone is shoving typescript down our throats, is it really as good as they say?
Zah it’s hype like everything else ... it’s good to learn but makes development slower
@@Cognitoman do you really think it slows down development?
I have found my JS development to be much faster. I don't use the strictest type settings. It prevents lots of not immediately apparent errors that slow down development.
I've also found it makes the code more changeable. Because you don't have to refamiliarise yourself with old code ro interface with it safely.
@@Cognitoman The tradeoffs are worth it. Unexpected behaviours are common mistakes even advanced programmers encounter, whereas changing your mental model and writing TypeScript is a learning experience that can make development faster and more confident.
Awesome presentation, great pace, great level of background
All JS code was converted to TS code in a PR with 38k lines changes.
But the codebase contains 2M+ LOC.
What am I missing?
22:02 wth happened xD
ts-migrate can help a lot of small companies to migrate their codebase in typescript. I would love to try it if ever it gets public.
ts-migrate was publicly released last month: github.com/airbnb/ts-migrate
probably can get up to 50% when coupling it with a sonarqube server
wonderful presentation!!
Great Presentation!!
While typescript does make it easier to scale your code, it does come at the cost of not being able to do some of the really wacky things. For example, it doesn't like to have circular references in namespaces which is something that would be extremely useful to ensure people hooking into typescript is able to use the importing style that they prefer. It also makes it difficult to lazy load modules as typescript likes to load things at startup which can slow down the startup load time of your module.
Circular dependencies maybe aren't a good idea, but since 2.4, TypeScript has support for dynamic import()
If your code _depends_ on circular dependencies, you have way more problems than TypeScript.
Lazy loading modules works great with dynamic import or React lazy with TS. Like in an async function just go with const module = await import(‘some/package’); and your good. Or within your TSX file with React lazy in combination with Suspense is good too.
Excellent talk! :)
thanks for the upload!
"Brie Bunge" sounds like the name of a super hero's best friend
Anyone know when tsmigrate might be open sourced?
They just put it out! I am super stoked!
but AirBnB left react native to adopt native. Where they are using TS ?
their website
server? Node?
Can't wait for TS Migrate to be open sourced.
@Vedran B Yeah, I know. But "TS Migrate" is not yet open source.
typescript is really awsome and cool
The talk itself is quite nice, but I', still not sold on Typescript. Overhead is huge and the example Brie gives can (and should) be checked by unit tests. Typescript in no way not replacing unit tests, and people who are selling it continues to sell it as some kind of magic wand to solve all the problems, so if you are using TS you don't need to write tests. Which is just straight bad. From the other hand, TS gives you some kind of design principles you've got to follow, and with time you start to write Java instead of JS. For example, try to type any higher order function - there is simply no way to do that without having bloated and overcomplicated code. We change beauty and elegance of JS for bloated and unnecessary TS. People, wake up!
TypeScript is really liberating to use when you're working with a team. I really think that It actually makes most tasks faster because of the auto-completion & refactoring features. With React 16.8+ you're not really manually typing things much anymore. A lot of types are already inferred and those that don't are stuff you probably should be self documenting anyways such as asynchronous fetches and props (which you probably already do through the PropTypes package). TypeScript is a great safeguard for avoiding most common errors (e.g. team members using functions made by other team members and expecting different return types). Refactoring also becomes 100x easier. Autocompletion is a godsend as well because it eliminates the need to remember all the properties on objects, meaning less mental strain on keeping a bunch of. Jump to definitions are also great.
Also do remember that your projects don't have to be 100% in TypeScript. You can use "any" to stub types if you don't know what they are, or, more crudely, use "// @ts-ignore"
I know you mentioned higher order components, just as a reference we use the following syntax: "export default function withHOC(WrappedComponent: React.ComponentClass) {...}"
I tend to disagree, slightly. I'm part of a fast-moving consulting team that pumps out a lot of blockchain proof of concept projects in javascript. Javascript is usually one of the first languages that are supported on open source blockchain platforms (or open source blockchain interaction libraries). Teams usually aren't very big and pressure is quite high. I've seen people come and go (mostly young people between 20 and 25). I've tried to keep everyone on a certain baseline of code styles and code quality but I notice that, due to a lack of attention or skills, these styles and qualities don't last long if they don't stick. We're trying to fix it with free and easy solutions, sometimes devops pipelines, but unfortunately, there isn't always budget or time to do a completely bug-proof setup.
We haven't moved to typescript yet, but I do see that my own code sometimes has undiscovered edge cases that weren't handled correctly. I personally think typescript is more beautiful than javascript because it gives me a more satisfying feeling of knowing that everything (be it parameters, return types, etc) are all checked from start to finish. I feel more comfortable relying on the typescript compiler than my own tests (since I'm not the best tester or don't know what needs to be tested).
I don't know how much you've used TypeScript in the past, but it seems to me that you've got the wrong impressions from somewhere.
TypeScript by no means replaces unit tests, but can replace the need for runtime type checks (given that you're working with private APIs or projects, that are going to be consumed by TypeScript)
I have used TypeScript, and migrated TypeScript-very similar to the strategy that AirBnb chose-and we have seen many benefits from it, albeit a less than steep learning curve for newcomers. It's inevitable that you will run into unexpected behaviours such as undefined values, etc., which TypeScript makes easy to discover and fix. On top of that, we decided to not think about TypeScript as a way to add extra inheritance. We embrace composability and TypeScript works very well for us in that regard. We use it for both our frontend (React + Apollo) as well as backend services and our other shared packages-all of which have (and are required to have) unit tests, integration tests and end-to-end tests.
It really helps with understanding the data you work with, without having to consult to external (and sometimes out-dated) documentation. It makes us more confident in the code that we ship won't break a build.
Regarding typing higher-order functions, I don't know what your frustation is with it, as you didn't provide an example. TypeScript has even added better typing support for functions like pipe, compose, etc. with arbitrary amount of functions passed to arguments.
I would recommend you to go check out the official documentations, follow the growing community and make sure that you listen to the right people (like the people who create TypeScript and its features) before making up your mind.
I will not say it is there to replace test cases, but help you write less yet better test cases, test cases that will test the logic, of course some of the examples she gave we can catch it when running test, but isn't catching it during typing code is better than have to wait until we can only discover it run the test cases? Again, using typescript or any static typed language doesn't mean we wont have to write any test cases.
Trucidare aren’t HOCS dead in the post React Hooks age ? Welcome useWhatever 😁.