Inside the Stack
Inside the Stack is a podcast for developers, founders, and tech leaders who want to understand how real systems are built, scaled, and maintained — without the hype.
Each episode breaks down what actually happens inside modern software systems:
from request–response flows and APIs, to architecture decisions, scaling trade-offs, developer tooling, security, and the human decisions behind technical choices.
We talk about:
- Backend systems, APIs, and architecture
- Scaling beyond traffic — systems, teams, and complexity
- Developer experience and engineering culture
- Practical lessons from side projects, startups, and production systems
- Technology trends, trade-offs, and real-world engineering decisions
Whether you’re an early-career developer, a senior engineer, or a founder building product infrastructure, Inside the Stack helps you think clearly about how software really works — and how to build it well.
New episodes drop regularly.
🎧 Listen. Learn. Build better systems.
Inside the Stack
UI/UX vs Frontend: The Developer Strikes Back | Pixel Vs Code Ep 3
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
The UI/UX vs Frontend debate continues! In this episode, host Oluwole Majiyagbe flips the perspective and sits down with frontend expert Mr Gbadamosi Moshood to uncover what really happens when the design handoff is complete and the coding begins.
We strip away the aesthetics and dive into the reality of building functional, performant interfaces. We discuss the most impossible designs developers are asked to build, why component libraries are sometimes necessary, and what frontend engineers genuinely wish UI/UX designers understood about the DOM. Whether you are a developer looking for validation or a designer wanting to make your team's life easier, this episode is packed with truth bombs!
👇 What we cover in this episode:
00:00 - Introduction
03:00 - When people hear "frontend," they think buttons and colors. What is it really?
03:53 - Why should a person go into Frontend?
05:20 - Is Frontend easy?
08:05 - Your app has to work on every phone, every browser, every screen size. What's the strangest bug you've had to fix because of that?
10:48 - is CSS hard or are we learning it the wrong way and what's the difference between CSS libraries?
14:40 - When you get a design to build, what do designers usually not realize about the work involved?
16:55 - Sometimes a design looks great but is really hard to build. When does that happen, and what do you do?
19:35 - Do you have to build the design exactly as given? When do you speak up and ask to change something?
22:42 - When there's a conflict in packages and design, do you communicate it back to the UI/UX?
24:47 - Design systems are meant to make life easier. Do they actually help you, or get in the way?
26:48 - When the design and what's easy to build don't match, who gets the final say?
29:28 - There's a new frontend tool every few months — React, Vue, Svelte, and on and on. Is that tiring, or a good thing?
33:06 - How do you know when a screen is actually finished/completed?
34:57 - Do you think UI/UX don't understand the amount of work you're to do to implement their designs?
35:48 - How do you tell if a frontend and/or design is complicated?
41:27 - AI can write frontend code now. What does that mean for frontend developers?
45:40 - Outro
🎙️ Guest: Moshood Gbadamosi
Follow them on X/Twitter: [@morshudlhgmo]
Github: https://github.com/morshud
LinkedIn: https://www.linkedin.com/in/morshudlhgmo
🎙️ Host: Oluwole Majiyagbe
Follow Inside the Stack on Instagram/Tiktok/Youtube: @insidethestack
💡 Don't forget to like, comment, and subscribe for more deep dives into the tech industry!
Let us know in the comments: Frontend Devs, what is the most frustrating design element you constantly have to code?
#Frontend #UIUX #WebDevelopment #SoftwareEngineering #TechPodcast #InsideTheStack #UIUXvsFrontend #ReactJS #TechCareer
Introduction
SPEAKER_02You can input SSS in the Steam. We put it on the other hand. We need to be a badest one.
SPEAKER_01UI EX is just drag and job. Two of us, let me know in the comments. Hello everyone. Welcome to another episode on Inside the Stack. We've been going through a certain series, the UI UX versus front-end series, Pixel vs. Code. And we've had two guests on this show today who are actually UI UX designers. We've heard from them. So today I'm bringing in a front-end developer. In a short while, he's going to introduce himself to us. But um yeah, since if you are still here, if you're still watching this video, please do well to subscribe and um share this video to you know UI UX developers, front-end developers who you feel might have uh might gain one or two things from that particular episode. So um Mr. Mashhood, you're welcome to the show. Can you give us a little introduction about yourself?
SPEAKER_02My name is uh Paramosi Mashud. I'm a front-end software engineer. I build data products, I've built several apps, uh web app, um fintechs, logistics app, educational app, which is edutech and agrotech projects. So my stacks are View JS and React Jesus.
SPEAKER_01Thank you. All right, so um thank you so much. Thank you very much. Um it's really nice to have you here on the show. Yeah, so um I'm mostly backend, I do a lot of back end. I know we've worked together, you know. I do I do a lot of a lot of back end, and um, if you ask people they would think back end is just buttons and um colors. I know colors was actually one of the things that discouraged me from front end. I will not like colors, like mixing colors and the likes, but front end has gone past just layouts, just um colors, mixing colors and the likes. So, in your own words, can you just give us what front end is actually?
SPEAKER_02Yeah,
When people hear "frontend," they think buttons and colors. What is it really?
SPEAKER_02um as you said, front end is just about color, about animation, your your bubble and other stuff. It's all about user interactions, like your login, your authentication, and then um, yeah, mostly login and authentication, and every other thing you can do. Like if you open an app, you see that when you log in, you can get your data and other stuff. So that's what frontend is about. It's not about the color and the fee visual that people are saying. So what I evolves is really the functionality, like the interaction of users on uh on the web app.
SPEAKER_01Okay, so um this is like a flow into the next question. If someone comes to you now and says, I'm thinking of going into back end or design or front end, you know,
Why should a person go into Frontend?
SPEAKER_01why why would you give that person that advice that go go into front end? Because I don't know, maybe if I come to you now and say I want to do front end or I want to do design. Uh, which one do you think for me, for example, anyone that comes and tells me front end, back end or design, of course, it is what I have that I would give. I would say definitely back end, definitely. But you know, why front end? Why did you go into front end? Let me let me rephrase the question that way. Why did what was the choice that made you go into front end?
SPEAKER_02Yeah, um, let me just start from if I want to advise someone, it's just a is a choice, and then the thing is that I love do seeing what I'm doing, but we see it between backhand. You can't you can't compare you can't compare. No, we've got to and you know you use postman as well. Just get requests and response. You do get thank. So we we are seeing exactly what we need, what we want to do. So it's easy for us to okay, what is what is wrong here, what is happening here. Though you too, you have you can you can trace it. I don't want to say you can just it's just layouts, it's just the layout and color that you are seeing. No, it's not only the layout. The visibility of the interactions of that front end will want to make you like, oh wow, I'm I'm correct, I'm doing well. So definitely. So is front end
Is Frontend easy?
SPEAKER_02easy? Yeah, it's easy and it's not easy. It's based on my to my understanding, it's easy. Once you understand what the front end is about, it's very easy.
SPEAKER_01So I can even as I'm a backend definitely, I can just decide that I want to design my front end by myself.
SPEAKER_02Ah, if you if you really know what you choose to use to do the front end, definitely you'll be able to do it yourself. But it's not that easy as you look at. Because one, you need to understand um the the the interact, the first thing you need to uh understand the UX of that front end, which is the interactions. Also, you need to also have a visual, you need to know visualize, you need to be able to visualize a design yourself, even without a Figma. You'll be able to come up with okay, if I had this color to this, at least we give me this, and also layouts, web layout, too. You need to understand web layout responsiveness and other things. You have there are a lot of things involved that you have to understand. It's not just that you just it's not just ordinary um the color you are saying, like uh test color and other stuff. There are other there are a lot of things involved, like even we do a bit of something similar to back end, not backend though, but we integrate API integration. Yeah, of course. What backends are doing, we too. We we send a request and we get the response from them. So we are the one sending the request, while the back end is the one sending the response.
SPEAKER_01Okay, now um front end, you know, you said it could be easy, it could be hard. Yeah, definitely based on based on what you want to do or how you want to do it. Yeah, well, for yes, I know we now have um frameworks that actually help a lot with most of this. But you know, there was a time where developing for the web means you have to take into into consideration every screen. Yes, definitely. Every screen from and it was during that just because that we now had it, uh started having smart devices, yeah, we started having laptops, we started having tabs. Yeah, there was a time when developing a website just means the desktop. There was no concern with the mobile, we we we had a lot of like it just HTML, table. Yeah, definitely table, designs.
SPEAKER_02Yeah, you just you just remove the table, but that's it.
SPEAKER_01Exactly. But later on, we started developing for mobile screens. It was so tedious then, yeah, you know, having to take into consideration numerous devices. You have somebody use a small device, you have another person use a big device, and it has to perform the same way on the two.
Your app has to work on every phone, every browser, every screen size. What's the strangest bug you've had to fix because of that?
SPEAKER_01So, in your experience, what what was the like hardest thing that you've done during that during that period? What was the strangest bug that you've had to fix during that period?
SPEAKER_02It wasn't easy then because uh you have to consider every CSS, every CSS code. Like you have to write the whole code yourself. So, no mistake. And then when you want to when you want to create a column, you have to consider a lot of things. One, it's not like when you use grid, like uh HTML on CSS 5, you use grid and flex. You just need to either float left, float right, and clear the boat boat. But now, then um, yeah, when Bootstrap was introduced, which is um that should be back in 2000. Early 2000s, yeah, something like that. It's it makes work more easier. People were enlightened that oh wow, so um front end is even more than what we are doing, that we just create and this, and that from that we started developing, we started developing, and uh we started considering those um tablets and other stuffs using flex and grid. So, and uh the difficulty so far is then was just the um property, mostly if you don't know your property very well and you don't know how to you don't know your um your screen layout, like uh a viewport, a system viewport or your device viewport, it will be very hard to know okay, this screen and this screen. What are you going to hold this particular screen? Okay, are you going to hold this particular screen?
SPEAKER_01So, yeah, so um I think bootstrap started around.
SPEAKER_02I think 2014 or so. Yes, 2014. Okay, so 2020. 2014, yeah, 20.
SPEAKER_01Yeah, they were using it in Twitter, yeah. For it became open, you know, the foundations of front end is HTML and CSS.
SPEAKER_02Yes, definitely.
SPEAKER_01Foundations or not, you know, we can still build a website without JavaScript, definitely, but with hand building websites we we HTML CSS, yeah.
SPEAKER_02You we can just build a landing page without JavaScript.
SPEAKER_01Yeah, it's it's still the same, it's something that can it can stand alone.
SPEAKER_02Yeah, but we you know we always call those people they are not frontend, they are web designer, yeah.
SPEAKER_01Whether it's web designer, whether it's front end is the UI. But uh definitely let's talk about the the okay. You said they are web designers. Now the fact is, you cannot do without being a web designer, but they can do without being a JavaScript, yeah, definitely um person. Definitely, but we are talking about let's talk about the foundations now, the HTML and CSS. CSS has gone
is CSS hard or are we learning it the wrong way and what's the difference between CSS libraries?
SPEAKER_01a long way. There was a time that to me, CSS was just like having a.css file.
SPEAKER_00Yeah.
SPEAKER_01Got to a point, I started saying dot CSS. Yes. I started saying uh we have less. There was one, yes, less SARS, SAS, yeah, definitely. So it started getting confusing. Like, is it hard? Is CSS hard to know? Or is it just that you know maybe the person trying to learn it is learning it the wrong way, or maybe he's trying to like learn a whole lot of things. Then what is the difference between all these should I call them libraries? These um Les, SARS, um S CSS, you know, all this. I'm talking about the CSS libraries now. I know we have a lot of um, should I say frameworks? Yes, uh Tailwind and Tailwind. Tailwind, Bootstrap, you know. Bootstrap is more, should I should I call it like a CSS framework? I don't think it's it's a CSS framework. Okay, so it's a CSS framework also. Uh Bootstrap and Tailwind CSS.
SPEAKER_02I think Bootstrap and Tailwind as difference to what uh there are some there are some things if you look at Tailwind variable, it's also a S CSS, it is converted. We use that we use um Balma. There is a there is a um, yeah. We use it to there's a I think we used it to convert it to CSS. SS is like it makes your work, you can you declare variables and other things on S CSS where you can, even though we do it in CSS nowadays, but then you declare SSS allow you declaring variable, like uh you have your you declare your colors, your um your font size, your font sizes, and everything you want to use. You just declare it, and it's not written as the way it we are writing, um, just as the um the way we write code on CSS. Okay, so it's it's a bit different, but when you convert it, you are still going to get the same result at the end of the day. But the thing is that you can't just put you can't you can't import uh S CSS inside your HTML like that. You have to convert it to CSS. That's what we're converted to CSS.
SPEAKER_01Okay, so how how do we do that?
SPEAKER_02And the is it where the lens, the SARS and the likes coming, or the legs is just for your work to be easier instead of writing, if you write if you are writing CSS of 1000 lines of code, then um for SSS, you can't write up to maybe 500. But when you convert it, you are still going to get the same 1000 lines of code.
SPEAKER_01Uh house, but it's definitely it's going to be many.
SPEAKER_02Yes, it's yes, it's uh just like oh that's more easy.
SPEAKER_01That's great, that's nice. Okay, so um now when you get a design that you want to build, yeah, we are now going into the pixel versus code part of this whole whole of this whole session. When you get a design, you know, nowadays, initially before your front-end developers are also the UI developers. Once you get a job, you have to like come up with come up with the structure and the likes, but we started having like a lot of things that are failing user experience, things that are not easy. The developer tends to do it from his from his own point of view because he has he or she also has code to write and the like. But now we now have UI UX designers, people whose sole job is to actually research okay, this thing that this user says he or she wants, or that this client says he or she wants, is it is it nice? Is it something that is user experienceable, like when users experience it? Is it something that I want to come back to? So that is one thing that we always that this that UI UX people that is one major job that they have to, you know, they have to make sure that they keep users on the screen and not make they make them like just leave. So what is uh when you get a design, what sometimes what is what is
When you get a design to build, what do designers usually not realize about the work involved?
SPEAKER_01that one thing that designers don't usually get, or they don't um should I say they don't realize what the work is about.
SPEAKER_02So um designers are wonderful, but they always do, they always say we say maybe they overdo or something because we both have the documentation. We the developers we really understand the document than the UI UX because we are the one that wants to do the work. Though they have the they can visualize it, but we we know what the this we know what they want, definitely. So which we expect them to know what they want. It's not only about UI, it's about the UX itself. Because there are some UI designer, the UI UX design, they are just UI, they are not UX, and also they need to understand that it's not about being animation and all this stuff. That's not the main uh main cast of a web. They need to understand the experience, the interactions. For example, uh, if you you go to a web, and also they should know they should also know that um those animations they slow down the server too. So we are going to do a lot of optimizations, kind of before, for example, an image that was used on UI. If you download it, it may be like maybe two megabytes at the end of the day. But we need to go and compress it because loading a two megabyte on a website is yeah, you know that you'll stay a long time before the site loads. So they just need to understand the user experience. They need to also take every detail. They also need to uh think like someone that wants to use it. Like, if I go to this, what do they want? They what did they want, what did I want to achieve on this website? Not about what I would want them to see my work.
SPEAKER_01I think that's where UX research comes in.
SPEAKER_02They have to like do their research to some is just they just want to let people know that no, I'm good at using color, I'm good at using and and at creating visual representation of a website. No, that's not it.
SPEAKER_01So that there are sometimes that you know a design that is given to you looks good. So just give us an instance where an example, story time, where a UI UX developer or UI sorry, UI UX
Sometimes a design looks great but is really hard to build. When does that happen, and what do you do?
SPEAKER_01designer, okay, after he or she is done with the job, and you just sit and you'll be like these things.
SPEAKER_02I think I've encountered with something like that. There a lot of times, a lot of times where you just see the UI be like this thing is not practical, it's not practical, though it may be practical, but the time consuming before I can we can achieve it. Okay, so it's very time consuming. Sometimes their design will be like to them, it's wow, but what's this? What's this? And also it may it may not even align with what we want to do because as they are doing their UI, we are also um, we are also doing our own part of it. We are doing our own um rough skelet front end too. So we too we are doing it, we are working as they are working, just as back end too is working.
SPEAKER_01So if we are given document, mostly back end and UI always work at the same time, and what backend is giving us might not be what might not be what the UI yes, but you know, we we always have like a product requirement document, yes, definitely that everything has to like go through, then every so whatever the back end, whatever data that is that every user is um or whatever data that any page needs, I mean you should have actually been part of the uh research already. So if that occurs, this is me jumping the gun here. So if that occurs, I feel like it is a case of not enough research being done. Maybe somebody just jumped straight into code without exactly thinking about oh, you've already told me this is what is this is what this is what they're doing.
SPEAKER_02Just as you you see design, you just you need to we need to go through design. Even designer, if designer bring a design, you need to go through it, and also when the backend send uh back end also drop a documentation, you have to go through it and the UI, you need to compare. Compare the two. If there is a contrast there, definitely there is we need to communicate with each other, and miscommunication sometimes always affects um our own part.
SPEAKER_01Miscommunication, miscommunication is one factor that always affects it.
SPEAKER_02Mostly we, we we always think uh we are yes, we are big. Yeah, we always think we are big. So maybe sometimes, but I don't do that. I need to you always think we are their boss, they need to whatever.
SPEAKER_01So miscommunication does happens, and that makes so you are you you're you feel like as a front-end developer. We are we are we always have an ego, yeah. It is what you say that the UIUX just has to just have to have the we always think we have the yeah, so that's we for you when it
Do you have to build the design exactly as given? When do you speak up and ask to change something?
SPEAKER_01is when the design gets to you, do you build it exactly as it is? Yeah, yeah, we build it exactly, but there are some there are there there may be some kind of uh there's sometimes one of the videos that I posted on our social media, there was a point where like one or two front end, I'm one or two UIUX developers said most times front ends don't get it, they are icons.
SPEAKER_02That that's yeah, yeah, that icon, that icon, yeah. Definitely the most the icon is always the problem and and and and and sometimes the two things the chart and then shade, the shade of the color that they give you might be the same. Yes, it might be what what the color that is on uh sometimes the figma color is always not the same as the production color at the end of the day, the same the same color code, but at the end of the day, we are going to get another result, maybe something like a shady or something like that. So it's not always perfect with the UI, UI color and the front end color. But even though we are using the same um the color code, and for the icon, mostly that's where we always have problems and chat, icon and chat. Because sometimes icon that they get, we may not be able to see it at the end of the day. So but I think there is there is a there is there is a solution to that now. Instead of we looking for icons that they use, we just kind of get the SVG code of it. Yes, so then we it's now I think we we've resolved that part of icons, but we still have issues with it though, but that that's not an issue anymore. But the chart is now the issue now. Some uh UIUS, they don't they build their chart themselves instead of them to make research on the chart that are available, like we have chart.js, we have um we have uh other ones. Apex charts, yes, apex charts and other they're supposed to make research on those package, uh those packages to know okay, what are the charts available for front ends to use? Instead, they'll go on with building their own.
SPEAKER_01And why why why can't you build a chart as it is?
SPEAKER_02Chart as it is as we always we we want to use a package. We can't be sitting down and be building chart as well.
SPEAKER_01You have to work smart, not yes. You have to build in building another chat package when we have exactly when we have a lot of like a lot of chat packets are available.
SPEAKER_02It's it's it's sometimes it's always it's always good to create a component and you create a chat component that's that is different now.
SPEAKER_01Create creating a component. Now you could create a component around it, but not for like a consultancy business where you have to. Will you start creating components for each and every one of them? Unless maybe you create a global or white uh global component. That means you continue as exactly. So for every comp for every project, you just have to take it in. But um, now the question there is
When there's a conflict in packages and design, do you communicate it back to the UI/UX?
SPEAKER_01now the UIUX has developed this chart as it wants it, but you want to use a package. Do you communicate it back to them?
SPEAKER_02We have to communicate it back to them.
SPEAKER_01We communicate back to them.
SPEAKER_02So what have they need to change it? Or else we are going to use our own and and Figma and UI guys, they are always like they are always annoyed when they see that what they design is not what what they design is not what we build at the end of the day.
SPEAKER_01Of course, why would they be this? Why would they be annoyed?
SPEAKER_02Like what they are the ones that do what we cannot do now.
SPEAKER_01Ah God, okay, so but there have been instances where irrespective of whatever that has been given to you, you just have to build it exactly as it is. Oh yes, and have you have you been able to like there was no uh there was no back and forth the icons, the filters?
SPEAKER_02The filter, there is one I think there is a work I did recently. The guy, the guy is a is the product manager and also a UI US. So it's like his design should be exactly as it is, and I tell you this one that I'm seeing here. Please go and change it because sometimes um font size, the way the font size looks on Figma, yeah. I think I've noticed always different from the way it looks on and some they don't they don't know that like the job I uh I said uh the recently I was doing the man did not understand that it's not the same. It's like why is this font? I said he's checking, he always inspects and check the size and everything. I would like because you can't compare the size. If I put the size there, you will see that you two you'll be like, what is this at the 24 pieces of there? If I use 24 that you use on Figma, it will be bigger than the one it that you use on Figma at the end of the day. So it's I I will reduce it to 22 to match that font.
SPEAKER_01So design
Design systems are meant to make life easier. Do they actually help you, or get in the way?
SPEAKER_01systems do they actually help you? No design systems like generally. Um, I think I've seen it in one or two UIUX um designs where they get the uh font, the color, everything, like designing a full system about the whole package, about sorry, about the whole um, should I say the whole job, the whole project? So having like a design system on ground that okay, this is the font you are supposed to use. This is the um color code you're supposed to use. Whenever success comes in, this is how the shade of green is supposed to be. Do they help you or do they get in the way sometimes?
SPEAKER_02Though um it helps a lot, though it sometimes gets in the way because we want we always want to use red. Most of the time we want to use package, but it's it makes the the the the um website a bit beautiful when we use what they be.
SPEAKER_01Yeah, for me, I feel like definitely for me personally, I feel like having a design system in place actually helps. Yes, I've not I've not done a lot of UI or a lot of front end, but from what I can see, you know, when you have a design system on the ground, you don't need to bother yourself thinking what color should we use here, what color should we use? You only declare it already. Even if you are if even if you are going to use an external package, I know packages now allow you to custom, yes, customize the color, like if we like the alerts now, sweet alert, for example, it allows you to customize the green, allows you to customize the red, the orange, and the like.
SPEAKER_02So it's it's really helps because one, uh once a design system is available, definitely we too, we are starting, it's just as the design system for them a component for us. We build everything. As they build it, we build everything as a component: the model, the table, the buttons, and everything. We build it. So it will be very easy for us too when we are trying to when we want to build the old system. It's just we all scall it and then we start using it.
SPEAKER_01Now, one
When the design and what's easy to build don't match, who gets the final say?
SPEAKER_01question now. It's still based on everything that we've said so far. Okay, we have a project on ground. Okay, the UIX is done. The time frame is there. It's not like you can't do it, you can't finish it up within the time frame. But if you like, let's just take for example the chart. For example, now you feel like the time taken for me to integrate this package is lesser than using this one, you know, and um the work, the amount of work that I will put in this one is lesser, is lesser than this one. So when the design and what is easy to build, when they don't match, who gets the final C now? Don't forget, it's not like you can't build it. Yes, of course, within the time frame, you can you you can see it, but because it's not easy.
SPEAKER_02I have to call the I have to call the UI. But who gets the final C is the front end that will get the final C because one? I asked with we have time limits. This design, please go back, just look for something very no, it should be it should be what we expect, but try to make it more easier.
SPEAKER_01So at the end of the day, okay. So that means you give him the things that you feel like makes it easier for you to do that. Exactly.
SPEAKER_02We are once a designer now. Before Figma was introduced, before they we are also we do it, so definitely okay.
SPEAKER_01So, in other words, for you, you feel like front end gets the finances, you have the financing, you have the finances, so front end always has the finances, always have the finances. Well, what will make your whole life easier, even though this person he has already done like three that will make his he has already done like three revisions from the product manager.
SPEAKER_02Now you are coming at your last time anyway, and also for his own work for people to see if if we don't build it, it will it will just be there as design. You might put it on Pinterest or for being as whatever, but at least someone will still at the end of the day build it.
SPEAKER_01Okay, so um, you know, there was a thank you. That's the settled. I know people people will have opinions about that, definitely. People will have opinions about who gets the final say, but we would open a poll, we would open up a poll for that final. We will open up a poll for that, ask it who has the final say, it's just like I refuse to comment on that. I'm not taking any site, but I refuse to comment on that. I'm not taking any site. Okay, so now there was a
There's a new frontend tool every few months — React, Vue, Svelte, and on and on. Is that tiring, or a good thing?
SPEAKER_01certain period now that we had a lot of tools coming up, a lot of frameworks. Then ViewJS, React, it was like they were just bombarding us that particular year. We were just there was always a new tool, Angular 1, Angular 2, Angular, Angular 2. Maybe I think Angular 8 or 9, or I don't even, maybe 10 self now. But I think I stopped on Angular 3. I stopped, I stopped following, I think I stopped following Angular at Angular 3. Then it was that period that React came, viewjs came. There is just a whole lot of UI.
SPEAKER_02Everything, everything is still based on JavaScript. Is people that doesn't are on the are they all the same or is there subtle differences between two? All the same, but they designed it separately. Just as we have CSS framework that they design separate, like Tailwind designed their own, they design they declare their classes as they want. Same as how um what's it called? Um Bootstrap use their classes as they want. Uh materialize use their own classes as they want. It's the same, same goes for the front-end package, um, the JavaScript packages too. Everything is still on JavaScript OOP. Object-oriented JavaScript. It's people that understand the JavaScript OOP that would know that all these things are still the same. If you if you um if so if we can look deep into it very well, is the combination of different packages that forms those um that forms the old framework itself. Okay, though they've they have their own um OOP written too, but there are other packages that are being you um you notice that when we installed, there are a lot of packages that will be installed with it. So they've they've um they've considered other packages too. No, it's not just their they are not the one that builds the whole React space thing. So there are some packages that are being imported to your yes. So the the thing is that they just look at that instead of we writing it ourselves or trying to bring in different packages like um um validation package, this and that. So they've all they call they've put everything in a hole that we can just call at any time, okay. For example, um React 2 has different versions, but people did not understand, did not realize that they have different versions too. React initially, React was um was modal um was um class based, but now it's now a function based. Same goes for View.js, it was option API, now composition API when TypeScript was introduced. Yeah, so and React is just the is the is the is the re-engineering of Angular. Yes, it's the re-engineering of Angular. Okay, because Angular consider a lot of things that is not supposed to be like on Angular, if you want to create a page, you have the CSS, you need to you have the CSS for that page too. But on React, they makes everything seamless. Just one CSS uh just CSS one CSS file, or you just import one Tailwind CSS, even on it's just one CSS file, safe, even though you want to use Tailwind, just import the Tailwind in that same CSS.
SPEAKER_01So, um guys, do you agree with this that React is actually the the engineering of um Angular? I will have a poll in the um in the YouTube video, I'll have a poll. So please let me know your thoughts in the comments. Um, so let's moving on. Now,
How do you know when a screen is actually finished/completed?
SPEAKER_01when you're giving a screen to design like to build out the UI UX guys have already done it and they give you the screen, how do you know you have you've completed it?
SPEAKER_02One, um, there is always um for the UI guys, they there's always what we uh we call prototyping. And I don't think most of them prototype, they just give design. Some of you don't even understand prototype, they they don't even know that there is prototyping. But if they prototype it, definitely you test from the UI side by using their own prototype and also test from our side.
SPEAKER_01So, should I say, like, if if you are like should I put like 80%? Because you've already you already mentioned it that the charts and the icons might be something there. So if you are like 80%, at least what they have there, if you are like 90% done with it, like okay, what I have, what they have is like 90% um similar or 90%.
SPEAKER_02Something like 90% similar. What I order is different from what I did. It must be 100% much, it must be 100% much, but you just mentioned it yourself. Uh no, no. Now I said it's easy now. We know how to to overcome that. We've we've we've been able to overcome that icon aspect. Oh, and okay, and the chat we've i we've communicated already, so they've changed it.
SPEAKER_01Okay, so you oh oh, so it's not like you will go ahead and no no no now.
SPEAKER_02They have to change it, they have to change it because build it the the the project owner. We always check, they always they always trust the figma that the front end because it's not the first of us, yeah. Because they that that's their force. So when they open the figma and see that it's different, definitely something is going on, it's going wrong somewhere.
SPEAKER_01Okay, then um most
Do you think UI/UX don't understand the amount of work you're to do to implement their designs?
SPEAKER_01times when designers develop anything, do you feel like they don't understand the amount of work that you are going to put in?
SPEAKER_02They don't understand, they don't they think it's like drag and drop that they are doing. Do you think it's just drag and drop that they are doing? No, it's not drag and drop, but I would say it's still drag and drop because they already have everything in place, they have their tools there that they can just drag and also just like rectangle is a is a tool now, they will drag it's still the same drag and drop now, so it's still drag and drop.
SPEAKER_01UIX is just drag and drop. Two of us, let me know in the comments. All right, so um have you when you see a website, you have a website, you see it. How
How do you tell if a frontend and/or design is complicated?
SPEAKER_01do you tell if the website is complicated or easy to use? Of course, when you just see something first, I need to check the load time.
SPEAKER_02Load time, okay.
SPEAKER_01That's interesting, and also um sorry, before we go on, what is uh a an an accepted load time for you?
SPEAKER_02To me, it shouldn't be more than um um, I think five five, maybe I think that should be maybe five uh should be more than five hundred and fifty uh milliseconds or something like that.
SPEAKER_01Okay, five fifty milliseconds or shouldn't be more than that.
SPEAKER_02So that's like 0.00 because one image must not be on that file, it must be on it, must be uploaded to DN. Oh, okay. So that's not part of the load. Oh, okay. Okay, the site will have loaded already before those ones start loading. So those ones are background loading.
SPEAKER_01Okay, okay, okay, okay. So like 550 milliseconds. All right, then what else do you you check? What else do you look at?
SPEAKER_02Um mostly and also you need to check the console as a front end. But most people don't check the errors.
SPEAKER_01Most people don't check the console now.
SPEAKER_02That's that's no that's for me, the front end as a front-end developer. You need to check it. You need to check the warning, you need to check the error itself.
SPEAKER_01But there are some times that the errors might not actually be from the site. No, let us take for people who use third parties, grips, yeah, um, for charts, pendo for tracking, Google and Google Analytics.
SPEAKER_02Mostly those ones can only be those ones will be seen on network, not really the console itself.
SPEAKER_01Some of them actually show they show in the console. Okay, I think it's in dev mode that they show in console.
SPEAKER_02That is true in console. Okay, so and also front end should be you should take note of console log. They always they should always clear every console log. Me too, I do that. I don't clear it sometimes, and later for yeah, yeah, yeah. We actually use it for debugging. It's something that is very important. Okay, that's what I need to check. Yeah, so what I mean for the UI part, yes, mostly if a if a front end is complicated, and uh I will blame the UI guys, like the the low time because it's they are the one that caused it.
SPEAKER_01Yeah, so um what I'm trying to understand now is when you say a website is complicated, is it like too much image, too much text, too much of animation, too much okay, too much animations.
SPEAKER_02But what if it is like uh a video site or something, you know, like a should I say a site for like Pixar or a site for like uh OneA Bros, you know, this cartoon something, and then we'll know that that's cartoon something we should know that if it is cartoon, we know that it's for cartoon, but if it is for something else, let us know that it is for something else. If it is real business, okay.
SPEAKER_01So, what is the like acceptable? Let us take a tech company for example. Let us take a tech company for example. What is the acceptable number of animations that you would expect on a tech company?
SPEAKER_02The the the the the highest I can see is using maybe wild yes to either animate in or something like that. Anything aside that I don't expect, I'm not expecting the board to be rolling on screen for a tech company. What are they saying?
SPEAKER_01So the what of if it's like an hospital, and then we now have syringe stethoscope rolling syringe rolling.
SPEAKER_02If you want to see syringe rolling, then definitely go to the hospital or look for no no okay. These are another thing they can use, they can use uh uh uh what is it called a g file. Okay, instead of coding it, they do just get a g file. That is even more that they will still see their animation that is this syringe will be going in and go coming out.
SPEAKER_01Okay, so like when there's too much animation on the screen, yeah. Of course, I I I actually concord with you, I agree with you. You know, we should know what a website is for. If it's a kid's website, of course, I would expect much more animation than an adult, um, what's it called? An adult um website, you know, like a an hospital or whatever. That if it's a if if if it's for a video company, maybe like um a should I say ground video, like a movie making company, or you know, like Sony, and yes, we should know that your kids definitely definitely see videos in there, we'll definitely see some a lot of animations and on the ones they they have they know that they are the the server that they are running on is will be very we of course of course of course we can't expect someone that is using cpanel to be having that kind of still use c panel, yes.
SPEAKER_02People still use it, definitely. Mostly PHP people still then done, not JavaScript. So let us it's not meant for JavaScript, guys. I think it's mostly meant for PHP, CPAN is mostly for PHP for WordPress and WordPress and the like, so it's not meant for you can uh c Panel cannot you can learn from React on C Panel.
SPEAKER_01I think C Panel should I say they are mostly fading out now. Most people prefer to use their own virtual price for it, and I I've seen like it's now so easy to like get a VPS, set it up, and then have like multiple websites on it. All right, so um
AI can write frontend code now. What does that mean for frontend developers?
SPEAKER_01now let's talk about AI. There's a lot of AI coding going out there. You know, I've actually gone into agentic uh coding, agentic AI, and I can tell you that this thing is so powerful that if care is not taken, you can outsource everything that you are doing to this day to this state, like it is so powerful, especially in the coding aspect. It is so powerful with prompting, of course, you can definitely go rubbish with it, you can definitely do a lot of nonsense. I've seen a lot of nonsense. That's why I'm always like, this person, does this person not have a foundation in uh this aspect? Like, why will you do this sort of uh nonsense? But the fact is when you can like develop agents, have them work the same way you would work, like having a full development team working the same way you would work. A UIUX, QA, security reviewer, the mobile designer, the back end, the front end. What do you think about AI AI AI for front end now?
SPEAKER_02AI for front end is a very good um is a tool. AI is a tool for a person like me. It's not something that can because we still write our code. Yeah, of course, definitely, but it helps a lot. There are there are certain things that are they're like there are some standard thing, some standard way of writing code that AI can help. For example, if I write a code now and I can just ask the AI, help me to analyze the code and give I won't ask I won't tell AI to override the code just to analyze and don't code it. I want to see the errors and other things. Then if I think I see that okay, this will definitely work for me. I would I would definitely ask AI to write it. So and for the testing part, it's always easy for us to test with AI.
SPEAKER_01I AI is doing testing test, but the fact is you also need to know what to prompt. Yeah, I actually definitely I ask you to test happy part edge cases. You know, if you don't understand what an happy part is, when it gives you an happy part test, you won't even know about it. What definitely that's getting you won't even know when you ask it to test for edge cases. If you don't know what edge cases mean, you won't know.
SPEAKER_02It's just like uh a uh there is there is one of my my boss. I did a project definitely with AI using AI. It was like, wow, since I can do this, definitely you can do it. It's just a blog he wants to build.
SPEAKER_01If you my god, if you don't know, if you don't know, even if you have the the best AI agents in this, you it will never give you the result.
SPEAKER_02So it's not you just you need to have the knowledge of that thing you are doing, even if you want AI to help you. Yes, but if you don't have the knowledge of what you are doing, what you want to do, definitely you'll get the wrong result from AI, and it's not AI's fault. And the thing is, it is the person's fault.
SPEAKER_01And and the and the thing is, especially in coding, you don't you don't just give it everything and just like hacks it. No, you have to do it. You have to structure your folders and you have to check meet it, you have to check everything that it's doing at any point in time, whatever it is writing, you also have to test it on your own end, and of course.
SPEAKER_02No, no, just add your own thing is done, yeah.
SPEAKER_01Because there's a lot of security issues that can prompt up from this little thing.
SPEAKER_02I think I encountered some ad security issue. I didn't check, but thank god that before I uh the day I wanted to deploy the app, I tested.
SPEAKER_01So you found the security bug.
SPEAKER_02Wow, I see a link.
SPEAKER_01It's actually it's actually very, very easy to get carried away and just have it do. No, it's very fun when when it's working, it's very fun. Yeah, of course.
SPEAKER_02You'll be like, ah wow, instead of me wasting no job.
Outro
SPEAKER_01So thank you so much for coming on the show. I really appreciate you. Um can you tell us where I can find you on social media? What are your social media handles? LinkedIn.
SPEAKER_02LinkedIn, I'm on X. I'm not on Facebook, I don't use Facebook, but I'm on Facebook too. I'm mostly I'm not always active on Facebook, okay. I'm on X and LinkedIn. And also can I can be uh contacted through GitHub too.
SPEAKER_01Okay, so um, guys, you've heard it from him. I would link his um social media profiles below in the description of this video. So please do well to follow him, check him out, you know, add him up as friends, ask him questions, he will be happy to um respond. So we've come to the end of um this segment. Um, if you guys have any questions, please don't forget to comment, ask those questions, and we'll be sure to get right back to you. And also, as you're doing so, please don't forget to like, to subscribe, and to share this video to anyone who you feel might need it. I'm your host, Oluwale Majiyagbe, and um I'll see you in the next episode.
unknownBye.