Convopage
See the entire conversation
It's dowright amazing how much you can fit into 100k min+gzipped if you start with a minimalist toolkit and you're conscious about size the whole time.
279 replies and sub-replies as of Dec 07 2018
The reason this is a big deal is simple: you can ship something as rich as a native app in like 1/100th the size.
Instant loading, like a fast web page, but all the richness of an app.
Why isn't *everybody* doing this?!
It's the best of both worlds.
Have you met @_developit ?
Haha, yep. Several times 😁
Cause... React! 😂
I would clarify though, that it's often not react itself that is the problem. Usually it's a few react community modules later and your base toolkit is 200k.
Agreed. Honestly think it’s because majority of people want to use stuff already built and shimmy it in. Which ends up being dependency bloat like crazy.
Why isn’t everybody doing this?
This article shows how deep the problem is
Software disenchantment
Everything is going to hell and nobody seems to care
tonsky.me
You know why.
For the developers' convenience.
The hill to build nice little things that use the platform takes a craft mindset.
It's all too simple to bolt 30 packages together, leading to 100s of dependencies and boilerplate code and be done with it.
To really build something as rich as native would probably require WebGL and custom Design System built on it from scratch with accessibility in mind. A monumental task. There was an article from Pinterest where they got close to native using Canvas but the cost was too big
Do you have a link to this app?
Agree completely. I think what makes it less common is it’s much easier to do right when you start, sometimes near impossible after a project has gotten out of hand. Resources at project start aren’t always experienced with or prioritizing perf. Hire perf minded folks day 1
Absolute. We got first interaction of squoosh.app down to 15k, and it wasn't particularly hard.
I went into that project thinking I'd find some empathy for folks who ship 600k bundles, but I'm more convinced it's just careless.
Yep. I've got one of the most complex apps I've ever built at about 100kb without any bundle splitting at all. The only reason I haven't is... it just hasn't really felt necessary yet.
Are you using any sort of framework for that app?
fwiw, squoosh.app uses Preact
Can't find the link but someone did a nearly identical version of the Android Calculator app and it came in at 17k (I think?) Comparedt o the 20+MB for the APK
It isn't! We don't even bother minifying anymore. Small modules loaded in parallel with no transpile or bundle ftw.
fwiw I think it's useful and not-too-hard to go lower than 100k for first interaction. Makes a difference on 3g.
I don't disagree, I may end up splitting a bit, but my audience on this is literally doctors in the US on wifi.
Are you suggesting 10x 10kb modules is better than 1 x 100kb? Even with H2 I’ve heard this is not the case, although haven’t tested personally - have you?
10x10kb is absolutely better than 1x100kb if you can do something meaningful once the first 10kb has landed.
That’s a big ‘if’ though. Assuming from this thread all 100kb is needed, is it still better?
Not for the initial visit, but it means updates can be smaller.
Although, 100k is a massive amount of JS for a first interaction.
ya, that's a lot of app now. raw platform is pretty powerful now. also we're getting super good compression by opting into atomic css. (controversial!) but I love it. inline the entire stylesheet in the head. (we did this for begin.com)
We're using modular CSS for squoosh.app. It has its pros and cons, but I'm pretty happy with it. And yeah, we just inline the bits needed for first interaction.
That includes 8k of JS, which is still a lot given what the interactions are, but pfffft 8k whatever.
squoosh.app is delivered in many chunks:
➡️ First interaction - 15k
➡️ Main compression UI - 25k
➡️ Offline page-side handling - 1k
➡️ Service worker - 2.1k
➡️ Worker - 2.4k
➡️ MozJPEG - 68k
➡️ + more codecs
This means we're interactive in 15k, rather than 400k.
Is first interaction "code required to handle image drop" ?
+ image select via file picked, + demo image select, yeah.
Here's the bit of the talk that dives into how we split the main UI from the first interaction UI.
Complex JS-heavy Web Apps, Avoiding the Slow (Chrome Dev Summit 2018)
If you can do it without JavaScript, that's usually the fastest path. But what about when JavaScript is the only way? In this session we take a JavaScript-he...
youtube.com
Great presentation! I should read @DasSurma article you mentionned.
Link?
Great, thank you.
I'm writing an enterprise SPA and I'm code-splitting the various pages in there. Currently I'm prefetching all of those pages upon loading of the app. Wanted to know your thoughts on this approach.
Preloading everything is only a concern if it's so huge it's a waste of user's data & battery to fetch things they might not need, or if the code for rare interactions contends with bandwidth for common interactions.
This is awesome, what happens if the user tried to get to the next section, is there a loader or some such?
Only if they're very very quick. After the 15k, the second interaction is ready in an additional 25k.
Let's say the connection drops, what happens? Does the UI not respond?
Ah I saw in the video you show a loader :)) nice
idle-until-urgent pattern
Yes! kinda daily since they landed in FF last year (!)
here's a 'worst case' load. those response times are bad because we've hit lambda coldstarting (subsequent loads usually 100ms) and all pretty much in parallel. IDK how many modules / we're talking at least 50. cc @dam
Awesome stuff!
love seeing this
thx! it's all @dam really =) also we love working w preact so thx for that too! 🙏
Seriously @_developit preact has been the most reliable tool I've used in years.
I really, really appreciate not having to deal with constant thrash anymore.
👏👏👏👏👏
Loving htm as well!
Want to ping you about a PR so I could use it for SSR too with esm.
💯%. I am continuously impressed with how much we can do now with so little; also super back into thinking about things in terms of mulitpage apps with richer in-page components. it is way better user experience.
Did you have 5 PMs breathing down your neck to ship it yesterday? Empathy doesn't just come from how hard it is to build something.
I had a hard deadline. The app splitting (and choosing a light framework) was a small effort compared to the rest of the build.
(the app had to be ready for Chrome Dev Summit. Along with the talk, the MCing, and other writing & video work related to the event. Also, Background Fetch and TPAC had deadlines around the same time. I did burn out, I think, but certainly not due to code splitting)
Sheesh, dude... that's intense. You looked a bit zombie-ish at the party afterwards.
I felt it
The problem isn't one dev spending two weeks building a performant app, the problem is doing it with hundred devs spending two years.
hah, do that, while trying to survive to find a company that can pay well to separates me from reality so I can have more time to care about my bundle.
Yeah. I just built an app, it doesn't need to be crazy fast as it's internal only so I was just minimally careful to make sure it didn't blow up. I can't seem to get it to grow much larger than 30k...
Careful you might trigger some folks 😂
I’m using Gatsby with just the default webpack config and having a really hard time keeping my bundle sizes down. Any tips?
I don't have any experience with Gatsby, but if it's chucking out large bundles out-of-the-box, I'd be tempted to say "wrong tool for the job".
youtu.be/ipNW6lJHVEs?t=… - here's how we split stuff out in Squoosh. It might be possible in Gatsby.
Complex JS-heavy Web Apps, Avoiding the Slow (Chrome Dev Summit 2018)
If you can do it without JavaScript, that's usually the fastest path. But what about when JavaScript is the only way? In this session we take a JavaScript-he...
youtube.com
Pretty sure it doesn't and that I'm doing something wrong. I just can't figure out what. Thanks for the link though, I'll check that out.
the default bundle w/ React & @reach/router is 54kb
Announcing Gatsby 2.0.0 🎉🎉🎉
We’re incredibly pleased to announce the 2nd major release of Gatsby! Gatsby is a blazing fast modern website and app generator. Thousands…
gatsbyjs.org
Hmm, quite heavy for prerequisites.
You can shave ~30kb off the default bundle by switching to Preact, it is a drop-in replacement if you're not doing anything particularly React specific.
gatsbyjs/gatsby
Build blazing fast, modern apps and websites with React - gatsbyjs/gatsby
github.com
Nice. Yeah we used Preact for squoosh.app. We wouldn't have been able to hit our goals with chunkier frameworks like Preact/Ember/Angular etc.
I could take the last sentence and seriously misquote you here 😅
"Jake says even Preact is too big in Google SHOCKER"
Haha shiiit. I think my brain has started the weekend early.
pour one out for me
I'm not faulting Gatsby, pretty sure the issue is on my end.
Of course, there are four >180k bundles on the gmail app of which the largest weighs in at 584k so I guess I shouldn't beat myself up too bad.
Gmail shouldn't be your performance budget.
No, but it's one of the most widely used web apps in the world so not a bad benchmark.
It's also not used the way most web apps are used. I typically open Gmail once and leave it open in a tab all day. Load time for certain types of apps legitimately matter less, IMO.
+1. You shouldn't try to sweep performance under the carpet by betting on this kind of engagement.
I open gmail as a fresh tab every time, I hate open tabs. Neurotic about having more things open than what I'm focused on.
Totally agree. Time to interactive matters a little less if I know I'm going to be using the app for an extended amount of time--rather than a customer looking for something on an e-commerce site who's going to get impatient and bail if things get slow.
I would like to see how y'all can upstream your process and tooling to the larger community.
I think it is unrealistic to expect reaching the sub 100kb bar to be a normal thing for 99% of developers.
The only way this will happen is if our frameworks+tools do this by default.
Not that I disagree, but why do you think it's unrealistic to expect the vast majority of developers to care about users in this way?
Because the OSS toolchain that people are using today does not care about users this way.
This means you have to drop into bespoke build+framework land.
That's why we used Webpack & Preact for squoosh.app, not bespoke stuff.
(the web needs both realists and idealists to work together and learn from each other for progress to be made 👍🏻)
If you only had to convince the developers this was easy.
Start by convincing marketing that the tag manager and client side optimizely have to go.
absolutely. would love chrome to make it easier to roll up waterfalls by initiator and help devs push back on GTM cruft.
devrel: Try reducing script execution time by chunking your bundles!
me: Try reducing script execution time by maybe not letting marketing use Google Tag Manager to backdoor your waterfall with ads and tracking!
You make it sound like it's the developers fault. I don't think that's fair to assume. Let's assume good faith. Oftentimes there are hundreds of problems in the way initially that are far more existential than the bundle size.
We are lucky that we can focus on certain details and Google still pays us. Other developers would happily do that too. But reality is that they aren't paid for that.
So, what do you think the cause is of 200k+ bundles?
I think the root cause of this is bad defaults and bad tooling. And in between that you gave the problem that app devs aren't paid to fix that for the customers (unless explicitly requested). But as said in the other post, 200k+ per se might not be a problem at all.
There's a diversity of customers and not every application has to load fast everywhere.
I don't think we can compete with native if we treat performance as a nice-to-have.
Stages of performance delusion:
It's fast
It's fast enough
It's fast enough for my users
Solution too hard
Does performance really matter?
With squoosh.app we deliberately built a complex JS app, with modern real-world tooling, to show that it can still be fast with relatively low effort. The idea was to avoid it being easily dismissed as some kind of unicorn case, but… I guess not. ☹️
Yeah, performance budgets & monitoring are very import to maintain this across big teams.
The problems are similar to the external ones. Although, a lot of Google web products are built using tools that make non-web-developers feel comfortable. As such, a lot of the web's advantages are thrown away in favour of native patterns.
That's maybe part of the story.
The rest: Does "smoosh" have analytics? A/B testing? Experiments that can be turned up or down without rebuilding? What does it's unit testing look like; does it support dependency injection? Is it developed in a mono repo with 1000s of projects?
Sure, there's always going to be a way to dismiss something I build, as dev rel, because I also need to do dev rel jobs.
I wasn't born at Google. I have many years outside Google. I absolutely have empathy for stuff that grows over time. By the time you get to the bad place, there's a new thing promising "if you used this, you wouldn't be in that place", then 5 years later there's a new one etc etc
I'm more upset about new sites that launch with 600k to first interaction.
Even business/desktop apps?
Oh god yes I hate staring at a spinner for 10 seconds before I can access some form internally.
If it takes 10s, we're not talking about 600k.
I don't doubt your credentials
I find that even the best people/engineers, once they aren’t shipping web projects, start to have hard opinions they don’t have to ship
Struggling to figure this tweet out. Is the suggestion that I don't ship web projects?
I don’t want it to be taken as toxic as it might have come across. Every org I have worked in, there is usually a huge gap between principals not shipping products and juniors trying to ship products. The gap usually lies in that the eng heard two separate priorities (prod/eng)
It’s not a personal reply, just adding color to the thread
I like that @tomdale’s angle is coming at it from embedding in product, that is all. Not saying anyone in this thread does it differently.
*existing* product work is different from a *new* product. Especially around bundle size.
Undoing choices from 3 years ago requires massive investments.
To clarify, I'm talking about new products.
From my experience most "new products" nevertheless have to integrate with legacy infrastructure and services set up at that company. I haven't worked on "new B2C websites" lately, but just from listening to app devs I get the sense that it's not very different for them today.
Why is a V8 engineer showing more empathy towards developers than a Developer Advocate in this thread?
I have been an application developers for more than 10yrs before I joined the @v8js team, so I can empathize with my past self ❤️
*developers who unnecessarily launch with 600k JS bundles.
I have empathy for developers. But I must balance this with empathy for end users.
What I see is, dozens of *developers* giving you reasons why that happens, and because those reasons are by and large non-technical (and largely out of their hands), you are dismissing them and saying they don't care about end users.
Maybe Google needs End User Advocates and Developer Advocates as separate positions. Developer advocates should perhaps be targeting their materials not at developers, but at decision makers (PMs, CEOs) and explaining the business advantage of performant apps.
We currently try to do both.
I don't see the dev rel position as a cheerleader. I think it's about advocating developer issues to browsers, web issues to developers, user issues to developers.
Advocating use issues to developers is like yelling at your waiter about the ingredients in your sandwich.
This analogy doesn't really work. Maybe if I was yelling at web servers, but I'm not.
I think people are reacting strongly because it's easy to read this tweet as a bit glib. I know your real beliefs are much more nuanced, but the implication here is that avoiding large bundles is easy, and the primary cause of them is carelessness.
Absolute. We got first interaction of squoosh.app down to 15k, and it wasn't particularly hard.
I went into that project thinking I'd find some empathy for folks who ship 600k bundles, but I'm more convinced it's just careless.
I'm not surprised. Regardless of any back-patting it would earn me, I don't want to simply tell devs everything is fine – I don't think it is.
Tooling could be better, but code splitting is easier than it's ever been. But yes, it needs a mindset of progressively serving features
That's the web's big advantage, and an area native struggles with (eg Android 'instant' apps). We need to make the most of it. I worry for the web when I see sites that throw this benefit away.
The message (again) seems to be that ecosystem grew in the wrong direction & usual suspects hate to see it still does
The message is: Think about the user. Think about their first interaction. Deliver that first. Don't deliver everything before doing anything.
Ok. I guess the dozens of developer in this thread saying otherwise are just wrong.
Please continue with the strategy of telling developers to switch frameworks that hasn't worked for 3+ years now.
I was talking about your analogy, not dozens of developers.
I am not dismissing you or your project(s). I'm saying they don't represent all of the kind of requirements product teams at Google (or I imagine, many large companies) have to tackle. I realize as a Web DevRel that puts you in a particularly difficult situation 🙄
I'd like to hear more about projects that cannot be code split on things like first interaction.
Almost every project I know of has some form of code splitting. Not everyone is developing a PWA, or has a requirement to get a <1s TTI on mobile phones.
(Which I think is one of the original points brought up by @bmeurer)
I'm suspicious of projects that treat performance as a nice-to-have.
Some projects are fine with a Nissan Leaf and don't need a Tesla Model S
I would say a real comparison in this thread is between a very aerodynamic car built out of LEGO bricks that can drive your Barbie doll around the floor vs a real ugly fume producing jaggernaut that can drive you from A to B and back.
Just to check, are you saying the project I worked on is just a toy?
In terms of scale - yes. I think that problems become obvious when you try to scale. So what you did easily for your application does not necessarily easily translate into other larger apps. Of course you might have a recipe of how to make this - but I don’t see you offering one
For the record, squoosh.app is meant to be day-to-day useful. Not just a demo/toy.
Life lessons.
Talking web performance on Twitter: 对牛弹琴
more like «кидать ЛЕГО перед свиньями»
For most devs at most companies, you don’t get to choose perf in isolation. You have to choose among 100 competing priorities with resources that only allow you to accomplish a fraction of them.
It’s great when perf is at the top, but sometimes you need growth, or enough revenue for your company to survive the quarter, or to not get fired
Sure, but I think there are steps between terrible performance and "performance is top priority"
I'm aware of that. I often think of the first iPhone. It competed on user experience rather than number of features.
I think the amount of Chrome-only launches kinda speaks for itself in terms of attitude towards the web in large parts of Google.
So much this. This subtle-shame tweet from Jake is wild when a Lighthouse audit showing Gmail, one of Google’s most popular products, gets a Lighthouse perf score of 20/100 with TTI of 39 seconds.
mobile.twitter.com/jaffathecake/s…
Not that I disagree, but why do you think it's unrealistic to expect the vast majority of developers to care about users in this way?
Is the suggestion here that someone from a company cannot comment on performance unless every product at the company is perfect?
Sounds like a race to the bottom.
That’s a charitable interpretation of what you said and a strawman of what I said. There is implicit shame in your tweet that I quoted, that if you don’t keep your JS small, you don’t care about your users.
I think if you ship 600k-until-interaction when a code split would have made it 30k, the user impact of that has either been ignored or given a low priority.
Commenting on performance is one thing, but if you’re implying someone doesn’t care about their users if their apps have poor performance, then yeah, you absolutely should have killer perf in all your apps unless you also don’t care about your users.
Are you saying Gmail is *my* app?
Are you saying Google doesn’t care about its users?
I see you're now totally happy with strawman arguments.
Not a strawman, Jake. That was based on a reasonable interpretation of your words and the fact that Gmail ships over 1MB of JS before the page is interactive. It was even my original premise.
Asking if I thought Gmail was your personal app was a strawman, though.
Can you point to the tweet where I said Google, as a whole company, that builds many products on many platforms, "doesn't care about its users"?
The focus on shipping features deprioritize all the non-functional requirements. Teams are measured on features shipped, not on response times.
I'm not suggesting 15k is everyone's target. It's just what we reached with basic splitting. We could have gone much lower.
How big are the other bundles? Assuming the 15k is for the main bundle.
squoosh.app is delivered in many chunks:
➡️ First interaction - 15k
➡️ Main compression UI - 25k
➡️ Offline page-side handling - 1k
➡️ Service worker - 2.1k
➡️ Worker - 2.4k
➡️ MozJPEG - 68k
➡️ + more codecs
This means we're interactive in 15k, rather than 400k.
That’s a work of art 👌
The biggest bundle, OptiPNG, is 110k. We're not massively happy with that, and we're looking at alternatives. But, it's a couple of potential interactions away, and off the main thread.
This tweet is so on the money, but it does make me wonder: have any platforms in history solved that scaling problem?
Perhaps the huge dev teams are actually the problem. /me ducks.
Cool, i'll give you first option to buy :)
I have definitely observed a correlation between super-high-quality apps and tiny dev teams. Squoosh.app is an example of this.
Software development is so simple that obviously we should generalize all web applications in the world and their developers and focus on less than 100k. And then everything will be perfect :)
"5 time zones", says the guy working remotely from Alaska 😀
Do another one, and keep a work diary/log describing how you do each part and how long it took?
We've already wrote docs for parts of it, and plan to write more. But yeah, tracking the time that went into the build is pretty hard. It was a 20% project for all involved.
Yeah. That’s a data point right there, of course
Interesting, for me squoosh.app doesn't represent complex in the way I usually think about it when it comes to web. The pain point is complex UIs more than complex functionality. It's a very impressive piece of work, but not one I'd have used to make this argument.
People who can afford to focus only on complex functionality will fail to realize this, hence this kind of thread.
I don't think we should compete with native. That being said, I also don't disagree that performance should not be a nice-to-have. But unless you're the customer, you have to make sure you meet the requirements of the customer within the given constraints.
Your whole project can easily fail if you don't align the priorities according to the customers needs, many projects have. And that might mean, whether we like that or not (and I realize that as a DevRel it's even more inconvenient than for me),that performance is a nice-to-have.
If something can be built on either native or the web, would you advise building it on native rather than the web?
Whatever makes sense. There's some overlap between these options, but both also have unique strengths. I think we're better off focusing on the aspects that are unique strengths of the web rather than trying to compete on features in the intersection.
So as native platforms take on features of the web, we should just stop developing those features?
That's not what I said. I'd advocate for being pragmatic here: If "native" (for whatever that means in detail) turns out to be the clear winner, then we just do that (JavaScript will still be around anyways). It's all up to the customers. We should make our offer compelling...
...but focus on the strengths of the JavaScript platform (which for me BTW includes native via ReactNative, Electron, etc.), and not focus on what the competition is doing (I guess that's .NET, Android, iOS, etc.).
But if we mustn't compete in the intersection, as native platforms grow that intersection, the web shrinks.
You're taking this to the extreme.... but let's go there: if there's nothing unique left to the web, then what's the point of having the web?
Also as I said, I see this in terms of the "JavaScript platform" and the web is just a small part of that puzzle. There's so much more 😁
I don't think that's the same argument. For instance, native apps can render fonts. I don't think the web should stop trying to be good at rendering fonts. (replace "fonts" with everything in the intersection)
Native apps are dozens or hundreds of megabytes, and are fast because they cache the bundle.
No other platform fetishising 15k this way, and no other platform has devrel folks telling engineers to focus on it.
We can't compete with native if everyone hand-rolls the basics.
Downloading and installing a 50mb app is not fast.
Right, which is why this "compete with native" frame isn't comparing apples to apples.
Downloading and caching 600k is going to be worlds faster, apples-to-apples, than downloading and caching 50MB
Right, but when that 600k could be 30k with a tiny bit of effort, do that! That's what stops users staring at a white screen / spinner.
This has nothing to do with competing with native.
I disagree with your statement.
If you're describing native as competitively fast, that means you think that large bundle sizes not only don't disadvantage native, but actually put them far ahead of web.
When analyzing web, you measure the initial download. This is not an apples-to-apples comparison.
I'm not describing native as fast in this respect.
Native has many features the web doesn't have. Some the web may never have. There are things the web can do that native can't, or is very bad at. We need to make the most of those benefits.
The App Store model gets a free pass, again.
Another way of looking at this: sites whose owners also build native apps, but convert only a fraction of users, at different ROI per user. Most people won’t install app N+1 w/o strong incentives. Install costs count against native.
I simply don't believe that in order for the web to be competitive, web developers have to learn to ship apps with competitive features with nearly no code and no abstractions.
That's the way to lose to native.
There's a lot of different kinds of web apps and websites.
I'm not sure who this is aimed at, but I haven't been talking about the amount of code shipped with an app, I've been talking about the amount needed for first interaction.
I get it, but Yehuda's point is apples to oranges. Native apps start pretty quickly once installed (well, most do) but install costs (all in, time + cog-load) are a barrier. So if web can beat native on app start, great. But other tradeoffs than startup time still vex devs&users.
Simple things like tab switching using a swipe gesture are not so great on web. Also, offloading heavy work to a background thread is simpler in native. There are things other than just start time preventing users from using very well made PWAs like Instagram and Twitter
Agree in general. FYI some browsers of quality provide swipe to tab-switch ;-).
This thread needs systems/requirements engineering. Each app will have requirements. If PWA (best @jaffathecake practice) meets requirements then use PWA. If PWA doesn't but native does then use native. If neither meets requirements then do multi-criteria analysis.
Those are things that are in the native/web intersection that we absolutely must improve.
Users don't mind waiting, its about acclimatization and creating a norm. Consumers of services do. If time can be spent discussing purposeful experiences rather than lower amount of compressed bytes it would make more sense. Competition isn't everything if there's no interest.
*slowly raises hand* I mind waiting
Mr. Eich, will Brave ver. 1 support addons like Chrome does? It really should.
We already do, please read today's news: brave.com/brave-upgrades/ (we had the new version up for default download for over a month; now we are updating the installed base). Note we disable Google accounts/sync/tracking so extensions that depend on APIs tied to those won't work.
Brave Upgrades Users of its Desktop Browser to its Redesigned, Faster Version | Brave Browser
(no description)
brave.com
How 600k could be 30k with bit of effort? 20 times smaller bundle size?
Code splitting the first interaction (see the thread)
Exactly! ~50% of our customer projects are internal web apps that are loaded once and then used for several hours. Performance is still important (because mobile is still a use case) but it's not our main use case we're focussing on.
It's going to become more common for browsers to discard tabs that aren't visible, so this argument may change slightly.
Also, One thing that was visible from our performance metrics data is that first time users care less about UX performance than repeating users. This gives devs some room to get some quick wins like having proper cache-headers and so on.
Interesting. I think I'm less forgiving of sites that haven't yet proven to be useful. But it's possible what I think doesn't match how I actually behave.
Tooling could be better, always, but it's also better than it's ever been. squoosh.app achieved 5 seconds to interactive on 2G with modern tooling, + a little care & attention.
I think the web will always be behind the latest tooling. A greenfield project can start with the latest tools and best practices. Lots of jobs have devs joining projects that already have a few years worth of commits. Hard to retrofit modern principles.
I wasn't born at Google. I have many years outside Google. I absolutely have empathy for stuff that grows over time. By the time you get to the bad place, there's a new thing promising "if you used this, you wouldn't be in that place", then 5 years later there's a new one etc etc
My bad 🤗 I wouldn’t be suprised if more declarative/static/domain-specific languages win in the long term. Playing with Elm, the compiler seems to be able to be very aggressive at optimising for size (when combined with uglifyjs).
At the companies I have experience with the root issue has been priority. If you don’t already know how to build a certain way (e.g., a11y or performance focused) it’s hard to research, learn, and change while still delivering what the company sees as priority (new features).
Our bundle is just shy of 400k (we're still working on it) but 140k of that is just Angular. Hoping that ivy will make things better. There's also probably some stuff we could eliminate already manually.
If 140k is Angular, Angular has put you in a position where you lose by default. I really hope things improve here.
Preact let us hit first-interaction in 8k of JS.
The majority of application development is making the customer happy, building the product that the customer needs (which is not strictly equally to what the customer claims it needs). Whether or not that includes fast page load time in EM varies (I'd guess it often does not)
I wasn't born at Google. I've worked at startups, agencies, big companies with hard deadlines. I always built with performance and accessibility in mind, even if it wasn't explicitly asked for.
I want to build a good web.
I consider it a privilege to be paid to focus on software performance.
In many companies, to make fast apps, you must first take on an uncommissioned job of convincing management to value the science of building high-speed software.
The tell: CEOs with millisecond-accurate eyes
I didn't convince management, I just did it. Then they started to notice the stuff I built "worked better" than projects I didn't work on.
Right. It's possible. I too have created artisanal apps with blinding performance.
It demonstrates your commitment to your personal values and probably gets you a pat on the back.
But let's not confuse that with sustainably changing company/industry practices.
That's is why we used common tooling for squoosh.app.
That's what I do, I often build stuff and ask permission later. I've noticed that it's really hard to argue with "Hey, here's a working thing I already built... oh, and it's fast as hell."
Devil's advocate: what did management learn from this experience?
They learned that without specifying performance goals or commissioning performance infrastructure, engineers just magically deliver a fast product. At best, they concluded they should invest more in you.
For sure @HenrikJoreteg @jaffathecake are doing stunning work educating the world on best practice.
This wasn't my experience btw. Once they were complimenting my projects, I explained my process. Then, they wanted that process applied to other projects.
This is true. I’m the sole dev for a product that has 5m+ requests/month (not big). Its bundle size is 3mb (!!!) and I couldn’t afford taking time to improve it yet. I want to, but other stuff is more important. Stakeholders never cared about this.
What if we care about users but we very often do not get the opportunity to write greenfield projects, and have to constantly balance product changes vs performance improvements in big existing apps that have a heavy weight of past decisions involving many stakeholders?
My tweet was aimed at sites launching with 600k-to-interaction.
Ah, sorry, that is much more fair of a question than how I was reading it
I do not want to drag your accomplishments through the mud, I want to be realistic when communicating. Most applications I work on and see have 1+ frameworks, 1+ UI toolkit libs, and 1+ "heavy" 3rd party lib.
Under 100kb is just not possible with today's frameworks+toolkits
squoosh.app is delivered in many chunks:
➡️ First interaction - 15k
➡️ Main compression UI - 25k
➡️ Offline page-side handling - 1k
➡️ Service worker - 2.1k
➡️ Worker - 2.4k
➡️ MozJPEG - 68k
➡️ + more codecs
This means we're interactive in 15k, rather than 400k.
I agree that you should code split as soon as the split points become clear. However, we did the splitting kinda late on squoosh.app, but it was still pretty straight forward.
Elm makes this so easily done with its amazing dead-code elimination. And about functional CSS, you are so right!
Didn’t get your question really
"Weird and less productive" I can tell you this fades dramatically over time. The ability to add a new feature without adding any new CSS is worth the learning curve, IMO.
I can only speak to my lived experience. Tachyons (or similar) has been a life-saver on several projects I've been involved with. Including the starbucks PWA. The pattern library uses and provides lots of functional classes: starbucks.com/developer/patt…
props to: @alexlande
In my experience, you can get the ability to add new features without adding new CSS with a well maintained module-based style guide. It also helps enforce corporate branding more strictly than functional CSS does
I combine the two. I build a pattern library out of components that apply functional CSS classes based on properties.
Yeah, there is a best of both worlds there when you can rely fully on a particular component approach (i.e. a React-only ecosystem)
Isn't functional CSS the thing where you write a dozen class names on every element? Aren't you just trading writing CSS in a CSS file for writing in a style attribute value?
Most should - heck out styled-system + emotion. My favorite combo. Have a WIP example here with next/react
mrmrs/scary
Contribute to mrmrs/scary development by creating an account on GitHub.
github.com
Sorry for interrupting, but how can we achieve this approach?
Can you recommend any articles or books to read?
Yup, I wrote a whole book about how I do it. Oh, and it's available to read for free online: read.reduxbook.com
Thank you Henrik! 😄
"minimalist toolkit" is key.
Otherwise I think it can be difficult to keep size down.