Lucas Paganini (00:02.723)
Hey, welcome to Adventures in Angular, the podcast where we keep you updated on all things Angular related. This show is produced by two companies, Top End Devs and Unvoid. Top End Devs is where we create top end devs who get top end pay and recognition while working on interesting problems and making meaningful community contributions. And Unvoid, which provides remote design and software development services on a performance basis.
clients only pay for delivered tasks. In today's episode, we have a very special guest. His name is Danny Parides.
Dany Paredes (00:43.107)
Lucas Paganini (00:44.411)
Hello, Dani. And well, today, Dani is here with us, and we are going to be talking about UI libraries in Angular. So when should you use one? When should you just build it from scratch, build all your UI components from scratch? And also, which options are available? Because I think we're all familiar with Angular material, because it's just
wildly referenced in the Angular community, but that's not the only option. There are many others. I'm not going to paint myself or Dani as a know-it-all about every single UI libraries that exist, but from our experience, we may have had contact with some of them, and we can talk about the ones that we're familiar with, the ones that we liked. And of course, when
Again, right? So when should you use one and when should you, should you just build one from scratch? So this is going to be the topic of today's episode. And yeah, Danny, let's get started. So what do you think about, we start with the conceptual question of when, like which problems this library's solve, which problems they create because it's not all good. Right. And so the pros and cons, and then we can talk about.
when it makes sense to use them and when it doesn't. So from your point of view, what would you say are the pros and cons of using a UI library? Which problems do they solve?
Dany Paredes (02:26.066)
Okay, Lucas. First, you know, when as developer, when we work in company.
You are building products. The speed is something very important to have. You need to deliver fast, but sometimes when you need to deliver fast, at the same time, you need to create everything. The library, create your own library is something that you need to take care because you need to, uh, maintain that code. It's not something that you need to take as the first approach.
In some scenarios, from my point of view, create a library, help your team and your company to speed to time to market. Because, for example, you and me are working in the same product and you need to show a grid with all the list of data. If you create your own component, like create my own component is waste of money. So when you take a decision, hey, I want to create a library. So it's because.
you have something that is repeat around your application. If you are building a simple landing page, you don't need a library, of course. But if you have a product that have some component around the whole application, it's very important to you take a solution.
Lucas Paganini (03:50.399)
Gotcha. So basically, if I'm going to be using the same thing in multiple places, then it makes sense to create my own components. Is there a middle ground? Because I think there's this discussion about when to build your own components and when to use a UI library. I don't see...
Dany Paredes (04:12.374)
Lucas Paganini (04:16.047)
many people, I know that a lot of people are doing this, I don't see them very active on social media saying, just go with both, right? I'm pretty sure a lot of people are, they have custom components and they also use UI libraries for some parts of their application. But if you look online, I see much more like people just go in one way or the other. But in practice, I think people can use both.
But then if we were to use both, which problems would we have?
Dany Paredes (04:52.946)
Good question Lucas because I can tell you I'm working with libraries for more than five years in two companies I'm working oh we want to create our own library this is common that ah
the company won't have its own brand and that kind of stuff. So in my current company we're building our UI library, but when you create a library you need to know what the responsibility you take, because I have a post that where I'm talking about the common mistake that when you create a library that you need to take care because
For example, the common point I hear in every place is, oh, you need a design system. Oh, we need to create the atom. We need to create everything. But you have to deliver something to the market. When you tell to the manager, no, I need to spend the next three months building a grid or a placeholder or a form generator, they say, okay, but the product need to be launched in December.
Do you want for the summer or for December? So this is important to know. So, and also you need to take care about the using system, the how you deliver the, your library. If you use NPM or your wheelhouse in your own, in your own repository. And also the flexibility that you need to create your components. So with all these points in your head.
you say, okay, I'll create my library, but I need to first create... This guy, I don't remember the name right now, but I think, let me say, called Bram Frost, if I'm not mistaken, the creator of Atomic Design. He said that, no, you need to have that interface inventory. You need to know what's the primary piece that you need for the framework of your library.
Dany Paredes (07:01.558)
So instead to go to create the atom, the point, no, create the really you need because you need to deliver and get feedback from your, for your customer. That your customer are not the client, is another domain that you have in your company that are using your library. And when you start to see that, is that you say, okay, this is a new project. This is not something I will do in one week or two weeks. Create a library is something that takes time. If you want to...
that have a good ground to the library be extended in the future. I don't know if I can answer your question, but this is a topic that I work a lot because I, I take, I did a lot of mistake building, a lot of mistake using a wrong tools, trying to create a component with sometimes with too much flexibility, but you developers do whatever you want. But sometimes that's break the design and sometimes you need to have a balance between
Oh no, I use ING content? Oh no, I will use a lot of input property that I have the control over the design.
Lucas Paganini (08:12.595)
Yeah, I don't think people see all the complexity when they make this decision at first, because it sounds so simple when you get started. It's like, oh, I'm just going to create the component. Is that it? But if you really want to use that, then you would have to isolate that somehow so that you could use it in other repositories.
And this isolation, if you're in a monorepository, then perhaps that's gonna be, a lot of the pains are gonna be dealt with. By the way, I love NX because of that. It's just so much easier to just have everything in a single repository. Of course, you lose in terms of access when you do that, because every developer has access to everything. And that's not something that enterprises are comfortable with.
And also when you have a large enough number of teams, then that also doesn't work because you literally, like the time that it takes for you to send your PR and run continuous integration, the branch that you're targeting already changed and you're gonna have to rebase again. So it literally doesn't work if you have too many people working on it. But...
If you have a small team and you're just using a monorepo, then perhaps it is easier for you to get started with your own library. So that takes care of it. If not, one approach, if you want to isolate that and use npm to install is to, well, you can just public that.
Dany Paredes (09:59.006)
Lucas Paganini (10:05.231)
publish that in npm publicly and then everyone will be able to download it. But if you want to have private access you can pay for your private libraries on npm or you can even use the github package registry which supports the same protocols as npm and you have private packages for free. So that's one way I went to that route once when I had that multiple...
different repositories and I needed to share some code from them and a lot of them were literally libraries that we needed to share, but they were just internally for the company so we couldn't just make them publicly available. So that's one way to go. But then going back to the original question, which is if you should use both, and I think other problems that you need to consider is.
Dany Paredes (11:05.538)
Yeah, one thing that's, oh, sorry.
Lucas Paganini (11:05.859)
Well, first of all, I don't think I would... Oh, sorry to cut you, but when considering to use some UI library or some external components, I would be very careful to not import an entire library just for one or another component. I think that would be... I don't think... I'm not gonna say that this is a...
bad decision because it depends on timing. So if you need things to be done really fast, then sure, at the end of the day, we are developers and our job is to actually deliver the application and to deliver value to the end users, not to try to find the absolute best perfect way at first. But I just, I found myself in so many...
bad situations due to such decisions, like two or three months go by. And when you take a look at your package JSON, you have 20 dependencies that are like for small things, right? And then like, why are we using, like you're importing a library that just exposes one single component, like a carousel or like, really? I don't know.
I think that if you go to that path, then that can be a problem. But if you import like a big UI framework and then UI library, and then you use that when you don't have time to build your components, then that should be okay, like you can have Angular material or even Bootstrap, I hate that, but whatever, or Nebula or Kendo UI, you can import these, but like choose one.
and try to use that one as much as possible so that you don't add other UI libraries. That would be my approach.
Dany Paredes (13:13.712)
Yeah, that's something that you say that...
is happening a lot because you have a lot of peer dependencies only for that. This is something that the people need to take care. If you create a package, try to don't require to the consumer need to install all that dependencies. This is something that happened a lot. But something that you say, right, for example, the people at the beginning say, Oh, I'm creating that, but they're not thinking about, for example, something very simple, the theme.
How do you think you're a library? So you need to take care of that because if not, you need to import all the CSS and you have a bundle. So be careful.
Lucas Paganini (13:47.261)
Lucas Paganini (13:54.615)
Yeah, and also people need to keep in mind the major requirements of the project. For example, team is an important one. If your app needs to support multiple different teams, or just the basic light and dark team, not every library provides those two options. So that is already something for you to consider when choosing your library.
Dany Paredes (14:19.882)
Lucas Paganini (14:24.463)
But I'm gonna go beyond that. And I'm gonna say that the best ones support what I'm about to say, but a lot of the more amateur just starting out libraries don't support that, which is server-side rendering. And I get it. Like it takes a lot of work to do. I'm not throwing shade at those libraries. If I were to start a UI library and I needed to just have all the components fast.
Dany Paredes (14:48.642)
So, I'm going to go ahead and start the presentation. first item, which is the
Lucas Paganini (14:50.855)
Maybe I would not prioritize server-side rendering at first, I'm talking from a broader sense, but I care a lot about this. So I can't use a library if it doesn't support server-side rendering because it's not something that you think about a lot in the beginning, but then when you actually launch your application and then you have to think about marketing, accessibility, SEO,
performance, then there are going to be pages where you might want to render them on the server, either to make them more friendly to search engines to index your page, or just because it's a page that needs to be extremely accessible and it's like the page that...
90% of your users are going to spend most of their time at that page. So you want it to be as fast as possible and you want them to be able to access that from whichever browsers they're using. If they're in their company and the firewall is preventing a lot of network requests, you want them to be able to use it nonetheless. So in such cases, if you.
at some point of your application, import the things that don't support server-side renderer, then you're gonna find yourself in a really weird situation where you're trying to explain to other people in the company that maybe don't understand the technical difficulties, why you can't deliver that particular part of the system using server-side rendering.
and you probably don't want to find yourself in that position. So I would consider... Actually, I just exclude libraries that don't support server-side rendering just because I think this is important. But if you're going to be okay with libraries that don't support server-side rendering, just be aware of the trade-offs that you're making. And maybe it's fine for your case, just be aware of it.
Dany Paredes (17:03.792)
Yeah. It's important to know.
Lucas Paganini (17:08.015)
Did you? And let's talk about the libraries that you have used in the past. So I'm very familiar with Angular Material just because it's the default library that everyone learning Angular ends up using it eventually. But there are many others. Before we started recording, you were talking about your experience with Kendo. I only know that by name. I have.
Um, I took a look at their website and their library, but I never really used it. So I've been curious, like, if you are going to use a UI library, why not just stick to the status quo and use Angular material?
Dany Paredes (17:56.453)
Well, I think that AngularMaterial is a very good UI framework. Also if you are, if you don't need one to...
embrace the UI and design, you have the Angular CDK. So you can create your component only with the behavior, but not need to fight with the styling. And for most of the project that you need to build maybe application, Angular Material covers most of the case. But when I take the decision, I want to move to a library like Kendo that's
is the free, is when you really have a product that you need a huge amount of components that for example, Angular material don't bring to you, also the support and for example, another case, Angular material, but if you are using React or are using Vue and you are not have the same support and that is something important if your company are using for example,
micro-frontend and everything needs to have using something like React or whatever. It's important you have a library that provides support for all the technology. In the case of Kendo, for example, support jQuery. Keep in mind that, jQuery in no days. But some projects, here in Barcelona, you have some companies.
the government that they have some page that are in legacy and you need to, ah, we want to have a great interface so you pay for a came that you can cover. That's escape. But I, another library, very good also in the market, but the only downside I saw is if you want a AJ Griggs, for example, is another good library that have some components.
Dany Paredes (20:01.718)
So from my point of view, if you want to take Angular Material or Angular SDK, this is a good option. If you want to look for something that have a huge option and support for PDF printing, that kind of situation you don't have with Angular Material. So you'd need to pick up, for example, Kendo.
Lucas Paganini (20:24.131)
Gotcha, gotcha. So it's not just, oh, I don't like the way that Angular material bottoms look like. That's one part of it, but there's also the part about some libraries are just literally bigger than Angular material. They have more components, they have more flexibility. Okay.
Dany Paredes (20:47.763)
Yeah, that point of the flexibility is something that, for example, in my company, we are our own library. We have our own library, but they are on top of Kendo UI. We have our own color brandings, the kind of stuff that they have something called Team Builder, that you can create your own team that match with the colors.
You can extend the component, for example. And we have a set of components for the company. We're building a content system, but we don't have the UI that we have. But we can customize very easily, but this is something that we need to pay. I would like to have that in AngularMaterial, but keep in mind that thing. If you are getting money for your product, pay for that. You save time for the developers.
But if you are doing some open source, please use something free.
Lucas Paganini (21:46.979)
Gotcha, makes sense. Yeah, let's get into the pricing for those things. Like a library like Kendo, for example. How is the payment model for that?
Dany Paredes (22:03.218)
I don't have the real current prices, if you can check out the website. But I think that they support domain or something like that. I can tell you about the pricing because I know Pay4Lets, the company. But this is something I take care of. If you are in a project that doesn't have too much budget, go take the decision. But I don't know what you think about that, Luca. When you start to create the components,
Maybe if you create a library as a bridge between the care party library, Kendo material or wherever, that is important when you create your own library because your library works like a bridge between Kendo for example or between
Dany Paredes (23:00.386)
using Angular material because your project is starting, but when you start to say, okay, no, now I need that, so you can just, from your library, working like a bridge, connect with another library, like Fendo or whatever. We have the same situation.
Lucas Paganini (23:18.764)
It's also interesting to think about that as a product, because we can look at that from the consumer perspective and it's like, oh, there are a lot of open source libraries out there, why am I gonna pay for that? But yeah, there's a ton of value too. There's a lot of time that they take off from your product development. So looking at it from the perspective of a company.
Sometimes it makes sense. But there's also the perspective of a seller of the library. Like, I don't think many developers think about the fact that they can sell libraries. It's just not that common. We sometimes think of, oh, we need to create a SaaS product, and it needs to be like a closed sourced.
something running in the cloud and we charge a subscription. But there are people actually getting money just selling libraries. There's a particular library that I've been looking at it and I'm probably gonna purchase that, which is I believe Bool MQ. It's a queue that uses Redis.
So you can run distributed queues on Node.js, and you just connect to a Redis instance. So that's really useful for microservices, for example, when you have multiple containers and they all need to share the same queue to make sure that they are not running tasks twice or that they are following the order that you stipulated in the queue if you have priority in your queue.
Lucas Paganini (25:13.591)
all those things are being respected. So boolmq provides all that, but there's a pro version of this library, which is boolmq pro, I believe. And it adds some other features. So, and it's really an interesting model if you stop to think about this, like you can provide a lot of value with a completely open source version of the library, and then you can provide on...
professional or enterprise version of the library, which has more features. And if there are companies interested on that, then sure, you can actually make a living out of that. So that's really interesting, especially for developers that sometimes don't feel too comfortable with all the other parts of running a business that is not technical. It's like...
Since we are all developers, sometimes it's easier for us to understand the mentality of other developers. And once you actually try to build a product, you need to put yourself in the customer's shoes. And most often than not, the customers are not the developers themselves, and they don't see the world as we do. But there are actually products that developers can make for developers or for companies that are going to use it for their development process.
So it's really interesting to see that their company is actually being sustained just selling those tools and it's something that people can consider.
Dany Paredes (26:38.496)
Dany Paredes (26:48.314)
Yeah, because like you say, for example, I share something with you, the FaxDB. This is a new package that I was playing with that in the last two weeks. That is amazing. That is on top of Fax, yes, for creating local storage and like work like allow you create offline application easy. So a lot of developer and clients are creating tool for developers. So
I think that kind of market that you have there, like the UI libraries and also that library that is for RxJS, is easy to convince because you are facing a lot of problems and they are solved. Because sometimes we want to deliver value, but you say, oh, how much take the UI library or how much take create a system to work offline?
You need to create a lot of serving, play with local storage, it's not easy. Or connect with China layer and Firebase, whatever. But when you have a product that they give to you a free version and you play with that, you say, hey, that's the worst, then I can't pay.
A lot of people I think that is getting money, building solutions for developers.
Lucas Paganini (28:08.491)
Yeah, yeah, it's really interesting. I used to think about people spending a lot of time building libraries as like just heroes, but I would think of them as heroes that unfortunately were not getting paid by that. So I would think of a person that has a day job and contributes to the community after work. And that certainly exists. And I appreciate everyone that, that
helps us have the ecosystem that we have today. It's crazy the amount of things that we get for free. But that's not like the only situation possible. There's definitely ways for you to actually monetize the work that you are putting in the libraries that you're building. So it's really, really interesting. But yeah, so we talked about Kindle. We talked about Angular Material. What else?
is out there. I have once taken a look at Nebula too. I found it really interesting. The interesting thing about Nebula is that they have a sample project and when you first see it, you think, holy shit, this is crazy. It's a very big dashboard with a lot of charts and there are...
loading animations and a lot of things that you know take a lot of work and time to create. But I have also seen people really not liking it and saying that the support is not very responsive, that it doesn't have all the features that they would expect, that the performance is not always...
top-notch. So I'm not gonna recommend, but I'm also not gonna not recommend because I don't feel like I have enough experience with it to be able to not recommend. Maybe it is a terrific library and I'm just saying things that are no longer true because I've saw that for a while ago. Maybe they have changed and now they are actually extremely perfect.
Dany Paredes (30:26.565)
Lucas Paganini (30:34.503)
I really don't want to throw shade on nebula, but I think it's an interesting library to take a look to and it just looks good. The components look good. They look clean and minimal.
Dany Paredes (30:47.72)
Yeah. But the problem is sometimes from a feeling that I always work with Angular, that some libraries are very good, but only for React, most of them. Or don't have support for Angular. That's something I say, oh my God, why? So they say, I don't know which...
UI library, I say, oh, it looks amazing, but only for, yeah, don't support for Angular native. Say, hmm, that's something for me is, hmm. But you have a lot of option, also ng-soro, this one for Angular, but for, you have a lot of libraries, but ISO, for example, another, the beautify from Vue, that's something that only works in Vue and also React, but don't support Angular. I don't know why.
Lucas Paganini (31:39.567)
Yeah, they don't like us. But yeah, I mean, I feel that a lot. And not even libraries, like complete design tools. For example, I think it's Framer, the name of a tool that it basically competes with Figma. And I might be wrong, okay, maybe it's not Framer, maybe it's another tool and I'm making a confusion in the names. But there is a design tool that is...
a competitor of Figma, and it lets you import React components. So you can actually code a React component, import it onto these design tool, and the designers can actually just move the component as if they were moving a regular, like the regular assets and shapes.
that they can create on the system. And the cool thing is that the component is actually interactive. So when you render a prototype, for example, users can actually interact with that component. So if you build a date picker and you put it into this design tool, then users interacting with the prototype can actually use this date picker, which is crazy. But yeah, again, React components, no support for...
Dany Paredes (32:57.701)
Lucas Paganini (32:59.171)
for Angular, and I kind of get it because React has a much smaller footprint when you just think of it as a component library. Angular is this complete thing that depends on a bunch of modules, and you never see people just using Angular components and not using the rest of the ecosystem. It's always the entire framework. Whereas React...
you can use in isolation. So it does make sense, but I would love to have a way to use those tools. And I think Angular Elements provides a big bridge, but I think we need the tools to actually use the native technologies, right?
Because think about this, if we have a specification for custom elements, and you're creating a tool, for example, this design tool that lets you import React components, if we have a native specification, like, cool, you can support React components just for convenience, but why not also support the web native format and then let...
Dany Paredes (34:23.819)
Lucas Paganini (34:24.307)
every other library just export their components in that standard and that way everybody's talking in the same language.
Dany Paredes (34:34.638)
That's something I can understand. Yeah, and you say, for example, I remember a few years ago, a study book, they never work well with Angular. Now it's working more or less. But three years ago, I say I love starting to play around my component. But for Angular, it was like, now the last person is working fine. But three years ago, it was like, why?
Why is slow and a lot of configuration is painful? But these are things I can understand. I hope now with the new version of Angular, or Angular 14, that you have a standalone and this kind of thing that simplify a little bit the registration of the stuff, the developers and the tooling can improve the Angular ecosystem.
Lucas Paganini (35:28.26)
Dany Paredes (35:29.096)
I hope not.
Lucas Paganini (35:30.655)
I hope so too. And just so that we actually touch on all the points that we brought up during the introduction, one thing that we haven't talked too much about is which way to go if anyone actually wants to create their own libraries. We talked briefly about where to deploy and install them, but you also mentioned before some that I think we should talk a bit more, which is the Angular CDK.
So if you are building your own components, your own UI library, then you don't need to actually build everything from scratch in the sense of, I'm gonna have to build every little thing from scratch because it needs to be exactly how my company wants the design to be. There are things that you can use that will...
simplify the process of, for example, rendering elements outside the normal flow of the application. So for example, you need to render a model, a dialogue, or a tooltip, or things like that. You can use the Angular CDK to help with that. There are performance helpers, for example. If you are rendering thousands, if not millions of elements,
but you only really want to render the thing that needs to be rendered, and basically lazy render, then you can use virtual scroll, also from the Angular CDK, which improves the performance a lot of your infinite scroll. And other than that, you also have a lot of helpers for accessibility, so to create components that...
Dany Paredes (37:20.821)
Yeah. I have, you have a drag and drop stuff.
Lucas Paganini (37:21.915)
are going to have all the area labels that you need to make your HTML accessible. And what else, Danny, what am I missing from the Angular CDK in terms of what it can help people?
Dany Paredes (37:38.262)
that they have good support. Also, but something that the people under don't think too much is that you say, what's the quote? Oh, the accessibility. Because when you are working, I don't know, I work for a product, but I don't know which the user that's applying with that. It's not easy when you are building your own library. You have support for accessibility by default. Angular CDK help you a lot.
Lucas Paganini (37:39.844)
Dany Paredes (38:07.926)
with that. When you need to create forms and that kind of stuff. Now I think that the dragon drop also, the calendar of Angela Matea for me, from a view, works. They make me prove a little bit, but that's worth fine. Also that they have now.
It's the... No, the Drakhan Dropbot is something that they have for you. Yeah, I think it's the Drakhan Dropbot or something like that. Let me check out the website.
Lucas Paganini (38:38.759)
Yeah, but these are very good points I have forgotten about the drag and drop. And that one is in particular is extremely useful. There are also like observers that they give you. Yeah, so you can observe changes to the window size, for example, things like that. There are a lot of really, really interesting things.
Dany Paredes (38:54.878)
Yeah, for sure.
Dany Paredes (39:06.24)
Lucas, the portal, the underestimated things, the you have played with portal. This is something that people don't use too much. I don't know why. It's very helpful. Now I check out the website. I remember that we played with that in previous companies. They said, oh, a portal, a CDK portal.
Lucas Paganini (39:12.918)
Lucas Paganini (39:17.293)
Lucas Paganini (39:24.971)
And for whoever is not familiar with that, portals allow you to project your content outside of the normal flow of the HTML. So for example, you can have an element that is in your component template, but it's not rendered in as a child of your component, it's actually rendered as a direct child of...
the body tag, for example, so you can sit on top of everything else in the content. So you can have a fixed main menu. You can have a sidebar. You can have modos, dialogues, two tips, drop downs. All of those things, they use portals to be projected on top of the other elements. But the interesting thing is that still, if you
You're going to write your CSS the same way. It's crazy how that works. It's like you're going to write your CSS normally, and Angular is going to project that. And even though the element is not going to be a child of your component, all the styles that you apply to it are still going to be applied. It's really, really interesting how Angular does that.
Dany Paredes (40:48.864)
I highly recommend the people that if have time check out the portal because you can do amazing things and can save you your life in some moment.
Lucas Paganini (40:58.551)
Definitely, yeah. Danny, we're 41 minutes so far. I think we should start wrapping up so that we don't reach one hour. But do you have anything in particular about this subject that you want to bring up before we start wrapping up?
Dany Paredes (41:11.09)
Yeah, my friend. So fast.
Dany Paredes (41:23.346)
Keep in mind that when you start creating your library, please create a toolbox first. Don't start with the design system, please, because you need to deliver. Sometimes it's good when you have... Keep in mind if you really need or expect in the future, use a library. So in that case, create your own library can help you use like a bridge. And also keep in mind that use...
and grow a CDK because it can save you a lot of time.
Lucas Paganini (41:56.439)
Definitely. By the way, I'm going to close this topic with one thought that I have, which is aligned with what you said. And I think it can be a bit polemic, especially if we have many designers listening, but I'm going to say it either way because I think it's true. And from my experience, it was true. I think that the design should come before code. Yes.
you should design what you're gonna do before you start coding. But I do not think that the design system should come before the product design. Why? Because I believe the value of the design system is when you are isolating the repeatable patterns that you found during the design of your product. If you attempt to do...
the design system before you actually have your product stable, then you risk just wasting a lot of time and coming up with patterns and conventions that you should not be worrying about that at first. Oh Lucas, but what you're saying is going to lead my company to have 20 different versions of buttons in the initial version of the product. So be it. And then you're going to realize that...
out of these 20 different versions of buttons, you can isolate 18 of them into just two components and then you're gonna do that. And the other two variations, you can either decide to get rid of them and use what's in the other patterns or you can keep them. It's okay to like, oh, but these two buttons, they're not in our...
our design system. But at the end of the day, what is more important? That the component is in your design system or that you're offering the best possible experience that the user can have in that page? If that page is the page, is like Pareto rule, right? Is the part of your system that delivers 80% of the value, is the place where 80% of the time your users are going to be there, then
Dany Paredes (44:05.545)
I think that's a good way to start.
Lucas Paganini (44:20.879)
Maybe it's worth it for you to break the design system a bit so that you can provide a better experience in that page. Maybe you want to take up less space so your bottom is smaller than in other places. Maybe you want to take more place and you want to make it more attractive so it's a very different bottom. That's fine, you know. So I don't think people should...
have their design systems right in the version one of the product. I think that tends to be a mistake.
Dany Paredes (44:59.838)
Yeah, I like the last statement you said. This is very clear. I would like to hear maybe three years ago.
Lucas Paganini (45:08.475)
Yeah, it's good that, thanks, it's good that I have you here on the show. Otherwise, I may get a lot of heat from that opinion. But yeah. Okay. So let's start wrapping up. Danny, what would you like to promote? Is there anything that you are doing or any project that you would like to share with people?
Dany Paredes (45:09.275)
Good advice, mate.
Dany Paredes (45:38.742)
No, that's if I continue writing article about what I'm doing, that you can visit dannywolves.com. That is my blog where I share my experience, my hate, my pain with creating libraries and the kind of stuff with Angular. That's it.
Lucas Paganini (45:54.987)
Nice. Okay, so dannywalls.com. Is that it? All right. So, where else can people follow you?
Dany Paredes (46:07.022)
Oh, and Twitter, Danny Walls is the only social network I use.
Lucas Paganini (46:12.523)
All right. Okay. So everyone, if you're interested in learning more from Danny, you can check out his website on daniewalls.com or also follow him on Twitter at DannyWalls. I'm going to promote my company, Unvoid. So I am the founder and CEO of Unvoid and a big differential that we have from other software on consultancy companies is that.
Clients here only pay for delivered tasks. So we do not charge by hour, we charge by the tasks that we actually deliver. And the price from those tasks is calculated based on their difficulty. So clients describe to us what they want to accomplish. We break it down into smaller tasks. We estimate a difficulty for each.
of these tasks and we calculate the price based on that, then the client approves and then we start working and we get paid as we actually deliver the tasks that we agreed upon. So that takes away all the risk that clients have when they are trying to outsource. If a task takes longer than expected, clients don't have to pay anything more from that. So there's no way in which we're ever gonna...
in which clients are ever gonna pay for overtime that simply doesn't exist when you're working with us. So if that is interesting to you or to somebody that you know, check out unvoid.com and get in contact with us while we actually have slots available for projects because one other really important thing that we do is we limit the amount of clients that we take simply because
If we try to take too many clients, we really do not have the amount of developers to handle and we don't want to overwork anyone. So we have our limits. We are aware of that. So we are always working within that to make sure that our quality is within what we promise. So again, if you're interested in that, on void.com.
Dany Paredes (48:32.906)
Perfect. I'm taking notes. Interesting.
Lucas Paganini (48:38.22)
Nice. All right. So, Danny, thank you so much for being on the show with us. I hope you come again. You have a lot of knowledge about Angular. Again, I highly recommend everyone that is interested in learning more about the things that we talked about, and just Angular in general. Danny talks a lot about that. He creates a lot of content. And he's just overall an interesting person to follow.
And yeah, man, thanks for being on the show. I hope I see you here on the show again.
Dany Paredes (49:11.051)
Lucas Paganini (49:13.668)
Have a great week everyone and I'll see you in the next one.
Dany Paredes (49:18.865)