I honestly believe that the groupthink allowing people to think of performance as equivalent to a11y is resulting in a failed regime that attempts (but fails) to push the responsibility onto end developers and doesn't accomplish its own stated goals.
-
-
"secure by default" was an acknowledgement that applying this kind of thinking to security is catastrophic. It's like teaching people to cook with chainsaws and adding a chainsaw safety class to the beginning of the course.
1 reply 0 retweets 0 likes -
The same is true about performance. Web browsers and frameworks working together to improve performance by default is the only way forward.
1 reply 0 retweets 0 likes -
Incidentally, one success story: modern frameworks are naturally much much better at phasing DOM reads and writes than the jQuery style of coding in large part because web frameworks took the problem seriously in collaboration with web browsers.
1 reply 1 retweet 2 likes -
Replying to @wycats
Mhh, I half agree. A11y is more of a necessity, as slow sites *can* still be used (by those with fast connections). I also love your utopian idea of a 'fast by default' web, but to my knowledge, no programming environment ever achieved that.
1 reply 0 retweets 1 like -
Replying to @pbakaus
What we have now is slow by default, and web browsers thinking they can solve it by reaching each individual developer one person at a time when people are mostly working on adding features for their job.
2 replies 0 retweets 1 like -
If you follow it to its conclusion, you get the increasingly shrill (and ineffective) shaming campaigns we've seen come out of Google in the past and which I don't want to see crop up again. If you're worried about TTI, pervasive route-based code splitting would do a lot.
2 replies 0 retweets 1 like -
Concrete ideas like building: code splitting, tree shaking, DOM phasing, more work off the UI thread into frameworks will go much further than trying to get already-burdened curricula to cover the low level details that people can use to try to do it themselves.
2 replies 0 retweets 0 likes -
To be concrete, I think browsers could be more overt about the fact that frameworks are likely the solution to this problem, and come clean about the fact that a vanilla.js + perf training world is unlikely to result in the fast web we all want.
1 reply 0 retweets 0 likes -
Replying to @wycats
I don't see it as one-sided. It's imo important, and OK to teach developers about a perf budget. I'd prefer not to teach them about the browser's hidden classes. I definitely think frameworks and libraries are part of the solution.
1 reply 0 retweets 1 like
I think it's ok to teach devs the concept of TTI but if end devs are trying to hit frame budgets directly we probably already failed. I've met many good devs who don't even know how to use `debugger`
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.