Carl Vitullo: Hello, thanks for joining us.
This is June's edition of This Month in React, where we recap and digest
the recent developments in the ever evolving React and web ecosystem.
We're coming to you live from Reactiflux, the place for
professional React developers.
I'm Carl, I'm a staff product developer and freelance community manager here
at Reactiflux, where I run community programs like these events and build
tools that help keep the community going.
Mark Erikson: Hi, I'm Mark Erikson.
My day job is working at Replay.
io where we're building a time traveling debugger for JavaScript.
And outside of that, I do Redux stuff.
Mo Khazali: Hi everyone.
I'm Mo.
I head the mobile team at Theodo.
I'm quite active in the React Native community and I organized the React
Native London meetup and here and there dabble in open source with a couple of
libraries in the React Native ecosystem.
Very happy to be here.
Carl Vitullo: Uh, I'm just going to start off with some quick hits
of new releases and conferences.,
Starting off immediately, because the market, the job market is so bad, I've
been reading off stuff from layoffs.fyi.
We're not quite at the end of June, it's a couple of days left at time
of recording, but most of the way through June, we're at about 9.
2, 000 laid off from 40 companies, which is down, I mean compared to six
months ago we're down substantially, but compared to two years ago we are up
substantially, so it's still not great.
I've seen some other broader metrics trickling out from other places,
like I saw a link from ADP that I unfortunately don't have handy
suggesting that the overall like, tech market is at about 80 percent of
it was, I believe, compared to 2018.
Yeah, I, I found that really interesting because between hearing headlines about
like record hiring during the pandemic and record layoffs in the two years, after
that, it was like, Where do we end up?
So that's the first data point I've seen, uh, addressing that question of, like,
what's the net gain loss, and it suggests net loss of, like, 20%, which seems
massive, but yeah, it's also, it's ADP, I don't know how much to trust that, I
would assume that they got a very large sample size, but I'm not sure how they
defined, like, tech, so, I don't really know how to interpret that in, through
a lens of like software development.
But yeah, moving on to some new releases.
There is TurboRepo 2.
0.
That's probably especially relevant if you're doing stuff with Next.
It looks like it's mostly like a fancier UI.
They're doing like a pretty high effort in terminal UI.
Like it's, you know, reactive and interactive.
And you can now break down your logs on a per task basis rather than it
just being, you know, a constant scroll back the way terminals usually are.
So that seems neat.
Oh, they had some new docs, and it looks like they included some,
like, fundamental information about Monorepos, which seems cool.
React Admin released version five.
We actually had Francois Zaniotto, hope I'm not mispronouncing that,
on as a guest a couple of weeks ago, and I think he's super cool.
I love his ethos for the company that he's building, which maintains
React Admin and does agency work.
So I just wanted to shout that out.
RS build released version 0.
7, which they say is going to be the last release before 1.
0.
Mark, you had some thoughts?
Mark Erikson: ByteDance, the folks behind TikTok, have a massive
web tooling infrastructure team.
They've actually rebuilt Webpack in Rust, and I know that, you know,
rewrite it in Rust is its own meme at this point, but it seems like
they've, they've truly built a Webpack compatible version in Rust called RSPack.
On top of that, they have a higher level abstraction layer called RSBuild,
which has an easier configuration format, a little bit like ESBuild does.
if you actually look in their docs, they have a migration guide for switching
from Create React app to RSBuild.
I did that on a little side project a few months ago.
It was really easy to switch and the compile time dropped from like
30 seconds to less than a second.
it feels like a, an actually viable competitor tool.
Carl Vitullo: Nice.
Super cool.
We've also got biome 1.
8.
Yeah.
I have a soft spot for biome.
I was an early supporter of Rome.
I have been eager to see what comes out of that.
So yeah, it looks like they've got like new support for CSS.
They have better support for language servers in workspaces, so
if you've got like a big monorepo, it should work a little bit better.
New reporters, migration, some more linting options, but yeah, Biome
is like kind of an all in one.
They try to do like formatting and linting and, yeah, it's a bundle play.
They're taking in a bunch of tools that, were separate and
doing it all as one package.
Mark Erikson: And written in Rust.
Carl Vitullo: Written in Rust.
Sure.
So super fast, blazing fast.
Is blazing fast still cool?
There's also Astro 4.
10.
I am hoping to play around with Astro this month.
So maybe I'll be able to actually, you know, say some more intelligent
things about what the experience is.
But I, I know lots of people who love the tool.
It looks like some small improvements, nothing too major.
This is a new library to me, Valibot released 0.31.
It's a competitor to Zod, which does like schema validation or, you know, data
validation through a schema with like type generation and all that kind of stuff.
This looks like a pretty solid competitor.
They talk about, tree shaking and stuff, which I'm broadly skeptical
of tree shaking as a general promise.
It's very difficult to verify.
Mark Erikson: My understanding is that Zod, when you import it, you're
basically importing a giant object that has all the possible validation types
built in, and I think Valobot's sales pitch is that it's a bunch of individual
functions, and so you would only import the actual bits that you need.
And therefore, you're not getting a giant blob of runtime code.
Carl Vitullo: Yeah, I think they said it was like, could be up to like 95
percent smaller than Zod, while also like significantly simplifying the mental model
of the schema and the type validation.
If I can think about it less and have it affect the size of my code
less, like both of those sound like things that I would want.
Mo Khazali: I guess the thing is, it's a question of how much you
want to really optimize your bundle size and at what stage you're at.
If I'm recalling correctly, Zod minified and gzipped was about
60kb, something around that size.
So it is quite a chunky library to add into your dependencies.
So, I guess if this actually delivers on that promise and it's closer to
90 percent less than that, which is I guess 6kb, it wouldn't be
too bad of a shave to do, I'd say.
But, remains to be seen if it's in practice going to be that good.
Carl Vitullo: Yeah, I just pulled up Bundlephobia for Zod, and it's, yep,
61kb minified, 14kb minified and zipped.
Which is Hefty.
Yeah, that's enormous.
That would give me a lot of pause.
Onto some conferences.
Mo, I think you had a few.
Mo Khazali: Yeah, I'll jump right in.
So, firstly, at the very beginning of July, 4th to 5th of July,
React Nexus is happening in India.
One of the great conferences that I attended last year, I really enjoyed.
The crowd there was quite a, quite a large crowd as well.
I think there's about 500, 600 people.
So a massive conference, but people are so friendly and I got
to meet a lot of lovely people.
So would highly recommend if you're sort of in the South Asia region
to, to definitely give it a shot, if you can make it to Bangalore.
Mid July, we have Chain React and this is hosted by the folks at Infinite Red.
Another one of those great conferences.
I've not been to Chain React myself, but I'm, So involved in the React
Native community that I get told every year, why are you not at Chain React?
And you're missing out on one of the best conferences ever.
So the FOMO hits real hard every time around Chain React.
The folks at Infinite Red are absolutely amazing, and they
organized an incredible conference from all accounts that I've heard of.
Everyone really loves Chain React, so if you are in the U.
S.
and you're in the React Native scene, you really do not want
to be missing Chain React.
If I was in the U.
S., I would definitely be at Chain React this month, so I cannot
give it more praise than that.
And then, lastly, towards the end of July, we have GeekConf, so GeekConf
is another sort of React Native conference with a little bit of a
blend of web as well added into it.
So that's happening on the 25th of July in Berlin.
There's also a day that's dedicated to remote track, but 25th of July is the
key date that's going to be happening in person, and I'll be speaking at
that conference as well, and hopefully if any of you folks are there, please
do come around and say hi, would be lovely to meet some of you in person.
Carl Vitullo: Heck yeah.
Leaving the list of conferences that us as hosts have personal experience with,
there's a We Are Developers World Congress in Berlin, July 17th through 19th.
There's a CityJS in Singapore.
That's going to be July 24th through 26th.
We love JS in Amsterdam in the Netherlands, August 9th and 10th.
And then the last conference that we're highlighting in the next two months is
React Rally, which is going to be August 12th through 13th in Salt Lake City.
Actually, I have been to that one in the past and it was pretty quality.
Mark Erikson: Yeah, I, I would also.
Emphasize like React Rally has been fantastic.
the organizers are great.
they do a really good job of giving it a good community feel.
I was there last year and attendance was unfortunately just a little down because
of trying to revive it after COVID.
So if, if you can all make it to React Rally in August, please go.
It's, it's totally worth, worth it.
Carl Vitullo: Yeah, and it's the home neighborhood for a lot of really big
people in the React and web ecosystem.
there are quite a number of people who live generally in
Utah and in Salt Lake City.
I think Kent C.
Dodds is out there.
Mark Erikson: Kent, Tanner, Ryan.
Carl Vitullo: Yeah, it's their home neighborhood.
I assume they'll be at the conference.
Yeah, anyway, cool.
All right, moving on to some of our main content here.
Mark, you want to start us off?
Mark Erikson: Boy, oh boy, oh boy.
Okay, welcome to SuspenseGate.
So, for the for those of you who may not have been following all the
drama on Twitter, we're here for you.
About a month ish ago, a month and a half ish ago, Andrew Clark actually tweeted
that, We've, we've updated to a new React 19 release candidate, and we think that
this release candidate is going to be the final one, like, these are the actual
bytes we plan to release as React 19, unless there's any other major changes.
Well, there is now cause for major changes.
And in fact, React 19 has been delayed semi indefinitely.
The React team is going to be doing some updates, and we don't know
how long that's going to take.
Why are they doing these updates?
In November of last year, Andrew Clark put up a PR that changed the
behavior of the suspense component and how it manages loading children
that are suspending to fetch data.
Previously, if you had multiple children inside of suspense, And
they all wanted to fetch some data.
The suspense component would give each of these components a chance to start
rendering and start the data fetching.
And then actually pause and wait for all of the components
to finish fetching their data.
Doing it all in parallel, kind of like a promise.
all combination.
And with this PR, the React team changed it.
So that React really only gives the first child that suspends a chance to
fetch, and then it waits for that child to finish loading its data, tries to re
render, and then keeps going until the next child component tries to fetch data.
Basically doing all of that in serial instead.
Now, they, if you look at the PR, Andrew listed some potential reasons for this.
One is that this actually made Facebook.
com load a little faster.
But also, it has to do with how the React team thinks.
that people should be doing data fetching on the client side.
And basically their argument is, you, you shouldn't be doing data fetching
nested deep in the component tree.
Instead, you should hoist it up to the top at like the route
level or the page level instead.
And so their argument is like, well, we don't think people should
be doing this pattern much anyway.
So it's okay for us to change it.
Now, this was done as part of React 19's development, and
React 19 is a major version.
So you can totally, you know, make changes.
It's, it's legal under the terms of semantic versioning.
And this was available in the React 19 Canaries, but as we all know,
nobody actually tries out pre release versions, everyone waits until
it's actually released, and then tries it, and then reports bugs.
So, this basically went unnoticed by the community for months.
And about a month ago, someone mentioned it on Twitter, very briefly, and TK Dodo,
the maintainer of React Query, Saw that comment and said, oh, that doesn't look
great, and then didn't think about it.
And then just a couple weeks later, there was another discussion thread,
and suddenly TK Dodo and a bunch of other people began to realize, wait
a minute, this is actually a very significant change in how suspense works.
And in particular, the React 3 Fiber developers, which is the React for
3D game engines, Realized we depend on suspense heavily because we need
to be able to load a lot of different things async like game assets.
So it's not just about data fetching, it's about lots of other async behavior.
And they, and they started showing demos where, everything
went from loading in parallel to loading as a waterfall in serial.
And now example apps were way, way slower as a result.
There was a massive firestorm on Twitter.
A day or so later, Sophie Alpert from the React team said, We talked about
this in a React team meeting today.
We didn't realize how many people would be affected by this.
But also, this was a very major change to React's internals.
We did this, like, seven months ago.
We've continued making lots more changes to the internal since then.
We can't just roll back this change.
We know what we would need to do in order to re enable the old behavior, but it's
going to take another fairly significant set of internal changes to do that.
So, we don't know when we're going to get around to it.
Stepping back for a second, at that point in time, the community
conclusions were, they already said React 19 is release candidate and
ready to ship, and we don't, like, we know this would take major changes.
Therefore, the conclusion was React 19 is about to ship with this behavior and we're
all going to be stuck with it for the duration of React 19 as a major release.
Carl Vitullo: Yeah, I don't know, some of the like firestorm framing for this,
it makes me a little bit like, I don't know, it's, okay, this was a, this was
a confusing behavior, and something that they overlooked, but I am glad
that this conversation did happen.
And ultimately, the React team had this pointed out to them and did respond
ultimately, I think, appropriately.
So, like, it's, I don't know, how do you, How do you do open source development
with millions of people, very few of whom actually try out pre releases?
Mark Erikson: Yeah, that actually even ties into the events this
week of Jordan Harband and some of the package updates going on.
Mo, you had a thought?
Mo Khazali: Well, I was just thinking, well, firstly, ironically, I remember when
we did the last, last month's episode, we were talking about how this might
be like the quickest release cycle for React, or, well, you know, it'll be a
quick transition into Release Candidate and then released, and then this came up.
So I find that quite funny that sometimes these things will
come up and we can't predict it.
But I think it's, you know, around the whole expecting people to test canaries
and, and release candidates, I almost wonder if there's a different way that
that needs to be done and if there's some level of automation that can be done to
ensure that not just, you know, apps that are using RSCs and are, you know, the
most up to date and exactly architected in a way where Meta wants them to be
architected, are tested, but rather, there's a whole wide range of apps,
ones that are built over a long period of time, there might be SPAs or other
things like that, all of those get tested.
I don't know if there's a nicer way to handle that, but I feel like just
expecting people to test Canaries and test RCs will not catch stuff like this
. Mark Erikson: That's the thing, I believe the Vue ecosystem has like a
full fledged, I don't know the right term for it, they have a massive automation
setup that tests all kinds of libraries across the ecosystem against the latest
versions of like Vue and Vuex and Pinia and Vue Router and all these other tools.
And similarly TypeScript, every time you push a PR to TypeScript, it does checks
against almost all of DefinitelyTyped, or at least like a, the most widely used
libraries on, on DefinitelyTyped and across the ecosystem, to try to catch
a lot of these issues ahead of time.
But even then, there's a distinction between, do the library's tests fail,
and how are people using that library.
I think in this case, React Query had one test that did parallel
fetching in a suspense, but it was like two components running locally.
And so the effects of it would not have been meaningfully
visible in terms of timing.
Carl Vitullo: Right.
Right.
And ultimately this is a like timing and parallelism issue.
And I don't know, I'm not sure that that's something that would work.
have been proactively tested?
Like, I'm not sure that it's something that An automated test suite could
like reasonably easily evaluate.
And I'm not sure that someone would have said, Oh, this is a large enough
risk that we need to invest, you know, several days of engineering time in
order to make sure that we have test coverage that will flag this if it breaks.
So I don't know, I, to me, this is just like such a.
Niche interaction between, you know, it's, it's such a corner case between
the assumptions of the React core team and the, you know, evaluation work that
they do against the Facebook project and the, you know, broader needs.
So like, I don't know, I saw various negative takes, like, oh, I don't
know, I saw lots of various negative takes, I'm not even gonna try
and imagine, try and make up one.
Mark Erikson: the React Summit organizers for the last couple years Have done
an event that they call the React ecosystem contributors summit, where
they get like 25 to 30 maintainers and contributors to various tools
and libraries together in a room.
And they just give us a chance to vote on whatever topics we think would
be worth discussing and then give us three hours to, talk about it in
whatever way we think would be useful.
So, I was there.
There were two topics that were discussed.
Two thirds of the room was discussing the technical aspects of the suspense
change, two thirds of the group was discussing the technical behaviors.
One third of us were discussing, how can we have better communication and
interactions with the React team.
A couple of days later, Joe Savona from the React team put up a long
Twitter thread, which is very, very good and very worth reading.
And he said, number one, we're going to hold off on the React 19 release.
We agree that this is a major behavior change.
And frankly, we underestimated how many people would be
affected by this pattern change.
So they're going to step back and they're going to do something to do it.
My, my, my assumption is trying to do the actual work to re implement
some of the older behavior in the, in the reconciler internals.
So that's good.
Like the community complained, we communicated, they
listened, they changed plans.
These are all actually very, very good things, but that ties
into the communications question.
Like a semi official way to communicate to the React team is by filing an
issue, and the React issues are basically useless in that sense.
One thing, they've been full of spam, both in terms of like really, really old
issues and literal, literal spam issues, but also like the React team doesn't pay
tons of attention to their issues list.
And so just filing an issue is not necessarily going to
get like a quick response.
There's Twitter, and a lot of the, you know, React team members are
very active on Twitter, and that's great, but it's also not like a
formal communications channel.
So, what we concluded in our little set of people talking during this Contributors
Summit, is that we really need to bring back this idea of a working group.
For React 18, the React team put together a React 18 working group
where they specifically invited 50 to 75 people from across the ecosystem
and continued adding to it over time.
And there was a public GitHub repo where the React team and the invited
contributors could write comments.
Anybody could read it, so the discussions were public, but the idea was have
a high signal ratio of meaningful discussions and questions about React
18, how things worked, how people could actually use some of the features and
what the practical results would be.
And I think that was a great success.
Like, there was a lot of really good information in that repo.
So our conclusion, as the little group of people talking amongst ourselves,
was we should somehow have a permanent version of the working group.
And actually, Tanner Linsley independently tweeted the same
thing a few days later, as well.
So along with that, Joe Savona also said in his tweet thread that we are
actively looking at how can we get more feedback on pre release versions
and how we can actually Have better communication with the community.
So, I don't know exactly what will happen, but I'm hopeful that something
like this working group model would be an option going forward.
Mo Khazali: That's not, you know, too far away from how the React Native team does
it, you know, for, for the past couple of years, I'd say, since, you know, Nicola
Corti and Riccardo have come into the React Native team, they've been pushing
this sort of release cycle where they'll have two, three different people from the
community owning the release process for each version of React Native that comes
out, and that Inherently add some level of community involvement to the releases.
Obviously a working group with more and more and more people, you know, about 60,
70 people sounds like there's going to be even more exposure, which is great.
But I think it's, it's something that could take a page out of the React
native core teams book as well, because they've done it successfully there.
Mark Erikson: Overall, takeaways are, nobody tries pre release versions, we
really need a formal communications channel between the React team and the
community that they will pay attention to, and that we can collectively
offer feedback that they will see.
Carl Vitullo: Yeah, I, I, I chimed in on that because I don't know, Reactiflux,
we're a thriving subset of the community.
Maybe we could be a neutral space for that type of communication to
happen where they don't need to own the moderation side of things that
has not turned into a conversation.
So, hey, maybe it will eventually, but yeah.
Twitter is definitely, I'm not sure how effective it was ever as like a DevRel,
you know, source of truth, but now, like, if you don't have an account, they don't
even let you view tweets, so, I think it is past time, well past time for DevRel
from the React team to go somewhere else.
Like it is, it's been over a month since the last blog post.
And other than that, I don't know where any communications from the React team
out to the broader community come from.
It's basically the blog and the Twitter and the blog is not active.
So.
Yeah, I hope that that working group concept turns into
something a little more effective.
But yeah, okay, cool.
Next subject, TC39 proposals.
A bunch just came out.
I'm just going to kind of run through this on the high level.
Yeah, promise.
try, it looks like it's pretty much just like a quick wrapper on, , you
know, new promise, and then you immediately resolve with a value.
I've done that a number of times, so I guess there's a use case for this,
but in the abstract I'm not really coming up with a great example of
why you would want to just Take a synchronous value and make it a promise.
Deferred import evaluation seems useful.
it's a way, it's a way of delaying execution of some parts of the import
process when you're getting a module in.
You can, you know, mark it as deferred so that it will not
actually evaluate the module.
It'll still like parse it and do some other interpretation steps
that I'm blanking out at the moment.
But it will not actually evaluate the code until later on.
Mark Erikson: Basically this, this allows.
Speeding up, like the initialization process by not running all the
code in the application right away on startup, even though you know,
you'll need some of that code later.
Carl Vitullo: Yeah.
Okay.
There we go.
Another one was joint iteration.
I thought this was pretty cool because I've needed this a number of times.
It's a way of iterating over more than one.
iterable at the same time.
That's on stage 2.
7, which means it's still pretty far from getting shipped.
Error.
isError seems very useful for, for types.
I guess lots of new stuff is moving down the pipe, I don't know how many of these
are super important to call out in great detail, but yeah, Mark, Mo, anything that
caught your eye is particularly important?
Mo Khazali: I, I really think Error.isError is the one
that I'm most interested in.
Obviously quite a while away before it gets to adoption.
It's still on the process step two, it's stage two, but hopefully very soon.
Well, I don't know how long this process is going to take for them.
It was interesting.
The TC39 meeting that they had was happening in Helsinki, uh, near Future
Frontend, which was a conference that we gave a shout out to last month.
And I happened to be there.
That was quite cool to see some of these folks gather together and how they
chatted about some of these standards.
Just being privy to those conversations was fascinating.
So they have a, they have an incredible process that I've, I've
not seen anything like before in any other sort of working group.
So quite interesting, would recommend.
There's a, if you go onto the Future Frontend streams, they actually have
a big panel discussion for, from the second day of Future Frontend, and
they actually discuss some of these proposals in detail, which is quite cool.
Carl Vitullo: All right, let's move on to the next one.
This is, I'm, CodeMod they announced they are partnering with the React
team to help migrate to React 19.
I know, I feel like the React team initially popularized
the idea of CodeMods.
So this is like not a surprise at all to me.
I guess I wasn't really familiar, wasn't really aware of Codemod
as like its own separate team.
I see, you know, this is posted by the founder of CEO of Codemod, I guess.
So that's kind of news to me.
But yeah, so there's gonna be more Codemods, I guess, to help your
codebase stay up to date with React 19.
Mark Erikson: I am very familiar with code not code mods as a technical
concept I had no idea there was an entire company devoted to building tools for
code mods as like a corporate thing.
Carl Vitullo: Right, right as a technical thing Very familiar.
I don't really understand what the business case for that would be.
I don't know, I guess maybe consulting.
Maybe it's a services business.
Mo Khazali: Apparently the way that they also make it more effective is that
they apparently pair it with some AI.
It might be a pivot, I don't know, but apparently they pair it with
some AI and some nice CLI tools to make your code mods more effective.
That's not an endorsement, I don't know if it works well, but
that's seemingly their model.
Carl Vitullo: Makes me a little skeptical, but yeah, I don't know.
Codemods generally are great.
Any migrations and like major refactorings like that are definitely substantially
helped by having automated tools that do, you know, even if it's like 60 to 80%,
that's still pretty great, but yeah, cool.
So there's an official partnership there.
So I guess there's a business that is writing these codemods and the React
team is in collaboration with them to make sure that they work well.
That's cool.
That's great.
Love that it's not just the core team trying to do everything on their own.
Yeah, Mark, you want to take us on to React Compiler?
Mark Erikson: Sure.
So, React Compiler came out in beta at ReactConf, and so we're starting to get,
you know, various examples of people trying it out hands on in the real world.
There was a very good post from Nadia Makarevich, I believe is the name, who
has written a number of excellent articles about React rendering in the past.
And she tried it out on both some toy applications and some larger,
real world codebases that she had.
And she found that the results were mixed.
She expected the compiler to optimize fairly large percentages of the
components in those codebases.
And it only seemed to optimize like 20 or 30 percent.
Now, , apparently the compiler tool does have a health check command
that will tell you which components it would bail out of because those
are breaking the rules of React.
And I believe that the updated React lint rules can also give you an indication of
which components might not get optimized.
But her takeaway, I believe her takeaway was You know what?
Well, okay, like this, this seems promising, but if real world code
bases aren't going to get, or are we going to have like 20 to 30 percent
of the components improved, that's not quite what we were pitched.
Now, I will note that, uh, Satya from the React, React compiler team, I
believe commented here in Reactiflux that, hey, this article is great.
Like, we got to See these example apps that she posted about, and we've been
doing a bunch of additional changes to make sure we're handling those cases.
So, I mean, just because it didn't work perfectly in her case, doesn't
mean that the compiler's bust.
It just means that it's still a work in progress.
So having that real world feedback is actually very good.
And then Tony Alicea, wrote an Excellent article that actually breaks down what
the compiler does and what the output looks like and how it works in practice.
So, very worth reading if you want to understand what the
compiler actually does for you.
Carl Vitullo: Heck yeah.
Cool.
Yeah, I guess I'll move us on.
I wanted to call out this There's been a lot of, conversation that I've seen
around, like, Laravel, specifically, specifically Laravel, Theo put out
a video that then somebody wrote a blog post replying to of, " why don't
we have a Laravel for JavaScript?"
And this actually crossed my radar from somebody who's not in
the React world at all, they were talking about scoping a project,
adding authentication to some app.
And they said, "this developer estimated two weeks to add authentication to the
product and I thought that was ridiculous.
We have that out of the box in Laravel."
I, I, I chimed in because it's like, you know, I've done auth a couple of
times in my life, in my career and like, yeah, you know, okay, sure.
A login form, that's not hard to do in a day, but when you get like a
settings page and you know, you got to be able to change your email address and
reset your password and do two factor authentication and, you know, social
login, It's like, you know, I mean, two weeks doesn't sound that wrong to me.
And he replied like, All of this is, all of that, everything you just described
comes out of the box in Laravel.
And it's like, alright, you know what, okay, maybe we do
complicate things a little bit.
Maybe not overcomplicate, but I guess, it, it, we do have so much flexibility
and modularity and ability to Write things from scratch in React and, you know,
in the React ecosystem more broadly, maybe that we have, you know, as far
as the pendulum swings, maybe we have stayed in maximum modularity mode for a
little bit longer than might be optimal.
I don't know.
I, I'm curious what you guys think of that.
where's the trade off?
Where's the optimal line between modularity and out
of the box functionality?
I
Mark Erikson: mean, I think a lot of it also is the, you know, the
whole back end, front end split.
I mean, Laravel, you know, PHP, Rails, Ruby, they are back end languages, and
the use case is You know, like, you know, the back end is doing basically
all the work for you, and then, you know, there, there might be some
additional stuff on the front end.
And so I think the frameworks there, they've, they've been around longer,
and also they evolved to have, we, we need to have everything the
back end needs to do all the work.
Whereas, JS has always had the front end, back end split, and it's not that
we couldn't build something that was, you know, absolutely out of the box like that.
I mean, there are, you know, some examples of that in the JS ecosystem,
but I think it's typically been much more of a, like, I just need
a basic HTTP server like Express.
to serve up my client side code and then go from there.
So, I think the modularity is a big aspect, but then also the differences in,
like, the ecosystem historically as well.
Mo Khazali: I do think, you know, I've spent a bit of time working
in the Django world a little bit, and I can definitely see the appeal
to having something like Laravel, where so much comes out of the box.
Done for you.
And that interconnectedness means that it is a lot smoother to do things
like you mentioned, like settings on a profile to modify those things.
They're all like one centralized model in Django.
And it's significantly easier to create those sort of CRUD operations
for users on like a settings page.
It doesn't take you weeks.
It takes you a day.
And I know a lot of people who've been developing a while, like they spent
time in the PHP world or in the Python world with Laravel or Django, and then
they, you know, started doing React in our company and they were all like, this
sucks, really don't like doing this.
It was so easy with Django, but I guess it's the pendulum swings and we
probably land on some sort of midpoint, you know, I wouldn't be surprised if
people start building things on top of Next, which allows it to be a more full
fledged opinionated server that also can render and template React code.
Mark Erikson: That's what Blitz was.
Blitz started off as the whole suite of things to go with Next,
and then they tried to fork Next, and then they gave up on that idea.
Carl Vitullo: Yeah, and I mean, I guess this is, over the last
ten years, React has slowly, I feel like it's grown in scope of,
like, where people want to use it.
Like, when I first started it, There was a lot of, put it in, like, this spot, this
little rectangle on the website, like, that's where React goes, and several years
ago, that moved into, most people are using React to build their entire app,
like it owns the entire client side, and now we're moving Up the chain into React
owns more of the server side as well.
So maybe that's just kind of like the, this projects like Laravel already
owned the data model in the server.
And they had to come from there into owning more of the client side to
provide a better experience there.
And they certainly don't compete with React there in any meaningful way.
Like nobody would, I don't think anyone would seriously suggest that projects
like Laravel are able to provide.
An exact, or a highly comparable, interactive client side experience.
You know, as I'm saying that, nobody would argue that.
I think DHH has seriously argued that.
Mo Khazali: I was gonna say DHH hasn't argued that yet.
Carl Vitullo: So, okay, people do People do argue that, but let me
add the caveat of offline capable.
I don't think anyone would seriously argue they provide an offline capable client
side experience comparable to React.
And so, yeah, I guess, you know, now with, as server components expand in utility
and capabilities, like, yeah, maybe we will start seeing more of a Laravel.
Or Ruby on Rails type of full ownership of the experience,
which would make it more easy.
Because that's really the problem here is React isn't even aware of
the data model in most applications.
So that makes it very hard to do CRUD interactions, if you
don't have the data, if you don't have direct access to the data.
I just thought that was a really interesting framing for this.
Like I have all, I've, I've lived in React for many, many years.
And so then seeing people talk about how quickly you can do common tasks
in a Laravel, it's like, Oh, Shit.
Interesting.
That's, that is a big difference.
Cool.
Let's move on to Vercel Ship, their conference roundup.
Moe, do you want to take us on that?
Mo Khazali: Sure.
just the general and quickly running through this, Vercel is obviously
moving across and, and taking up more of the, more than just
becoming a hosting platform, so.
There's pieces on how you can collaborate and people in different
teams can collaborate and, you know, preview different sort of webpages.
And we've seen some stuff like that and more focus on observability.
So they've added things like metrics and feature flags.
And so there was someone who actually commented on Twitter about how
beautiful their toolbar was as well, which I thought was quite cool.
But no, there's, there's like a lot of direction around like
product collaboration and a push in that, in, in that direction.
So that's quite interesting.
Just on the observability piece, I actually found it quite interesting that
hosting providers are going in that space.
So Cloudflare a few months ago acquired Baseline, which is also an observability
tool, and I think they're trying to integrate it into their workers slash
Cloudflare pages space, which is a competitor to Vercel's, you know,
hosting platform plus their, their serverless functions that they've got.
So, or the edge functions that they've got.
So I think it's interesting that a lot of them are moving.
Past just hosting into that observability space as well.
And I think there's going to be a pretty big competition in that
space in the next couple of years.
Carl Vitullo: Okay.
That makes sense.
Yeah.
I haven't yet played with this at all, but I think I've heard people discussing
the Vercel, metrics and feature flagging and that, yeah, I think that the, tacking
those onto the, to a hosting provider does make a lot of sense to me because I feel
like you get, you start getting a lot more things for free if those are all bundled
together into one thing, like, I don't know, just having used LaunchDarkly and
other feature flagging tools like that.
It feels like if they knew when a release was happening, if those
feature flagging tools knew when a release was happening, I can imagine
various optimizations or improvements to the, like, developer experience,
the experience of putting out a new release that could be enabled by that.
So yeah, that's something I'm paying attention to.
We'll see how that goes.
Mark Erikson: All right, next up, TypeScript 5.
5 is out.
And the, the single biggest thing that is interesting about this release is what
they're calling inferred Type predicates.
So as a little bit of background, one of the nifty things about
TypeScript is you can write code that does runtime checks, and TypeScript
uses that to narrow down TypeScript type of a particular variable is.
And part of that is not just having like an if statement, but actually
having separate functions that, for example, accept any value, and then
they do some runtime checks and you tell TypeScript, if this function returns
true, then the actual TS type of the value must be some more specific type.
And so you can use that to tie together runtime checks and
type and compile time behavior.
But the issue was that things like filter callbacks for arrays, which return a
boolean, didn't do any of that narrowing.
And so you might have, like, an array that could be, like, item
or null, and you could do a check.
In the filter callback and say, if thing is not null, you know, return
true, which ought to tell you that by the time we're done, we only
have actual items and no nulls.
But TypeScript wouldn't automatically narrow down the TS types based
on callback functions like that.
So with TypeScript 5.
5, they've improved the type inference.
So that if you have a function that accepts some value and does some checks
and returns a boolean, TypeScript will automatically try to narrow down the
TS types of the output to be stricter.
And so, this is going to be a nice little quality of life improvement for
a lot of different TypeScript use cases.
One other interesting thing that I saw in there, is that apparently
they're doing some syntax checking on regular expressions.
Mostly just catching things like, you know, like you have
too many parentheses in there.
But that one's actually pretty cool too.
Carl Vitullo: Yeah, definitely super cool.
I, on my list of things that I, that would make me excited, like typescript
checking regexes was not on there, so I, Very unexpected for them to
even start moving in that direction.
But like, heck yeah, please help me make my regexes a little more robust.
Mark Erikson: One other thing towards the bottom that's under the hood.
So they've done some changes on their internal variable definitions.
So that they get more optimized by the JavaScript runtime, basically making
sure that the same fields always exist.
And you don't like occasionally add an extra field to the object dynamically.
And so because of that, the runtimes are able to optimize the behavior.
And they found that it actually improved compile times by like 5 to 10 percent
just by making the fields more consistent.
Carl Vitullo: Yeah, I also want to share, Matt Pocock did a really great,
just like quick 10 minute video breaking down what's new in TypeScript 5.
5.
So definitely worth, he's just such a great TypeScript expert.
Just wanted to call that out.
Great resource.
Cool.
I wanted to shout out a conference talk by Ryan Florence that
came out of Big Sky DevCon.
I saw quite a number of people referring to it as like the
best talk I've seen in years.
I don't know if I would go that far personally.
It's a great, it is a great talk.
It's, it's kind of just, I think I would describe it as like an oral
history of the Problem space that React Server Components is trying to address.
It just sort of talks about like the difference between, you know, the
server and the client and the network being in the middle and plots out a
couple of different tools and where they live in that, You know, taxonomy.
Definitely worth checking out.
I mean, Ryan Florence has been around for so, so long.
So hearing him just do kind of a dump of history of a problem, I
thought was really interesting.
It was definitely worth listening to.
Mo Khazali: I'll jump in with some React Native stuff quickly.
So first, and I'd say most significant news in this space is unfortunately
that Lorenzo Sciandra from the Microsoft team is leaving the React Native world
and also leaving Microsoft, which is, I would say personally, a pretty
big blow to this, to this community.
He's been such an instrumental part of.
Getting more and more community involvement inside of React Native.
He's been doing React Native for more than six years and,
you know, being based in the UK.
I've known him personally for a couple of years now and such a lovely guy.
And I think he's moving on to focus something around making sure that
the tech space is A little bit healthier and a little bit more
humane, as he likes to put it.
And he's been focusing on mental health struggles within the tech ecosystem
and within, within a career of tech.
So you should definitely check out his podcast called Debug Mind.
But really just want to, from the bottom of my heart, say a big thank
you to Lorenzo for everything that he's done over the last six plus years.
An absolute shame that he's leaving us, but I am very excited for everything
that he's going to be doing afterwards.
Carl Vitullo: Yeah, I have repeatedly come across his name when I've
looked for React Native resources.
He's done so many great lists of like, I can't even remember the various types
of lists he's done, but just like major projects in the React Native space and
educational resources on React Native.
Yeah, definitely a big blow to have him exit the ecosystem.
Mo Khazali: And, you know, more than that, you know, I think Lorenzo
has been sort of the person who's been trying to bring the meta team
closer and closer to the community.
So, you know, Lorenzo, for the first time that I went to Meta's offices,
Lorenzo invited me and, Organize that with a lot of the Meta folks to, to
bring me over and, you know, for me to be able to chat and bring some of my
concerns over to some of the folks at Meta and, you know, that became more of
a recurring thing, all thanks to Lorenzo.
So he's been very instrumental and he's one of those sort of open source
maintainer that maintainers that really cares about the community.
So yeah, definitely a big blow.
Carl Vitullo: Yeah, and earlier, Mark was talking about how the React
Native team has been a little bit better than the React core team at
interfacing, doing like working groups and things like that, and including
the community and the development.
I wonder, I wonder what role he played in making that happen.
Mo Khazali: A major one, definitely.
So, yeah, but.
Best of luck to him.
I'm sure he's got some amazing stuff lined up that he's going to be exploring next.
And yeah.
Next up, one thing that I'm personally super excited about is Expo Atlas.
So Expo Atlas is almost like a sort of bundle size visualizer, but taken
to a little bit of a higher level.
And this is something that's been missing from the React
Native ecosystem for a long time.
So just a little bit of context.
Bundle size has never been a concern for the React Native ecosystem, unfortunately.
For, for, for better or for worse, because it's all sort of sent once in
the bundle of an application, when you download it from the app store, people
don't seem to really care that much about how much JavaScript you ship, so
long as it's downloaded once it's done.
And, you know, things like app startup time and actually, you know, having a lot
of JavaScript and runtime don't affect React Native apps as much because of.
Things like Hermes existing, where you have an engine that will have some sort
of like bytecode representation and not have to load the entire JavaScript
bundle into, into its runtime.
So that's been a challenge when you're trying to take React Native
and put it on the web and deal with this whole universal story.
And so, you know, one of the things that I spent a lot of time around React
Summit, speaking to Evan and Cedric from the Expo team about was, you
know, how do we make sure that some of the third party libraries that have.
I've been creating over a long period of time in the React Native ecosystem,
actually have small bundle sizes when you try to take them to the web.
And Expo Atlas is kind of the take that the Expo team has at doing that, which
is, well, a lot of these libraries are all CJS based, so if we just introduce
tree shaking into the bundler for React Native, It's not going to necessarily
solve that problem by itself because most of the libraries won't be tree shakable.
So then what's the way to do it?
Well, let's just visualize the problem, see what libraries are bundling in
a lot of crap, and then see if we can slowly start to, as a community,
shave some of that off and improve the performance for React Native web apps.
This is a slow burn.
It's not going to.
Change over the next year, two years, maybe even three years, because
there's a lot of legacy there.
But I think it's the right step.
It's showing and visualizing the problem.
So great tool that's out there.
We'd definitely check it out.
It shows you in a different way to how like the bundle visualizers that
you might be used to, it actually shows you which import of a library
you have in your code that is actually causing this library that might be
bloating your bundle to be loaded.
So, you know, it might, it goes down the tree for transitive dependencies
as well, which is quite cool.
Mark Erikson: Oh, that's wonderful.
Mo Khazali: Really great tool.
Carl Vitullo: Yeah.
I'm looking at this, the visualization of the blog post with the, you
know, recursive squares showing the, the bundle size and, oh man, I
remember almost a visually, almost identical tool, much less polished.
Clearly this has someone who did a design pass, but there was a very
similar tool that came out for Webpack in like, I don't know, 2014.
Mark Erikson: There's been a number of them, Webpack Bundle Analyzer, Source
Map Explorer, and a couple others.
Carl Vitullo: I, I like practically made a career out of like fixing performance
issues just because I learned that tool and it actually enabled me to do things.
So yeah, cool.
Love to see it.
Love to see it in the React Native context.
Definitely looks valuable.
Mo Khazali: Cool.
So then a few sort of quick things.
Firstly, Expo's now added React compiler support.
We saw this in the React Conf app.
It was already using the React compiler.
So just, you know, if you want to try it out experimentally, you
can use the React compiler and see how it works for your app.
Next up is Starlink's React Native story.
So this was interesting because it came out during AppJS,
which happened last month.
So the Starlink app is, is obviously built with React Native and it
uses a lot of the expo libraries and things like React 3 Fiber.
And it's really cool to see how some of these tools that we all have
available to us are used in practice in some pretty serious production apps.
And then another quick fire one, minor changes to Expo
Router in Expo Router version 3.
5.
So, just some stuff like, you know, supporting the, the
sort of the hash parameters.
There's some stuff around native, native intents with deep linking that
you'll need for having a more seamless handoff between different Devices, and
also for allowing for certain links to, to come with more details to, to
really augment the native functionality.
Another small thing that I think is quite important, that's not
actually one of the top headlines with this, is that previously Expo
router was using an, a non standard version of the request and response.
And with this version, they've, they've standardized it a bit
more, which is great because that should definitely be standardized.
And then a few.
Other minor things that I'm just going to run through.
One is React Native Vision OS won the Git Nation Open Source
Award, which was quite cool.
It's a really cool project.
Definitely give it a shot.
And the folks from Callstack were there at a bunch of these different
conferences with Apple Vision pros, trying to get people to try out
React Native with Vision OS, which was quite a fun thing to try out.
Next up there is sf symbols.
So sf symbols is sort of an icon pack that comes default with iOS.
It oftentimes feels very Apple esque and having that inside of your app means that
the icons are uniform with the OS and they look and feel like it's an iOS application
and Expo's added beta support for it.
This is an interesting one because React Native is obviously cross platform.
The main targets that you'll have is an iOS and an Android app, so specifically
supporting icon sets and an icon set that's available for iOS means that
you may need to have some divergence in your code base if you want to
really use those SF symbols, and you'll need to create or choose equivalent
Android icons, so a little bit of an odd take, but I'll see you A lot of
people seem to really want to use SF Symbols, even with React Native apps.
So I'm sure that there was a level of feature requests and community
involvement in trying to get that working.
So that's definitely there.
And then lastly, React Native Screens.
This is actually a library that you will rarely ever have to use
directly inside of your application code, but it's actually being used
under the hood by React Navigation, which is by far the most common
navigation library within React Native.
And they've just added some extra minor improvements.
One that's quite cool is transparent header support.
Obviously on the native layer, there's functionalities on iOS and Android to
be able to add a transparent heading that's got a little bit of a blur, and
it comes up with some cool effects.
You can do that in React Native with the, with the default navigation libraries.
So React Native Screens has been updated to support that on both iOS and Android
now, which is just cool minor changes.
And that's just about everything that's been happening in the React
Native ecosystem in the last month.
Carl Vitullo: Nice.
Excellent.
Thank you for catching us up.
Okay, shall we move on to our lightning round, see how many
links we can get through there?
Mark Erikson: Yes, because we're already an hour in, so moving right along.
I saw a really, really cool tool called React Internals Explorer.
It looks like you write some React code in a sandbox editor.
And then it actually digs into the React fiber tree and shows
you the structures of that.
I haven't even had time to play with this, but just like glancing
at it and seeing a screenshot.
I'm actually really, really excited about this because I love
digging inside React's internals.
I know most other people don't need to, but this looks really helpful.
And the author has already written a whole series of blog posts where they
actually go straight into the React source code and explain how specific features
of React are implemented under the hood.
So if you want to know how React works inside, very worth reading.
Carl Vitullo: Yeah.
I wanted to call out a blog post from the Chrome team where
they just, they do a recap.
What's new in JavaScript frameworks for May, 2024.
So this is, I guess this is old.
It's undated.
So I guess it must have come out last month, but they are just, they
just quickly round up a bunch of.
they go through like Angular, Astro, React, Remix, Next, Vue, NUC,
Solidsfelt, and a couple of others.
Yeah.
This is Adi Osmani is.
One of the, you know, it looked like they did a video and wrote a blog post with it.
I thought it was curious, or I thought it was interesting to see what the Chrome
team thinks about JavaScript frameworks.
Mark Erikson: There were a few different blog posts that touched
on the theme of memory leaks.
There was one that talked about memory leaks inside of Node, potentially
if you're using the relatively new local async storage feature.
the example there was with setTimeout.
Apparently, Node can be keeping track of async call stacks attached to the
context storage, and so you could actually end up leaking a whole bunch of memory
if you're using it in certain ways.
Uh, similarly, there are also a couple of very good blog posts talking about
potential ways you might end up with memory leaks in a React application.
In cases where you're using like use callback or use memo or with React query
where you're writing functions that are doing data fetching or something
like that, and they're closing over variables that are in scope and
they might not even be getting used.
But the closure keeps those variables alive longer than you would have expected.
Mo Khazali: Cool.
So next up is an article that's actually on Martin Fowler's blog.
So Martin Fowler being the big thought leader and evangelist of, of all
things, application development, period.
Mark Erikson: Enterprise architecture patterns.
Mo Khazali: You see, divisive at the best of times, Martin Fowler is, but
there's, there's been more and more React articles popping on, and they're
not actually written by Martin Fowler, but they're written by someone who works
at, whose name is Juntao, or actually, I don't think he works at ThoughtWorks,
but he's very close with Martin Fowler, so he writes on Martin Fowler's blogs.
And he's been doing some really cool work on writing articles that start from
the basic principles and expand out and create more and more complex applications
that explain a bunch of concepts.
So his latest article is about data fetching patterns in single page
applications, and it starts with basic React concepts, builds up around, you
know, asynchronous states being handled on the client side, parallel data fetching,
how do you handle fallbacks, and then things like pre fetching, and then kind
of It takes you through this journey and tells you when you should use which one.
Would recommend it.
It's a very, very long read, probably one of the largest blog articles I've
seen in a very long while, but it's definitely worthwhile if you want
to get a more holistic viewpoint.
And he's written a lot of articles like this.
Another great one that he's written just to give a shout out is called
modularizing React applications with established UI patterns.
And this is one that Mark is not going to be very happy about, but this one
is one of those, which is like, how do you enterprise ify React code,
but it's actually a very interesting article that has some thoughts about
how you should architect React apps.
And some of those patterns, not all of them, are actually very good to
make it easier for you to do things like testing and so on and so forth.
Carl Vitullo: Cheers.
Yeah.
Oh man, I remember reading Martin Fowler's blog like 15 years ago
when I was like starting my career.
So just for it to still be relevant is like a little bit mind boggling to me.
Mo Khazali: The website still looks like it's from 15 years ago as well.
Carl Vitullo: Yeah.
It's unchanged from when I started reading it.
Yeah.
Not a single change that I can identify.
Cool.
Yeah.
I wanted to bring up a blog from Snyk, a security.
Firm, I don't know, security product service, 10 modern Node.
js runtime features to start using in 2024.
It's, I have always found it really tricky to stay on top of every
level of development over time.
So I appreciate a little roundup post like this that just sort of calls
out a number of new features that I may not have caught the release of.
It's sometimes it's hard to see, see the each individual release.
So the 10 that they call out are a test runner.
Native mocking, native test coverage, watch mode, core pack,
the env loader, some import meta fields for the __dirname and __file
fields, native timers and promises, permissions module and a policy module.
Those last two are not super clear to me, but like the test runner and
native mocking and test coverage.
Super great to not have to pull in a third party tool for that.
As well as, yeah, I mean, watch mode.
The number of times I've installed NodeMon.
If I can stop relying on a third party package for that, I'll be pretty happy.
I haven't checked that out yet, though.
CorePack is actually, I feel like the name of it makes you compare
it to Webpack, or it makes me compare it to Webpack, at least.
But actually, it's, the main use for it is being able to specify a package manager
at a specific version, which is so useful.
Um, I appreciate that they have made it, I guess it's a, I guess it's a
combination of being able to pin a specific version of your package manager,
but it's also, I think, some underlying tools to make cross compatibility
possible between package managers.
Mark Erikson: The primary issue is that NPM has always
come pre installed with Node.
But if you want to use Yarn or PNPM, or, Bun, I guess, you have to first use
NPM to install those tools globally.
And that's kind of a one off per system thing.
And then you have to remind everybody that they're supposed to be using
this package manager, the project.
And so I think the idea of CorePack is that if you specify in your package JSON,
that, Hey, we're actually using Yarn 4.
1 or PMPM 9.
2.
It will automatically do the work to make sure that the right package manager is
available and being used in that project.
Carl Vitullo: Right.
It fills the gap where, like, PackageLock or Yarn.
Lock will let you pin your dependencies, left the, you know, the gap of what
about the version, you know, for the package manager because the different
versions interpret that lock file slightly differently sometimes.
Or, you know, I've had a more recent version of Yarn blow away my Yarn or,
you know, start adding things like a, a digest half to the, to the lock file.
So being able to pin a version, super great.
Yeah.
As well as like having a env loader, so we don't need to use env anymore.
But yeah, so I appreciated this as a quick summary of a number
of new built ins for Node.
Mark Erikson: There was a very good post on migrating to the next
app router with zero downtime.
One of the pain points with server components is that you have to have the
entire application set up with server components as the outer layer of the
application in order to use them at all.
There's no straightforward, simple, like migrate, just a
little piece of my component tree.
And while you can use the app router with everything still on the client,
as a client component, it's still a key step in order to even be able to think
about using server components with Next.
And so, this article was a good example of how a team with an existing Next app
that used the Pages router was able to mimic the routing setup in the app router
and carefully, step by step, make sure that things worked the same both ways.
Switch over and then be able to start using some server components
piece within the existing structure.
Carl Vitullo: All right, Deno announces that the standard library is nearing 1.
0.
That sounds great to me.
The standard library is now a collection of 38 packages, they say.
I appreciated this.
Rather than doing it all in one big bang 1.
0 release for the standard library, they're actually going to repeat a
process for bringing each of those 38 packages up to stable relief.
So they're gonna do it through like a release candidate and then gather feedback
with like a a one month timeline for each of those packages to gather feedback.
So yeah, that's A lot of effort, a lot of energy being invested into creating
a standard library and oh man, here's a standard library for a JS runtime.
Mark Erikson: I'm confused.
Are we allowed to have that?
Carl Vitullo: Right?
It's, it, the classic criticism of JavaScript is the
lack of a standard runtime.
So, oh my goodness, we have a standard runtime hitting stable.
I feel like that's going to affect the ecosystem in some way, but we'll
have to see what happens there.
Cool.
I'm going to call this one out.
This was, I put, I put up one of my tweets.
I don't know.
I think it's a good question.
I'm going to do it.
I proposed the question out, why did we stop making checks like the ACID3 test?
Why isn't there an ACID3 test for, for example, progressive web apps?
I remember the ACID test series of, projects was
Mark Erikson: Browser rendering behaviors.
Carl Vitullo: Browser rendering behaviors.
It was, is the browser you're viewing the web page in standards compliant?
Here is something.
It should look like this.
And I remember checking that in, you know, 2008 or whatever,
when I was a wee baby nerd.
And, my browser didn't render it correctly, and then a
couple years later it did.
I was considering, like, what factors may have moved us away from things like
that, and I feel like it used to be so hard to ship new things, new standards.
That it took big coordinated pushes like that, or maybe the ecosystem was
also just smaller and the number of players involved were, you know, it could
fit in a room, but I feel like we've lost something a little bit in there.
Like the acid three test was CSS three was ratified as a standard.
They put out an associated test for this rendering behavior so that.
Users could check if their browser was working in compliance with the standards.
And I guess I, I put up the comparison to progressive web apps because like, They
are not fully rolled out, like Chrome put out, the Chrome team put out a lot
of support for progressive web apps, very much as a attempt, I think, to make web
pages viable as competitors to native apps, and it just kind of never really
happened, I think in large part because we never got cross compatibility With
all the browsers for those capabilities.
And I don't even know that we, as an ecosystem, as web developers, have
a shared understanding of what makes a progressive web app, you know,
what defines a progressive web app?
How do you distinguish that what you've made meets all the criteria?
So, I don't know.
I just, it was lamenting our lack of those sort of litmus tests for, I guess,
bringing a Technical definition to some of the terms that we throw around frequently.
Mark Erikson: It's, it's not quite what you're asking for here, but I can point
to a couple ways that there's been more efforts to do interoperability efforts.
One is I think the latest version of the speedometer benchmark for JS
engines was specifically built to include a bunch of different things.
Reasonable, plausible example applications using various JavaScript frameworks.
Like I know that there's like a React, Redux, Todo application as
part of the benchmark sequence.
So that's been an attempt to semi standardize things and make
things a little more plausible.
Also, I believe the last three or four years, all the major browser Vendors have
done, I don't remember the exact term but like an interoperability effort where they
identify like the top five or six pain points of places we know where browser
behavior is differing and we're all going to make a push this year to make sure we
all work the same way for these things.
So it's, it's not quite the same as having like the ACID3 test or, you
know, a named version of CSS that we're all trying to implement, but it
is, it is kind of along those lines.
Carl Vitullo: Right.
Yeah.
I don't know.
I guess I, I, I think the branding that used to be baked in to
those sort of releases served, I think to me, it served a valuable
function in developer education.
And I think that we've lost something through not having it.
Like there was a web platform tests dashboard that like, yes, here is a single
place that compares all of the features, accessibility, all of the compatibility
across browsers, but it's not actually, you know, as a developer, it doesn't tell
me what features are grouped together?
What features go well together?
What capabilities are unlocked by supporting this thing?
We're going well beyond the scope of a lightning round link right now.
Mark Erikson: all right, and last one we got on the list.
HTMX is a library for basically adding attributes to HTML tags that do things
like data fetching and automatically inserting the results into the page
without having to explicitly write JavaScript yourself, and they put
up a blog post entitled Simplicity in an Age of Complicated Solutions,
where they have some examples of handling inputs and data fetching
with VanillaJS or with React code.
And they point out and say, look at how complicated this is.
Whereas if we just slap HTML into the page and we add a couple
attributes, look at how simple this is.
And there's, there's some valid trains of thought to this.
Certainly you're writing less code as an application developer.
I questioned a little bit some of their arguments on general principle,
but it is worth reading for an alternate viewpoint on how application
behavior should be implemented.
Carl Vitullo: Yeah, definitely interesting from a perspective of just
considering expansion of complexity too.
I thought that was, I thought it was cool to read from that lens too.
Cool.
All right.
That is all of the, all the links we have.
Thanks everyone for joining us.
We'll be back on the last Wednesday of the month in here in the live
stage of Reactiflux or in your podcast feed as soon as we can after that.
Mark Erikson: Thank you for listening.
Plug, please check out Replay.
io for debugging your tests and trying to fix flakes.
And also, I'm almost done with a very large revamp of the primary
Redux tutorial to make it TypeScript first and explain more things.
Carl just pasted a link to the draft PR in there.
I would appreciate feedback.
I'm hoping to have this done within the next couple weeks.
Like, I'm almost done with the first draft, and then hopefully there's
not too much more work to do.
So, feedback, please?
Carl Vitullo: For sure.
Awesome.
Yeah.
Mo, anything you want to add?
Mo Khazali: Nothing.
Just thank you again for having me and always a lovely time chatting
with you all and going over everything that's been happening.
And yeah, looking forward to the next one.
Carl Vitullo: Most definitely.
Yeah.
Always good talking to you guys.
Cool.
we, we gather links from, um, a bunch of different sources,
including thisweekinreact, bytes.
dev, reactstatus, nextjsweekly, the reactjs subreddit.
Bye.
Here in Reactiflux from the Tech Reads and News channel, um, and directly
from people publishing articles, usually on like Twitter or Blue Sky.
If you see anything that you think that we should be paying
attention to, definitely feel free to email us at hello at reactiflux.
com with T M I R in the subject line.
That's acronym for the show.
I read every email that comes in, even the ones marked as spam.
If this is the show you get value from and want to support, the best
way to do so is to send it to someone.
Send it to your co workers, help them learn how you know so much about React.
Otherwise, you know, submit a review, do stuff like that.
But yeah, thank you so much for joining us.
Appreciate it.
See you next month.