Great walkthrough of the concepts! As a trainer of instructors, I'd like to recommend that you _progressively_ reveal your complex diagrams in your videos, for the same reasons that we avoid throwing all our bullet points on a single slide in slideshow presentations. You will intimidate fewer learners initially and you will _shepherd their attention_ where it needs to be, as it needs to shift. Less visual complexity, fewer distractions, lower emotional and cognitive resistance.
@@tantalus_complex Adding to this, I would like if there was a blend of both actually. I liked how he showed the entire diagram just so I have a mental map of how much more stuff he'd be covering. If I never saw the entire diagram, I'd have this internal 'uncertainty' on how much more stuff he'd be talking about. I think best solution would be to briefly showcase the whole diagram or so to let everyone know what all we'll be covering, and then you can zoom in to progressively reveal stuff like person above mentions.
@@aryan.prince I didn't want to go into depth about strategies here, but yes, you want to give _some_ kind of preview to "where we're going." I recommend digesting it down to a few on-screen bullets or steps or highlighted junctions of diagram. Save the complexity for the main content but do provide an overview in some form.
oh my god friend you will never believe how useful this video was for me and how many concepts you helped me to grasp ! Thank you very much , i love you i wish you the best
Nicely done. At first I was skeptical about how deep you would go, but I think this is a great start. I would love to learn more deep into it as well. Thanks
I would love to go deeper and will do so, packing all this into a single video is impractical - better to focus on one part at at time. What part do you want to see next? I will probably do HMR, it's the most fun part, what about you?
I would love to see more videos from you on all the topics you covered in this one. It would be awesome if you could make a series out of it. Thank you for your amazing work!
I finally found some good frontend content I like. I'll wait for your book. I'm a frontend developer but also have a lot of love for compilers. One thing that annoys me a lot is (frontend) developers not understanding the tools they work with. Knowing a little bit about what problem a tool solves and how, will translate into being more productive in the long term. It will also give you independence as you don't need others to help you with a tooling problem. Need your build tool to do something but can't find a plugin that already does that? No problem, just write it yourself! Also developer UX is a big thing for me. I feel like I can do so much more in less time, just because I know which tools to use and when. Keep making these videos, I'll keep watching!
Thanks Kevin! I am in the same boat as you, I did a lot of frontend development but am much more interested in tooling (front, back, whatever) - it's all the same concepts, really!
I think there are couple of inaccuracies though as per Vite docs 1. when you run vite build it doesn't do typechecking and doesn't use tsc - it uses esbuild to get rid of types. You need to do the typechecking yourself or add a plugin 2. when building, by default esbuild is used to minify JS
Definitely possible I made mistakes. I looked into your two points: 1. For type checking, I made a new react TS project. `npm run build` does this: > react-ts-vite@0.0.0 build > tsc && vite build So you are right, vite build does not do type checking. But many Vite templates will run tsc when you run a build step. Good point, thank you for pointing this out. 2. Did not check this in depth but I suspect you are correct. Wasn't expecting this vid to blow up so much, will definitely be more thorough in future! I think this still gives a good overview of the general tools but there is a lot more going under the hood.
Amazing video. It took me transitioning a CRA project to Vite while modernizing some of my build processes to even understand half of what goes on when building a React app. I wish I had this video then.
Very good! Not sure if visible in this chart, but one really interesting architectural feature of Vite to me was that during “dev”, this transpilation is being performed live on request (asynchronously) whereas the production build phase will pre-build/transform the code and save it to plain .js files. That’s partly why it’s so fast but also might explain some differences between how the dev generated references look (e.g. file paths) when compared to the bundled versions.
This is something I have always found a bit strange, too. Despite this, it generally works pretty well (amazingly) but I do hope that eventually dev/prod mode can use a single tool (maybe esbuild?) I will do more research and try to talk about this in the future entry in this series. Thank you for the comment and food for thought!
I've seen you before in some Vue related repos in Github, just wanted to say thank you for your OSS contributions! 🙏 This is a very insightful video. Sometimes I'd like to know more about Vue ecosystem packages' inner workings, and there's not much material around for easy consumption so the more we have, the better.
@@LachlanMiller If I may give a suggestion, one thing that always gets me is how the change detection / rerendering works in Vue. Coming from a React background, I had a lot of trouble until I understood more about it. But even after a long time with Vue, things like a computed returning the same value still rerendered the component was very surprising to me. It was finally "fixed" in 3.4, but that just shows how much I don't know about the subject 😂 There is a section in Vue docs about reactivity and rerendering but I feel like it does not go too deep into it, so more material about that would be great. Hope this comment is useful 🙇
Increadible content, looking forward to hear more from you. I will watch more of your videos and follow you. Good luck and thanks for awesome learning possibilities
The visual explanation is dope but I felt lack of something at the end like It was all theory-based. although it gave me some clarification about internals, showing some code can be useful too. great and unique content btw keep it up.
Great content, Lachlan! Love the explanation. I have issues with making dynamic imports work for me in Vite and your overview helped me to understand where I should investigate
Great video! Before this I just didn't know about vite but now I'd be more comfortable using it, especially the part about imports because that was some of the main issues that I had with js lol
The js module system is a complete clusterfuck, I made a video about it a week or two ago, if you have any specific content ideas around modules lmk - I know basically everything about the module system now from years of pain
Amazing! As an improvement I would like to suggest adding annotations to your diagram, e.g. jsx compilation arrow pointing to esbuild is labeled "dev", while the arrow pointing to tsc is labeled "prod"
@@LachlanMiller bit of both would be 👍, I do like vite but say I want to custom configure roll up options.. it can get a little tricky.. although I haven't spent a huge amount of time on it
Thanks for the comment! WebGL - yes, done a bit, love it. Wasm - did a bit, haven't got any use case but learned a ton, Rust - tried advent of code last year with Rust, this language is really hard 🤯
Great thsi what we need rolight now, understanding how tools works is really important. Would also love of you show how frameworks like vue, svelte, astro etc works behind the hood albeit with some code. Keep it up bro 👍👍👍👍 you earned a sub.
@@LachlanMiller you should, it could be even more amazing, cause you can use almost all type of frameworks with astro like use using react and qwick together in astro.
@@rajmajumdar5253 Oh neat, I didn't know I could integrate Astro with my other stuff. I will check this out! Qwik seems kind of weird, I don't see that much value in the reusability paradigm
Nice work bro! Awesome format and very rich content! There's some flickering in your background tho, idk if it's a fan turning above your head or it's the light source but it hurts the eyes 😅
@@LachlanMiller if you're not streaming, be sure to crank up the video bitrate a bit too. theres a lot of in depth OBS setup guides out there that'll help with your quality :)
@@MrNedinator Yep this was my mistake, I used to just do quicklime which defaults to 1080, apparently OBS does not do that. TY for the tip! No streaming for me, don't really see the value, I see more value in spending time to create a high quality, concise video 🚀
Great stuff. I am starting to hook on Vite. One important thing I hope Vite had out of box is Module Federation, which is quite essential to build micro-frontend. Do you have any idea how to build micro-frontend with Vite?
I had no idea that was even possible I still have the raw recording, but I don't think it is possible to replace an existing YT video :( Probably just going to live with it for now and be more careful moving forward!
Nice explanation, but... I expected from the preview "How Vite really works?" - this tool architecture breakdown, and why is it faster then webpack and what is the difference between architecture of esbuild.
Too much to pack in one video I will make more in depth on each of the parts soon. Even just learning one of the tools is a huge topic! Thanks for the encouragement, stay tuned for more ⚡️
You have awesome content.I am stuck on a problem plz guide me on I am implementing server-side rendering for a datatable (e.g., blog listing) in my Laravel project. I need to create a JavaScript file for this purpose. Should I place this datatable JS file in the public directory? If so, how do I compile the JS file from the resources directory to the public directory using Laravel Vite?Where should be the file placement in the folder structure. project-root/ ├── resources/ │ ├── js/ │ │ ├── app.js │ │ └── datatable/ │ │ └── blogListing.js ├── public/ │ └── build/ ├── vite.config.js ├── package.json └── ...
damn I would so much love to see this but I only have time after work hours and then I really physically can't look into bright white screens anymore. YT vids are where darkmode just fails.... uff had to scroll up even writing this. Maybe worth a consideration...
I work as frontend. I do work on projects that have similar or more complex tooling. I even had to implement some part of that on a internal tool. Where did we screw up? Why do we need so much of this just to write JS?
The main reason is, JavaScript was not designed to build these large complex applications! But it's the only language we've got the browser so we have to make do. All other languages and ecosystems have the complex tooling too - compilers, linkers, etc... it's just more mature and will add distracted, so you don't know about it 😅
"we strip type checking because it slows you down", like you could do it anyways, it's only static and not even JavaScript. TypeScript is just a linter
I think TS is a bit more than just a linter, though - it does do some transforms, like JSX, changing some syntax (like import -> require for cjs) but my understanding is the main bottleneck is the type checks.
TypeScript used to be more of a multi-purpose tool, like Lachlan mentions. These days its all about its type system and it lets other (better) faster tools solve the other problems. You still the want actual type checking process to run before you deploy to production, usually on a build pipeline where the build fails if type checking fails. Just as you probably want your linter to actually run on your pipeline, instead of just giving hints in your editor.
@@Kevin-xo5ul My one wish for TS would be a proper spec so all the other (faster) implementations could align more easily. Right now the "spec" is just looking at what the reference implementation does.
yes, doing frontend back in the day with no babel, no bundle, no types etc was a nightmare backend has this level of complexity too, it is just so well abstracted you don't get exposed to it
Hey, thanks for the video! Amazing content. One thing tho was not very clear to me: what do you mean by "in dev we do not care about type-check but in prod we do"? Thanks!
Hi! What I mean is when you are doing your general frontend development workflow in Vite (eg making components, layouts, styles) you want HMR as fast as possible. For this reason esbuild simply ignores or "strips out" the type definitions from your typescript - a type error will NOT prevent HMR from running. Vite calls this "transpile only". Read this point in the docs: vitejs.dev/guide/features.html#transpile-only You need to rely on your editor to show you type errors during development. When you deploy to production, we DO want as much type safety as possible, so the build will fail if there are issues.
@@LachlanMiller Good explanation, there are options like running the type checker in a separate terminal or as a child process, that way HMR is still blazing fast and you still get proper compilation errors in case your editor and extensions miss something. Usually not needed, but if you really want it there are options without slowing down your dev UX.
This video is one of the reasons I hate Javascript. It's so complicated. Add NX on top of this. I am facing a memory issue with tsc because of too complex types from Graphql objects. Hopefully webpack still compiles the code but then I have to figure out how to fix tsc part. 🤪🔫
Nx is way too complex for most projects Graphql is a whole other bag of worms - this isn't really JS specific though, is it? but yes, ecosystem is complex!
@@LachlanMiller all but one graphql library in Typscript are built that when you request properties of any object in a query, all the values can be null and undefined. It gets heavy quick.
Sorry for the quality folks, I'll figure out what went wrong and be in 1080p moving forward!
2k/4k screen-record with side by side windows via loom works the best.
Can you please share your vscode theme and setting
Great walkthrough of the concepts!
As a trainer of instructors, I'd like to recommend that you _progressively_ reveal your complex diagrams in your videos, for the same reasons that we avoid throwing all our bullet points on a single slide in slideshow presentations.
You will intimidate fewer learners initially and you will _shepherd their attention_ where it needs to be, as it needs to shift. Less visual complexity, fewer distractions, lower emotional and cognitive resistance.
@@tantalus_complex Adding to this, I would like if there was a blend of both actually. I liked how he showed the entire diagram just so I have a mental map of how much more stuff he'd be covering. If I never saw the entire diagram, I'd have this internal 'uncertainty' on how much more stuff he'd be talking about.
I think best solution would be to briefly showcase the whole diagram or so to let everyone know what all we'll be covering, and then you can zoom in to progressively reveal stuff like person above mentions.
@@aryan.prince I didn't want to go into depth about strategies here, but yes, you want to give _some_ kind of preview to "where we're going."
I recommend digesting it down to a few on-screen bullets or steps or highlighted junctions of diagram. Save the complexity for the main content but do provide an overview in some form.
What an amazing explanation! I’ve never heard someone explain how js compilation works in such a clear way. Thank you!
Glad it was helpful!
oh my god friend you will never believe how useful this video was for me and how many concepts you helped me to grasp ! Thank you very much , i love you i wish you the best
thank you!
This is soooooo helpful for people like me that love to know what is happening under the hood of these applications. Really appreciate the work done!
Nicely done. At first I was skeptical about how deep you would go, but I think this is a great start. I would love to learn more deep into it as well. Thanks
I would love to go deeper and will do so, packing all this into a single video is impractical - better to focus on one part at at time. What part do you want to see next? I will probably do HMR, it's the most fun part, what about you?
I would love to see more videos from you on all the topics you covered in this one. It would be awesome if you could make a series out of it. Thank you for your amazing work!
More coming! Thanks for the kind words!
Bro!!! This answered so many questions/problems nobody talks about since I looked at react years ago and now I have more questions 😭
I finally found some good frontend content I like. I'll wait for your book.
I'm a frontend developer but also have a lot of love for compilers. One thing that annoys me a lot is (frontend) developers not understanding the tools they work with.
Knowing a little bit about what problem a tool solves and how, will translate into being more productive in the long term. It will also give you independence as you don't need others to help you with a tooling problem. Need your build tool to do something but can't find a plugin that already does that? No problem, just write it yourself!
Also developer UX is a big thing for me. I feel like I can do so much more in less time, just because I know which tools to use and when.
Keep making these videos, I'll keep watching!
Thanks Kevin! I am in the same boat as you, I did a lot of frontend development but am much more interested in tooling (front, back, whatever) - it's all the same concepts, really!
I think there are couple of inaccuracies though as per Vite docs
1. when you run vite build it doesn't do typechecking and doesn't use tsc - it uses esbuild to get rid of types. You need to do the typechecking yourself or add a plugin
2. when building, by default esbuild is used to minify JS
Definitely possible I made mistakes. I looked into your two points:
1. For type checking, I made a new react TS project. `npm run build` does this:
> react-ts-vite@0.0.0 build
> tsc && vite build
So you are right, vite build does not do type checking. But many Vite templates will run tsc when you run a build step. Good point, thank you for pointing this out.
2. Did not check this in depth but I suspect you are correct.
Wasn't expecting this vid to blow up so much, will definitely be more thorough in future! I think this still gives a good overview of the general tools but there is a lot more going under the hood.
Amazing video. It took me transitioning a CRA project to Vite while modernizing some of my build processes to even understand half of what goes on when building a React app. I wish I had this video then.
thankyou!
This was super informative!
Keep up doing good stuff.
Thank you!
Very good! Not sure if visible in this chart, but one really interesting architectural feature of Vite to me was that during “dev”, this transpilation is being performed live on request (asynchronously) whereas the production build phase will pre-build/transform the code and save it to plain .js files. That’s partly why it’s so fast but also might explain some differences between how the dev generated references look (e.g. file paths) when compared to the bundled versions.
This is something I have always found a bit strange, too. Despite this, it generally works pretty well (amazingly) but I do hope that eventually dev/prod mode can use a single tool (maybe esbuild?)
I will do more research and try to talk about this in the future entry in this series. Thank you for the comment and food for thought!
Hey man, I really appreciate this videos. I just discovered your channel and I think I'll be going on a binge. The vue vs react video was also great.
thanks for the kind words!
Godspeed CRA, my loyal old friend. I'm hooked on Vite for months now.
I've seen you before in some Vue related repos in Github, just wanted to say thank you for your OSS contributions! 🙏
This is a very insightful video. Sometimes I'd like to know more about Vue ecosystem packages' inner workings, and there's not much material around for easy consumption so the more we have, the better.
Thanks! I want to try and make more content around the more advanced/interesting stuff
@@LachlanMiller If I may give a suggestion, one thing that always gets me is how the change detection / rerendering works in Vue. Coming from a React background, I had a lot of trouble until I understood more about it.
But even after a long time with Vue, things like a computed returning the same value still rerendered the component was very surprising to me. It was finally "fixed" in 3.4, but that just shows how much I don't know about the subject 😂
There is a section in Vue docs about reactivity and rerendering but I feel like it does not go too deep into it, so more material about that would be great.
Hope this comment is useful 🙇
very helpful, understanding how these stuff works, really helps me with imposter syndrome
Yeah me too, I have no idea what I'm doing, just figuring it out as I go 🤷♂
Thanks for the breakdown. Always good to know what features exist under the hood of frontend toolkits.
Increadible content, looking forward to hear more from you. I will watch more of your videos and follow you. Good luck and thanks for awesome learning possibilities
Working on next video in this series already, thanks for the feedback!
Very clear and straight to the point, thanks for the explanation!
No problem, I am not one to waste your time, just prefer to straight to the point
The visual explanation is dope but I felt lack of something at the end like It was all theory-based. although it gave me some clarification about internals, showing some code can be useful too. great and unique content btw keep it up.
I will go more deep into code next one! Thanks for the kind words!
Oh man, gold stuff sir ! I wish you can go deeper, but this stuff is a very great introduction already
thank you for the awesome video. can't wait for the book to come out!
me too!!! lots of work to do, I want to build a react like framework to go with it!
Great content, Lachlan! Love the explanation. I have issues with making dynamic imports work for me in Vite and your overview helped me to understand where I should investigate
Glad to hear I helped!
Awesome video would love to see more similar explanations for other tools!
More to come! ⚡️
This was SUPER informative! Thank you for dong this, I learned a lot and you're a great explainer :)
Thanks! More deep dive content soon!
Great video! Before this I just didn't know about vite but now I'd be more comfortable using it, especially the part about imports because that was some of the main issues that I had with js lol
The js module system is a complete clusterfuck, I made a video about it a week or two ago, if you have any specific content ideas around modules lmk - I know basically everything about the module system now from years of pain
Amazing! As an improvement I would like to suggest adding annotations to your diagram, e.g. jsx compilation arrow pointing to esbuild is labeled "dev", while the arrow pointing to tsc is labeled "prod"
Good idea! honestly I threw this together in about 10m - did not expect this many views!
More vite videos please 😊.. beyond the basic config it gets tricky
Sure thing, do you like the visual style or do you want to see more of the actual code base? Vite is ⚡
@@LachlanMiller bit of both would be 👍, I do like vite but say I want to custom configure roll up options.. it can get a little tricky.. although I haven't spent a huge amount of time on it
amazing video, never knew vite is doing so much work for us. great content, Keep it up!
Thank you! Vite is the best, it's fast ⚡
Great video! Glad I came across your content, looking forward to the release of your tooling book ✌
Thanks! I think it'll take the best part of the year to write.
You've got my subscribe. More videos like this please!
Very informative video
PS: I like your keyboard layouts
hi! what do you mean keyboard layouts?
This is gold
Super helpful, thank you!
Hey Lachlan great video. Would love the series of you deep diving on technology like rust, wasm and webgl.
Thanks for the comment! WebGL - yes, done a bit, love it. Wasm - did a bit, haven't got any use case but learned a ton, Rust - tried advent of code last year with Rust, this language is really hard 🤯
and also would love videos on JS testing frameworks too.
Very easy to understand and thorough, subscribed!
thanks!!
Great thsi what we need rolight now, understanding how tools works is really important.
Would also love of you show how frameworks like vue, svelte, astro etc works behind the hood albeit with some code. Keep it up bro 👍👍👍👍 you earned a sub.
Lots more "under the hood" on the way, especially for Vue/React which I know best. Svelte seems neat too, haven't tried Astro yet - should I??
@@LachlanMiller you should, it could be even more amazing, cause you can use almost all type of frameworks with astro like use using react and qwick together in astro.
@@rajmajumdar5253 Oh neat, I didn't know I could integrate Astro with my other stuff. I will check this out!
Qwik seems kind of weird, I don't see that much value in the reusability paradigm
Nice work bro! Awesome format and very rich content! There's some flickering in your background tho, idk if it's a fan turning above your head or it's the light source but it hurts the eyes 😅
I think it's the fan, I will turn it off next time 😎 thanks for the tip!
Thanks. Quality explanation.
Would love to see video about vitest
Me too, I don't know how it works really, but I will find out and make a vide about it
great content
1080p please
I thought OBS defaulted to 1080p, I must be doing something incorrectly. I will find out and fix it!
@@LachlanMiller if you're not streaming, be sure to crank up the video bitrate a bit too. theres a lot of in depth OBS setup guides out there that'll help with your quality :)
@@MrNedinator Yep this was my mistake, I used to just do quicklime which defaults to 1080, apparently OBS does not do that. TY for the tip!
No streaming for me, don't really see the value, I see more value in spending time to create a high quality, concise video 🚀
It was well explained and helpful
Thanks for this informative video.
Awesome!! Nice explanation.
Keep making such explainer videos ❤
Great stuff. I am starting to hook on Vite. One important thing I hope Vite had out of box is Module Federation, which is quite essential to build micro-frontend. Do you have any idea how to build micro-frontend with Vite?
Not sure about micro frontends! I have not worked with those before. Let me know iff you find out!
if you want, you can resample and upscale for 1080p, but its ok like it is rn ! top content :D
I had no idea that was even possible
I still have the raw recording, but I don't think it is possible to replace an existing YT video :( Probably just going to live with it for now and be more careful moving forward!
dont mind over this @@LachlanMiller
just keep producing more content like this :D
Nice explanation, but...
I expected from the preview "How Vite really works?" - this tool architecture breakdown, and why is it faster then webpack and what is the difference between architecture of esbuild.
Too much to pack in one video
I will make more in depth on each of the parts soon. Even just learning one of the tools is a huge topic!
Thanks for the encouragement, stay tuned for more ⚡️
You earned a sub. Great explainer
Thank you!!!
Amazing explanation!
I'm interested in understanding better how plugins integrate with vite
Good idea for more content - the plugin architecture is pretty neat actually, hopefully I can talk about it soon!
You have awesome content.I am stuck on a problem plz guide me on
I am implementing server-side rendering for a datatable (e.g., blog listing) in my Laravel project. I need to create a JavaScript file for this purpose. Should I place this datatable JS file in the public directory? If so, how do I compile the JS file from the resources directory to the public directory using Laravel Vite?Where should be the file placement in the folder structure.
project-root/
├── resources/
│ ├── js/
│ │ ├── app.js
│ │ └── datatable/
│ │ └── blogListing.js
├── public/
│ └── build/
├── vite.config.js
├── package.json
└── ...
Thanks for this video!
Thanks for the encouragement I appreciate it!!
Quality content. You gained a subscriber
Thank you!
Good one and to the point❤
Excellent
Tough af 💪 ❤
very usefull stuff. please make some deep concepts behind this
yes sir, coming soon. This stuff takes a while to make!
Great. Thanks.
damn I would so much love to see this but I only have time after work hours and then I really physically can't look into bright white screens anymore. YT vids are where darkmode just fails.... uff had to scroll up even writing this.
Maybe worth a consideration...
Sorry about that 🙁
Thanks
Thanks! Quite informative!
this video is very good. thank you for making this. can you please use a darker theme? It is hurting my eyes (I have sensitive eyesight issue)
Do you mean for the diagram or vscode?
Sorry to hear that, maybe Eraser has a dark mode...
Subbed, keep the content coming!
Working on more, this kind of content takes a bit more time than usual!
@@LachlanMiller quality over quantity, any day :)
YES!!@@al1gned
I work as frontend. I do work on projects that have similar or more complex tooling. I even had to implement some part of that on a internal tool. Where did we screw up? Why do we need so much of this just to write JS?
The main reason is, JavaScript was not designed to build these large complex applications! But it's the only language we've got the browser so we have to make do.
All other languages and ecosystems have the complex tooling too - compilers, linkers, etc... it's just more mature and will add distracted, so you don't know about it 😅
Great content🎉
Thank you!!
"we strip type checking because it slows you down", like you could do it anyways, it's only static and not even JavaScript. TypeScript is just a linter
I think TS is a bit more than just a linter, though - it does do some transforms, like JSX, changing some syntax (like import -> require for cjs) but my understanding is the main bottleneck is the type checks.
TypeScript used to be more of a multi-purpose tool, like Lachlan mentions. These days its all about its type system and it lets other (better) faster tools solve the other problems. You still the want actual type checking process to run before you deploy to production, usually on a build pipeline where the build fails if type checking fails. Just as you probably want your linter to actually run on your pipeline, instead of just giving hints in your editor.
@@Kevin-xo5ul My one wish for TS would be a proper spec so all the other (faster) implementations could align more easily. Right now the "spec" is just looking at what the reference implementation does.
what theme is that in vscode btw nice video
Thanks, it is Egoist One
Incredible content keep it up please
Thank you for the kind words!
Youre a legend
I've seen a bunch of your OSS work on your GH you are the real legend
Do you believe we need this level of complexity on the front-end side?
yes, doing frontend back in the day with no babel, no bundle, no types etc was a nightmare
backend has this level of complexity too, it is just so well abstracted you don't get exposed to it
Great!
Hey, thanks for the video! Amazing content. One thing tho was not very clear to me: what do you mean by "in dev we do not care about type-check but in prod we do"? Thanks!
Hi! What I mean is when you are doing your general frontend development workflow in Vite (eg making components, layouts, styles) you want HMR as fast as possible. For this reason esbuild simply ignores or "strips out" the type definitions from your typescript - a type error will NOT prevent HMR from running.
Vite calls this "transpile only". Read this point in the docs: vitejs.dev/guide/features.html#transpile-only
You need to rely on your editor to show you type errors during development.
When you deploy to production, we DO want as much type safety as possible, so the build will fail if there are issues.
@@LachlanMiller Good explanation, there are options like running the type checker in a separate terminal or as a child process, that way HMR is still blazing fast and you still get proper compilation errors in case your editor and extensions miss something. Usually not needed, but if you really want it there are options without slowing down your dev UX.
@@LachlanMillerI understand now, thank you very much!!!
This video is one of the reasons I hate Javascript. It's so complicated. Add NX on top of this.
I am facing a memory issue with tsc because of too complex types from Graphql objects. Hopefully webpack still compiles the code but then I have to figure out how to fix tsc part. 🤪🔫
Nx is way too complex for most projects
Graphql is a whole other bag of worms - this isn't really JS specific though, is it?
but yes, ecosystem is complex!
@@LachlanMiller all but one graphql library in Typscript are built that when you request properties of any object in a query, all the values can be null and undefined. It gets heavy quick.
Vitest is a nightmare
What issues are you having?
I found it a bit buggy but it is nice and quick, and particular problems you've had?
@@LachlanMiller frequent running out of memory, debugging is pain in the ... Many are facing the same problems