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
I think you’ve touched on a key point here Alex - these are already successful products / companies who can afford to put in place performance teams to further their success. Most people working in startups and medium sized companies are scraping by to survive year on year
2 replies 0 retweets 0 likes -
There’s a reason most companies and teams follow the Kent Beck approach of ‘make it work, make it right, make it fast’ because having a fast product doesn’t meant anything if no one is using it
1 reply 0 retweets 0 likes
That isn't a full explanation for the market failures I'm seeing. In many cases, the last experience standing is a native app (not a faster website), which creates massive issues in the long run.
-
-
And darwinin progress takes time. Screwing over your experience can be totally silent (a failure to grow at a predicted rate) rather than noisy (loss of existing business). Hysteresis is hard to detect and most businesses are not dialed-in on the metrics.
0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.