acemarke.dev
Redux maintainer, building time-travel devtools at Replay.io. I blog about React, Redux, and TS at https://blog.isquaredsoftware.com . Answering questions anywhere there's a textbox on the internet, and otherwise out on the golf course!
789 posts
7,075 followers
409 following
Regular Contributor
Active Commenter
comment in response to
post
fwiw I feel a lot of concerns on exactly the same topics as well :( had some ups and downs the last few months dealing with them. handling all that better now, but doesn't change that the problems and concerns still exist.
comment in response to
post
hah, decided I had time now and got that done :)
comment in response to
post
Yup :) In transit atm, but I'll push this and some other tweaks to the post once I'm settled down.
comment in response to
post
heh, I guess your visibility is more apparent than the actual numbers would suggest :)
comment in response to
post
For a year+ we’ve been following a staging system inspired by TC39 for React development. It’s a great model. We don’t publish precise details on early stages, but focus on communicating what’s in dev (labs posts), canary, and stable.
comment in response to
post
I'm curious, how so?
comment in response to
post
@tannerlinsley.com @acemarke.dev and @tkdodo.eu when concurrent stores are mentioned
comment in response to
post
Yeah, Tanner said in his talk that "85% of React apps are still client-side".
I'd say framework usage is very _common_, but certainly lots of React codebases don't use them.
So I wouldn't say you're "behind the times". That _is_ part of the point of my own talk :) dichotomy in docs vs usage.
comment in response to
post
I actually wrote a post like that a few years ago! :) it's more about visible public behavior than internals per se, but it does touch on those some too:
blog.isquaredsoftware.com/2020/05/blog...
comment in response to
post
@acemarke.dev wants a react version of TC39 and I'm all for it
comment in response to
post
I've also put up an extensive blog post that goes into more detail on the same topics, including the history and influences of React's development, and discussions of the pain points and concerns I see in the community:
blog.isquaredsoftware.com/2025/06/reac...
comment in response to
post
Yeah, almost to Central Station
comment in response to
post
YES! Where?
comment in response to
post
Hey! I'm at the hotel and about to go out exploring the area. Meet you somewhere?
comment in response to
post
About to nap for a couple hours, but ping me if there's plans!
comment in response to
post
Arriving now. Will probably need a nap this afternoon, but generally up for hanging out after I get checked in!
comment in response to
post
Should be! In the air now, landing 9:30 AM local Wed
comment in response to
post
I'd love to see a return to Windows 7 themes everywhere. Or even Windows XP! XP-era common controls were peak visual usability.
I WANT MY BUTTONS TO LOOK 3D, DISTINCT, AND _CLICKABLE_ DOGGONIT!
comment in response to
post
(also, got a link to that issue? curious what it was)
comment in response to
post
Hyrum's Law strikes again! :)
comment in response to
post
If you're still on the fence, I wrote about my experience attending @heypresents.com in May, and it was truly lovely.
I got to spend a whole day talking about tech and ideas and life with some very special people.
Afraid you won't learn anything? The experience is enough.
comment in response to
post
Oh hey, would love to meet both of you!
comment in response to
post
Dan's posts are awesome, and probably the thing that's making some progress moving the needle on folks grokking RSCs.
but I bet the React docs have way more views.
Getting some of those points in the docs, the way you want them explained, ought to scale better than individual replies.
comment in response to
post
yeah, I can try to come up with a partial list.
Per our prior discussions, I do think the best step here would be to add a few explainer pages introing RSCs, explaining use cases, summarizing tech architecture (including the "doesn't need a server / works with SPAs" bit), and _then_ tack on an FAQ
comment in response to
post
I genuinely don't think the existing page is useful in its current form.
Agreed on people not reading docs enough, but half the point is to have a canonical source to link to in responses.
comment in response to
post
look, you shouldn't be exclusionary.
is there a good way to make _both_ groups unhappy at once? :)
comment in response to
post
Yo!
comment in response to
post
I've seen Ricky mention "original demo was Webpack + SPA" a few times. acknowledged.
but generally my own mindset is "if the info isn't live in docs or a blog post it's buried enough to not meaningfully exist". especially given we're a few years on from that demo.
comment in response to
post
Dan's posts are wonderful, and I think the core docs should have some form of that info to explain mental model.
but having concrete info on options outside of Next (if any), ways to use with an "SPA" / Webpack / Vite / RRv7, etc, would answer a lot of questions and concern about adoption.
comment in response to
post
more specifically:
AFAIK the only real option atm is "use Next App Router". which implies migration if not using Next (and part of the reason why there's the "doesn't work with SPAs" assumption, yadayada).
would love to see React core docs on how to adopt, how to migrate, tool options, etc.
comment in response to
post
and now you understand my problem 🤣
comment in response to
post
technically I _did_ do the long extended version for the blog already, I just never published it... :)
comment in response to
post
my own thought from the sideline is that the lack of concrete "how do I adopt / migrate this" info and capability is a bigger blocker for the ecosystem than "what problems does this solve".
comment in response to
post
looking forward to it! :)
comment in response to
post
Not sure why React hasn't yet shipped an actual ESM artifact themselves. Obviously way overdue and years of it being asked for. Just not a priority to sort out impl and ripple effects I guess. (having fought that battle myself, I sympathize)
comment in response to
post
Because the expectation for many years has been that it will be bundled and optimized at build time.
They did ship a UMD build precompiled up until 19. The 19 release notes now point to ESM.sh for an in browser build, I think.
comment in response to
post
Slides of my talk @webengineshackfest.org - Bridging CommonJS and ESM in Node.js, or implementor's tales of require(esm)
github.com/joyeecheung/...
comment in response to
post
I mean I'm still on Old Reddit and will be until they kill it (which would also kill Reddit for me entirely).
but also I honestly forgot Dan's even still a mod there :)
comment in response to
post
approved :)