Twitter | Search | |
Sebastian Markbåge
React JS · TC39 · The Facebook · Tweets are personal
8,553
Tweets
419
Following
29,281
Followers
Tweets
Sebastian Markbåge Jul 13
We sometimes use “umbrella” issues for releases. We should create one. It’s a bit harder because we don’t have a fixed end state. cc
Reply Retweet Like
Sebastian Markbåge Jul 11
Replying to @jfbastien
Intentionally left vague.
Reply Retweet Like
Sebastian Markbåge Jul 11
Hot take: Magic is underestimated.
Reply Retweet Like
Sebastian Markbåge Jul 11
Replying to @sompylasar
The unconstrained form will always include some messy pieces, because it's a hard problem. My experience is that if you take an unsolved problem and make it constrained, you or others will find a way to create hacky workarounds your constraints. Those hack end up being worse.
Reply Retweet Like
Sebastian Markbåge Jul 10
Replying to @betaorbust
Once a better solution has been found, the APIs can be constrained more by removing the need for them.
Reply Retweet Like
Sebastian Markbåge Jul 10
Replying to @betaorbust
React lifecycles is an example of a fairly unconstrained API. They exist so that you can solve problems that don’t have built in solutions. Often such solutions turns out to be a mess because the easy solution hasn’t been found yet.
Reply Retweet Like
Sebastian Markbåge Jul 10
"Solved problems need constrained APIs. Unsolved problems need unconstrained APIs." Paraphrasing . This really resonates with how I think about framework design. With time you learn a bit more about the right way of doing things, but constraining too early is fatal.
Reply Retweet Like
Sebastian Markbåge retweeted
Parashuram Jul 10
Wanna hear about React Native's new architecture ? Come talk to at . He is one of the devs working on making React Native faster !!
Reply Retweet Like
Sebastian Markbåge Jul 9
Replying to @rahul1sethi @reactjs
renderToString could work but is less efficient for other reasons and something we'd like to discourage so haven't put much effort into making it work. Would require a significantly different architecture to handle the state transitions.
Reply Retweet Like
Sebastian Markbåge Jul 9
Replying to @rahul1sethi @reactjs
The newer async mode renderer will have it but it can't work with pure HTML streaming only, since by the time the error happens, we'll have already sent part of the HTML. Needs to emit script tags that can update existing content which is part of the new async approach.
Reply Retweet Like
Sebastian Markbåge Jul 8
Replying to @jordwalke
The most effective tool I have for optimizing my workflow is making it harder to open Twitter. Starting... now.
Reply Retweet Like
Sebastian Markbåge Jul 8
Replying to @pcwalton
In fact our native frameworks favors doing everything from scratch instead of diffing. Which speaks to your point about diffing being bad but perhaps not in the direction you had imagined.
Reply Retweet Like
Sebastian Markbåge Jul 8
Replying to @pcwalton
Diffing has a nice property of requiring very little bookkeeping initially and very little code to handle all state transitions. Code size and initial render matters so much more that we barely even look at update performance.
Reply Retweet Like
Sebastian Markbåge Jul 6
Replying to @sayrer
Embedded standard libraries is a risk factor for cross-platform adoption. Easy to add bloat to it on “own platform” with zero bloat. That makes it unsuitable for Android or Web. Will need a forked ecosystem focused on minimalism. Java and .NET failed at that game.
Reply Retweet Like
Sebastian Markbåge retweeted
Benedikt Meurer Jul 5
🔥 is speeding up object spread (the new {...o} syntax) in . Performance already seems to significantly faster than the transpiled version and Object.assign. 🔗
Reply Retweet Like
Sebastian Markbåge Jul 5
I’ve never felt so ready to have children as when I worry about accidentally hurting himself last night.
Reply Retweet Like
Sebastian Markbåge Jul 5
Replying to @brian_d_vaughn
Starbucks?! You’ve lost your credibility to make fun of my coffee preferences.
Reply Retweet Like
Sebastian Markbåge Jul 4
Replying to @sebmck
Is this example explicitly avoiding visible side-effects? I think you pretty quickly start requiring side-effects for reduce and then the difference is more pronounced. I prefer the side-effectful loops, but optimizing them is waaay harder. I have some ideas for Prepack though.
Reply Retweet Like
Sebastian Markbåge Jul 4
I like to talk about first principles a lot. If you face some problems, try to drill down to what the primitive problems are. Always be ready to explain that. It lets you switch to other simpler sufficient solutions or dismiss alternatives that aren't.
Reply Retweet Like
Sebastian Markbåge Jul 4
AFAIK the released version should do this by default. Note that typically forceUpdate usually is used with mutation which has its own set of problems with async. Scheduling a setState is better.
Reply Retweet Like