|
12345 |
- title: Honesty is the best policy
- url: https://hankchizljaw.com/wrote/honesty-is-the-best-policy/
- hash_url: 195a2ecd81fa25a7cf43248b809bf724
-
- <p><strong>Update - 6 February, 2020</strong>: Gatsby have now clarified their position by deleting <em>“a single image is often bigger than a JavaScript bundle”</em>, only with no explanation on why. As is increasingly the case, <code>trust--</code>.</p><hr/><p>There’s an article circulating, titled <a href="https://www.gatsbyjs.org/blog/2020-01-30-why-gatsby-is-better-with-javascript/">Why Gatsby is better with JavaScript</a>, which boils down as a justification for why the framework produces so much JavaScript output. This is fine and there are some good points in the article, but there’s one bit that I initially skimmed over, and spotted today (thanks, <a href="https://twitter.com/stowball/status/1224791020220510208">Matt</a>) which made me wince:</p><blockquote><p>“It’s also important to put the JavaScript bundle size in perspective. While it definitely can have a detrimental effect on performance, especially when it grows uncontrollably, a single image is often bigger than a JavaScript bundle.”</p></blockquote><p>It goes on to say that “It’s worth judging the website as a whole, not only how much JavaScript it ships”, which I wholeheartedly agree with, but the sentiment of the main quote is concerning and frankly, it’s completely false.</p><p>I urge you to read <a href="https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/javascript-startup-optimization">JavaScript Start-up Optimization</a> by <a href="https://addyosmani.com/">Addy Osmani</a>. It’s a brilliant article that explains the true cost of JavaScript really well. There’s a couple of takeaways that I want to highlight:</p><blockquote><p>“Spending a long time parsing/compiling code can heavily delay how soon a user can interact with your site. The more JavaScript you send, the longer it will take to parse and compile it before your site is interactive.”</p></blockquote><p>This is something that’s very important to remember and it’s one of the main contributors to my obsession with shipping as little JavaScript as possible— <a href="https://web.dev/interactive/">Time To Interactive</a>, which is how long after the initial request for a web page it takes for you to be able to interact with it. For heavy sites, this can be an eye-watering long time (hello news sites).</p><p>This is not an issue for me, because I am steeped in privilege with my top-spec MacBook Pro and iPhone 11, so generally, most sites—even ones with outrageous bundle sizes—tend to run fine. We should’t be building for people like me though, because people like me are the privileged minority. We should instead be optimizing for low-to-mid powered devices. One good way to test your sites against devices like this is <a href="https://webpagetest.org/easy">Webpage Test’s “easy” preset</a>.</p><p>Some other related advice is to not 100% rely on <a href="https://developers.google.com/web/tools/lighthouse">Lighthouse</a> scores. Lighthouse is a fantastic tool which gives you a good idea of how your website is performing, but it can also be misleading, as <a href="https://www.matuzo.at/blog/building-the-most-inaccessible-site-possible-with-a-perfect-lighthouse-score/">Manuel Matuzovic eloquently describes</a>.</p><p>Anyway, back to Addy’s article. Another takeaway from the article is this:</p><blockquote><p>“JavaScript and image bytes have very different costs. Images usually don’t block the main thread or prevent interfaces from getting interactive while being decoded and rasterized. JS however can delay interactivity due to parse, compile and execution costs.”</p></blockquote><p>This is what my issue with the Gatsby article is.</p><h2 id="heading-benefit-of-the-doubt">Benefit of the doubt<a href="#heading-benefit-of-the-doubt" class="heading-permalink"><span class="visually-hidden"> permalink</span><svg fill="currentColor" aria-hidden="true" focusable="false" xmlns="http://www.w3.org/2000/svg" viewbox="0 0 24 24"><path d="M9.199 13.599a5.99 5.99 0 0 0 3.949 2.345 5.987 5.987 0 0 0 5.105-1.702l2.995-2.994a5.992 5.992 0 0 0 1.695-4.285 5.976 5.976 0 0 0-1.831-4.211 5.99 5.99 0 0 0-6.431-1.242 6.003 6.003 0 0 0-1.905 1.24l-1.731 1.721a.999.999 0 1 0 1.41 1.418l1.709-1.699a3.985 3.985 0 0 1 2.761-1.123 3.975 3.975 0 0 1 2.799 1.122 3.997 3.997 0 0 1 .111 5.644l-3.005 3.006a3.982 3.982 0 0 1-3.395 1.126 3.987 3.987 0 0 1-2.632-1.563A1 1 0 0 0 9.201 13.6zm5.602-3.198a5.99 5.99 0 0 0-3.949-2.345 5.987 5.987 0 0 0-5.105 1.702l-2.995 2.994a5.992 5.992 0 0 0-1.695 4.285 5.976 5.976 0 0 0 1.831 4.211 5.99 5.99 0 0 0 6.431 1.242 6.003 6.003 0 0 0 1.905-1.24l1.723-1.723a.999.999 0 1 0-1.414-1.414L9.836 19.81a3.985 3.985 0 0 1-2.761 1.123 3.975 3.975 0 0 1-2.799-1.122 3.997 3.997 0 0 1-.111-5.644l3.005-3.006a3.982 3.982 0 0 1 3.395-1.126 3.987 3.987 0 0 1 2.632 1.563 1 1 0 0 0 1.602-1.198z"/></svg></a></h2><p>I want to give Gatsby the benefit of the doubt on this. I want to believe it’s not a sinister attempt at self-justification by distributing a little mistruth that could cascade, much like the <a href="https://github.com/w3c/html/pull/331">myth that you can use multiple <code><h1></code> elements on a site</a>. I, of course, <a href="https://twitter.com/hankchizljaw/status/1224972729373405185">spat out my tea on Twitter when I saw this</a>, but <a href="https://twitter.com/hankchizljaw/status/1224976031163076610">added to the thread</a> that I appreciate the work that Gatsby are doing for Accessibility and improving client-driven JavaScript, by working on partial hydration. These are good things and the optimist in me is hoping that they take their <a href="https://www.crunchbase.com/organization/gatsby-e828#section-overview">sizeable VC funding</a> and apply it in becoming leaders in modern, performant frameworks.</p><p>I also think that there could a bit of naivety from the author of <a href="https://www.gatsbyjs.org/blog/2020-01-30-why-gatsby-is-better-with-javascript/">the article in question</a>, who might not be aware of the points raised in <a href="https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/javascript-startup-optimization">Addy’s writing</a>.</p><p>I’m trying to look at Gatsby in a more positive light, as I <a href="https://hankchizljaw.com/wrote/2019:-a-year-in-review/#heading-time-to-embrace-react-and-gatsby">mentioned in my 2019 year in review article</a>. I even built <a href="https://front-end-challenges.club/">Front-End Challenges Club</a> with Gatsby to better understand the workings of it and I must say, the developer experience was lovely. I’ll also be <a href="https://piccalil.li/course/lets-build-a-landing-page/">teaching a course on Piccalilli</a> using Gatsby as the core static-site generator. I still, of course, prefer <a href="//11ty.dev">Eleventy</a>, but it’s important that I’m fair with criticism and that actually using tools like Gatsby contributes to that.</p><p>This all boils down to trust. Trust is often not lost in single events but instead it is chipped away at. With the <a href="https://themejam.gatsbyjs.org/">rather problematic theme competition</a>, last year, which encouraged people to build an entire theme to win a conference ticket (hello, unpaid spec work) and then articles like this coming about: I can feel my own trust being chipped away at. It also doesn’t help that Gatsby is built with React, so by proxy, has a direct link to Facebook, which for those who know me well, will know that’s almost immediately in impossible barrier to get beyond.</p><p>But as I said when I was <a href="https://shoptalkshow.com/episodes/394/">lucky to be on the Shop Talk Show</a>: Gatsby is not going anywhere and will only get more popular, so I want to try to be productive with criticisms, with the hope that in turn, they make a big, positive impact on the web.</p>
|
