Does the Website vs- Web App Dichotomy Exist

Episode Description

JavaScript Jam explores the React criticism wave, the websites-vs-web-apps spectrum, HTMX as a disruptive competitor to Next.js, and NPM ecosystem data.

Episode Summary

This episode of JavaScript Jam, hosted by Ishan Anand and Anthony Campolo with guest Rishi Raj Jain, opens with discussion of a wave of public criticism directed at React, including concerns about complexity and the influence of the Next.js team on React's direction. The conversation pivots to an article from the newsletter proposing a four-quadrant model for classifying web applications along two axes—static versus dynamic and online versus offline. Ishan argues the static-dynamic axis remains the more consequential distinction today, while the online-offline axis represents a future battleground tied to local-first development and data ownership. This framework leads into a deeper discussion about whether HTMX poses a greater competitive threat to Next.js than other JavaScript frameworks, with Ishan making the case that HTMX follows a disruptive innovation pattern—serving backend-driven teams whose needs were never well met by React-heavy architectures. The group also explores Mavo as a declarative HTML framework, Astro's adaptability, WordPress's underappreciated role in the ecosystem, and a Super Agent AI framework. The episode closes with a look at NPM dependency data revealing TypeScript and React as the most depended-upon packages, highlighting the outsized scale of front-end project activity compared to the backend.

Chapters

00:01:17 - Welcome and React Ecosystem Criticism

Ishan and Anthony open the show with their usual introduction to JavaScript Jam, welcoming audience regulars Rishi and Nifty to the stage. The hosts describe the show's open-mic format and encourage audience participation, setting a casual and community-driven tone for the episode.

Rishi kicks off the substantive discussion by raising the recent wave of criticism directed at React, referencing tweets from Ryan Florence and Tanner Linsley, as well as Cassidy Williams's widely shared blog post. Anthony summarizes the concerns as a mix of frustration with React's increasing complexity, its drift from client-only simplicity, and the perceived outsized influence of the Next.js team on React's direction. Ishan notes that Cassidy's post was especially effective because she grounded her critique in deep personal expertise with the framework.

00:07:36 - React Server Components and the HTMX Alternative

Rishi shares his experience trying React Server Components, noting the complexity of integrating them with Next.js and the confusing developer experience around forms and client-side mutation. Ishan acknowledges the conceptual appeal of RSCs—likening them to a modern PHP where server and client code coexist—but questions whether that level of complexity is necessary for many common website types.

This leads Ishan to restate his prediction that the biggest competitive threat to Next.js won't come from another React framework but from HTMX, which appeals to backend-driven teams that lack the budget or scope for heavy front-end engineering. The group discusses how HTMX gives developers permission to push back against the pressure to adopt React for every project, framing it as a tool for a different market segment rather than a direct replacement.

00:11:20 - The Websites Versus Web Apps Quadrant

Anthony introduces a newsletter article proposing a four-quadrant model for web applications, adding an online-versus-offline axis to the traditional static-versus-dynamic distinction. The quadrants map to informational, transactional, real-time, and local application types, with examples like Amazon fitting the transactional category where mostly static content still involves server interaction.

Ishan offers a layered interpretation, calling the static-dynamic split the "dichotomy of the past" rooted in the historic W3C versus WHATWG debate, and the online-offline split the "dichotomy of the future" tied to emerging trends in local-first development and data ownership. He argues that while the offline dimension is aspirational and important, most real-world applications today still cluster on the online side, making the static-dynamic axis more practically relevant for choosing a framework.

00:19:21 - Mavo, Declarative HTML, and Future App Architecture

The conversation turns to Mavo, a declarative HTML framework highlighted in the newsletter article that extends HTML syntax to handle data storage and manipulation without a server backend. Ishan walks through its features, noting how it adds state and actions directly into HTML markup with near-pseudocode simplicity, and connects it to the local-first quadrant of the app spectrum.

Ishan speculates about combining frameworks like Mavo with local LLMs, imagining applications defined through a blend of markup and natural language instructions. Anthony draws parallels to early Angular and Vue patterns, and the group discusses the boundary where declarative HTML approaches break down and full dynamic frameworks become necessary—acknowledging that for many content-rich and transactional sites, the simpler approach is sufficient.

00:25:16 - Astro's Adaptability and Disruptive Innovation

Anthony and Ishan reflect on Astro's strategy of continuously adapting to new trends, from Islands architecture to HTMX integration, positioning it as a flexible platform that stays relevant regardless of which paradigm is ascendant. Rishi raises the question of how HTMX handles server rendering compared to RSCs, and Ishan clarifies that HTMX inherently assumes a server-rendered starting point, making it a natural fit for backend-driven stacks like Django or Flask.

Ishan frames the competitive landscape through the lens of disruptive innovation theory, arguing that trying to unseat Next.js head-on with another JavaScript framework is attacking strength with strength. Instead, HTMX succeeds by serving an underserved market of backend-focused teams, gradually building capabilities that could eventually encroach on the broader market. The group agrees that WordPress sites represent another large potential market for HTMX-style interactivity.

00:36:26 - WordPress's Role and Potential in the Ecosystem

Rishi asks about significant WordPress sites, prompting Ishan to look up high-traffic examples including Bloomberg, CNET, NPR, TechCrunch, and Time Magazine. The group observes that many of these are content-focused or represent corporate subsites and blogs rather than primary interactive applications, placing them firmly in the informational quadrant of the earlier framework.

Ishan shares his view that WordPress has been underappreciated by the JavaScript-centric community, noting its strength as a CMS-first platform where content velocity matters more than feature development speed. He suggests WordPress could serve as a viable MVP framework for certain use cases and discusses the historical tension between the Jamstack ecosystem and WordPress, while acknowledging that at 40% of the internet, WordPress remains a force that shouldn't be dismissed.

00:46:13 - AI Frameworks, NPM Data, and Closing Thoughts

Anthony highlights a JavaScript Jabber episode about Super Agent, an AI framework for building assistants, comparing it to LangChain. The group discusses how Super Agent is more narrowly focused on chat-driven agent interfaces, while LangChain offers broader workflow orchestration capabilities, with both serving as glue layers between LLMs, vector databases, and external integrations.

The episode wraps with a deep look at NPM ecosystem data from Socket, revealing TypeScript and React as the most depended-upon packages. The hosts note the overwhelming front-end skew of the top 50 dependencies, with Express barely appearing at number 50, illustrating the extraordinary volume of front-end project creation. They share amusing finds like the longest NPM package name and the BBC's appearance as a top collaborative maintainer before signing off and reminding listeners of the biweekly schedule.

Transcript

00:01:17 - Ishan Anand

Hello.

00:01:17 - Anthony Campolo

Hello.

00:01:18 - Ishan Anand

Oh, there we go. What's up? Hey, how you doing? I'm doing good. I just discovered that my desk was falling apart, so I'm glad I realized that now. Otherwise, I shudder to think about the whole thing falling down on me while I'm at it. That would be bad. But welcome, everyone, to JavaScript Jam. I am Ishan Anand, VP of Product for the Edge geo-applications platform.

00:01:58 - Anthony Campolo

And I am Anthony Campolo, developer advocate at Azure.

00:02:02 - Ishan Anand

JavaScript Jam, we like to call it an open mic for anything web development or JavaScript-related. Basically anything in frontend is on topic. We like to be audience-driven as well as informed. So we have a newsletter, which Anthony wonderfully curates, and if you go to javascriptjam.com, you can click on newsletter and see this week's episode, which Anthony just put up there on the Jumbotron and mailed out this morning. We sometimes go based on the topics in the newsletter, and you can look at that, but we're very flexible. Like I said, we tend to be audience-driven. So feel free to raise your hand and ask a question on a certain topic or change the topic of conversation at any time. We like to be driven by what's of interest to you. Some of our favorite conversations have been when somebody asks a question in the audience and we don't know the answer, and somebody else in the audience has an answer. So don't hesitate to raise your hand and come up to the stage. We'd love to hear from you. As much as Anthony and I like to talk to each other, we do that all the time at work.

00:03:16 - Ishan Anand

This is one of my favorite meetings. Indeed. Yeah, because it means I get to interface with the market. So, yeah. Anthony, anything I forgot or left out?

00:03:29 - Anthony Campolo

No, I think that's good. I just want to say hey to Rishi and bro Nifty in the audience. I just threw them invites, whether they can speak or not. Let's see if they come up.

00:03:38 - Ishan Anand

Hey guys, good to see you again. So let's...

00:03:43 - Anthony Campolo

Oh, Nifty.

00:03:44 - Ishan Anand

Hey, what's up? Yes, hello, gentlemen.

00:03:49 - Anthony Campolo

Long time, most loyal fan.

00:03:50 - Ishan Anand

Yes. Long time no talk. Yeah, man, how've you been? Did you...

00:03:56 - Anthony Campolo

How were your holidays?

00:03:57 - Ishan Anand

Good, very good, very good. Just got a new job. I'm trucking. I'm driving all over the country, hauling freight.

00:04:05 - Anthony Campolo

Really? Wow. Do you like it?

00:04:08 - Ishan Anand

Actually I do.

00:04:10 - Anthony Campolo

That's good. I mean, you probably a lot of times listen to podcasts and music and stuff like that.

00:04:15 - Ishan Anand

Absolutely. I'm living and breathing these Twitch streams and these podcasts and different things. Yeah, it's great.

00:04:25 - Anthony Campolo

Looks like we got Rishi too.

00:04:28 - Rishi Raj Jain

Hey, do you hear me?

00:04:31 - Anthony Campolo

I do.

00:04:32 - Ishan Anand

Awesome, Rishi, great to hear from you.

00:04:35 - Rishi Raj Jain

Hey, Ishan, we have to have that call. But yeah, it's always good to join JavaScript Jam.

00:04:43 - Ishan Anand

Yeah, thanks for joining. Well, did you guys get the newsletter? And is there anything you saw of interest? Otherwise, we'll jump into the first topic. Or anything on your mind in the current state of web development?

00:04:58 - Anthony Campolo

Yeah, I'd be curious if there's like any cool projects you're working on or just things you're excited about.

00:05:04 - Rishi Raj Jain

Oh, yeah. So I'm working on Astro Font, basically, and it's like Next Font just for Astro sites. So it was recently used in the Rising Stars JS website. And I think what I see going on in the ecosystem right now is this debate around React and how it's being led, you know, between two companies. What's the shape it's going to take, and whether it's going to be a regression or actually uplift how apps are made, or websites are made, with React. So I think there was a tweet by Ryan Florence recently about it that was praising Cassidy too, I think.

00:05:50 - Anthony Campolo

And then like Tanner tweeted something.

00:05:54 - Ishan Anand

I missed this. Can you refresh both for myself and the audience? What was the tweet and what was said?

00:06:02 - Anthony Campolo

Yeah, I'll go grab some of them. Basically, it was a lot of people voicing separate concerns with React, and then it kind of just became a pile-on at a certain point. Some were more about it being influenced heavily by the team at Next, and some were more about just the complexity of it and how it has kind of strayed from being client-only. So I think these are similar criticisms people have made about React for a while. It just felt like there was a moment where everyone felt the need to express it at once, I guess.

00:06:42 - Ishan Anand

Yeah. I saw Cassidy Williams, I think, also put out a post. I don't know if you saw that.

00:06:47 - Anthony Campolo

That's Cassidy.

00:06:48 - Ishan Anand

Yeah, yeah, okay. And I thought she opened it really well by being like, hey, before you disregard what I'm saying, I'm really qualified to speak on this. She was like, I used to teach React. Even coming at it as an expert, it does feel like there are certain areas that are unsatisfactory at the moment. So I think it's very topical. I think it kind of dovetails with what you put in the newsletter this week on the spectrum of types of apps. But I'm curious, Rishi, where do you land on this? Do you have a thought or opinion? Are you still figuring it out?

00:07:36 - Rishi Raj Jain

Yeah, I'm actually still figuring it out. I did try RSCs, but they turned out to be complex for me initially when I was trying to actually integrate RSCs with Next.js, and there were a lot of errors in my CLI that I saw. And I think there's a gap in understanding of how forms, for example, are supposed to work with RSCs and how you mutate them on the client side and stuff like that. So definitely I feel there's a gap in how development would be in the future. So in some sense, they're right about it. But when I see demos of partial prerendering by Rauch, I think it's a, I don't know, a two-sided sword, as they say. So it might be beneficial for some use cases, but again, it might backfire in some cases. Does that make sense?

00:08:29 - Ishan Anand

Yeah, it makes perfect sense. With great power comes great responsibility. And I have to say, I kind of like conceptually what RSC is actually going for. I think it was Malte who said, if you squint, it's kind of like imagining back to PHP. You can grab what you need on the server, but then you can also use the same code and have it do stuff on the client, and have those interact seamlessly. In some sense, it's like the true isomorphic JavaScript application framework. On the other hand, it comes with a ton of complexity, and if you're trying to build, I don't know, maybe even a blog, but even an ecommerce site, do you really need all that complexity? Would something like HTMX just be sufficient? We talked about that last week with Dan, and my prediction for 2024 was that the biggest competition to Next isn't going to be another React framework. It's going to be HTMX and these others taking the addressable market of sites that are primarily backend-engineer-driven, and basically saying, well, we don't have the budget or the scope to be able to have a big frontend engineering team.

00:09:58 - Ishan Anand

We're better off just putting HTMX on it and being done, at least for now. So I think it's going to be an interesting year, and we'll see how that fleshes out.

00:10:13 - Rishi Raj Jain

Yeah, I also do see an increase in HTMX. Maybe it was by Flavio Copes, if I remember correctly. But yeah, I see a lot of sites going with HTMX recently. So Rising Stars JS, again, is built with Astro and HTMX. And if I read the code right, it does make sense to use the framework if you're just prototyping something out very quickly. But I'm not sure if it does make sense for large apps. Is there any production-built, Next.js-like use case, websites built with HTMX that you know of? Because I haven't been able to locate them for now.

00:10:54 - Ishan Anand

Yeah, I think that that actually kind of takes us to the topic, Anthony, that you opened most of the top of the newsletter with, which is the spectrum of apps or the quadrant of apps. Do you want to just briefly walk us through that? Because I think that actually sets the stage for how you make this decision of, you know, do I use RSC and Next JS or do I use, you know, something like htmx?

00:11:20 - Anthony Campolo

Yeah, I saw this post shared around a lot. It was about websites versus web apps, which I think is usually kind of a tired topic. But I thought this was a really good take on it. So they suggested thinking about it like this: usually you have the static/dynamic distinction as one of the biggest things to distinguish a website versus a web app, like content-focused versus interactivity-focused. But he adds another axis, which is online versus offline, and that creates four different quadrants. So if you're dynamic and online, you're real-time. If you're dynamic and offline, you're local. If you're static and offline, you're informational. And if you're static and online, you're transactional. The transactional one might not be the most obvious just from the name, but it's kind of referring to sites like Amazon, where it's mostly static content, but you still have some interactivity and you're interacting with the server, but you always have a full page refresh any time that happens. And then he takes a bunch of different examples and puts them in there.

00:12:34 - Anthony Campolo

So if you click through to the newsletter or the post itself, which I'll share, you can see an image where he puts all the different examples in each quadrant. But yeah, what was your take on this, Ishan?

00:12:48 - Ishan Anand

Yeah, so I thought it's the dichotomy of the future mixed with the dichotomy of the past. Let me explain why I say that. The dichotomy of the past, this static versus dynamic, to me is a really old battle. Back, oh, 20 years ago, there was this big debate and it split the standards bodies. The W3C was the original standards body for what HTML did, and then a bunch of folks broke off, creating the WHATWG. And their vision for the web, which will sound very familiar, was we can build web applications inside HTML. It is a language for building full-fledged applications. While the W3C was trying to create what they were calling the Semantic Web, and they were leaning into this idea of the web as basically being documents. Eventually they reconciled, and we get, thanks to the work and influence of the WHATWG, really powerful frontend frameworks and languages and capabilities within the browser. I think that reconciliation, in some sense, is one of the defining moments that eventually gave us the fertile ground that created things like the Jamstack and the rise of JavaScript frameworks.

00:14:26 - Ishan Anand

But to me this is that same dichotomy. Static is really what the W3C was going for, and the dynamic is more what the WHATWG was going for, if you want to oversimplify. That's not strictly true. So to me that was the dichotomy of the old, which still remains relevant today. The north-south in his quadrant, which was the local versus online, I feel like it's the dichotomy of the future. The reason I say that is, at least for the web, less so for apps, everything that you think of that's really big and is an application people use is online. Our whole world is networked and interconnected. I would really like to see more of the local-first stuff. I'd be really interested. I think inside native apps there's more of that. That's a long way of saying that I still think the static versus dynamic dichotomy is the more important dimension than the north-south. When you look at classifying all the apps out there, and you try to say, well, where do I see the most differentiation or use between the horizontal and the vertical axes, and you project them down, you'd find more distribution on the vertical axis than you would on the horizontal. That's a very mathematical way of looking at it. But basically, I think the north-south is more, I would love to see that, but I don't think it's as relevant, and it doesn't change the application you build today as much as the east-west in that chart does. Does that make sense?

00:16:22 - Anthony Campolo

So you don't think that it's important to like always have kind of an offline experience? You think people just kind of accept the need to do things online?

00:16:30 - Ishan Anand

Oh, no, I think it's important. I would love to see it. But as an observer of the state of the web as it is, not as I wish it to be, I just think the vast majority of applications sit on the online side.

00:16:49 - Anthony Campolo

Something that could actually change that would be people wanting to have their data on their computer for things like running LLMs and kind of being more conscious of security. So I think it's possible that we could see more of that.

00:17:06 - Ishan Anand

I completely agree. And that's why I call it the dichotomy of the future. Right. I think that is actually the battleground where things will be fought. I mean, the whole pressure, regulatory or social, is toward exactly that, and being able to own your data. Just look at the rise of more distributed social networks. I definitely think that's where things are going. I just don't see a lot of that right now.

00:17:36 - Anthony Campolo

Yeah, for me it's like, if it's something that I'm going to collaborate with people on, then it's just going to be online. And for stuff that I'm kind of doing myself, that's where it could be better to have some like, offline stuff. Even still, I end up then saving my own stuff in the cloud, so I kind of end up online either way.

00:17:55 - Ishan Anand

Yeah. Here's the really simple way to think about it. Practically, the last time you were on an airplane and the internet didn't work, right, what was it like without connectivity? Or you went to the subway.

00:18:09 - Anthony Campolo

Like, I wanted to jump out of the plane.

00:18:11 - Ishan Anand

It was like half your phone was useless, right? Maybe three quarters of it. You're like, okay, I can set a timer to see how much longer until I get connectivity.

00:18:22 - Anthony Campolo

I remember Twitter worked, but not images or gifs, just the tweets would come in.

00:18:29 - Ishan Anand

Yeah, it's like just imagine what it's like when your bandwidth is constrained, let alone when it's gone. I do think that maybe that might change. When you've got a local LLM, you could at least talk to it and it's got a bunch of things, but so much of it is online. So that's why I describe it as the less important dimension. And I guess here's the question I had when I was reading it: the static versus dynamic dichotomy really does tell you, should I build with JavaScript first or should I build with HTML first? Right? Or use HTMX? If somebody was trying to figure out which framework to use, this at least points you in a direction. I'm not as sure what direction the north-south part of that quadrant points you in, but maybe I'm wrong. I'm curious what you think.

00:19:21 - Anthony Campolo

Well, it mentions progressive web apps. If you want to be offline, you want to go more toward that angle.

00:19:31 - Ishan Anand

That's true. Maybe we talk this forward and walk through it. Does a progressive web app necessarily have to be built with something like React, and in a more dynamic-first implementation? I can imagine a progressive web app like a to-do list could be done as a progressive web app built with a framework like HTMX, if HTMX just adds the right capabilities for service workers and a few other things. And actually what I really like about the article is they did talk about things I wasn't aware of. What was that framework? Mavo. Mavo, M-A-V-O dot I-O. I thought that was really interesting. And that, I think, could point the way to building those types of local-first applications without any server backend. In fact, that's a great example of that. The one thing this map does is get people aware of frameworks like that. So maybe I'll take it back. Maybe what this diagram is saying is rather than... I guess this is what it's saying.

00:20:54 - Ishan Anand

Now that I pause, there are like two ways to do things, static and dynamic. So static is like HTML and HTMX, and dynamic is React. There are four different ways to do things, not just four examples of websites for those use cases. The use cases might drive four different architectures, and here's the right framework for each of those architectures. Right now we've classified across two, but really we should have four different architectures. I'm not sure what they would be. So the architecture for the informational is HTML. The architecture for the transactional is HTMX. The architecture for the upper right, which is dynamic and online, is React or RSC or Next. And then the architecture for the bottom right, which is local and offline, is Mavo, or maybe that's...

00:21:52 - Anthony Campolo

So what is Mavo like? Can you describe it?

00:21:55 - Ishan Anand

Yeah, so I honestly don't know much about it. This article that you found is actually what turned me onto it. It basically extends HTML syntax in the same way that HTMX does to describe web applications. And this idea of a declarative way of describing applications embedded in the HTML is actually an old concept. There are a couple other frameworks that used to do it. In fact, we used to work with a team that built one. Let me see if the page is still up there. Yeah, Uranium JS actually worked similar to this, because basically we were in a situation where we needed to add capabilities to a site in a composable manner on top of an existing classic HTML page. And the easiest way to do that was just to mark up the HTML. But what it adds to it is more commands for manipulating and storing data in the cloud or locally by just changing HTML attributes. And it'll do things like perform calculations. And what actually got me excited about it, if you go to Mavo.io...

00:23:10 - Anthony Campolo

It's on the Jumbotron.

00:23:12 - Ishan Anand

There we go. You can see they've got an example of an editable homepage. They have another example of, I always go to this example, a to-do list. It's the second example down there. And basically at the beginning you say, here's your app name. You then declare where it's going to store things. So you say locally in the browser.

00:23:32 - Anthony Campolo

And then this is like HTML with state.

00:23:37 - Ishan Anand

Yes, that's a good way to say it. HTML with state. And then look how the action is defined. Do you see the button has mv-action and it's like delete task where done? It's almost pseudocode. I think if you squint and think a little bit, it's not hard to imagine combining this with an LLM, especially one that maybe is native to the browser or runs locally, where you could entirely describe your application in a mix of... You can already describe your application in natural language and there are great examples of people saying build this application and it builds it. But maybe if you want a little more mix of control and complexity, you could imagine somebody using a markup language that combines natural language with a markup language to control an application, how it gets done. That's where I think, if I was looking at Mavo, I would be like, oh, that's the way to go. It's to take this and say rather than simply creating program instructions in HTML, embed natural language instructions on what should happen and describing how things should happen.

00:25:02 - Ishan Anand

And then mix that maybe with natural language descriptions of what it looks like in this weird mix of HTML and natural language. That could be a really interesting way of defining applications going forward.

00:25:16 - Anthony Campolo

Yeah, you know, I see so many of these projects now that are really HTML-forward. Even going back to Astro, one of the things they were saying... So I'm curious how far this trend is going to go because looking at these examples, they kind of look like early days Angular, Vue, where you're just adding these kinds of tags into your HTML.

00:25:41 - Ishan Anand

Yeah. I mean, there is a point at which you cross, again, the boundary on that chart between static and dynamic, where it gets so dynamic or complex that you're actually building a full-fledged application. Like if you were going to build Figma and you said, well, let me start and build the first version this way, I would say, well, okay, you can do that for product validation, but no, you're going to have to throw that architecture away and rebuild it. There's a point at which this doesn't work or make sense for a certain class of applications, and it won't stand up to a certain level of complexity. But there are so many websites where you can just use money as a proxy for value, whether it's like Salesforce is a great example, or buying stuff on Amazon, or pick an ecommerce site, where the level of interactivity may not require that much JavaScript sophistication. I think what got us here was, and this was the other thing that was kind of left out when I was reading the article, it's ignoring the pressure that was put on the web.

00:27:00 - Ishan Anand

If you go back to when this split happened between the WHATWG and W3C, around the same time, or maybe a little after, you had the iPhone come out and there was this existential crisis for the web, where people just loved the interactivity and smoothness of native apps. And there was a feeling that in order to compete, the web needed to not only deliver that same quality experience, but also architect applications the same way. We need to build our applications as large globs of code that talk to APIs the same way native applications are. It's the only way to build a PWA, for example, even though that's not technically true. The other thing that was alluded to either in this or one of the other links you shared in the newsletter was things like the View Transition API and invokers. I think they point the way to building web applications using simpler primitives that feel more like classic multi-page apps, or classic hypertext, without having to have all the JavaScript but still delivering a compelling experience. So in the case of the View Transition API, you can have that nice sliding feel, but you don't have to necessarily code a whole single-page app with that level of complexity.

00:28:28 - Ishan Anand

You can just keep sending mostly HTML. I think that's going to be part of the move back to a lot of these tools. And Astro, I think, has been one of those frameworks that's been at the forefront, with great examples of using that with the View Transition API. Actually, Astro's been... The other thought I had was just how great Astro has been about molding itself to the moment, or at least being flexible to the moment, whether it's HTMX or Islands architecture or a variety of other things. It's just, I don't feel like they

00:29:02 - Anthony Campolo

don't talk about Islands at all anymore. I can't remember the last time they mentioned Islands. That was the thing when it launched, and I was just kind of like...

00:29:10 - Ishan Anand

Eh, yeah. Well, I feel like here's kind of the product-marketing thing about it. I think they picked up some amount of attention, and you keep moving from thing to thing. Last episode, Dan was talking about how he feels like Next did a really good job of kind of embrace-and-extend, and it did it to things like the Jamstack. And I feel like that's another way of looking at it, just staying relevant to the moment. I feel like Astro is doing a really good job of that, whether it's Islands or now with HTMX. You shared, for example, that video. I think it's Harrington doing an HTMX demo with Astro. It's just like whatever the new thing is, Astro's there. Or it was Solid used to be part of Astro. I think Solid moved out, but it's just Astro's there. And I think that's only going to work to their advantage, and it speaks to the flexibility of the platform as well. So if I'm wrong about my bet that the biggest threat to Next is going to be HTMX, I'll say that the most likely way I'm wrong is because of Astro and the flexibility it gives you.

00:30:28 - Ishan Anand

That's the other contender. Although technically you can use Astro with even a non-React framework.

00:30:33 - Rishi Raj Jain

But the concern that I feel is how do you server-render HTMX even if it's dynamic, right? With RSCs, what you get, even though they're complex to understand, is you still get that server-side render with interactivity, at the cost of network waterfall, let's say. But how do you do HTMX? So that's the blocker for taking over the Next ecosystem, is what I feel.

00:31:05 - Ishan Anand

So I guess the way I look at it is HTMX essentially assumes a server-rendered starting point. Your starting point for HTMX, I think, is a page that is already, in my head, mostly server-rendered, and you're basically marking it up with HTMX. There has to be something, which could even be non-JavaScript, it could be PHP or Java, and they want to add interactivity to the page. They're probably going to pick something like HTMX. So I guess my answer to that is, when I said sites that are already, let's call it backend-driven, they're almost inherently already server-rendered. Does that address your question, or maybe I missed?

00:31:45 - Rishi Raj Jain

Right. So looking into that, if you're talking about Django, maybe Flask sites, I think those are mostly server-rendered around the backend, right? It does make sense there. But I'm not sure how it actually takes over Next or threatens their ecosystem, because those are the kind of people who are not shipping Next, you know, they're shipping Django sites or Flask sites or maybe Streamlit apps. So that feels like a very different area of concern, probably. Does that make sense?

00:32:20 - Ishan Anand

I think we're saying the same thing. If you're building that type of site, you probably weren't going to use Next, right? I think there was a lot of pressure on folks in the past decade or so, which was, oh, the right way a sharp engineering team builds a website, regardless of what the backend is, is you build it in Next or you build it with React. React is the way sharp engineering can build. In fact, even if you're planning to send just HTML or just a bunch of APIs, you spin up a Node server just so you can have something that creates a React or JavaScript-heavy experience so you can get that kind of native-like quality. I think what HTMX is basically giving people is the license to say no and push back against that and say, no, we are a Python shop, or we are mostly a backend shop, and we just need a little interactivity. It's overkill to add all this complexity just for this because it doesn't fit.

00:33:29 - Ishan Anand

We may not even have the budget for a large engineering team. I think we're saying the same thing, which is that it wasn't a good fit to begin with. But I think a lot of those people faced a kind of headwind that said that they needed to do that, partially for the reason that not only was it this kind of engineering, like this is the sharpest technical way to do it, but also, again, to compete with native apps, people thought websites needed to be built this way.

00:33:59 - Rishi Raj Jain

Right, I see.

00:34:00 - Ishan Anand

So you tell me.

00:34:00 - Rishi Raj Jain

I think, yeah, I do see that coming. And taking it over by actually migrating back to the process of server-rendering your Python apps and just adding a little interactivity on top with HTMX. Yeah, I think if that's going to happen, then it's going to add a lot of, what do you call it, learning curve to the existing journeys that people have heavily invested in with React and again take over this system of Next. And yeah, that would be huge, man.

00:34:34 - Ishan Anand

Well, I mean, so my statement last episode was actually that I don't think you can compete with React and Next with the same customer base. It's like disruptive innovation. There's already an entrenched competitor. The only way you're going to displace it, they say, is there's another larger market or another customer set, and maybe we can cater to their unmet needs. You don't want to, like Sun Tzu, attack strength on strength. So I think trying to unseat Next by just building another JavaScript framework in the traditional sense, or even another React framework, is just harder to do because they're the entrenched competitor. And so what you have to do is find, in classic disruptive innovation, another audience where your application or your solution to the problem may not be good for the traditional market, but it's good enough for some subset, and they get excited about it and enthusiastic, and gradually you build up enough capabilities that you can eventually start stealing away from the larger market that you couldn't go after directly.

00:35:51 - Ishan Anand

So that's basically what I was saying. I think we're saying roughly the same thing, which is that it's not a good fit. If you took a Next developer and gave them HTMX and they needed to build, I don't know, Figma or even maybe a dashboard, they're going to be like, no, this doesn't make sense. It's a poor fit for that. But there are simpler sites where people were told you need to build it with Next, and I think the tide is turning on that, and people are like, oh, maybe I could just use HTMX instead. That's just my two cents.

00:36:26 - Rishi Raj Jain

Right?

00:36:26 - Ishan Anand

Okay.

00:36:27 - Rishi Raj Jain

I could also see WordPress sites using it, but yeah, there probably needs to be a middleware or edge layer on top of the WordPress site to handle that interaction.

00:36:44 - Ishan Anand

I could totally see it for WordPress.

00:36:47 - Rishi Raj Jain

Right. So that would be a totally different market from Next, I think. Not totally, but yeah, I think it's a big market to cater to.

00:36:55 - Ishan Anand

Yeah, it's probably the biggest, right? Forty percent of the internet. I've actually thought a lot about this. There was this project, Frontity, that tried to be the canonical way of building sites with React plus WordPress in a headless manner. There was a lot of attack, or kind of attack on the WordPress ecosystem, from the Jamstack/React ecosystem as well. WordPress also uses React for the new version of the editor. In fact, I saw a comment thread, maybe it was actually in response to the thread you guys were talking about... Oh, I know where I saw it. It was on Hacker News in response to Cassidy Williams's article, and it was actually from one of the people who was part of the team that decided to use React. And yeah, I think maybe if they would do it over again, maybe it might make sense to use HTMX. But at the time they made the decision, React was clearly ascendant, and I could certainly see a lot of value in something like HTMX in that ecosystem.

00:38:14 - Ishan Anand

I mean, just look at, I don't know, like half the plugins that are, call it pro-user-level. They give you some capability to create like a pseudo-markup that lets you describe your use case anyway, whether it's form builders and things like that. I could totally see somebody saying, hey, why don't we just give them HTMX? It'd be nice if that was built into Gutenberg. In fact, I think that would make a really interesting WordPress plugin, something that just lets you build stuff with HTMX right there inside the editor. I've actually recently been a lot more bullish on WordPress, gradually, over the last few years, and I think there's a lot of potential there. I completely agree with you.

00:39:02 - Rishi Raj Jain

What are some of the top sites that you've seen built with WordPress? Because I'm...

00:39:08 - Ishan Anand

What is it?

00:39:09 - Rishi Raj Jain

Yeah, because I'm wanting to dive into that space, because I've been lately into the frameworks. But I want to expand beyond that. What are the best WordPress sites that you have seen

00:39:23 - Ishan Anand

in terms of size or quality?

00:39:26 - Rishi Raj Jain

Yeah, I think it's about the size that they're serving. So let's say a Next.js production website versus what is that site that you see in WordPress?

00:39:39 - Ishan Anand

Well, you know, I actually looked at this the other day. I don't know them offhand. Let's see, most-trafficked WordPress sites. Well, let's see, websites using WordPress with high traffic volume. So according to BuiltWith, which was the first or second link on Google...

00:40:09 - Rishi Raj Jain

We've got...

00:40:10 - Ishan Anand

So this may not, because it's built based on their automated system, I'm assuming, but Bloomberg, Booking.com, interestingly, CNET. You're going to find a lot of content.

00:40:20 - Rishi Raj Jain

Oh okay. Yeah.

00:40:24 - Ishan Anand

NPR.org, it says T-Mobile.com. Let's see, TripAdvisor. What else? I think I said this... Actually, a year ago I went back for the 2024 predictions. I went and listened to our ones in 2023 and WordPress came up. And I said you should pick the framework or technology that optimizes for the thing that needs to move the fastest. If you're building something like Figma, then the most important thing is being able to push out new features. So you want something that lets your developers move the fastest. But if you're building a news site, the thing that needs to move the fastest is getting content out there, right? And that's hugely important. So then build something that's a CMS system at heart like WordPress, because you need that more than you need to be able to push out new features or flashiness. Let's see, WPBeginner has Sony Music, PlayStation, TechCrunch, Time Magazine, CNN Press Room, Disney Books, Hypebeast, Wired, Microsoft News, TED Blog, Yelp, Vogue. Let's see, the Mozilla blog, the Harvard Gazette. What's really interesting, though, is some of these, it's not their primary site.

00:41:54 - Ishan Anand

So, for example, they have The New York Times Company. It's the corporate website behind the New York Times, so it's not that the New York Times runs on it, but their corporate website. Another one, Vogue, it says the domain Vogue runs on it. But like Yelp blog runs on it, but Yelp does not. Etsy Journal, but not Etsy. So they're associated blogs. So it's still very much on the blog side. Now, I do know they acquired WooCommerce to do a lot of ecommerce, but I think what you find is a lot of folks in ecommerce either graduate past a certain total merchandise volume size toward a more enterprise ecommerce platform like Shopify or Magento if they want to stay in PHP world. I'm more used to large ecommerce sites on Magento. But when you're already running 40% of the internet, I wouldn't count WordPress out, and I could certainly see them going after that segment as well.

00:43:13 - Ishan Anand

Let's see, Reader's Digest, 538, Variety. This is on WPBeginner's website. Let's see what else. Time magazine came up. This is on the InfoStrides list. But, oh, 9to5Mac. So those are some examples, but again, mostly informational. Going back to the post that Anthony referenced in our newsletter, most of these are in that informational quadrant because the most important thing is spitting out content. And WordPress is great for enabling content creators. That's the thing that needs to move the fastest. I actually think WordPress is a good MVP framework for certain areas, but that's like a nascent idea that's developing in my head. If you want to spin something up really quickly, it does have login and some of those other things, if you're willing to squint. And I plan to do some experimentation with that. But that's my thoughts there. Does that answer your question? Cool.

00:44:34 - Rishi Raj Jain

Yeah, I just wanted to know... So I'm visualizing an intersection between interactivity and content-rich, but I feel that WordPress sites are more content-rich, or as you said, on the informational side of the graph. So that would be running parallel with the Next or interactive ecosystem, compared to the content ecosystem. Not sure how I can extend my skills to that particular space. But I've seen websites making it easier to deploy WordPress websites and make them faster or more dynamic. I still wonder what value that brings compared to just running on WordPress.

00:45:24 - Ishan Anand

Yeah, I cannot claim myself, at this point, an expert in that ecosystem to know. I've helped people with their WordPress sites. But I do think, as somebody coming from the Jamstack or very JavaScript-centric world, WordPress has been underappreciated. I said back a few years ago, it may turn out the biggest headless CMS is actually WordPress. I think that may not turn out to be the case, but I still think it's got a lot of potential and I'm really interested to see where they take it.

00:46:08 - Rishi Raj Jain

[unclear].

00:46:13 - Ishan Anand

Anthony, was there anything else on that as we move to the rest of the newsletter?

00:46:18 - Anthony Campolo

Yeah, I think that's probably good. Were there any other links that piqued your interest?

00:46:28 - Ishan Anand

So let's see. There's another one about HTMX. I didn't get a chance to look at the one on the screen. Data benchmarking... There was a podcast episode which I didn't get a chance to listen to before, but it was Deno in 2024. Was there anything interesting that came out of that, or what you thought of it?

00:46:56 - Anthony Campolo

I haven't listened to that one yet, actually, but it's a Podrocket, so I know it's going to be good.

00:47:02 - Ishan Anand

Okay. The other one that caught my attention was the Streamlining AI one. Did you get a chance to listen to that one?

00:47:12 - Anthony Campolo

Yeah, so that one is really interesting. I've been looking for more JavaScript AI-related stuff. They talk a little bit about Super Agent, which is another one of these AI frameworks that is probably fairly similar to something like LangChain. It's for building AI assistants. I think we're seeing this a lot with what are they called, agents, that are basically LLMs that can kind of follow instructions. So this is a project I hadn't tried yet, but they have a JavaScript client. Obviously that's why they were on JavaScript Jabber. So I'll probably check this out along with all the other AI JavaScript stuff I've been checking out.

00:48:02 - Ishan Anand

So how is it different than, say, LangChain, for folks who are familiar with that?

00:48:11 - Anthony Campolo

You know, it doesn't seem like it integrates with as much stuff. I think it's because LangChain, you can plug in almost anything, whereas this seems a little more self-contained. It lets you connect to some data sources and then kind of create your own agents. So I'm not sure actually what models it works with. I would assume you can probably do ChatGPT and stuff like that. But I would have to try it to really see what the biggest differences are.

00:48:53 - Ishan Anand

Okay, so whereas LangChain, I think you can use it for all sorts of, call it, orchestration of a workflow that is AI-enabled, or even AI-central. My impression from briefly looking at it is that this is entirely for assistants. So rather than you might use LangChain to enhance an existing workflow by sticking it inside it, this is entirely for building your own version of ChatGPT, or a custom GPT, for your own unique use case. But it's still like a chat-driven interface. It maybe integrates with the things that you control with it, but it's more for that, whereas LangChain can do that, but it can do other things.

00:49:40 - Anthony Campolo

Yeah, yeah. LangChain has an agents capability, which is like... you could think of this as just the equivalent of that. And then it has things called workflows. So it's basically like a sequence of agents that run in a specific order. And then they have integrations with things like Algolia, Bing, WolframAlpha. Looks like they also have OpenAI. Oh, that's OpenAPI. There's a ChatGPT plugin and ChatGPT or GPT Vision, so it must be multimodal as well. And then they have vector-database things as well, connectors.

00:50:22 - Ishan Anand

So what do they use as the LLM? Is it flexible like LangChain where you can swap in particular models? Do they prescribe certain models or vector databases for handling it?

00:50:43 - Anthony Campolo

It's not super clear. I'm reading their docs. There's a page called Concepts and they have a section called LLMs. They're like, language models are the core computational models that power the functionality of an agent. It says in the context of Super Agent, they're used to understand and generate text. They're trained on vast amounts of text data and learn to predict... like, it doesn't say what the LLM actually is.

00:51:11 - Ishan Anand

Got it. Okay, I'm going to look through. Oh, I found an example where it references an OpenAI key.

00:51:21 - Anthony Campolo

Yeah, that's the Forge example.

00:51:22 - Ishan Anand

So yeah, okay, so it's again an orchestration layer that manages essentially models and these other things. So whether it's the vector data, it's kind of the glue between everything. Okay, that's an interesting episode. I'll have to check it out. There was another one on JavaScript performance wins and new Node.js features. Well, actually, why don't I pause here? Why don't I turn around and ask you what you thought was the most interesting when you were putting this together, or is there something you left on the cutting room floor?

00:52:08 - Anthony Campolo

No, I don't think so. I thought the article on NPM in Review was interesting because it has a ton of data in it. It ranks the top 50 packages by how many other packages depend on them. What do you think is number one?

00:52:28 - Ishan Anand

I don't. I should have an idea. But what is number one?

00:52:32 - Anthony Campolo

TypeScript.

00:52:34 - Ishan Anand

Oh, of course. Yeah, that makes perfect sense.

00:52:37 - Anthony Campolo

I thought it was interesting though. Second is React and that's pretty amazing to me because, you know, NPM predates React by a few years.

00:52:47 - Ishan Anand

Yeah, by dependency count, so the number of projects that depend on it. You're right, because NPM came from Node and Node originally was backend, and React, until RSCs, has been frontend. So I'm pulling up the link right now. And again, folks can go to javascriptjam.com, go to this week's newsletter in the header, and see this. But yeah, we've got TypeScript, React, ESLint, @types/node, react-dom, Jest, Prettier, tslib, Babel, Lodash, Axios, ts-node, ts-jest. I don't know what Rimraf is. Then webpack, Rollup, Vite.

00:53:48 - Anthony Campolo

Rimraf is like rm -rf, but a package that's used to delete Node packages.

00:54:01 - Ishan Anand

Oh, wow, okay, that makes sense. Webpack, Rollup, and then Husky. What is Husky?

00:54:11 - Anthony Campolo

Husky is like hooks, like Git pre-commit hooks.

00:54:17 - Ishan Anand

Oh, yeah, I see that. Okay.

00:54:20 - Anthony Campolo

Which some people hate and on principle will not use.

00:54:24 - Ishan Anand

Okay, and then I see Sass. So what, anything that surprised you here on the list?

00:54:30 - Anthony Campolo

Like I said, kind of the fact that React was so high. But mostly this is what I would expect, especially because most of these are what you use to set up a basic project. Things like ESLint and Prettier are installed by default by most people. So I think this kind of shows, when someone's spinning up a project, what are the things they're always going to download, and that's mostly what we see here.

00:54:57 - Ishan Anand

Yeah, that makes perfect sense. But I mean, this isn't just downloads. These are dependencies, right, if I'm interpreting this correctly.

00:55:09 - Anthony Campolo

Yeah.

00:55:09 - Ishan Anand

And so, yeah, they have a chart below which is downloads. My interpretation of this is that it validates your sense that the frontend ecosystem is massive and keeps creating new frameworks and new stuff and just will not stop spinning up new forks and variations and new projects, way more so than the backend ecosystem does. Because to me, this is number of projects that reference it, not even by popularity. And if I'm interpreting this correctly, it's just showing how much people are building things that reference React, whether it's a UI component library or something like that. It's just showing the health, or churn.

00:55:54 - Anthony Campolo

Yeah, yeah. And Vue is also in here, but Express just barely comes in at number 50, and that's the only server-side framework I even see.

00:56:05 - Ishan Anand

Yeah, right there at the bottom is Express. You're right. You should be asking yourself why Sass is even higher than Express, right? That just goes to show you. You could take a binary weighting of this and say, is this frontend or backend? Maybe you'd say neutral for TypeScript, right? And then if you took the expected value of this, it would be extremely heavily frontend. So it just shows the amount of project sprawl, if you want to be negative about it, or health or innovation or experimentation if you want to be positive about it, in the frontend ecosystem. Wow, that's really fascinating. I love data like that that tells you something about the ecosystem. That was a really interesting find.

00:56:51 - Anthony Campolo

Yeah, this is from Socket, which is that company that is based around giving you higher-level security information over NPM, because NPM is a security nightmare.

00:57:05 - Ishan Anand

I liked that they had, what is the package with the longest name? Those are interesting. There's one like, this package exports the number 214 and its name is also 214 characters long, which is the longest name currently allowed by the NPM registry. To see how a name that long would look if you did it right. It's like you'd ask ChatGPT, come up with a 214-character name for an NPM package. And then the other one was like, if you want to get the sum of two numbers where those two numbers are chosen by finding the largest two out of three numbers and squaring them, which is multiplying them by itself, then you should input three numbers into this function and it will do that for you. Yeah, exactly. I think these are just like, the number of dependencies must be one or zero. And then there's the person who just did all A.

00:58:11 - Anthony Campolo

That doesn't have a link though. How do I know that one's actually real?

00:58:14 - Ishan Anand

Yeah, I want to make my project depend on that and it'll be all Bs. So that was interesting. The other part that I thought was interesting in this post, because I'm looking at it at the very end, is the package with the most maintainers.

00:58:35 - Anthony Campolo

These are almost all the BBC. Almost all of them. Interesting.

00:58:41 - Ishan Anand

I wouldn't have expected that. And then Conde Nast too. But props to BBC for being so collaborative. That's really interesting. I don't really know how to interpret that, but it sounds like a positive. So that's very interesting. Well, we're coming up right at the top of the hour. I think we should probably call it for this week. Thank you everybody for tuning into JavaScript Jam. Just a reminder, we now do JavaScript Jam every two weeks, noon Pacific time, every Wednesday. So we will see you again in two weeks here at JavaScript Jam. Thank you everyone for tuning in.

00:59:34 - Anthony Campolo

All right, catch you next time. Thanks for coming, Rishi.

00:59:37 - Rishi Raj Jain

My pleasure. Catch you, everyone. Have a great one.

00:59:40 - Anthony Campolo

Bye-bye.