Looking for more podcasts? Tune in to the Salesforce Developer podcast to hear short and insightful stories for developers, from developers.
85. The New Definition of Frontend Development
Hosted by Charlie Gleason, with guest Ben Vinegar.
Charlie: Hello, and welcome to Code[ish]. I'm Charlie Gleason. I'm a designer and front end developer at Heroku and at Salesforce. Today I'm joined by Ben Vinegar, the VP of Engineering at Sentry. We're going to be talking a little bit about the new definition of front end development and what that means. Ben, maybe you want to give a little bit of background on yourself to kick us off.
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.
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: 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.
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.
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.
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: 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.
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.
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: 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.
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: 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.
A podcast brought to you by the developer advocate team at Heroku, exploring code, technology, tools, tips, and the life of the developer.
User Interface / User Experience Lead, Heroku
Charlie is a designer, developer, musician, and creative coding enthusiast. He can usually be found somewhere in London, probably on a bike.
More episodes from Code[ish]
Robert Blumen and Marcus Blankenship
How can developers learn from catastrophic errors such as airline disasters? Learn how understanding the root causes of failure in complex systems can prevent their recurrence. →
Karan Gupta and Marcus Blankenship
How can applying the right technology choices at the right time impact your coding and business choices? Karan Gupta explains how practicing “pragmatic engineering” can have an oversized impact on business and business efficiency. →
The episode focuses on managing a certificate authority (CA) within an enterprise. The internal CA is compared on many points to PKI on the public internet. →