Carl: Hello everyone.
Thank you for joining us for the October edition of This Month in React.
As we recap what's going on with React, React native in the web, we're coming
to you live from React Flux, the place for professional developers using React.
I'm Carl.
I'm a staff staff product developer and freelance community leader here at React
Flux, where I run community programs like these events and build tools to
help keep the community operating.
Mark: Hi, I'm Mark.
My day job is at Replay.io and in my copious amounts of spare time,
I maintain Redux and rewrite Immer.
Mo: I am Mo, I head the mobile team at Theo.
I'm an active part of the React native ecosystem and community,
and I organize the React Native London Meetups and conference,
which is coming up in two weeks.
Terrifyingly so.
Carl: Coming right up.
Yeah.
And you got a shout out that we're gonna talk about.
Let's start with some new releases.
Mark, tell us about Immer.
Mark: Okay, I can, I can do both these things.
So I actually take very full credit for this one.
So to be clear, I do not maintain the Immer immutable update library that is
Michelle West Rate, who created it and has maintained it all the easier years.
However, since the start of September, I have sunk a stupid amount of time,
something like 120 plus hours into trying to rewrite the internals of
Immer for faster performance after some re users filed complaints to the
Redux repos, that it was kind of slow.
So I filed a few different prs, one to make some relatively
small tweaks, and then a couple larger architectural changes.
And Michelle just merged and released Immer 10.2 with the small options.
And we are hoping to land the larger architectural changes in the near future.
And those will probably come out as Immer version 11, hopefully in
the next few weeks or something.
So I'm excited faster for performance free upgrades.
Yeah, should be.
Carl: Yeah, love some big core performance improvements of deep packages.
That's awesome.
Mark: And I will also hopefully turn this into a conference talk.
Nice.
Along with that, I, I just saw the announcement, I think like yesterday,
that the author of the ARC type validation Library, which is a, a
competitor to Zod that takes a, a rather different API approach, just released
a, a similar tool called ARC RegX.
It's a function that is supposed to be a replacement for defining regular
expressions in JavaScript, but it actually parses the RegX string into
TypeScript types so that it can both.
Interpret at the type level, what the regular expression is doing,
and also even provide syntax errors if the reg itself is invalid.
Just looking at the docs, my mind is blown.
Carl: Well, yeah, other than new releases, we have a bunch
of main content this month.
The React conf happened, what, three weeks ago, and a bunch
of new stuff came out of there.
They did put up an official recap blog post from it on the 16th, about
a week after the event happened.
The big takeaway here, I think, well, I don't know, we got a couple of big
takeaways, but one of the headlines is definitely the React Foundation.
This is a pretty big change to, or this sounds like it will be a moderately
large change to the governance of React.
They're pretty light on details of the actual governance, so far.
They have talked about like a new technical steering committee.
But they also say that the governance of that is not finalized.
The members are not finalized, but they do have the founding members of
the founding sponsors basically of this foundation, which are Amazon Call
Stack, Expo, Meta, Microsoft Software Mansion, and Vercel with Seth Webster.
Seth Webster is executive director and he's the what
manager of the React core team,
Mark: Basically.
Yes.
Carl: Yeah, so that makes sense.
He is basically already doing that role and expanding what the core team
means to an intercompany organization.
But yeah, it's a lot of the details that I was most curious about, like what
does, what does this mean for governance?
Like how will decisions be made are not yet answered right now from
the, from the various posts on this.
A quote is, the React team is actively working on this new technical
governance structure, and we'll share more details in a future post.
So this is an announcement of a future announcement in some
ways, but it's pretty real.
So this is in collaboration with the Open JS Foundation, which is
a partner to the Linux Foundation.
So like th these are very large, pretty well-founded organizations that the React
team is glomming onto in support of like a neutral home for React, as they call it.
It's sounds like they're in incorporating React Native into this as well, which
I think is not necessarily a given.
You know, if you're talking about the governance of React, what that means for
React Native is not necessarily implied.
But just looking at the founding members like Amazon, Call Stack,
Software Mansion, and Expo, and I guess Microsoft too, like those are
all heavy React native investors.
Mo: I think it's quite surprising in that sense because it's more
heavy on the React native side.
Like Vercel is really the key sort of non-react native player.
The rest are really heavy on React Native and there's like noticeably
missing membership from like Shopify on the Remix side as an example.
I, I actually find it's very skewed towards React Native, almost shockingly.
Carl: Yeah, I'd agree with that.
It's, it is almost shockingly skewed towards React.
React Native, given that it was not really pitched as the React Native foundation.
That's true.
I guess Software Mansion does do a fair amount of web React work.
But I, I believe Call Stack is predominantly a React native shop as well.
Mark: So I'll do my usual thing where I, I step back and provide historical
context and what matter at all.
So React was invented at Facebook.
It has always been a project owned by Facebook and Meta.
The code has been open source, but.
You know, for years the entire development team was Facebook meta
employees paid by Meta to work on React.
And I've said even in my conference talks this year about Meta, Vercel, React
ownership, that the React team has had the freedom to work on what they want.
And that's true, but I've, I was reminded in some conversations with
React team members at React Con, how much their work is constrained by,
like the fact that their performance reviews are, "what have you done
to further meta's goals this year?"
And so in some ways their ability to push React in the technical directions that
they think are right, are limited by how much they can make the case for that.
Inside Meta, even something like the Concurrent Stores work is
essentially being pitched as, how can we make Facebook's Ads Manager
app faster in a lot of ways?
So we saw multiple React team members move over to Vercel.
Like people used to complain that this is all a Facebook app, all
the meetings are inside Meta.
There's no public roadmap, it's only meta.
And then we had team members move to Vercel, and then it became, well, now
Vercel is applying too much ownership to React and all the stuff we've talked
about with Next and server components and Vercel and how that's supposedly
driving the roadmap, et cetera.
And so the team itself has been split across two companies,
and they're working together.
It's one team, but it's kind of within these two companies.
And so because of Reacts widespread usage, there's been calls for many,
many years that there ought to be some kind of an independent foundation
that would own the trademarks, the rights, the development process.
To React itself.
And it always seemed kinda like one of those pipe dreams.
The calls on Twitter to build, React into the browser.
And obviously there's no way that's going to happen.
And, and this felt like much of the same kind of idea.
And so they, they did the initial React and the initial keynote at
React Con, and they were mostly focusing on technical things.
Like last year we, we fixed the, the sibling preloading bug.
That was the suspense gate problem that everyone was talking about last year.
And 19.2 came out and the compiler is 1.0.
And then Seth came out and he did the one more thing routine
and as soon as he put the React Foundation slide up, my jaw dropped.
And I think I even said out loud, oh my word, they actually did it.
And my first reaction was, even without knowing.
Any actual details about what the foundation is or how it's going
to work or whether this is even going to work out in practice.
The fact that they have taken the time to do the legal preparation work to try
to make this happen and are actually attempting to execute on that is a
huge deal for React and the ecosystem.
It, it is a statement of good faith and intent for how they want
React to proceed in the future.
Like without any details, my immediate reaction is, yes, finally,
this is a good step forward.
We'll see what it means in practice, but this is a really big deal.
Carl: Yeah, I would agree with that.
It's a really big deal that they're moving in this direction.
I'm really curious about the details because I think there's a lot of, I
don't know, like in the past they've done working groups and et cetera.
And my understanding of the takeaway is generally, has generally been
that they found it really difficult to manage participation in those
like open access kind of arenas.
So maybe the, this is kind of like adding a new layer of abstraction perhaps with
administrative support from currently thriving independent foundations.
Mm-hmm.
So that, that definitely makes me think that this has a real chance
of being something real and valuable that goes on for a long time.
I'm curious what it means for things like, like in practice, it's not
like anyone's employer is changing.
No details have been shared yet.
At least that anyone is being paid from this new foundation.
I, I don't know whether to call it meta or Facebook 'cause it's on the fb.com domain.
Mm-hmm.
But in the Facebook engineering announcement here, they do say that Meta
has committed to a five year partnership with over $3 million in funding.
I don't know what other funding they might have.
I don't know what other sources of funding they might have in the future,
but like just looking at five years, $3 million, like that's 600,000 per
year, which is like, you know, for meta engineers, that's like free engineers.
So I don't know.
I don't know what that means for people's incentives and where they
will work and how their focus and performance will be evaluated.
Yeah.
Mo: What that rules out is that effectively the React Native or React and
React Native Core teams will definitely not be unemployed by the React Foundation.
Right.
'cause that would basically cover three salaries, which is far smaller
than what the React teams are.
Carl: I think the React core team has like 10 engineers.
Mo: And RN is about the same.
So you're talking 20 engineers.
It's definitely not going to cover those employees to move them
over, which is in some capacity.
And then details are to be fleshed out.
But in some capacity it is a bit disappointing because it would be great
if they had more freedom as the React Native Core team to play around without
the restrictions, like you mentioned, of the reviews that Meta has internally.
And so it's gonna be interesting to see how that Dyna dynamic plays
out effectively because there is still gonna be that same team.
At Meta
Mark: I, I have three sources of information that I'm piecing
together for some of how the foundation is supposed to work.
Seth Webster answered a few questions about this during the q and a session
that was broadcast at React Conf.
I had a conversation with a couple React team members and the topic came
up about how things would be governed.
And then there was an article on the new stack where Seth Perry was
interviewed and was giving some further details about some of the governance.
So as best I understand it, so you've got kind of the corporate
level stuff that's Meta, Amazon, Callstack, Vercel, et cetera.
They will then elect a technical steering committee.
Which is, I guess sort of similar to how Node and other projects work,
Seth said in the q and a, that meta will start with five votes on that
corporate board, and then it will go down to one over the next five years.
So you kind of a decreasing amount of influence in that sense.
The technical steering committee, I assume, would be able to make decisions
themselves, but obviously the fact that they are employees of the companies
elected by those companies, et cetera, they would be taking their company's
interests into account in the process.
The article says that the technical governance will be in
the open more than it once was.
Request for comments, sets of stages, et cetera.
But a lot of the process is still to be figured out.
The article also talks about the foundation doing things like investing
in React hubs, helping boot camps teach React better, possibly some things with
conferences and alignment and such.
So it sounds like the foundation is going to be doing more outreachy things.
So there, there's a lot of this that is not clear what it means
in practice yet, but certainly.
React is not solely a meta owned thing at this point.
There are multiple companies that are invested in it.
There is a, a future for React independent of META'S ownership and goals.
And this all feels like the people who care are trained to do the right thing.
And
Mo: on the conference side, I mean, I hope that's the case because one of the,
as a conference organizer, one of the things that's perhaps challenging is
that Meta doesn't necessarily sponsor any conferences beyond just React conf, right?
And so, look, it's well known that that's sort of the case.
And so maybe the React Foundations that is going to be able to sponsor
those conferences, even if it's not a meta badge to speak, which
would be very, very interesting if some of that is used for that.
So I'm sure it's not just Meta who's investing, right?
Like I, I suspect that there's funding coming in from.
Amazon and Microsoft, at least from the bigger, bigger sort
of established enterprises
Carl: hopefully.
And that's interesting.
And the new Stack article interviewed Seth and has a bunch of poll quotes
from him and they do talk about that, that like the foundation will look
at expanding the annual React conf.
I guess that's not sponsoring other conferences, but they're
talking about conferences at least.
But also something that caught my attention.
They say while React Comp is one of the few conferences that actually makes a
profit, it basically only paid for itself.
And also it's a thousand dollars a ticket conference.
So like hopefully the mode of making conferences self-sustaining is not
making them cost a thousand dollars.
Mo: Yeah.
I mean conferences are from experience a very, very expensive endeavor.
And if you don't have companies backing them, they will make a loss.
Carl: I do wanna shout out, as we mentioned at the start, Seth says
"We have lots of boot camps out there that are doing their best, but they're
also sending people out into the world misinformed about how React works."
This is interesting there.
It's a, it's funny, they're actually hitting on a couple of points
that I've investigated myself about how to do businesses in
like a community since like I had previously connected with a bootcamp.
Somebody was working there as the curriculum lead and they
were doing a curriculum overhaul.
'cause they hadn't changed what they were teaching in three or four years.
And they were like, is this still relevant?
Is this what the industry's using?
And I was like, cool.
I help run a community.
I know lots of experts.
I would be happy to facilitate some kind of professional review.
And then the bootcamp curriculum lead got laid off because that was 2022
and lots of things were not happening.
So it's interesting to see them talk about things that I've thought a lot about.
And also a lovely shout out, Seth says there are also cohorts such as meetups
and local groups that could be assisted.
One meetup actually led to the creation of the conference React Native London.
So that's super cool.
Love that for you, Mo.
Mo: Yeah, I didn't, I, I did not have that on my Bingo card to get
a shout out from Seth Webster on an interview, which is awesome.
Yeah, it was good to have him last year.
Carl: Mo is the organizer of React Native London and that one
meetup that led to the creation.
So that, that's just fun.
That's cool.
We have actual players in the ecosystem in the podcast right now.
Mo: Well, you got Mark.
So I'm stepping up to very, very, very high standards.
Pretending to.
Carl: Cool though.
Yeah.
So I don't know.
I don't know if there's more to say there.
Mark: Some of the more technical stuff.
So they, they talked about React 19.2 coming out, which if you've been
paying attention to this podcast for the last several months, you would've
known all the details already.
Like the new activity component for being able to hide components while persisting
state use effect event for hopefully fewer use effect related bugs, et cetera.
React compiler hit 1.0 and then
Mo as like as usual, you wanna talk about the React Native-y things?
Mo: So a few updates that they did, one of which was quite surprising was that
the next release of React native version 0.82 is going to be new architecture only.
So obviously earlier on a few months ago, we talked about how they
deprecated the old architecture than they froze the old architecture.
Now they're dropping the old architecture.
And so to me that was a much faster deprecation cycle
than I, I would've expected.
Specifically when it comes to the fact that there are still a fair few libraries
that are using the old architecture and only support the old architecture.
So to give you a very concrete example, we had our monthly meetup
literally yesterday, and there was a talk about Arrive, which is this
animation engine that a lot of people are using to animate websites and
make really, really cool stuff.
But what we learned surprisingly was that Rive only supports the old architecture.
So what that means is that this company who's a very popular healthcare company,
really don't have a path to sort of migrate to the new architecture and
hence version 0.82 until Rive starts to support the new architecture.
So there are still libraries, albeit the majority of major libraries have
been ported to the new architecture that are still hanging behind.
So I'm quite surprised by this, but we'll see how it goes.
It probably means that these library maintainers really need to like step up
in the next month or two and get ready.
The second big thing, which I have a little bit about later on, but
just a quick one, is that Amazon did the Vega Os announcement earlier.
It was towards the end of September that they actually announced it,
but they formally talked to the React and React native communities
about it during React Conf.
This is a completely new operating system that's fully built from scratch by Amazon
folks and React Native is the UI layer.
It's the only way that you can write apps for it, which is quite a big
investment from Amazon's perspective into React Native as a technology.
So Amazon makes a lot of devices.
For a little bit of context, you might've seen their Fire TV devices, some of the
Kindle fire devices that they had, but also like Echo dots and a whole slew of
different devices that they manufacture.
And previously a lot of these were running on Android or a variety of Android
called Fire Os that they had adopted from the Android open source projects.
And so now they've kind of completely ditched that and they're betting
long term on React native now at our company at Theo and a bunch of other
companies have been sort of working with Amazon behind the scenes on this.
And we're aware of this but weren't really allowed to speak about it.
So it's now out in the public.
But it has been a good while, which I cannot specify how long that duration is
that I have been aware of this, but just not able to talk about it and have been
working with the Amazon folks to make sure that things are ready for their launch.
So they have an introduction video at React Con, which I think is
interesting because TV apps need to run on very, very limited specs.
You're talking like a few gigs of Ram one or two gigs of ram and like
very, very, very slow CPUs and some of them are even worse than that.
So effectively they really had to optimize the living crap out of their
operating system and make sure that React plays nice with it and is like the
first class citizen when it comes to it.
So it's, it's very interesting how they had to optimize it and
it was a big undertaking for them.
So.
I guess congrats to the Amazon team, but beyond that, it's quite interesting
for people that are interested in performance and React and React native.
Carl: Yeah, I was just scanning this to see if I could find any details
about what they built on top of, because like, I don't know, nobody
builds a whole OS from scratch anymore.
And this is on top of Linux?
Mo: Yeah, it's c plus plus on top of Linux.
Basically it's a Linux.
Or is a Unix based system.
Carl: Right, like, and so is Android.
Like, I'm curious to what extent this is a locked down, stripped back version
of Android that they're calling Vega.
They don't say that anywhere, but like reading the tea leaves here,
I, my assumption is that the, I don't know, Android was such a
massive undertaking that Google then acquired and commercialized.
Curious to hear more technical details about the OS layer here and how it…
Mo: I can tell you a little bit about that because I've known about it for a while.
It's not on top of Android in any capacity.
It is fully, the Android open source project components of
it are fully stripped out.
It's built from scratch, which means that compatibility with old apps is.
Limited and there's other solutions.
It's not that you can run Android apps on it as an example that
we're the old Fire OS apps.
Carl: So wait, it sounds a little bit like you're saying there is a shared lineage
with Android, but it's different enough that its own technically distinct thing.
Mo: They share a technical lineage in the same capacity that like Mac Os and
Androids here, which is, they are both unique systems and that's pretty much it.
Like they serve the same kernel but like so does 90% of devices out there.
So it's as Android, as IOS's, Android, if that kind of makes sense.
Carl: The Tree of Life, kingdom Family order.
Like this is not shared genus.
This is shared order maybe?
Yes.
Okay, cool.
Good to know.
Thank you.
Mark: I do wanna highlight a couple talks in particular, and again, you can look at
the whole React con recap blog posts to get links to the different talks and the
different portions of the live stream.
A lot of good talks that were worth watching, but two that I liked in
particular, Joe Savona did a talk on some of the React team's performance
experiments, and there's a bit of controversy because he showed a bunch of
hypothetical, semi hypothetical benchmark numbers without any real details on the
actual implementation of the benchmarks.
And then some of them were like, versus we built NAP with signals
and compared it with one with React and then ex a highly prototype
React and a bunch of other stuff.
And then people were saying, well, we tried to mimic this and we think you're
probably using signals the wrong way.
But it was still interesting to hear the discussion around, we agree
that performance has been a problem and we've tried prototyping some
different ideas to see what's possible and where bottlenecks might be.
The other one I really wanna point to though, Rick Hanlon did a talk called
Async React and he had a few major, he had a couple different points out of this.
One was that the React team has been talking about things like suspense and
concurrency since 2018, and if it's been hard to follow where the React team is
trained to go with this, it's 'cause the React team itself really didn't know
where they were trained to go with this.
He even pulled out meeting notes from a React team weekly meeting in like 2015 or
2016 where they started having the first initial ideas for, we think we want to go
in this direction, but they really didn't know what the final result ought to look
like or how they were going to get there.
And so showed a diagram with a whole bunch of back and forth wavy
lines like we, we don't know where we're going, but now it's 2025.
We've gotten through the confusion.
We've now built all the main concurrent pieces that we were trained to build.
We are seeing the results of even like the React 16 fiber rerate.
And now we can actually say, we've built these pieces and here's
how they ought to fit together.
And so the second half of his talk was a demo where he took a badly
written but viable React app, which uses use effect for data fetching
and manual setting, state for loading states and things like that.
And he first refactored it to have a bunch of transitions for better
loading animations, using suspense for the data fetching, and he showed the
visible improvements in user experience.
And then his point towards the end was that, yeah, the, so like this is how
modern Async React code ought to work.
But in fact, you shouldn't even have to write most of this code in your
own app because the transitions and the loading states and everything else
really ought to be embedded in your router and your data fetching library.
Now, unfortunately, his actual talk got interrupted for stupid technical reasons.
So he came back at the end of day two and picked up with his demo and actually had
a chance to do a better version of it.
And so I think the key points are, one, the React team has now built
the concurrent async features that they've talked about for years.
Two, a lot of us, including myself, are still kind of stuck in like a 20 16, 20
18 era mindset of how to use React three.
These things make writing React apps better and better user experience.
Four, we need to get these things embedded in component libraries and
data fetching libraries so that a lot of this stuff just works outta the box.
So I highly, highly recommend watching Ricky's talk.
He also put up the demo code as well.
Carl: That was a good talk.
It was a good demo.
I will say, while watching him write the code.
I was like, man, this looks really complicated.
Mark: Yeah.
And that, and that's another point that we're going to touch on here with a
couple of the, the other things as well.
One other thing that really caught my attention, so if you've been listening
to podcasts for a while, you've heard me agitating, saying that we really
need is a new React working group where folks from the community can
officially communicate to the React team for things like, Hey, we think there
should be more docs to cover this topic.
Or, oops, create React app just broke.
I think you should fix it, and things like that.
And Ricky was actually the person who drove most of the React eight team.
Working group.
And so at the end of his talk, Ricky actually announced that there is
now a new Async React working group.
And this is sort of a catchall, it's meant to cover discussions of things like how
do we get async React features into major ecosystem libraries and, what kind of
docs should we have to cover this stuff?
And so the, even the first discussion thread is a lot of discussion between me,
Ricky, Dan Aberman of Corbin Crutchley, about a whole bunch of possible docs,
pages that we could add that would cover things like transitions and
suspense and how to use them correctly.
And getting people from the community to contribute those new docs pages
rather than waiting on the React team.
To write them.
So I am actually genuinely, genuinely excited.
Like I've done a lot of complaining and this is the answer to my complaints
that we have working group and docs plans and an agreement that people
outside the team can contribute.
So like I am actually legitimately thrilled by this.
Carl: Nice.
I do appreciate more, I don't know, open participation more, more discussion.
That's great.
Should we get into Remix V three?
Mark: Yes, we should.
Alright, so usual caveat, I still have not had time to actually watch
the announcement, but I, I think I can give a fair summary of it
from having seen the discussion on Twitter and the articles afterwards.
We have mentioned for the last several months that they were teasing
Remix V three is going to be, not pre-ACT, its own component model,
something with iframes, whatever.
And our last comments on it were just show us some code already.
Well, at the Remix Jam conference, they did actually show us the code.
There was a, a repo put together that did timestamped links to all the appropriate
pieces of the announcement video.
So if you'd like to be able to jump in and see the examples of what Remix
V three code is supposed to look like, that should make it easier.
My first impressions, again, just having seen screenshots of the code in
following the discussions, is that Remix v three's component model is sort of a
mixture between React, view and backbone.
So it's kind of like React in that you have function components
and they, and that uses JSX.
It's kind of like view and the composition API, where you're
given a closure as the setup.
It's a little bit like backbone in that the function component
you're rating still sort of is organized like as if it were a class.
It passes in a reference to the instance rather than getting
the props as an argument, and you're supposed to call it this.
And part of that is to make use of a TypeScript typing trick that
lets you declare the type of this as an argument to a function.
But also you manually trigger updates by first mutating a variable
in the setup closure, and then you manually call this update.
And so Ryan Florence even said, this is basically old school React class
component, this dot force update.
Essentially, so I, I can see bits and pieces of parallels and influences
between all three of those frameworks.
When I look at the Remix code, it's also supposed to come with a
bunch of utilities for being able to compose event handlers together.
And yeah, so we, we have finally seen the code.
I believe they also gave some demonstrations of what the server side
loading story is supposed to look like.
Some kind of an I frame alike component that has its own URL and
can automatically re fetch HTML.
I haven't looked into those pieces as much, so very big picture.
I saw a lot of people arguing about having this dot update.
A lot of people saying it feels like a step backwards, it's manual update code.
But some people demonstrated that you can very quickly write your own wrappers that
just call this DOT update internally.
I have seen wrappers that mimic like the used state hook.
I've seen wrappers for other state management libraries like Redux.
So it's a primitive that can clearly be abstracted if you really want to.
I saw some good posts and articles from James Long and a couple other
people with thoughts on the ability to compose interactions together.
Carl, to your point that modern React and all the new async
features feel very complicated.
Like there's good reasons why methods like transitions exist to try to give
better user experiences, but it's just all these additional concepts and behaviors
you have to keep track of in your head.
And Remix is trying to go for a less magic, less abstraction approach.
So we'll see what it means in terms of adoption.
Again, this is non-reactive, so different framework, different ecosystem.
Who knows what the actual adoption will look like, but I get the sense
of what they're trying to go for and I, I think it will appeal to
some number of users out there that want to have that kind of behavior.
Carl: Yeah, I'll definitely keep paying attention to it 'cause
they're thoughtful about things and historically have just done a lot.
So I'm very curious to see where this goes.
But my gut feeling here is that this is going to end up more as an API exploration
and that any great ideas that come out of it will be a fresh exploration and then
maybe validate some ideas that get brought into React or view or other big tools.
But yeah, I, I could be wrong, could be, could be more
independently successful than that.
They, they did stress in the video that I watched, that this
is all like prototype phase.
So they, like right now apparently there's splitting it all up into
a bunch of different packages.
They can iterate independently and explore a bunch of different things.
But the, the final intended usage would be from one package,
not from 20 different packages.
Just to throw that out there as a a thing that will change.
Yeah, I don't know.
We'll see.
I think the component model is just gonna be really hard to disrupt.
One, one thing I did see in the video of Ryan Florence talking about just talking
while he was demoing, he like compared and contrasted with like, here's how we
do state changes and you just call the dispatch function instead of set state.
And I was like, I dunno, you can do that in React.
Like they've been encouraging people to do that for years, for like six years
basically Ever since hooks came out and you could do a state reducer, they were
like, please, except for trivial uses of state, all of your state should be in
a reducer and you should use dispatch.
Not set state.
So just like calling that out as a point of comparison, like React has been
trying to do that for a long time too.
It's just nobody actually does, I dunno, just caught my attention.
Mark: Well least we have an actual code to critique now and argue
about instead of the vague teasing.
True facts.
Carl: I will happily continue reading code and critiquing.
Speaking of which , I love this project.
I have thought about doing this so many different times and I
never have because it's hard.
Somebody built the same app 10 times in a variety of different frameworks
and tools and benchmarked them and compared and contrasted their performance
in a bunch of different metrics.
It seemed like they focused pretty heavily on like bundle size to me, very wordy.
I, I will say I got a little bit lost in the
Mark: instruction.
Very wordy and very, also, a lot of the article was very clearly AI generated.
I saw some comments from the author saying he had written pieces of it in
sections and used AI to help with it.
So like there, there was clearly human involvement in it, but the,
the AI generation of the article itself was a critique point.
Carl: Yeah.
Just like as I'm scrolling, it's got so many paragraphs in a row
that are all like identically long.
Just a little bit of a wall of text.
I definitely skimmed this pretty hard.
All that aside, like I just love the idea of doing the exact
same thing with the exact same.
Like, well, I don't know that they use the same test suite, but that,
that was always my idea is build.
You build an end-to-end test suite and then you get a passing app for that test
suite in a bunch of different tools.
I meant to do more of a deep code review on a couple of
the different implementations.
It's a CanBan board, it's, you know, a Trello clone type project
where you're doing task management with cards and drag and drop.
I guess it, it's a great and a parable comparison because drag
and drop is really hard to do and so it's very frequently something
people try to lean on libraries for.
So if you are implementing it yourself, that's kind of cha, that
makes it a little bit challenging to use as a point of comparison.
But the tools that were used here, he built it analog, which I guess is
vanilla js is what I'm assuming, or
Mark: analog is actually a, a next like tool for Angular.
Carl: Oh great.
Okay.
So you built it an analog, which is an angular type thing.
And HTMX, Marco, which I'd never heard of.
Next.JS, of course.
Next.
Sure.
Qwik City, which is Qwik.
I've heard of Qwik City I had not heard of.
So this is I guess
Mark: probably another solid versus solid start type thing.
Carl: Qwik city to qwik Sure.
Solid start spelt Kit Tan Stack with solid and then Tan Stack with React.
Yeah, one of the first tables, one of the first actual like points of
comparison of the output tables is just on bundle size and how much
JavaScript was served in order to.
Get this app running.
They used Next.JS version 16 as the baseline and that was about 500
kilobytes gzipped, which is huge.
It's big hand stack.
Start with React.
Clocked in at about 300 kilobytes a little bit more with solid
was a half of that hand stack.
Start with solid was 150 ish kilobytes.
The smallest was Marco.
12. At 12 kilobytes followed by quick city at 88.
Oh, I just realized there's parenthesized compressed.
I thought I was reading the compressed and I was not.
Mark: There's also the board page versus the homepage sizes.
Carl: Yeah.
Okay.
Alright.
This is more confusingly presented than I realized.
Mark: I think the biggest picture takeaways, number one, it's worth noting
that the author of this article previously put up a post a month or two ago saying
that React by is the default choice and it's killing innovation in the ecosystem.
So that kind of to where they're coming from.
But I do think they did.
They were legitimately trying to do a real meaningful comparison, even
if the results were sort of what they were hoping they would be.
IE reacted big and bad.
So yeah, the big takeaways are like React itself is huge and so any React app is
going to be very large bundle size wise.
And look, if we do like Tan Stack with Solid instead of Tan Stack
with React, it gets smaller.
But also if you do these other frameworks, it gets even better smaller and then it
kind of ends with a bit of a, another rant about React is a bad choice.
Carl: Yeah, I, I will validate that.
To me it also looked like they really tried to give React a fair shake here.
Like, you know, if you wanted to, if you were wanting to complain about
bundle size, if React apps, like there are so many easy ways to bloat
this up to a couple of megabytes.
So like the fact that they didn't do that is indicative enough to me that
they tried to give this a fair shot.
It's cool.
I love this.
This is a great project, great effort.
I don't know that, to me, at the end of the day, this is interesting
and fascinating and a great point of comparison, and also like not that
meaningful because the performance metrics that you measure here that are
easily measured by comparing the outputs of identically functional applications,
that's really only like maybe a third of the reason why you would choose to build
an app with any particular set of tools.
Like really, if you're starting a company and hiring engineers
and doing a greenfield project.
Like some of the most important things are how much will this cost?
Mark: How well is everything?
How well is everything documented?
How easily can we spin up engineers who know these things?
I mean, the, the ecosystem argument is a real thing.
Carl: And like, you know, if it takes you two months to find a developer,
you know, a senior developer who can build your app in Marco, you
know, you could do that in a week.
I don't know.
The hiring for React is much easier than hiring for some niche tool.
And I have seen writeups of people saying like, yeah, we built our
startup on this niche framework and we couldn't hire for it.
And that ended up contributing to the death of the company.
So like, you know, these performance metrics are important, they're really
useful, it's great to have them.
So we know where opportunities to improve are like tying this
back mark to your Immer work.
Like if somebody hadn't complained about performance, you wouldn't
know that it needed to get better.
Pretty
Mark: much.
Yeah.
Carl: So this is great and I love it, but it's also not the end all, be all
of like decision making for, things.
Yeah.
It's also, man, this, it's just so hard to read because of how long it is.
I wish they'd stripped this down a bit more.
Mo: And if we take like a step back out of our like web ecosystem bubble for a
second, like you go to like the backend world and like enterprise business
companies or finance or whatever, and like they employ a lot of developers, right?
Like thousands, thousands and thousands of developers.
And like there's a reason they're all on Java and .Net is because like
they can hire for those and it's pretty easy to build a team around.
That's the top priority.
Even like this stuff is quite minuscule when people are, companies
are hiring at a large scale.
And then the second thing, which is like not accounted for, I think in this
like approach of looking at like just the bundle size that's outputted is the
fact that like your productivity with the fact that most of the AI tools are
really like optimized around React is not something that you should not look at and
consider when you're choosing something.
There's so much training data and so much like tooling around building React
apps quickly and prototyping React features or React apps that with AI
that is just a bit, it feels a bit moot some of some of these conversations.
It feels.
Mark: To be clear, like React has got itself has gotten
much bigger over the years.
In fact, even just 18 to 19 it got notice will be bigger.
Bigger bundle sizes are not a good thing.
We are not sitting here saying Your bundle size does not matter.
Alex Russell, as much as I disagree with his communication style is right
to point to the technical receipts saying that big bundle sizes are
bad, but also it's not the only single metric you should care about.
Carl: Yeah, right.
Yep.
And also, last thing I'll shout out here.
I think the author of this blog post also mentions that he tried not
to pull in too many dependencies.
So like did not pull in fetch wrappers or data fetch tools like React Query and.
Axios, the data fetch thing, which many people still use, I don't know.
They still have a fair amount of utility just for things like observability and
security and various guarantees like that.
Like Axios itself is 36 kilobytes ified like 14 compressed.
React Query is 55 kilobytes.
I guess to say that the way he did it is actually better quote unquote
for React in terms of the bundle size argument, but it's also not representative
of how people actually build apps.
It's a challenge of these types of articles is that by necessity it has
to be the level of scope that a single developer can execute on their own, and
that's just not how most apps are built.
Like most apps are not passion projects by one person.
So yeah.
Super cool.
Love this post.
It's interesting more than it is authoritative, I think.
Mark: Good way to put it.
Mo, tell us about Solito.
Mo: Yes, Solito.
So go back a few months.
You'll remember that we said Fernando Rojo joined Vercel.
And he joined as the head of mobile firm Vercel.
This was significant because he's the author of this library called Solito
and a few other libraries like Ziga.
So he's really, for the last few years, has been focused on.
Using React native on the web as well, especially with Next.JS.
So he built his own startup in that sort of tech stack.
It is from experience and having built with this tech stack quite a lot,
it's a challenging approach because you are always balancing oversharing
between your native components and your React native code and the web
functionality that you import in.
And oftentimes that comes at a detriment of performance or ux,
depending on if you do it right.
And the more that you share, the more chance there is that you're
not, you're sharing something that you probably shouldn't share.
And so there's a lot of libraries in the secret system, but Solito is
probably one of the key ones where it lets you share navigation across
Next.JS and React native apps.
Now, we've talked a bit about Toledo in the past.
One of the big limitations that any library in this space has is
that it relies on React Native Web Now, React native web was
made several, several years ago.
I think it was back in 2015.
And it was made by Nicholas Gallagher.
Now, he also did a talk at React Conf, which I would recommend
you watch about React strict dom.
But the key thing with React Native Web is that it's not really receiving
as much love because Nicholas is working more on React strict dom, which
is sort of like the future path for sharing code across the web and mobile.
And so React native web is, is a little bit bloated, and what that means is
that any library that you really use, especially your, something like your
navigation and routing library will import in large portions of React Native Web,
even if you're not using all of the APIs.
And so that means that your bundle size goes through the roof.
And what the Vercel team slash Fernando Roho have now been able to do is actually
remove React Native Web as a dependency from from Solito, which is pretty massive.
It sets us up in a foundation where you can effectively get ready for React
strict dom adoption more easily in the long run, but also means that if you
pick and choose your libraries well, when you're building a UniVercel app and you
really think about what you're using on the web platforms, you can really start
to tackle that bundle size problem.
It doesn't help if you're using libraries like let's say Reanimated, which has a
pretty heavy reliance on React Native web.
But if you're going really vanilla and you're very careful, it means that
you can actually achieve much better performance on the web by using this new
version of Solito, which is very exciting.
So yeah, if you're already using Solito, give it a look and if you're
thinking of building a uniVercel app, it's a really good candidate if
you wanna build a highly performant web variant of your application.
Carl: I love that.
It definitely makes a lot of sense to start moving away from
React Native Web, given that we've compared and contrasted React Native
Web with like React strict dom.
I guess it makes sense to move away from React native web, 'cause
the guy who made it is now doing a different thing in the exact same
space from a very different angle.
So yeah, that's a pretty strong argument for changing.
Mark: Okay, the last major topic for the day next 16 and directives.
So next 16 came out.
The headline feature is they now have what they're calling cash components.
This is the, I don't know, second, third, fourth iteration on how
to do caching in next, across the last couple major versions.
I'm not gonna pretend that I understand what, how this works.
No one does, but thing is that they introduced.
Another new directive.
Now to recap a directive is these little strings that you just put in your code.
Originally we had use strict back in the ES 2015 days and then React server
components introduced, use server and use client, and now we have 'use cache'.
And the idea is that by slapping this directive on certain components, that
tells the next bundler and compiler that, Hey, this is the output of this
component is supposed to be cached.
I don't understand the details.
From there, go read the documentation long.
With that, they also announced a new long-lived workflow product, kind of
similar to what the temporal company.
Has built where you can have a function, for example, that implements a billing
workflow by sweeping for 30 days and you've written what looks like one
function, but under the hood it's actually like saving its status to a database and
then a time job wakes it up and continues executing the code, that sort of thing.
And I believe they opted to implement this also with a use workflow directive
and like a use step directive.
And I think there may have even been one or two others related to
variations on caching, like use Cache, remote, something like that.
And meanwhile, we've also got the React compiler has opted to use
directives for a couple things.
So there's a use no memo directive.
If you want to tell the compiler, don't try to auto optimize this component.
And so all of a sudden we've gone from the JavaScript language specifying.
One directive.
There was also the unofficial, oh, was it use a SM directive that
was part of a SM js, the precursor to web assembly, but like one
official directive in the language.
And now we have a couple for bundlers, and now we have more for workflows and
the compiler and all these other things.
And so the Twitter discourse over the last couple weeks has
been our directives, good or bad.
And they're so confusing and they are changing the language.
And you have all this bundler defined behavior that is not
part of the language spec.
And so Tanner Linsley, again, creator of all the different Tan Stack
libraries, put out a blog post where he expressed his opinion that he does
not think directives are a good idea.
Because they are unofficial, because they're not standardized, because make
it not clear what the actual intended behavior ought to be, as opposed to
like explicitly importing a function that says, turn this into a client
server function or something like that.
So there there's been a lot of arguing about directives
and are they understandable?
Are they good or bad?
Are they too much magic?
So that's been happening.
Carl: I'll say it.
They're bad.
It's too much magic.
I hate it.
I'm not a fan.
Mark: I understand the thought process.
I, I can't say I'm thrilled.
And so on that note, two article articles that are related enough
to throw them into this section.
I've seen lots of different article articles upset at Next or critiquing next.
Most of them are frankly very badly written, but I saw one come out last
week that I thought was very well written and focused strictly on the technical
pros and cons of using the App Router.
The title is Clickbait, everyone Hates Next, but the article itself
is actually very well written.
It discusses technical aspects of using Next, some of the problems his
team went in, ran into, and how and why they ended up migrating from the
App Router over to 10 Stack Start.
And then Nadia Vic, who has done a bunch of very excellent articles on
React rendering behavior, put together a very data-driven look into do server
components actually help with things like First Contentual Paint and various
other White House style metrics.
So very worth reading.
Carl: As I'm trying to think about how you might solve problems of caching
and runtime things without directives.
And I'm thinking about, you know, my experiences using like CloudFlare
workers or other runtimes where it's not a traditional process scope.
And I don't know, I guess like it is a really challenging question
of like, how do you signal to a developer that the file they're editing
runs in a certain type of context?
And I guess I understand why directives are an appealing thing to
reach for, but man, just the state we're in right now is really a lot.
I found the Next.JS docs page with directives and it lists 'use cache',
'use client', 'use server', and then two sub variants of 'use cache'.
And that's not all of 'em that, so there's missing ones here and.
I don't know.
When you start getting into like many different contexts, just naming
them at the top of the file doesn't really seem like enough for me.
I don't know.
And then like the implication for that code can import other code that will not
have it flagged what context it's running in via a directive at the top of the file.
And I don't know.
It's a tough problem.
It's a weird unanswered question in the industry, like not even the
ecosystem, but like the industry.
How do you flag code that might run on your browser, a real server, serverless
environment, and yeah, I don't know.
It's a challenge.
Mark: I think it really does speak to the overhead and mental complexity
of trying to juggle all these things.
We said earlier that React 19 has, 18, 19 have introduced a whole lot of things
like transitions and other pieces to try to let you write better user experiences.
But now you're having to juggle in your head like, here's the current version
of my app in its display state versus a work in progress rendered version
versus a future output rendered version.
On the server side we're having to deal with, this is server code, this is client
code, sometimes they're mixed together in the same file, sometimes they're
mixed together in the same component.
Which code is running?
In which context do I have to worry about accidentally leaking security
tokens or something like that.
We're building tools to solve real problems, but there's more and more
to juggle in your head as you go.
Carl: Well, I'm gonna plug effect one more time because I saw it come up in the chat.
Oh, man.
It just like talking about different ways of signaling facts about the code.
The code you're writing has certain dependencies.
Certain dependencies is too loaded.
That's, that carries too much context with it, but the code you write
has a certain amount of assumption baked into it about what will be
available and what it can rely on.
The thing I love about a fact is that it makes that more explicit
and brings it into the type system.
So I think the challenge right now is that we are missing a like platform
and language level abstraction to express information like this.
And yeah, I don't think we're gonna get it anytime soon.
And I think these explorations will lead to something like that and
hopefully converge into something.
But I think this is gonna be like a real state-of-the-art problem
for a couple of years and still, which I hate, but it'll get better.
Mark: Alright, moving on to the lightning round.
In addition to React Con and Remix Jam, we also had Vite Conf and the V
team gave a bunch of updates on all the different tools they've been working on.
Some of the highlights to me were that OX LT now supports ES lint and JS
plugins via some really awesome tricks for interop between js and rust without
the the cost of serial serialization.
They announced a combined tool chain called v plus, which basically pulls
all the different tools, VIOX lint, OX format, Vitest, everything else together.
That'll be their enterprise sales targeted tool set.
And then Vitest four is out with browser mode support.
You basically just put a flag in your Vitest config and suddenly
your tests are running in a real browser instead of a node plus js.
Last week, AWS east went down and the internet died and they put out the
postmortem and it was DNS apparently they, their internal DNS system for
dynamo DB had like three different instances of the DNS updater running
and one of them got stuck and was taking a long time to complete, and the other
one came along and updated and then said, well, these, some of these plans
look out of date, let's delete them.
And next thing you know, DNS goes down, dynamo DB goes down
and the internet goes down.
So, oops.
Mo: It's funny that the, uh, internet is backed by Dynamo db.
Mark: A lot of people like us East One is the default.
A lot of people have tried to get away from US East one, but when a lot
of Amazon's own stuff depends on US.
East one.
Yep.
You all
Mo: of your certificates can only be issued in US East one,
so that doesn't really help much.
Side note, if you end up working in a consultancy one day, just hope nothing
like this happens because the morning of was fascinating reaching out and
getting reached out to by a bunch of clients being like, my site is down.
And then having to figure out what's going wrong, which is US East one on AWS.
So it was a fun Monday,
Carl: but at least the uh, at the end of it was a vendor is out.
This is not our fault.
Mo: At least it was that, which was great.
Cool.
Moving on.
So a couple of React native lightning route items.
Firstly ra, which is really cool because we've talked a little bit about live
activities on iOS and iOS extensions, all of the little widgets and stuff
that you can now use on your iPhone.
And you were able to use iOS extensions within a React native app.
But the challenge was you had to write SWIFT code to be able
to actually implement those.
And so a independent developer named S has been working on building an MPM
package that allows you to ship these custom widgets and extensions without
needing to use Swift X code or extra js, which is so cool because he's basically
had to like write a translation layer or a render that takes React UI code.
And converted to Swift UI code, which is not trivial because many
have tried before him and failed.
So this is a really cool project and like it's one of those things
that's like kind of mind blowing.
So kudos to him for making this.
Secondly, and I thought this was an interesting article to link to.
On the expo blog, they publish an article about building fully native apps with EAS.
So EAS is expo's application services.
Typically, this is being used to build React native apps that are usually
running on Expo, but actually a lesser known fact, and one that we've actually
used on some of our apps is that you don't need to be on Expo and you don't
even need to be on a React native app.
And so EAS is really great and it's become super mature and it's a really just good
build tool for building mobile apps.
And so people have started to use it in the wider mobile community rather
than it just being a React native thing, which is quite cool to see.
And lastly, this was something that Tzveton from the Hermes team in Meta
actually, uh, published a week or so ago.
And this was actually something he linked me on a DM because we were chatting about
interesting things that could be talked about at a conference by a Hermes team.
And this was quite cool to see.
So for those who don't know, Imgui is like a very light UI layer that is powering a
lot of sort of debugging for video games.
And it's used in a bunch of other places, but like the key thing is that it's just
like a very, very lightweight UI layer.
And so he made a puck of basically using React and then rendering
it on Imgui, which is quite cool.
And it runs obviously like fully natively.
It's fully running on c plus plus.
And all it really needed was some typed JavaScript and it's basically just
React really, which is quite cool.
So yeah, it's just a little cool fun POC, but it shows the power
of using React and how it can be applied to different contexts, which
I thought was quite cool to include.
Mark: Okay, Lodash has powered much of the JavaScript ecosystem for years.
Those of us who have been around for a while, remember its predecessor,
but low, has also been relatively unmaintained for a while.
The author John David Dalton, said there was going to be a low dash
version five, and then that never really happened, and so some announcements
came out in the last week or two.
That low dash is being taken over by a new maintenance foundation, and they're
going to be doing work to update the ci, put out some new maintenance releases,
and then apparently when low dash V five happens, it'll be more about stripping
out a lot of the internals that tried to polyfill platform behavior and
try and make it lighter and make use of platform built-ins at this point.
So Lodash is still around, it ain't going anywhere, and good
to see it being maintained.
And then there was a really good post unrelated to React, but cool on building
your own key value database system that walks through a whole bunch of pieces on
what a key value database actually has to track and how the internals would work.
And I believe it's actually pretty interactive, which is cool.
Carl: This build your own database post, I love, this is so good.
I love when people rebuild foundational building blocks.
And this is also something I've thought about a little bit because he talks
about in a file, you know, if you need to store something, put it in a file.
And this is something I've thought about a little bit because I have been
using SQL Light pretty extensively in my own work the last couple of years.
And at the end of the day, sequel light is a file.
So like when I realized that like most of the time.
If I want to store something in a file, like I should just use sql,
you put something in a file and then the file gets too big and you need
to optimize it, and you need a better way to access it and like, oh, maybe
I could use a more descriptive query language to get things out of it.
And like the end result is that you will recreate a shittier less performant
version of SQLite that doesn't use sequel.
And so, I don't know.
I just like reading this that was very strongly on my mind and
everyone should do SQLite if they start putting things in a file.
'cause it's just a file.
It's cool.
I like it.
Mark: The SQL Light website even has a page that says why, why you should
consider just using SQL L as your app's file format rather than inventing
another new binary format from scratch.
Carl: A hundred percent.
If you start right, if you start thinking I should put this in a binary
format on disc, like no, stop it.
Use SQLite.
It's great.
Mark: Alright.
Jared Palmer, the creator of the Formik Library, has had
been at V at Vercel for years.
He worked on turbo repo, v0.
And he announced just a month or two ago he was leaving Vercel.
He has then announced that he has joined Microsoft as a senior VP at GitHub.
And the first thing he did was post on Twitter saying, how can we make
the GitHub PR experience better?
And he got like eight or 900 replies, and he was pretty actively
engaging with a lot of 'em.
A lot of them were people asking for things like Stacked Diff support, so
you could have multiple PR branches that depend on each other and be
able to automatically update them.
He actually came back even just a couple days later and gave some
technical details that he had found after internal discussions on here were
some previous prototypes of stacked diffs at GitHub and how, like how far
they got and what the blockers were.
So I have no idea how long it'll take to roll out any of this stuff, but like
he seems pretty serious about trying to improve the PR experience, whether
it's paper cuts or new functionality and is trying to look into that stuff.
So given that we all pretty much depend on the GitHub PR experience,
I'm happy to see improvements.
Carl: Yep.
Love that.
Wow.
This is very jargon heavy.
Mark: Yeah, I, I know, that's why I was happy to see it.
Cool.
Carl: Sounds like a technical roadmap.
Mark: Couple other bits, node 25 is out and so another development line branch
for node and the biggest thing there is they've updated the version of V
eight and that includes those faster js ON string of FI improvements that we,
we talked about a couple months ago.
So given how much everything depends on JSONs string offi, it's
nice to see that being sped up.
And speaking of more optimization work, I believe Theo put out a benchmark
where he was comparing CloudFlare in Vercel in Building Next versus
Vanilla versus a couple other things.
And it pointed out places that both Vercel and CloudFlare were slow and
CloudFlare jumped on this and they found a bunch of places in their system.
Where things could be optimized.
They did a excellent blog post detailing some of the improvements.
They also went in and they looked at next itself and they found a bunch of places
where Next is doing like useless request copying like 1500 or 1700 request streams
per request or something like that.
So basically everybody is getting faster as a result of
this, which is a good thing.
Mo: CloudFlare folks are just doing some great work recently,
especially with the whole like workers rebrand as well is really cool.
Mark: So Interop is an attempt to get all the different browsers on the
same page in terms of what features they're working on, especially around
compatibility with each other each year.
And so this year the Firefox folks put up a rather nifty interactive
suggestions thing where they list dozens, like 50 or a hundred different
potential features or technical areas of emphasis that they could spend time on.
And it's got a neat drag and drop interface where you can basically use that
as a way to vote for which features do you want browser manufacturers to work on?
This year.
Carl: Love that.
Yeah.
They say they're gonna publish the final selection of proposals
in February, so I'll, I'll keep an eye out on that, I guess.
Cool.
Chris Chedeau, vjeux, he has been really prolific in the
React ecosystem for many years.
Was really influential in React becoming open source and was the original
author of Prettier, which changed my professional experience significantly.
He put out a blog post titled The Birth of Prettier earlier this month.
I'd spent almost 10 years since Prettier was released.
He says, which is wild.
I like his introduction of this is the story of how the tabs first spaces
Holy War ended, and yeah, it did.
I appreciate that.
I actually just did a little DX PR for a code base.
I maintain to make better use of prettier because somebody created a plugin to
sort imports and like, yes, I love that.
I hate sorting my imports and I hate when of my imports are not sorted.
The introduction of automated formatting into the JavaScript ecosystem
was, oh, what a, what a blessing.
Like what hours?
The years of my life that have been saved from arguing over
formatting is just really lovely and this is a great retrospective.
Looking into just the whole process of how it came out.
Mark: There's some fascinating details in there.
Carl: Yeah, like one of the challenges of this that I remember in the moment a
little bit, but like if you're gonna start formatting things, the format needs to
be something relatively unobjectionable to the people who are evaluating
whether they want to use it or not.
Like, yeah, so, and then figuring out what options should be exposed,
what is actually configurable, because if you make it too
configurable, then it's not helpful.
If it's too much manual thing, then it's not actually consistent enough to
be valuable at its intended purpose.
So lots of really interesting details throughout here.
Definitely recommend it.
I always love a great technical white paper, a writeup of implementation,
and this is, oh boy, is this that.
It's great.
Mark: One of the most interesting bits I saw was he was talking about
how they started rolling it out and like Prettier has some options,
but they wanted to minimize them and he wanted everyone to basically
agree on a single set of options.
And so he said the strategy I used to figure out how to make this work was
lining up incentives so that it took a ton more work to use a different
set of options if you wanted to.
It said Prettier is either in this, in CI or in your IDE.
So I made it so that they read them from different places with a
different rollout schedule to make it harder to choose one or the other.
Carl: Oh, that's incredible.
That's some good details.
Reading this a little bit more is it's got lots of fun non-technical details
that like they're not the engineering work, but they are absolutely essential
for actually making a thing that is successful and sustainable and thriving.
Like it also talks about money and like ongoing maintenance is
a thing that you have to pay for.
You don't have to, I guess most open source does not, but if you don't,
then it has its own challenges.
So like not only is this a great technical writeup, but it's also a great, I don't
know, like entrepreneurial writeup.
Mark: How do you do the, the real work to make stuff happen?
Carl: People talk about the difference between like senior and staff
engineering being, the difference between junior and senior is how
much English you're asked to write.
And the difference between senior and staff is like how much non-technical
things you're asked to account for.
And so this is a phenomenal, I would say, staff engineer writeup.
Like, this is how you take an idea and you make it an industry level impact project.
Yeah.
Great Writeup.
Mark: I can even point to a couple personal examples of how
prettier has affected my work just within the last few days.
One is that I'm jumping between the Redux repo, which is two spaces,
single quotes, no semicolons.
The Immer repo, which is four spaces, double quotes, and I can't, and may,
maybe no single semicolons, Replay.io repo, which is four spaces, double
quotes, semicolons, and I don't think about any of that anymore.
And then also just yesterday, I was trying to tweak some of ER's exports and tried
to put in an export type keyword, which I was pretty sure was a legit thing except
that when I hit save, it didn't format.
And I have learned that if it doesn't format, I have put in invalid
syntax somewhere for a moment.
It was like, oh, export type must not be a valid TS keyword.
And then I finally realized, oh wait, this is on prettier 1.19.
That must predate that syntax being added to TypeScript.
And so I had to update prettier, but like that's how much I have learned to lean on.
You hit save and it formats and it's valid.
Carl: Yep, a hundred percent.
I, I recognize that in myself as well.
Okay.
Let's wrap it up with some conferences.
Mo: Let's jump into it.
So we've hinted a few times and I can now say that we've
got Seth Webster's endorsement.
So the executive director of the React Foundations talks about my conference.
I'm very happy today.
We've been organizing this for the second year, so React Native London
for anyone who's a React native enthusiast in London and beyond.
We have people from Brazil and India last year, so that's like the
furthest extent that we have people coming in from around the world.
But if you are interested, we've got our conference on
the 13th and 14th of November.
In Central London, we've got a beautiful venue, some great talks from Meta, Amazon,
Microsoft, and just a bunch of community people from expo and independent app
developers who are gonna come and give some really, really phenomenal talks.
Use the code TMIR 10 and you should get a 10% discount on checking out, which
will, if I'm doing my mental maths right, make the ticket price 330 ish pounds
for a two day conference to be able to attend workshops and the conference day.
Carl: Um, other ones we've got coming up are Wey Wey Web November
17th and 18th in Malaga, Spain.
We've also got React Summit November 18th through 21st in New York.
Mark: There's JS Nation on the 17th.
There's in-person React Summit in person on the 18th, and then they
have an online day the next week.
Okay.
Carl: Oh, oh, oh yes.
I see it's 18th and 20th, not through.
Interesting.
One day in person.
One day online.
Okay.
Makes sense.
There's also React Advanced November 28th, also
Mark: in London the day after Thanksgiving.
Someone in England didn't think about that part.
He, he, he,
Carl: yeah.
It's not for Americans.
Mo: It's not just React Advance, it's also Tech Lead Conf, which is
also organized by the Ation folks on the same day in London as well.
So, no, I would doubt that there's gonna be a lot of people from
the states there, unfortunately.
Carl: For sure.
Well, I'll, I'll also add, I just saw like two days ago, the organizer of
React Paris posted in the events channel here that CFP is open, so we gotta React
Paris if you want to submit a talk.
But that's gonna be in like March though, so not anytime soon.
That's all we got.
Thanks so much for sticking around for a whole 90 minutes.
Mark: It was a very busy month.
Okay.
Carl: Yeah.
We'll be back next month, on the last Wednesday here in the live
stage or back in your podcast feed just as soon as we can.
Yeah.
Thanks so much.
Well, normally we gather sources from a variety of newsletters.
We actually had so many things that Mark shared in the tech
reads and news chat this month that I don't think any of us did.
So that's cool.
Mark: And I pasted a lot more links in the discussion threads too.
Carl: That's something I should be better about.
That would be lovely and helpful.
But yeah, if you see anything newsworthy, definitely let us know
in the Tech News and Reads channel, just like Mark has been doing.
You can also email us at hello@reactiveflex.com.
But you know it's a community like Join, participate.
I do read every email though, so if you send something I, I will read it.
If this is a show that you get value from and want to support, best way
to do so is by submitting a review wherever you listen and by telling
your friends and coworkers about it.
And go to a meetup and say, Hey, there's this great podcast I love.
Cheers.
See you next month.