Perhaps surprising: I agree with @slightlylate that the discussion we're having about web performance isn't helping us move forward as a community.
-
-
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 -
-
-
The "hello world" focus is a big problem. Too many popular backend benchmarks will, for example, never require looking at request headers -- thus favoring a framework which implements `headers.get` as an on demand string search, even though that will hurt real world use cases
-
This goes so far as so penalize frameworks for constant-time verification algorithms, or even having on-by-default cookie signature verification at all.
-
And on the server side, the "slow frameworks" have a few milliseconds of overhead, while people report "requests per second", which produces much much bigger apparent differences.
End of conversation
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.