I cannot emphasize how important & rightly timed this video is for me. I am literally working on a project, and embarrassing it may sound the chunks are oversized. Saw this video and my bundle sizes are literally the smallest in the team. Your hard work is commendable! Thanks Jeff... Looking forward more to you reading my mind 😄
Im loving vite and the other new js frameworks like astro etc. It’s painful to have to face so many new frameworks in the js ecosystem. But it seems we’re moving in the right direction. Hopefully we’ll be a bit more settled in the future.
If looking at all this framework is the right direction, than that's why web is so doomed. Solving same existing problems for years but in different framework.
are you in my house? I'm literally working in a project with vite using the react template and firebase And i had the exact same problem 🤯 thank you so much for the amazing content
A benefit to browser-side frameworks is that the whole package is very easy to cache. Why load anything at all? Offering Overview is 676 bytes per page load after the first load, and could be slimmed down more by moving the inline JS back to its own file.
I used to wonder why people did _"code golf"_ exercises. Now I know why. A little _"code golf"_ is something more people should practice. You'd be surprised how few bytes may actually be necessary to implement your functionality.
@@4.0.4 For sure smaller is not faster - loop unrolling for example - In theory the fastest program would just be one giant map of inputs to outputs, very large in size, very fast to execute. Yet smaller programs are typically easier to understand and reason about, and are often more flexible in terms of adding features or reusability. Those qualities lead to faster overall systems in the long run, because if individual code modules aren't flexible and easy to reason about, the entire system will eventually get slow due to compromises in its design... More people should do code golf so they can get positive experience with that "flavor" of programming.
Just wondering, don't dynamic imports eliminate the bundler's ability to statically analyze what code is used and therefore eliminate tree shaking for that entire import? From my understanding of tree shaking, it only works for es2015 style imports to statically analyze what is used and eliminate dead code from the bundle. If you are only using one functionality from firebase, tree shaking should only include the code for that one functionality, but if you import it dynamically then it has to include the entire package code in your final bundle. Am I missing something here?
the import() function returns a promise containing the entire module, if you only want one part of it you do import('firebase').then(f=>f.onUpdate) for example, but its still requested the entire firebase module, so you may end up shipping more code to the browser. Unless Vite has a smart way of figuring out what you actually use and then removing dead code??
haven't tried it yet but i guess you can static import into a file than dynamic import that file. also for some packages, you can pas specific path into dynamic import like import('package/path/to/function') instead of import('package')
Only thing I don't like about vite is that it still doesn't support react context or any other state management ... would be glad to know the solution of this issue
I remember going through code splitting hell on my website. I managed to get the 100 on pagespeeds, but lort was it a pain. I wish Vite was around then. Astro islands are doing it for me right now as I rebuild.
Frameworks like Sveltekit is making it possible to run your most heavy deps on the server (firebase-admin comes here), so authentication and some stuffs can be run on the server and in addition to your techniques,, there's a possibility of small smart client 🤓 🤓
Angular does this ages ago..using lazy loading..I think Angular is far far more advanced than the all other js framework and for some unknown reason it is also most underrated js framework.
Learning curve of Angular is slow compared to other framework, that part I agree. But once you used to the framework, it is hard to love any other framework.
And u have already observables (which u don't need to worry about ssr crap) what is famous for some time now, because of solidjs and telling liberal kids, hey kids, see, solidjs is react, but fixed, oh god
Kind of... if you wrote everything yourself instead of relying on 3rd party libraries, that might be possible, especially avoiding ones that can't be tree-shaken like Moment (as mentioned in the other video about relative dates). But that's obviously more work than most are willing to put in. And if your site is mostly static, then yeah, something like Astro could really help. Also we used to do a lot of things with JavaScript (especially jQuery), that can either be done with native HTML elements and/or CSS. So, I definitely agree with you, but it's not always that simple!
@Iain Simmons Libraries are fine but they should be provided as (public domain) starter templates, not black boxes to pile your own hacks on top of. Layered architectures are insanely overrated. In my personal experience library spam makes it fast to get a project going but dev time exponentially increases over the lifetime of the app. When you control the entire codebase it stays linear.
Wait....what! Isn't firebase used for databases? Why would you use it on the client side? Isn't that a security concern? Accessing the database directly from the client side??
I love Vite too, but agree the docs could be improved, particularly for beginners, and for a wider variety of tech stacks e.g. when you have a Umbraco CMS involved, or e11ty, Publii, Handle bars, different directory structures. Etc.
He made a video explaining the difference in channel goals to keep channels in scope. First channel for basic overviews and news, second channel for a little more about principals and beyond news and brief overviews.
The problem are often third party libraries without tree-shaking possibilities. Sure, you could write anything by yourself, but sometimes you just want to plug in some pre-made alternatives and basically have no other choice then to accept the bundle size.
Yeah it’s not cool but if it’s so bad I don’t want it anymore lol it’s not a big mess anymore it’s just me and I just need to know lol what do it do lol I think I can get a little bit more like that lol lol I don’t know what to say but I’m still trying lol I just need a lot more help with my life lol lol I don’t think
Why do you need so much JavaScript? In a webpage? My suspicion is that instead of writing 20 lines of plain old Java script? you are using hundreds of thousands of lines of libraries and frameworks because it’s cool
Images are literally binary arrays, it's very easy to load them and the browsers do it off-thread in the first place. JS bundles on other hand have to be fetched, parsed, interpreted, then all sync and async side-effects in them ran. And side-effects can load other modules too, which means you can have several scripts going through these stages at once, all on the single thread.
The best thing about it is that these days you can get away with having 10MB js file that's needed for a website to load and it still will work perfectly fine and the users won't notice any difference so pushing to decrease the file sizes is completely pointless. A 1MB decrease for example is nothing.
Not everyone has super fast broadband internet, and if you use your website for your business, your users will notice, will care, and will not stick around.
@@IainSimmons Not really. An incredibly small percentage of users have such a slow internet that cannot handle even 50MB per webpage Edit: and that's still a large size for even an unoptimized website
Some more things to watch out for - Mobile users don't always get smooth connections, so that extra 1mb could break when they go indoors, in elevators, in crowds where networks come under pressure, rural/regional areas that have slower internet, or have lower end devices that may not handle things so well.
@@komakaze1 users that use mobile devices are not "serious", as in - if something breaks for a user that uses a mobile device it'll be "no biggie". If an application is mission critical a user is going to be using it on a PC, or at least a laptop
Or... stop using big unnecessary frameworks and libraries. Web development is really bloated and we need to move it into some kind of diet. Stop using over complicated dependencies just because of their marketing bullshit and do things yourself.
Wow! I never knew about this, now my sites can be visited by people who aren't on localhost!
The classic "wait for them to log in, then hit them with megabytes" strategy. Jokes aside, thank you for this!!!
I cannot emphasize how important & rightly timed this video is for me. I am literally working on a project, and embarrassing it may sound the chunks are oversized. Saw this video and my bundle sizes are literally the smallest in the team.
Your hard work is commendable! Thanks Jeff... Looking forward more to you reading my mind 😄
my new favourite channel, sometimes when im coding i just remember something from a vid 2 weeks ago and it saves me
Im loving vite and the other new js frameworks like astro etc. It’s painful to have to face so many new frameworks in the js ecosystem. But it seems we’re moving in the right direction. Hopefully we’ll be a bit more settled in the future.
Famous last words (as history shows)
If looking at all this framework is the right direction, than that's why web is so doomed. Solving same existing problems for years but in different framework.
I think Astro will succeed in that. you get to write vanilla js or other frameworks. it also use vite
I'm loving both Astro and Vite.
@@MrEnsiferum77 We need frameworks because the native web APIs suck ass. So until they don't we're using frameworks
I'm loving this channel and the humor.
Great videos as always!
Great video my man! Good luck with this new channel and keep up the good work :)
oh hi you lol
@@qexat Lol hi
a monad is a
@@dakata2416 sorm form of monoid :)
@@AByteofCode in the category of no bitches
In next js you can dynamic import as well btw, and automatically imports it when needed
I just subscribed with all notifications, liked, commented, and shared.
I also watched the whole video.
It was enjoyable to consume.
You're videos sometimes has perfect timing
I love 1% code coverage man
I had no idea vite could do this! Very useful
It does it from using esbuild under the hood.
@@thekwoka4707 Rollup is what is used for production.
I just subscribed, liked, commented, and shared. I also watched the whole video.
are you in my house?
I'm literally working in a project with vite using the react template and firebase
And i had the exact same problem 🤯
thank you so much for the amazing content
Jeff must have a place among the programming Deities 🔥🔥
Im so glad I work on the backend
Really want to get started with Vite now
Hi! Like the idea of this channel
every video i learn something new🔥
I'm loving these videos
Never knew this channel existed Jeff :(
I’m the lead at the company I work and that hangover clip had me rofln’
A benefit to browser-side frameworks is that the whole package is very easy to cache. Why load anything at all? Offering Overview is 676 bytes per page load after the first load, and could be slimmed down more by moving the inline JS back to its own file.
Im loving this channell
I used to wonder why people did _"code golf"_ exercises. Now I know why. A little _"code golf"_ is something more people should practice. You'd be surprised how few bytes may actually be necessary to implement your functionality.
As someone who's code golfed a bit, small does not usually mean faster. But I do agree Javascript taking 500k+ is absolute nonsense.
@@4.0.4 For sure smaller is not faster - loop unrolling for example - In theory the fastest program would just be one giant map of inputs to outputs, very large in size, very fast to execute.
Yet smaller programs are typically easier to understand and reason about, and are often more flexible in terms of adding features or reusability. Those qualities lead to faster overall systems in the long run, because if individual code modules aren't flexible and easy to reason about, the entire system will eventually get slow due to compromises in its design...
More people should do code golf so they can get positive experience with that "flavor" of programming.
JS devs : nooooo 500kb is too much !!1!1!1!1!!!!
Balzor devs : wow i managed to shrink it down to 10mb
Is it Balzor or Blaze?
@@Dev-Siri blazor. The c# webassembly spa framework
@@ioneocla6577 oh ok
Just wondering, don't dynamic imports eliminate the bundler's ability to statically analyze what code is used and therefore eliminate tree shaking for that entire import? From my understanding of tree shaking, it only works for es2015 style imports to statically analyze what is used and eliminate dead code from the bundle. If you are only using one functionality from firebase, tree shaking should only include the code for that one functionality, but if you import it dynamically then it has to include the entire package code in your final bundle. Am I missing something here?
I was just wondering the same.
Yeah was thinking the same thing, unless its smart enough to recognise every import statement I think tree shaking wouldn't work with dynamic imports.
the import() function returns a promise containing the entire module, if you only want one part of it you do import('firebase').then(f=>f.onUpdate) for example, but its still requested the entire firebase module, so you may end up shipping more code to the browser. Unless Vite has a smart way of figuring out what you actually use and then removing dead code??
haven't tried it yet but i guess you can static import into a file than dynamic import that file. also for some packages, you can pas specific path into dynamic import like import('package/path/to/function') instead of import('package')
Well clearly firebase wasn't tree-shakeable in the first place so it's a moot point for this particular circumstance.
Only thing I don't like about vite is that it still doesn't support react context or any other state management ... would be glad to know the solution of this issue
the solution is to stop using react
Ofcourse when I'm struggling with huge bundle size, Fireship uploads a video.
Next video on tree shaking!
I remember going through code splitting hell on my website. I managed to get the 100 on pagespeeds, but lort was it a pain. I wish Vite was around then. Astro islands are doing it for me right now as I rebuild.
Frameworks like Sveltekit is making it possible to run your most heavy deps on the server (firebase-admin comes here), so authentication and some stuffs can be run on the server and in addition to your techniques,, there's a possibility of small smart client 🤓 🤓
1:40 thanks I'm only aware of the route level
New Next js logo 🤩😅
Vite is the move
Stock Rollup can do the same. You don't need Vite for this.
omaigod zet iz sou smart
Waiting for the programmer humour channel to be created.
in react u can do it with lazy import whit out vite
Did the video give the impression that only Vite could do dynamic imports? Or am I missing some nuance? I do like Vite, just curious.
If lazy loading is so much better, should you use it everywhere?
thanks helpful vid
Angular does this ages ago..using lazy loading..I think Angular is far far more advanced than the all other js framework and for some unknown reason it is also most underrated js framework.
Because it is by far more complicated, that is the reason
I think Angular is just a bit too complicated when it doesn't need to be.
Learning curve of Angular is slow compared to other framework, that part I agree. But once you used to the framework, it is hard to love any other framework.
Backend bundles? Anyone? I really like microbundle for that purpose but it is slow af. SWC and Rust/Go based tooling is what I hope to use one day
Thanks
Angular has lazy routed modules.
Meanwhile Angular : you can do that for quite a while now :p
And u have already observables (which u don't need to worry about ssr crap) what is famous for some time now, because of solidjs and telling liberal kids, hey kids, see, solidjs is react, but fixed, oh god
The best way to get a smaller bundle is to write less js. Occam's razor 😉
Kind of... if you wrote everything yourself instead of relying on 3rd party libraries, that might be possible, especially avoiding ones that can't be tree-shaken like Moment (as mentioned in the other video about relative dates). But that's obviously more work than most are willing to put in.
And if your site is mostly static, then yeah, something like Astro could really help.
Also we used to do a lot of things with JavaScript (especially jQuery), that can either be done with native HTML elements and/or CSS.
So, I definitely agree with you, but it's not always that simple!
Write less JavaScript and use Blazor. Problem solved lol
@Iain Simmons Libraries are fine but they should be provided as (public domain) starter templates, not black boxes to pile your own hacks on top of. Layered architectures are insanely overrated.
In my personal experience library spam makes it fast to get a project going but dev time exponentially increases over the lifetime of the app. When you control the entire codebase it stays linear.
Yesssss!!!
Webpack also can lazy load)
Can't you load stuff into frontend partially? Half the job board postings want me to use React, and that's a thing it can do.
Maybe review yet another frontend framework , like nextja but uses vite as the build tool
Is there any way to get same result in Angular?
Any fast way to create a React app without the ` create-react-app ` ????
Sure
npm init pett-app
Use Vite
npm init vite app-name
Then a drop-down will appear, choose react
npm create vite@latest my-app -- --template react
@@Dev-Siri thanks 👌
@@Vantivify nice 👌 thanks
Still haven't finished watching the video... Can this be done with angular+firebase?
This is an app that uses vite, I think you can use vite with angular but I'm not sure
Why I have to wait 4s to get data from Firestore in React. It is react problem or Country too far Problem?
Can this be used in existing Nextjs project?
Not using Vite, but you can take a look at NextJS Dynamic Import
Any tips for nuxt 3 #fireshipio
too much work. make it a pwa and force the user to download everything. not my problem. 😎
❤🌟
God = Evan You
Wait....what! Isn't firebase used for databases? Why would you use it on the client side? Isn't that a security concern? Accessing the database directly from the client side??
There is only one God.
Evan You
Absolutely
Everybody loves vite so much, but their docs are so aweful. I must be missing something
I love Vite too, but agree the docs could be improved, particularly for beginners, and for a wider variety of tech stacks e.g. when you have a Umbraco CMS involved, or e11ty, Publii, Handle bars, different directory structures. Etc.
KiB is kibibytes
Make a video on own Virtual DOM.
By now I’m a chunk 😘
wait, what is this channel? If it's still fireship and still short videos, what's the word beyond for?
He made a video explaining the difference in channel goals to keep channels in scope.
First channel for basic overviews and news, second channel for a little more about principals and beyond news and brief overviews.
solution: don't use bloated libraries
Can't for a qwik video
At some point you have to wonder what kind of functionality requires so much Javascript.
The problem are often third party libraries without tree-shaking possibilities. Sure, you could write anything by yourself, but sometimes you just want to plug in some pre-made alternatives and basically have no other choice then to accept the bundle size.
14
Kak e brat
First
(Please Pin)
First
(Don't pin the guy who wants to be pinned, jk)
among the
Yeah it’s not cool but if it’s so bad I don’t want it anymore lol it’s not a big mess anymore it’s just me and I just need to know lol what do it do lol I think I can get a little bit more like that lol lol I don’t know what to say but I’m still trying lol I just need a lot more help with my life lol lol I don’t think
(generated with automatic apple keyboard)
And don’t ask why here. I’m bored
Why do you need so much JavaScript? In a webpage? My suspicion is that instead of writing 20 lines of plain old Java script? you are using hundreds of thousands of lines of libraries and frameworks because it’s cool
please give us your instagram id for further references,doubts and for clarification..
Is this channel just your way to promote Firebase? If really starts seems like that 🤨🤨
Easy. Just don't bundle.
(・o・)
Maybe bundled size is not that matter, Sometime your bundled size for all of your apps smaller than your single image in your site 😂
Images are literally binary arrays, it's very easy to load them and the browsers do it off-thread in the first place. JS bundles on other hand have to be fetched, parsed, interpreted, then all sync and async side-effects in them ran. And side-effects can load other modules too, which means you can have several scripts going through these stages at once, all on the single thread.
The best thing about it is that these days you can get away with having 10MB js file that's needed for a website to load and it still will work perfectly fine and the users won't notice any difference so pushing to decrease the file sizes is completely pointless. A 1MB decrease for example is nothing.
Not everyone has super fast broadband internet, and if you use your website for your business, your users will notice, will care, and will not stick around.
@@IainSimmons Not really. An incredibly small percentage of users have such a slow internet that cannot handle even 50MB per webpage
Edit: and that's still a large size for even an unoptimized website
Some more things to watch out for - Mobile users don't always get smooth connections, so that extra 1mb could break when they go indoors, in elevators, in crowds where networks come under pressure, rural/regional areas that have slower internet, or have lower end devices that may not handle things so well.
@@komakaze1 users that use mobile devices are not "serious", as in - if something breaks for a user that uses a mobile device it'll be "no biggie". If an application is mission critical a user is going to be using it on a PC, or at least a laptop
Or... stop using big unnecessary frameworks and libraries.
Web development is really bloated and we need to move it into some kind of diet. Stop using over complicated dependencies just because of their marketing bullshit and do things yourself.
Complicated
FYI - kib is not kilobytes, it is kibibyte :) en.wikipedia.org/wiki/Kilobyte
Can angular 🫣 do this?