Wrapping Up

Steve Kinney

Steve Kinney


Check out a free preview of the full Vite course

The "Wrapping Up" Lesson is part of the full, Vite course featured in this preview video. Here's what you'd learn in this lesson:

Steve wraps up the course by explaining the concept of returning null in JavaScript, discussing the maintainability of writing your own plugins, differentiating between micro front ends and module federation, and highlighting the benefits of using Vite as a build tool. They also share their thoughts on investing in learning the lower-level functionality of Rollup and provide closing remarks.


Transcript from the "Wrapping Up" Lesson

>> Cool, questions, comments, concerns, cries of outrage, someone wanna yell at me about my opinions on microphones. So I won't hear it. [LAUGH]
>> Could you explain the return null?
>> It basically saying at any given point, if you wanna kinda opt out or not, directly returning undefined will do the same thing.

It's basically like I don't, what is this one now? I was just typing or atleast yelling about something else. It's basically a way to go, you can return undefined from this one. It's a way to say I actually don't wanna continue, right? The resolve ideas I believe, if I'm not mistaken, in case you have like, yeah, with the SSR flag or something along those lines.

It's basically it's like I don't wish to continue down this path with this plugin at this point, with this file through this plugin.
>> Is writing your own plugin better in terms of maintainability? I saw some plugins with no action in over two years.
>> I mean, you maintaining it versus nobody maintaining it.

Yes, right, now the big, the big question you have to ask yourself if nobody is maintaining it, yes. However, are you going to be the next person who is nobody maintaining it? You know what I mean? Yeah, especially if there's something that doesn't work, there's nothing stopping you from forking it either, right?

But think for the common ones, again, anything that is either nothing that exists that is maintained, yeah, write your own. Should you write your own? There are more than one markdown plugins out there, right? There's more than one YAML plugin. Do we need another one? Unless there's something specific that you need, maybe it's like, yoh, we use this YAML library that formats the stuff in this way.

Yeah, you can totally wrap it in a plugin super easily, but if it isn't actually maintained one, use that, but if it's not maintained, yeah, absolutely, that's kind of the point. It not existing and one that doesn't work at as a longer maintained are basically the same thing.

>> Is microfrontends and Module Federation the same thing?
>> No, right? I mean, what is a microphone and we can cut all this. [LAUGH] For me, l sharing an app bar across multiple repos, which have always been separate that I don't own the docs repo. I don't own the, but to navbar and think totally cuz they are separate?

They both they predate any of us, right? It's not necessarily an architecture that point they're totally separate properties. Using it for that make sense? Some no, you can use it for other things. It is most commonly used in microphone and architectures. Hopefully, right, in this kinda whirlwind tour from the very simplest you need almost nothing to get started all the way through to you can customize literally anything.

You can reformat images on the fly. You can host pieces of code that can be remotely fetched. You can create libraries, right? Vite and we did all that in a day, right? A few hours, really, all total. And both the flexibility and the simplicity and the speed because Vite is able to leverage a lot of modern web technologies to not do a lot of stuff.

Let the browser use its native bundlings, particularly when we're in development because we know we're using a modern browser. I don't know if any of y'all choose to use IE6 while developing. I use Safari because I don't trust that anyone else on my team is checking stuff on Safari and I'm the manager.

So, but generally speaking, and Safari supports these modules, you have all this stuff in place so it becomes wildly fast. And, I think we don't spend enough time thinking about the faster something is in development, the quicker you can make decisions. If something takes ten seconds to load, right, versus one second, especially if on a second monitor, you change code, you see it instantly, as you're changing something trying to get.

Or your tests are running or something along those lines, that feedback loop, if you cut that down by 50%, 75%, the number of decisions you can make in a day go up. Because unless you write perfect code the first time every time, which at least I've demonstrated I can't do.

All right, unless you're better than me, which you might be. Right, it's usually about do something, get feedback, and see bunch of red, right, realize you've made booboo, right? Look at booboo, fix it the quicker, you can get that feedback loop, I think we underestimate the power of sometimes being a faster developer is not thinking faster.

It's just finding out that you made a bad thought faster, right, and recovering from it. And the more you cut that down, the more powerful it is, and the less time you spend fighting with your build system, right? Even as we're doing every wild thing that we could think of in our time together is still relatively with a lot of things straightforward, right, especially as I'm talking and typing at the same time, right?

And those times that gets you back to the important part of the application cuz I've lost weeks of my life fighting with certain build tools that I won't name. Multiple of them, honestly, a decade's worth of them. I could name them all, and it'll just make me sad.

A lot of them start with the letter G, multiple of them, some I'm not doing this right now. [LAUGH] But the idea that we have a place where we're using modern web platform features. We've got super fast tools built and going rust. We've got the idea that there's ergonomics around how simple can this be and out of the box it works.

And then you can extend it as much as you want, I think is a wildly powerful pattern. It's the first time I don't hate a build tool after using it for two years.
>> Does it make sense to invest in learning the lower-level rollup functionality as well por does Vite provide enough transparency via rollup options?

>> Yeah, effectively, if you're writing a Vite plugin, you're writing a rollup plugin, right? Vite adds two or three extra things what your Vite configuration is cuz rollup doesn't have the idea of a server, right? It's just a build tool. So Vite adds a few things. You're effectively writing a rollup plug-in for really reals, right?

There's a few, I think it's true to say all rollup plug-ins are Vite plug-ins but not all Vite plug-ins are rollup plug-ins cuz they have a few extra hooks in them. And for the little options, external and stuff along those lines, but generally speaking, in my experience. And again, the experience of using it for two years but in my own use cases, right, is that if you are looking up how to do something in Vite and it involves a roll-up option.

You'll find it looking for how to do it in Vite. You don't I mean? I would say in the plugins, if you go to the plugin docs for Vite, they're like go read the roll-up plug-in docs first, right? So yes, in that case, but I think the general day-to-day usage, I mean, there's a whole bunch.

I've read every single Vite option that there is. How many of them did you see me use today? Not that many, right? Cuz I think a lot of the power is that in how I write my JavaScript code by kind of using modern conventions, I get so much for free.

If there's a problem you need to solve, you go into the Vite's docs, but yeah, do you wanna use lightning CSS instead of post-CSS? Cool, there's an option for that. There's all sorts of little things like that. Most of those I don't tend to tweak. I spoke it.

I could pull up the Vite config, there's the pattern is the app makes sense, and leaning into stuff like the glob imports and stuff along those lines make sense. But in terms of getting all the way to the bottom, I would say if that's the intellectual exercise you wanna do go for it.

I don't think that you need to per se. I think we covered the greatest hits of everything you need to know today. But yeah, you might have a very esoteric use case or something off the beaten path, I do, right? Those are not the things I chose to include because if it's something that only really applies to the unique nature of the business I'm working on, it's felt like the not the best use of your time.

Did I have a section on writing your own JSX parser? Yes. Did I even choose to include it? No. Right, because how many of y'all are gonna do that tomorrow at work? Nobody, right? Could you write your own hot module replacement logic? Yes. Should you? Probably not. Right, so there are, I think, if you're gonna build your own library, your own framework, yes.

Right, in terms of the building apps, I think some of the patterns and some of the features that make your life easier, the ability to change images. Then figure out the post-CSS plugins you might need, like, you wanna do stuff with fonts that makes it a little bit easier.

All that stuff is I think powerful, but getting all the way to the bottom. Unless you're building a live, a lot of this stuff is in there for library and framework authors. They are being used, just not by you. Thank you so much, and I hope you get to use this in the applications you're building and I hope it speeds up your development workflow.


Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now