A place to cache linked articles (think custom and personal wayback machine)
Vous ne pouvez pas sélectionner plus de 25 sujets Les noms de sujets doivent commencer par une lettre ou un nombre, peuvent contenir des tirets ('-') et peuvent comporter jusqu'à 35 caractères.

index.html 13KB

  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,minimum-scale=1,initial-scale=1,shrink-to-fit=no">
  11. <!-- Required to make a valid HTML5 document. -->
  12. <title>Thinking about the past, present, and future of web development (archive) — David Larlet</title>
  13. <!-- Lightest blank gif, avoids an extra query to the server. -->
  14. <link rel="icon" href="data:;base64,iVBORw0KGgo=">
  15. <!-- Thank you Florens! -->
  16. <link rel="stylesheet" href="/static/david/css/style_2020-01-06.css">
  17. <!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
  18. <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" crossorigin>
  19. <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" crossorigin>
  20. <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" crossorigin>
  21. <meta name="robots" content="noindex, nofollow">
  22. <meta content="origin-when-cross-origin" name="referrer">
  23. <!-- Canonical URL for SEO purposes -->
  24. <link rel="canonical" href="https://www.baldurbjarnason.com/past-present-future-web/">
  25. <body class="remarkdown h1-underline h2-underline hr-center ul-star pre-tick">
  26. <article>
  27. <h1>Thinking about the past, present, and future of web development</h1>
  28. <h2><a href="https://www.baldurbjarnason.com/past-present-future-web/">Source originale du contenu</a></h2>
  29. <p class="decking">You're supposed to talk about the past, present, and future in the new year, right?</p>
  30. <p>Here is a disconnected, rambling list of thoughts spurred by reviewing the passing year.</p>
  31. <ul>
  32. <li><p>Charitable or social benefit startups are screwed up in a special kind of way. Most of them target a specific industry from the outset—hoping to fix it in some way, even though the reasons for systemic dysfunction tend to be, well… systemic and not something a startup or charity can fix.</p></li>
  33. <li><p>Organisations of this kind—like Rebus, my employer—are effectively prevented from using the most powerful tool available to entrepreneurs: picking your market based on research; guided by what you know to be your organisation’s strengths and capabilities. We’ve already picked our market; we’ve already picked our tools; and building a sustainable business <strong>without</strong> the ability to revisit those choices is an enormous handicap.</p></li>
  34. <li><p>That handicap increases our dependance on grants and outside financing, which in turn makes us—and every organisation like us—dependent on the whims, agendas, and politics of America’s wealthiest. And that class is <em>never</em> interested in addressing systemic issues: they always choosing to patch up the cracks with ‘innovative’ software or ‘disruptive’ business models.</p></li>
  35. <li><p>Any sensible business that chose its focus based on what <em>sustainable</em> good they could do, would likely leave the education industry proper.</p></li>
  36. <li><p>The education industry is kind of screwed no matter what happens. Their options for tech and software are: idealists burning money on ideas that will never be sustainable, greybeards raking in money for maintaining clunky, outdated, legacy tech, sociopaths looking to extract value from the system (stripmining) through ‘innovation’ and ‘disruption’, or entrepreneurs seeking to ‘fix’ education by establishing monopoly dominance over some vital cornerstone that everybody relies on (because they know better than everybody else).</p></li>
  37. <li><p>That the fastest path to sustainability for an education startup is often to stop being an education startup tells us something. Not sure what, but it’s definitely telling us something.</p></li>
  38. <li><p>The web developer community, in social media at least, seems to have hit a transition point last year. Most of it has become full of intolerable nonsense where the plans and ideas of an advertising company (and its employees) dominate the social media discourse. The discourse itself has completely ceased to reflect what most people are actually doing, both end users and web developers.</p></li>
  39. <li><p>Once you step outside of the social media bubble, however, vanilla JS and more ‘modest’ approaches like Svelte or Stimulus/TurboLinks seem to have reached critical mass in terms of sustainability. Irrespective of those newer trends, jQuery and PHP-driven, un-hydrated, old-fashioned server-side rendering still utterly dominate the web that people use.</p></li>
  40. <li><p>Web dev driven by npm packages, frameworks, and bundling is to the field of web design what Java and C# in 2010s was to web servers. If you work in enterprise software it’s all you can see. Web developers working on CMS themes (or on Rails-based projects) using jQuery and plain old JS—maybe with a couple of libraries imported directly via a script tag—are the unseen dark matter of the web dev community.</p></li>
  41. <li><p>What should worry you is that npm- and framework-driven web development <em>feels</em> just as painful as enterprise software dev because it <em>is</em> enterprise development.</p>
  42. <ul>
  43. <li>TypeScript smells like Java.</li>
  44. <li>The complexity of npm packages harkens back to painful Java packaging monstrosities.</li>
  45. <li>JavaScript build systems are about as much fun as Java build systems, even though they are doing very different things.</li>
  46. <li>Deployment, as implemented in the Kubernetes and Docker ecosystems, is exactly as hard to understand and use as its Java predecessors because those <em>are</em> their predecessors.</li>
  47. </ul></li>
  48. <li><p>Some of use work exclusively with SMBs (Small-/Medium-sized Businesses) and shouldn’t need to run the enterprise anti-productivity gauntlet. Our needs in terms of frameworks, bundling, and packages are very different from those working in enterprises with hundreds or thousands of employees.</p></li>
  49. <li><p>It is not rational to expect us to be using enterprise-oriented tools and environments or to demand that we be happy about being saddled with your need for complexity.</p></li>
  50. <li><p>The divide between what you read in developer social media and what you see on web dev websites, blogs, and actual practice has never in my recollection been this wide. I’ve never before seen web dev social media and forum discourse so dominated by the US west coast enterprise tech company bubble, and I’ve been doing this for a couple of decades now. The pre-2000 dot-com bubble comes close although that one came attached to an actual financial bubble and happened before social media had evolved into its current form.</p></li>
  51. <li><p>I’m more and more leaning towards the idea that the future of digital publishing is the web.</p></li>
  52. <li><p>As much as people keep harping on the death of the web, it has matured enormously as a medium and is at a point now were a massive flowering of artistic and creative expression is possible.</p></li>
  53. <li><p>Whether that bloom happens or not is no longer a question of technological capacity but of social and cultural factors that are hard to predict or anticipate. (This wasn’t, in my opinion, a realistic possibility even as recently as a couple of years go.)</p></li>
  54. <li><p>Most of the criticisms web developers throw at Safari concern its usefulness as an <strong>app platform</strong> while the browser itself has become fully-featured and powerful as a medium for design and storytelling.</p></li>
  55. <li><p>This means that ebooks will fall further and further behind and continue to be limited to being a modern replacement of the mass market paperback, with largely the same design limitations.</p></li>
  56. <li><p>This creative expression might be distributed as web sites, apps, web apps, web publications, packages, or all of the above. I don’t know how it will pan out.</p></li>
  57. <li><p>All current modes of digital distribution are unsustainable and are likely to change over the coming ten years.</p>
  58. <ul>
  59. <li>App stores don’t scale and can’t reflect cultural and social variation. We do not have a unified global culture and never will.</li>
  60. <li>The web is being hit hard by the world’s swing towards authoritarianism.</li>
  61. <li>On the other end, it’s also being strip-mined by unregulated and uncontrolled tech companies—most of the ballooning download sizes and biggest performance monstrosities are entirely down to advertising and privacy-violating tracking.</li>
  62. <li>Many of these things are coming under increased government scrutiny for both sensible (anti-trust, pro-competition) and for scary (authoritarianism, nationalism) reasons.</li>
  63. <li>Some of these things will swing back. Some of them won’t. We can’t tell which way things will go from our current vantage point. We’ll have to wait and see as most of these changes are taking place at such a high level that it’s well beyond the ability of any one of us to meaningfully affect. But it’s safe to say that things will change.</li>
  64. </ul></li>
  65. <li><p>If you’re personally invested in the dominance of the browser over all other forms of digital media (<strong>cough</strong><em>Google</em><strong>cough</strong>) then the uncertainty regarding distribution is likely to terrify you.</p></li>
  66. <li><p>But the rest of us will probably (hopefully?) be able to adapt to whatever happens. However it gets packaged and distributed, it’ll either be made using some variation of HTML, HTTP, CSS, and JS or something substantially better (like a mature SwiftUI).</p></li>
  67. <li><p>I’m excited about the web as a creative and narrative medium—we might be in for great things in that regard. I’m less excited about the web as an app platform because, from a purely utilitarian perspective, most productivity apps should be native apps. A native app platform is capable of providing much greater privacy assurances without compromising functionality than the web ever can.</p></li>
  68. <li><p>Conversely, a native app platform that has been captured by an advertising company, like Android has, is much much worse for privacy than the web will ever be. At least on the web you can usually add content and privacy blockers. That said, even on Android, you can still go against the grain of the platform and create a client-side only app that is more powerful and more <strong>private</strong> than anything the web can realistically offer.</p></li>
  69. <li><p>Native Mac, Windows, or even Desktop Linux apps (whether they’re Electron-based or ‘proper’ native) are still unbeatable when it comes to delivering a pragmatic balance of productivity, privacy, and value.</p></li>
  70. <li><p>I have a hunch that as Chrome’s dominance over the web increases, the web’s association with Android and Google will strengthen in people’s minds. The web on other platforms like iOS and Windows will be seen by end users as a ‘Google compatibility thing’ instead of an independent and open platform. Whether that perception will be a correct one is an entirely different thing.</p></li>
  71. <li><p>I have very complicated and conflicted feelings about all of the things in tech and education that are labelled ‘open’. Too often its a label used to manipulate people into working for free, or as cover for extracting profit from community effort. Communities dedicated to ‘open’ causes all too easily veer into manipulation and abuse while <em>still</em> funnelling most of the value into the hands of the few.</p></li>
  72. <li><p>In other words: ‘open’ is a labour management strategy; not a wealth redistribution strategy</p></li>
  73. <li><p>Most mature open platforms are dominated by a profit-taking enterprise of some sort, for example the web is dominated by Google and Amazon. Whenever you do anything to strengthen the web as a platform, the majority of the value and benefit will end up in their pockets, no matter what you do. If the buck stops on the web, it stops at either Google or Amazon.</p></li>
  74. <li><p>Most of the time, when a system is truly open, it’s open to being taken over by the powerful and the rich. The rest of us will never have the resources to protect the commons so any time the playing field is even, the rich will win.</p></li>
  75. <li><p>The Free Software movement distinguishes itself a bit from the rest of the ‘open’ crowd in that they do care about, and take steps to protect, developer freedoms.</p></li>
  76. <li><p>They still throw the non-coding end user under the bus <strong>by design</strong>. Implicit in their manifestos is the idea that you are only free if you code.</p></li>
  77. <li><p>The US and UK are screwed. <strong><em>So</em></strong> screwed.</p></li>
  78. </ul>
  79. </article>
  80. <hr>
  81. <nav>
  82. <a href="/david/" title="Aller à l’accueil">🏠</a> •
  83. <a href="/david/log/" title="Accès au flux RSS">🤖</a> •
  84. <a href="http://larlet.com" title="Go to my English profile">🇨🇦</a> •
  85. <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">📮</a> •
  86. <abbr title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340">🧚</abbr>
  87. </nav>
  88. </body>
  89. </html>