Keith Cirkle of GitHub on React Fatigue

In this episode of Coffee with Developers, we sit down with Keith from GitHub to explore why some developers are moving away from frameworks like React and focusing on standards and browser-native solutions. From the evolution of JavaScript to the ongoing debate about web components and frameworks, this conversation dives deep into the future of web development and why understanding the platform matters more than ever.

----------------------------------------
Welcome to WeAreDevelopers, the #1 developer community in Europe!
This is your one-stop destination for the latest tech insights, tutorials, and career advice to elevate your developer career.

Stay updated Dev Digest, with our weekly newsletter featuring the most recent tech trends, career guidance, and original content crafted by developers, for developers. Subscribe now

Interested in advancing your career? Browse through our job board featuring over 190,000 jobs. Unlock job opportunities with a free developer profile

Don't miss out on the annual highlight of every developer's calendar - the WeAreDevelopers World Congress. Network with 15,000 peers and learn from over 500 speakers. Secure your spot and save 10% with "wearedevs_yt"

#CareerInTech #Tech #ProgrammingTutorials #DevRel #CodingTools #TechJobs #TechTalks #DeveloperSkills...

Transcript

Welcome to another coffee with developers. I'm here in a hotel room in Caratovicei, Poland, so hopefully it's go goingna be fine. But it was fine yesterday when I talked to Paul Kinlin about a similar topic that I want to talk to my guest today here. So Keith, who are you? And I mean I heard you actually don't have time to learn React and that's why I wanted to interview you.
So yes. First, what are you doing? And actually why don't you have time to learn React? Everybody need it, right? Well, I'm busy doing lots of things, so I work at GitHub.
I'm an engineer at GitHub working on the issues experience. I used to work on the design system at GitHub and we kind of have these two flavors like one was written in Rails view components and one was written in React. But aside from my day job, I also participate in standards as much as I can. I think it's really important for non engine implementers to participate in standards, so I try to do that as much as I can. I attend a lot of the OpenUI community group, I attend Wattwig, which is the HTML working group, CSS working group, ARIA working group and try and help out wherever I can and sometimes contribute new things.
So I work a lot in my free time on hacking browsers and I just did a blog post about that about my hundredth contribution to browsers.
So yeah, I guess like with all of that I just feel a little bit, you know, there's not enough time to learn all the things I want to learn and I want to kind of pick and choose more sensibly. And for my money, I don't think that React is is worthwhile learning in depth. I think it's okay to have a cursory understanding of it and it's easy enough to pick up, right? As the rhetoric goes, you can learn React in a day or whatever and I think you can learn a lot of the broad strokes of React or any other kind of framework, but they're very complicated tools and you can specialize in them. But I don't think it's necessary and I don't think it's even that valuable the use of your time especially because I don't think the frameworks themselves value your time that much.
I see a lot of these frameworks are releasing whole new paradigms. Svel just announced this thing about runes since svel 5. React is talking about their React compiler, which is going to change everything and you're not going to have to worry about Useect anymore or whatever. That to me is a sign that they don't value their existing paradigms or they don't value your time enough because you've invested all of this time in learning these things, but it's going to change from under you. Maybe that's why I'm interested in contributing to these browsers.
It's a bit of a retreat from all of that because the browser code bases are very old and there's not a lot of exciting newness. It's just like a lot of C and not much in the way of hot newness. Like the JavaScript landscape forever changing. It is weird, isn't it? Like, I found that in the later years, JavaScript, what came into the language was a lot of stuff borrowed from other languages, like from Python and from Ruby.
And then there's things like symbols which I still don't know what I should use them for. And like it feels like that there was a heyday when like ES6 finally came out and we finally said like, okay, let's's s. Let's get the whole mess that we had with Act Action Script and jscript and Live Script and all these things out of the way and standardize it on ES5 and then ES6. And then it started to like became synthetic sugar and like things that come in. I mean there was a sink ofai that actually became a paradigm that actually was not in JavaScript before it became a thing.
And it feels like that the we learned a lot from frameworks back then, especially in the DOM space. We learned a lot from jakebry which we then became a query selector and we, we learned that it's not as simple as we think it is to navigate the DOM in vanilla. And then we actually made that easier with like. We also have like parent and neighbor selectors now. Things that we learned from jQuery back then.
But I felt the same when I worked with a Jaxian back then and Ajax came out and out of a sudden we had like 152 different JavaScript libraries that made Ajax easier. And then like two years later there was just one left. JQuery and the others were all forgotten. Moot tools maybe a bit more and like these kind of things, but it felt the same back then at least they just made JavaScript easier. But now it seems like all these frameworks try to reinvent the web as it is, whereas browsers basically bend over backwards to make the web perform really well no matter what you throw at it.
And so we, we I kind of understand that the investment that you think like you don't want to get locked into one of those, that you might bet on the wrong framework that then goes away half a year later and you stand there like the, the Flash or Silverlight experts from yonder and basically like okay, what do I do with this knowledge now? So the something that standardized takes more time, but it seems like it's a longer investment for the future. Uh, so it's interesting to see that these, these paradigms always come and go and a lot of times they come from a different environment than the web and they try to force, to be forced on the web and it seems never to work. It seems like always trying to pay, catch up with the other systems. Yeah, yeah.
I think there's probably a bit of a kind of mental divide between some of the frameworks and I do think some of them, and I would include reacting this kind of see like dom's the wrong model and their attempt is to try and fit their model into the existing model of the web rather than extending it, it almost replaces it. To me that's a misstep. But I think more than that is I think you pointed out some interesting bits around like jQuery where things that do extend can be more easily folded into the platform. So like jQuery selector becomes Qury Selector all or Ajax, the paradigm of AJAX can fall into Fetch. I think those things, they seek to improve the web, they introduce new ergonomics on the same underlying kind of architecture.
But it's a net improvement, it ends in a net improvement. Those things have to be modest improvements though. We need to solve the web one step at a time because it does take so long because there is so much rigor and complexity involved. There have been discussions about incorporating JSX into the dom or into JavaScript. Mean E4X was the thing that the specification that existed before ES5 which looked to incorporate XML into as a native language feature, but it's just so complex and there's so much to discuss and decide and so many stakeholders involved that it almost is doomed never to be specified in my opinion.
So tools that make these rapid departures like JSX React have, I think that they're never going to exist in earnest in the platform because they kind of deviate from it too far, they step too far away and I think's we should still have that space, we should have that space for frameworks to innovate and experiment. I think what has been kind of concerning though is watching the rise of the predominance of React, I think it came at a good time where we were stepping away from jQuery, but we still had to find new tools to use to address some of the shortcomings of the platform. But I look at the platform today and it's totally different to the platform I worked on 10 years ago. None of the compatibilities are really a concern anymore. We have these projects like Interop, Interrupt 23, Interrupt 24 that the browsers are working on to make sure that there is this cohesive platform that you can develop against.
And so the issues that frameworks like React initially sought to fix, they no longer exist. So it's answering a question from a decade ago that's already been answered by the platform itself. It hasn't really caught up with that, I think. And that's kind of the problem that I see with it. You're learning this entirely new system on how to build ui.
It doesn't gel with what exists in the platform, it doesn't gel with the dom, but it has all these workarounds that it kind of still holds Ono. I mean, one of the little pieces I picked on in the blog post was autofocus. Trying to just manage focus in React is a pain, and it shouldn't be because the browser actually does a whole load of work to manage focus for you. If you open a dialog in the web platform, like using a dialogue element, the browser will retain the pointer to the focus element that was focused on before the dialogue was opened. But I see so much React code that has these forwarded refs to store this kind of stuff because there's not really, like React doesn't give you this very nice way to reveal these parts of the platform underneath.
Well, what's a bit like when we reinvented Hashag to keep the state of the, of the app in the URL. And basically before that we did that just with the URL. And now we have like, we have like view transitions. So we can actually keep the old URL model and still make it look like it's. It's an sba.
And I find that a really, really interesting approach to basically put it in the platform that you. That it doesn't feel like that it's actually going from one page to another, but it does go from one page to another. Seeds to history allows the black back button. All the things that we keep having to reinvent in that was already in the platform in like one of these abstractions. It also feels weird that all of these Abstraction models, when they come up, they always say like, oh, we make it easy for you in like five minutes to build your first prototype app.
And they always talk about prototypes, they never talk about final applications. And then when it comes to like building accessible applications as well, and especially when you talk about focus, making, making those things work then actually cost you more time than if you would have started with vanilla to start with. But I can to a degree understand that when it comes to React and others, that there is a consistency in the, in the syntax and the language of it. Whereas like newer features in css, when you take a look at like a flexbox and Grid and now like, I mean, I'm happy that we got nesting in CSS now, which is very simple syntax, because we had like discussions about having different syntax for that as well. But it feels like that.
Yeah, something like CSS and Grid, explaining to somebody who works in a component world is kind of really tough. It's, it's a, it's a steep learning curve, but that's why people go for these abstractions. But in the end, what ends up in the browser is HTML and CSS. Even if you generate everything with HTML with JavaScript, it's HTML and CSS. So you might as well understand what can be done.
What frustrated me as a browser maker was that people didn't use the platform things because those were the ones that we could optimize, those were the ones where we could do speed optimization for your memory, optimization for you, because they were standardized. But if every framework did something different, we had a problem. So what are your thoughts on htmx, which seems to be like just building on top of HTML and give all the other features that React and View and Next JS and whatever they're called bring in as well. But seems there was a flash in the pan. People were too excited about it.
I think HTMX is very interesting. I think that there's a balance to be struck between. I kind of see that as like the polar opposite to what I would call the typical way that people build React apps. This SPA style very integrated onto the client. But I think htmx, there's a silent part that HTMX doesn't really address necessarily, which is the latency between the client and the server.
I think that there's a lot of good quality ui, almost transparently hide these kind of details from you. And that's not something that beat. That's not something that can be reasonably addressed in any kind of framework. I don't think at Least I haven't seen it. But the ability to hide user interaction, but the ability to hide network latency behind user interaction I think is really important.
And that's where this balance needs to be struck. Because htmx effectively says, well, the server is where all of your state'going to reside and you're just going to feed HTML down the wire into the browser, which is the right direction. But the problem there is that every click, if you're on a slow network or if you're a good distance away from the server, all of those clicks are felt by the user. So I think that there's a good place for more richer client side interactivity. But I think in that space that's where you can hide some of this network latency.
I think this is a very common thing in UI design in general. You can hide CPU cycles, you can hide network cycles behind animations. For example, that 200 millisecond an. This is a very common thing in game design is this idea of the interstitial loading. And so in a game you might see this animation that your character is opening a door and in the background the game is furiously trying to pull in assets from the disk or render the new world in front of you, and you're just seeing the same animation for the hundredth time.
I think that is like applicable to UI as well, and it's especially applicable to the network. So we're going to cutscenes in GitHub soon. Like you click a button and then Octocad is doing a dance and keeping you occupied while something's going on. Yeah, exactly. Yeah, but I mean we kind of have that.
But it's like with skeleton UIs, right? And so it's like this very visible thing to the user. It's a very clear signal that something's happening. But I think that that can be reduced by clever and tasteful optimizations of the ui. I think that that is something.
It's not necessarily intrinsic to what HTMX is offering, but I think it, it teeters may be too far in the other direction of let's go back to everything being on the server. I think there's a good middle ground, but I think this is where the platform has a lot to offer and is working up to those things. We see things like the new dialogue element, the popovers, all of this kind of stuff is really interesting and it solves a really key problem for these richer applications that do need these layers of UI and this interactivity. But hopefully it can solve it in a way that does hide those of transition points. I think new transitions is another good example.
We can kind of like we're still facing that same round trip time, but we're just hiding it with a bit of an animation or just a way to smooth the transition away from this stark kind of, you know, delete the page and re render everything againe. I mean the browsers did that with caching of interfaces already for quite some time. I mean one frustrating bit. And again, thank you for contributing back to the platform because one frustrating bit I had in Edge was like I wanted to fix so many broken form elements and I never got the chance to actually get engineering time to do it because we looked at the numbers and nobody used them. You know, like, I mean you, you can complain about like things like, I mean now we got selected styable and we can put an HR inside the select element as well.
So that was a big pain that people always did. But it needs like affirmative action from our side to actually go to our managers and say like we want to fix that because if it's broken then people don't use it. And basically people don't use it because it's broken. So It's a catch 22 I found. Also there's a, there's a massive amount of like and I talked yesterday with Paul about this.
There's a mass amount of people that actually wrote like so and so is dangerous to use. Don't use it yet. Especially accessibility experts say like date picker, okay, here's like three bucks and a date picker. And then until they're fixed you cannot use it. Whereas like native controls in React have the same issues, but people don't have any qualms about using them because they don't know that it's even broken.
So the, the discarding something because it's. Or there seems to be a fetish in the, in the web dev community to basically find flaws in native, native components and then say like they're broken this way and that way that way and they don't even file a bug for the, for the, for the browser. And then you're like, how can we fix that? That's just basically a lot of, like a lot of people don't touch the web because the luminaries of the web say like it can't be used. So I think that's something we really need to stop if we want people to come back to the fold and actually do things natively.
Yeah, yeah, there's a lot there isn't there I think I agree that we can kind of quickly dismiss parts of the web because of a few issues. It's something that comes up regularly for me is that some of these elements, the dialogue element, has existed since 2014 or something, but it's only recently in the last few years where it's gone through a lot of iterations to improve it and it didn't exist in a cross browser way. It only existed in Chrome in 2014 and I think maybe it was 2018 when Firefox started working on it or something. But there's been a lot of new work on it as people have started to use it. But yeah, there's still a lot that people dismiss around that or select menus or form controls because they don't quite hit the mark.
I think there's a bit that the web platform needs to do there to make these elements more composable, I think Customizable select or styable select. That proposal is doing excellent work to detach all of the parts. And that's where things like pop over have come from, this idea that what if you wanted to build your own select from scratch? How would you do it? What are all the constituent parts of it?
So we can offer the primitives at the same time as offering the complete solution there. But yeah, there are a lot of cases. I said earlier I worked on a design system, I've worked on a few design systems in the past where it's very easy to describe the bespoke needs that this application needs as a reason to throw away some of the existing web platform primitives there. But it does do a disservice to our users in some cases because the platform will continue to mature. And the question is, is your design system, is your UI maturing at the same pace?
You able to pick up all of the complexities and subtleties that browsers are implementing, all of the accessibility that browsers implement for these controls, form completion, for example, it is like a very complex topic that browsers can handle pretty seamlessly if you let them. But we see a lot of forms that, that are kind of because they're hand rolled, because it's a stack of divs pretending to be a form. We start to miss out on these features and suddenly the web is a bit more broken than it could have been. So ye, I would love to see people relying more on the primitives available and maybe taking some of the compromises or working with browser vendors to fix those. That would be a great step forward for me.
I'm always going to put my money behind people that actually turn up to the standards.
I see a lot of representation from folks like lit who buildil lit HTML and Lit element. They turn up to the standards meetings. And so to me that'like that's an interesting place, right? Like it's maybe often jokes that programmers like to kind of build themselves out of a job. I think framework authors should be especially motivated to do that.
Well, I mean some of them were and it kind of never worked out. I think the only one where I've seen it happening was phone gap, you know, like that. That was the only one where then just vanished and nobody needed it anymore. And that was really wonderful. It was built inuil redundancy so to say if it's good enough across browsers to show that.
I mean today I showed required on stage. Just basically sayect put it required on an HTML input element and then you don't have to write a JavaScript that actually filters if it's there. And the first thing that people then ask be like yeah, well how can I style that required messaging thing there? I'm like yeah, there's ways to override it. But then I actually pointed out like how do you want to style it?
Like right now it looks different on desktop than it looks different on iOS, than it looks different on Android according to what those people are used to. Like, people on these platforms expect something to look like that. Do you want to, to control this all yourself? Do you want to design these different experiences yourself? And he's like I never thought of that.
Like just wanted to control it. I just wanted to make like the perfect solution for it. I mean of course there's, there's issues with it. There's like you always have to have server side control as well. I mean my favorite is uh, is like when you had lengths that you can define like the length of an input element and you cannot type more than in in it but you can use JavaScript to, to inject a longer thing and it would actually not trigger the validation.
So there's a bug in there. But I mean that ddd that the, the joy of people wanting to put things in and want to control and design it themselves, not understanding that the web can be consumed in any environment that you can't control and it should, it should actually fit into that environment rather than try to replace it. And I found that very, very hard for people to swallow to like let go. You don't need to control it then you're not actually in charge of it. But people are just like, yeah, but my boss wants me to style it.
So it's really painful when you also said JSX in the browser and I also hit markdown people want to have in the browser and I'm like, okay, which of the 15 markdown standards do you want to have? Like takequery in the browser was also a request back then and u. Yeah, all kind of stuff. So it's like, yeah, the standards are there for a reason and they take a long time to standardize because they have to think of lots of contingencies that you haven't thought of. Now one thing that I found wondering about React is like it does reacted react native so that the idea of a lot of these frameworks is you can build something for the web but also native platform native apps with it.
So they see HTML as as a compilation target. Do you think that's something that people really believe or do you think that's something that is just. Yeah, it's a nice to have, but it gives a bad experience on all platforms. Yeah, I haven't really seen a particularly compelling use case for this. I haven't spent that much time in the mobile space, but I have quite a few friends and peers who do.
And a lot of the time it's either native or it's a webview. I can't see where the value add is for something like React native, but I'm sure there are a lot of people building with it and doing great stuff with it. But if you're not building native and you're not building for the web, like what is the point? I guess you're accepting this halfway ground between the two. I've never personally seen successful application that leverages the idea of React native appearing on both a web and on mobile.
Like I say, a webview is just so easy to put together and you can just render HTML and you might be using React behind the scenes there, but that's not React native, that's just like React outputting HTML. Well, what drives meat bonkers is when people build apps and use their own internal browsers to basically to have control over all the data. And it's Normally like a 15th generation outdated chromium somewhere in there. And more annoyingly, I'm happy to to to store my passwords and information and autofill in my browser, but every time I go from Facebook to a website, it opens in the Facebook browser and none of the autofill works cause it's all in my Edge browser and it's just like this this extra control is just driving me nuts. And it seems like a lot of people were happy to include their own browser with their app just so they can spy on you.
I don't know why they do it, but it feels like that's a, that's a pattern that needs to be broken to a degree as well because like there is a browser on the operating system that the user chose. There's probably. It's far easier for them to order something on your website because all that data is being pre filled but people are still like oh, why don't you enter that data here again? You're like no, I don't wantn. Yeah, yeah, it's kind of wild.
The dream of PWAs that was sold to us. I think you know that there's a narrative there that like the kind of arbiters of these platforms have kind of tried to prevent that from happening. Maybe there's some truth there. But yeah, I kind of yearned for the idea that was sold in like, I don't know, the 2015s that we could just have these web apps installed on our phone and they would all just use the built in browser likeever or whatever browser we wanted to pick and they would just operate like native apps. But yeah, we've kind of stepped far away from there I feel, which is a shame.
One big discussion was that was lately a big drama and I was on vacation so I'm happy I didn't follow. All of it was the whole like web components are not good enough and native components solve all the other problems. So where do you think we are on that in that regard? I think that that was just really bizarre. It seems like there's a lot of developers that actually start, started a component world because they came from, I don't know, native development and actually think the web is a componentized thing rather than a page level paradigm.
But it seems we, we have to make those people happy. But at the same time what did, what we did with web components is not good enough. And I still don't understand what the problem was. Yeah, I think there's a lot of complexity in web components. I think that they do change some of the existing paradigms which does make things a little more awkward.
Like shadow DOM is a departure from just regular HTML I guess, or light dom. There's some learning curve there. The web platform isn't immune to this shifting of the tectonic layers either. Yeah, the drama was around this idea that web components are this kind of exclusive or in isolation tax on framework Authors I don't know. Personally, I don't buy it.
I understand the points that were being made, but to me it's like they are an intrinsic part of the platform and they're not going away anytime soon. People find use for them. But like everything, a framework's job seems to be to make the developer's life easier. I don't see how taking a particular stance on one particular platform technology over another makes developers lives easier. I don't want my framework having opinions about Fetch.
I don't want my framework having opinions about bfcche. Why would I want my framework having opinions about web componen? Maybe they're a bit of a straw man or at least a punching bag. But yeah, I did a talk a while ago about bad parts of web components because I am an eternal pessimist. But I do think web components are good.
I think they're useful technology. We're seeing more and more increased adoption of web components and I think that there's a good reason for that. They do provide that kind of interoperable layer and they don't provide everything a framework does. But I don't think that everything that frameworks give you is necessary for all of the time. We don't need state management for these small independent components.
They don't need to opt in into centralized state management or they don't need a context provider or any of these other things that the frameworks offer you. So there's a place for them and they fit in. I wish people would embrace them more. An eternal pessimist from England. I never heard about that.
That's a very. Yeah, right. It's, it's weird. One thing that actually always rubbed me the wrong way and I mean I talked to Jeremy Keith about this on stage several times. It's like we.
I wrote this unobtrusive JavaScript course in 2000 where I basically said like progressive enhancement, make sure that your JavaScript is never in the way, put all the styling in your css, put a class on top of something and use the CSS to define it rather than doing inline styles. And then we get JSX and then we get things like tailwind and we kind of like paint with, with, with markup again. And it feels to me so weird that we're actually that, that it seems to be such a hard sell to make people understand that the separation of concerns is not something that because we hate you, but it's actually something to make it easier for you to maintain something that you've created half A year ago and you go back to it and you still to understand it, but it seems like especially with the success of Tailwind, I still don't understand it. I still. People that said, like, I work in Typescript, I work in react, so Tailwind makes me really, really effective.
But learning all these shortcut CSS names, that reminds me of BEM or other systems that we had before. And I'm like, why do I need this when I actually could have it in like readable CSS syntax? Or am I just being a dreamer? And I think CSS is readable. I mean, what's SOL is new, I think.
Right? Like a lot of these. I often joke like nothing good has been invented since the 1970s. Like all of the foundational problems were resolved in white papers and conferences in the 1970s, but. But no, yeah, I agree in part.
Like, I. I kind of see some of the value in Tailwind. I think a lot of the value, like a lot of these tools talk about developer experience, which is this very kind of weird, nebulous term and kind of what I've pinned it down to, as far as I can see, is IDE completions and go to definition, which is like something that I think has been under invested in for a long time in the world of dynamic languages and maybe markup languages like HTML and css. So having good auto completions I think does actually help a lot of developers. I think that's where the value out of Tailwind comes in, because the idea that you can pick from a list of things and hopefully get the right one is maybe comforting.
But yeah, I got into an argument recently on Twitter because someone was pointing out how good Tailwind's innovation of logical properties are, and I had to explain to them that that is actually.