Future of Frontend Frameworks Fireside Chat

Thank you for being here. This has been an amazing day so far. And we still are going to have one amazing fireside. I said the word fireside, but I don't see any fire around here. Can we get some fire somehow here? Okay. An applause for the fire! Every fireside needs something like that.

So now I'm just going to call by the order that we have here, our speakers, and they're going to go one by one, but I'm going to ask you as I'm introducing them for you to give a big, big applause for each one of them, and starting with the first one on this side, which some of you already saw on the stage today, very likely. So give it up for Ryan Carniato, the creator of Sava.js. Okay. Keep it going, because now we're going to invite the product lead for Angular, Minko Getsev. Continuing with our next panelist, the co-creator of Astro, Fred K. Schott. Come on, let's go. We're still going on the flow, because our next panelist, she's one of the core maintainers, right? And we're going to invite Akanksha Doshi. Come on, applause, everyone! Energy! We need to keep this discussion alive. And last but not least, so this person you might know from the panel before earlier today, but he's also the co-creator of Next.js. So let's welcome Tim Neutkens!

Okay, and now I'm going to take my position on this chair. Let's get this discussion going. So we're going to start with one topic that Ryan already has on his shirt, I guess, which is signals. As we have been getting aware of, most frameworks have been getting all on signals lately. How do you all predict that signals will grow and keep impacting the ecosystem? Who wants to go first? Can we start with Ryan? Because he's got signals! RYAN NEUKOMPTON Yeah, okay, sure. I mean, it's funny, you think I would be able to predict these things, but I honestly didn't see us getting to where we are today where most of the major frameworks and some less major frameworks are using signals. I expect that trend to continue. The thing about signals is it's not about adding signals and suddenly getting these benefits. It's what you can take away. And we're seeing that across a large part of the ecosystem, adoption by many frameworks, some which have here with us some panel, and just simply seeing more benefits we can get from having data flow known to the application, basically. This applies in lots of ways. It solves server-side rendering hydration, things like resumability. It honestly will give us incredible insights into tooling. Wouldn't it be great if you could open up your VS Code and basically when you go to update some state, it will tell you every part of your app that can update.

We know this simply because of the way signals wire up. So it's very exciting and even more exciting now because, you know, what might have started with small niche groups are now seeing, I don't know, thousands of developers now being able to use signals which is very exciting from my perspective. Microphone test? You can talk into my cheek. There you go. Let's try. All right. I have two microphones.

Based on everything that Ryan said, definitely they're going to help a lot with tooling, and in Angular we're really interested in using signals for partial hydration because we are aware of the data flow. We're chatting with Evan Yu before Jazz Nation like two days ago, and it's really exciting how signals can also enable code reuse across frameworks. Imagine building business logic or like some kind of hooks in one framework and being able to reuse them across all the frameworks in case signals become part of the JavaScript standard where they're hitting right now. I got nothing to add. It's working.

Okay. So I think, yeah, I mean, it's definitely true that now signals like apart from React probably all other popular frameworks and libraries are using the concept of signals, not directly, but still they are using the concept of signals. And the concept of signals I think has been there for long. I think KnockoutJS probably was ten years back, 2010 I think it came out, and they had they were probably the first one to introduce the concept of signals. That's what I read in the proposal. So the concept has been there for so long.

Now we are trying to standardize it so that there are different libraries, but under the hood sort of they use the same concept. And that's where I think the frameworks are slowly adopting it. Probably for React maybe if not using the signals directly because the way it works with the virtual DOM, but maybe it may combine with some state management library like recoil which is also using the concept of signals somewhat. So yeah, maybe we will reach a stage where all the libraries and frameworks will be able to utilize the performance improvement of signals which signals is giving you. At the same time, the way you write code when using signals is something which we are not used to. That is a concern as well at the same time. We have been writing the code for years. And probably we might be a little reluctant to, hey, now I have to change the way I'm passing the props. I have to use those braces to write the code. So probably that is where the learning curve will also come. So that is like a trade-off I would say. But yeah, the future of signals I think is really bright.

And hopefully all the frameworks and libraries will be able to utilize the performance benefit of it. Does anyone else want to add something?

Okay. What's up to the next question? So I'm going to talk about something which some of you might have heard. Angular is merging with Wiz, and the question that I have on this scenario is, do you all think we could see some of the frameworks in the future going in the same direction somewhere, somehow? Do you mean merging between multiple frameworks, or merging between frontend libraries? So in this case, merging between multiple frameworks. Probably not.

Right now on this day it's solid and React. It's nice to see that there's another angle to this, which is all the frameworks that you see coming out now, they're learning from the past. Like, Astro comes out and it's got some better things than Next.js had before, for example. You see this with Remix and Next.js, for example, where Remix had actions and things like that, and we worked with the React team to bring some kind of actions primitive to React itself, right? And those are now, like, now the Remix team is adopting the server actions in Remix itself as well, and they can share these between the frameworks, right? Once it's fully implemented, they're still working on it. But that's like a thing that's probably more likely to happen, which is that the frameworks are built on the same rendering libraries, so like Next.js, Remix, Astro, with React Island, they will be able to share more components, because previously the data part was never part of the model. Whereas now it's part of the model as well. So you can do data fetching that actually works in all frameworks on top of React, right? Like less so between React Angular, Solid, that kind of thing.

Okay. Was it Rich Harris who said people choose frameworks based on their vibe? I think that was the quote. I don't know whether that's a good or a bad thing. I'm maybe not as positive about it, but I actually agree with him almost wholeheartedly. So as long as there's different vibes, you're going to have different frameworks. So even if, you know, part of it is, like, there's a technical aspect, and I think that we are seeing the emergence, at least right now, of at least a couple different, like, high-level architectural approaches. So you could say, argue that some of these could merge together, you know? But I mean, see people bike-shed over syntax. Like some people will never pick up JSX, some people will never give up their single file components. It does not matter to them that in the end, if you grab maybe Vue Vapor, Salt 5, Solid JS, the output might be almost identical, but they all have different syntax. So from my perspective, it's quite possible that we're converging, but people will probably prevent that from ever actually completely happening. Yeah, I agree with everything that Tim and Ryan said. We are probably going to unify on some shared primitives over time and shared practices. I see how we can, for example, start using all Vue transitions for routes animations. That's going to be awesome. A lot of the frameworks are sharing signals. We're unifying on similar ideas about fine-grained code loading. And it's so hard to unify on syntax. So many strong feelings about that.

I will say, I love that vibe comment, because I feel like it is actually a reaction to the fact that none of us will ever take a stance on what our thing is good at. Like, you go to Svelte's website and it's like the syntactical... What is it? It's like the synthetic... Cybernetic. Cybernetic web browser. It's like, that's not why you use Svelte. You use it because it's really good at data visualization. It's really nice kind of HTML familiar syntax. It's great for learning. It's really powerful. React is really good for these. It's a standard JSX. It's such a safe bet if you're building your company. Solid is super performant and is leading the way. So I think sometimes when we say vibes or we talk about merging these things, I think it's good that everyone has a focus and a vibe, a thing you do well, like Astro's content focus. And I think that's, if we all went down to the lowest common denominator of some one tool to rule them all, I think we would lose out on... Not every use case is the same. Not every technology should be the same. I think it's good that different frameworks or different libraries all do things better or worse or different and have different focuses.

Also, I think I definitely agree with what everyone has said. Additionally, I think instead of focusing on merging the frameworks, I think it should be more about standardizing the principles used behind those frameworks, because then probably it can be possible in future that in the same application, some part could be in Next.js, some part could be in Astro, some part could be in some other framework. So you get best of all the three, depending on the usage. But merging and coming up with a single thing also leads to... I don't know the maintenance part, how it is... That will be impacted, because now both the teams will be involved in let's say pushing out some feature and then deciding on what you want to do it, how you want to do it, and things like that. So I think, yeah, I mean, let there be different frameworks, but let's try to standardize the principles behind building those frameworks instead of merging those frameworks.

So, picking up on what you just said, would you think something like is happening right now with the TC39 proposal for signals? Something building up on top of that, could we see a standard signal implementation going on from all frameworks that are already using signals converging on top of that proposal? So that adoption of just using that implementation of signals, basically. It's possible, and everyone is probably going to have different wraparound around that that matches their specific syntax and component altering format.

Okay. So one question that I would like to ask you as well right now is, let's for a moment forget all the stuff that, like, okay, you have been working on the things that you are building on your day to day, and let's imagine anyone here from the audience comes up to you and says, okay, I need help to pick a framework somewhere, somehow. This is the question they're going to make you. What would be the advices or the follow-up questions you would ask for them to help them decide what's the best option for them in this world of all of these frameworks? I think this is the question which every new developer diving into the frontend has, which one should I choose? There are so many libraries, so many frameworks. Why should I choose React or why should I choose Angular? I think all frameworks and libraries are really good. There are good things and tradeoffs in each and every library. Since we have so many options right there, people end up spending time, which is expected because they want to take the best. That is what we want to do. But I think when it comes to usage, every library is actually doing good. I won't say that Angular is bad or React is bad or solid is bad. We need to, what we do is we pick one library and we stick with it for years and we maintain it. That is something which we do. Once we start, let's see if I pick React. I have been working with React for some time, so it will be hard for me to just move out of React and switch to Angular right away, because the amount of time you have contributed to learning React, the way things work in React, that helps you to build better applications with time. So I think my answer would be, I don't think there is a clear one answer for this. I can't just say that, pick this framework. It would be like, pick one framework, go through the community, go through the documentation, the learning curve, stick with it and go ahead and use it. I think that is something which I would suggest. It has to come down to their outcomes, right? If the question is, what framework should I learn to get a job? I can give a pretty short answer to that one. PHP. Otherwise, I'm just going to say, if you have the freedom, definitely vibe.

That's my short version of that. Go to the docs, get a feel. It's funny, I view frameworks almost like people, which is kind of strange. There's design ethics. You're not going to pick it up and understand all the details at once. People it's complicated, there's hidden bits, there's things they believe, things they put on the surface, things they hide. It's kind of interesting. If you have the freedom to, make a gut decision off the little information you have and see how you feel about it.

Other than that, often it is not your choice. In fact, very often it's barely your choice. In that case, just be sensible. Choose what will get you the job, which will help you accomplish what you need to get done with what you already know, where you're already standing. You can't really go that wrong. I'm thinking, definitely worth exploring as many technologies as possible to learn different ideas, different paradigms. At the end of the day, if you have a job that you need to do, it's good to pick something that you know is going to support you and you'll be able to sleep at night.

I remember I tried learning web development first ever was on Rails. I ran the little init command and 20 folders, 50 files. I was so overwhelmed. This was meant to be the really helps you framework and I ended up dropping it and using Python with Django. The only reason was because when I got started, I think there was five files. That was the thing that for me at that time was like, oh great, I can reason about five things, great. I used that framework for two years, just strictly because of that. It didn't even come down. I don't know if one of those was more helpful in the end, but one of them was able to get out of my way. Maybe that was my personal thing. Maybe other people aren't overwhelmed like that. Whatever that is for you, I think the thing that lets you start building and start seeing something come out of it, if that's what keeps your attention, for me at least, that was the big unlock. You're probably overthinking it, I guess is my short answer. You do something and work with something that makes you feel like you can keep the attention and keep the focus and have some fun with it. I definitely agree with what everyone said, especially what Ryan said, whatever gets you the job.

Oftentimes, it's like you don't get to make the choice. Someone else had made the choice five years earlier and you're stuck with that particular thing because you have to ship other things, so you have to ship actual features, that kind of thing.

One of the things that you can think of when you're choosing between libraries or frameworks is also the other parts, which is that am I going to build all the components myself? Am I going to build every single button, build my own design system, build all of these things? At that point, you can say any framework is good enough. Maybe you want to ship something really fast and you want to make sure that these are... You already have a set of components that you can use, like a design system that someone else has built. At that point, you can compare, what are the design systems? What are the limitations they have for React solid or Angular, for example? Then choosing frameworks is another whole thing because even if you choose React, you might have to choose between Nexus Remix, Astro, some of the newer frameworks, that kind of thing.

In the end, a lot of it is like it depends. It's where do we want to be in five years? If we're talking about five years, maybe that's too long for you, it's too short for you. Some companies think about ten years in the future, we still need to run the same stack. Others are like next month we're going to re-write everything because that's what I like to do. Maybe we'll use Angular, for example.

Something some people have been wondering and something that I've heard a lot online is people talking that it feels like web development is on a loop. We're picking up concepts that we had years ago and we're just bringing back stuff from the past, now with better technology. What is something you would like to bring back or think should make a comeback? Flash the bling tech? I'd say Astro is very much an exploration into that question. The whole MPA architecture, that idea of server rendered web pages versus JavaScript app rendering, that's the web from 20, 30 years ago of just servers running. Obviously, that's an idea that all the frameworks now are exploring. We definitely just jump straight into that and separating the front end from the back end in that way and letting us then play with Solid and React.

I think that's a natural part of things just are constantly changing. I have a serious one now. Also in the... That's compared to the blink tag.

They start to break down. Then technology advances. Now, some old idea actually makes a lot more sense. These ideas kind of flush around, like view transitions, which I got up on stage and showed off. That is such a cool technology that totally changes, at least for me, the formula of when I click a link, what should happen? Who's responsible for that? Is that the browser, the framework, the developer? A feature like that can just totally change that formula in ways that take another decade to kind of figure out what that means at the end of the day.

I think that's a natural part of things just are constantly changing. I have a serious one now. Also in the... That's compared to the blink tag. In the past, back when I was doing web developments, 15 years ago, we used to use the web platform very heavily. After that, the requirements for web applications evolved so quickly that the web platform couldn't catch up. It was trying to guess where to go and created some abstractions that we don't really use. Web components could be great. Very few people are using them, for instance. I've been seeing a shift lately where the web platform is evolving based on the shared requirements of different frameworks, and they're adding abstractions that are actually helpful, pretty helpful. We're incorporating the web platform more and more over time. We have to shift with JavaScript. We're using more JavaScript standard features across frameworks. You can see that in Remix. You can see that with Astro, in Angular, and Next, and other frameworks.

Whoa! The infrastructure is falling down! Okay. It's because of the fire, probably. Yeah. So, we have three minutes to finish this fireside. And before the stage catches on fire, because of all that fire that's there, could you... Let's try to leave this with something that... To look for something exciting. What for all of you is exciting in the future of front-end frameworks? What are you working for right now? I think the first one would be some kind of standardization as much as possible. That will also help... That will also make it easy for the application developers to just choose one library or framework, because then ultimately I think it will boil down to how you write the code.

Because under the hood, we will probably have a lot of things which are standardized. So the way... If you're writing JSX or you're writing it the Angular way or the solid JS way, so which syntax you like the most, which according to you has the least learning curve, pick up that. That will ease the process.

Secondly, I think... When it comes to choosing a framework and I want to build a project, it doesn't stop there. I have to think about what CSS framework should I use. Should I use Tailwind? Should I use some other style components? Should I use CSS modules? What should I pick as a bundler? Should I pick Webpack? Or should I pick ES build? There are a lot of stuff like this. Will the components be accessible? So I think at one point, probably if we can have some standardization where the frameworks would support some kind of standard libraries, which they agree with, that might not make process easy for us, the existing developers, but definitely for the new developers, because they don't have to spend time in choosing stuff. So at least there will be some default config which we have right now, some default support. And then if you want to update the config, please go ahead, and you will have the options to choose the other libraries, but at least it will, I think, reduce the brain cycles of the new developers jumping into frontend and choose the framework. I see that as the future.

I would like... If each one of you could... I gave an entire talk about what gets me excited about the future, so I will shut up a little bit, but I think every project up here has awesome stuff going on. I think, like, so thankfully you all are pushing stuff forward that the Excal draw exists. Stuff like that is so cool, so yeah, I have tons to get excited about. I mean, I'm excited to see if the topic of my talk this morning can truly be solved. I want to know if there is one app, like, one ability to present a single paradigm that can work for sites and apps, unify the web. I don't know if this is possible, but I want to find out. I'm excited about shipping less JavaScript to the browser, or at least incrementally loading it so they can make the web faster and more usable. I'm really excited about all the explorations going on currently. It's especially... What's really interesting is that there's a lot of overlap, so people might think, like, oh, everything that React is doing is super different from what Sola is doing, or everything that Esther is doing is super different from what Next.js is doing. A lot of this is overlapping with each other in so many ways. We ended up talking yesterday, and we spoke for, like, two hours just on, like, all these things are actually a lot of the same things that we're trying to solve, and we solve them in this way, you solve them in that way, and a bunch of that is spikes, a bunch of other things is like this is how we want the X to be, that kind of thing. I'm excited to see, for React itself, I'm excited to see the DX for cervical buttons get better over the next year or two years as well, because that's something that we're working on quite a lot as well. Okay. And with that, we're right on time to wrap up the fire slide. Can I give applause for our speakers? Thank you. Thank you. Thank you. Thank you. Thank you.