Steve talks with Milad Dehghan, a Vue developer for Trengo in The Netherlands, to talk about his blog post on creating a VueJS component library. They start with the basic definitions of component libraries (aka design systems) and atomic design principles and then dive into the specifics of how he does it in VueJS

They also get into short discussion on Astro, and Steve makes Milad laugh hysterically with his amazing dad jokes.

Hello everybody and welcome to yet another exciting episode of Views on View. I am Steve Edwards, the host with the face for radio and the voice for being a mine, but I'm still your host. Today with me, we have a special guest and I'm going to say his name without butchering it, Milad Dechan, coming to us live from the Netherlands. How you doing, Milad?

 

I'm doing good. Thank you for doing it perfect actually. So much better than Dash people. So, duppon.

 

So, Milad is Iranian, actually living in the Netherlands. We are quite the multinational podcast, as I like to say. And also, before I forget, I would like to say welcome to our studio audience. Thank you. Thank you. Thank you. It's always good to have a studio audience. They add so much to the podcast. So today we are here to talk about creating a view component library without losing your mind, which is something I often have a problem with losing my mind that is not creating a library. But before we get started, let's Milad, can you introduce yourself and just tell us who you are, your development history, why you're famous, etc.

 

Okay, I'm Milad. I did some rock music. No, I'm Milad and I'm a front-end developer and I've been front-end developer actually my whole career kind of. And I was working in Iran and I started working in the Netherlands for the past year and I'm currently working in Trenco, which is a customer support software. It's not like the thing that people use, but I think the businesses know it a lot, even in the US and the whole Europe. So yeah.

 

So,

 

That's

 

Trenco,

 

basically it.

 

how do you... We'll put the link in the show notes, but yeah, I haven't heard of that before, so, interesting.

 

Yeah, I sent the link to you, but

 

Okay,

 

yeah.

 

t-r-e-n-g-o dot com, awesome. Yeah, we'll put that link in the show notes. So, okay, great. So how long have you been working with Vue?

 

Actually, my relationship with Vue came back to version 1.

 

Wow.

 

I was working in a company that was using Vue.js version 1. They were on the migrating to Vue.js 2. And Vue.js 1 and 2 were completely different. For example, now Vue.js 2 and 3 are kind of backward compatible. But Vue.js 1 and 2 were not backward compatible. It was a different breed. So we tried to migrate it to Vue 2, we did it, but it was a hassle. And then it was I think 2017 or 2016 which I started using Vue. And yeah, I'm using it till now. Actually, I don't know why, but any company that gives me like offers and stuff is using Vue. So that's the thing.

 

Awesome, so View 1, you are the first person I have ever talked to, whether here on the podcast or just in my own contacts that actually worked with View 1. Most people have come in with View 2. In terms of being

 

Yeah.

 

very different, some people would say that's true for View 2 to View 3, although View 3 does handle backward compatibility a little better in that you can use View 2 syntax, although it's not recommended,

 

Yeah.

 

at least by having you. So great, so our purpose here today or our topic today, like I said, is creating a view component library without losing your mind. So I guess first of all, Milad, let's talk about what a component library is and then how to create one.

 

A component library or a design system. For example, you're in a company or you have an application. So your application has some design language. So you need some models, you need some inputs, some buttons, a lot of components that is basically all are designed by your designers. So you cannot use, for example... Bootstrap or anything like that because you have a different design you have a different functionality different animations different everything so in that case you decide to have a component library so then then the thing is start how you can do it because for example you have You need 100 components how you can manage it, how you can make it reusable through all of the application, through all of the use cases, through all of the developers you have in the company, or even if you want to publish it open source or anything like that. So that's when the struggle starts, because making a reusable component, which you can use in a lot of situations, it's not an easy task. I don't know if you had experience with that, for example, even if you were making a simple button. And it seems really simple, but when you make it, you think, oh my God, I need a smaller one here, I need a bigger one there, I need a full width button, I need a button that is like a little different here. or these kind of things. So that's when the struggle starts and people will have really bad components and they will start losing their minds, kinda.

 

Yeah, that's the rub with anything that you're using that's off the shelf. There's your classic bootstrap, I think it's probably the more better ones. There's Bulma and any number of component libraries. And it's safe to say that their usability is going to be better when it's more flexible, when you can pass in different options and things like that. In my day to day we use Bootstrap View. which I'm sure many people will pan. It is a decision that was made long ago. The nice thing about a lot of those things is they do have a decent amount of flexibility in terms of props that you can pass in. But as with any off-the-shelf system, like you said, at some point your needs may be much greater than the flexibility that those provide. So you basically end up creating your own design system. I know one of the ways we've handled that is we're working on some, on GovTribe we're working on some UI redesign to make things look like a designer actually did it and not code people that try to do design. And we've sort of created our own design systems by enhancing sort of wrapping around some of the built-in bootstrap components, right? So here's this and then we'll create our components that have some more. some company specific designs already implemented and then props and so on. So anyway, that was my rant. So that's what a design system is, right? So you want to talk about doing one in view. So I guess, was that your reason for doing it, creating your own new one is just that there was nothing off the shelf that really design did what you needed for your particular application. And so you figured you'd create your own.

 

The thing is when you have an application that has a design language and everything is designed by your designers, you can use off-the-shelf component libraries. You can wrap them up, but the problem is you should fight with their styles. You should fight with their

 

Yes. Mm-hmm.

 

style they already have. to make it look like the thing you have. And also, you have the problem of the versioning. If they update, you should update too. And if they are deprecated, you should always be careful. If you want to migrate to Vue 3 and they don't have a Vue 3 option, then you have problems with it. So in that case, if you're a big company or if you have the people to make the components for you, I will hugely recommend the... making your new component library. Because it's better not to be dependable on the other people's code, if you have your own design. So it doesn't make that much sense to, for example, the model that Bootstrap or Vutify have, it's so hard to make it like the model that we had, for example, in the triangle. So... We had a different kind of footer, we had different kind of scrolling, we had different kind of header and stuff like that. So we could use those models, but it wouldn't be even more work to make it look like the thing that we wanted.

 

Yeah, it's funny you mentioned that about being tied to the underlying libraries versioning. We use Bootstrap Vue and we're still in Vue 2, which there's many view sites out there in Vue 2. But part of the reason we have been tied or restricted from going to Vue 3 is that Bootstrap Vue does not have a Vue 3 version yet. Same with Vue2Fi. I know they're working on that too. problem in that the developer is in Ukraine and he sort of had some other issues maybe going on there that would keep him from being able to do what he needs to do. But just that illustrates perfectly your point about being tied to somebody else's versioning and losing that flexibility when you need to upgrade.

 

Yeah, exactly. And the thing is, your developers need to learn two APIs, your own wrapped API, and also the API of the Bootstrap view or Beautify or anything like that. So if there is a problem, they should go and read all of the documentations of the Beautify. But the problem may be in the wrapper. So first, they should... debug the wrapper and then if the problem is not there they should go and debug the beautify thing like if you have a Design and you have people enough people to do it. I highly recommend Making it from scratch. It's so much easier

 

Sure, yeah, you know, obviously it's going to depend on your available resources. If you're a one or

 

Yeah.

 

two man person shop, probably not going to happen. But if you

 

Yeah.

 

have somebody that is able to just focus on the design system itself, then sure, it's a great amount of flexibility for sure.

 

Yeah, that's the thing.

 

So, alright, so now that we know what and the why, let's talk about the how.

 

Oh,

 

So,

 

okay.

 

right, so we want to build, as you say, an extensive, reusable, and cohesive component library. So, you're going to follow the atomic design principles. So, I want you to talk about those and how those work and then how those play into creating your view component library.

 

Okay, there are different kind of structuring component libraries, or UI in general. Actually, atomic design principle is not for component library. It's like in the making UI in general. It's not even connected to frontend, I think. It's like in general kind of structuring your application UI. So, the thing is... I found it really useful because then you can really differentiate the responsibility of the components. For example, if you have an input and then you have an input with an icon, you don't need to make two separate components with really duplicated code and stuff like that. You can make an atomic component and make an atomic icon, and then make a molecule out of those two, which is like a... input, for example, with some other features, icons or like other features too. So in that case, atomic design principle, I found it really, really, really good for component libraries, especially if you want to follow principles of the solid, not full solid, even just like a single responsibility and open clause principle. So in that case, it will help you. differentiate responsibilities. It's so easier to do that with atomic design principle. There are other parts, other kinds of structuring too. For example, people do it for like, for example, these are forms, form components, these are like, I don't know, these are components based on their, what they do and stuff like that. But I found it really hard to do it like that. Like these are form component, these are like an design component, these are like typography or this kind of thing, but Yeah, I found that really not good

 

So you find it difficult. So in other words, it's better to group it by functionality, I guess, by here, this is something that I can drop in that has everything I need, right?

 

Yeah, exactly. Especially when you want to start, you can just have three folders, like atoms, molecules and organism. And then you're set. You just can put your component inside them and use it as you want. The molecules will contain atoms and the organism will contain molecules. And just that.

 

So yeah, okay, so for the non-scientific among us, who maybe haven't studied molecules and atoms and design, it's a size hierarchy, right? So your atoms are your smallest,

 

Yeah.

 

right?

 

Yeah,

 

It's

 

yeah.

 

the very tiniest thing, the things that in science we can't see, right? And then use atoms to make up molecules, molecules contain multiple atoms, and then you can use organisms to say, okay, here's my multiple molecules. And so the atoms within them, Organism are pretty transparent because all the organism cares about is the molecules, right? In terms of that

 

Yeah,

 

hierarchy

 

yeah, yeah, exactly. For example, Brad Frost, which is like the creator of the Atomic Dism Principle, which has a book too, I think, about that. It shows, there's a picture that he shows what they mean exactly with the Instagram example.

 

Right.

 

If you've seen it, that's quite really... If you see that picture, you will already know what this is about in UI design.

 

Right, yeah, the book's Atomic Design by Brad Frost.

 

Yeah. Actually, I didn't read the book, to be honest, but

 

Uh-huh.

 

I use atomic design principle a lot in my books because I researched it online, but I didn't read the book fully, to be honest. Yeah.

 

He's got some quite detailed things about how atoms and molecules fit together from a scientific perspective. He's even got the periodic table of the elements in there

 

Yeah.

 

and how it all fits into design systems and templates and pages and stuff. Cool.

 

So

 

Okay,

 

yeah, that's it.

 

so you've got that methodology, right? Molecules, organisms. Okay, so let's, okay, so your post is basically just talking about high level stuff, right, with some examples. So can you give us some real life examples of how you've used this in Trengo or where else you've used the custom library?

 

Oh yeah, for example, the problem we had in Trenco was like, we had components that were doing multiple stuff. So we had the input components, for example, that was doing like everything. Input with icon, input with like, and the component got huge. You may imagine, for example, an input component in Vue.js, it's just, yeah, it's just input with maybe some props and that's it. But after a while, for example, you need a new feature, which the input has, for example, a label, or it has an icon, or it has something. Every one of these kind of things, every kind will add to that component. And after a year or two, you will have a huge component that nobody wanna look at it. Nobody can edit, nobody can do anything with it.

 

It just scares you looking at it because of the amount of code that's in there, right?

 

Exactly, exactly. So I was looking for a solution. I was looking for how we can make it not look like that. How we can do a component library that we can add anything we want in the meantime that will not clutter our code. So a nice example will be in Vue.js, we have props. And When we have a component and we need a new feature in that component, we will just add props. But I don't think that's a nice idea. I don't think that's a good idea. The better idea is having maybe another component that wraps that component, or maybe another atom. Make another atom and combine it in a molecule with the thing that you already have. And that is open-close principle. And it has... The things should be... You should not always edit the things. The things should be open to be edited from parents. They should have all the features from the start up. But they should be close to getting edited by time. In the

 

Thanks

 

simpler

 

for watching!

 

words... You should not have to edit a component every day. That's the

 

Right.

 

thing.

 

So the idea is that when I'm going to implement a particular input, let's say, you know, to use that example, I don't want to, if I have, I just want to use that top level organism, right, and be able to configure everything from there. I shouldn't need to go down and add the molecule or the atom, right? at least in theory, everything you're going to need. Now you might want to add something later, like add a different color option. Say you've changed your design and you need to add more color. Then yeah, you can do that, but that should be rare and

 

Yeah,

 

not very often, right?

 

exactly. That should be rare. And if you made your component small enough, it will be more rare and rare. But mostly you will edit the bigger options. You will mostly edit molecules or organism and not atoms. So that's the thing. And if you're changing atoms, that's the thing that you should talk with your team, like the design team changing something, the inputs and stuff. So

 

Mm-hmm.

 

that's the thing.

 

Okay, so let's play devil's advocate for a minute. One of the things you're going to run into, I would anticipate running into, especially as a site scales up, is complexity and trying to track things down. You know, I've run into this before where you're implementing something in PHP for instance, using OOP principles where you try to extract everything and pretty soon you've got something that's down. you know, five or six layers of classes and inheritors and stuff. And it sounds like you could run into something similar to where you've got things so broken out and so isolated that you run into a bug or something that's not working right. And so pretty soon you've got 20 files open in here, your editor because you're trying to figure out where the problem is, right? So

 

Yeah, exactly.

 

is there, is there, I know for instance, If you think from an organizational structure in terms of managers and employees and subordinates, there's a term at least we use in the fire service and I've heard it used other places here called span of control where you only want one manager to manage no more than five employees because it gets too messy. All that to say is there's some sort of guideline whether it's general or specific on how... many smaller pieces an organism can have. You know, for instance, as an organism, what I only want to have no more than five or 10 molecules under that part of one organism, and then under the molecules, only five to 10 different atoms that make up a given molecule. Have you run into any restrictions or set any guidelines on numbers like that?

 

To be more specific, you rarely even need organisms. Because organisms, for example, are a set of molecules. For example, if you have a login form, that will be organism. But you don't have that much of an organism in your application. You are mostly will be using molecules in your pages, just that. I never been in a company or been in a... I never made a component library that used a lot of organisms. The need for the organisms are so rare comparing to molecules and atoms. You have a lot of atoms, you have smaller molecules, and you have a smaller organism. And you have even smaller templates. So because of that, I don't even consider templates as a component library. So because they are so rare, they should be in their respective folders.

 

Uh huh.

 

Yeah, that's the thing.

 

Okay so then to follow this, it's almost as if, I'm trying to think how to put this, your organisms are almost the pages as compared to the components themselves. I mean to be honest you could almost, you know, you could use this paradigm for lack of a better word for your site as a whole, right? So you know, say you have a page. as an organism that's made up of different molecules if you want to think about it that way, different sections on your page, your sidebar, different areas within your main content, your nav is a, you think of as a molecule and then your nav can be broken down underneath that. Is that, do you think about that in the design system at well or are you strictly thinking of it in terms of the components, the individual components that you use throughout the application?

 

If you want to make an organism, it should be accessible with the props and events. So if you have a full page as an organism, it's super hard to make it controllable with props and events, because it has a lot of elements. So because of that, as you said, it should be a limit to the components that you have in an organism. So for example, the number 5 you said was like good. or even less, but it depends. It depends on the things. It shouldn't be so hard to make it reusable with props and events, because props and events are the things that we have in Vue.js. We have props that go down and events that go up, and we don't have anything else. So

 

Mm-hmm.

 

if you can make it manageable with props and events, then

 

Mm-hmm.

 

you can make it a component, make it an organism or something like that.

 

Okay, so you had mentioned when we were talking earlier about how generally you're going to get atoms and molecules but pretty rare that you'll have an organism in terms of the design system and the things that you're creating. Can you give me an example of where you have seen or where you have used an organism going, using that third level?

 

Mostly in the forms, the forms that are so repeated in the application, like login forms, like for example, the forms that are repeated in the application, like confirm models or these kind of things that are so repeated in the application and you want to reuse them a lot. But for example, if there is a page that is different from other pages, it shouldn't be in a... the component library at all, because it's just one time thing or two times

 

Right.

 

thing. So no need to even hassle to go through all of those problems to make it reusable and stuff like that.

 

Right, if it's a one-off, there's no need for creating it.

 

Yeah.

 

You know, it's like content management systems, there's one that I've used called Prismic, where you can define by your content types, you can define it either as this is just a one-time or this is a repeatable thing. So yeah, that makes sense. Yeah, I know, speaking from my day-to-day experience, modals and forms, that's the stuff you're gonna use all over the place, right? A modal in particular. Because your modal can have I guess I could see it where your modal is your organism, right? And then maybe the form components are your molecules and then as you said the different parts of the inputs would be the atoms.

 

Yeah, even some of the atoms you have don't have any design. The thing that, for example, the model should appear on the top of everything. So that functionality that something appear on top of other things by a state or something like that,

 

Mm-hmm.

 

it can be an atom by itself and you can name it dialogue. You can name it overlay or something like that.

 

Uh huh.

 

And then you should have a card of the model, which is another atom. And then you have the header of the model, you have even the close icon, even the footer of the model. And then you will combine all of them in a... You can decide. If there's a lot of options, it should be organism. If there are limited ones, it's a simple model. You can put it in molecules. So that's the thing.

 

So how you define them is going to be based on the needs of your particular application, right?

 

Yeah, that's the thing, exactly. Every application is different. Some application has really extensive models, for example. Some has really simple models, simple stuff. So you don't need to really over-engineer and do a lot of things that you may not need in the future.

 

So, okay, so we've talked about a design system within a application. I'm assuming that an organization like yours has multiple applications. So is it safe to assume that you have one design system internally that can be used across your multiple applications? That would seem to be the reason for doing one in the first place, I assume, correct?

 

Yeah, exactly. Actually, we even think of making the component library as an MPM package for private MPM package that we can use in multiple places.

 

Mm-hmm.

 

So this is where it financially makes sense to make really extensive big component library.

 

Mm-hmm.

 

When you have multiple applications that have the same design, or you have a big application that has the same design, and the design is really done by your designers and You don't want to mess up with your designers because they will get

 

Hahaha

 

angry if you just use beautify and Just change the colors and say yeah, this is just kind of look like it's what something you did But no,

 

Hehehehe

 

they want it to be like exactly like they what they did pixel perfect otherwise they and I get them because They are researching, they are going through all of the best practices, and they make some designs, and then one developer just wraps it, view defy, and says, yeah, this is the button you made. Kind of looks like it. Yeah.

 

Hahaha Yeah, you don't want to anger your designers because then things won't look good if they get mad,

 

Yeah,

 

right?

 

yeah exactly.

 

So, at Trango, do you have any ideas of how many applications? I'm assuming you have some sort of design system in place, right? Or that's where this all came from.

 

Uh,

 

So how many

 

exactly.

 

applications would you say you use your design system across?

 

Trenco actually is just one application, but we have like different... if we are in different devices like in we are on mobile and we are on desktop and we have a web application too.

 

Mm-hmm.

 

So this design system is getting used across all of those three. So

 

Mm-hmm.

 

it's the same application but in different devices because it's just one application just called Trenco.

 

Okay, so I'm assuming that your CSS has all the reactivity built into it, right? You know how it adjusts for mobile versus tablet versus desktop types of

 

Yeah, exactly.

 

things. Okay.

 

Yeah, it's just one application. It's just one web application that is getting used in all of our devices.

 

So just out of curiosity, how is that built? Are you using something like Electron or Ionic for your apps? Or is it just basically web apps?

 

As you can maybe know, it's an electron in the desktop. But I don't know if I can tell it here.

 

Okay, that's fine. That's fine. I don't want to get you in trouble. I'm just always curious to see

 

Yeah.

 

what tools people use for building their different applications for sure.

 

But I can tell that the desktop is electronic because it's quite obvious.

 

Is it using a lot of memory? Is that why? For sure. So when it comes to, obviously you're gonna use CSS inside of it. I don't know if you can tell me this, use something like an atomic library, so like a tailwind or something, or is it just hand built CSS, where you sign your classes and all that kind of stuff? How do you? How do you incorporate that into your design system?

 

We're using Tailwind, but

 

All right.

 

as you may already know or not know, I don't like Tailwind. I

 

Oh,

 

think

 

okay.

 

for the big applications that you have a really extensive design, I think Tailwind is just reimagining CSS, because it's

 

Uh huh.

 

just all of the CSS features,

 

Mm-hmm.

 

but with different names.

 

With atomic classes, right.

 

I get why people use Kelvin,

 

Uh huh.

 

because it's easier just speeding things up, like put everything in the class, but when you have a big application and everything doesn't have any name on the app, HTML tags, that's gonna be a chaos. But we are using Kelvin now, but I'm not the person to decide, but if I was the person to decide, I

 

That was

 

wouldn't

 

my next question,

 

use Kelvin.

 

yes. You would

 

I

 

use

 

wouldn't

 

what?

 

use... I use just CSS.

 

Just straight CSS.

 

Or STSS if you

 

Sass

 

want to do

 

or

 

some.

 

something like that.

 

Yeah. Yeah.

 

So you like to use close to the metal, just use the basic stuff.

 

Exactly.

 

That's going to give you more control, I'm sure, of how you name things and where you put things and stuff.

 

Yeah, that's another thing. If your component library doesn't have name in the classes, you cannot, for example, the thing is in the Vue.js, if you don't make your style scoped, you can even edit the child's CSS. Like you have a component children that you

 

Mm-hmm.

 

can edit the thing. But if you don't have any named class, you cannot edit that children. Another thing is when you're using Tailwind, you need to do like post CSS and go through all of the versioning of post CSS, something's deprecated, and all of those hassles for just ease of not having a separate CSS file.

 

Right. Well, that would

 

I

 

make

 

don't

 

sense.

 

think.

 

I mean, you're creating your own custom component library in the first place. So you want to have as much control over what goes into your custom component library, you know, as much

 

Yeah,

 

as

 

all

 

possible.

 

right.

 

So, yeah, I mean, every tool, there's no one tool that's going to fit all use cases, obviously. And and

 

Exactly.

 

tailwinds are very popular, but there's some places where it just doesn't work and that's fine. You know.

 

Yeah, exactly. Tailwind is so fine. Tailwind is nice. It has a lot of use cases, especially for the landing pages and the thing that you want to just go fast with it. I don't think it's really good for the thing that you want to age. You want to go back and edit later. Because if you want to go back and edit the template that is using Tailwind, I don't know if you have the experience with that. The template looks awful. Like it's big and it's not really good.

 

Sure, sure, awesome. All right, so I think we've covered everything in your post in general, anything else in particular regarding design systems in Vue and how they work that you wanted to cover.

 

Yeah, the design system, I think if you have a company that have a design system or even have an application that has a design system, it's nice that you have like the alignment with your designers too because if you have a designer or you are a designer, it's better to make those components in Figma too. So it's all the same. So you have an atom in the... code so it's better to have that atom in the figma or in the sketch or any tool that you like they all have component component thingy what they call component feature so yeah yeah

 

I like thingy.

 

so that's the thing sorry because my english is not that good so that's

 

I use

 

the

 

thingy

 

thing

 

all the time, it works great.

 

yeah

 

I'm sorry.

 

You can use it for everything like, Tinguy can be UJS, can be JavaScript can be...

 

Yeah, that thingy. Oh yeah, I know what thingy you're talking about. Sure, that's great.

 

That

 

Ha

 

green thingy!

 

ha ha ha ha. Yeah, for sure. Awesome. All right. Well, thank you for that. That's a good discussion on high level and low level stuff with component libraries. And we'll leave the implementations up to the listeners, because that can get very

 

Yeah,

 

complex,

 

it's a little bit boring.

 

for sure.

 

It's a little bit boring conversation. There is not a lot of Actually, there's not a lot of things around these because not everyone needed these kind of things most people just will go and use beautify or use a lot of

 

Bootstrap view, yes.

 

Yeah, pre-made component libraries, but I think it's really really really valuable for the people that have a big application or have a design system. And when you want to do that and you search in the internet, there is not enough articles. There is not enough things how you should do it. For example, even the Atomic Design Principle, I was searching the internet to know how should I use it? Like what's the thing? I know what it is. I read the first sections of the book and I know what is it, but how can I do it in Vue.js? How can I do it in the... React.js or how should I do it? Or the solite, yeah, it's open-close principle, but how can I do it in JavaScript? How can I do it in VJS? So that's the thing I really like to really emphasize of how we should actually do something.

 

Yeah, you've got the blog post has a number of code samples in there putting something together so that's a little easier to read and play with than it is to talk about

 

Yeah.

 

the code samples. But anyway, great. You know, and I think one final point I'll make is that if you think about it, anytime you're putting together some sort of web application, whether it's a static site, whether it's a dynamic site, you know, whatever. You're basically using those principles anyway in terms of how you lay out your components, right? So, for instance, as a little side project, I'm building a static site for a business, for a friend of mine using Astro and using the same thing in there. You know, I've got, here's my page, okay, here's my nav bar, and here's my footer, and here's my header, and within the nav bar, you know, the different items. So, you're using the same hierarchical structure. in most any app unless you have something that's so small you just dump it all in one file which is always a possibility. This paradigm is certainly bigger than just design systems for large companies.

 

How is Astro? Do you recommend it? I never used it but I looked into it. I was not sure to use it or not. Do you recommend

 

Yeah,

 

it?

 

it's neat. The idea behind Astro is that you use as little JavaScript as possible, but you have the flexibility to use it as you need it with whatever framework you need to use it with. So the idea is that obviously, you know, you know when SPAs first became the rage with Angular and then you know view and react and that was a way to do it well then you know you've obviously got your problems with the more JavaScript you have the more that it needs to download to your browser which has performance issues and so now you see the pendulum swing back to as using as little JavaScript as possible and you know that's where you run into static sites and you know Next and Next and you know Jekyll going back to you know some of the original

 

Yeah.

 

tools. So the idea with is that you create static pages, you use what are called.astro components, which has all your HTML and all that stuff in it, right? And you can use, you plug in, I'm using Prismic as a backend for an example, and then at build time, you generate your static site. But within... your Astro components, you can throw in a React component, you can throw in a View component, you can throw in an Angular component that gives you maybe some dynamic showing a graph or something or some sort of click and it happens right away. And it's the islands architecture is the way it functions is that here's your ocean of your whole page and now I've got little islands of little JavaScript interactivity within there. So it gives you the islands architecture but it gives you the flexibility to use the framework tool that you're most familiar with. So it gives you great flexibility. And then you generate a static site, upload it, and you've got great SEO because of your static component along with your interactivity. So that's the gist of it. And yeah, I really like it. I've heard about it a lot and this is the first time I've really tried to use it. But yeah, it seems like a really neat tool with some good flexibility.

 

And I like their websites. I'm seeing the websites they have. It's so neat.

 

Oh, some of the, yeah, the Astro. Yeah, I've seen some really neat stuff on there. So yeah, it's

 

Yeah.

 

really cool. Really cool.

 

Yeah.

 

So anyway, all righty. So with that, we will move on to pics. Pics are things where we get to talk about other things, or we can talk about view, your technical stuff. You know, it all just depends on what you wanna talk about. I know we talked, sort of sprung this on you before we started. Did you come up with any pics?

 

Any picks? Like,

 

book,

 

I

 

a

 

don't

 

movie,

 

know.

 

food,

 

Okay.

 

you know,

 

Oh

 

a

 

yeah,

 

TV

 

the

 

show

 

Dutch

 

you've

 

foods.

 

been watching.

 

Yeah, if the people that come and want to try Dutch foods and they realize that there is not a lot of Dutch foods that you may like,

 

Oh,

 

they

 

okay.

 

mostly are without any taste, especially for Americans. So...

 

Yeah

 

They always are like complaining like oh that's true. I don't like it and stuff like that. So if you're going to Netherlands You can try Dutch foods, but don't expect a lot

 

Just not why, just because it's bland or something maybe is compared to Persian food or what?

 

Yeah, like it's just like for example cheese and meat without any flavor and stuff like that.

 

Ah, so it's pretty bland, huh? Okay, so

 

Yeah.

 

what's, since you're from Iran, what's your, do you have a favorite food from Iran that you still like to try to eat there in the Netherlands?

 

Yeah, the thing that I really like to eat here is called fesajan, which is so hard to make. Otherwise I would make it myself, but it's so hard to make yourself. So that's the thing I really want to try when I come back to Iran, I think.

 

Oh, so you don't get it there in the Netherlands, huh?

 

Yeah, you can make it in the Netherlands, but it takes like 2 hours, 3 hours just to make it. So,

 

What's in

 

I

 

it?

 

don't have it. There is like a lot of things. Let me see. Actually, I don't know how to make it too, like my mom mostly. But it has chicken,

 

Okay

 

pro-gamut, something like that. and butter, olive oil, like onions, walnuts and these kind of things.

 

Hmm, sounds good.

 

Yeah.

 

Sounds nutritional, for sure.

 

Yeah, cinnamon. Some people put cinnamon too. So, yeah. Black

 

Alrighty.

 

pepper.

 

There you go. Yeah, if it's too hot, I can't eat it. I'll tell you that much right now. My brother was blessed with the kind of mouth where he can eat super, super hot peppers and like, yeah, that's really good. I'm like, you know, smoke's pouring out of my mouth and I'm sweating just because I like to tell the story. Back in college, I lived in Mexico for a while. And I was like, oh, I'm going to eat this. The family I was living with had a party one night, it was a birthday party for the lady of the house. Real Mexican food and American Mexican food are totally different things, as I discovered. But they had these six different types of taco mixes you put together with fresh made corn tortillas, which are so good. Out of the six of them, I could eat one. because the rest were just way too smoke and hot for me and I didn't have enough water to put out the fire, you know, all the time. So that's me and my wimpy mouth. So if it's too hot and spicy, yeah, I just

 

Yeah, but

 

can't

 

I

 

do

 

have

 

it.

 

another problem because my mouth is like, I can handle spicy stuff really well and I like them. But you will have a problem later on. So...

 

with this yes yeah i get

 

Yeah. That's the problem

 

it

 

with me.

 

uh... darn it it is a good but i can't eat it because problems later

 

I will eat it, I will eat it by the way but I think my stomach and my lower half of the body will not like that.

 

I guess I guess each time you have to evaluate to determine if it's worth the price right?

 

Yeah

 

For sure. Alright so I will jump in here with the dad jokes of the week. I gave Milad warning about that so you can laugh or groan as you wish. So you know around here in the states. You know it's summertime in the better weather so you get a lot of people having barbecues having friends over and you know cooking some food on the barbecue grill I like to say that nobody throws a barbecue like me. My record is 28 feet

 

Wow! Nice!

 

That's the joke. Throw a barbecue. Throw a barbecue. You know, anyway, sorry. The

 

Okay.

 

joke always loses it when you have to explain it. But yeah. So.

 

Actually when you explain it, I really like bad jokes. Especially terrible jokes that nobody laughs and everybody looks a bit awkward. I

 

Right.

 

really like those jokes actually.

 

So are you saying mine are bad and terrible? Is that what I'm getting?

 

It's terrible but in a nice way, I think.

 

Terrible in a night. That's

 

..

 

a good way to get around that. I like that, classy. All right, so now if I had a dollar, for every time I didn't know what was going on, I'd be like, why am I getting all this free money? you know, because I don't know what's going on, why I'm getting this money. Anyway, sorry. That one was pretty bad, I guess.

 

I love them to be honest. Actually it's like a mind game. You will go and try to find the funny part in it.

 

Right. And then finally the other day I was talking to my wife and I said, and I'd been outside and I said, honey I just saw a wolf. And she said, where? And I said, no the regular kind.

 

That was funny.

 

you know like werewolf. So yeah I put that in my company chat this morning like I do every day and a guy came back with a great clip from a movie called Young Frankenstein where they play off of that whole pun too. I'll put a link in there, it was really great. So yeah.

 

Nice idea, I should do something like that too with terrible jokes.

 

I like to think that the ones I tell are the best of the worst. There are lots of other ones that I won't tell because they are so bad even I won't tell them. I like to say I have some pride for lack of a better term in my jokes but people appreciate them. Alrighty, so before we sign off, Milad, if people want to talk to you or get in touch with you and hear some more pearls of wisdom, where can they do that?

 

They can go to my website which is connected to my Github but all of my contacts are there or they can give me an email with my email which is milad.d3 at Sanjimal So they can use all of those things or they can connect me in the LinkedIn just search my name and My face will show up

 

So what's your username on GitHub? We'll put the links in the show notes.

 

Yeah, I sent you the link in the chat.

 

Oh, okay.

 

So yeah, that's

 

Oh, yep,

 

it.

 

got them here. Right, so we will put all that in the sharing. Do you use Twitter at all by chance or?

 

I use Twitter, but I just tweet in Persian, if you can

 

Oh,

 

translate that.

 

right, suppose you can use Google Translate, right?

 

But don't use it because it's mostly terrible, terrible stuff like jokes and stuff.

 

I like that. That's the kind of profile I like to follow, you know.

 

Yeah, it's not technical at all.

 

Right. And yeah, and so for those of you that like my jokes, if you go to my Twitter, which is wonder95, five days a week I'm usually putting a joke out there. I'll leave it to you to judge whether it's good or not. and I'm 195 on GitHub there. Alrighty, well thank you for coming on a lot. This has been really great. Appreciate you coming on to talk about design systems. And for everybody else, oh, before I forget, I'm sorry. I'd like to thank the studio audience as well. Right, thank you. And you can't see it here, but Mulata's waving to the studio audience. His appreciation. And that will wrap up this episode of Views on View. We'll talk at you next time.

 

Thank you for having me and it was really nice talk. Your jokes were really daddy and it was nice. So yeah, just

 

Thank

 

that.

 

you, thank you. Alright, adios.

 

Adios.