Twitter | Search | |
Sebastian Markbåge
React JS · TC39 · The Facebook · Tweets are personal
9,010
Tweets
442
Following
35,272
Followers
Tweets
Sebastian Markbåge Dec 14
I think it might be even less than that. We probably shouldn’t just guess.
Reply Retweet Like
Sebastian Markbåge Dec 14
Replying to @sebmarkbage
I don’t think we’ll see the true distinguishing factors until we move further away from CSS’s global property list model. It’s a hard move to make though. Too much value in shared existing knowledge.
Reply Retweet Like
Sebastian Markbåge Dec 14
Many CSS-in-JS solutions are ambiguous about how much they want to move the needle. You get rid of one part of CSS which makes it less powerful to a wide group of authors. You also keep most of CSS to retain the power of that shared existing knowledge.
Reply Retweet Like
Sebastian Markbåge Dec 13
No. I don't think "changed bits" is enough which is why this discussion is asking for more, but it's stuck on the idea that Context should have solutions to all problems built in instead of being one piece of several.
Reply Retweet Like
Sebastian Markbåge Dec 13
There is a danger when we think of primitives as replacement for high level concepts/frameworks since that might cause us to couple too much logic with the primitive and now it's not general enough. Context can't even be used to implement stores across multiple roots yet at all.
Reply Retweet Like
Sebastian Markbåge Dec 13
This is a low level API primitive discussion that has been derailed about what the high level API should be. Not everything should be built in.
Reply Retweet Like
Sebastian Markbåge retweeted
Sam Goldman Dec 13
Flow speaks LSP used by VS Code natively, but we will need to invest more in this integration. Please let me know what sucks and I’ll make sure we look into it. Help wanted!
Reply Retweet Like
Sebastian Markbåge Dec 12
There always *is* a fully qualified name but most of the time it is not used because the context will tell them which one it is. It is only in cross-functional contexts that fully qualified names tend to be used.
Reply Retweet Like
Sebastian Markbåge Dec 12
They do use contextual names for this. Nobody uses the full qualifier. Same with surgeons. In fact in every field I’ve worked as a consultant it’s usually hard to get people to say the full qualifier which is important for software engineers trying to model the process globally.
Reply Retweet Like
Sebastian Markbåge Dec 10
Replying to @mehieltwit
Hooks makes it hard to decide whether something should be a custom hook or a new component. Often it should be a new component.
Reply Retweet Like
Sebastian Markbåge Dec 10
Replying to @sebmarkbage
I think that because many components and modules are 1:1 it seems like you’d need a new file for a component but you don’t. Just create one inline. Just like a function.
Reply Retweet Like
Sebastian Markbåge Dec 10
“How do I do this with one less component?” is the most annoying question to me. The answer in React is almost always to create another component and we try hard to make it modular so that this is always possible. This seems tricky to internalize though.
Reply Retweet Like
Sebastian Markbåge Dec 10
I have this sneaking sense that front end will not only have more choice but that the choices will differ more than they have in the past. The different goals we want to achieve are leading us to more opinionated solutions which leads to differentiation.
Reply Retweet Like
Sebastian Markbåge Dec 9
It’s surprisingly complicated but has done some more recent research into this space.
Reply Retweet Like
Sebastian Markbåge Dec 9
Replying to @addyosmani
I gravitate towards some kind of SRI/hash based solution that doesn’t require browser blessing. It’s important that libraries/versions can organically replace each other in the cache. It also works better for the longer tail of modular supporting libraries rather than monoliths.
Reply Retweet Like
Sebastian Markbåge Dec 9
Replying to @sebmarkbage
The bigger issue is that we need to be talking about version unification more in the ecosystem. It’s important that everyone keeps relatively fresh versions but not too many releases. Think for example how iOS forces developers into a few releases at a time.
Reply Retweet Like
Sebastian Markbåge Dec 9
Replying to @sebmarkbage
There has been talk for many years about solving the “CDN” problem. We know many people used the same version of jQuery but cross-origin caching never really worked out because the dependency on third party servers and privacy concerns but those are solvable.
Reply Retweet Like
Sebastian Markbåge Dec 9
Replying to @sebmarkbage
E.g. it’s hard to tell from a bundle size how much of that code could be shared across sites using hash/versioning mechanisms as standard libraries. How much can remaining in a long cache and how much is frequently changing code.
Reply Retweet Like
Sebastian Markbåge Dec 9
When talking web perf we need to distinguish common popular libraries from product specific code. There is a movement to more reuse but also an explosion in product specific client logic - which changes frequently. Current delivery mechanisms combine these which cause confusion.
Reply Retweet Like
Sebastian Markbåge Dec 6
Replying to @mjackson @dan_abramov
What would you call the three levels? 1) About to be deleted. 2) Won’t be deleted but if you use it and it leads to bugs, you only have yourself to blame. 3) This is the mainline narrative and some expectations can be made that if used correctly, it keeps working w/ new features.
Reply Retweet Like