16 comments

[ 5.3 ms ] story [ 48.7 ms ] thread
JS: 1.5MB PageSpeed score: 61/100 Time to Interactive: 9 sec TBT: 1.7 sec
Watching the browser choke two load points to make it appear is truly disgusting.

Honestly pathetic considering the size the engineering team used to be and points to an extremely broken culture.

In my experience, a larger engineering team makes these kinds of problems more likely

I wonder how many teams worked on tweet embeds, each with their own incomplete understanding of the full widget and their own competing product priorities and OKRs

> What hope does an average site have if a simple tweet requires MegaBytes of JS and seconds to interactivity?

Their hope is that their orgs probably aren't as bloated as twitter's

> What hope does an average site have if a simple tweet requires MegaBytes of JS and seconds to interactivity?

But dev deploying that abomination spent whole days less by just including random shit instead of understand the problems they solve! That's investor value!

Hey now, if you’re measuring my performance base on lines of code, I am damn well including everything I can think of, and cloning it right into my code rather than using it by reference.
Yeah, if it wasn't for the improved developer velocity of these fancy new JavaScript frameworks, we would have been left with a basic HTML version of the widget that doesn't require any JavaScript and has all the same features. Unthinkable!
Until a year or so ago you could read Twitter with Javascript disabled in your browser. So we know zero lines of Javascript are actually required to read tweets.

I just stopped clicking in Twitter links once they intentionally disabled browsing without Javascript, and use Nitter.net if there's a tweet I really want to read.

It's common sense that for reading a bit of text and perhaps an image there is no need for JavaScript. Even video doesn't require it. It should all be HTML.
Providing adaptive video (MPEG-DASH / HLS on any non Safari browser) still requires JS though.