Aloha everyone. Aloha friends. My name

is Cap. I am the head of developer

community here at Verscell. I see a lot

of my friends in the crowd. Hi everyone.

So we run the open source program at

Verscell and I know that the open source

community is very important subject to

many of you here today. So bringing the

creators andor builders of Nex.js, spelt

and next on stage was something that

really mattered to me because I know it

matters to you. And in all honesty, when

Verscell when spelt and Nexlabs joined

Verscell, I know it sparked both

excitement and curiosity. People started

asking what does this mean for the

future of my f my favorite framework. So

I wanted to create space during this

conference to hear directly from the

folks behind these tools to ask them

about the future about open source at

Verscell and the web in general and

maybe we'll find out some fun facts

about these builders. So this panel is

about transparency, curiosity, and

celebrating open source. I always say

it, but the world runs on open source.

So let's chat with some of the builders

in this community. So let's bring to

stage Tim Newton's from Next.js, Rich

Harris from Spelt, and Sebastian Chopen

from Next to the stage. [applause]

All right. So, we have Tim, Rich, and

Sebastian, all builders of frameworks we

use and love. Who's using one of these

frameworks? Next, next.

>> Nice. So, let's start with intros. Could

each of you introduce yourself, what

your role is in the particular

framework, and give us a sentence that

captures your framework for someone

that's new to it?

>> That's good. Hey, I'm Tim. I uh uh work

on next chess mostly uh nowadays tech

lead uh but yeah started uh next chess

together with uh Garm.

>> Nice.

>> Rich.

>> Yeah. Uh I'm I'm Rich. I have been

working on spelt for the last nine

years. Working at Vel for the last four

of those years. There's a team of three

of us who work full-time on the

framework within Vel. I manage that

team. Um the the pitch I mean if I was

being cheeky I would say react without

the BS but this is next comp so um I

have to [clears throat] watch my words.

Uh it's a way of building resilient and

accessible web apps um more easily than

than with alternative tools. It's a

framework but it's also a compiler and a

language. Um you should check it out.

>> And I'm Sebastian Shopan the author of

Nux. I joined Versel with Nuxlab's

acquisition three months ago. Um

if I have to compare uh if you use NexJS

uh I guess you are here. Um NexGS is the

Vue alternative and we have maybe more

feature less feature. Uh this is a

matter of taste. I highly recommend you

to check it out. Um, with my team, we're

also working on Nitro, which is the

server part we extracted uh two years

ago with NX 3 that is now compatible uh

that you can use as a backend framework,

but also use it as a vit plug-in if some

of you are using VIT.

>> So, you said nine years. Next is also at

nine years. And what's next at?

>> Uh, nine years as well. It was really

the 26th of October uh 2016.

>> Awesome. So why did you build it? Why

did you build next?

>> Yeah, I was making an e-commerce website

with Vue. GS and serverside rendering.

Back then Vue2 was not there. It was in

2015. So I was using pre-rendering with

a headless browser. And then I was

following GMO and I saw the announcement

of Nex.js

>> and I gave myself the challenge to do

the same for view and a week later I had

the first prototype working.

>> Oh, that's cool. What about you, Rich?

Why'd you start spelt?

>> Uh, guilt partly. Okay. Um, it's

actually my my second front-end

framework. I'm a serial offender. The

first one was uh it's like kind of bulky

and a little bit slow and I just wanted

a doover. And um having spent time

working in the compiler space, I created

a module bundler called rollup. And so I

was learning what you could do with

abstract syntax trees and and all of

that. And I thought, what if we can

apply these ideas to frameworks and do

the work instead of doing it in the

browser? Like you do a lot of the work

as part of your build step and make

everything faster and and more compact.

And so it kind of started out as, you

know, atonement for my sins in in the

earlier project, but also as an

experiment to see how far you could push

that idea of doing ahead of time um

work. And the reason that I was

motivated to do this was because my

background is actually in journalism. I

was working in newsrooms um building

interactive visualizations which tend to

be very heavily interactive. You're

dealing with large amounts of data,

motion, things like that. And you need

something that is capable of moving a

lot of pixels at 60 frames per second

even on mobile devices. And the tools

that were around at the time weren't

really up to it. So that's where it came

from.

>> Nice,

Tim.

>> Yeah. Uh well if you're here you might

already know the story but uh we we

basically started by so this is before I

started contributing to access but we we

started building this uh um like the

dashboard for versell actually like what

turned into the dashboard that you use

maybe every day if you're customer uh

and uh we we basically didn't have like

like had a a very um like clear vision

of like what he wanted this kind of

thing to look like uh and also like how

the the actual like development on it

should work. He wrote this blog post uh

um forgot the name of it but uh you can

still find this on his blog on his blog

and it was basically uh like what should

a framework look like uh in in 2016 uh

before we had all this like all these

different paradigms. Uh but um one of

the big things was like serves at

rendering. Uh you think like we we we

immediately chose React but actually

didn't. Uh we we chose uh to build our

own like react like thing uh that was

like a templating language. It's called

the N4. uh and uh eventually like they

decided to pivot that to a uh like react

based framework which was uh uh react

wasn't as popular at the time uh per se

uh and

uh we we basically started like building

with like service rendering and doing

all of that then like over time it

evolved into doing like more static

generation other things as well.

>> Cool. It's fun because like these are

frameworks that are all like being used

by so many of us but there's just like

this unique story that made them start.

So it's like really cool to hear that.

Um so I engage with a lot of the open

source community and people have a lot

of mixed feelings about open source

projects like code exposure I think is

the biggest one like oh I got to keep my

code safe. I I don't want to open source

it. But then others think it's super

important to be a part of the open

source community and have the

contributions. So why did why open

source? What why is open source so

important to you?

>> Honestly, never even occurred to me to

not do things

>> as as open source. It's just kind of how

software is is written, particularly if

you want to get users.

>> Yeah.

>> Which I mean I I don't know having users

is a is a blessing and a curse. But um

if you want any kind of adoption then um

you've got to be open source because

otherwise someone else is going to do an

open source version and that is going to

be more popular. But there are also like

very tangible concrete reasons why it's

it's beneficial to the software itself

for for the source to be open. And I'm

sure like you've had similar experiences

of you know you throw something over the

wall and then someone comes up and says

oh hey there's a security vulnerability

that you might not be aware of and if

the source wasn't available to them then

you'd just be sharing that vulnerability

with your with your users. Um, so yeah,

it just never occurred to me to

>> I think for you it's also what's really

what I found really interesting for your

case is like you like you said you're

serial a serial open sourcer and you

created many projects but actually many

of these projects that you uh are

talking about they they still exist

today right so you're obviously working

on swelt uh but then you're also you

created rollup but actually you're not

working on rollup dayto day uh at least

I think so but there's like someone else

that came in that's how working it I

think like even full-time or something

like that. Um

>> right

>> longevity is is like

>> yeah so it's like even like uh there's

this thing with like if you don't open

source your software uh and you lose

interest or like I'm not saying you lost

interest but it's it's more like you you

uh live and you learn new things and you

start building even more uh software and

uh maybe something like that. And what I

always find really interesting for the

products that you build is that they

they end up um like going over this

lifespan of just like you being the

maintainer and creating it to then also

getting more user like more users but

also the user starting to contribute

back to it and then also uh like

outliving you as the the like rollup guy

basically or yeah I mean that's

absolutely essential and like I think

we've probably all we probably all would

say that we learned how to be developers

by reading other people's source code.

>> Yeah.

>> And like it sounds a bit like come by to

be like giving back to the community and

everything but actually that is how we

create the next generation developers is

by giving people the ability to to to

learn the same way that we did. Um, and

so I I think it's just essential that we

continue to prioritize open source over

uh the alternatives.

>> And I do think that if you want to

create a community, um, it has to be

open source. So I think it might be very

hard and if you want to get some help,

it's also easier if it if it's open

source. Uh, it might be frightening to

push your code as open source, but you

may be surprised that not everyone look

at your source code. uh potentially they

look at some files uh or it's the same

thing as you have this feeling that

everyone is watching you if you are on

stage but probably not maybe everyone is

watching uh

>> they're all on their phones

>> yeah they're all on their phone actually

uh and it's quite similar on the open

source like most people won't read your

source code they will probably read the

documentation but they will have trust

by by knowing they can look at the

source code at one point and be able to

contribute so I saw only benefits of

open sourcing it and at one point if it

becomes popular uh the maintenance might

become a burden but the beauty of open

source is you can find help quite

easily. So this is something that I

highly recommend for you to try.

>> Speaking of the community, what has been

the weirdest quirkiest contribution you

have seen and did you accept it?

>> Quirky. It almost sounds like the the

like you're looking for the the Guy Fury

in Babel [cough and laughter]

thing.

>> So, at least someone in the audience

knows what I'm talking about. No.

[laughter]

>> Yeah. The the the Babel thing. Um there

is one thing that springs to mind. So,

the the project I mentioned that was

Spelt's predecessor. Um, it was, you

know, you'd have have a JavaScript file

and you would instantiate a component

inside it and you would pass it a

template which is like this HTMLish

thing and it would just be in a giant

string that you pass to the constructor.

And um, one day this guy comes along and

says like I want to have my my

JavaScript and my HTML like in in the

same place. What do you mean they are in

the same place? Like no no I don't want

to put my HTML in my JavaScript. I want

to put my JavaScript to my HTML. What

the hell does this guy mean? And after a

bit of a back and forth, he was like,

"No, if you have your component in an

HTML file and then you have a way to

import that and it becomes a JavaScript

component,

then everything is just kind of much

more neatly organized and you can put

your JavaScript inside a script tag

because HTML can contain everything

else." And while we're at it, why don't

we put our styles inside a style tag?

And it was like I didn't see it at all

at first, but he he convinced me. And

that is how single file components were

born.

>> Wow.

>> Um so this I I remember like this is

like 11 years ago guy's name Dave

Marshall um very influential figure in

frontend um development because we did

that and then view adopted it too and

like now it's just how uh some

frameworks work and it was just because

some guy had an idea and thought I'm

going to raise an issue.

>> Yeah.

>> Power of open source.

>> That's cool. So someone had you're

saying someone had strong feelings

>> and that that affected like millions of

developers basically

>> open source

>> you won.

>> Nice.

>> Good on you Dave.

>> Mhm.

>> Um what I think recently uh we had an

issue on Next uh someone saying that uh

can you please rename this prop because

the LLM doesn't assume that it should be

the right prop like it was a U table. I

think we're using tenstack table under

the hood. So obviously we give this data

attribute to give the whole array to

generate the table but because the LLM

was expecting to use rows we should

rename directly the uh the attribute. So

at least it gives thinking that

potentially uh with the rise of LLM

shall we also try to either educate the

LM of this new prop or just go ahead and

and trust what the LLM is expecting to

for us to so maybe the LLM will be the

one making the craziest ideas for

frameworks. But uh yeah

>> that's a good point. Have you had to

change much with the framework with AI?

like is there a lot of issues that are

coming up that you're like, "Oh, I would

have never thought of that." But this

LLM issue is showing itself

>> there. There are some uh some things

that that I I think like at least I as a

programmer never did is it's like

running the Nexus dev server and then

also running next build.

>> Mh.

>> Because like every change I make, I'm

like running next build to verify if my

thing is correct. Like I never did that

myself. And then when you start getting

like agents that are like automatically

like verifying their own work like you

get people to do uh next build. But we

like we never thought about it in that

way like at all. So uh there wasn't even

like a good error message for that like

if you do that. Um so what happens is

like you run next build it breaks the

entire app like your development server

is broken you have to reboot uh start

over. Um, but now with the uh so of like

agents or like

like AI writing code and verifying

itself, you basically end up having to

take all these like new DX features into

account that are like sort of like

geared towards uh uh like AI more. Um,

and that was like one example like it

was for us it was like a oneline change

to the config by creating like a new

disc directory for for build or for

development and then like for built it

it uses the same thing so it doesn't

break but that like oneline change uh

was received so well because like

everyone's running into day-to-day at

this point uh if they're if they're

using AI um

>> and uh yeah that that was like one that

immediately comes to mind for me.

>> Yeah.

>> What about you Rich? uh we haven't

changed anything in the design of the

framework itself for the benefit of LLMs

but um you people do run into the

reality that if you're using cloud code

to build your spelt app it's probably

going to have more spelt 4 in its

training data than spelt 5 and we

changed a few things um and like you

just can't get the len to generate

modern idiomatic code so we have

released an MCP server

>> okay that really helps with that. Shout

out to Paulo and Stannislab on the team

who who put that together. But most of

the conversations that we have about if

there is something that we need to do

differently for LLMs, it's about um

making the the documentation more

digestible and we are we are loathed to

do something purely for the sake of LM

partly because we think of ourselves as

you know engaged in a in a very human

first project.

>> Yeah. Um, but partly because it is a is

such a moving target. Like the things

that are beneficial for LLMs today are

not the same things that were beneficial

six months ago and are almost certainly

not going to be beneficial 6 months from

now. So we we always think okay is this

change like making more digestible

documentation something that is also

going to be beneficial to humans? If so,

yay, let's do that. If not, let's just

hold off if for the minute and see how

things shake out

>> because spelt 5 is new this year.

>> It was released last October.

>> Okay.

>> Yeah. But um

>> and it's still not on five.

>> Is it version five? Yeah. And so the

newer models their cuto offs are after

that date, but there's I think there's

still

>> more of the old stuff in and the

training data for most of these models

than there is the new stuff. And this is

not a problem that's unique to us by any

stretch. I mean, I'm sure that it's

going to take a while for new React

patterns to get adopted. And

>> yeah, and this is like part of why uh

we're also introducing the uh next evol

mention it as well. Yeah.

>> Well, at first when I saw that the LLM

was trying to put React code in my view

app,

I was considering to support React, but

then I was like, okay, [laughter]

let's let's see how we can help the LLM

to to read the NX dogs. So, we started

with this /lms.txt

uh being able based on the um adding

this MD suffix to other pages to serve

the markdown so it's easier for the LLM

to crawl our documentation. We recently

released this next UIMCP server. The

next MCP server is coming end of this

week. And we noticed better uh code uh

output from the LLMs. And lastly, we've

been also teaming uh teaming up with the

uh Versel and X team to uh build this

eval to compare the different AI models

about uh producing uh proper code. So we

add some tests, we make sure the uh uh

we give a prompt and we compare the

output and it help us to see if the uh

MCP is doing a good job or not. Maybe it

can be part of the prompting. So if we

notice that uh always pasting these uh

sentences in the prompt always give us

good result. We will try to advocate

having this agents MD but we go step by

step like Richard said it moves very

fast. So you we also need to focus on

the human uh so trying to juggle between

the two uh and listen to the community

and yeah that's uh that's how we do it.

>> So I always think of open source as that

like building block thing and then you

have like the one tiny one that if it

goes away everything crumbles that's

like open source that's like the one

open source package

>> the random guy in Nebraska.

>> Yeah. So it's the foundation of a lot of

projects. Um, and it can also be a lot

handling like issues and then keeping

the community energy up. So, how do you

keep the momentum going in your

community for next, for how are you

handling those issues, making sure your

community is happy and staying true to

open source?

>> I mean, anytime you start an open source

project, you have to wear all of the

hats. like you're pushing all of the

code, you're writing all of the docs,

you're um doing the like the logo design

and you're building the website. If

there's tooling involved like ESL limp

plugins and stuff, you got to do all of

that yourself and and that quickly

becomes a lot. So, the the one thing

that uh that I'm glad I learned quite

early on is if anyone shows any

inclination to help whatsoever, you bear

hug them and you put them to work. Um,

and the the thing that I think is is

really crucial with that is if you find

people who are community-minded, who are

good at helping other people who are

like less far along their their learning

journey, um, and can help answer their

questions, help responding GitHub issues

or in Discord threads. um those people

are absolutely worth their weight and

gold because if you know if if you're

working full-time on the code and the

design of the framework like you really

don't have the bandwidth to be also like

customer support um and so if you can

divide that labor it will it will save

you a lot of trouble I imagine we've all

found that

>> I think uh you cannot do it by yourself

at one point you need help and embracing

people helping you uh on my end it

really helped um umping the the

newcomers uh it was Puya Para who became

a lead uh maintainer of KN then Daniel

row uh and I think crediting people even

if it's small action a p request

answering issues um it can be very

beneficial to showcase their their their

work like just a thank you sometimes

just a tweet uh adding them in the blog

post showing them that we see their work

and we value them. I think it's uh it's

how you you have people that trust you

in return and and wants to continue

helping you. So that's how it worked for

us. Uh but it's still uh very hard to

maintain this flow of issues.

>> Yeah.

>> Yeah. Yeah. Well, it's it's a resume

builder for these people. [laughter]

Like, oh, I I contributed to Spelt. I

contributed to Nex. Like, here's the the

stuff that I put in that's in the

framework. And they may not be building

it, but they can contribute. And we've

created this like open source community

that we're helping each other learn

more, but also get more opportunities.

So,

>> yeah, I yeah, I I I was the person that

uh Rich was talking about where I got

bear hooked to basically be here for

eight years now. Uh the uh I think

what's was really interesting is that um

so I I came into the like national

project pretty early but I I was uh

contributing to a bunch of uh for sale

like site at the time uh um like

projects and it was more so because the

um like there was technical challenge

there like I could learn something new

uh 19 at the time I wanted to learn more

about JavaScript and this like one way

to do it and I I found that like fixing

bugs for some reason I learned really

well uh doing that. Um and uh so like

how we approached this like uh and for

Nexus is evolves over time as well

because like I think the um is this

strange thing where like the well it's

not strange it's like the the overall

usage goes up you get more GitHub

issues. It's a thing where everyone will

find every single bug there is even if

it's uh that there's a dot or comma

somewhere wrong in the docs or things

like that. Um so in the end like what

what we're doing now is that we're uh

obviously we have a larger team working

on it. Uh we're like triaging issues uh

every day. Uh there there's someone uh

like actively work on that. I know that

if you're in this room and you've seen

issues and they've been open for a long

time, uh, we haven't replied yet. Uh,

very sorry about that. I will say that.

Um, it doesn't mean that we haven't seen

them. It means that they were either

triaged already, but like we we're

keeping them on a list or um, they are

actually like uh, still being worked on,

but like we uh, we can still do better

here. I will say that. Uh but then the

uh the thing is like

uh it will take some time to get through

all of those because it's like uh I

don't know like a thousand open issues

>> and while the number you see keeps going

up actually like if you look at the

stats it like we're closing like as much

as there is being opened

>> but like even if that's like 10 or 20 or

40 or like 50 issues per day more every

day being opened than that we close uh

it it just never goes down. keeps going

up over time.

>> Uh, and it's a thing that we have

because because of like large adoption

and like a lot of people using it. Uh,

we're and also I'll say like we're very

thankful for people reporting it to

GitHub. If you're reporting it to GitHub

and the bot did not close it, you did a

super good job because uh we we have a

pretty uh strict bot that will say you

need to provide a reproduction because

otherwise we will close it. Uh, and

really the only reason we have that is

because we can then correctly triage

everything and and investigate it really

and really fix it for for these cases.

>> But the overarching message is big bear

hugs for the community. Yeah.

>> Yes.

>> All right. So

let's talk about spelt and nuxlab

joining Versell.

So some people were excited, others were

curious. So

>> why did you join Versell? what like and

what has changed behind the scenes with

Nux and with Selt?

>> Oh man, I have so many thoughts. Um,

people did have many opinions when uh

when when uh I joined VEL. I'm sure you

can relate. Um,

so I've been at Vel for 4 years now and

at first people were like, "Oh no, Vel's

acquired Spelt."

>> Yeah. Um like I wish there was there was

nothing to acquire. It's like an MIT

licensed codebase. Um so like I I joined

as a salar employee to work on on spelt.

Um and uh you know people worried that

being at a company that exists to make

money was going to have a corrupting

influence on on the road map. And uh I I

think I can say four years in that our

track record disproves that. Um so to to

the people who uh who thought um that it

was all going to go terribly wrong that

we were going to start prioritizing

um Vel support over being an independent

platform agnostic framework. Um that

hasn't panned out for a few reasons.

Number one, the three people who work at

VLE on the project are a small part of a

much larger maintenance team. And if we

started to go rogue, then the rest of

the team would mutiny and and it would

be a shortlived thing. Um, but also I I

think what

like people have have come to see is

that it's just not in Vel's interests to

um exert influence over the road map.

Like the whole point of the project is

that um there's no vendor lock in the it

is designed to be a platform independent

um project and that the reason that you

would bring your spelt project to the

cell is for the cell. Um and so I think

that has that has panned out pretty

well. So I I wouldn't say that anything

has really changed.

>> Okay. Um, in terms of the the governance

and the road map, um, the only thing

that has really changed is our ability

to ship stuff because before me being

here and Latally, Simon and Elliot being

on the team, it was a like a weekends

and evenings project. And

>> any open source project beyond a certain

scale, especially when you have beyond a

certain number of users, you just can't

do it on a part-time basis. Like, it

needs to be a full-time endeavor.

>> Um, and so being part of the company has

>> has made that possible. Um I mean I

guess it's slightly different for for

you in so far as um

>> there was an acquisition

>> no on NLabs. Yes. Um

>> so Nuxlabs was a company and we had uh

different products around NX to sustain

the uh the open source we've been

building. Uh one was NXUI Pro which was

a premium component libraries on top of

NXUI. Uh the second one was next studio

which was a gitbased CMS on top of of

your modern files and the last one was

uh next hub which was uh adding a

developer experience layer on top of

cloudflare to deploy your next

applications trying to get the versel

experience on top of cloudflare which

was not that easy anyway to to do. Um

and then um I got the opportunity to

talk to GMO to brainstorm about what it

could be to to join Versel. I think it

really helped also to have the uh

history of Rich joining Versel seeing

that the the framework was not denatured

like it stayed agnostic. It was very

important for us as next and nitro to

stay agnostic. Um I think universal

interest it was also important to

showcase that it support multiple

frameworks. So at that stage or um

strategy aligned uh I was excited also

by the idea of bringing the team working

full-time all together and also open

sourcing all of our products because it

opens the possibility for the community

to access our premium products. um

making next also agnostic. So being able

to build full stack application on cloud

fair but also on versel and that was

this thing that was uh tricky for me to

have something that is locked in. So

opening it for the web I think it made

sense um and I can understand people

being sus suspicious. Uh but what I'm

telling them is you will see with time

and I'm very confident that Versel was a

great choice.

One of the the really cool things with

um like the the Nuxlabs acquisition is

also that we're uh we're talking a lot

more now. We were talking before as well

like between our teams as well. There

there's like quite a like there's a lot

of overlap obviously like we're building

similar tooling. It's not exactly the

same. The APIs are not the same. is all

uh like there's a bundler and there's a

service rendering and like all of these

things and like seeing uh like even in

the last few months like seeing like

Puya like lend all these new APIs into

Nitro to to make Nitro overall better

has been uh been really cool to see as

well.

>> Yeah. And even the C uh the cache system

where we've been collaborating. I mean I

was excited to be able to uh talk with

these guys on the same Slack channel. I

think this is honestly uh one of the

greatest things.

>> Yeah. One of the interesting things is

that uh because there's a bunch of

people that you'll see from Verscell

that are like super uh like

super online uh always on Twitter uh

that kind of thing. I'm not personally

not super like that. Uh but the and Rich

is not like that as well and and I think

uh Sebastian as well. But the uh

basically there's also a lot of uh like

historical

uh like there's there's people at

forcell that have shipped like some of

the largest uh like tools in the world

at the like either like big tech or uh

like uh did it in like open source as

well or other things that you don't know

about that really uh are helping shape

this like like bringing these tools that

were in uh that always existed like

every single like large company like

Meta or Google has and uh that could

never be brought to open source because

like their tooling is like super built

towards like their particular stacks. Uh

but we're actually now able to build

some of these tool these tools uh as

open source for like the the frameworks

that we're building.

>> Yeah, I'm lying.

>> So you had some closed and then you were

able to open it all after joining.

>> Yes. Uh so far we released Nexus UI V4

which includes all the NXY pro

components. We are working toward uh

making NX studio self-hostable. So you

will be able to uh edit your NX content

your markdown documentation within your

website and commit directly to to

GitHub. So all you need is a is a

hosting that supports serverside

rendering and old GitHub app. And next

we are going to release uh same as next

studio at the end of the month uh first

uh version capable of running on on

Versel. I got a a demo of Max Studio

yesterday. It's pretty crazy.

>> I wish we could do it right now.

[laughter]

>> Okay, so you all have been building

frameworks for almost 10 years. A lot

has happened in those 10 years. Version

16, version five, version four.

>> Yes. So, what does the next 10 years

look like? It's been going on for almost

10. What's the next 10 look like?

>> More convergence, I think. Um, we were

sat in the office yesterday just kind of

nerding out over some of the things that

that we're working on. Um there are some

areas where spelt and spelt kit are

ahead and there are a lot of areas where

nux is ahead but like the things that

has are the things that we want to do

next and the things that we have are the

things that nux wants to do next.

>> Um and I I know that the same is true

for next. Um, I I think making these

frameworks truly full stack is the the o

overarching trajectory like reactivity

and rendering like keeping the DOM up to

date is very much a solved problem at

this point. But there are a lot of

unsolved problems around making storage

and OR like straightforward and

bulletproof and well integrated into

these systems. And these are the things

that that I know you're pursuing and

we're pursuing

>> and it overlaps so much that like you

can have generic solutions for some

things. Uh that that's not to say that

we'll ship all of them in the same way

and that the APIs are all the same or or

things like that. Uh but there is a lot

of overlap and uh ids and experiences

are really helpful here as well. Uh I've

noticed been talking with uh Daniel on

the next labs team uh like quite a lot.

um also just about um like uh open

source in general and uh how we uh like

build this at for sale as well. Yeah,

>> I think we'll see also what the

community and users and maybe LLM will

ask us to to build next. Um I think the

full stack for me has been uh I've been

waiting for a long time to to add full

stack feature on next. uh I think with

the LLM building we're expecting the LM

to build full stack apps. So trying to

define a standard uh an opinated way of

building full stack may also reduce the

security risk by building it in the open

as well and as open source. Um and yeah

we we will see we didn't expect to add

an MCP server um few years ago and here

we have having an MCP server helping

developer to build MCP apps. We'll see

uh it's hard to predict honestly.

>> Yeah. How often is the this like feeding

notes to each other happening? That's

fun.

>> It is. I mean, I wish we could do it

more often. Unfortunately, he lives in

France.

>> Well, you're all in the same Slack, so

[laughter]

>> we are

>> 10 years for next.

>> 10 years for next. Next 10 years.

>> Next 10 years for next

>> 10 years for next. Uh

>> yeah. What is next? No. Uh the um yeah I

I think like the u like today at the at

the keynote you saw what our vision is

for like what Nexus should look like.

It's

>> the the thing we started two years ago.

It's uh getting a really good bundler.

Uh it's going to start paying off like

the thing that um I've been talking to a

bunch of people like probably in the

audience today uh that came up to me and

said like Nexus 16 fixed all my

problems. uh uh which and other problems

were slow next def uh to be clear. Um so

the the thing here is like we're we're

now at the baseline, right? So this is

the baseline of what all the features

that we already had are with Turopac. Uh

but now we can start building new

tooling. So there's like a better bin

analysis tooling coming very soon as

well. like in the next few months you'll

you'll see like a bunch more tooling in

in this uh like in that space around

like the bundler because we can now like

we now we have knowledge about the end

to end of like where everything goes. Uh

so now that we have this bundler we can

basically we made everything fast. Now

we can make it slower. Again this sounds

crazy but uh it means that we can do

more work in less time than we did

originally and uh do more like advanced

optimizations. You can do do all this

these things and that's just for turbo

pack for Nexus itself uh like cache

components uh partial pre-rendering and

uh like being able to build this like

one page that can do both static and

dynamic was always the vision from the

like when we started building app router

it just took some time to get there and

it's finally here to try out so I

definitely recommend you to try it out

um and then for the like the next 10

years is going to be refinement getting

better D like even better DX than you

already get. Uh all the error messages

should be correct to where like you

throw the error uh if you introduce one.

Um and uh I'm sure we'll see like some

something like coding agents and things

like that to like bring all these

features that that are missing there as

well.

>> I would add a small note on we see the

rise of AI browsers now. So I think we

are going to see uh our web frameworks

also being able to ship some

capabilities for this AI browser to

communicate directly with your app. Uh

it could be MCP server, it could be a

new standard that will come with this AI

browser. So I think adapting also to

this new uh new browser experience

maybe shipping web component directly

for the air browser to to use from your

website. I don't know. That's that's

exciting.

>> Yeah. where I see these three in 10

years, we're all gonna have a chip in

our head and we're gonna think, "Build

me a spelled app and just gonna build

it." That's [snorts] 10 years from now.

Um, okay. So, last question. It's not

about frameworks. It's not about tech.

If you were not in tech, what would you

be doing? What would be your job?

>> Realistically, I'll probably still be in

journalism.

>> Okay. Yeah.

>> Um, I I don't know. I most people who

work in tech, I think, have some sort of

fantasy of doing things with their

hands. Uh, I really like cooking. Maybe

I'd open a cookery school.

>> All right.

>> I do like building things with my hand,

actually. Um, I like 3D printing a lot,

but I guess if tech doesn't exist, 3D

printing, uh, neither. Uh, so I guess

probably, uh, building houses. Um, I

wanted to be an architect when I was

young. I mean, building things. So,

whatever it is.

>> That's cool. Yeah.

>> Cool. Um, for me, it's uh, completely

different. I think I I would probably

end up uh working in my like my parents

have a a gardening center in the

Netherlands and uh I uh I'm I I know

nothing about plants. Don't come to me

with plants questions. But uh the

uh I would probably be working for them

like most likely uh in in their

business. They uh uh it's an interesting

business. They actually do e-commerce as

well which is uh they they they bring

plants to you. uh uh using Yeah, it's a

whole logistical thing and so you can

Yeah, you can do whatever. You don't

have to work you you don't even have to

touch plants to work in a garden center.

How is that? Yeah.

>> So, we have a gardener, we have a

journalist, and we have an architect. I

love it. All right. Well, that's it from

me. Thank you so much to all three of

you. Give it up.

[music]