We're over-focused on benchmarking "hello world" minimal thresholds, with very little focus on what we can do as a larger community to systemically reduce the cost of abstractions?
-
-
Show this thread
-
Which practices in frameworks combined with which tools reduce (or eliminate) the cost of unused code? Which tools could we be building? Which asynchronous programming models help to delay the cost of code to the point where it's being used?
Show this thread -
What different kinds of users are there and what size/CPU budgets do those users have?
Show this thread -
As
@slightlylate said: "This will mean that many popular tools are relegated to prototyping. That’s OK." Rather than "disqualifying" frameworks for all uses, could figure out what use-cases a particular environment is useful for?Show this thread -
Can we, as framework authors, do a better job of communicating which personas are appropriate for our frameworks, using quantitative measures that the community agrees on broadly?
Show this thread -
Any analysis that lives or dies based "how many bytes is in a <Framework X> hello world" is a completely useless analysis that does nothing to promote the kinds of questions we really need to be asking.
Show this thread
End of conversation
New conversation -
-
-
Do you agree that it's React's fault that because a site that happens to use React is unoptimized that it's React's fault though? It seems like he's just looking for excuses to yell at frameworks at this point.
-
I think that the developer community could really, badly use a discussion about which techniques work better, and I also believe that the discussion around React isn't helping us have that discussion.
-
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.
-
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.
-
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.
-
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.
-
Do you agree that tooling could eliminate or defer enough unused code (in combination with better patterns and programming models) so that the size of the "raw" framework matters less than how many features of the framework you're leaning on?
- 36 more replies
New conversation -
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.