A place to cache linked articles (think custom and personal wayback machine)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

index.html 11KB

  1. <!doctype html><!-- This is a valid HTML5 document. -->
  2. <!-- Screen readers, SEO, extensions and so on. -->
  3. <html lang="fr">
  4. <!-- Has to be within the first 1024 bytes, hence before the <title>
  5. See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
  6. <meta charset="utf-8">
  7. <!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
  8. <!-- The viewport meta is quite crowded and we are responsible for that.
  9. See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
  10. <meta name="viewport" content="width=device-width,initial-scale=1">
  11. <!-- Required to make a valid HTML5 document. -->
  12. <title>Honesty is the best policy (archive) — David Larlet</title>
  13. <!-- Generated from https://realfavicongenerator.net/ such a mess. -->
  14. <link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png">
  15. <link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png">
  16. <link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png">
  17. <link rel="manifest" href="/static/david/icons2/site.webmanifest">
  18. <link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c">
  19. <link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
  20. <meta name="msapplication-TileColor" content="#f0f0ea">
  21. <meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml">
  22. <meta name="theme-color" content="#f0f0ea">
  23. <!-- Documented, feel free to shoot an email. -->
  24. <link rel="stylesheet" href="/static/david/css/style_2020-04-25.css">
  25. <!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
  26. <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light)" crossorigin>
  27. <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light)" crossorigin>
  28. <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light)" crossorigin>
  29. <link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
  30. <link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
  31. <link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin>
  32. <meta name="robots" content="noindex, nofollow">
  33. <meta content="origin-when-cross-origin" name="referrer">
  34. <!-- Canonical URL for SEO purposes -->
  35. <link rel="canonical" href="https://hankchizljaw.com/wrote/honesty-is-the-best-policy/">
  36. <body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick">
  37. <article>
  38. <h1>Honesty is the best policy</h1>
  39. <h2><a href="https://hankchizljaw.com/wrote/honesty-is-the-best-policy/">Source originale du contenu</a></h2>
  40. <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>
  41. <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>&lt;h1&gt;</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></p>
  42. </article>
  43. <hr>
  44. <footer>
  45. <p>
  46. <a href="/david/" title="Aller à l’accueil">🏠</a> •
  47. <a href="/david/log/" title="Accès au flux RSS">🤖</a> •
  48. <a href="http://larlet.com" title="Go to my English profile" data-instant>🇨🇦</a> •
  49. <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">📮</a> •
  50. <abbr title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340">🧚</abbr>
  51. </p>
  52. </footer>
  53. <script src="/static/david/js/instantpage-3.0.0.min.js" type="module" defer></script>
  54. </body>
  55. </html>