Twitter | Search | |
Sebastian Markbåge
React JS · TC39 · The Facebook · Tweets are personal
8,378
Tweets
414
Following
27,513
Followers
Tweets
Sebastian Markbåge Apr 22
Replying to @Daniel15 @MarkFunk
If the selector is just identity function you can't do much better than the structured clone algorithm already does. Since it can't be shared, it must be cloned. Maybe we need some kind of "selector" structured clone that can take a filter.
Reply Retweet Like
Sebastian Markbåge Apr 22
Replying to @Daniel15 @MarkFunk
See I think shared data is a distraction here because it's actually the opposite of what you want. You want the components to get a copy of the data in the store. So at the lowest level, you want to copy it into something that is transferred. Not shared.
Reply Retweet Like
Sebastian Markbåge Apr 22
Replying to @RReverser
Service workers can incur a significant overhead for unrelated things just by having them.
Reply Retweet Like
Sebastian Markbåge Apr 22
Replying to @RReverser
Shared Worker is sufficient for most of that right? Maybe not for image caches and such.
Reply Retweet Like
Sebastian Markbåge Apr 22
Replying to @jurmarcusallen
Yea. That sounds about right. "Cloud State" / "Device State" / "Component State"
Reply Retweet Like
Sebastian Markbåge Apr 22
Replying to @MarkFunk @Daniel15
I think that's a temporary or accidental issue. Since selectors *should* vendor immutable data there is some inherent marshaling going on already.
Reply Retweet Like
Sebastian Markbåge Apr 22
Replying to @sebmarkbage
This only works if you assume a good balance between component local state and Flux. If you put all your UI state in Flux, this breaks down.
Reply Retweet Like
Sebastian Markbåge Apr 22
Sunday thoughts: Flux stores should live in web workers.
Reply Retweet Like
Sebastian Markbåge Apr 22
Replying to @rtfeldman
I wasn't so much arguing for why JS succeeded but for why other attempts failed to dethrone it. JS wasn't really used for apps until the late 00s. It was plumbing. Before that there was Flash and Java. They were heavy weight for whole apps and too heavy for extending HTML a bit.
Reply Retweet Like
Sebastian Markbåge Apr 22
Replying to @skoomacowboy
Stack Overflow.
Reply Retweet Like
Sebastian Markbåge Apr 21
What are you passionate about?
Reply Retweet Like
Sebastian Markbåge Apr 21
Replying to @wycats
I think it has not seen as important. High-end games has gotten a free pass where as small peripheral games that need this are seen as low-end even though it’s big business.
Reply Retweet Like
Sebastian Markbåge Apr 21
Replying to @wycats
Exactly. I think it goes beyond that. There is an elitist associated with those communities that consider the JS approach is purely subpar. Web assembly will hopefully surface the bitter truth of this tradeoff.
Reply Retweet Like
Sebastian Markbåge Apr 21
Replying to @jordwalke
The mentioned experiment was byte code (which does expand) compared to native linkable. But Java byte code vs JS byte code is even more prominent.
Reply Retweet Like
Sebastian Markbåge Apr 21
Replying to @wycats
JS code tends to be smaller because of the encoding (and the ecosystem). So it’s faster to load from disk (or network). It doesn’t mean it’s ideal and other languages can beat it in theory but they haven’t done the work yet. The point isn’t that JS is inherently better.
Reply Retweet Like
Sebastian Markbåge Apr 21
Replying to @sebmarkbage
On the other hand Node went the opposite way and relied on the file system to load code - synchronously against its own principles. Making it one of the slowest ecosystems to boot.
Reply Retweet Like
Sebastian Markbåge Apr 21
Replying to @sebmarkbage
I think this is the primary reason JS succeeded on the client. Java, C#, Haskel and the alternatives were too occupied with large standard libraries and runtime performance in loops. The accepted wisdom was making the wrong trade offs.
Reply Retweet Like
Sebastian Markbåge Apr 21
We’re seeing numbers on mobile that suggest that JavaScript can be faster than native end to end due to I/O costs for loading the code from disk. On web this matter even more because the network cost. JS haters need to embrace I/O over CPU perf if they want to win.
Reply Retweet Like
Sebastian Markbåge Apr 21
Replying to @aweary @reactjs
It’s fine if you know what you’re doing but if you encourage this pattern to be prevalent, it can basically destroy the React component model.
Reply Retweet Like
Sebastian Markbåge Apr 21
Replying to @aweary @reactjs
It’s a dangerous pattern though. One issue is that you can’t safely refactor other components around this since switching trees can break it. Also it only works with terminals like text. If it renders children you risk having nested thing around yourself.
Reply Retweet Like