Some people want to "blame React", while React people want to "defend React". But those two narratives overwhelm a discussion about which techniques, when used together with any framework, get the best results.
-
-
So it's not "React's fault", but at the same time being defensive on behalf of your framework of choice (I include myself with regard to Ember) is contributing to the poor quality of the community conversation.
1 reply 0 retweets 8 likes -
Replying to @wycats @slightlylate
I use React sure, but I don't feel particularly defensive about criticisms of it when they actually make sense. But blaming a 400KB bundle on the fact that the user used React is a bit absurd to me and makes it really hard to take anything Alex says seriously on that front.
1 reply 0 retweets 4 likes -
Replying to @sincerely_tegan @slightlylate
I think that it's wrong to blame React, because that isn't the conversation. It's not wrong to observe that people assume that React is "fast enough" and that there's too little discussion about techniques that should come default across the board.
1 reply 0 retweets 7 likes -
Replying to @wycats @sincerely_tegan
Also, I don't "blame" React. Instead I note the probability (approaching 1) that sites with 400K of 1P JS include a relatively heavy framework, too many polyfills, and many other unneeded elements. Heavy FW use is a symptom of broken culture and management priorities.
2 replies 0 retweets 10 likes -
Adam Rackis Retweeted Adam Rackis
Define heavy? React is < 10% of that 400K. If you really want to make this better, *here's* the battle to be fought:https://twitter.com/AdamRackis/status/1040029445179039744 …
Adam Rackis added,
3 replies 1 retweet 14 likes -
The thing in your cited tweet is a big piece of what my other tweets were getting at! STRONG CONFIRM!
2 replies 0 retweets 8 likes -
Replying to @wycats @AdamRackis and
Another piece is figuring out how to model async fetching in frameworks so that simply using popular routers in the normal way gets you a decent amount of code splitting.
2 replies 0 retweets 3 likes -
Replying to @wycats @AdamRackis and
import() is a nice primitive, but asking every dev to use it manually is asking people to deprioritize it. It's great that the tooling is getting support that we can use in frameworks.
1 reply 0 retweets 2 likes -
That’ll always be tricky. Maybe some Babel plugin that takes <Route> <Component> and rewrites it using an async middle man? Tough to get right.
1 reply 0 retweets 0 likes
There's already in-framework async points inside of the routing layer. The framework can take one of those points and automatically fetch code associated with a route using import() and some registry or naming convention.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.


