A Vite Demo | Evan You

[Music] after i trans moved it to veets it now takes 1.5 seconds to start it wow so yeah so that's like 20 times faster [Music] hi welcome to javascript jam i am ishan nand the cto at layer zero and i'm mark brocado the vp of engineering at layer zero and today our guest is someone who truly needs no introduction uh it's avenue the creator of the famous view framework uh evan and welcome javascript so you know i actually most people know you as the creator of ujs and we'll talk a little bit about that later but i really want to focus on your new project and that's v so why don't we start there first um and give us a you know explain to folks what vita is and uh would be great to get a demo as well sure um so v is a dell tool right um essentially it's also an attempt to sort of think about think about how we can just make make building web applications with bell tools just a bit easier and faster well that's the that's the main thing right because um you know over time we've gotten used to using bundlers like webpack webpack is probably the biggest one but as we all have experience you know when you have a lot of files when you your project gets more complex uh you have to wait for builds uh sometimes it gets kind of slow also uh webpack isn't the easiest thing to configure it for especially for beginners so we have a lot of these meta frameworks we had to build ucli on top of webpack just to you know hide away all the complexity behind the configurations so but lead is essentially saying okay over time you know a lot of things we just do it the same way across frameworks a lot of the conventions like importing css or uh how we expect certain things to work uh so why don't we just um you know uh reset it and uh start with something simpler leaner faster also there is also this um opportunity where um the browsers today are supporting native es modules uh there are also a lot of tools new tools that's coming up that's targeting javascript but not written in javascript for example uh es build and swbc uh so one is written in go one is written in rust but they both compile javascript but they're like bounds and leaps faster than uh than javascript written tools so um but at the same time you know just directly using them is still kind of challenging to build a real application just because all the things javascript developers are already used to you want plugins you want uh to be able to compile uh have a dev server hot module replacement and all that stuff so vita is essentially you know combining es build with the yes native es module based dev server put these two together uh and then with a lot of uh experience and opinionated configuration that we you know pre-configure it for you so uh you don't need to do too much to get started yeah so i think it would be cool to just uh quickly uh jump into a demo to to show what it is because it's kind of abstract right i always struggle just explaining what it really is but i think a demo will probably be easier so let me share my screen here uh can everyone see it yeah yeah okay so i'm i'm just in a fresh um in a fresh directory uh so i'm going to just quickly so it's empty here okay so i'm just going to say yarn at the viet and as you can see it's fast uh i like i i have a locally cached but like this is a real install over the network and it took like what two seconds i mean i'm on a mr mac but it's uh it's still pretty fast right so um once you have installed uh what you want to do let me give myself a bit more space for the editor so pretty standard stuff so i'm going to just say index.html and uh maybe h1 hello feet uh add some scripts actually this step is sort of optional but you know a lot of people like to so right so um at this step don't think of it as build tool yet just think of it as a simple http server so i'm going to say uh um and the browser is here okay so that's hello viet um maybe let's put it over here so at this point it doesn't do much yet but uh you already get updates just by editing the html it just reloads right this is literally like a static file server so when you say um main js say a low high and i'm going to just main.js right this is literally how you develop and you know uh this is all native javascript like this would working with over any simple file server right now uh the interesting part part happens when you start to do things like rename this file to ts [Music] and you can just do this and it still works right so typescript uh just worked um and then you can also say uh style.css h1 color red i guess so you you can obviously do the do it the uh the old school way use the link so star.css um and becomes red let's get rid of this alert because it's annoying but um no here the cool part is if you say green notice the page actually didn't reload so css is actually hot updated yeah that's awesome and it works over this right so but we can also remove this and instead i'm going to say import style dot css and also just works right again if i update this hot update no reload so um a lot of developers are are used to this right when you have a module system when you have a build tool but we're kind of used to have to build everything have something process it to be able to get this kind of behavior but here everything is just working over uh yes modules um and some custom you know client hot update code handling the styles right so now um so now if you're you were to build a real application i think this is interesting because for say most react developers uh or any anyone who's used um npm we're kind of used to seeing code like import react from react right which obviously wouldn't work i'm gonna say so it's gonna tell you fail to resolve import react does the file even exist uh if you're using a native http file server you're probably gonna see something like react is not a valid import specifier because native esm requires all the paths to be relative so it does not know how to actually handle this this bare import specifier but vt actually knows how to do it so what i'm going to do here is let me open a new tab i'm going to say yarn add react react um um okay so now if i reload the page and we get react right and uh interestingly um interesting because we know rian doesn't actually ship native es modules reacts this files are actually common js but um so theoretically you shouldn't be able to use named imports off of it but uh we can actually do that here because uh vt does have some that interrupt so that a common js module is actually wrapped into native esm so you can use named imports off of it um so this is also something we're kind of used to but it's ahead of you know it's a pain the um it's a it's very painful if you were to handle this yourself to get all the commonjs interrupt working right uh so let's say let's see um so i'm not an actual react developer so i might be you know making some weird mistakes here but if you rename the file to tsx we should be able to say import render from react dom sorry um uh okay bear with me here so i say uh app um return dev hi render app document.gm by the app so this should not work because we don't actually have a div yep here okay so functions are not valid as a react child oh of course uh it should be this all right cool react is not a fine okay uh yeah jsx requires that yeah right okay cool all right so we got a high here so high react right i love that you chose to use demo and reacts it really underscores like this is not a react thing this is about your yeah yeah right um yeah it's not a reacting it's not review thing it's a it's framework agnostic uh tsx just works here because cs build already handles this for us so it kind of comes for free but by default you don't get hot module replacement with this kind of setup right um but but the the purpose of demoing it like this is notice that we didn't actually write a single line of configuration to get all this working it literally works like a simple file server and and you get to actually already get pretty far by um by having css being importable having tsx working out of the box um how deep does that go like if i wanted to start importing svgs as react components does it do like this yeah then you have to configure it yeah you have to use plugins for that because uh different people might have different opinions on how you want to handle svg files yeah right um but there are some other things that uh that's uh that comes for free for example if you have an asset you can uh import url from say test.png right um so this becomes part of the asset graph which will be uh included in the final build static assets and you get this url will be the final resolve url a public path that you can use to embed into a markup this comes for free and then there's um you can say import text from some food.txt like with the curve parameter raw you can just import the import the file as plain text and get it here um so these are all built in um but on top of that you probably want to um you probably want to do something more advanced like um hot module replacement or how do you support view right then you need to write use plugins so um just create a vidconfig.js you can even use ts um so you can say import define config from veet x4 default define config so this gives you full type script based uh auto completion intellisense documentation like resolve git tells you what is in there right inline documentation tell you what you should use here uh full type supported configuration files i can say plugins vjs plugging oh wait i i should install it first so i'm going to do that here so i'm saying yarn id djs plugin view and um plugging view and um voila so this should actually already give you view support i think i need to res oh okay what does it say can i find module oh yeah because if you want to use i didn't install view packages themselves obviously so you are adding view it next sfc so if you use our scaffold like this comes for free right um so if you want to start a fresh one you can use the npm so npm init at vjs app which will give you guided guidance on what you want to scaffold like we have um actually you know like just demo here we have vanilla view react react so once you pick one you can also check if you want to type script or javascript so i'm not going to do that here but you can try this yourself because you already have a project here i want to you know demonstrate how it's actually not that difficult to actually scaffold it from uh from from zero yourself so um so i should have you know i can actually have you and react working in the same project and it's still kind of clean right you don't oh wait there's not a lot of uh there's not a lot of extra stuff here so um let's see if i restarted the thing now where is my wait why do i have my 3001 running oh i think it's because my uh i accidentally started it in my vs code i don't even know how to stop it so uh this is a great what am i doing what am i even doing here this is actually the first time i actually accidentally triggered that behavior in vs code maybe it's something new but you could uh npm global install kill dash port and then just kill port 3000 it's the greatest thing so i'm just going to put this here so i'm in here uh let's see okay so scratch all that um actually let's keep this i'm going to just start a different file which is um which is going to be our view entry so i'm going to say import create app from view create app let's just you make it empty for now because we don't have anything yet and then i'm going to create a view file uh hello view all right and why is this thing here how can i get rid of it it's like a debugging mode yeah i don't how do i exit this um this this no it's so weird anyway uh yeah it might be the button all the way to the right on here that like disconnect button i think it's like connected to a node i believe this should give us something yeah so the view file is working and because it's a view file it comes with hot module replacement out of the box and as you can see the the only thing i had to do is just the the view plugging and use it and you get viewfinder support um so same thing for real hot module replacement a single plugin and you essentially get most of what you need um obviously people want to write their own plugins and the good news is uh these plugin system is actually roll up compatible um so if you want to if you want if you already know how to use write roll up plugins then you already know how to write feed plugins uh they are uh v plugging is a superset it extends rollout plugin interface with a few of these specific things uh like you can transform html the server html you can um do custom hot module replacement handling but you know most users don't really need to deal with that themselves um so uh you got something working with with great development experience right and it's uh it's pretty it's it's very very fast in the sense that um if i restart the server um so i can start it in literally 100 milliseconds i can also um so notice here it actually pre-bundled view uh because so if you look at the network requests it's also it also make things a lot easier to debug because um the files are actually served at uh over the network right so you can actually use the network tab to see the transpiled output it's not a big unreadable bundle yeah yeah right so even like even a view file right viewfile actually goes through some pretty complex compilation but here you can actually see the compound code for each individual one which i think is pretty cool so this one so this is a dependency as you can see this dependency so view internally actually has a bunch of small modules it imports one some dependencies but vit has pre-bundled the whole view dependency tree into a single file so that it's faster to serve over native vs modules because the overhead here is actually the number of requests so we do the pre-bundling here um the pre-bubbling also is extremely fast because it's done with es build so um i don't know i can't think of something to i don't know if i have something i can show here but the the pro the the common experience is for example you are using a a huge library like the react material design or uh especially projects that ships their source code in native vs modules in many small files it will take a very long time for any bundler to to actually bundle all the dependencies so that you can actually serve it in inside here but for v it's uh it's a piece of cake because um because it's bundled using yes build it's pre-bounded using yes build so typically you some numbers here is um i got a project that took 28 seconds to start up um with roland which is already a bit faster than webpack and after i trans moved it to veeds it now takes 1.5 seconds to start it wow so yeah so that's like 20 times faster because most of the work is actually done when you're processing the dependencies so this is a philosophy here because veed in our projects right we have two types of code one part is the source code you can see these are the source code that i am writing so these source code will change very often and i also want to see them updates reflect instantly in the browser without having to reload the page but uh but my dependencies i probably install them once then i forget about them and they don't they don't really change they sometimes you may need to manually edit them but that's like extremely rare right so most of times you install dependency they probably stay the same for a month so in that sense what's the point of you know processing them over and over again so here's the here's what v is doing is uh we are actually just uh pre-processing all your dependencies each dimension gets pre-compounded into one file we have some metadata stored here so the dev server can actually leverage that to serve them as fast as possible and the metadata here has a hash so basically on subsequent server restarts we notice if the your dependency hash based on your log file is the same then we don't have to do anything to the dependency we just use the the already cached ones right so that's there's one level of cache here right so we avoid rebundling them on subsequent startups and then there is another level of uh cache here so if you look at this dependency header as you can see this is actually a very strong cache header here it's using it's basically telling telling the browser to cache it forever uh because it has this fingerprint here yeah um so on page reloads as you can see i disable cache here but if i enable the cache and i reload here you can see this dependency is actually read from this cache so on page reloads you're not paying the network cost again for any dependencies in your project only your source code also your source code actually has as you can see they are actually getting uh so this main ts here the response is actually 304 because the server knows you haven't edited it since the last refresh so what's the point of serving again right so we're actually just use you know this these are just native es modules native requests we're using http headers to make sure your page reload like even on hard reload your page is still you know reloads fast um right so a lot of these little details combined makes the whole development experience you know very very snappy very fast um and uh and this is something you kind of have to experience yourself right um the common thing that we've heard on twitter from a lot of people moving their existing projects over to veed is like oh my god the the deaf server just starts like 10 times faster now uh right and we believe you know when you have something that's so much faster it creates a very fundamental different sort of experience when you work on something because like if i have to wait for 20 seconds for death star to start whenever i work on this thing i'm going to be very reluctant to even think about it right yeah yeah uh but having veeds available is especially like for me right because i have to debug a lot of reproductions people send me like bug repros um with view single file components like previously i like every time i see someone send me a full vcli reproduction i'm like oh no like install install all the node modules wait for the webpack to compile everything it's usually like a minute or two before i can actually see the thing running but with v it's like you know uh it's so it's so fast like i get everything up and running in like a few seconds so it's a it's a very different different thing um when you have that fundamentally faster more snappy experience right it's so fast it changes what would be a difference of degree to a difference of kind it's just so yeah so like it's a subconscious friction that you kind of just learn to live with in development and you you you you don't pause and think oh why is it this way like the analogy i like using for this kind of subconscious friction is actually you know the iphone cable you know you used to have to orient it a certain way to plug it in and then they said you know why do you have to do that like you shouldn't have to think about it you just go in it's like you didn't realize oh all those thousand times i've been plugging that in actually there's friction there i didn't even think about uh you know what's worse is like i find myself interleaving tasks to try to just make the most of my time because like i know i'm waiting for a webpack production build it's like well what can i get done in 30 seconds that's that's not a good way to go about life yeah yeah so that's uh that's kind of the the just about these um we are oh yeah so one more thing you can uh you kind of get for free is um so the development experience starts like just a simple file server but the moment you want to send it to production i'm going just to say uh feed build uh and the builds and then i say v preview so this is what you would see in production this is development um and it's pretty seamless because we we try to be opinionated the reason for us to be opinionated is because we want to make sure like everything you get in development uh it should just work the same way in production you shouldn't have to figure out like they shouldn't be separate processes where like okay i have a nice dev server now i need to figure out how to actually build this thing right we don't want you to have to go through that process uh so if you get something working during dev it will just work in build so you just build it and you deploy it um so that's one of the things like we want to make sure it covers both uh instead of just focusing on the dev server part so that you know that kind of forces us to be quite comfortable to roll up in a sense uh like ideally we want to actually leverage es build for build as well but you know it's it's just that at this very point of time like people have asked me like why why roll up why not just directly use build right uh the the thing is with es build there are still something that's kind of in flux uh road up has been out there for a very long time it basically covers most of the application bundling concerns that you can think of um like asset fingerprinting code splitting and also the ability to actually do some more advanced stuff like one of the things we do in veed is when you have code splitting you may have quite a few different async files that's importing one another and one of the performance killer when you have that is nested imports like a imports b and b import c so essentially you have to have to wait for two round trips two network round trips before you can actually have the whole module graph resolved so you want to eliminate these nested imports and veed does that automatically for you by traversing the chunk graph at build time and make sure these nested imports are actually fetched in parallel we also handle css code splitting out of the box so um when you have css imported from an async chunk that part of css automatically split into its own file and fetched in parallel with the javascript of that chunk so a lot of this stuff you can't really easily do by just throwing a bunch of files into a default default build tool configuration right um so big you know by being more opinionated about the whole thing uh we're able to give you a better more performant default out of the box so these are different kind of trade-offs right um because people um i guess this extends into when we compare this to uh some similar tools like uh snowpack because people often compare v with snowpack yeah right um snowpack uh i think initially snowpack was more like we we want you to actually deploy on bundled uh we don't actually handle the bundling part uh so snowpack build actually transforms every file in isolation and then gives you a bit a bunch of unbundled production files but obviously you know it's very difficult to actually deploy that in a performant fashion so you still have to like today you still have to actually bundle them and when you bundle them you have to use additional optimizers right so one of the upside of going unbundled first is you can use different end bundlers to handle those files but the downside is you you can't afford to be as opinionated in certain areas like vitas right so essentially the trade-off is because we stick with one single bundler we're able to do something that's very very specific but get get you the most performance possible do you have examples of like you mentioned that uh in development time you know you've got a 20x improvement um before after is there examples you can you maybe have off the cuff that of sites that actually improved or projects that improved in their user performance because of the [Music] that is kind of difficult because um this kind of uh optimization you have to have you have to have very specific cases that actually have the the pieces but so right now we don't really have real stories like that because i mean it's early like people don't even actually tell us they're using feet like we have to dig ourselves but uh i think some more contacts will probably be helpful um let me find the part here so this is a common situation where um in a large application you may have your entry then you have two routes right routes are split into async chunks and these two routes actually have a common dependency so this is split into a shared chunk this creates what we call a nested import because by default when you navigate to this route it have to first import this shared chunk yep which results in two network requests so what v does is at build time we convert this dynamic import call to import a and c in parallel and then you know so that um when both are imported then we resolve it chunk a so essentially we're like moving this nested import ahead of time by analyzing this graph at build time do you uh do you have an ability to do that in like the link headers as well so that uh how are you signifying that um so the the here's this thing right in link headers those are what we call preload direct uh preload directives right yeah uh we generate those automatically but if these are actually lazy you know when you cosplay you're you're meant to load them lazily if you load everything up front then you kind of defeat the purpose of it like especially on mobile um you don't if you have like 20 routes you don't want to preload them all at once it's gonna play you know so it's kind of a trade-off like depends on if you only have a few routes you can actually say manually force all of them to be preloaded up front or you can use uh observer intersection observer to load them which is what we do in vpres um but you know like but this is the safest uh default optimization should benefit and benefit you in all cases yeah uh taking a step back uh has uh ees you know module compatibility come up as a issue like just maybe let the audience know i think it's basically everything except yeah right right so yeah so for um for vds in development you need native es modules right so vee is essentially positioned as to be modern first which means um which means we target browsers that support native es modules but as a baseline by default but we do have an official legacy plugin that allows you to actually target down to arbitrary browsers so the thing is yeah so we um input because we bundle for production right so we can actually target inject a uh system.js small system.js loader and then use rollup to targets to output system.js modules instead of native vs modules so which allows us to actually run on legacy browsers as well oh that's correct so it's yeah it's actually possible yeah so you know stepping back um how did you get started like you know on building you know another big you know project outside of view and decided to to start tackling this area was it frustration was it like what's kind of the background here what kind of inspired you uh yeah it's interesting i guess the um it has partly to do with the frustration because i so first of all i have to um i personally do a lot of bug reproductions right i'm gonna start sharing my screen yeah we can that yeah yeah um also let you know whenever i want to start a small site project um vcri has really gotten to the point where it's it's kind of become this mental deterrence like just thinking about installing hundreds of megabytes of node modules just makes me reluctant to start a new project uh and then you know the the overall slowness just kind of chips away at you yeah and uh so i always have this personal itch of wanting to it's also for the view users right because just thinking that oh every view user starting a new vcr project has to actually wait for this to to get started it's not a good feeling so i've always kind of wanted to scratch that itch and find something lighter and faster all right so i've considered just moving to roll up in the past uh but roll up doesn't really have a good damp server story um and hot module replacement is kind of a really important thing if you have something large and you don't want to like reload the page on every update um uh so at one point uh we we do have a feature in ucl i called view um i can't even remember the name but the idea is you start with very minimal setup it's actually a global command where you just say view serve a file and it just start instantly but it's still webpad based so once one time i was thinking so i saw the native es modules becoming available in chrome one day and i was like uh wait a second if i have a dev server that http that's an http request so if that's an http request i can actually so so basically the idea was if that if the browser is sending an http request asking for a view file but i compile it on the server and send javascript back instead wouldn't that actually just like be compiling everything on the fly so we don't even need a bundler anymore um so that was the the initial idea that kind of clicked so i started this really early prototype called um at view dev server it's actually archived now um let's see if we can still find it um yeah it's here so uh oh i'm not sharing the screen but um yeah let's see when was it actually started um so this thing was like more than two years ago so uh the the idea came around in in march 2019 uh i got a very basic proof of concept working and then dropped it because i couldn't figure out how modular replacement back then and also because i felt like you know native vs modules was still early and people would not would kind of be reluctant to rely on on it as as a requirement for development so um you know but a year later it became more widespread and then i somehow had the uh i don't know i just randomly came up with the idea oh maybe we can do hot module replacement this way for native es modules then i pulled an all-nighter got a another proof of concept working and that was the initial uh kind of the prototype for beat um so that was the zero point x per viet so once you have that uh proof of concept going right it's kind of a very you know it's kind of that sort of creativity rush where um i just recently tweeted on twitter saying like you know the first one zero to one percent is always very exciting then the first fifty percent is very fun because you're like oh my god we can get this working too we can get that working too like this is coming together very nicely and then uh you reach a point where you're like all the fun stuff has been done and you you have to start like fixing all the edge cases yep uh so it becomes a grind at the point you know there was a period of time when i when we were in the zero point x every day i'm pretty much just fixing bugs for all these crazy package compatibility issues because uh the ecosystem uh there are so many packages that are that are written assuming it's going to just work with webpack uh and webpack has just so much magic like auto it auto power fills no beltings it you know handles mixed cjs and esm usage a lot of things that you know because the initial assumption is okay v is going to be pure esn no cjs whatsoever and quickly we realized okay that's probably not practical if we actually want to let people use this just because the ecosystem is just you know there is just so much existing packages that people want to use but they somehow have all these assumptions about how what a bundler should be doing um so luckily a lot of the heavy lifting is now handled by es build so uh so we had to do a lot less i mean but over the over the process we kind of learned the lesson and it's really a grind getting the thing to even something that's usable right so um now you can hear stories of people saying okay i just switched my vcr project to veet in a few hours i just switched my create react app app to vt in a few hours that's all possible because we went through this whole process of just like finding out all these edge cases and finding ways to to work around them so that kind of uh that kind of got wear on me for a bit i think um i got it to a stage where i think it's like 1.0 rc then i just put it there because i want to drop it a little bit back switch contests back on work on view view for a bit so i worked on view for a few months uh then i came back and look at uh i took another look at vt i was like you know uh a lot of lessons learned and the initial architecture we saw some shortcomings and we also kind of want to um think about how the build story like a plug-in system that would allow you to i think i guess the biggest drawback of the initial version of zero point x v was that our dev server and the build process is very separated so we're not actually sharing the maximum amount of code possible right because most of the code transform is actually the same and they should be same they should be calling the same code when you're transforming the code say compiling the tsx or that but we're duplicating a lot of that so 2.0 was like a big refactor actually almost a complete rewrite making sure that we can review we can offer a nice plugin system which is uh partly inspired by wmr which is the also a es module-based dev server from the pre-act team they came they first um in fact that like there was even earlier there were projects i think there was a project called nolap that that has this idea of you know so note up was basically trying to run roll up in the browser uh wmr came up with this idea of okay we don't necessarily want to emulate entire rollup but we can use roloff's plug-in interface to allow people to define their own plugins so uh v2 kind of built on that idea a bit further and then we built a superset on top of that we also use rollup as the actual production bundler so um so the end result i think is pretty pretty pleasant um because i like personally i enjoyed when i was writing roller plug-ins i kind of liked how simple the interface is uh it's really simple and straightforward uh whereas compared to my experience writing view loader for webpack it was pretty complicated and it's a lot of the stuff is i mean it's not really well documented you kind of have to either read the source code and just look at other plugins like how are they using it then you kind of trial error until it works but uh in comparison the rolex plugin interface is something you can read in a day and then you figure out how to use it so um so the end result i like it quite a bit i think we've it's something that kind of also is beneficial because a lot of people who've been previously using roll up feels right at home uh when they use v right some of the a lot of the plugins can even just you know roll up plugins can even just work as is directly as a beat plugging so we are essentially uh sort of um leveraging a bit of the existing ecosystem system from roll up and kind of maybe you can also think of veet as a um as a companion to roll up where previously if you use rollup you kind of have to figure out your own dev server solution but now you can just use veed so evan let me ask you i want to ask about meta metaframers because i'm really jealous watching all this like i do most of my work in next js and nuxt and i want this now especially it's very timely because today i was working on our support for spell kit and spell kids based on these like how much how familiar are you with svelte is it a pretty standard use of beat i think it is uh the thing i think spell kids i mean i mean i personally don't i haven't really used it but previously it was zapper i think yeah and uh in a sense it's also sort of next inspired right so it kind of solve it's essentially next for spell so in this sense these server ssr meta framers kind of have similar needs in terms of what they do that is you still need the dev server you still need it's essentially an extension of the pure client-side experience where you but you also want to be able to have server side rendering so i mean i've also i so i essentially designed the initial architecture for how to do view server side rendering when we first introduced the sound rendering view which then evolved into so nux is basically built on top of that initial architecture and that was based on webpack and it involves like bundling your application twice essentially once per client and once for server and then on every file update you're actually rebundling the two bundles which can be kind of slow right um so when we are so when i was working on v2 i always had this hope that you know we can in the future we can have a meta framework that's built on top of leads but in order to do that we need to solve the problem because of how do we run es modules in node.js for server-side rendering because all the source code right the the dev server the reason the dev server is fast because we're actually serving the code as actual es modules but how do you run them in node.js i mean now ojs has actually es module support but um but there are a lot of tricky tricky things you need to handle especially like when you can't assume the user actually always you know if they are using like note 10 which don't actually have native advanced modules how do you get the service rendering working so rich harris who's author of svelte and you know uh he came up with this idea i think they their initial version of file kit was based on snowpack but none of these new dev servers actually handled server-side rendering back then so rich came up with the idea of doing a lightweight transform on the fly for each es module so luckily because es module syntax is so statically analyzable it's very safe to transform so you can actually transform es module syntax into a kind of like creating your own node.js module wrapper then we instantiate them we are essentially constructing all your modules and instantiating them virtually in node.js and which allows us to invalidate them individually just like doing hot module replacement for the browser using similar logic so vit maintains already maintains a module graph for hot module replacement analysis so we basically essentially reduce that for the server side as well so which gives us a pretty efficient server-side runtime for es modules um so the initial idea of of course is uh thanks to rich for coming up with this so they came up with that uh when when they were trying to use snowpack for spell kit and then um and then i implemented that in veed as well and rich saw that because i i essentially like basically i tweeted say okay we got this running thanks to rich's idea and rich saw that i think he probably saw that okay so uh if we can do this and i mean i think the reason they eventually switched to v is because um is a bit more opinionated in the as i mentioned in the in the build part where um we have ssr now we have build we have the dev server story so if you want to build a meta framework there's really no reason not much reason for you to reinvent the wheel for in these areas uh if that already fits your bill so i think that's why for spellkid they're essentially saying okay like we we will have to figure out the build story but veed already does it so we can just leverage instead of inventing our own wheels um i guess i think that's one of the reasons why they you know essentially um essentially it's kind of like where the with the scope of the the thing is feat does is not uh in itself a meta framework but it does quite a bit which makes it easier for you to build a meta framework on top of it yeah yeah yeah so so smell gets you know still under development so it has like no baggage but you know more established frameworks like next and knocks like how hard is it going to be to switch those over to a modern tool chain or hopefully to feeds yeah it depends on how coupled your the core the framework core is coupled to the bundler they're using uh i don't know about next but i it seems they are also working on some like they've experienced performance improvements so i don't know the details but they just hired tobias so i think they're gonna come up with something um in terms of next so the cool thing is when they work when they started working on next three i think they started with the assumption that it's probably have to be a builder agnostic to some extent because they don't i think the initial design premise was that don't be too coupled to webpack so most of the core of nux is designed to be bundler agnostic um which is why they were uh it's it's crazy because um after i release v2 um next team actually got a demo running next three on vt like very short like in a few days uh because the architecture um they're coming i think not three next three has a has a lot of interesting stuff coming like um i personally like don't even have a full comprehension of like all the stuff they're doing but they have some cool packages that like you know uh just being able to nicely extract the score and then just like swap they have a version that can run on webpack they have a version that can run on vt um so i'm i'm also kind of uh pretty pretty uh looking forward to see like you know how it turns out to be but i know there are people who have currently running next projects being able to use the nux meet module and actually get it running so like i'm not 100 clear on the technical details either but like the bottom line is i know like nux can already run on beat maybe not in the 100 efficient you know uh way um it leverages v to some extent it's probably not using the server side rendering runtime but you know just for serving client-side modules it's probably uh i think it already works yeah so it really depends on the design like how how you want the meta framework to be how coupled you want the meta framework to be coupled to a certain tool like i think spell kit is pretty deeply coupled with beat but next is obviously trying to be a bit more built to agnostic yeah we had um the the nux cto actually on a previous episode and they definitely it sounds like wanna to while trying to be less builder-centered still keep up with what's happening there um but i'd encourage folks to listen to that episode we had a a whole list of view questions we want to get to but we're already uh at time so we i think we'll have to do a part two i would love so many things i want to ask you about and talk about on the view side uh just the efficient rendering and react server components and thoughts there but we're going to save that for i think a part two um just to close us out you know as it relates to v what should folks look forward to in the future um for veeds so things probably going to slow down a bit we want to stabilize it we are getting a lot of new users a lot of issues so uh there's a lot of just daily maintenance going on so we want to probably slow down a little bit i'm actually diverting a bit of my most of my attention back to vue because we have a lot of work here as well so um in the short term it's probably mostly just stabilization want to make sure we currently you know fix the edge cases we're still discovering a lot of because it's still really young right i think stabilization is going to be a major theme for the next few months uh and then on top of that we have some ideas on uh you know taking the performance even further and once es builds application bundling fully stabilizes we hope we can you know uh have a mode where you can actually build your application with es build directly so that would make the build also 10 times 20 times faster so hopefully that can happen but for now it's mostly making sure everything there there will be a because our long-term eventual goal is like especially for new view projects we want users to start with beat because it's just uh a much lighter and faster experience we don't want to intimidate users especially beginners like oh like you know people make enough jokes about modern front end development being so heavy you know we want to just dial it down a little bit so so and view three is starting is is starting with v out of the box is that correct or not so we want to uh we are probably going to update our like documentation and everything later this year so the initial introductory workflow especially if people want to start with the tooling route is just you know install beats and you can get a project running in no time okay um and then what's the best way for people to keep up with vt and to follow you online um so my twitter handle is uh yoyushi we can probably edit this in y-o-u-i-u-x-i uh and then if you want to follow wheat the twitter account is at feet underscore.js unfortunately both veed and vtjs are already occupied so we have to go with underscore before we close out how did you pick the name v actually uh vit is the french word for fast yeah ah okay just like view is the french vu is the french word for view so uh okay uh that makes a ton of sense thank you well uh you know thank you again for for joining uh javascript jam and we look forward to having you in a part two and we'll we'll talk about vue yeah sure awesome thanks a lot

Channel: JavaScript Jam

Views: 6,870

Keywords: evan you, vite, vue, vue.js, vuejs, webpack, demo, hmr api, web developer, webdev, esbuild, jsx, hot module reloading, dx, developer experience, javascript, javascript jam, hot module replacement

Id: Pgsges6rw0o

Length: 58min 21sec (3501 seconds)

Published: Fri May 14 2021