|
29 posts total
12
"I wasted a day on CSS selector performance to make a website load 2ms faster" by @trys https://www.trysmudford.com/blog/i-spent-a-day-making-the-website-go-2ms-faster/ This is one of the unfortunate things about the DevTools' "selector stats." It can really mislead you if you don't notice the text "(slow)" which _really_ means slow. Working on an additional PR now that adds a _bit_ more complexity but gains a ~15% perf boost in Chrome and ~36% in Firefox. It relies on detecting when the `content-visibility: auto` state changes and using the old `<img data-src>` trick to set the `src` in that case. https://github.com/nolanlawson/emoji-picker-element/pull/449 A bit of extra code, but still not as gnarly as a full virtual list! Publishing npm packages as ESM-only and with no TypeScript is such a breath of fresh air. The published files are the same as the source files, just like we used to do with npm back in 2012 New blog post: "Retiring Pinafore" https://nolanlawson.com/2023/01/09/retiring-pinafore/ Probably not going to surprise anyone, but I'm stepping back from Pinafore. Thanks to everyone who followed along with this project over the years!
Show previous comments
@nolan Saying thank you like this feels a bit weird, but pinafore has meant a lot to me over the past few years. Especially while I was still on my old galaxy s2, with internet throttled to 64kbit/s because I'd used up all my data, sometimes with spotty connectivity on a train. And it worked so well, with so little frustration. It showed me just how good a webapp can be. It's one of the best pieces of software I have ever used, and I have a fondness for it that I have for little else. Thanks. @nolan Thank you for your work, Nolan! It would be interesting to see if Svelte community can pick up maintenance of Pinafore and highlight it under awesome SvelteKit projects. @nolan Thank you for making the fediverse a little more useable over the years. Well done! Enjoy your "retirement"! @flaki asked me for this, so here's a short guide on scaling Mastodon *down*: https://gist.github.com/nolanlawson/fc027de03a7cc0b674dcdc655eb5f2cb Note that I'm not a Ruby/Sidekiq expert and probably don't know what I'm talking about. But these tips worked for me. Your toot motivated me to look into S3 pricing and holy cow ~40GB for 1$/month. I've got to look into it asap
 @nolan Thank you for sharing this, Nolan! I haven't felt the Sidekiq memory leak in my single-user instance yet but I'll add the auto restart regardless. @nolan @flaki Forgive the naive question, it's just out of curiosity, but would it be bad advice to run a small site off a cheap VPS server that also had 4gb RAM? Or I don't know if lighter weight alternatives to Mastodon are preferable (not sure which one). Ruby on Rails seems so heavy. Even the popular Canvas LMS built w/it disables search & other features probably because of costs and load. "Home invasion: Mastodon's Eternal September begins" by @hugh https://www.hughrundle.net/home-invasion/ This past week has been wild. I have mixed feelings about it as well. For me, Mastodon developed into a small, quiet space where I shared the odd post from my RSS feed and mostly talked about Linux and web dev. I gave up on it going mainstream ~3 years ago. Seeing it featured in CNN, Time, BBC, NYTimes, etc., is surreal. If history is any indication, though, this current wave will eventually crest. The question is: what % will remain, and what kind of community will they build? Us old-timers have to remember that we only get a vote, not a veto. "What people think that web developers do vs. what we really do" by Christian Heilmann https://christianheilmann.com/2022/05/27/what-people-think-that-web-developers-do-vs-what-we-really-do/ This got a chuckle out of me. Sometimes I feel like "Updating node/npm" is actually the majority of the pie chart.  I feel better about how much of keeping dragon.style running is "updating its myriad dependencies" now. I swear so much when doing that. So, so much. "Understanding why our build got 15x slower with Webpack 5" by Eoin Hennessy https://engineering.tines.com/blog/understanding-why-our-build-got-15x-slower-with-webpack Pretty nice to see a perf post that actually goes the extra mile to open a PR on the library in question, plus build V8 from source (!) to identify the root cause of the regression. "Using the platform" by Elise Hein https://elisehe.in/2021/08/22/using-the-platform Good overview of where we're at with the "framework-less" approach. For something like ES Modules, I'm looking forward to the day when I can just write static HTML/CSS/JS and have the server optimize the bundles (similar to how modpagespeed used to work). "Apps Getting Worse" by Tim Bray https://www.tbray.org/ongoing/When/202x/2021/08/07/Apps-Get-Worse My wife and I have a running joke where she'll complain about some awful new "feature" in an app that makes the experience worse, and I'll say "Somebody got a promotion for that." The sad thing is it's probably true. "npm audit: Broken by Design" by Dan Abramov https://overreacted.io/npm-audit-broken-by-design/ I'm so glad someone finally said this. The current situation is a huge mess. "Svelte for the Experienced React Dev" by Adam Rackis https://css-tricks.com/svelte-for-the-experienced-react-dev/ Directly comparing Svelte to React is a great way to show how well-designed it is. Things in React that make my brain hurt feel like they "just work" in Svelte. Personal preferences will always vary, but I know which framework I prefer.  "iOS 14.5 brings the new Safari 14.1 to PWAs and the Web Platform" by Maximiliano Firtman https://firt.dev/ios-14.5/ As always, exhaustive and fascinating. Looks like I'll have to adjust the app status bar color. I was on the Frontend Heroes podcast recently talking about web performance. We managed to get pretty deep into some geeky topics, so I had fun with this one. https://frontendheroes.transistor.fm/episodes/performance-returns Coincidentally there's a Jeremy Keith post today talking about Core Web Vitals, which we discussed on the podcast: https://adactio.com/journal/18040 I was on the Shop Talk Show podcast, talking about web components, CSS, and JavaScript. It was a fun interview! https://shoptalkshow.com/451/ Pinafore development has slowed down because I've been focusing on other things, like my personal life. But I'm starting to ramp up a bit now and have been fixing some bugs recently. Part of it has been me stepping away from social media in general (I don't post as much as I used to) and from open-source software (it became a source of guilt and dread, so I dialed back on it). Cooking, biking, books, and video games have been a more fulfilling use of my time recently. Honestly, Pinafore is the only interface I need for Mastodon, and the main one I've used since I started developing it. I know the Mastodon frontend has tons of features Pinafore doesn't support (trending hashtags, server announcements, profile editing, etc.) but I just haven't felt hugely motivated to add those. Somewhat tangential, but I think it's better to teach accessibility by examples ("screen readers will read this part," "an Alexa will speak it in this accent") rather than talking about HTML tags as if they represent some platonic ideal of semantics. The abstract stuff is hard to grasp, and it's often just wrong, e.g. when screen readers have bugs or don't implement certain things correctly. I like the author's example of "if you forget this, mobile users will have to zoom in which is annoying." Reading up on how Hot Module Replacement actually works, and it's sort of confirming my suspicion that it's not really worth the trouble. https://github.com/rixo/svelte-hmr#whats-hmr-by-the-way There are so many caveats and edge cases, and it turns out you need to make your module "HMR-ready" by adding annotations or custom code. This can work out-of-the-box for some component frameworks, but it seems to me that on a non-trivial app, it just takes one module to mess everything up. Maybe refreshing is not so bad? @nolan I almost wonder if setting up some kind of OS-level keyboard macro that reloads the browser when you press a key combo wouldn't be easier to set up and 90% of the benefits (also I am really suspicious when it comes to layout changes in particular being rendered correctly in a hot-reload situation) "We rendered a million web pages to find out what makes the web slow" https://catchjs.com/Blog/PerformanceInTheWild Interesting analysis, although I think it's hard to draw conclusions from the correlations. A lot of the causes are probably social/organizational rather than technical (e.g. X library is older, so it tends to be in older, more gnarly codebases). @nolan our finding is that it takes a very long time to render a million web pages and we do not recommend doing it 12
|
Gregory's Server
Another issue I've noticed with "selector stats" is that it might give the impression that selector perf is all that matters for reducing style calculation costs. Whereas if your costs are due to CSS custom properties, or excessive numbers of stylesheets (e.g. this fun issue [1]), or something else during style recalc, you can end up chasing ghosts.
(That said, I *love* selector stats, and it has helped me debug some real perf issues! I am glad we have it!)
[1]: https://issues.chromium.org/issues/40229331
Another issue I've noticed with "selector stats" is that it might give the impression that selector perf is all that matters for reducing style calculation costs. Whereas if your costs are due to CSS custom properties, or excessive numbers of stylesheets (e.g. this fun issue [1]), or something else during style recalc, you can end up chasing ghosts.
@nolan I think the confusion comes from the expectations set by of all other performance profiling tools. We're used to Lighthouse and WPT being 'slow', but we know we can trust all their tables and graphs to be time-accurate.
This particular flavour of 'slow' needs a big ol' tooltip warning you which results are and aren't affected by the enforced slowness.