JACOB: Hello and welcome to Episode 170 of Greater Than Code. My name is Jacob Stoebel. I'm here with my co-panelist, Rein Henrichs. REIN: Thanks, Jacob. I am here with our guest, Chris Ferdinandi. Chris helps people learn Vanilla JavaScript and he believes that there is a simpler, more resilient way to make things for the web. His Developer Tips newsletter is read by thousands of developers each day. Learn more at gomakethings.com. Hi, Chris. CHRIS: Hey, how's it going? Thanks for having me here. REIN: Yeah, very excited to talk to you. So you know what's coming next. What is your superpower and how did you acquire it? CHRIS: Yeah, I have two. The first is derailing conversations. Really, really good about that one. That's probably [inaudible] all over the place. And so I tend to go on a lot of tangents when talking. A more useful superpower though, I somehow have a knack for taking complex tasks and breaking them down into smaller, simpler parts that people find easy to understand. I'm actually not 100% sure how I pick that one up. I don't know if it's something innate or if it's like a nurture thing that I learned over time, but it's really useful when you want to teach people stuff. So, that's been kind of a blessing for me in my career. I'm not necessarily the best at certain things, but I am oftentimes better at explaining it in a simple way than other people are. And that's worked out quite well for me. REIN: And you are known for advocating Vanilla JavaScript. CHRIS: Yes. REIN: That is sort of one of your bags. CHRIS: Yeah, that's my big thing. And a lot of that honestly is just born out of my obsession with simplicity. I'm a little bit of a minimalist at heart and that carries over into the way I like to do web development as well. REIN: So, I'm interested in what is the pitch for Vanilla JavaScript? If I am, let's say, a React developer, why would I care about Vanilla JavaScript? CHRIS: That's a great question. So, there's a few reasons and it's a little bit interesting when you frame it in a sense of like if you're a React developer, because a lot of what I do is not necessarily trying to convince hardcore framework developers that they're wrong. Although I do try to do some of that too. I'm a lot more focused on people who are kind of just getting into this and finding the current state of web development really confusing and overwhelming. And I can take both angles. So I'm absolutely happy to talk about if you're a React developer, why you should care. But I think the conversation is maybe bigger than that. REIN: So, is this more of like websites can have a little JavaScript as a treat thing. You don't need jQuery for that. CHRIS: That's part of it. Although I'm not necessarily against [inaudible] by JavaScript and I think sometimes that's appropriate and sometimes that works. I think it's a bit more kind of a spectrum. If I were to start off this conversation, you mentioned early on I have a daily Developer Tips newsletter. Everybody who signs up gets asked a question by me, what's your biggest challenge as a web developer? And I get a ton of responses back. But the one that comes up more than anything else, it's honestly like half of the responses I get back is some variation of 'I have trouble keeping up', 'I'm not sure where to start', 'this seems really complicated' 'I don't know where to even begin'. And there's this thing where modern web development has gotten so, it's grown in scope. So, frontend developers do a lot more as we've kind of matured as a profession, we've added a lot more kind of processes and tools into things, but it also makes it, I think, sometimes a lot more difficult for people to get started. And it can impact the performance of the web for our users in bad ways that we don't always feel. Because a lot of times we're working on fast internet connections and really high powered machines. So from my perspective, a lot of what we consider modern best practices are actually making the web slower, more fragile, more prone to breaking, and ultimately harder to build for these tools, help in some regard. And then they also make things more difficult than others. Anybody who's ever gone [inaudible] and then suddenly found that all of their dependencies are out of date and they have to like re-install or update their dependency chain and then find that versions of things are out of sync, so stuff isn't working anymore. We'll understand what I'm talking about or maybe resonate a little bit with that pain. JACOB: And as someone who works in JavaScript, I can definitely relate to the -- I'm speaking in all capitals THE RIGHT WAY TO DO IT and how that you read Twitter, you can be pretty funny because I remember a few years ago when there was a right way to do it with React and now there's some contradictory advice on what's the right way to do it. And nowhere are we really reminding new people that that comes with a big asterisk. The really what it is is knowing [inaudible]. But when people are new, they're thinking about not just getting their project done. They're also thinking about like how can I use this project to show that I'm a real developer because I want to do it the real way. I want to do it like the professional way and prove myself. And I feel like that's always in the background. And I feel like that's kind of partly what's striving thing. CHRIS: Yeah, 100%. The caveat here is like my whole career is teaching people JavaScript. So I'm not against JavaScript. I use it all day. I absolutely love it. I just want us to be more responsible with how we use it. And there's a lot of factors for kind of why things are the way they are today. But if I kind of look back at the history of web development, I think about how we got to where we are today. If you've been doing this for awhile, you may remember the era where the backend developers were where real serious development happened and the frontend was just kind of like, it was a play thing. You had webmasters, they built these cute little Geocities sites with under construction banners, and the real work happened on the backend. And then somewhere along the line as the platform matured, that shifted. Now, frontend development is like real serious business and you build these crazy tools that let you have real time video chat and edit photos and do all sorts of really cool stuff. And you saw two things happen. A lot of backend developers migrated over to the frontend because that's where the exciting stuff was happening or companies that wanted to save money said, "Hey backend guy, you're going to do our frontend stuff now too." And a lot of these backend approaches and best practices and paradigms got brought over with them. A lot of my friends who have backend backgrounds, a lot of .NET developers who moved to Angular, in the way that they talk about the frontend, you can tell they're bringing these backend best practices. They make perfect sense on the backend over to the frontend, but the frontend is a very different medium. In the backend, you have control over pretty much everything, how fast the server is, when things run, the operating system. There's just all this control that on the frontend, you have none of. People are accessing what we build on a variety of devices with unpredictable internet connections and devices that may or may not be able to handle the stuff that we're sending. And so from my perspective, I feel like a lot of kind of these backend best practices, they don't carry over the way you'd like them to. And when you get people who are on spotty internet connections, CDN times out and a file fails to download or they go through a train tunnel and lose their connection. If we build things in this like modern JavaScript heavy way, the whole house of cards just kind of falls apart on those people. And so we've made this web that in 2020 could be the fastest thing we've ever built. But oftentimes, it's actually slower to load or have the same speed as pages were five years ago and way more likely to break or fail unpredictably. You just get the white screen of death and you have no idea what's going on. And so for me, that's really my biggest problem with the way we're building things. And that doesn't mean never use JavaScript. It just means let's be a little more thoughtful about how we do. So I have some ideas on how we can approach things differently that we can get into if you want. But that's kind of the big problem I see with the way we do things today. JACOB: Yeah, I'd love to get into that. [Laughs] CHRIS: Awesome. For me, there's a few things. It's almost worth -- before I get into what web development maybe should look like, because this is not just for me about frameworks, it's not just like frameworks are bad. They serve a purpose. So if I think about modern web development, it involves a few things. It's the use of frameworks, which if you're someone who's building your entire UI with JavaScript and you're using it based on some sort of state or data object and you want to say, "When the data looks like this, the UI looks like this. When it looks like that, the UI looks like that." Frameworks are really helpful. They make stuff that would be kind of a pain with manual dom manipulation a lot easier. So if you totally get that, awesome. The other piece is package managers. A lot of people think about this modern use of modules and packages is like standing on the shoulders of giants. So rather than reinventing the wheel every time you build a site, let's re-purpose this amazing ecosystem of tools and packages and modules that already exist. The third piece around frontend development or modern best practices, and I don't see this talked about as much as I did maybe six or eight months ago, but for a little while people were really psyched about the idea of the cascade is bad, writing CSS sucks. Let's put all our CSS in JavaScript too. There's been kind of this shift to doing more and more and more in JavaScript and we're seeing people author CSS in JavaScript too so that you can avoid the C in CSS, the cascade and just tightly scope everything to components and individual pieces so that styles wouldn't bleed over from one thing to the next. And all of this JavaScript has this really nasty kind of effect of slowing down performance of the frontend of your site because like a hundred kilobytes of JavaScript is not the same as a hundred kilobytes of CSS or a JPEG or HTML. It's a lot slower for the browser to parse and compile and actually do stuff with, just because of how browsers work. And so, you also see this thing where single page apps have gotten a lot more popular where rather than having to download all the things on every page load, you download them once and then you just update the stuff that needs to change in the UI every time someone clicks something, which means you're now recreating all this stuff the browser gave you out of the box in terms of routing and shifting focus and handling forward and back buttons. You have to recreate all that with JavaScript. And so, you're solving performance problems that were created by JavaScript with even more JavaScript, which is the most fragile part of the stack because it doesn't fail gracefully. If a browser encounters an HTML element, it doesn't recognize, it just treats it like [inaudible] and moves on. If you have a CSS property that you've mis-typed, the browser ignores it and just keeps handling the rest of the CSS file but ignores that property. But with JavaScript, if you like mis-type a variable and then the next line just kind of like wraps over by accident or you forget a curly bracket, and JavaScript automatically adds a semi-colon for you, the whole thing just kind of falls apart. The JavaScript file stops running and anything that happens after that never happens. So for me, modern, a better approach to web development is one that is more lean, more narrowly focused on just the things you need. So that means a few things. For me, that means that old doesn't mean obsolete. I think as an industry, we're kind of obsessed with bright and shiny new objects. Honestly, it's part of what keeps this industry so exciting. It's one of the reasons why I fell in love with web development. There's always something new to learn if you want. But it's also a little bit of what fuels that sense of not being able to keep up, that burnout, that feeling like as soon as you've learned one thing, there's three more things you have to go learn. And so just because a new technique comes along doesn't mean you have to immediately ditch the old way of doing things for the new thing. Sometimes old is actually better. It comes with better backwards browser support so you don't have to worry about how you're going to handle the newer devices. Sometimes, it's more performant because it's been around longer, so browsers are better optimized for it. I guess I kind of start with that. You don't have to ditch the old way of doing things just because there are newer ways, but the first principle for me is embracing the platform. So I think kind of almost out of impulse these days, we tend to reach for libraries and frameworks even though there may be things baked into the browser that do what we need for us, I still run into a lot of people who don't realize that the dom manipulation stuff that used to be really hard and is why jQuery exists is actually pretty easy in Vanilla JavaScript these days. So things like getting an element and manipulating classes on it or injecting some HTML into an element. Those things are pretty trivial today. They used to be a huge pain five or six years ago. Really easy today, great browser support. In some cases, the Vanilla JavaScript versions are actually even smaller and simpler. And I mean, you can cut out quite a bit of JavaScript that you would otherwise need. A lot of times today there are actually HTML elements that do things that used to require JavaScript. Disclosure components, expanding and collapsing things, you can now use the details and summary elements for those. And on browsers that don't support them, people just see all the contents. So you've got built-in progressive enhancements. Right now, there's a spec in the work for lazy loading for images. You won't need to use a JavaScript plugin for that anymore. CSS can also handle a lot of stuff that JavaScript used to. Oftentimes, more performantly. Most notably, animations used to require heavy JavaScript libraries. And you can do some really, really amazing stuff with just CSS in that regard today. Animated scrolling down to anchor links, making elements move around on the page, and the CSS animations are tied really tightly into browser refresh rates. So you get these really smooth animations without needing to mess around with any JavaScript at all, which is awesome. So, that's one piece of it. The other piece is thinking a little bit more small and modular. We have this tendency to like kitchen sink our development sometimes. So, let's pull in all the modules, all the libraries, all the frameworks. The analogy I like to use is we always grab that multipurpose utility knife when sometimes all we need is a pair of scissors. And so, I've seen people like pull in all of jQuery or all of lodash just to toggle some classes on an element or use a couple of helper functions when you may be able to just grab a helper function that [inaudible] you need and is a fraction of the size instead of loading 30 kilobytes of JavaScript. Similarly with libraries and frameworks or with the frameworks like the big ones, React, Vue, Angular, there are some very lightweight alternatives that do similar things. You've got things like hyperHTML, which is less than a kilobyte after minifying and Gzipping and provides a state-based UI experience for you. If you really love React, there's Preact which is only three kilobytes instead of 30 and has the same modern API as React, missing a couple of features that are less often used. And also most notably, missing the virtual dom but it gives you that same syntax and is a fraction of the size, so it's going to load, parse, and compile a lot faster and just get you kind of implementing code for your users that much faster. Now, there's also Svelte which gives you a React-like experience and then just compiles down into the Vanilla JavaScript. So all the end user gets is browser native goodness. And then the last piece for me is remembering that the web is for everyone. I feel like a lot of times because we are often using high end computers, the latest mobile devices, fast internet connections, we forget that that's not the experience for a majority of web users. And we build these things that work just fine on our machine. But for the people who are actually using the things we build are painfully slow, painfully prone to breaking. For users who have disabilities, permanent or temporary, they are sometimes difficult to use or unusable. Frameworks compound this because of kind of the 'we'll just grab a plugin for that', 'we'll just grab a module for that' kind of mindset. A lot of times the people who are building these things haven't built them with accessibility in mind and so we're dropping things into our sites that don't work for people who are on screen readers or navigate a keyboard. And so, there's a lot of resources we can kind of use to maybe be a little bit more thoughtful in that regard. I just threw a lot at you guys. I'm really sorry. We can unpack this and dig into any of these areas you want. I've been talking for a long time. I'm going to shut up now. So if you guys have questions, I'd love to kind of dig into some of this in more detail. JACOB: No, it's good. This is all good stuff to talk about. REIN: There's a lot here, but that's good. I'd like to unpack one specific thing you mentioned, which was CSS and JS. And specifically around how we've taken a thing that was designed for humans to write and to be delivered directly to the browser, which is the original cascading style sheets. And now you have tools like CSS blocks, which basically they've built a compiler for CSS so that they can have an arena in which to do the optimizations they need to make the way they want to write CSS performant because if they didn't have that, every element has hundreds of classes on it with lots of duplicate properties and that would slow down the parsing and the rendering and all sorts of things. And so they've solved a problem, which is we want to be able to write CSS in this certain way that is different from the way you can do it sort of natively. But in doing so, they created this problem, which they then had to solve by effectively writing up a pretty sophisticated compiler for a thing that's designed to be just written natively and delivered natively to the browser. CHRIS: Absolutely. So as you noted, the problems that CSS and JavaScript and similar tools try to solve are real problems. Like if you're on a bigger team or if you're working on an app where different teams touch different parts of it, it is really easy to end up with a lot of duplicated style properties, colliding style properties, sometimes dead codes, you write code that was intended for a specific component that eventually goes away and then the code gets left behind. And so you end up with these really giant bloated style sheets. So I 100% understand why these tools exist. The bigger problem for me -- so there's two types of web bloat. The one I'm usually most concerned with is the kind that really impacts the end user. So when we ship a ton of JavaScript down the wire, that's really bad for the end user. If we use JavaScript to write CSS and then it gets compiled by half the time and then with the CSS gets shipped down, that doesn't necessarily affect the user, but it can have a really negative impact on your internal development teams. I don't think a lot of folks always think about that. So, a lot of these tools were written for, they're designed for people who prefer to write JavaScript. I talked to a lot of JavaScript developers who find -- and the idea of like a JavaScript developer, like someone who just codes in JavaScript or whatever. Most people know -- or not most people, they know a little bit of CSS. But I know a lot of people who focus on JavaScript who find CSS confusing because it's written in a very different way than JavaScript and vice versa. This holds true in kind of both directions. A lot of these CSS and JS tools were optimized for people who prefer to write JavaScript. And in my experience, those people are often not CSS experts. They've just been tasked with doing some styling for the things they're creating. And the knock-on effect of this is that for people who specialize in CSS, accessibility, user interaction design, where they used to be able to participate pretty meaningfully in the development process, they oftentimes are no longer able to because their specialty is not JavaScript and they struggle with authoring CSS in this fashion. I think a real example of this for me happened towards the end of 2018. Accessibility Consultant, Rian Rietveld, resigned from her position as the WordPress Accessibility Team Lead and documented [inaudible] really detailed article. The TLDR of it was that WordPress' new content editor, Gutenberg was built on React. And because of that and because no one on the accessibility team had React experience and because they couldn't find any volunteers in the accessibility community who did, they couldn't work on improvements themselves. They use to be able to just go in and fix things and now they couldn't. And this made it really difficult for Rian and her team to do the work they were tasked with doing. They'd have to push tickets, which would just get added to the backlog and hopefully they get taken care of. Oftentimes they don't because the team is focused on pushing out features, not fixing accessibility bugs. You know, one of those 'it doesn't affect me, so I'm going to focus on this other thing instead' kind of thing. And it got so bad that in May of 2019, there was an accessibility audit done on Gutenberg that found, it was a 329-page report, the executive summary alone was 34 pages long and it documented 91 accessibility related bugs in quite a bit of detail for a product that had already shipped and was being used by the public. And just as a refresher, WordPress powers like a quarter of the web or 30% of the web at this point. So this is like a really big deal. So these tools have this like gatekeeping effect. The more Javascripty our tool chain is, the less people whose core competency isn't in JavaScript but who are critical to the success of your application, get blocked out of participating in a meaningful way. They have to go through the JavaScript developers to do stuff. And that sucks just from like an internal success of your app perspective. And just related to that, I feel like a lot of times the argument around using these tools is that they let our team work faster, we can do more so we can focus more on creating things that user's are going to love. That may be true in one regard, but then I feel like it often gets balanced out in another by blocking a whole suite of internal stakeholders who are not your JavaScript developers from doing important stuff, which is I think kind of what you were getting at. I just said it in like 100,000 more words. REIN: It also creates a sort of monoculture if everything is JavaScript in your organization. CHRIS: Yeah, absolutely. One of the things you'll see happen with organizations that have a very JavaScript heavy tool chain is even if they didn't start off that way, over time the team becomes largely or exclusively developers who are primarily focused on JavaScript. And you end up with this situation where if you're a hammer, every problem looks like a nail. I've seen applications where people create really complex JavaScript solutions for things that could very easily or more easily be handled with CSS or HTML. And in the long run, that ends up creating experiences that are actually worse for the end user even though they feel really clever. They're very smart solutions, they're just not necessarily the best solution. So, 100% agree on the monoculture. Again, I really want to be clear here that I'm not like, "Rah, rah, JavaScript is bad." I love JavaScript. I use it all the time. It's just to me, it's one third of the stack and it happens to be the most fragile and the most kind of performance damaging to work with. And I think we just need to be more mindful of that when we bring it into the things we build. And again, I've totally built things that were largely powered by JavaScript. There are times where that's appropriate, just maybe not throwing 300 plus kilobytes of JavaScript at sites would be a good start. REIN: I think to be fair and balanced, we should probably point out that when a lot of these things were being created, the standards that would enable this sort of stuff, like web components, weren't really there and web components is still sort of not there. And so, React in some of these things exist to fill a vacuum, which is the need to deliver these rich, highly interactive sites based on what was available when the need existed. CHRIS: Yes, absolutely. That is fair. One of the other things that I often see talked about in the context of like React , Vue, et cetera, is the notion of development at scale. There's kind of this belief that if you're going to be building applications that deal with large datasets or large amounts of kind of UI elements or large amounts of users, you need to use a framework for performance. And there are situations where that can be true. So like really dom heavy apps like Facebook or Twitter or like QuickBooks online or whatever, that may make sense. I think most of us, as much as we'd like to think we are, aren't usually building apps of that scale. And so, we're picking tools that were oftentimes built for a very different use case than ours just because there's maybe sometimes a little bit of that like, "Well, if it's good enough for Google or if it's good enough for Twitter, it must be good enough for me," kind of thing. REIN: That reminds me of like the Google hiring process, which was Google thought was good enough for Google, but it was designed specifically for the scale of problems of being Google. And then every early phase startup in San Francisco started using it and then Google was like, "Actually, it doesn't even work for us." But then the startups just kept using it. CHRIS: Yeah. And you see that with frameworks, right? It's one of those like, "Everybody uses them, so I should too." JACOB: The real developers use them. CHRIS: Real developers use them. JACOB: The cool ones that give keynotes and have the -- REIN: [Laughs] CHRIS: These tools do amazing things. Sometime last year, I decided I wanted to better understand how things like Vue and Angular and React work under the hood. So I tried building my own. It's this open source project now called reef that you can dig into. But I just wanted to better understand like the mechanisms behind how all of this stuff works. One, it gave me a much better appreciation for the sheer amount of engineering that goes into some of these tools. They are just brilliant pieces of engineering. But it actually gave me an even greater appreciation for tools that manage to do the same things with a much smaller footprint. So I'm really impressed with tools like Preact which boil that same API down to a much smaller footprint as well. And I think there are definitely things we can learn from these bigger tools even if we don't use them in every project. It's almost like an impulse reaction. We reach for kind of these standard set of tools even when they're not the right choice for the thing we're building. JACOB: I've been thinking about silos of technology. You were saying before how if I have a JavaScript developer who's writing JavaScript all day, they might not implement a solution when they could do it in just CSS, for example. And I've been thinking about that as well because I could see also a scenario where like, a JavaScript developer is giving a task and just like you said, they think that their only tool is JavaScript. It could also be a situation where they're afraid to write CSS because it's like, "Well, I'm not supposed to write in CSS. I'm a JavaScript developer, that's someone else's job. I don't want to do it wrong. I don't want to look wrong." So then they go off and they solve it in JavaScript. And then no one who's an expert in CSS, no one who knows a lot about CSS on the team reviews the code because it doesn't have CSS in it. And so, just sort of further in trenches those silos when there are these sort of boundaries between "I'm supposed to solve my problem in my own language". CHRIS: Yes, absolutely. I want to be a little bit cautious to paint this idea that JavaScript developers don't know CSS and vice versa. I'm a little bit wary of the idea that someone can be a real deep expert in both just because the kind of the approaches to writing CSS are very different or the kind of just the syntax of it is so different that I feel like when you go really deep into one, sometimes you kind of soften up just a little bit on the other. But there are definitely people who are very competent in both. So this is like #notalldevelopers I guess kind of thing. But yeah, I think that's a really good point. A lot of times, these silos emerge. Oftentimes even just because of the way teams are structured. And then you get into some of the gatekeeping we were talking about before where if someone who's a deep CSS expert comes across CSS that's written in JavaScript, they can't really effectively debug it or review it, and so it never gets reviewed. Yeah, I agree. REIN: It's interesting for me to think about the complexity of these systems and how it arose, why it's there, given that Vanilla JavaScript is, and I think you would agree, simpler than React or Angular. There's a sense in which complexity is evidence of success, which is to say that when you're existing in a complex environment and solving new challenges, to do that successfully, you have to become more complex. But that doesn't necessarily mean that that complexity is warranted in other contexts. They are different from where it originally arose. Like you said, React was invented to solve Facebook problems with scale, with complexity, and these sorts of things. But not everyone has Facebook level complexity problems. So they don't need Facebook level complexity solutions. But the complexity itself isn't bad. It's necessary sometimes, but it's contextual. CHRIS: Yes. And I don't mean to be flippant here because there are definitely times where things legitimately are complex and require complex approaches and solutions. But a lot of this sometimes to me feels like a design problem. And I don't just mean strictly from a visual design kind of thing. But humans are really good at making things complicated. It just seems to kind of generally be a superpower of our species and it's really hard to make complex things simple. Our industry seems to have kind of this move fast and break things culture that oftentimes lends itself to like -- what am I trying to say? When you're trying to push things out the door as quickly as possible and there are like business pressures that drive this too, but when you're trying to push things out the door as quickly as possible, you will see products and systems over time get more and more complex. And you can look at that and say, "Yes, this has to be this complex because we've grown and we're scaling, we have all these new things." But it's I think periodically worth stepping back and looking at what you're doing and asking yourself if it has to be that complex. Are there simpler ways to approach this that would actually do the job better? Is it really better for our user if we add these features or does it just make what we're building harder to use? And I'm speaking in really vague generalities right now. And sometimes the answer is yes, it does need to be that complex. And yes, it is better if we do this, but I think sometimes it's worth stepping back and just reevaluating what you're doing and if the approach makes the most sense. In many ways the lean web is like a slower web. It's a more thoughtful web. It's a web where we're not just constantly pushing out more because that's what, I don't know. I'm going to get a little like a little like hibby dibby right now, but that's what kind of capitalism or consumerism demands is like there's more, more, more, more, more. And I don't know that that's always the best. I'd almost love to see us focus more on quality over volume, both in the things we make and the way we build them. REIN: Well, you're not going to get an argument from me on that point. [Laughter] CHRIS: No, no. This is the tough thing with being among kindred spirits. It sometimes makes for a less interesting podcast because they're like, "Yes, I agree." And I agree. These conversations are sometimes more interesting when I go chat with folks who are die hard, like, "Frameworks are the best." REIN: There's a thing you said which has to do with finding simple solutions to this complexity. And I would like to challenge that a bit by pointing out that first of all, complex systems aren't, what's called by James C. Scott synoptically legible, which means basically understandable in brief. You can't glance at a complex system and see it and understand it, but they're also not vulnerable to analysis. You can't analyze a complex system down to its individual components and interactions and then understand the system. And so when you come up with a simple solution, there's also this idea that the variety in that complex system has to go somewhere. And if you have a simple solution to a complex problem, some of the variety in the problem won't be accounted for by the simple solution. But what simple solutions generally tend to do is they hope that the stuff they don't account for doesn't really matter in some way, if that makes sense. And they don't have to account for it. The people that designed these simple solutions effectively hope that the stuff that their simple solution can't deal with doesn't matter and they don't need to worry about it and the simple solution will work in the cases they care about and do something okay in the cases that they can't understand. CHRIS: I think that's totally fair. This almost in a way, this kind of I think gets back to the picking tools that solve the problems you actually have. So, a simpler solution may not address problems you actually have, in which case a more robust offering might be a better choice. There's a little bit of a like 'no one ever got fired for hiring IBM' kind of thing going on with frameworks. REIN: Right. One of the challenges is that like you can't know whether the simple solution will work without putting it in place, without actually seeing what it does in the real world. And that's risky. You can't analyze, because you can't analyze a complex system, you can't analyze whether simple solution will work. You won't know until you see what it really does in the real world. So you have to design for the possibility of catastrophic failure. JACOB: And the sort of the pressure of capitalism is to assume that you're inevitably down for Google level scale. Like hockey stick growth. REIN: Yeah. JACOB: And so obviously, if we don't need React now, we will because we're going to have lots of users. CHRIS: I mean the reality is most apps and businesses never get there. I think for me, the second thing is and when I think about this, in my experience, most apps when they start to see that kind of growth, at some point there's usually some sort of like refactor or -- I don't want to trivialize the amount of work that goes into a refactor. But if you're really seeing this kind of [inaudible] growth, there's a good chance you're going to want to retackle your code base at some point anyway. REIN: There's always some inflection point where the things that got you here won't get you there. CHRIS: Right. Even if you built it in React in the first place, as you start to see an expanded user base, you're going to start to realize that assumptions you made building for an audience of three were wrong for an audience of 100,000. And you're going to need to go change a whole bunch of stuff. And whether you're refactoring the code base from React into a different kind of approach with React or from Vanilla or some other tool into React, you're still refactoring and a lot of stuff is not going to be reusable. One of the things I love about Vanilla JavaScript and frameworks like Vue or React is a lot of it carries over. Like you can use Vanilla in React. You can use Vanilla in Vue. So that's a big part of the reason why I advocate for Vanilla so much is it minimizes some of that pain when you do refactor, but not all of it. But some of it. REIN: You were talking about, there's going to be a point where you may have to refactor or change the code or the way the system works because the way it scaled, the way it evolved over time wasn't something that you predicted. I think that maybe one of the advantages of Vanilla JavaScript or a more minimal approach is that it's more easy to understand. And so when you need to change it later, it's easier. CHRIS: I find that I also find a lot of people disagree with me. Those people usually seem to be people who are already like deeply entrenched in the framework landscape. I'm just going to argue with myself here for a minute. But one of the other things I've heard people argue about is, or arguing against me with is, you're writing Vanilla, you're really just creating your own poorly documented homegrown framework. REIN: [Inaudible], right? CHRIS: Yeah. And that's always felt a little disingenuous to me because the framework may be well documented, but the app you're building on top of it is only as well documented as you document it. For anything you want to do in React or Vue, there's usually at least a couple of different ways you can approach it. My buddy, Brad Frost, was complaining last year about how one of his biggest challenges learning React was every time he Google how to do X in React, he'd get eight different articles telling him eight different ways you could approach it. And he never knew which one was "correct". So just because you've written something in React doesn't mean that the app built on top of it is automatically also documented by extension. You still need to document what the code you wrote does, why it works the way it does, or what's going on under the hood. And so, if you're authoring something in Vanilla JavaScript, those same rules apply. You've got the browser native code that's documented. I mean, this is the one thing I will say about Vanilla JavaScript is like there is no one source of documentation. The W3 specs are impossible for normal people to read and MDN is great but a variable quality. But assuming you have someone who knows how Vanilla JavaScript works, the app that you're building with it still needs to get documented just like it would if it were in React. So if you don't document your Vanilla JavaScript code or you don't document your React code, does that mean the React one is just inherently easier because it's in React? I personally don't think so. I just think it seems a little disingenuous to be like, "Oh, you built your own framework that has no documentation." REIN: I think one of the arguments along that line that does make sense to me is if React has been proven to scale way more than you're ever going to need, then when it comes time for you to scale, the thing you won't be doing is ripping out the framework bits. CHRIS: Sure. That is fair. The thing with the whole -- I also think there's maybe a little bit of a -- like, even if I never get to that level of scale, it's better to have the insurance. It's like, the person who goes on vacation and packs for every possible situation they could run into versus having to just figure it out when you're there. "It's not supposed to rain while I'm going on vacation, but let's pack a raincoat and an umbrella anyway just in case," versus you're on vacation and it rains, well now you're going to go out and buy those things. I think for me, kind of the inflection point here is who do you want to have to pay for that unexpected incidental? Do you want to pay for it as the developer? Or do you want the user to pay for it? So if I write my application in Vanilla and then I eventually hit this level where it doesn't really work and a framework would be helpful, I, as a developer, need to pay that tax of converting it to this new system. If I throw React or Vue in there and never actually need that level of scale, my end users are paying the tax of that extra code that has to get sent down the wire and the extra abstraction every time they use my application. So, I've really just shifted costs from myself to the end user. And I think for me, that's kind of where my big argument in favor of moving away from some of this stuff comes from, is I don't think it's fair to make users always pay that tax for our own convenience. REIN: Another counter argument to the argument I just made is that React itself is designed with on-ramps for people moving in this direction. I've worked with a number of teams that have moved from not React to React in small incremental steps. They've injected React to do this one part of the larger page, for instance. And they just keep doing that until they don't have the old stuff around anymore. And it actually works okay. JACOB: That was always supposed to be the idea. I remember when I was learning it maybe in five years ago, that was the pitch, you don't have to make a full switch, you can put it in incrementally. And somehow we sort of lost track of that. And then it might be just sort of, there are so many people that have started becoming developers in the last, I don't know, three years that the understanding of React doesn't have to be from the very beginning. REIN: I think another flip side here is the flip side of, there are eight different ways to do routing in React. There is a large community of practice where you can find people who can suggest ways to do things. Even if there are eight of them, that's certainly better than zero suggestions. CHRIS: Yes. The the community aspect is definitely an important one. REIN: That's not a technological problem at all. CHRIS: No. Honestly, I think a lot of the tech that we throw at the way we build sites is us trying to solve people problems with tech. But no, you're right. I think one of the byproducts of React being such a dominant player in the market is there are a lot more solutions, either prefab third party things or people who can answer questions, otherwise. Just from my perspective, I'm starting to see more people emerging around Vanilla JavaScript. Like a year ago, I used to see really negative sentiments around it on Twitter. And I'm actually starting to see kind of the reverse of that happen now where you're getting a lot more folks talking about how refreshing it was to drop the heavy tool set. But we're not there yet in terms of this large robust community of Vanilla JS folks who can just throw tools and things that people whenever they get stuck. So, I would agree with that. And I also really like, Jacob, what you were just saying about kind of the, and Rein did too, about moving gradually. I have a lot of students who come to me having tried to learn React and just getting really, really stuck because they're new to their career and every job description says React developer, React developer, React developer. So, they go to learn it and they just can't figure it out. So even if you think you want to eventually dig into a framework, I still think it's worth knowing native JavaScript. I've had a lot of students who have failed the React come to me, learn some stuff and then gone on to learn React and be like, "Oh wow, this all makes sense now because I understand what it's trying to do under the hood." And so, it clicks a lot better. And I think that kind of dovetails nicely into what you were saying about gradually migrating the code base over. JACOB: Again, I'm going back to about 2015 when React was just starting to take off. CHRIS: Oh man, I cannot believe it was five years ago. JACOB: I know. [Laughs] I remember when I was writing React to create class. It's amazing. And now, it's like I'm in trouble when I write a class component at all. I mean, maybe for good reason. But anyway, I remember I feel like I saw this on a lot of blogs and just everywhere, the phrase, "It's just JavaScript," when they were talking about React. Particularly the word 'just' is like down under the hood, it's just JavaScript, which I feel like is [obfuscating] a lot because the virtual dom is just JavaScript, but that is really underselling the amount of complexity that's going on. I guess this sort of gets back to the complexity versus simplicity stuff that Rein was talking about. It may look intimidating, but it's actually simple. If I'm new and I actually find it intimidating and you're telling me that really it should be simple, that doesn't feel very good. CHRIS: When I see that term, it's usually used, I don't want to say patronizingly, but it's almost used like dismissively. So if I talk about how Vanilla JavaScript is more performant, "You know, it's all just JavaScript under the hood." Well yeah, but it's a lot more JavaScript with a lot more abstractions that adds many layers of latency to certain tasks. It speeds up others, like DOM diffing and the virtual DOM are brilliant. But getting all that JavaScript down the wire, like it's just JavaScript that just happens to be an extra 30 kilobytes of it [crosstalk]. REIN: Gerald Weinberg calls 'just' a lullaby word because what it's designed to do is to get you to fall asleep for the rest of the sentence. JACOB: [Laughs] CHRIS: Yeah, that's a good analogy. Love it. REIN: And he suggests instead paying much more attention to the rest of the sentence and also replacing it with words that mean the opposite. So another lullaby word is 'it should be easy too'. And what you do is you replace that with, 'we will have great difficulty too'. [Laughter] CHRIS: It's also like, as Jacob was just kind of alluding to, if you're someone for whom this is not as easy as the sentence makes it seem, you may come away feeling like you don't belong or that you're too stupid to get it. I talked to a lot of beginners who are like, "I keep reading all these articles that say you just do this. I simply need to do this and I'm just not understanding it and I'm starting to think maybe I don't have the mind for a developer," and that is such garbage. There are people for whom maybe things come a little quicker. But I fundamentally disagree that there are people who are just not wired for this. I think I can teach anybody how to code whether people enjoy it or not is a totally different argument. But if you're not understanding something, that's not your fault, that means the way it's being explained to you is bad, if for lack of a better word. REIN: Good technical writers don't use that framing and good technical editors won't let writers do it. So Brian Hogan is an editor at Pragmatic Programmer which is a great publisher and he's very sort of outspoken about do not say something is easy because if it is not easy for that person, they will think something is wrong with them and then you hurt them. So don't do it. CHRIS: It's such a common phrase to use casually in conversation that as much as I try not to, it still occasionally slips into my writing and my talks and stuff. I try to be mindful of it, but yes. REIN: The interesting thing is I think the goal of using it as the opposite, you want to indicate to people that, "Hey, you can do this." But actually the intended result is not the actual result. And what matters more is the actual result. JACOB: I felt like just like going back, sorry 'just', going back to the example of React again. I think one of the reasons why, and I would love to hear you talk about this too, the pain coming from trying to go straight to React. For me, what made it click was when I understood what frustrations and problems React was trying to solve. And so, I sort of feel like if you're a beginner and you don't understand React, go off and try to manage state manually by yourself for a little bit and understand the particular pain points involved in that. And then when you can go back and see, "Oh, I see how React is trying to help me worry less or it's trying to help me organize a little bit better around that problem," it might click for you a little bit better. CHRIS: Yes, absolutely. One or the other, just along those lines, just the concept of state in general confuses the heck out of people who are not used to writing code that way. So if you're just new to development in general or you used to do a lot of manual DOM manipulation, even the word state, I've broken it down, I'm like, "State is just data at a particular state and time." And they're like, "Oh, that makes perfect sense now." And again, I used the word 'just' in there. But state is data at a particular state and time or point in time. "Oh, I get it now." But yeah, you're absolutely right. I've had people who don't really understand why someone would want React and then when you try to do state without it, they're like, "Oh, I can see how this would be helpful." REIN: There's an interesting thing -- CHRIS: Now I'm arguing in favor of React. REIN: [Chuckles] I think it's more about being aware of the context. But there is an interesting thing that just happened to you, which is you used just, but you used it in what I think is a subtly different way that's really fascinating to me. I think the way you used just was to indicate that the thing that follows is an oversimplified model of a complex phenomenon. CHRIS: Yes. REIN: It's 'just' changes in state over time. It's not just that, but if you think about it that way, it's a lie that will help you. It's a lie we tell the children. It's Wittgenstein's ladder. It's a model that's wrong but useful. And I would like to find a way to separate out that use of just from the one that intends to diminish the thing that comes after it, like we were talking about before because I think that use of just is actually quite useful. JACOB: Well, it's the acknowledgement that you're pointing at a model and not the thing itself. REIN: Yeah. JACOB: If you're going to say just and not acknowledge it, say like, "Look at this ship in a bottle. Do you want to go sail it in the ocean with me?" [Laughter] JACOB: And then you're asking the listener to drink the Koolaid and believe that the model is the thing. REIN: I have been using 'it's kind of like' instead of 'just' for this. So I would say, "It's kind of like state the changes over time." CHRIS: I like that a lot. One of the other things that comes up when I talk about kind of this more minimal approach to building for the web -- by the way, one of the other things I really would love to see, it's starting to grow in popularity a bit, but one of the things I'd love to see us doing more of is static HTML. I absolutely love websites that are flat HTML files that get sent back from the server and are maybe sprinkled with a little bit of JavaScript pixie dust to add some interactivity as needed. It has, in my experience, made the web a lot faster and I'd like to see more of that. REIN: An interesting thing that's happening with some tools like Gatsby is that they're sort of taking what was intended to be an interpreter that runs on the browser and they're turning it into a compiler. This whole, what's it called? Isomorphic, which is always a weird word for that. But the idea that you can actually just render all these pages on the server and then send them over, but you're using the same technology. CHRIS: Yeah, absolutely. That is maybe a kind of a closing conversational topic. Whenever I talk about this way of building for the web, that often maybe seems a little bit more like the way we used to do things a few years back. Even for people for whom this resonates, I usually get the question of, "Look, this is all great, but do companies actually build for the web like this?" Because at the end of the day, I need a job. I need to be employed that's why I do this. It's not just a hobby. I need money to buy things. And the answer is yes. There are absolutely companies that do this. The caveat is not as many as I personally would like and I don't think we're really there yet. I do see the pendulum starting to shift a little bit, but there are some bigger companies that you have definitely heard of that build like this. So, most notably GitHub last year, I guess actually maybe it was 2018 at this point, but they finally removed jQuery from their web stack. And instead of switching it or replacing it with a framework, they decided to instead use Native JavaScript or Vanilla JavaScript and custom web components. And they wrote a pretty detailed blog post about it and why they went that approach. But it has resulted in an application that is a lot more resilient and stable than if they didn't use that approach. Even things like commenting, opening issues and so on, are static HTML with server rendering that is then augmented with Ajax, JavaScript so that it can happen snappier and faster if your browser supports it. But if that JavaScript file fails for some reason, it just doesn't -- oops, did it again -- it does an old fashioned server submit and still handles the thing you were trying to accomplish. So it's very resilient, which is great. Also notably that same year to late 2018, Netflix ripped React out of their client side initial page load, replacing it with Vanilla JavaScript and they found that they're loading and time to interact had decreased by 50%. So, substantially faster initial page loads for their users. They're still using React for server-side templating, but their frontend now comes through as pre-rendered JavaScript, just Vanilla JavaScript and it had really good performance wins for them. Another one I haven't been able to -- I heard from a developer at Marks and Spencer that they are still using Vanilla JavaScript. This is a big retailer over in the UK. I haven't seen any sort of public acknowledgement of that in the form of like a case study or article or anything, but one of their internal developers told me about it. And then there's a handful of other smaller companies that do this too. But I still see tons of job descriptions saying we want Vue, we want React, we're looking for a framework developer, that sort of thing. The flip side is I am also starting to see maybe more 'we're looking to simplify our stack', so I think the pendulum is maybe starting to shift to somewhere in the middle. And I think for me, that's the big thing. I don't think the answer is everybody does Vanilla JavaScript all the time either. I think there's like a happy middle ground that uses smaller tools and selective bundles and packages and maybe has a more lean system that is not 100% Vanilla, nor is it all in on these bigger frameworks. REIN: I've been trying to sort of put together in my mind what is the value proposition for Vanilla JavaScript as we've been talking and it seems to be there seems to be a lot there. One of the things is that it's easier for new developers to learn. For example, JavaScript plus React. Another is that learning JavaScript provides the sort of understanding that makes it easier to use then to learn then React or Angular or Vue or whatever. Another is that as you just demonstrated, Vanilla JavaScript or JavaScript plus a few carefully chosen packages and so on, has a pretty long potential lifespan. You can get pretty big with it if you need to. Another is that when it doesn't work for you anymore or you have [inaudible] that are feasible so moving to React, for example, is pretty feasible. So, you're not painting yourself into a corner by starting there. CHRIS: I think that's really fair. If I were to condense it down to just a couple of things, it's ease of beginner developer on-boarding, allowing non-JavaScript developers to participate more meaningfully in your process or even just non-developers who are part of kind of the overall kind of engineering, like UI designers and accessibility consultants and things like that. And then the third is just overall resilience and performance for the end user. Those are probably the biggest things for me. It's going to give you a finished product that maybe breaks less often and is kind of snappier and more performant for the people using what you've built. REIN: I think it might also be good to sort of, I'm sure you've already done this, but in my mind it's sort of happening on the fly. Break this down into a few sort of different contingents of your target market. So, there's new developers, then there's startups who want to be able to do interactive stuff but also worry that they may become the next unicorn. And then there's established companies with large, highly interactive sites that they need to support and they each have very different needs. CHRIS: That's a good point. I don't know if I'd be prepared to do that right now on the fly, but I like where you're going with that. Just thinking about it out loud though, startups are a very unique kind of beast. They are usually bringing in people who they want to do a little bit of everything, who they expect to work crazy hours and deliver maybe inhuman kind of results. And for those people, given the constraints of the business, I think sometimes just grabbing an off-the-shelf framework and slapping together a bunch of pre-configured components and then building like a minimum viable product maybe actually does make the most sense, maybe not for the end user, but from an internal kind of perspective. It's almost like if you don't do that, the thing won't exist before the money runs out or before the investors get angry. And so for me, startup land is a very kind of unique and specific microcosm that maybe differs from everybody else. REIN: That's really interesting because that would imply that early stage startups might get more benefit from React than late stage startups, but the transition between them is asymmetrical. People go from Vanilla JavaScript to React. I don't know that a lot of people that are on React go back to Vanilla JavaScript. So if you start there as a small startup, you're probably going to be there forever unless you move to something sideways or more complex. CHRIS: I think the bigger thing here is less about tool selection and more about picking the tool that allows you to get moving faster. So for me, in that situation, that would absolutely be Vanilla JavaScript. For someone else, that might actually be jQuery. For another developer, that might be React because that's the tool they do most of their development in already. I think the one that is less likely to give you more headaches down the road is to start Vanilla and then layer in later. But most startups fail. So at that phase in your development, worrying about down the road headaches is almost premature. We, as an industry, sometimes are maybe a little bit too sucked into the Silicon Valley vortex and kind of the startup vortex. And I think it's important to remember that that is only a small microcosm of what actually gets built on the web. I'm just kind of thinking out loud here. REIN: That's good. CHRIS: Like we put a lot of stock -- as thought leaders, like founders and investors are often the big voices of the industry. But I don't know that they really represent a majority of kind of the industry itself. REIN: I think the elephant in the room that we've mostly avoided, although you mentioned it a little bit before, is that there's probably no ethical choice of JavaScript approach under capitalism and especially not in the absurdly extractive context of venture capitalism. CHRIS: I think that's fair. We can have a whole nother conversation on ethics. REIN: Yeah. You were talking about how people have these inhuman demands in startup. And I would, for them, just say, pick the thing that reduces your suffering the most. I don't care whether it's [inaudible], I literally do not care about any of the technical considerations. Just pick the thing where you'll hurt less at the end of the day. CHRIS: Yeah, absolutely. I think that's a very reasonable, humane approach. You know what I mean? Like if you're really thinking about the human element of working in a startup, which can be absolutely vicious, then yeah. REIN: It seems to me like a pretty big privilege to be able to very carefully consider your JavaScript approach and to take the time to evaluate options and maybe try a few to see what happens and then pick the one that's right for your business. Oh wait, I got fired yesterday. CHRIS: Absolutely. REIN: I guess that's my reflection is that this is all great, but maybe you should focus on the thing that reduces your harm in the short term, depending on who you are and sort of what constraints you're operating under. And good luck with that because capitalism. CHRIS: [Chuckles] Yeah, that's a good way to frame it. REIN: Jacob, do you want to do reflections now? JACOB: Yeah. For one thing, for people who are listening that are just starting to learn JavaScript, I totally feel your pain and I want you to know that it is okay to not learn a framework immediately. And it's also okay, like you're feeling like you really want to dive in to React and build something that you've been thinking about, do that. And then later learn about Vanilla JavaScript. I think there isn't one right way to learn it. It's more of a question of understanding the various levels of abstraction and the trade-offs involved and knowing how to analyze your problem and understand what might be the best approach. And then the other is that when we were talking about -- I was thinking of a book that Noel Rappin wrote recently, I guess it's still in beta and it's called Modern Frontend Development for Rails. If you're not a Rails developer, that's not a huge issue. But if you are a Rails developer, it's probably a great book to read. But what I was thinking of that is that he takes a really great approach that I think is really similar to what we've been talking about is that he starts out with a Rails application that's going to be using some Vanilla JavaScript. And then he starts discussing various other technologies and what they might bring to your project. And then he builds up that exact sample project by layering on first a library called Stimulus, which is from Basecamp. It's a tiny JavaScript library that's about events. And then he adds a React and then he adds TypeScript. And it's really about, he's showing you how you can incrementally add these technologies if they're going to solve a particular problem for you. And to also start thinking about like, what problem do I need to solve and will this technology solve them and will it create new ones? So yeah, I highly recommend that book. REIN: I just want to mention, and I'm doing an example of what I'm about to say, that not every use of just is problematic. So you don't need to police every time we use the word because cops suck. But we should be aware of the potential ways that word can be interpreted. It's okay to not use just sometimes, but you don't need to remove it from your vocabulary. JACOB: I agree. What I've found is I've been trying to be careful and more mindful about that word for a long time because I've found that my usage of it, sometimes the word isn't bringing anything new to my sentence. So yeah, I've been always hesitant about that word. REIN: It's almost habitual, so it's difficult. JACOB: Yes. It's like the word like. REIN: Like actually serves some interesting grammatical purposes that we could get into, but maybe another time. For one thing, it indicates that the speaker hasn't finished their thought yet, so maybe you won't interrupt them. Hey, Chris? CHRIS: Yes. For me, I think one of the more kind of interesting takeaways from our conversation was around the instances where it does actually make sense to use some of these tools. Because I spent a lot of time talking about why you shouldn't and why you don't want to and alternatives for them, some frameworks like React and Vue and whatnot. And I think our conversation around when you hit a certain level of complexity or a certain level of scale was really interesting. I also enjoyed our little detour talking about just minimize your pain aspect of being in a kind of a startup environment where maybe the rules don't quite apply as much there. Although we could have a whole kind of side conversation about that culture and its impact on the broader web. The other big thing I just wanted to say, and I think it kind of echoes what Jacob already said, but if you are learning web development or JavaScript for the first time and you feel like it's just too many moving parts or you don't really have the mindset for this or it's really hard for you to kind of figure out, you are not alone. It's not you and you've totally got this. Don't feel like you have to kind of dive into the latest trends, the new hotness. Your best bet is probably to step back, take it really simple and work on some basics. One of the things we didn't talk about, but that I find comes up a lot is people often try to do one of two things. They either try to jump into a project that is way too big for where they're at. Like building a to-do app when you're just learning is maybe not the best thing to kind of dive into. Or they try to do something too basic. It's important to understand what a function is, what a variable is, what an array is, the differences between them, but it's also really, really boring. It's like trying to learn how to play piano by reading music theory versus sitting down in front of a piano and someone teaching you how to play a song, when you can backfill into some of that other stuff later and it makes the learning experience a lot more fun and interesting. Those are kind of my closing thoughts.