Right, Joel, how are you? Before we get started, can you introduce yourself?

Yeah, so my name is Joel Ramos, and I am a software developer at Microsoft. I just love everything UX and front-end related, so here we are talking about web frameworks today.

Cool, cool. So before we get too far into web frameworks, because you're a developer I like to always ask this question: how did you get started? What was the first app you ever wrote?

Yeah, so I wouldn't call it an app, exactly. I guess it was a console app, right? But I picked up an old textbook that one of my cousins had one random summer night, followed the tutorial, and ended up with a Hello World type of application. I guess the rest is history.

When you say a console app, was it like a Windows console app or a browser console?

A terminal-based kind of application, yeah.

Cool, and what language was it written in?

Visual Basic, or it might have been C#, actually.

Cool. Yeah, that's awesome. And now you're doing web development, or you're interested in web development and all of that. So how long ago was that?

That first console app was when I was a junior in high school, so about seven or eight years ago.

Cool, cool, cool. Yeah, nice. All right, so now let's shift over to talking about web frameworks and all the fun stuff there. What do you want to start with?

So, I recently started working on a team that's using React as our main framework. React is also something I've been learning by myself on the side during college and after work. One day I was going through a tutorial, and the person giving it said two things that really resonated with me: whenever you're learning a new tool, you kind of have to ask, what is the tool, and why does it exist? So I applied that idea to React, and I wanted to explore why React exists, why it's so popular, and what problems it solves. Why did the industry as a whole transition into using frameworks like React, Angular, and Vue?

How were web applications made before? That's also an interesting question. And then, where are we going now? That's kind of what was going through my mind when I reached out.

Wow, that's a lot of interesting topics to touch on. So where should we begin? Should we start with why we have frameworks like React in the first place?

Yeah, sure. I think the right place to start is the history of the web itself. When the web first came out, there really wasn't a whole lot beyond text documents displayed on screen, so everything was heavily optimized around that. If you saw some of the earliest web pages Tim Berners-Lee created, it was just text on a white background, maybe an image here and there, maybe no image at all, plus some links. It was a document-centric model, and that's what the web was really built around. As time went on, it really continued down that path. The internet was mostly known for text, large pages of text, and things like that.

It wasn't until JavaScript, Netscape, and some of these other developments that the technology and the platform evolved to where you could go beyond just having static web content. You could have images, maybe even videos, and plugins like RealPlayer and Flash, which made the browser do a little bit more than it could do before. Eventually you got to the point where you could look at the apps you were building, like desktop applications or even a console application, and think about doing that in the browser instead.

I could maybe make it work more easily in the browser, where there is no installation, or if there is installation, it's just a plugin that everybody on the planet already has, like Flash. So we saw a trend where apps that had traditionally been what we would call big-client, installable apps started to move into the browser and onto the web, and you could do more things through it. That also meant the way you built those apps changed as well, including how you architected a large-scale application. There are some common patterns there, and the web in many ways wasn't really designed for that.

JavaScript was single-threaded, it had limited support in various cases for what you could pull off across different browsers, and ignoring mobile for a second, once you brought mobile into the mix, you had a whole host of things that needed to be better as well. You also had HTML, which had various levels of capability, and CSS, which for a long time lacked a lot of things that a modern visual language would often want. Recently that has gotten better, but over a long period this evolution was messy. As a developer, you had to know what Netscape supported, what Internet Explorer supported, and what other browsers supported.

You had to keep in mind: can I use this capability, and if I do, what is my fallback going to be? So what really emerged was a need to get more things into the web that took the best practices of traditional programming languages and programming architectures, whether on the back end or the front end. We needed more evolution in that space. The other part was simplification. How do you simplify all of this so people can actually build these applications in a way where, if you're an individual, you can be successful, or if you're working with a team of developers, these things can also scale?

A lot of approaches came out of that to figure out the best solutions, and some of them have been more successful than others. We talked about jQuery quite a bit as having been one of the most successful solutions, because it abstracted away what a browser supports or doesn't support, at least from the JavaScript layer and especially around DOM manipulation. It basically said, yeah, just write jQuery and it will figure out whether it's going to use a native API, a polyfill, or something else. Then, as things evolved, you had various other frameworks.

MooTools was really big, and there were also more traditional declarative ideas, similar to how XAML and WPF have data-binding support and so on. The question became: how do we take the best of traditional languages and use them to solve common problems like, I have data, I need to visualize it, and it needs to be interactive? How do we simplify that so a developer isn't spending all this time learning HTML, all this time learning CSS, and all this time learning JavaScript as separate concerns? That's when we started seeing richer frameworks that started doing really well, probably about 10 years ago.

Angular was one of the big ones that really highlighted that it is possible to build mission-critical line-of-business applications, which had traditionally been in the realm of desktop apps. It had rich templating and really nice models for being able to translate your ideas into code that was fairly universal across all the various browsers. That was one of the first big frameworks in that sense. Then, over time, React came into the picture as well, mostly because one of the big gaps web apps still had was composability.

If I'm building some UI that needs to be replicated across lots of pages, it's one thing for it to be something I can copy and paste and make work, which I can always do. It's another thing for it to be a case where I'm building a component, extending it with more capabilities, and using traditional subclassing and classical inheritance-style approaches that aren't just working at the code layer but also work at the UI layer. And also, how do I think about UI development in a way where I'm not thinking about every state change as a bunch of incremental stages and about how I go from point A to point B?

How do I instead think in terms of, my UI looks like this right now, here's what I want it to look like in the end, and I don't really care how the in-between steps happen? I want to make sure I get a performant experience, and I want everything else to be handled automatically. For me, those are really complicated problems, especially when you're thinking about performance and the tree of elements your browser is dealing with. React really came into the picture as something solving that, and the original use case for React was Facebook. Facebook's timeline, news feed, and all these other parts had a lot of elements.

The question was how do we build them as reusable components, make them more composable through other components, standardize all of that, and make teams more efficient when building them? React gained a lot of popularity as one of the first tools that didn't just solve the developer workflow problem, where I'm thinking about UI in terms of actual UI. It also let me represent things not just as a combination of HTML and JavaScript, but using this newer syntax called JSX, which is kind of a mixture of both.

So what needs to be represented in markup can stay in markup, but I can also put imperative code where I need to do calculations or processing. There is also a really nice templating mechanism where child components and parent components can transfer data back and forth. It had a very good model for solving a lot of these problems, and it was also, in many ways, about performance.

React had the idea of the virtual DOM, where instead of every operation causing the screen to update, the tree to reflow, and all these other expensive things, the framework optimizes for the browser based on what is the least painful set of activities we need to do to get a pixel updated on the screen in a really performant way. So React touched both the performance side and the developer-experience side, which very few frameworks at the time did a good job with. And of course, Facebook building heavily with it and also using it for their own products gave it that validity. It wasn't just a hobby.

It was something actively maintained that could solve really big problems, because 99 percent of the time what you're building is going to be far less complex than what Facebook has ever attempted to solve. That really got us from the very beginning of this document-centric world to the world of today, where frameworks like React abstract away many details and help you focus more on building your UI and representing it in a more natural way. That is a lot better than spending all your time figuring out the edge cases you historically had to deal with.

Right. So for folks who aren't too familiar with React, there's the concept of the DOM and the virtual DOM. From my understanding, the DOM is basically the structure of your web page, right? All the nodes and the whole layout live in this tree. Traditionally, before React, to do DOM manipulation you would just use JavaScript. Then that evolved into a more standardized way with jQuery, which had some optimizations for manipulating the DOM because that can be really painful. Whenever you manipulate the DOM, does it cause an entire re-render of the page?

It depends on the kind of operation you're doing. Some operations browsers optimize heavily, and they don't cause a full re-render of the page, and some do. There are a lot of resources that highlight which CSS changes trigger repaint or reflow and which DOM activities trigger more expensive work. At the most basic level, though, if you think of the DOM as just a tree of elements, then changing something at a leaf node is usually not too bad. You add an element, or move something near the edge of the tree, and it doesn't affect the rest of the tree that much.

But if you're further up a branch, or even at the root, then any modification there has a ripple effect on everything below it. Our computers have gotten faster, our browsers have gotten faster, and even mobile devices have gotten faster. But if you think about the users who are going to have the worst experience, maybe someone on a tablet or a low-powered mobile device somewhere in the world, then you have to ask whether the approaches you're using are still good enough for them. So even though our computers are getting faster, our web pages are also getting more complex. It's a constant cat-and-mouse game.

Browsers get faster, devices get better, but the manipulations we're doing involve larger numbers of elements too. Those are some of the things you have to balance.

Right. And then, transitioning to React, we have this idea of the virtual DOM. In simple terms, that's how React is able to calculate the most minimal change it needs to make to update the page. You can obviously see why that's an optimization. We don't need to re-render everything. We just need to look at the virtual DOM, look at the DOM, compare them, see what changed, and then update that.

Exactly, and that's such a huge improvement. Often, let's say you have to make five DOM operations. If you do them sequentially, you might build something, tear it down, build something else, and tear that down unnecessarily. Instead, you can step back and say, here's my beginning and here's my end. How can I minimize the unnecessary, duplicative work I'm doing only because the operations happen sequentially? You can save a lot of time by using a framework like React. React has all that logic in place. I'm oversimplifying it greatly, but it uses a very complex diffing algorithm.

With simple trees that we can visualize, we can easily see that this needs to change here and that needs to change there. It makes sense at that scale. But a page can have thousands of elements at any given time. One part of the subtree or UI may change while another part changes because of something arriving from the server or because of a user interaction. The whole problem space gets really, really complex. I'm grateful that things like React handle so much of that complexity. Otherwise, you and I would have to figure out how to do it ourselves and make sure we didn't do it badly.

One thing to add, especially given the trends we're seeing these days, is that browsers have also gotten really good at optimizing DOM operations. That's why you now see a countercurrent of people saying React may not be necessary anymore, at least from a DOM-performance point of view. The overhead of maintaining a virtual DOM and doing this work may duplicate optimizations browsers already perform natively. React might not provide as much of a performance benefit as it once did. From a developer-experience point of view, though, that value is still very much there and hasn't really changed. React still has JSX and the large ecosystem built around it, including meta-frameworks like Next.

Js that go one level beyond what React provides. But performance was a major part of the argument four or five years ago, and the jury may be out on that now. At this very moment, today, do we still need those performance benefits?

Yeah. So that kind of leads into my next question. We've been talking about how React is so great and how, in many aspects, it's been revolutionary. What are some of its shortcomings, and why have there been enhancements like Next. Js and things like that?

Yeah, I'd say there are multiple ways of thinking about where React comes in, and it's similar to how jQuery evolved, from being something you absolutely had to use to becoming something where your browser now does a lot of those things for you automatically. We already touched on one angle, which is performance. If you're building with JavaScript APIs and you have more capabilities in the DOM and in CSS for arranging data, virtualization, and things like that, then there are cases where React gives you benefits you may not actually need anymore.

A recent example for me is that I had to build a grid of emojis that had about 2,000 icons, or 2 000 or so icons, displayed on the page. By default, if I did not use something like React, it would take a long time to create all those elements and load them. I could use a virtualization library that would only render what I need to use on screen, but those libraries are complex and require a dependency on something else. But now the browser supports the whole idea of lazy-loading images only when they hit the viewport, so I can specify the loading attribute as lazy.

In that case, a 2000-element, or 2,000-element, set of emoji images being displayed takes a fraction of a second, if even that, because it only renders what I need and that behavior is provided natively by the browser. So in an area where I might normally have used React because it handles these things for me, I'm now able to save a 30-kilobyte, 40-kilobyte, or even 100-kilobyte JavaScript bundle from being downloaded. That's one of the bigger things about frameworks in general that people talk about, and something I personally have some issues with. There is often a large download cost.

You're downloading a large amount of JavaScript, and then your browser also has to parse that JavaScript every single time. So it's not just the download size. It's also CPU time, and on a battery-powered device these things add up. We've always seen those statistics showing that the average web page is now bigger than interactive video games from 10, 11, or 12 years ago. Your typical web page might be 10 megabytes, 20 megabytes, or 30 megabytes. It can feel almost unbounded in how large these things get.

So there is this movement, or at least I like to think there is a movement, to say: let's not keep adding more bloat to a web page, and let's try to scale it back down where it makes a lot of sense. That's where you see React and newer alternatives like Vue. Vue is in a position where people can say, yeah, let's take the best parts of React and make it even more lightweight. Then you have Preact, which in many ways takes React syntax but cuts away a lot of what is going on.

So you're seeing a lot of innovation and interesting work from the community around how to address different shortcomings. But what React, and even Vue, really solve well is the single-page problem. I have components, I have a single page, and I want to make sure it renders appropriately. Realistically, though, most of the things we build span multiple pages. You might have, for example, a restaurant site. I might have multiple pages there, page A, page B, page C, and page D. How do I make that work in a more traditional world where I don't want to load everything at once the first time the page loads?

I want to preserve this natural web-like world where I navigate from page A to page B, there is a transition, some state might change, and some state might not. These multi-page applications, which we kind of took for granted as a traditional web thing, never really caught up to how you might build modern web apps in a more modern environment. That's where meta frameworks are what they are for. Meta frameworks like Next. Js and Nuxt come in and say, okay, let's take the great ideas we have for building single-page apps and extend them to multi-page apps as well. That might mean server-side rendering, ISR, or static site generation.

Those are all ways of heavily optimizing around the idea that I'm still building my application as one large, monolithic activity. But what the end user sees is only what they need. Only what they need gets downloaded and used, and that is exactly the kind of thing you're going for.

That's really interesting to hear. I never really thought about it that way. If we do want that native browser feel of navigating from page A to page B to page C, and we're talking about a site with thousands and thousands of pages, do we really want to load all of them in at once? Is that actually the best way to do it? So I'll definitely have to check out something like Next. Js. Like I said, I'm just exploring this framework world, and asking why React exists, what problem it promises to solve, and what its limitations are naturally creates this whole world of exploration and innovation. What is Next.

Js, and how can I make React better? It's really interesting to hear that perspective as well.

Yep, and in parallel the browsers are still doing really good work. For example, if I want to create a single-page app that has the performance of a multi-page app, where things are downloaded on demand but the transition from one page or view to another still feels very native, like I'm animating from one state to the next instead of doing a hard reload, that's becoming more possible. There are newer ideas around the Web Transitions or Page Transitions API that are being introduced, where you can do that without relying on third-party frameworks. So we're seeing this really nice mixture of approaches. Now the doorbell is ringing, one second.

All right. Well, good thing there's always editing, so I can always cut things out. Where were we? Oh yeah, the Page Transitions API. I was actually reading about that a couple of weeks ago, and it felt kind of surprising that it hadn't already been introduced into the web world. It just seems like something that would already be there, or should be there, so that's exciting too.

It does exist, and it has existed in various phases. When Jake Archibald tweeted about this about a month or so ago, I replied with a screenshot of FrontPage 98 from 1998, where they actually let you use JavaScript to create transitions like blinds and checkerboards between pages. So the technology has always existed. The question has always been how to make it work without adding more bloat and more capabilities than we really want. In reality, you're offsetting some of that by making the browser a little larger because it has more capabilities built into it. But you install the browser once, and now you have all of that for free.

So it's kind of like amortizing the cost into the browser instead of pushing it out into every individual framework. Then there are all the other questions you have to revisit. Why didn't it succeed back then? Why does it work better now? How do we make it work on mobile devices, across multiple rendering engines and platforms, and in a performant way? And if the transition is an animation, what happens when the user has reduce-motion settings enabled for accessibility or personal preference? You have to respect all of that. The complications of building browser capabilities just keep increasing with the number of devices and features involved.

Yeah, there's definitely a lot to consider when you're developing a browser that's supposed to render everything correctly on every device possible. For me, that's the exciting challenge of web development, honestly. That's what I enjoy doing.

Puzzle, basically, yep. And I'm still a big fan of just traditional HTML, CSS, and JavaScript. No matter how much I appreciate React and all these frameworks and what they're doing, I keep asking how we can make the web better in general so every developer doesn't have to take on so much extra weight. When you look at the size of some of these frameworks, it adds up. By default, a Hello World app in some of them is like 300 kilobytes, and I'm like, there's something wrong here.

But that's just me, because at the end of the day, if I were on a team or in an organization with an existing codebase that's millions of lines long and built in a particular language, that might shift the balance toward, let's use a framework and simplify things. TypeScript is a good example. Before TypeScript, JavaScript wasn't the best choice for large-scale applications because accidental errors could get introduced and be very hard to pinpoint. Types simplified a lot of that. So I think the real question is how do you make sure developers are productive without negatively impacting the end user's performance? Those goals are often at odds with each other.

I'm hoping one day there'll be a solution that aligns them both, so it's good for developers and good for users. Right now, I think frameworks are still over-optimized for developer productivity and less so for what the end user might see.

Right, I think you hit it right on the dot, and that's why I wanted to have this conversation. What's the use case for React? Why use React? When do you use React? What are its limitations? And I urge everyone listening to think like that about every tool they use. One of my other questions, which maybe we can chat about later, is why JavaScript, with all the complications of it being single-threaded, hasn't been replaced by something else. So yeah, always challenge everything.

Yeah, it's one of those things where, when we look at the web and why people build web apps, the web has always been the lowest common denominator and the fastest way to reach the largest audience. Almost every device on the planet can run a web app. Then once you get to the point where you're seeing a lot of traction on mobile, you have a good product, and the feature set is solid, you might say, now I'm going to build a native application because I want better device access. And when you build a native application, you have multiple options there too.

You have tools that wrap a browser in a native container, like typical WebView components on Android or iOS, or abstractions of that idea like PhoneGap, Cordova, or React Native. Then you also have something like Flutter, where you're not really using web technologies at all, but you still get a write-once approach that works across platforms. You're writing in Dart, but compiling natively into the UI language of the platforms you're targeting.

So with something like Flutter, you get both code reuse and really great performance, which you couldn't get with the WebView-style solutions because you're always limited by the single-threaded nature of JavaScript and by translating between JavaScript and whatever native language you need to build the actual UI. And then, of course, you have the ideal solution, which also takes the most time: build natively for every platform. That means learning all the details of iOS development with Swift, Xcode, and Objective-C, and all the details of Android development with Java, Kotlin, and everything else.

So it really depends on productivity, how much time you want to spend building the solution, and what kind of final experience you want. A lot of line-of-business or traditional enterprise apps optimize more for agility and getting something out the door quickly, and less for user experience. With consumer apps, you usually have the opposite pressure. You want the user experience to be very, very polished, even if that means large teams doing work separately for each platform. And the web still carries that lowest-common-denominator label in a lot of ways, because it's not always the fastest option, and different platforms prioritize the web differently.

Android is generally very open to the web and provides good integration between the device and the web itself. On iOS, the web is often still competing with the native app store model and native apps in terms of what is and isn't possible. And on desktop, it's more of a free-for-all. You can do whatever you want, and Electron apps are really popular too. So I don't see the web ever slowing down as a relevant tool, but I do think its convenience isn't always the best thing.

People look at VS Code, Slack, or Teams taking hundreds of megabytes just to display some text on screen and wonder whether that would be the same if those apps were built natively. Maybe, maybe not. Plenty of native apps are slow too. But the opportunity to do better exists natively, whereas on the web you can only go so far because you're adding more layers of abstraction. You have the hardware, the operating system, and then the web rendering runtime and everything stacked on top of that. And even though many computers have a lot of RAM these days, they can still feel slow.

So you end up asking whether the web is helping or hurting. But it's all fun. I keep seeing this pendulum swing back and forth between all web, all native, and then all web again. Right now, we're in the web phase.

Yeah, and ideally you'd want to give the user the native experience every time, right? It's just very hard to accomplish. You can see that with web development and PWAs. That's something I recently started looking into, and it's really cool that a website can be taken offline, can be downloaded, and can be added to your taskbar in Windows and things like that because it's a PWA. So ultimately we want to provide the user the best experience possible, and it's interesting to see all the different solutions that try to help with that challenge.

Exactly. I'm probably dating myself heavily by talking about this, but the idea of write code once and deploy everywhere has been around for a very long time. Java was one of the more popular versions of that. You could write a Java application that ran across all these places, and early on it looked exactly like a Java app. You could spot one from a mile away because of the purplish-gray colors, the buttons, and the whole look.

Then eventually different UI toolkits, like SWT and others, came in and said, yeah, you're defining a button in your code, but it can look like a native button on Windows, a native button on macOS, and a native button on Linux. That gave people the familiarity of seeing their app look and behave appropriately for the platform, and people generally liked that. With the web, we kind of went back to the older world of Swing and more traditional UI development, where it's extremely difficult to build UI that adapts to the native look and feel of the platform you're on.

I think Ionic and some other frameworks and toolkits do a good job there. But ultimately, what you end up doing is taking a bet on a design system like Material Design or Fluent and saying, okay, I'm going to optimize for the Material look and feel or the Fluent look and feel, so everyone gets a consistent experience. But that consistency may not match the native look and feel. And when you do try to use native UI with something like Flutter or even React Native, now you're effectively dealing with two codebases in some ways. My list view on iOS is very different from what it is on Android.

It's not just that it looks different. The interactions are different, so I need specialized code in all these places. The intentions are good. I want to write code once and build the right UI for my audience. But as you get deeper into it, the more you optimize for your own productivity, the more user experience can suffer. If you push all the way in the other direction and optimize only for user experience, then your productivity suffers because now you're writing multiple versions of the same code in multiple languages. That's why I call it job security.

If it were all solved, I'd just go to some AI or ML system, say build my app, and it would spit out everything I want. So the fact that it's still complicated means we still need human beings involved in a lot of these cases. Though maybe the more interesting question is whether there are more creative, more advanced things we could be doing as humans than writing the same button over and over again just to make sure all the text displays when you're hovering over it. So, you know, it's complicated.

Yes, it is very complicated. Is there anything else you want to touch on? I know we don't have much time left, and I have thousands of questions, but I think this is a good starting point. I think we covered a good amount of the before, during, and after, or I guess the future, of React. You definitely gave me some starting points. I want to look at Next. Js, I want to look at web transitions, and I also want to see what optimizations browsers are doing. What's CSS doing in terms of development, and can there be any more enhancements for HTML? There's just a lot to look into. So cool.

Well, Joel, great chatting with you about all these topics, and we should probably do this again sometime.

Yeah, sounds good.

Cool, all right. Talk in a bit.

Yeah, thank you.