There's a cottage industry of "thought leaders" trying to sell you one weird trick to fix what you broke with JS ("SSR!", "scheduler!", "compilers!", "preset-env!") but it's all failing. The only thing that works is *less script*. How? Structure + budgets.https://twitter.com/slightlylate/status/1018329021522706435 …
-
-
Replying to @slightlylate
Do you have any multi-year case studies of a real world, revenue generating application that successfully shows this? In my experience, software is never done, features are always added, never removed, which typically means "more script". This is a game of cost mitigation.
3 replies 0 retweets 13 likes -
Replying to @chadhietala
You're conflating a few things here that are worth untangling: first, many of the failures I see are either new development or redevelopment. E.g., "green" field. It short be easier to succeed in these environments, yet unusable amounts of JS are the norm...
1 reply 0 retweets 3 likes -
Replying to @slightlylate @chadhietala
I *also* see failure in stable, evolving products, for reasons we'd agree on. In both cases budgets and structure are helpful. In new projects, that defines tool choice. In stable products, that defines the space of improvement projects (often down to changed assumptions)
1 reply 0 retweets 0 likes -
Replying to @slightlylate @chadhietala
What I'm trying to say is that performance is about culture supported by tools. Browsers did a decent job supporting an HTML+CSS world; pulling out all the stops to get users to interactive content quickly. JS defeats all of this, puts burden back on teams...
1 reply 0 retweets 8 likes -
Replying to @slightlylate @chadhietala
...and the tools they're picking up today, frequently, do not include equivalent support for getting interactive quickly by default. So we need to reset: when you pick JS as your starting point, you now own the full problem. The browser can only do so much to help.
1 reply 0 retweets 7 likes -
Replying to @slightlylate @chadhietala
Teams ARE NOT BEING TOLD THIS BY THEIR TOOL VENDORS. The successful products have staffed-up performance teams whose only job is to define, measure, and iterate on metrics that are meaningful to the business (Chrome sure does!)
2 replies 0 retweets 9 likes -
Replying to @slightlylate @chadhietala
Facebook doesn't serve React with some glued together WebPack and Google doesn't "do" Closure the naive way. They come with gobs of infrastructure that their OSS projects don't benefit from. That's the difference between success and failure, and we aren't talking about it enough
1 reply 8 retweets 34 likes -
Replying to @slightlylate @chadhietala
This is why tools that do things like auto-per-browser-builds and default route-based-code-splitting are different IN KIND. They represent that full, supported stack that you need to succeed.
1 reply 2 retweets 10 likes
That is, they are a key part of a culture that understands limits and budgets and has the tooling to support those things as an organisational priority. Cultural change is usually a discussion with managers and TLs. Not all teams get it. Related: lots of progress is darwinian.
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.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.