Stack/Unstuck: The Fractious Front End

  |  Compiler Team  
Desarrollo y distribución de aplicaciones.

Compiler • • The Fractious Front End | Compiler: Stack/Unstuck

The Fractious Front End | Compiler: Stack/Unstuck

About the episode

Front-end development can be complex—and that means a front-end developer’s skills are essential, albeit constantly shifting. But a humble web search can produce various memes and jokes about how the front end isn’t as much of an endeavor as other parts of an application can be.

Expanding knowledge beyond one’s area of the software stack can strengthen the skills they have, but negative perceptions can become a barrier to building those necessary relationships. As communities and companies grow, though, attitudes can begin to change. How can front-end developers communicate their expertise to their peers, and learn new talents along the way?

Compiler team Red Hat original show

Suscribir

Subscribe here:

Listen on Apple Podcasts Listen on Spotify Subscribe via RSS Feed

Transcripción

Yeah, thank you for having me on the podcast. Yeah, my name is Adam Bergstein ... A few months ago, I was interviewing someone for Compiler. His name is Adam Bergstein, he's a Senior Director of Engineering for Acquia. We were talking about application development and how it's changed over time. I remember, even a few years ago, where there was a huge ... Well there was React and there was Angular and there was Vue.js And there was tons of the similar tools that you could use for front end development. And I think it was very hard to know exactly which one you needed. There are a lot of different choices, paths to take when you're building an applied. It can be really hard to choose which tool to use and which ones to trust. I think it could be really daunting, though, as you're looking at the broader spectrum of, hey, which tool do I want to use? And, wait, why did this new framework just come out that they're marketing themselves as solving this same exact problem that 50 other open source projects are already doing? Sound familiar? He's not lying. There's been a lot of debates. Couple years ago, it was all the rage. Angular versus React and which one's better. It was just nonsense, but yeah, there were so many tools and how do you make the right choice? Yeah. And talking about this, Adam said something to me that really stuck out. The front end communities are extraordinarily vibrant right now. And it's funny because, if you're watching the memes and you look at some of the jokes online, it's like, oh great, yet another framework that does this. And if you're trying to solve a specific problem, you might find 50 or 60 different tools, and then the next day, you might find another 10 more. The running joke I look at is, it's so vibrant and so wild west at the moment that innovation's happening so quickly and people seem to be solving the same problems repeatedly, and then they solve it in different ways based on the kind of framework that you're using, and it is just really interesting to see that. Now, I want to make something clear. Adam asked me to do this. He's not the expert on front end developers. He considers himself to be a full stack developer, but this discussion made me ask another question. What is going on in the front end? This is Compiler, an original podcast from Red Hat. I'm Brent Simoneaux. And I'm Angela Andrews. We're taking you on a journey through the software stack, we call this series Stack Unstuck. Today's episode, we take on the front end of the stack. This is one episode of a series so if you want to listen from the beginning, you can start on our episode called The Great Stack Debate. All right, now producer Kim Huang is here with our story. Brent, Angela, I have been combing the internet for memes lately. I do the same thing, often. I've been looking at a lot of memes, specifically about front end development. Why memes? Why not memes? Okay. I mean, memes tell you so much, a whole story in a tiny little image. So what are you learning? It's interesting because I think of any type of software developer as being a person who's very specialized, highly trained and experienced, but it seems like a lot of people think that the front end is just for show. It's the flash and not really the substance of an application. Oh, so there's this perception that it's more about aesthetics or making things pretty, more than anything else. Is that it? Yeah. And also that it's not a lot of a challenge to handle. It's not a lot of complexity there. And nothing could be further from the truth. Yes. That's exactly what I've found in my conversations that I've had for this episode. I wonder why it's like that? Why are we having this debate? That front end is all pomp and circumstance and it's just making it pretty. And then, it's not work, it's not challenging. Why is that happening? I think that people take a lot of, I don't know if solace is the right word, or a lot of shelter in complexity. It seems to validate people if their job is really hard or really difficult, they feel some sort of validation that they're ... It gives them a sense of importance. And they are important, it really is important to have those skills that we're talking about, but that doesn't mean you sell the other areas of responsibility short. That doesn't mean that you cast aversion on other people who work in other areas of a technology stack. Interesting. I think this really gets at something that's at the heart of what we're talking about today, which is, is the front end just for show? Is it as technically challenging as other forms of development? Or can it be a bridge to understanding development needs in general? Good question. So to start us off, I'm going to bring back somebody we've heard from before. This is Noel Minchow, he's from LogRocket. I spoke to him in The Great Stack Debate episode, the first episode of the series. Here, we talked about the attitudes around front end development and the attitudes that people that work in that sphere can face in their working lives. The more I think about it, the harder it is to define. I think my impulse is still, somebody who thinks about receiving data and displaying it and then maybe posting it back. They don't think about the way that that data is stored and fetched and retrieved as much. Again, I think increasingly that realm is becoming something that front end devs concern themselves with as we get into GraphQL and stuff like that. But I think that most people, when we're talking about front end devs, that's what they assume. It's like, hey, you spend most of your time writing React or Vue or Angular or something. Noel is saying that there's a lot of assumptions made about where front end developers spend their time and what they spend their time thinking about. The front end layer, as we've said before, is the thing that is closest to the user. It's the pretty and the shiny, it's the interface, and Noel says that because people have misconceptions about the difficulty and the sensitivity of that work, that's where a lot of these viewpoints come from. They're focusing on display and accessibility and making sure things are reactive and responsive and it's not exactly the same muscle that you're using to think about users interacting with the front end, be it mobile or web or whatever. And then how data is stored and the efficiency and stuff. And I think that there's always been this superiority complex that backend people have maintained. But I think that that is dying. I think people are realizing that the front end is hard too. I think it's just like, there's knowledge gaps. He nailed it. Yeah He nailed it. Superiority complex. It is. And I think it gets such a bad rap because think about every site or app that you've used. If you can't view it on your phone, if it's not responsive, if it isn't accessible, you're checking out. That is literally the window. That's the window into what your service is that you're trying to sell. Let the front end be bad, whatever you're doing on the back end won't even matter. Exactly the point. I agree completely. And I think that goes back to what Noel is saying about a different muscle being used. Front end developers just think of things a little bit differently. And it's a little strange to me that people have these attitudes in the first place. You could have an amazing backend setup, but if the front end experience is poor, it doesn't matter. People won't be able to use it. Yeah. I feel like Noel is trying to say these attitudes are slowly going away and people are realizing that the front end is a little bit more complex than they thought. If you're stepping into some giant, super mature code base that's got tons of moving pieces and data's going all throughout the system, and there's multiple storage areas that you're worried about, and the pipelines are complicated and it's just this big thing, of course that's intimidating. But that's also hard if you're a backend developer getting into this system trying to figure it out. But I think maybe the language, the way of thinking about problems, is maybe just a little bit different for front end devs. I can respect that. It's just different. Yeah, it's just different. Does that surprise you any or is this something that does not match your experience? I'm wondering. Well no, I just think the problems that the front end versus the back end are trying to solve are slightly different. Now of course they meet in the middle, they have to, but when you're focused on what your job is you think about it in one way. So I understand how, when we do a front end versus a back end, it's just a little bit different. I would say it's a little bit different for both ends, and we haven't even talked about the middle, but I digress. We have not. We're going to get there. We're going to get there. We'll get there. We'll get there, yep. I did find it really interesting what he was saying before, about it just being a different muscle. And so, for example, my leg muscles. They're going to be really good at helping me run long distances. My arm muscle is going to be really helpful at helping me lift something. And it's not that my leg muscles are more important than my arm muscles, it's just like what's needed for the particular job that I'm doing. That's right. Yeah. That's right. That's a good analogy. Perfect. Noel says a more collaborative approach to product design is needed. He thinks that's where software development is headed, because when there is a server error or a problem with the API, Application Programming Interface, the problem is usually first discovered where? In the front end, right? So the front end of an application isn't just like fields and buttons and devs. And developers working there aren't just doing things that are just for aesthetics, they are usually at the front line of where problems and challenges become evident. And those front end developers working there are the most knowledgeable about the impact of any changes that were to happen, whether it's a new feature coming out or an update or maintenance. Any type of change, they are going to be the ones that are most tuned to what effect it will have on users. They are the vanguard. That's right. Yeah. I think we're realizing that the way in which data is fetched is pivotal to how the front end itself needs to work. That is to say, I think that we're realizing that systems need to be designed more holistically, regardless of who is implementing. So I think that, at minimum, a lot of front end devs ... I think this has been the case for a long time, they have a knowledge of what the performance impact might be of certain ways that they're fetching data. They realize they don't want to write 1000 queries to fetch 1000 items from a list, I want to do this in one big query. People know this, it kind of seems intuitive. Is this what Noel was meaning when he was saying that software development is becoming more collaborative? Maybe collaborative's not the right word. I feel like he's thinking that developers need to look at things more holistically, not just look at their particular area and the effects there, but all of these other different systems and parts and things and how they all interact and connect. Maybe not a collaboration between people, but a collaboration between different components. That's a good way to put it. Does that make sense? Yeah, that does make sense. Yeah. There's a lot of moving parts in application development, so being aware of what the other parts are doing makes your job much more effective because now you have that knowledge, you have that understanding. So I think if we turned it around, the front end folks are much more aware of maybe what's happening in the middle or the back, but it can also go the other way where backend folks now have a better respect and understanding of the complexity of the front end role. So the front end and front end developers, it's all very important. The people that work on the front end of an application, or the front end of a tech stack, they need to know a lot of different things. We've established that. So how do they go about learning what they need to know? We're going to get into that next. I spoke with a Red Hatter who experienced a lot of these things firsthand. I'm Evan Stoner, I'm a Solutions Architect at Red Hat. I work in our public sector division. Angela, I feel like you know or you might know Evan. I do, actually. I just met him. And he is an amazing essay. Heart emoji. Evan started out as a software engineer, but even before that, he worked in research. Specifically research in cybersecurity for his alma mater. It was a very contained environment and his peers worked on a lot of what they call greenfield projects. I don't think I know what that means. What is a greenfield project? I understand greenfield to be, it's like a net new product. A net new service. It's not something that existed before, but they're doing something on the cutting edge of whatever. This is the first iteration of it, is that correct? Exactly. Yeah. I have a greenfield sticker on the bottom of my laptop with a little cute cow standing in a green field. So I think [inaudible 00:15:32]. What? Long story. I like stickers. Where did you get the sticker from? Oh, from a conference. Of course. Of course. So anyway, back to Evan. Well, speaking of conferences, he went to a conference actually, and he heard something there in a keynote that changed the way he thought about his work. I was fairly young, having a good time at this event, and then there are a lot of different sessions. And I remember one where it was maybe a keynote by one of the government sponsors and he said, "We don't just do research for the sake of doing research. There's somebody out there who needs technology in order to do their job better. So the things that we're building are not just science projects, there are things that, at some point, need to go out and be used by a person who's trying to do their job." And so that stuck with me, especially as we're doing so much of that greenfield, just kind of fun, technology research work. That those were not just projects that are going to live in isolation. That those need to be built at some point to go out and be used by someone. That's true. Yeah. That's an interesting way to think about it, though. Well, what do you mean by that? I mean, especially because he was in university and you think of that as being the place where you grow and you test and you experiment. And usually you don't think that it'll go any further than that. But we should probably change the way we think about that, because everything has a purpose and that research might be purposeful in someone's job in the future. So just because we don't have that in front of us right now, we should think of it as such. Not for just the sake of doing it and getting an A or something. It's really bigger than that. I think sometimes when we are in build mode, like when we're actively building something, it's easy to get lost. Whether we're actively thinking about it or not in the mindset of technology for technology's sake. And so, what I love about what he's saying there is that technology is there to help people do things. They need to live in the world. They need to make it outside of the lab. And they need to be used by people. Yeah, totally. And Evan says that sometimes thinking about the details, the really small things, can have a huge impact as well. To be fair too, you can be really granular on the technology. Say you're a staff engineer working on database performance and you're reducing some query time from three milliseconds to half a millisecond. Maybe in the grand scheme of things that doesn't really seem like it's a big difference, but if you can quantify that to some sort of monetary savings for your organization. Or you can talk about a certain segment of users that that's going to be valuable for. You can be in the weeds on the technology, as long as that's still having an impact on some measurable customer or user or bottom line or whatever matters to your organization, that's really the measure of success that project's going to have. Not how many new tools and technologies and frameworks we added, but what is the effect it's going to have on a real person trying to do their job? Yeah. It seems like what he's saying is it needs to be some kind of balance. You can be very granular. You can be focused on the technology. But at the end, I think that that realization of, someone has to use this. It needs to be at the forefront of everything that you're doing. This gets back to something you were saying earlier, Kim, which was the proliferation of frameworks and tools. I'm curious, how do you learn what you need to know in all of this? This is where things get interesting. Okay. So Evan says that branching outwards from whatever area you're working in is key to learning what you need to know about development. He talks about his own methods of doing that for himself in his own career. I think it starts with asking questions about the periphery of where you're at. So for me, the beginning of my work was developing software that was getting deployed out to a server. It was actually on a virtual machine. And so the next step of that was, well, how does this virtual machine get deployed? And where is the physical server that it's deployed onto? And how does all that work? And from there, it was like, okay, well, how does that physical server get racked and stacked? How does it get networked into a switch? How does the power redundancy work? How do I configure VLANs on the switch? And so you can see how it just spider webs out as you start to ask questions. And you can stop wherever you feel comfortable or whether you think you have something valuable to add. Okay, let me stop right here because I have never heard a developer say these exact words. Well, yes, they want to know where it's getting deployed. That makes perfect sense. But now he went down to the bits and the bites and where it is and it's being racked. And what switch is it in? And where is the ... Okay, as being a systems administrator, I ain't never heard a developer ... They don't even care about that stuff. The question is, is that the energy that you want to have or is that the energy that you don't want to have? I'm curious. You know what, I wish that was that energy that more folks had. Where they were that curious to find out, how does it all work? Not just your little sphere of what you're doing, but how does it all work? I really wish that this is what most folks thought. And I'm not talking about just developers. I'm talking about wherever you are in this stack or in your role, you should want to be curious and figure out and find out how it actually works. You should want that because that'll give you such a better understanding when you're troubleshooting, where the problem lies. This is- Yeah. Go ahead, Evan. Preach. What he said was very poignant and I hope this point gets driven home, because that's that curiosity that we talked about in so many other episodes. You want to know how it all works and how it all works together. Well, what's interesting is that, he's coming at this also from a sense of place. Or almost like a home base in some way. So he started by saying, asking questions about the periphery of where you're at. So he's starting in one place and then slowly moving outward. Slowly moving outward from one area of the stack to other areas, to figure out how they intersect, how they interact, how they connect. It makes you a stronger tech professional. I agree. That's what it does to me. I agree. And you don't need to learn everything. You don't need to become full stack to have that kind of understanding. That's not a prerequisite. You don't have to have an awareness of everything. But ... If you keep asking questions and just looking at, what's just over the horizon of your current comfort zone, that's where you can start to pick up those other skills and then have that, what I think is extremely valuable information, about how everything else connects together. I want to put a pin where he said skills and talk about that later. But ... Pinned. Yes. His point, though, is still very salient. That behavior creates more, then, opportunities for a person to learn. It's building a good work environment for everyone. If you walk up to someone and they work on databases, and people just don't bother asking them about how everything works, and you approach them with a spirit of curiosity and you really ask that person, "Well, how does this work?" It shows that you're interested in what they're doing and it shows that you're invested in what they do. And everyone, it doesn't matter where you work, everyone benefits from curiosity about what they do. Yep. Yep. And generally, people respond to that really positively. Because the worst thing in IT, or computing or whatever you want to call it, is for someone to throw something over the fence to you and say, "Good luck." When someone starts to take an interest in your job and your role in the big puzzle that is IT, that can bring people a lot of confidence and make them really interested in talking to you. Because it shows that you care about their job and their contribution and that can be a really valuable relationship. He is so right about that. You want to be able to show your colleagues and the folks that you're working with that what they do matters. So you ask those questions. And people love talking about their work, especially if they're really passionate about it. And to see that another person is showing interest? You've just really built ... You've strengthened your working relationship to another level of respect, because that's what we all really want, though. Yes. Yep. So Kim, Angela, there are two things that we started this episode with. So one is, in the front end, this proliferation of tools and frameworks. So we're going to talk about that. And then the second thing is the perception of front end developers and what is involved in front end development. I'm going to hold both of you to answering pretty directly on this. So that first one, this proliferation of tools and frameworks, what do we do with this? This is the world we're living in. It is. What do we do? I mean, what can you do? You find it's less about the tools, more about the problem you're trying to solve. So, because there are so many tools, pick one that does exactly what you need it to do. And if it is an open source tool, then maybe if it doesn't do exactly, then you can add the functionality you need. So in the world we live in, if it doesn't work how you want it to, you can make it work better. But I think that's the first thing. We really need to stop thinking in terms of, this tool this, X. Or that framework, Y. We really need to think of, well, what problem are we trying to solve? And then focus on that. And then trust me, I think the tool will start to reveal itself and you're going to find just what you need. So if someone came to you and asked you, "I'm trying to become a front end developer, what should I learn first?" It's always the basics. Yeah? It's always the basics. You're never starting with a framework. And then when someone says, "Well, what should I use?" Well, what do you have on hand? It's always the small parts. You learn the basics and then the frameworks are almost like, they help make your job easier. And how about this second theme of this episode, which was the perception of front end developers or front end development. Kim, as you were talking to people, what came from those conversations? Definitely that the front end isn't just for show. It's not just pretty, it's not lacking in complexity, it's a very complex area of the tech stack. And the people that work there, they need to know a lot of different things. Including some of the things that are on the back end. They need to have a holistic understanding of how things work in app development. And front end developers can be the first to identify challenges and opportunities in developing an application as well. And whether you work on the front end or somewhere else in the stack, you shouldn't feel any shame or any type of imposter syndrome. You should strive instead to learn and to broaden your horizons and broaden your skillset. Indeed. And build relationships with other people in the stack. That way, you can make your working life and your work environments more collaborative, more friendly, more open, more good to be in. And on top of that, you can also see what else is out there. Maybe you won't be a front end developer all your life. That's true. How about that? Maybe you want to move on to something else. Remember I said that pin earlier, here's the pin, I'm taking the pin out. You can use these opportunities to learn and also figure out where to map your career journey as well. So we discussed front end development and the front end of the tech stack in this episode. And we did tease a little bit about frameworks. Well, next episode, we are going to tackle frameworks more directly. All right now. Well, this was such a fun episode and I'm so glad you were on this ride with us. We want to hear from you, share your thoughts with us on what you thought about the episode. Also, send us your favorite framework memes, I know you've seen them out there on the internet. Definitely tweet at us @RedHat, hit us up on Instagram @RedHat, but everywhere use the hashtag Compiler Podcast. We want to hear what you thought about the episode and we want to see your framework memes. Show us what you got. And that does it for this episode of Compiler, Stack Unstuck. Today's episode was produced by Kim Huang and Caroline Craighead. Victoria Lawton is our greenfield expert, as long as the field is near the beach. Who wrote that? Our audio engineer is Christian Proham. Special thanks to Sean Cole. Our theme song was composed by Mary Ancheta. A very big thank you to our guests, Adam Bergstein, Noel Minchow, and Evan Stoner. Our audio team includes Leigh Day, Laura Barnes, Stephanie Wonderlick, Mike Esser, Nick Burns, Aaron Williamson, Karen King, Boo Boo Howse, Rachel Ertel, Mike Compton, Ocean Matthews, Alex Trebulsey, and Laura Walters. If you like today's episode, please follow the show. You can rate us, leave us a review, share it with someone you know. It really does help us out. Thank you so much for listening everybody. We'll talk to you soon. All right.

More about application development and delivery

Development and delivery involves creating, testing, and deploying software applications, speaking to the entire product lifecycle. 

Publicaciones en el blog

Friday Five — August 15, 2025 | Red Hat

15 de agosto de 2025  |  Red Hat Corporate Communications

...

Publicaciones en el blog

Developing a standard AI OS: Unlocking production-grade AI at enterprise scale

14 de agosto de 2025  |  Brian Stevens

...

AI inference

Programas originales

At Your Serverless | Command Line Heroes

Desarrollo y distribución de aplicaciones.
Historia de la tecnología

Programas originales

Hello, World | Command Line Heroes

Desarrollo y distribución de aplicaciones.
Historia de la tecnología

Programas originales

Steve Wozniak | Command Line Heroes

Historia de la tecnología

Sobre el podcast

Compiler

Do you want to stay on top of tech, but find you’re short on time? Compiler presents perspectives, topics, and insights from the industry—free from jargon and judgment. We want to discover where technology is headed beyond the headlines, and create a place for new IT professionals to learn, grow, and thrive. If you are enjoying the show, let us know, and use #CompilerPodcast to share our episodes.