Jakub Andrzejewski is a Senior Developer and dev Advocate at Vue Storefront. They dive into the world of Vue.js and explore the latest developments in its ecosystem. They discuss the use of hooks and composable for code reusability, the challenges faced during the rewrite of the Storefront UI library, and the importance of performance and accessibility in app development. 

Steve (00:01.219)

Hello everybody, welcome back to another thrilling episode of Views on View. I am Steve Edwards, the host with the face for radio and the voice for being a mine, but you're stuck with me as your host. At least one of them. With me, as always these days, I have Mr. Cody Bontekiu. How you doing, Cody?

 

Cody Bontecou (00:19.047)

Hey internet, I'm doing fabulous. It's another sunny blue sky day here in Hawaii, so I can't complain.

 

Steve (00:25.851)

I feel your pain, I feel your pain. And with us today, we have a returning guest coming to us from Poland, Mr. Jacob Andruski. How you doing, Jacob?

 

@jacobandrewsky (00:36.727)

Yeah, quite good. In Poland there is no such good weather as for Gonti... as for Cody in Hawaii, but it's, I would say, quite warm evening, so it's not that bad.

 

Cody Bontecou (00:47.894)

Nice.

 

Steve (00:48.131)

Right on. So for those of you who might be having a little bit of deja vu, we recently had Jacob on with us back in episode 211 about performance and NUXT. So you can look that up. That was from about from March of this year. So if you want to hear about performance and NUXT, go back and listen to that episode. For today, we had a few different topics we want to talk about. So I'm going to hand it off to Cody and go from there.

 

Cody Bontecou (01:17.398)

Yeah, hey, so I've been following you, Jacob, on Twitter for a while now and love all of your content, really. And something that stuck out to me is how you've gotten really involved with the ecosystem, specifically like the Nuxt open source community. And I'm curious what got you involved in Nuxt and open source and kind of like what that looks like, you know? Like what...

 

I've been writing Nuxt for years now and I've never actually written a module or some sort of like open source installable package that works within Nuxt. So I would love if you could kind of teach us the ropes, what goes on.

 

@jacobandrewsky (02:00.463)

So for me it started when I joined the company that I work for until today, which is VStorefront. And back then, it was almost three years ago right now, we were building a storefront, like the storefront template for e-commerce that was purely Vue 2, which was three years ago, it was already old. So we decided to...

 

create a new version of the storefront, and it was based on Nuxt. And I didn't have that much opportunity to work with Nuxt. I used it for small hobby projects. However, I haven't really had a chance to create big enterprise projects with it. So when I joined the company, back then we started building a lot of integrations, there was a lot of community around the product.

 

that was focusing on adding new integrations, new modules. And I joined the company as a person who was working mainly in the UI part, like the front end of the front end, I would call it. So the component library, which is called Storefront UI, which a few months ago also was released as a version two, which supports Vue 3, which supports React as well. So if you want to check it out, I highly recommend.

 

that because we spent a lot of time rewriting it to match the current needs for the community. So I was not particularly involved in the Nux ecosystem. However, I really enjoyed this whole module approach where you have the core ecosystem, the core framework, the core product, and you have those modules that basically allows you to very easily integrate with some.

 

CMS or maybe a search engine or add image optimization stuff like that. So because I was working in a different area and I really enjoyed those like integration part where you could integrate one tool with another I wanted to try it by myself, try if I can make something work and I started building very small and not very I would say

 

@jacobandrewsky (04:26.959)

professional modules, they were basically more or less wrappers around something else. So for example, I created a module that was supposed to compress your assets and it was basically using another package, but in a Nux ecosystem. And then throughout those small packages that were more or less useful for the community, I started building the ones that started to make much more sense.

 

like you mentioned the module that I recently create, maybe not recently, but I'm quite active developing it, which is the security module for Next. And... Mm-hmm.

 

Cody Bontecou (05:07.562)

And before we, sorry, before we get too far, could you just explain what like a basic wrapper would look like on a module? Cause I do see that for example, like the side base is Nuxt auth is just a wrapper around next.js is auth. And is that just like, are you just somehow exposing the APIs or are you directing it to just be like client side versus server side?

 

What does the code look like in a situation like that?

 

@jacobandrewsky (05:41.371)

So it really depends on the implementation. However, the general idea is to broad something that usually requires some work from the developer, so that this developer doesn't have to do that. So for example, as I mentioned, this compression, usually the developer would need to install the plugin itself by himself, and maybe configure some options that can be repetitive stuff.

 

So you can do something like this for the user, for the community member and for the developer. So basically those kinds of wrappers, they take some package or utility that is already available. But for example, to make it work with Nux, it requires maybe some kind of configuration that is repeatable. Like, you know, it doesn't...

 

Cody Bontecou (06:11.362)

Hmm.

 

Cody Bontecou (06:36.234)

Yep. You do it every time.

 

@jacobandrewsky (06:39.743)

Yeah, it doesn't differ from one project to another, it's usually the same. And because of that you can just do it for the user.

 

Cody Bontecou (06:43.999)

And so.

 

Cody Bontecou (06:48.222)

And so that's kind of like a, like a user into if there was in a module, the user would just be, uh, writing their own plugin code and basically hooking that into Nuxt.

 

@jacobandrewsky (06:59.523)

Yeah, something like this, something like this plugin. Maybe as you mentioned, maybe it should work only on the client side or the server side. However, in general, those wrapper kind of components, modules, they are usually like wrapping certain functional. As you mentioned, the side-based module for off, it's not only...

 

Cody Bontecou (07:01.301)

Okay.

 

Cody Bontecou (07:07.627)

Mm-hmm.

 

@jacobandrewsky (07:22.307)

wrapping stuff, it also adds some code as well because it adds some, for example, composables that are Vue and Nuxt specific. So we can have a library that is, let's say, JavaScript or TypeScript only. So you take it into Nuxt with the module and you add some Vue or Nuxt specific stuff, such as composables, such as maybe Vue components for login or stuff like that.

 

Cody Bontecou (07:30.399)

Right.

 

Cody Bontecou (07:43.635)

Okay, yeah that...

 

@jacobandrewsky (07:49.563)

and you can auto import it so that users won't have to import it manually, they can just use it in your project. Which is, by the way, the auto import of Nux is, in my opinion, one of the core fundamentals of developer experience. It should be in any kind of project.

 

Cody Bontecou (08:08.86)

It's funny, it's so simple, but it makes your component files just beautiful.

 

@jacobandrewsky (08:13.355)

Exactly. It's just for those things that are, you know, used across the application, like for example, view imports for ref, for computed, for unmounted, for stuff like that, you probably use it everywhere. So not having to have this specific import everywhere is what I believe it's like pure developer experience. So huge kudos to Anthony for creating such a plugin. Anthony Fu.

 

Cody Bontecou (08:26.798)

Mm-hmm.

 

Steve (08:43.499)

So for, but for something like that, having a global import, obviously you have to weigh it against the performance of having it imported everywhere. Even if places where you might not need it, I'm assuming the pros of the global import far outweigh the performance hit for something like that.

 

Cody Bontecou (08:43.768)

Yeah.

 

@jacobandrewsky (09:01.403)

So, Antoni created it in a very smart way. So it doesn't work like it's a global import. It's more like after you are running your project, it scans all your code and in places where you should be like registering this import, it adds it for you. So basically it's not like global import so that you have it like on the top of the file and it's loaded everywhere. It's more like...

 

when it should be, it is added by the code. So it doesn't affect the performance in general of building and running your application because it's only added when it's needed. So it's not, yeah.

 

Cody Bontecou (09:45.068)

Is it similar to tree shaking? Is that what's occurring under the hood?

 

Steve (09:49.519)

Yeah, it's to me it seems sort of the opposite and correct me if I'm wrong Jacob instead of tree shaking just

 

@jacobandrewsky (09:55.949)

I would say it's a different aspect, but still related to improving performance of packages and utilities that you may use. So tree shake.

 

Steve (10:07.855)

Well tree shaking is like where you have everything and you get rid of what you don't need and it sounds like the way this import works.

 

So you're adding it only where it's needed instead of having a whole bunch and then having to remove what's not needed.

 

@jacobandrewsky (10:23.439)

Yeah, yeah. So it's more like that. So it's really brilliant. So it's not that, as I mentioned, it's global import. So it affects all your files. It's more that it is an intelligent import that it's only added when it's needed. So really smart one.

 

Cody Bontecou (10:26.606)

That's interesting.

 

Cody Bontecou (10:41.014)

And I'm sure it's open sourced somewhere. I'm sure Anthony has the code. Is it just like crazy regex or?

 

@jacobandrewsky (10:45.379)

Yeah, yeah, it's I think view auto, it's out unplugging auto import something like this. If you type view auto import or unplugging auto import, I'm sure you will find it there. And it's used in naxt by default. So you can use it in view. I'm using it in my project as well, which is like view free only. And I'm using it obviously in naxt wherever needed.

 

Cody Bontecou (10:59.766)

Yep, unplug in auto import.

 

Cody Bontecou (11:14.544)

Wow, super cool. Yeah. And the.

 

@jacobandrewsky (11:17.659)

The registration is like easily, very easy. It's one line of code. You just need to add the VIT plugin. And if you want some kind of like more advanced patterns for auto importing, maybe some custom links or custom routes, you can just add it there. Otherwise it just has the like auto imports for Vue, for Vue router, for V-validate, stuff like that. Automatically registered.

 

Cody Bontecou (11:44.334)

Mm.

 

Cody Bontecou (11:47.918)

Cool. And I imagine it plugs into Nuxt as well. And like you were saying, it kind of also auto imports additional modules, or do you as a module author have to configure that?

 

@jacobandrewsky (12:03.291)

I have to configure that, but thanks to how the new NUXT version was designed, it was designed with modules in mind. Because of that, when you are building a module, you have access to basically all the utilities that NUXT uses and you have it available for you as a module author. Thanks to that, the auto import of composables, components...

 

which are coming with the module, it's just one line. You just need to call use auto import, I think it's called auto import, and you just pass it the route where the files that needs to be auto imported are, and that's it. So it doesn't require you to hook somewhere or write some custom logic, you just mention where the files are that should be auto imported, and they are being auto imported.

 

for you. So for example if you could look at the Algolia module, the one that I created for Next, one of the three modules that I'm currently really actively maintaining, it auto imports components such as DocSearch. If you are let's say looking at the Next docs there is usually this Algolia search somewhere where you can just type what you want to learn about. So

 

This is, for example, the component that is coming from my module and it's auto-imported so that you don't need to register it. Same for composables. If you want to search through Algolia or get some product recommendations or stuff like that, they are also auto-imported. So there are less lines of code to achieve the same result. This is what we as developers really enjoy, I would say.

 

Cody Bontecou (13:45.175)

Mm.

 

Cody Bontecou (13:53.334)

Yeah. Nice. Yeah, that's, I know Anthony Fu is kind of a legend. Every, he seems to have his fingers in everything that's, um, changing the world right now, at least in the next world.

 

@jacobandrewsky (14:06.659)

Yeah, there was this great post by Evan Hull, the creator of Vue, when he mentioned that one evening he thought about building a test runner, like unit test runner, based on Vite. And then the next day he noticed that Anthony already created one, which probably some of you are using today, which is called Vitez. And yeah, I'm using it in many of my projects and it's amazing. So.

 

Cody Bontecou (14:12.91)

Mm-hmm.

 

@jacobandrewsky (14:35.575)

Yeah, Anton is true legend in terms of open source and projects and stuff that you are probably using, but you're not aware of.

 

Cody Bontecou (14:44.778)

Yeah, I think V-Test is, has it overtaken Jest in the testing, like downloads per month? I think it's either overtaken it or on track. It's growing rapidly.

 

@jacobandrewsky (14:57.335)

I think it can be really on track, especially that, you know, the speed of running tests. There is a great talk by Markus, Markus Oberlichner. Sorry Markus for probably pronouncing the last name wrong, but you will know who is Markus. So I was there in Vue.jsde in Berlin and Markus was giving a talk where he was comparing how

 

Cody Bontecou (15:02.738)

It's, yeah.

 

Cody Bontecou (15:10.637)

Mm-hmm.

 

@jacobandrewsky (15:27.343)

tests in Vtest and Jest and in Cypress as well how they differ in terms of the time of running them. So he started running tests, I'm not sure if it was Cypress or Jest but one of those two, he started running them at the start of his talk, at the end of his talk so after about 20 minutes the tests were still running. While in the same time, at the same time he started running the tests in Vtest and in like...

 

Cody Bontecou (15:48.458)

Mm-hmm.

 

@jacobandrewsky (15:55.867)

15 seconds they were gone. So you see like the difference between the time that is needed to compile and run the tests. So I am not surprised if VTESP will overrun just.

 

Cody Bontecou (15:58.122)

I'm sorry.

 

Cody Bontecou (16:10.726)

Yeah, it would be silly if it didn't. Like that's, that's like world changing speeds. You know, if you just compile every website that has, that runs tests and how much time is wasted and energy wasted. Um, and then you just plug in V test cause it's pretty much just the copy. You just change the imports, right? From just to V test and it all just works. At least that's been my experience.

 

Steve (16:33.751)

Now we get to talk to Marcus, we get to talk to Marcus coming up here in a few weeks. So that'll be good.

 

Cody Bontecou (16:37.642)

Yep. Yeah, I know he's writing a book on, uh, um, testing view applications. And so he's been writing it, I think over the last year or two. And so it'll be really fun to get deeper into some of those benchmarks.

 

Steve (16:47.939)

could you set?

 

Cody Bontecou (16:57.814)

Um, but anyways, sorry, go ahead.

 

@jacobandrewsky (16:58.203)

So, yeah, one last thing regarding Vtest. So I would say that if more, if there was more work, Vtest to work on the backend of the web development as well, I would say that it could easily like overrun Jest. However, if you take a look at the, for example, nest.js, which is the backend framework based on node.js, which is kind of similar to Spring.

 

Cody Bontecou (17:03.287)

Mm-hmm.

 

@jacobandrewsky (17:28.095)

from Java. So back there, the Jest is like the go-to solution for unit testing. And I don't think it will change because it sticks there very well in terms of the integration stuff like that. So I would say if there was some kind of a port of Vtest for the backend to support maybe end-to-end tests as well there, that would be like

 

Cody Bontecou (17:37.098)

Mm-hmm.

 

@jacobandrewsky (17:57.339)

game changer than I would say like 95% of developers will switch to VTest. However, right now I believe VTest is focusing mainly on the front-end testing and because of that, Jest is maybe still winning because it has this other part of the backend.

 

Cody Bontecou (18:04.576)

Mmm.

 

Cody Bontecou (18:15.722)

Yeah, that makes perfect sense. And I know Jest has been around for years now, so that, yeah, that makes perfect sense. I actually wasn't aware that Vtest is purely a front end testing framework. Do you know why that is? Does it run in the browser? No. What's stopping it from going to the backend?

 

@jacobandrewsky (18:36.451)

I will, I mean, I would say that maybe some dependencies, like I'm using VITES only on the front end, I'm using it in Nux as well, but Nux is more or less like full stack. It's not like backend, it's not like front end, it's more like a full stack. So you can use it there, but for test utilities in Nux, you also use another tool, which is frequently, which is recently quite, was recently quite.

 

Cody Bontecou (18:52.29)

Right.

 

@jacobandrewsky (19:05.935)

popular, which is Playwright, which is also based on VIT. I'm not sure if it's based on VIT test, but on VIT for sure. And it somehow manages to do those tests on the front end and the back end. And I think that right now Playwright is much more popular than VIT test. Let me check. So.

 

Steve (19:08.056)

Yes.

 

Cody Bontecou (19:14.816)

Mm-hmm.

 

Steve (19:25.667)

Yeah, for what it's worth, I had Debbie O'Brien, who is the main public person, I guess you call it, for Microsoft on Playwright on here. And I'll find the episode number, but we talked about it, went over it quite extensively, and it looks really awesome.

 

@jacobandrewsky (19:40.039)

So Vtest has 10k stars, while Playwright has 55k, so much more. Like, 55k, not 55k.

 

Steve (19:49.879)

I was gonna say 55 stars, that's not...

 

Cody Bontecou (19:51.426)

Hehehehe

 

Steve (19:54.475)

Yeah, view 206 is when we talked to Debbie about playwright.

 

Cody Bontecou (20:00.466)

Okay. And sorry, do you know what day that was of the, or what year?

 

Steve (20:05.387)

It was January of this year, January of 2023.

 

Cody Bontecou (20:07.35)

Oh nice, okay, so it's very relevant. It all just moves so fast, you know. But cool, yeah, Jacob, is there anything, what are you most excited about in the NuxtenVue world right now? I'm curious how things are going for you.

 

Steve (20:11.603)

Oh, anything I talk about is relevant, but yes, it's pretty new. Yeah, that's right.

 

@jacobandrewsky (20:33.187)

I would say that for... I'm always really waiting for the conferences.

 

Cody Bontecou (20:41.336)

Hmm.

 

@jacobandrewsky (20:42.723)

both for the ones that I'm speaking at and for those where I'm just an audience looking at the other guys talking. And when these conferences are happening, there is usually some kind of announcement around. So for example, there was Vue 3.3 when Evan was in London for Vue.js London. And for other frameworks, there are also some announcements.

 

So I am quite close with the Next core team. Actually, after today, I will have the meeting with the Aurora team, which is the guys from Chrome, where we will be talking about how we can make Next more performant. So those kinds of stuff, they are really great in terms of what you can do for the user so that the app will...

 

be more performant. So there are a lot of stuff that when you look at them, you just think this is very basic stuff, very easy. However, if you take into consideration that those kind of stuff are being done automatically, this is like a game changer. And what I mean by that is for example, a package from Daniel Rowe, which is called Fontaine.

 

and it's both a Nux module, it is a VIT plugin that you can use and what it does it automatically adjusts your fonts so that this layout shift where you are downloading or fetching the custom fonts so when you are using this fontane it will make the switch or this layout shift smaller so you may think okay this is really basic stuff however

 

if it's done automatically and you don't have to take care of it, it's another level. So those kind of small improvements that if you add all of them on top, your app can be really, really performant and those kind of improvements are... If you look at the code, you will see that there is a lot of like logic inside of it and the result might sound simple.

 

@jacobandrewsky (23:06.767)

as I mentioned, it's like changing the fonts a bit so that the layout shift is smaller. But if you take it into consideration that there are so many of those improvements that are being done in the framework for you by the core team, this is next level, I would say. So I'm looking, yeah.

 

Cody Bontecou (23:25.478)

Yeah, no, I, oh no, sorry, go ahead, go ahead.

 

@jacobandrewsky (23:29.659)

So I'm especially looking for those kinds of improvements. Recently there was one new version of Nuxt released where there was a support for Kapo, Kapo.js, which is a new project created by Rick, Rick Viscomey, the guy from Google. He is really into web performance. He created a book about optimizing performance and also auditing performance with web page test.

 

and he's like out or behind CRUX dashboard, I think it's called like this, so you have access to Chrome user experience results from your website, stuff like that. So he created this Capo.js that what it does is basically reorders your meta script, meta tags in your application. And thanks to that, it makes it...

 

more performant, maybe not as much, but just a tiny bit for you. So those kind of improvements are especially the ones that I'm looking for because they are like code based. I mean that there is a code, there is a logic that it's doing something for you so that you don't have to think about it manually. You just install it and it does it for you with good practices that are based on

 

experience of the guy who created the package.

 

Cody Bontecou (24:59.466)

Yeah, that was something we, Capo.js, that was something Daniel was talking about a lot last time we were on the, when we had him on the show. And yeah, like you were saying, it's just all these little incremental performance gains that are happening behind the scenes. And personally, I rely on that a lot. I love just kind of like, that's why I just go for the frameworks right from the get-go, is because I know they're just optimizing so many things behind the scenes.

 

And it shows in like the lighthouse scores, everything like the sights are snappy and run really well. And you don't really have to worry about it, but it's there if you want to, like it's easily modifiable if you need to get into it, into the guts, but for the most part, you don't even need to know.

 

Cody Bontecou (25:49.466)

This Fontaine thing is new, that's interesting. But I'll have to look a bit further into that. And so, we were talking a little bit earlier prior to the recording, and you were saying you're a dev rel without being a dev rel. And I know you present a lot at conferences and you work for View Storefront. That's mostly open source or entirely open source.

 

And so I'm just curious like how, why are you not an official DevRel? Because it just seems like you are a DevRel. Yes.

 

@jacobandrewsky (26:24.827)

Yeah, so I would say that the thing is that when you start to be a full-time dev rel, you are getting away from coding. Maybe not fully, but some part of it you are getting away from coding because as a dev rel, as your position suggests, you are working to make the developer relations better. And developer relations are...

 

Cody Bontecou (26:34.414)

Mm-hmm.

 

@jacobandrewsky (26:53.695)

developer experience in general, how developers are using your product. It's usually related to other stuff than the code itself. So it is about documentation, it is about video tutorials, it is about conference talks where you get to know the tool, actually from a person you probably have seen already somewhere on the internet and

 

Cody Bontecou (27:12.866)

Mm-hmm.

 

@jacobandrewsky (27:24.055)

doing stuff with the community, maybe some kind of hackathons, maybe some kind of like meetups, stuff like that. So as a full-time dev rel, you are focusing more on those kind of, I would say, soft skills rather than coding itself. So as a developer, I love coding. I really enjoy it. This is what I do every day, the daily basis. And

 

This is what I especially like and I considered it like moving fully into dev rel position. However, I realized that there is still a lot of things that I would like to learn and going fully into dev rel would basically not allow me to do that. I would be focusing more on talking to developers, maybe doing some sales presentations.

 

maybe doing some, as I mentioned, events or stuff like that. And because of that, I will be focusing more on those soft skills, I would say, which are not bad. And I really enjoy this part as well. So I decided to create some kind of a mix between those two. So on the daily basis, I'm a developer, and I'm a full stack developer, which I enjoy even more. And...

 

Cody Bontecou (28:32.386)

Yeah.

 

@jacobandrewsky (28:51.847)

I'm saying full stack and it's like purely full stack because I'm writing like CSS, I'm writing SQL queries, I am writing some Terraform code for connecting to cloud, GCP, stuff like that. So basically whenever there is a need for someone to jump in and solve some kind of an issue, I jump in and do that. So this is what I enjoy the most that I'm not...

 

you know, aligned with one group only, and when there is a problem, I cannot help with it. It's just whenever there is a problem, I could just jump in. However, being only with the code wouldn't be great for me because I enjoy sharing and I was doing it back then before I even started like working as a developer. Because when I started learning about programming, I was part of the...

 

Cody Bontecou (29:43.726)

Mm-hmm.

 

@jacobandrewsky (29:50.427)

like scientific club in my university, because my university wasn't very technical one, it was more about the business. So business economy rather than IT. So we have this kind of a scientific club where majority of people was learning programming and there was few of the guys who already had some programming knowledge and they were sharing it with other students

 

lecturers weren't that experienced, I would say, in modern development especially. Yeah, and because of that I joined this scientific club, this group, and I enjoyed it so much that I stepped from the learner path very fast and started to be a teacher. And I enjoyed this part really much and when I joined my first and the second company

 

Cody Bontecou (30:27.128)

Yeah.

 

@jacobandrewsky (30:50.719)

I was pure engineer, so I was with my laptop, with the code, just there building some enterprise functions or applications which were used by the users but they weren't open. And looking at those open source code that was there, looking at those speakers at the conferences, I always thought it would be nice to be among them somewhere or sometime

 

And so my journey with this, like being a content creator as well started when I joined Vue Storefront, which you also asked if it's like open source, fully open source, maybe some part of it is open source. So the product itself, the first one when the company was started, it was full open source. It was actually an open source. So before there was a company and they had this...

 

ViewStorefront project which was fully open source. It was built by a few guys and then it was like developed over time with the help of the community. So it was very popular and because of that, the founders were able to create small company there and right now it grew to about 100 people, I think right now. So it's quite a big company right now.

 

Cody Bontecou (32:12.77)

Wow.

 

@jacobandrewsky (32:16.599)

So it's not as open source as it was back then, because at certain point you have to focus more on the enterprise because the company is growing, you need more money, you need more developers, you need to basically build an ecosystem around the product so that the customers and users can use it more. So right now, the product, the main product moved more into the enterprise part.

 

So for the customers, however, for the open source, we focused really much on the project that I already mentioned here, which is Storefront UI, which is like the component library for e-commerce. So it supports Vue as well, because for sure because it's like Vue Storefront. However, it also supports React, which might be interesting because the company is called Vue, but still we figure out that we need to create

 

let's say a part of this library that will support React, because there is a lot of React developers out there who want to have those kind of easy to use components performant accessible by default for e-commerce websites.

 

So the company is, I would say 50-50. So there is some things open source, you can use freely and easily. And there are also some enterprise parts where they are aimed for the bigger companies, bigger customers.

 

Cody Bontecou (33:52.455)

I'm curious, were you a part of the view to react kind of like transition or I don't know what the right term would be but rewriting these view components in React?

 

@jacobandrewsky (34:06.451)

no, I wasn't part of it. I was looking at the progress, however, I wasn't the one building it. So I have some like, let's say, understanding how it was done. So basically the core part was to create shared functionality. So things that could be shared easily across those two other packages. So obviously the styles.

 

Cody Bontecou (34:20.92)

Mm-hmm.

 

@jacobandrewsky (34:35.014)

could be shared. There are things that could be shared as well, which are the utilities. So stuff like, for example, handling the outside clicks or handling some kind of interval stuff or mouse related stuff, which is basically like view use. If you ever used view use library, they have those kind of utilities there. So the storefront UI has those kinds of...

 

wrapped in a package, a shared package. And then you have the framework specific components, which are also using the Tailwind styles.

 

Cody Bontecou (35:18.003)

And was that like these like framework specifics? Is that like managing state or using those there like framework specific hooks?

 

@jacobandrewsky (35:32.331)

I would say more hooks. So hooks, so you have hooks in React, you have composables in Vue. You have different syntax obviously for React and Vue. So those kinds of differences. So the stuff that could be shared was added to one package. However, the like pure front-end, I would say code was added to storefront.

 

Cody Bontecou (35:49.494)

Mm-hmm.

 

@jacobandrewsky (36:02.731)

uh, UI slash react and storefront UI slash view. And because of that, it's more also, it was easier to develop because some of the functionalities could be easily reused and there was less code to maintain and it was, it was easier basically. However, you ask about the adding the react version. However, for this particular version of storefront UI, it wasn't

 

let's say adding React to Vue, it was more about rewriting the whole library. Because the problem was that this initial version of Storefront UI was created for, initial version for Vue Storefront, which was Vue 2 based. So this Storefront UI that majority of the users were using, it was...

 

still using Vue 2 in 2021, which is, or 22, which is basically not so long ago. And because of that, it wasn't using Tailwind, it was using SCSS and SAS. It was using CSS variables and other concepts that you don't really use nowadays, I think. So because of that, there was this decision that if we are aiming to

 

make this library better. We need to rewrite it completely, start from the scratch, and think through what this library needs and how it should look like, what the API should be, and basically work on the core concepts of performance, of accessibility, because they were assessed somehow in the first version, but not as much as they are right now.

 

And because of that, it needed like the complete rewrite. Without it, it wouldn't be possible because as I mentioned, Vue 2, SCSS, there was also JavaScript, not TypeScript there. So, you know, this kind of stack is kind of old today I would say, deprecated whenever you started.

 

Cody Bontecou (38:18.923)

That's actually incredible. And this entire rewrite only took a year? Is that what I understood?

 

@jacobandrewsky (38:25.739)

It took a bit more because there was a lot of like, many proof of concepts around it. So for example, at certain point we were investigating into Mythosis. I don't know if you've seen this tool. It's the tool from Builder.io. So Builder have Quake, they have Party Town and they also have Mythosis. So this Mythosis tool, it's...

 

It's another JS framework, interestingly. But the fact is that it is also some sort of a compiler that you write one code, like in a sentence syntax, and it can output the code in Vue, in React, in Angular. So it seems like a perfect solution for us because we wanted to have one code base that could serve more than one framework. So we tried it, but we failed.

 

because this Mythosis tool was great if you are building a button, but if you are building anything more complex, we started to see a lot of issues with the compatibility, with the support for like framework specific stuff. And so the whole rewrite took bit more, more or less two years, I would say, but the version that you can use right now, you can use it in Vue.

 

free you can use it in naxt, you can use it in react next, those kind of frameworks right now and a lot of I would say love was added to this library right now in terms of design patterns, in terms of developer experience, in terms of reusability and stuff like that. So for example

 

developer experience. With the storefront UI 1 you had for example the component which was called product cart which was like let's say a cart which had like a product image product title some kind of maybe description and the button add to cart and if you are building like a very simple demo it could work because you can just drop those components and they will look

 

@jacobandrewsky (40:53.007)

relatively nice and they will be very fast so you can accelerate the development time. However, if you wanted to make it a bit more custom You would realize that you either have to add like a million props and slots to make it more Customizable or you have to build it by your own. So We switch from this solution into

 

showing in the documentation, in the examples, how to build those stuff with the blocks that we have created for you. So you won't have a component for product card, you will have a component for button, for input, for label, so those like generic primitive components. And then for the examples such as product card, search, maybe some kind of address form or checkout.

 

you would have the code samples that are using those like block components. But apart from that, you will get like the full template which is composed by the storefront three components, regular HTML tags and logic as well, which was quite crucial to also deliver the logic. So for example, if you are looking at the search bar, you most probably apart from

 

the view and the functionality to search, you most probably would like to have some guides on how to make this component follow some design patterns. So for example, for search, majority of people usually forget about the bouncing. So for example, if you are typing something in a search and you type a keyword, like you type something.

 

the request for searching it's sent after each key press. So what you usually do is you're adding a debouncer so that after a certain amount of time, after user stops writing, then it will send the request. So this kind of good practices and patterns are added right now to the docs so that when you are building those components, apart from just getting the template,

 

@jacobandrewsky (43:15.587)

you also get those good patterns so that you can look at it and use it and make it accessible, performant and following the patterns themselves. So we went for a long way from this old approach to a new one, but the new one is much, much better and basically you can use it right now almost anywhere. There is also a fork of it right now.

 

that is created by Giorgio, Giorgio Boa, who is quite active contributor of QUIC. And he also created, or I think it's in progress still, but there were already the demos shown by Filip Rakowski of the QUIC version of the storefront UI. So we'll have the QUIC version as well. And I'm not sure if there is one being built by Innsfeld, but maybe in some...

 

weeks or months we will see.

 

Cody Bontecou (44:16.138)

Wow. And are you, so you took this different approach of customization. Are you at feature parity, or is that even like a real question at this point, in terms of like the view to version versus where you're at today? Can you solve all of the same problems and more?

 

@jacobandrewsky (44:40.251)

So I would say that right now it is solving more problems. Maybe it's slower. It's slow. The development is not as fast as when using the first version because with this first version, you were just like plugging components that were more or less five lines of code. Right now, if you are using those like guide docs, I would call them.

 

Cody Bontecou (44:46.124)

Nice.

 

@jacobandrewsky (45:08.095)

you get much more code because it's more like the you are learning with the docs how to build those components by yourself so that they will match your needs so i would say that if the problem you're trying to solve was the development speed like accelerating development the version two might not be as fast as the first one however if you compare

 

the time that you need to build something custom, the second version is much, much better because you will have the full flexibility of how you want to build it. But you get this like template that it's basic and should work with majority of cases, but you can customize it the way you want. So in terms of like the true feature parity, I would say that there are not so many.

 

I would say that the users that were using Storefront UI 1, if they want to use the Storefront UI 2, they should start a new project. Because if you're using Storefront UI 1, you are most probably using, we're using Vue 2 or Nux 2. And Vue 2 is like end of life, I think in December this year. And Nux most probably as well, because it's based on Vue 2.

 

So it will probably be sunset as well. Maybe this year, maybe last year we will see. So if you want to try the Sturf on TI 2 version, I would recommend to go for like view with VIT or next, or react with VIT or maybe next.

 

Cody Bontecou (46:58.93)

Yeah, that makes perfect sense. That's quite the journey, I guess. Is there a storefront UI, kind of like a case study or summary of this entire, I guess, like architecture and how you really built out a UI framework for two frameworks, a UI library, I guess, for two frameworks?

 

@jacobandrewsky (47:23.803)

So I'm not sure if it's like written, but for sure, Filip Rakowski was giving a talk about it during the we are developers talk, which was a month ago. It's not yet out, I think the, there is no recording yet, but it will be published in few weeks probably. Where he was talking about this whole journey, where he was comparing what we had to do to migrate this.

 

library and rewrite it. He was comparing it to Vutify, how Vutify also moved from certain approach to the current one and the headless UI from Tailwind Labs and stuff like that. So I, as I said, I'm not sure if it's out yet, I don't think so, but when the reconduct will be out,

 

the pros and cons and the issues we had while trying to build the new library. So what you need to, basically what you need to do to create such a library. So documentation, playgrounds, architecture, like constant feedback loops with the users, how to, whether this new approach,

 

Cody Bontecou (48:30.977)

Yeah.

 

@jacobandrewsky (48:44.487)

they like it or is it something completely bad and we should go in another direction so there is a lot of work that needs to be done to

 

follow this path, I would say. But it, as I mentioned, it will be like available online soon.

 

Cody Bontecou (48:58.848)

Yeah, definitely.

 

Cody Bontecou (49:03.894)

I'm actually amazed that view storefront has, you said upwards of a hundred employees, did I, did I catch you right there? But yeah, that's.

 

@jacobandrewsky (49:13.135)

Yeah, yeah, I think it's about 100 right now. So when I joined it, it was about 20 people. So you see the difference. So the company was quite different back then. A lot of things were being created like over the weekend, I would say. So there was a need to build something and right now there are a lot of processes which are normal in the...

 

Cody Bontecou (49:21.662)

Mm-hmm. Yeah.

 

@jacobandrewsky (49:42.895)

company of this size that you need to have those processes of creating new features, new projects and stuff like that. And back then it was more like, okay guys, there is a need for this feature. We need to have it for yesterday. So who has free time work on it. So it it's a bit different right now.

 

Cody Bontecou (50:01.516)

Yeah.

 

Cody Bontecou (50:05.534)

Yeah, it's going from the startup environment to a more of an enterprise, proper company environment. Is it mostly technical? I mean, I guess it's 100 people. There's kind of everyone in that amount of people.

 

@jacobandrewsky (50:18.971)

So I would say it's about, I think 70% is like the developers or IT in general. So DevOps, front-end guys, backend guys, maybe some guys from the BI, business analytics, stuff like that.

 

Cody Bontecou (50:26.956)

Mm-hmm.

 

Cody Bontecou (50:39.522)

Oh, yep. Data engineers.

 

@jacobandrewsky (50:41.575)

So majority is technical and it's like the product is for developers. So you need to have the majority of developers on board to create such a product.

 

Cody Bontecou (50:48.032)

Right.

 

Cody Bontecou (50:52.779)

Yeah, I've definitely been seeing Philip talk about View Storefront for basically as long as I've written View. So you guys have been around for a while. So that's really neat. But yeah, I guess, is there anything else you would like to talk about while we got you here?

 

@jacobandrewsky (51:11.963)

So maybe because I started to talk about it sometime ago, but the security module. So I created a module that I was also talking about it in We Are Developers Conference alongside Filip. So we were talking at the very beginning of those like developer experience module stuff. So when I first created

 

Cody Bontecou (51:20.12)

Yeah.

 

@jacobandrewsky (51:41.343)

this module, I thought to myself, okay, maybe it will solve some simple cases for the users and maybe some of them will like it. And I haven't realized how popular this package has become, because basically if you look at other modules, so stuff like maybe CMS integrations or analytics or I don't know, something else.

 

there are many alternatives that you can use. However, in terms of security, my module is probably the only one that could solve those kinds of issues. And because of that, a lot of people started to use it. And right now it has almost like 500 stars, which is, I would say, quite a good number for a module because it's not like JavaScript package, it's like framework specific module that works only for a framework.

 

So other popular modules that have more stars are basically the image module, which is the module created by the next core team, the module for content, which is also created by the core team themselves. So if you compare those modules, which are basically used almost anywhere,

 

Cody Bontecou (53:00.686)

Mm-hmm.

 

@jacobandrewsky (53:07.907)

and the module that I created, which is not as, let's say, as widely used, because if you look at the security, it's not like mandatory for everyone, which I'm a bit sad, but this is the reality. You work for performance, you improve accessibility, but security is okay, we'll handle it later, right? So I'm especially happy that

 

right now with the module that I created more people are using it because this seems to there seems to be a lack of knowledge maybe in this area and this module seems to help people basically do that so

 

Cody Bontecou (53:54.718)

And can you, can you just give a quick explanation of how, what problems is it solving, you know, is it as easy as just NPM install NUC security and you're protected, you're good to go.

 

@jacobandrewsky (54:09.251)

I wouldn't say that you are protected. It's more like in some way, yeah, you are protected, but the thing is that what this module does, in my opinion, great, is that, as you mentioned, you just need to install it and register it. And thanks to that, what you'll get, you will get a lot of recommendations for securing your application.

 

that are added for you automatically, you don't need to register anything. And so you get things like security response headers for the browser. You get security middlewares that for example enable course or enable rate and request size limiting stuff like cross-site scripting validation.

 

what else, basic auth, CSRF, stuff like that. So you get, it's a bunch of middlewares that makes your application more secure by default. And it's based on my experience when developing websites, but more importantly, it is based on Ofasp, which is like well-known document or organization and the document that

 

basically tells you what are the most common security risks and security issues right now in web applications. So if you follow of us, you will see like the issues that I mentioned, so cross-site scripting validation, rate limiting, brute forcing, stuff like that. So this kind of organization and the documents, the document lists all those kinds of issues. And the module I created

 

tries to solve as many of those without a user needing to worry about it. Just install it and it just works for you. And the thing is what I learned through it, a bit in a hard way, I would say, is that whenever you're building such a module, you can't just make it do something by default

 

@jacobandrewsky (56:37.399)

and just be done with it. This is like half of your work because you have to assume that for sure there will be people who would want to customize it so that your approach won't be the best. There will be someone who might need, who will have different requirements or maybe that person will have better idea than you to solve this kind of issue. So what I learned from...

 

throughout building this module, because I have built some of them already for Next, but the security is the one that I learned the most, I would say, is that you have to create something that will solve the issue for the user without configuration, without him worrying about it. However, you also have to provide almost full customizability of...

 

features that you provide. Because as I mentioned there will be people who would like to make it more custom and because of that when I was building the module whenever I was adding new function, new functionality to it, I was always adding like full override function like option so that whenever user will type okay your

 

rate limiting is good, but I want to make it more strict or less strict, or maybe for the headers, I want to give them a different value than you added, because for my case, it won't work. I need to customize it in a way so that my application will work well. And thanks to that, if you start thinking in this way, you have to develop those modules.

 

like the work you need to spend on developing those modules or functionalities is much bigger because you have to think of the cases that the user might have. So maybe they want to disable it completely, maybe they want to make it a different value, maybe they want to run it on a certain route only. This is something that I created at the very beginning of this module so that it was running globally. So there was no way to...

 

@jacobandrewsky (59:02.179)

maybe set it to a different value for a certain root. There was no option to remove it from a certain root. So you had it globally or not. And there were many users who were contacting me and saying, hey, your module is really great, but I would like to run it on a certain root or I would like to disable it on a certain root. What should I do? And I was there and okay. So you have to write it for yourself.

 

and it wasn't a great experience. So I rewritten almost all the module code to support those root rules, which allow you to set specific rules for specific roots. So right now you have support for both, so you can create those global rules and those root rules.

 

So they are not colliding with each other. So you can run certain one globally. And for example, for certain root, you can exclude it or you can make a different value. But it is kind of knowledge you get by building such modules that you are, it's kind of funny, but you're no longer alone, I would say, when developing code. Because if you share it,

 

you create a public repository, you share it on social medias, there will be people coming and trying it out and they will fire at you with some ideas like how to make it better, maybe there is some bug that they could report and maybe fix as well. So at certain point you realize that as I mentioned you are not alone and you start to build a small community.

 

like really, really small, because even if you have one person who contributed to your project in some way, even a typo, you start to build those small communities. And what I learned through, I would like buildings, building the modules is that, and it's also brilliant stuff in, in open source in general, that you might be building something, a package, a library or module.

 

@jacobandrewsky (01:01:25.927)

and you will have your idea on how it should work or what functionalities it should deliver. And then there will be another person on the... Another person...

 

Cody Bontecou (01:03:28.714)

Yeah, I could only imagine that feels so good to have, you know, you get the ball rolling and then you start getting people's interests and then they start just building it for you and for the rest of the world. Yeah, this is a really cool module. I'm looking at it. I'm looking at some of the code and the docs, really well done on the docs, by the way.

 

And I'm just curious, is there a reason why something like this isn't just built into Nuxt? Have you talked to the core developers and had that discussion with them?

 

Cody Bontecou (01:04:08.048)

Sorry, security.

 

Cody Bontecou (01:08:43.25)

Yeah, that makes perfect sense. You want to just start, you know, create your next app and build what you want. You know, it's, it, that's the absolute worst is getting into dependency hell or whatever, and just dealing with configuration rather than building.

 

Steve (01:08:43.544)

Yep.

 

Steve (01:08:59.447)

Yeah, plus it frees you up as a developer, maybe on a different schedule, on a different release schedule than corn NUXT. If you see some, hey, I want to add this, you can add it and say, hey, I got a new release instead of having to wait for the next NUXT release, whatever that might be.

 

Steve (01:09:35.45)

Alright.

 

Cody Bontecou (01:09:39.55)

Oh yeah.

 

Steve (01:09:39.899)

Right, well we're hitting the limits of our time here, so if there's nothing else to talk about, Cody, I think we're gonna move to picks.

 

Cody Bontecou (01:09:50.678)

Um, picks, picks.

 

Steve (01:09:54.371)

Pics are part of the show where we get to talk about other things other than next review. Can be next review or tech or books or movies or dad jokes as the case may be. So since Cody sounds like he came prepared I will start us off here. First of all I did have an article, something I came across on Hacker News today and it's sort of interesting because it's something I've thought about.

 

Cody Bontecou (01:09:59.56)

Yep.

 

Steve (01:10:24.275)

when I take my kids and their friends to the playground. And the question is, how far can you jump from a swing? So, I mean, that's the title of the article written by a guy named Alex Moloss, it looks like. And, you know, if you think about it, I've done this when I was a kid and I refuse to do it now as an adult because I don't want to land on my tail or my wrist or something else. As you know, when you're swinging on a playground swing, you say, hey, let's jump.

 

and I just have visions of me landing and hitting the back of my head. I was actually at the playground with my son and his friends a little while ago and saw a kid break his wrist jumping off a swing. But what's fascinating about the article is that it's if you're into math and physics and everything that goes along in calculating this it's great for you. I'm looking at it and

 

my eyes are crossing just trying to understand everything he's putting in there. I won't spoil it. I will say that it's longer than one meter and less than ten meters. It's somewhere in there, but we'll put the link in the show notes for sure.

 

On to the dad jokes of the week. I am a known connoisseur of dad jokes and I like to share them with everybody So, let's see. Oh, yes My wife recently asked me we had a com we're having a conversation about this, you know Something that happens as you get older about I wanted why I wanted to be cremated when I die You know instead of being buried in the ground and I told her it's my last hope for a smoking hot body

 

Steve (01:12:06.895)

Right? Then another time, this is going to the opposite end of the time spectrum when we had my first child who just turned 24 yesterday. I came home from work and she said, this is before I was working from home. She said, the baby's been crying for hours. Can you take over? And I said, sure. So I started crying for hours.

 

Steve (01:12:35.111)

And then keeping along that theme, when my daughter was first born, we had it scheduled because it was going to be a c-section, but my wife decided to go into labor a little early. So we got into the hospital and the doctor said, okay, it's time to deliver the baby. And I said, actually, we'd like to keep her liver.

 

Steve (01:12:59.019)

You know, D, liver of the baby. Sorry, Cody looked confused there for a second. I had to explain that. Yes. So those are the dad jokes of the week. All right, Cody, what do you got for us for picks?

 

Cody Bontecou (01:13:02.506)

It took me a second, it took me a second, and then... Let's keep delivering.

 

Cody Bontecou (01:13:14.238)

Yeah, okay. So I'm actually going to be going to Spain in September. There's a conference called NS Spain, and it's actually an iOS conference. Obviously, all of my work is in the web, but I like to play around with iOS. Just in my free time.

 

My talk is going to be on-device whisper. So how to get like a open AI's whisper model on your iPhone. And you run like the speech to text transcriptions completely locally and offline. And so that's going to be my talk, but my pick is actually Stanford's CS193P.

 

Cody Bontecou (01:14:01.07)

Stanford has a very good Swift and SwiftUI course on YouTube and they just came out with the 2023 version. And so I'm trying to power through this course because my Swift is actually not great. In fact, it's pretty bad outside of the actual UI component aspect of it. But now that I have this talk to give, I really feel like I have to better my Swift skills. And so I've been

 

that out and highly recommend it. It's an incredibly good course. By the fourth video, by the fourth lecture, it's gone deeper than most other courses that I've ever taken in documentation. So that's my pick for this week.

 

Cody Bontecou (01:14:51.454)

And I guess I'll pass it to you, Jacob. What do you got for us?

 

Steve (01:15:06.511)

Well, that's what we'd call a shameless plug if you had one that you wanted to, one of your own blog posts that you wanted to talk about.

 

Steve (01:17:09.843)

All right, well, we will put links to that information in the show notes. Thank you, Jacob, for coming to us all the way from Poland again. We are truly an international podcast, as I like to say. And with that, we'll wrap it up. Thank you for listening and before I forget, almost forget, almost signed off, if people want to follow you.

 

or give you money or yell at you or what you mentioned your DevTut2 blog. Anywhere else?

 

Steve (01:17:48.143)

Twitter, formerly known as Twitter, right?

 

Steve (01:18:28.719)

Alrighty, well thank you for coming. Thank you for your wisdom and expertise in Storefront and Nuxt. And we will talk to everybody next time on Views On View.