Full-Stack Web Design: Origins, Evolution, and Outlook

Transcript

Brian Skinn [00:00:04] Hello everyone, and welcome to today’s Open Teams community event. Open Teams gives you access to the best open source architects in the world to help you train, support and deliver your software solutions. I’m Brian Skinn, Community Manager at Open Teams, and I’ll be your host for today. 

Today we are joined by Colby M. White, Staff Software Engineer at Fractal for an Open Source Architect Spotlight event entitled “Full-Stack Web Design: Origins, Evolution and Outlook.”. As the title implies, today’s conversation with Colby is going to explore full-stack web design. What is it? Where did it come from? Where is it now? What advantages does it provide and what might be in store for it in the future? We are open for audience questions. Please post any you might have in the chat and then we’ll work them in as we can. 

Colby, welcome to you. How are you today? 

Colby White [00:00:50] Doing well! How about yourself? 

Brian Skinn [00:00:52] Doing all right. So, full-stack. That’s where we’re headed. But let’s start a little earlier. What’s your background? How did you get into software and development? 

Colby White [00:01:04] I think my first role was, you know, during college internship style. Classic archetype there when I was doing that at a startup. So, as you kind of aware, when you have a startup you get to wear multiple hats, right. So, we didn’t have a CI/CD system, or any kind of operation, or anything like that. So, it was a matter of ‘let’s just figure it out’. So, me being a young, naive engineer, I just put that hat on and let’s go. And, you know, I got hired to do some Java stuff, typical backend stuff. 

But now I’m doing DevOps, I’m helping in the UI, the whole shebang, right. So, this is before I would even realize there was a front end/back end divide. I think I just kind of naively have always been doing all the things and not even asking questions about it until later when I realized, “Oh, some of the people on the back end don’t necessarily even want to come over here on the front end”. And I think I’ve been a little bit full-stack minded since day one, for better or for worse. I would argue for better, but maybe others would argue differently. But yeah, so that’s kind of how I got started on this topic. 

Brian Skinn [00:02:16] Interesting. Yeah. Would you say in your experience that more people, more Devs than not tend to think in that front end/back end dichotomy? 

Colby White [00:02:27] Yeah, definitely, for sure. I mean, some of it is a little self-referential. Maybe that might not be the right word, but that’s what our job titles are. So, this reinforces then and now why did that job title say that, because, you know, engineers have already started thinking about that in a chicken and egg kind of thing there. But, you know, fast forward 30-40 years it’s pretty ingrained that there’s this front end/back end divide. 

Brian Skinn [00:02:54] So, I guess of the various languages you’ve worked in – just to set a bit more perspective – what’s been your favorite to work in over time? Kind of like, the Stack Issues survey most loved, most hated, and most excited to learn that sort of thing. 

Colby White [00:03:10] Yeah, I think over the last five or six years, the JavaScript/TypeScript ecosystem has made some pretty advanced data. That’s been my number one for a while now. As I mentioned earlier I kind of started out with Java, but just my personality type, it wasn’t too long before I started learning Python, for the sake of learning Python. And I started using that in some production things, and it went from there.

I remember, I got dazzled by Rails [laughing], so that was like a nine month honeymoon of being obsessed with Rails. What else have I done… I’ve done some Clojure. I think Clojure was when I really kind of discovered functional programming and went down that road. Elm is another one. Well, I guess that is a very heavy JavaScript, it compiles now in JavaScript. So, yeah, my personality type is  just kind of like I want to learn new things. But like I said, over the last five years, I’ve really kind of settled on a JavaScript/TypeScript ecosystem. 

Brian Skinn [00:04:16] Excellent. Yeah, the JavaScript I haven’t been doing recently, but I’ve been heavy on TypeScript. And as we’ve been putting the IDE integration and you know, all the aspects of it, I was like, “I understand the value here and really appreciate it”. 

Colby White [00:04:30] Yeah. Once you put some types in there, it kind of unlocks your capability there. 

Brian Skinn [00:04:36] Yeah. Facilitating really large-scale architecture, because there are lots of things that takes care for you. 

All right… So, artificial divide, front end versus back end. You know, it makes sense, that you are coming in not knowing from the outset, “Oh, there are these two different things” and having to discover it. Tell us more about that and, I guess, that’s kind of foreshadowing the conversation to come, where a convergence on to full-stack frameworks as a single entity. Just talk some more about that front end/back end dichotomy, and what full-stack is and work into the advantages that you get when you go to full-stack. 

Colby White [00:05:25] Yeah. So, you know, I think some history is useful here. I’m not going to claim to be a historian, but based on my understanding, I think there’s that story about JavaScript being created in like ten days, right? 

So, very quick, POC is out the door and now it’s going out there. I think there was some reaction to that, “How can you do that in ten days?” or “That can’t be a real programming language.” I think some of the response to that was that. But also, I do think there are some people, particularly in those early days who were technical, you know, I don’t want to call it bees, but critiques, some valid technical critiques around the programming language of JavaScript. So, there’s a little bit of suspicion in those early days of, “What is this?”… yada, yada, yada. 

But fast forward to today, I think the key thing for me to understand, and maybe it goes back to that startup mindset of wearing multiple hats… Nine times out of ten, I’m working at a company and we deliver our product through the browser. [laughing] And it is what it is, right? Like that or we’re doing SAS probably, that’s one of the dominant business models in our industry now. So, there’s a browser, and if you’re going to deliver your product through the browser, use JavaScript. So, once you have that, regardless of your opinions of the language, regardless of the history, you schedule or throw at it, you’re going to have to deal with it. 

So, in a way, I talked about some of the recent developments, and one of those is TypeScript. For me that really has some kind of title, and I’m this kind of guy that has really unlocked me. But since day one, I’ve been understanding I’m going to have to use this. Because for me, and, I think it’s important for everyone to state this explicitly. I think we all have it implicitly in our head, but to state it explicitly is important. We don’t get paid if our for loops are beautiful; we get paid if we deliver customer value, our customers don’t care about for loops or unsigned integers and all, you know, all that good stuff, right? We get interested in that, understandably. We all got a little nerd in us, right? So it’s easy for us to get nerds typed, as they say. But we got to stay eyes on the price and eyes on the price is customer value. And I can’t deliver customer value without the browser, which means I can’t deliver customer value without JavaScript. So I’m going to interact with it, right? 

Brian Skinn [00:07:59] Excuse me to intersect. And, especially, if we think with such things like electron apps, and progressive web apps, the range of applicability of where you can deliver something using a browser is only expanding. 

Colby White [00:08:10] That’s a great point because, you know, that’s one of the things – evolution, so to speak, in the last how many years is… the thought of doing some of this stuff in a browser probably would do our minds in the mid-nineties, right? [laughing] When those all very old-school blinking things on the website that wasn’t really feasible in that time. 

But the evolution has grown and we talked about PWAs. I’m a big fan of the PWAs and particularly from a business standpoint because I think there’s a lot of companies who think they need a mobile app, but if they really sat down and looked at what PWAs can accomplish in 2023, they would think “Wait a second, maybe I don’t. I thought I needed that because I needed access, but there’s a way PWAs do that too”. 

Brian Skinn [00:09:00] Why build three projects instead of one? 

Colby White [00:09:02] Exactly. Yeah. So, those evolutions for me not only are like a book-crunching thing, like, “Oh, I got to use, I gotta use JavaScript”, but now it’s like, “Wait a second, this all is a fine ecosystem, it is a powerful ecosystem. There are a lot of things I can do”. So, yeah it’s been an interesting harbor for me of 5-10 years in the JavaScript ecosystem. 

Brian Skinn [00:09:30] Yeah. So, JavaScript, I think it’s fair to say, it’s here to stay. You know, barring some long term evolution, which I don’t see any signs of it yet. But then, you know, the original web was CSS HTML on the front end, CGI scripts on the back end – very much not a unified framework. So, kind of trace quickly from the technologies from the good old days of the Internet to what we have today. 

Colby White [00:10:02] Yeah. So I think that’s a great way to start it, right? HTML CSS, maybe a little bit of JavaScript and most of your logic like PHP, JSP, ASP, pick your acronym of choice. And you’re kind of interacting that way. And what ends up happening, is, I kind of call it ‘A fairly artificial divide’. 

But I can understand why people would look at that and see the divide, because it feels like two different skill sets. HTML, you know, I kind of make fun of people who are like, “Hey, JavaScript is not a real programming language”. I’m going to be a little guilty here, HTML, you know, is not a programming language, it is a markup language, that’s what ML stands for. So, it’s just fundamentally different than something like PHP or something, right? So, it feels different, first and foremost. Over here I’m doing PHP – one of the main things I’m doing is I’m dealing with SQL queries and dealing with the database. That feels astronomically different from what’s going on on the front end. So it makes sense to me why we start to get this little separation. 

But fast forward over time, and, I think in many ways that node was a big IML on this timeline, so to speak. And if we were kind of loosely fast forward through the history, I think that node is a pretty big thing there. Because now what’s going on over here, on the back end, doesn’t feel as different anymore, because A) same language, first of all, but then B) it’s like now I’m starting to do the same things and it’s in the language. Also around that same time, the way we were building websites became a little different. It wasn’t just HTML CSS with a little JavaScript sprinkled on top. It is heavily JavaScript. It’s like we’re building, particularly, the SPA movement, the single-page app movement. You can’t even render the page without JavaScript, it’s not progressive enhancement, it’s required. 

So, you start to slowly get into this world where the skill sets are starting to converge. You know, not only the languages converge, because most people are using JavaScript in the back end, but the skill sets are converging because even on the front end, in a classical front end, in a SPA front end I’m doing a lot of the same things. What’s a common thing you do on the back end? – state management. Well, I gotta do it here – state management. You start to get this overlap. I got to do APIs; that sounds like a back end thing, but I’m doing that from my SPA. I’m mutating data; sounds like a back end thing, but I’m doing that in my SPA. So it’s like slowly but surely I get to this SPA where they’re converging. 

I think I’m just going to go ahead and kind of shut out to Chris Coyier. He’s done a lot of great work in writing. He’s got this great talk called ‘Ooooops I guess we’re full-stack developers now’. And it kind of outlines how it was slow. I don’t think it was like a magical big bomb dropped and now all of a sudden these are the same things. It’s a very slow thing. You start to get these frameworks that start to grow and have more capabilities. Like, you can enroute into them and that sounds like a back end, but now we’re doing it out of the front end. You start to slowly get this iteration. 

I think one of the cool things to call out is the components. Once we all started kind of realizing that using components was the right answer to build our front ends. That certainly sounds like the front end. But when you think about it for a second, zoom it out… that’s the DRY of principles, right? You’ve been doing that in the back end for years; now, it’s like a very similar sentiment. I’ve definitely had this in my past. 

I’ve got someone on my team who laid down the script they didn’t want to look at. I pulled them over. I’m like, “Hey, you have to organize these components, then you will see it, like flip, aha I’m done”. It’s the same thing. You see what I’m saying? 

So, yeah, it’s like a slow convergence, and then I think to get back to the what has been going on in the last 5-10 years, I think the emergence of these full-stack frameworks – I really think they are a consequence of that – they’re starting to see all that, noticed, be growing, to have the capabilities are growing and then they end up in a SPA where now we can build a full-stack framework and now it’s like official framework. It’s not like, I do this thing, I chuck it over to the back end guy, and he chucks it back over to me, blah, blah, blah. We can all do this in the same framework, in the same language. When you start to look at, like I said, it’s slow, but when you zoom out and think about it, it all kind of makes sense. I’ve never really seen it in this way.

Brian Skinn [00:14:43] The natural evolution of the technologies in a direction that makes sense with the functional and design constraints of the applications and the needs. Excellent. 

So, the web is not my background. So, I am coming in a bit from the outside here. I could rattle off a list. I know node on the back end for JavaScript, and I could rattle off Angular, and Vue, and React, and all sorts of front end frameworks. Can you dig it, partly in some sense just to help me understand? Can you dig a bit more deeply into… when we were discussing prior to the conversation you mentioned Remix and Next Touch js as examples of true full-stack frameworks. Can you expand about what it is that makes, for example, Next different from an app where you have a node back end and a React front end? What’s different about working with it? How does it work differently? 

Colby White [00:15:42] Yeah, I think it’s a great question. So, the way I think about that – front end framework, if its main goals are to help you to crank out components and maybe route to a page componer or something, and then that’s it, I would classify that as on this side of the divide, so to speak, it’s concerned about front end only data and all that good stuff you’re working around to figure out. And usually we’re all going to kind of follow a pattern or use a fetch request to an API, and that API is being built by a different framework. Maybe that’s a better way to even word it like, if it is not giving you a way to build out your API endpoints yourself, then it’s probably only focus on the front end. Remix; Next; I think, there’s like Astro full-stack framework now; SvelveKit, which is doing it for the Swell; I think even SolidStart, I think has one for the SolidJS – these are all frameworks that are trying to put those two concepts together, and it’s important to backup, right? 

This is what we’re all doing, at least we’ve been doing that for the last ten years. We build a component; what is the component that makes a call in the back end, gets some data, and renders. So, it makes sense to me to kind of couple that in some way. I think, you know, coupling, that’s a word that we are all going to use with caution as an engineer, but I do think this is a good coupling, particularly at the page level or at the route level. Going to the page we’re all probably doing the very similar flow – hit the page, we go to the back end, shoving the data, if there’s an error we got to show them the error component, we probably need a loading icon – it’s the same three or four steps that we’re all doing. 

So, these full-stack frameworks are going to help with that. I am going to highlight Remix. A lot of times when you are talking and comparing frameworks the differences are marginal. So, I’m not here to get into a framework war or anything. But I think Remix is relevant to this conversation a little uniquely because what they’re doing, as the name implies, they’re taking the old way we were doing things, that old PHP kind of way of doing things and just remixing it with the modern tools, the technologies. So, they’re kind of recognizing… I just feel like when you’re using Remix, it becomes a little more explicit, and you start to see the history explicitly, I guess it’s what I’m saying. So, you’re used to this singles-page app where I only need JavaScript and I can’t even run this thing without JavaScript. And I remember before that, where it’s like everything was a multi-page app, so, every time I do erratic, I sit there and wait for the thing to make a whole new web request, that whole clunky thing. 

Remix is kind of taking that history, taking those two errors, so to speak,remixing it up to get that story to a pile. And now we have this thing where we can leverage the strengths of both. And to go back to your question, I think that is a powerful step. I don’t think you can do that if you’re thinking in this world of like, “Well, that’s back end stuff  – I can’t do that; that’s front end stuff – I can’t do that”. You don’t even think about these things unless you’re alluding them together. 

Brian Skinn [00:19:05] Okay. So, one analogy that’s coming to mind, and I’m curious if you think it’s apt. There was a surge of companies using the microservices model for their applications. So that the two into that spectrum – the monolith and the microservices – the analogy that occured to me at least is that the front and back end it’s almost like a two-piece microservices like sort of setup, whereas a full-stack, you widen the port and or the interface. So, instead of shoving your data through a narrow channel between your front and your back end, you widen that so that the communication is more general and more extensive between the two, or is that anywhere in the ballpark? 

Colby White [00:19:51] Yeah, I think you’re onto something there. I think the analogy might work better for like a mental model of how we approach it, that’s where the similarities are. Microservices are going to look at every little thing and split it up, kind of doing that with our apps. We looked at it – the front end starts here, and that’s one thing, and that’s a second thing. So, I think it was an approach of making everything small. I think there is some overlap there. One is horizontal or one is vertical, but I think you’re onto something there. 

Brian Skinn [00:20:25] Okay. Yeah. It seems like the reach that the code has on the front end into back end matters is just more extensive than full-stack.

Okay. So, full-stack, we’ve described it. Now, make the case for it. You have the history, it’s fitting the way that the work on the web is happening anyways. So, what are some practical consequences with that? What do you gain from going full-stack? 

Colby White [00:21:00] Well, first of all, let’s kind of describe the old way. And when I say the old way, I mean more in how we developed as a team. You know, if I’m working on a classical single-page application, I’ve got a feature I gotta do. I’ll make up a feature, I click a button and maybe something gets saved. 

What are we always doing, improving those become two different stories. One, we need a story to build the button and another, we need a story to actually save it to the database. And then, of course, there’s always that little gray area – do we need a separate story for telling the button, like integrating the button to the end point? Is that the back end story, is it the front end? This whole thing…  And now you have a dependency. Not only in the fact that from the Agile set you got two stories that depend on each other, both from human sense. 

Because we’ve all put ourselves in these front end/ back end buckets – only all these front end folks can do the story and only back end folks can do the story. Our philosophy is hit, because we got the finishes, we got to wait for Joe Blow over here to get free so you can build the button. But we already got the back end and we can’t release it. Here we go. right? So this all comes down… to me the biggest endpoint or the biggest benefit here is vertical slices. And even in that front end/ back end divide I was always trying to work in that capacity. I don’t want a story that is built upon. What does that do? I want a story that is delivering this customer value. I want to allow somebody to say the thingamajig so they can use it later as a user, blah, blah, blah, blah, blah.  And in order to do that, I need a button and a database. 

So for me, in my mindset that’s how I want to work. I want to work dealing… and when I’m done, customer value has been delivered. I don’t want to be done like, “Yeah, my buttons are done, but I need a database guy to do something”. This is not that makes me move slower personally, this is my personal opinion that is not satisfying. I want to move on and see when I go out the door all the customers rejoice. [laughing] So, to me that is the main benefit, is that velocity impact of working and having the ability. 

Just because you do full-stack frameworks doesn’t mean you’re going to make your stories like that, right? But now you can. You can work in vertical slices, you can put velocity impact. From a more technical standpoint, I know that a lot of people… one of the things that they think about is being able to share types or share things: types, interfaces or whatever case might be, share across that divide. Because we’re sending the same thing back and forth across the wire, let’s write it once and go from there. I think that is an important impact. Obviously, there are ways to do that without a full-stack framework. So, that’s kind of the case. With any technical benefit there’s usually trade offs and a way to give it another way, but it’s kind of like a free thing as I like to work that hard to get it. So that’s another benefit as well. So, like I said, for me it’s philosophy. You know, I’m not here to, like I mentioned earlier, I am not here to craft performance, I’m here to deliver value, so it helps me do it faster. 

Brian Skinn [00:24:18] Yeah, I can completely identify with that kind of redrawing the boundaries of any individual developer’s responsibility in a project instead of being the horizontal slices of qualitative deliverable to the customer. You can refactor it to where any given individual has something that they can implement technically, but then have a business value deliverable that they can own on whatever scale. Yeah. Fits the human factor better. 

Colby White [00:24:52] Right, human factor. So, we’re thinking in terms of somewhat not abstract, but somewhat theoretical, I guess. That’s a utopia. You know, I’ve learned that there are going to be people who are a lot more comfortable building components than they are, you know, adding a column to the database. And that’s perfectly fine. So, you’re definitely going to have some emphasis there or someone, who’s a little more focused on one side or the other. But just having the capability to say “Hey, I got to add a column on the database, I’m just going to go do it”. Just having that capability. A) We talked about the velocity, but B) Also starts to improve, in my opinion, improves the quality of your engineers because now you’re not one trick ponies. And again, that’s a little bit of my bias because from day one, the notion of being a one trick pony actually answered my mind. But yeah, I’m all for jack of all trades and this gives you a capability. And you don’t necessarily have to. I certainly think people are like, “No, I’m going to be the database wizard. I want to know everything about index”. And that’s fine. You probably need a handful of those people all on board in a large organization. 

Brian Skinn [00:26:02] The deep knowledge. 

Colby White [00:26:03] Exactly. It’s a specialization, but I think for me, defaulting to being able to do a jack of all trades style, it has a bigger impact. 

Brian Skinn [00:26:14] I like that, lowering the barrier around any given developer so, “Hey, we need this other thing done. You have some margin in your bandwidth. It’s not that far off from what you’ve done before. Could you take it on”? “Sure”. Rather than “Oh, this is a completely different technology, so to speak, bigger lift”.

Colby White [00:26:36] I mentioned earlier how I feel like this transition has kind of happened slowly over the last couple of decades. The fact that now we have full-stack frameworks, I think what you just described, and I think that’s accelerating things. 

Brian Skinn [00:26:48] Yes, sure. 

Colby White [00:26:48] To allude to that tongue-in-cheek title, of course, coders talk ‘Oooops,we are all full-stack developers.’ I think that’s what people are realizing is like, “Oh I could do this. I’m not scared anymore”. Right? So, now it’s possible the door is open. You peek through and like, “Wait a second, there are no demons back here. This is code. Code is code”. So, I think that’s kind of accelerated that burn. 

Brian Skinn [00:27:15] It’s always interesting… Technological innovation in general. You get some people, who are trying to drive innovation, but then sometimes things advance and somebody looks around and goes, “So, wait a minute, what just happened over the last five years”? And then noticing a paradigm shift after the fact more than necessarily seeing it as what’s happening. 

So, speaking of paradigm shifts. We want to talk a bit about the future full-stack. So, full-stack is here. We have these frameworks that are specifically trying to implement it in a smart way. What does the future look like? More Java scripts? Does this potentially expand? Like we talked before about JavaScript likely being around for the foreseeable future? Talk a bit about that. You know, obviously none of us can predict the future, but where do you see the trends going? 

Colby White [00:28:06] I think there’s always a little bit of a cycle, right? And I think we’re in a part of the cycle right now where we’re seeing a boom in frameworks. We’ve got a lot of different frameworks who are telling the story. They’re all telling the story in a slightly different way. But we’re seeing that kind of explosion. And I actually do think we’re starting to reach the end of that, because what follows is we start to coalesce. Because we have this in a small base. What if I was supposed to build this SPA, there is an explosion, and there’s a new framework every week and then what happens is we start to coalesce. It was Angular, React, Vue. Those are the big three. We all kind of coalesced on that. So, I’m starting to see that. Mainly with Next.js, this is really like this year. Next.js, particularly, with that actually the Reach JS  conference that really kind of positioned itself to be the big player here, which, like I said, that sort of lay out more of the Remix guy. But Next.js is pretty awesome as well. That’s not necessarily a bad thing. I think there is a little trepidation when she starts to coalesce around something, you better don’t do it. But people who aren’t necessarily fans of that don’t worry. But I do think there is a little value of coalescing that way. That way there are no conciliate options – let’s take that down to maybe two or three. 

So, I sense that’s what is going to happen in the next year. We’ve definitely seen some. ACAP releases Versal right of the hip. Shopify just bought Remix. Netlify just bought Gatsby. We’re starting to see now the money to start to flow in. So I sense that there’s going to be some coalescing. Now, who stands up on top at the end that I want to pick, because I don’t know. But I do think we will have some coalescing now. 

So, yeah and you asked about JavaScript in particular. I do think for the foreseeable future, JavaScript/TypeScript are going to be the main cortejure in this field. And I think that’s going to hold for a while. In my big Asterix there, and this is where I will ever reach an edge of my knowledge, I think it becomes about Webassembly, and where Webassembly comes in the foreseeable future, over the next however many years. And I admittedly don’t know enough about Webassembly, so to have a healthy prediction. But it just seems like what they’re aiming for there gets us at a point where now perhaps we don’t necessarily need that. Because earlier I talked about – you got the browser, and you have to use JavaScript. They might bring that, they might say, “Yes, you got the browser, but there’s also some other options”. And they get to a point where it’s like I can write something in Python and it compiles down to Webassembly, and now we’re good to go and it’s effective. And the DEX is growing, I think that’s the main key right now. Some say that DEX does not necessarily have the growth story or at least not as well as these JavaScript frameworks. 

So, if that levels up, then that whole point I made about if you’re in the browser, you do JavaScript and that gets broken, then like Wild Wild West, right? We know what happens after that. Now we’re back into these wars like, “This is the best programming language. That’s the best part”. Who knows, right? So that becomes the big mystery I see or the big unknown that arises. 

Brian Skinn [00:31:34] Another explosion coalescence cycle potentially. 

Colby White [00:31:39] Potentially, like maybe we get a bunch of Webassembly frameworks, right? And then we will go and do this whole thing again. 

Brian Skinn [00:31:45] Just for the reference for anybody who might not be familiar. Can you do just a quick-minute summary of what Webassembly is, how it works? 

Colby White [00:31:53] Yeah. So I think and then again this is going to be a big asterisk, because I’ve been in a JavaScript world. But my understanding of Webassembly is we’re trying to operate at a lower level in terms of the web. This doesn’t sound like Bytecoin or anything, I might be taking the analogy a little too literal, but it’s the idea of going at a lower level and delivering that. In my understanding there are big performance improvements, when you do that as opposed to when you are dealing with JavaScript that has to be parsed and then would have to be run, doing dealings on a lower level and performance being different. 

Brian Skinn [00:32:38] Intermediate language or partial compilers. 

Colby White [00:32:43] That’s why I’m so interested in it. But haven’t had a chance to dive deep into it. I’m interested at a high level because, you know, like I mentioned earlier, HTML/CSS, those are programming languages. And we’ve been stuck with them for so long and stuck with them because the browsers use it and you can’t make changes to a browser willy nilly, right? Everyone’s got that browser and that’s a whole ordeal, right? So the browsers tend to be slow.

Brian Skinn [00:33:15] They are a platform, essentially, and platforms are very slow. 

Colby White [00:33:19] Exactly, yeah, it’s a platform. So if Webassembly becomes a viable alternative platform, it’s conceptually interesting to me because it’s like, “Okay, now we’ve got a whole new bag of tricks that we can do, only a toolbox to deal with”. 

Brian Skinn [00:33:36] Indeed. Any other particular topics you’d like to hit before we round up the conversation? 

Colby White [00:33:43] Yeah, I think it’s important to call out, because we’re engineers having this conversation. But I do think there’s a corollary and then there’s an adjacent conversation with this whole full-stack where we talk about designers. Because we talked about routing, data mutation, all these things are happening now in the front end, and that’s where we’re coalescing our back end skills and front end skills. But there are still skills that are very much front specific: accessibility, design systems. Things along those lines, right? Those are things that I’m not sure everyone is like… That seems to be a little different. And I’ve heard this referred to as the front of the front end. 

In my opinion, I think that designers have started, that industry has started to mutate as well. If you’re a designer in the nineties, you’re designing for print, right? Fast forward three decades, you’re designing for the web in over three decades. What happens, and I think a lot of designers are starting to realize, “Well, it behooves me to learn a little bit about CSS. It behooves me to learn a little bit about HTMLS”. So, I can interact with my web designers better. They’re getting a little more technical. They’re not necessarily going all the way building react components per se, or at least most of them. But they’re, definitely, adding more value, in my opinion, by doing that. So, we got design systems to become a thing, accessibility. 

I think by learning these technical things, they’re actually in a great position to help with web performance, because their designers are coming at it with a much more customer-mind, they’re thinking of it from the customer, sort of thinking about it from different browsers, from different mobile devices, etc., etc.. So they’re adding value here. But I think it becomes a little hard, like what do we call them, “Are they designers? Are they front end developers? Are they something else, some new hybrid? I don’t know, designer clothes”? I’m not sure what’s the answer there. I think it’s notable and I urge it. I’ve worked with those style designers and they’re a pleasure to work with. They ask you questions that you never really think about because they’re just thinking about the problems differently and not just in a different way, different in a way that we should be thinking about them as well. So it’s a very important skill to bring into this dichotomy. Here is engineering that we’re starting to flatten out, but we got to recognize there’s still an edge here that we’re missing. But they are also kind of coming in as well. So like How that works?’ I think it’s important. 

Brian Skinn [00:36:31] Yeah. A leading edge of exploration in terms of designers thinking, starting to acquire the technical mindset and the technical, you know, bridging into the designer mindset. What can we do with this digital medium novel, new, interesting, effective that just wasn’t. Is it possible in a static print medium and, you know, innovating? 

Colby White [00:36:58] Exactly. That’s one thing I’ve learned by bugging my designers over my career. How difficult, how much more difficult designing for the web is compared to divine designing for a magazine, right? It’s like right off the bat. What is your canvas like? And doing a magazine 8 by 11. Its web, well the customer can just adjust the browser, right? Just that off the bat it’s like a different world? 

But like I said, it’s kind of becoming a little more technical once you describe it. I think that helps all of us, and I do think that there is… what I say is I think where there are two worlds absolutely overlap is when it comes to design systems. Some of the tools around building design systems are, you know, technical as well. It’s like a very technical deal to build that out, but that’s where the overlap is. Because they’re cranking out the design system, and we are using it. And I think that understanding that overlap and making sure that that process involves both sides of the house, so to speak, I think is important. So, I’m just wary of us as an industry doing the same thing and making it say, “Oh, that’s their thing, that’s our thing”. Now back into this world, maybe it’s a little different kind of example, but this feels the same. And so I think we should learn from that. Let’s figure out how to overlap. And I think that’s happening with all these design systems to us. 

Brian Skinn [00:38:26] I mean certainly some of the websites I’ve seen like the Vercel the Next.js conf. That website is just one example that I’ve seen recently that was very interactive and like a treasure hunt game built into the browser. It’s just creative, creating new things that people are doing with the web. 

Colby White [00:38:43] Absolutely Yeah. So yeah, I like that word creativity. I think what we do as engineers is incredibly creative, but it’s a different kind of creative, mathematical, problem-solving creative. They come at these problems that are a little more, I forget what side of the brain, right, left, but brain. 

Brian Skinn [00:39:02] Yeah, exactly, exactly. 

Colby White [00:39:04] So and it is in this approach you get crazy, not crazy, but incredibly clever output like that. So, I think that’s important. 

Brian Skinn [00:39:14] Absolutely. Well, I think we’re about on time, so we’ll wrap it here. Thanks so much, Colby, for your time today. Thank you to the audience for attending. I learned a lot. You know, I really appreciate the insight into the full-stack frameworks. I’ve known a bit, but I appreciate the deeper understanding. 

The event is recorded for today and that recording will be posted to openteams.com and our YouTube channel once we have it prepared, that’s within a few weeks. So, look out for that. That’s all for today’s event. Remember, Open Teams gives you access to the best open source architects in the world to help you train, support and deliver your software solutions. Feel free to go to openteams.com to learn more about Open Teams to get to know our open source architect network or to apply to become an OSA and architect yourself. Thanks very much. Have a good one.