85. The New Definition of Frontend Development

Charlie: That's great. It's funny because I think in 2010 billing yourself as a JavaScript engineer now is a pretty common role potentially to advertise for or to go for. But it feels like thinking back on my experience of web design in 2010, it was a very different kind of space around the tooling and around how people would kind of pitch themselves.

Ben: Totally. Listen, I'll reveal something. I think I applied for Facebook around 2010, I got to the onsite and one of the interviews basically told me they didn't really know how to evaluate me. I was being asked to do some CSS exercises, float these squares on a website. That's what was expected of me. That's just kind of what front end development kind of meant at the time. The language was more of a design centered role. Didn't get that job. I eventually worked at a company called Disqus, which if you're familiar with it, it's an embedded commenting platform. It's all over the web. I used it on my personal blog in 2010. I think a lot of people did as static websites were coming into vouge. It was a way to get comments on your static website.

Ben: In part I took that job because they were one of the few employers at the time, which was like here's a product that's entirely embedded JavaScript that you deploy on someone's page and that's how it renders. That's how all the data gets transmitted back and forth. That just felt really exciting at the time. There just wasn't a lot of opportunities that were so exclusively JavaScript focused.

Charlie: I guess to kick it off, defining front end development and that evolution, which I think you kind of touched on there, but I'd love to get your thoughts on where things have come since 2010 and how things have changed.

Ben: At the end of the 2000s, I would call myself a full stack developer. At the time I was working for a company called Fresh Books. I was writing PHP. I was writing JavaScript. I would build the full solution. I would write database migrations. I would write SQL queries and then I'd get into JavaScript world. I don't think that we used anything beyond jQuery at the time. You'd wire things up and you'd have to do like just a lot of manual managing of DOM elements. There wasn't really a lot of tooling at the time. I would say the debugging experience was very painful. At the time, it was very normal to support Internet Explorer 6, maybe even 5 at the time, where the debugging experience meant that you were limited to writing window.alert and alerting out some values.

Ben: I think a big part of that is what drove almost like a lot of dismissiveness around JavaScript development or frontend development, mostly because no one wanted to touch it. My experience was that this was just so painful that no one wanted to work on it. That's the reason that it was just... I felt that if people dismissed it, it was because of that. I had an opposite take. I had a contrarian take, which is, "Wow, this is so hard. No one wants to touch it. This is an opportunity for me to become really good at this."

Ben: I'm talking about 2010. You're talking about the field in its infancy and I kind of wanted to be at the forefront of that. So 2010, I feel like at this point, maybe even 2009, 2008, Firebug was probably the tool that changed the game where now you can have a debugging experience in the browser. I can step through lines of code. I can inspect variables for what value they are at this running state. I feel like that's what turned it from hacking into a real software engineering profession. Then from there, the tools evolved. We got Backbone as sort of one of the first popular single page app development libraries or frameworks. Then from there Angular and Ember kind of emerged again, I want to say 2012. All those tools really just kind of sort of leveled the playing field in the sense that now software developers had all these tools and all these frameworks and all these patterns that made it more approachable, offered a lot of the tools that many people who are doing backend development were used to.

Ben: I should also offer up the browser landscape of course changing. Once we all accepted that maybe we didn't have to support old versions of Internet Explorer anymore and browsers got on this automatic release model, that also kind of really made things less frustrating and more pleasant and I think attracted a lot of people to the field.

Charlie: Yeah. I think one thing as well acknowledging everyone's favorite elephant in the room, the implications of Flash support on mobile had a really profound impact on what business could get behind in terms of what they'd support. In my past life, I was in advertising, which I think has a lot to answer for around the things in Flash where maybe it's less desirable traits like being incredibly bandwidth hungry and all those kinds of things. I remember being in a massive ad agency at the time that Steve Jobs wrote that letter about Flash and why the iPhone would never support it. It was like a kind of a groundswell of then internally people looking for ways, having this device in their pockets, creative directors and the like who had these devices in their pockets were like, "But I want to be able to do this thing and I don't understand why I can't do it on my phone now."

Ben: I didn't come from that background. I came from sort of the other side, but you're totally right. Those experiences that were being built in Flash, I've probably not thought enough about how that's led to desire to have all that dynamic behavior and flexibility in the browser, which has led to so many of the APIs that exist today. Canvas. Remembering that we didn't even have SVGs in browsers for awhile.

Charlie: Yeah. It's interesting. I think people talk about Flash in a really negative way, but I have super fond memories of it. Like ActionScript 3 was a wild language when you were starting out, it had like Java-esque qualities. It was really forgiving in some ways. It was like, I don't know. Yeah, it's a funny trip down memory lane. Maybe it'll come back. Maybe it'll be like cassettes and everyone will be like, "I built my website in vinyl." ActionScript 3, it's coming back.

Ben: Yeah. I mean, there's always that sort of cyclical nature of things. I think a lot of JavaScript developers who've been around for a long time... What is that expression people say like, "Dojo already had this or maybe MooTools already had this." Especially around... I think Dojo and YUI had all this bundle support in the mid or even late 2000s that we've reinvented over and over again. I know that ActionScript developers have the same attitude about like, "Hey, I could do all this stuff a decade ago. You're just catching up to the power that we already had in browsers."

Charlie: One thing I was going to say as well in terms of that evolution, I think Backbone was such a, at least for me personally, but in terms of looking at the landscape of front end development, Backbone felt such a breakthrough in the sense that no longer, like I think you talked a little bit about having jQuery touching different parts of the DOM in a way that was very manual. Then all of a sudden Backbone kind of allowed you just to bind these things together and things happened and it felt kind of magical and abstracted those things away so you could focus on the experience or focus on whatever data you were trying to manage or deal with or display.

Ben: I think the Backbone is to JavaScript as Ruby on Rails was to PHP development at the time. I started web development in Rails. I don't know the exact version, but this was maybe like 2006. My experience up to that time was like, okay, I can use CGI-bin. I can call a script and return something. It was really hard for me to envision what was even possible with that. I'd walk through phpBB code. It sort of like larger PHP projects and it was just such a tangle that it was really just hard to wrap my head around. Ruby on Rails presented this model that I think was very clean, the MVC model, that I can reason about. Now I could picture applications that I could build.

Ben: And similarly Backbone. Again, probably the only architecture that I had is that I used closures and didn't leak global variables as far as what I was doing in JavaScript in the late 2000s. What was the architecture of that? I think it was really just a bunch of function calls and just trying to encapsulate things as best as you could. Then Backbone was like, "Hey, you can think about front end development in the same way that you've kind of thought about MVC on the server." So in a similar way, I feel like the possibilities opened up, the profession kind of opened up. We could use software architecture patterns that people have been using elsewhere forever in a way that made sense in JavaScript world. I do think it was... Backbone certainly deserves a place in front end development's history for that.

Charlie: Yeah, absolutely. Absolutely. Then you can kind of see that evolution from what Backbone had started through Angular all the way to React in the future. What do you think about that evolution leading up to today?

Ben: I think that the evolution has been good. Backbone was so universal, truly. I think it really was a Backbone. I think that everybody who was building on Backbone, they use it as the skeleton that they sort of then wrote their own hand-rolled code on. It may have provided 60%, maybe probably less. I think that a lot of people looked at that and said, "Hey, we can go further. We can have a more opinionated framework that provides a lot more scaffolding, that provides a lot more tooling so that people don't have to make so many of these decisions for themselves." I think that's where Ember and Angular kind of came from in terms of providing that full experience, so being a little bit more like Ruby on Rails or Django or something like that.

Ben: Everything's been an evolution from there. React introduced this render model that just made things so easy. That was sort of another paradigm change. I would say like one of the largest paradigm changes in the sense that everybody has adopted that virtual DOM rendering data binding technique that has just made things easier. We're talking like from 2010 to 2015. So if you think about that five year gap or that five-year length of time where we went from jQuery to Backbone to Angular, Ember, React, I can understand how the attitude of many developers or observers of what's going on in front end world are just like, "Wow, this community cannot keep its head straight. There's something new all the time."

Ben: I actually felt that React was going to be around for a long time. I've got some tweets out there that back this up. Because my feeling was that each of these frameworks had really offered something new. Until we see what the next big leap is or the next innovation is, the community is maturing. A lot of companies have adopted these platforms and they're not interested in shuffling technologies every two years. There's no appetite for it. As the industry and the profession matures, there's just sort of a gravitation to holding on to things and trying to make them better. The idea that Ember adopted the React kind of render model and they introduced this Glimmer engine, I think is indicative. It's like, "Hey, we don't need to code and create a whole new framework for this. Let's just take the good ideas that React introduced and bring them into what we do." So that was kind of the path forward.

Ben: I think that there's still an opportunity for another big paradigm change, but until we see that, I don't know that we're going to have everyone roll over onto a whole set of frameworks again. I think that there is kind of a level of entrenchment maybe, and people are pretty happy. I think people are pretty satisfied. The tools have evolved really well, probably because of also corporate sponsorship where Facebook manages React, Google manages Angular. We didn't have that a decade ago. The tooling has been as good as it's ever been, which may be a incendiary topic for some who harken back to this time when boy, I wish I could just put a JavaScript file on a HTML page, but I'm really satisfied. I think it's great.

Charlie: Yeah. I think as well, I mean, I really love seeing that evolution to this point because so many of these tools have borrowed from the ones before. The level of complexity is ultimately up to the developer. You can get Angular- and Vue-like attribute directives using Alpine.js, Or you can get all the way through to fully fledged content management through like Nuxt and Vue content. There's a heap of options now that are almost more tailored to the kind of application that you're building, rather than potentially this one size fits all. Whatever you're building, you're using jQuery or whatever you're building, you're using whatever the flavor was at that window of time.

Charlie: But I definitely relate to feeling a certain amount of frustration during the uncertainty of making those tools better. I think Angular was a good example that in its earlier version, there was factory services and they were sitting on top of providers, but there wasn't really that many differences. Instead of there became a lot of uncertainty in the community and you can kind of see that a little bit now in the response to maybe Hooks. When Hooks first came out for React, there was a feeling of like... Or I felt like there was a swell of people maybe pushing back and being, not frustrated, but uncertain about how much they need to learn this, how relevant this was going to be.

Ben: I got an anecdote to share about this. I think that there's a perception that yeah, the JavaScript world was just spinning so fast. I need to be constantly learning. I just don't personally think it's really any different than any other community or sub community of programming as a profession. When I was in college, I worked part time at a bookstore, a big box bookstore in downtown Toronto. I worked in the business section where the computer books were, and I was a computer science student at the time. I would talk to people, buying books, buying programming books. Stack Overflow didn't really exist at this point in time. So people were still getting most of their knowledge from books. When I was doing graphics programming at the time, I had these big thousand page textbooks basically to teach me DirectX and OpenGL and so on. I have this memory I've never forgotten of somebody coming in, an older gentlemen, it may have been late thirties who was just picking up a stack of .Net books, which had come out recently.

Ben: He was just grumbling aloud to me just about what he felt were undue requirements on him to have to constantly learn new things. I think he was a Java developer and I'm like, "Oh, we're exploring .Net right now."

Charlie: I mean, that's the thing, right? Ultimately, if you try to keep right on the cutting edge, they'll definitely be things that drop by the wayside. There was a tweet you wrote in May that was saying that in January, you spent three hours trying to convert your personal website to Gatsby JS. And then you asked yourself, what am I doing? Uploaded an index.html file and called it a day. It's like definitely tongue in cheek, but also like very true. Because I think sometimes the anxiety comes from feeling like we're being left behind.

Ben: Absolutely.

Charlie: But you're solving a problem. I think someone replied, "I don't read this as a knock on Gatsby or any tool but instead the underappreciated skill of pragmatism that is honed over years of getting stuff done in spite of potentially shiny distractions." Which I thought it was such a great way of thinking about this, what could be a wall of possibility is actually just options. And you can choose to take them or leave them, depending on the organization that you work for, the things that get you interested. Ultimately, work should be something enjoyable. And if there's a tool that really doesn't feel right, then that's not a bad thing.

Ben: I think your comment about being left behind is totally right. If I had to bring it back to my bookstore anecdote, the concern that this fellow had was Java wasn't going to be good anymore. Here we are. By the way, Java is still one of the biggest programming languages. He would have been just fine, but I think that that anxiety, that was like, wow, .Net is big. It's got Microsoft behind it. That was kind of the attitude at the time.

Charlie: For me personally, I was thinking about Grid because I started trying to use CSS Grid for this project. And I realized just how many gaps there were in my knowledge because my career has changed to be potentially less hands on at times, how deep I need to be into new technologies has changed based on some of the things that I work on. Just things have changed. I was looking at, Una Kravitz has posted 10 modern layouts in one line of CSS as part of web.dev. I was looking at it and it's like 10 small snippets of information that made me feel a thousand times more confident about Grid because it's like this is what this is doing. Here's some examples. All of a sudden it kind of alleviated that.

Charlie: I think the amount of information that's available can be overwhelming, but it also means that there are more and more ways to kind of get up to speed even if you feel like you're potentially not right at the forefront, like you can find something that maybe gives you some context that helps you better understand it. I think that's true of the leaps that design has made on the front end as well.

Ben: I agree. I'll even throw out a suggestion to folks who are suffering from this anxiety. I have a personal rule, which is when I hear about something that's new, I'm going to wait a year. I'm going to wait a year, see how it shakes out and then check it out. Even though I'm in management and I have very little to say about the architecture of the application today, but I like to understand a little bit about where we're going. Hooks, I took a look at that for the first time a few weeks ago. We built a React application. I think that again, people chase shiny things. It's exciting. It is inherently exciting. But if you're concerned about, I need to know this stuff, well, sometimes things just actually fritter away a year from now, right? Some things don't get that kind of critical mass of mind share or adoption. I just want to be on the other side of that discussion or I would burn out personally.

Charlie: Yeah. If you want to be in that discussion, it's there for you. Right? I think that's the most exciting thing that as an industry, one really great example I've noticed is in interviews, it's much less common in my experience to focus on what's your public GitHub activities? What things do you have out there? What do you spend your weekend working on? Because ultimately not everyone has, for whatever reason, personal, familial-

Ben: I would say the majority of people don't have.

Charlie: Yeah.

Ben: But I think that the people that we follow, we're shaped by people who do, right? So that can create warped perceptions of the industry. If the people that you hear on Twitter who are retweeted, or you're watching their YouTube videos, they're frequently those people. Also in many cases, they're literally paid to be at the forefront. This is why I bring up developer advocacy again. So they don't have the same relationship with work as I think the gross majority of software developers. I think that's just something to keep in mind. Now, if you want to be there, to your point, all this stuff is there, but it's okay to not be. And I think that most of us aren't.

Charlie: Yeah, I think it's comforting as well, because then when you do find something that you're really passionate about as well, you can consciously make the choice to pursue that and potentially write about it or share it. So I think that kind of fundamental joy of education and web development, which to me has always been at the forefront is still available to me. It's just that I can now pick and choose the things that I choose to write about or that I choose to give my time to, and that's healthy. Right? That's like a good thing.

Ben: Absolutely. Yeah.

Charlie: Yeah. So I kind of touched on design a little bit and I'd love to kind of talk a little bit about that as well, how design has changed. I think I mentioned Grid is a great example, but you talked a little bit about that browsers have kind of moved away from these really... I feel a little bit like there's going to be really young people listening and I'm talking like back in the old days, but it was the case a browser had a set of capabilities and it was there for a long, long, long time. You learned how to move around that. But these days, now that browsers update automatically, features are added over time. Things are kind of rolled out pretty constantly to pre-release Chrome Canary, or Firefox Nightly, things like that. It does feel like there are a lot of new opportunities and ways to approach design on the web. I think that's a really exciting thing, but there has been a big evolution there.

Ben: If I look at our front end engineering team of which I'd say there's maybe seven people on our engineering team who would classify themselves that way, it runs a full gamut of people who are really interested in the internals of JavaScript and the classes and the architecture to the experience. I would also add that even our design team, most of our design team are hands on implementers. They're writing CSS and JavaScript, for example. They're doing designs in Figma and often implementing them as well. So that's true. I think that the idea of a designer as somebody who just hangs out in Photoshop all day, okay, they're probably not using Photoshop anymore, but I think it's kind of going away a little bit because now part of the design is also the experience. And to understand what is possible with the experience, you kind of need some knowledge of what is possible in a browser, what is exposed to you so that you can bring that experience to life.

Ben: Design has moved more into front of development, I think, in parts that we can just create really good experiences, right? It's going back to ActionScript. That type of work is in front end development now.

Charlie: Absolutely. Yeah. I think the value of... Even if you're not necessarily sitting there writing out components and the interactions, at least from a design point of view, both the tooling and the maturity of it as a discipline means that having that understanding of how your designs will be used is so important. Like UX. I think UX back in 2010, I remember I used to attend a UX book club, which was at the time kind of a new field. It wasn't necessarily something that was as commonly talked about or focused like it is. It's such a huge focus now, which is so great because I think a lot of the time it was the case where you would design something in Photoshop in many, many layers. Then you would hand it over to someone who had the unenviable task of trying to decipher what that actually meant in code and what was maintainable. You had this real disconnect between what you or your client or a product manager was anticipating would come out the other end and what was actually technically possible.

Charlie: Whereas this is, I think, the relationship that Figma and Sketch have to code is so defined and so at the forefront that it's almost impossible not to consider how these things will work in code. I think it means that we're all so much more literate about the things that we're creating and the idea of designers and developers is blurring in a way where the best of each can kind of combine to make something greater than the sum of their parts, I guess. Yeah. I just find it a really exciting shift in the way that we think about and talk about front end development.

Ben: Totally agree. Here's another one also is design systems and tools like Storybook where you create your own sort of internal components, agreed upon design language. There's just a lot of tools to facilitate that now that... I know that we have those things. So if you have an engineer who's maybe a little bit less design literate, they can create an experience that's pretty on brand, right? They can take you 90% there with the components that exist. They can make good choices. They can look at the patterns that already exist in the application and apply that to what they're building. So in some ways, designers are also turning into architects of their own.

Ben: That's the other thing I'm seeing where it's just as programmers build reusable components everywhere in software, I feel that we've entered an era where designers really, really technically fluent design teams are creating effectively reusable components often in the framework itself, right? Not just, here's a mock up of what this should look like, but actually here is the component, right? These are reusable and shareable. Here's the layout components, et cetera. The work that they're doing now is really high leverage.

Charlie: Yeah. I've been really lucky to work on design tooling at Salesforce in my time there. It's such an exciting, interesting space. I love this crossover between what design tooling can offer and how it's taking from some of the engineering ideas and pieces. For example, Abstract giving the concept of branches to design files so that two designers can be branching in a kind of get esque way and emerging things back together. And then how components, like you say, can be built within the framework with the intent of their final destination and how they're going to be used rather than being kind of separated from that. It feels good.

Ben: Yeah. It's a continuing evolution, right? If we began this kind of conversation talking about how just a lot of these tools didn't even exist in JavaScript development and then it kind of emerged and just sort of continuing up the stack, as it were, to the design space where everybody's programming now. I'm going to say that also on the debate of, is HTML and CSS is programming? Yes, it is. Just everything's boring the whole way.

Charlie: I think in terms of... One thing I was going to ask about. What skills do define wider front end development? There are some of them, but are there other things that should be in mind when we talk about this idea of a new definition?

Ben: Yeah. The new definition. Even something we talk about internally at Sentry, and I don't know if this is true for other companies, but even though we talk about front end development moving towards even more and more design, we even talk about in on the server. And I say that because now the backend components are being just so abstracted away. If I want to build a server endpoint and I'm traditionally a JavaScript developer, we've just expanded those tools so much. Now, in a serverless world or a cloud world, I don't have to think about how many metal servers or Apache instances I need, right? End of the day, I think software engineers, software developers, you can only hold so much things in your head. Right?

Charlie: True.

Ben: The notion of a full stack developer, I think, is becoming more real because we're abstracting away a lot of the backend stack and to build a product, to build a really good product, you do need to go up and down the stack. You do need to write, you need to understand how the server generates responses and how you can use that to create good experiences on the client. I mentioned that we have front end engineers at Sentry, but we have a philosophy that nobody owns a code base. You do whatever you need to do to be successful. If you want to jump in and write some Python on our server backend because you're trying to build that experience, absolutely. So maybe full stack is becoming like more of a real profession. It's gotten a bad rap as an endless list of responsibilities of a unicorn person. But with the way that things are trending with tools, I think it's becoming more realistic.

Ben: Now, if I want to pivot a little bit and say... Because I am a hiring manager and we've hired a lot of people. I do think that product sense is a really undervalued skill in front end development. Maybe this speaks to the bending a little bit more towards the design, but people who really do want to build great experiences. We want people who are more interested in the outcome of a good experience and thinking about what's the best way to get there rather than someone who's thinking a little bit more, I need to build things in a certain way to feel satisfied about the outcome of what I have.

Charlie: Yeah. I think you really hit on something there that ultimately, when we look back, the tools have come such a long way, but there is still this core underlying value to what is the experience? What are you trying to communicate? What goal does your user have in mind? All of these things are kind of tool agnostic, right?

Ben: Yeah. I mean if I could even give an example right now. So we have an older Flux library and like many people, we look at Redux and popular evolutions of that Flux pattern in our architecture. But the way that we approach it is are we going to adopt this because we're told? Either the community is communicating to us that this is popular and everybody just builds it this way, or are we going to achieve something new? When we do talk about it, there are genuine outcomes that we would get from adopting the technology by adopting Redux or something else.

Ben: But that's what's driving that decision, right? Maybe we want better control over our stores because we want to avoid refreshes on pages, which is hampering the experience. That's another example of something that we look back and we're like, "Yeah, we're going to get that from this. So let's invest more." Those are the real conversations that take place within a company. At least that's my experience. And I hope so for many companies, right? Not how do I get off of this old stack, or how do I get on to this new thing? But we have a requirement of the product to really serve our customers in a great way. What are the tools that are available that are going to get us there?

Charlie: Well, I think that's a great place to finish off because ultimately that's the biggest thing, right? What does this do for the customer? Ben, I want to thank you so much for joining me. I do want to though take a moment to recommend that everyone listening checks out Sentry.io, which is an open source cloud-based era and monitoring tool. If you only look at it for one reason, it should be because it's probably my favorite homepage and marketing experience on the internet at the moment. And I've referred to it many, many times, and I really want you to introduce me to whoever designed those buttons. Ben Vinegar, thank you so much for joining me on Code[ish]. It's been an absolute pleasure.

Ben: Thanks, Charlie. It's been great.