Twitter | Search | |
Sebastian Markbåge
React JS · TC39 · The Facebook · Tweets are personal
8,787
Tweets
434
Following
31,055
Followers
Tweets
Sebastian Markbåge retweeted
ZEIT Sep 19
Next.js 7: ⬩ Smaller footprint ⬩ 57% faster bootup, 42% faster re-compilation ⬩ Better error reporting ⬩ Webpack 4 and Babel 7 ⬩ New
Reply Retweet Like
Sebastian Markbåge Sep 18
Replying to @cramforce
At least people know about that one. Cookies and localStorage are the worst ones hitting us since the browser may choose to do sync I/O for them. What does AMP in a worker do for those?
Reply Retweet Like
Sebastian Markbåge Sep 18
Replying to @diegohaz @jamiebuilds
Only “hidden” by convention. It is important that its children get display: none behavior for visual displays.
Reply Retweet Like
Sebastian Markbåge Sep 18
Replying to @jamiebuilds
The “hidden” attribute on an element will already cause React to deprioritize that tree to effectively be this. The next step would be to do optimistic state transitions for something that is already on screen. That is also doable. We just have to figure out the right api.
Reply Retweet Like
Sebastian Markbåge Sep 18
Replying to @jamiebuilds
Resources also includes DOM. So the idea is that we will actually create DOM nodes for this pass and given the new display locking API those can begin performing layout, decoding images, warming up glyph/texture caches etc. asynchronously. The key is that we don’t display it.
Reply Retweet Like
Sebastian Markbåge retweeted
Brian Vaughn Sep 15
Tentatively planning on doing another YouTube live stream tomorrow afternoon with a "real world" profiler walk though session. Going to build a flame chart component and then use profiler to make it faster.
Reply Retweet Like
Sebastian Markbåge Sep 13
It’s hard question to answer because either solution can be outweighed by the surrounding system. You shouldn’t benchmark in isolation but compare entire systems after they’re done.
Reply Retweet Like
Sebastian Markbåge Sep 13
Replying to @Rich_Harris
While helpful, since it takes years to gets these things through it seems better to shoot for the more powerful primitive. The core feature in display locking isn’t batching, it is that you can compute layout of one tree on a different thread while still updating other trees.
Reply Retweet Like
Sebastian Markbåge Sep 13
I wonder how that came to be though. Maybe it was intentional branding differentiator and now that’s not there, that’s no longer an issue?
Reply Retweet Like
Sebastian Markbåge Sep 13
Replying to @Rich_Harris
(FB doesn’t just make one UI framework for any of the platforms. It has been hugely valuable to see the work of the others actually. Although only one is open source for web atm.)
Reply Retweet Like
Sebastian Markbåge Sep 12
Replying to @Rich_Harris
They probably have too many people to work on both product than can efficiently work together on a single product. Unifying around a single product doesn’t allow internal competition or exploring multiple paths. What kind of consolidation opportunities are you foreseeing?
Reply Retweet Like
Sebastian Markbåge Sep 12
If you’ve seen the new React Profiler UI in the DevTools, don’t miss out playing around with the APIs for production profiling of components and interactions. I think there’s a market for better tooling in this space too.
Reply Retweet Like
Sebastian Markbåge Sep 12
Replying to @cpojer
In the near term I’m excited for: Concurrency is just getting started.
Reply Retweet Like
Sebastian Markbåge Sep 10
Replying to @Rich_Harris
I spent an extraordinary amount of time learning to use it in the '00s. You just have to learn know how to use it right. Don't try to find an easier tool.
Reply Retweet Like
Sebastian Markbåge retweeted
Sebastian Markbåge Sep 10
Replying to @brian_d_vaughn @swyx
React is intentionally running slower in DEV to add warning messages. Calculating those messages are pattern dependent. So the slowest render function in DEV may not be the slowest in production. DEV perf characteristics has very little in common with the prod build.
Reply Retweet Like
Sebastian Markbåge Sep 10
Replying to @brian_d_vaughn
You should probably mention that what will happen in a future release is that the scheduling API will randomly stop working because it is pinned and stops sharing global state. React updates will cause React to install a separate copy.
Reply Retweet Like
Sebastian Markbåge Sep 10
Replying to @brian_d_vaughn @swyx
Meaning that even if you’re not get profiling data form actual user machines, you should still profile again prod/profiling builds even if you do it locally on your own machine.
Reply Retweet Like
Sebastian Markbåge Sep 10
Replying to @brian_d_vaughn @swyx
React is intentionally running slower in DEV to add warning messages. Calculating those messages are pattern dependent. So the slowest render function in DEV may not be the slowest in production. DEV perf characteristics has very little in common with the prod build.
Reply Retweet Like
Sebastian Markbåge Sep 9
Replying to @rauchg @sayrer
See Cykelslangen in Copenhagen too.
Reply Retweet Like
Sebastian Markbåge Sep 5
Replying to @sebmck
We’re still missing modules if you need a vacation. 😀
Reply Retweet Like