johan-hal-se-sgfcqg.txt (8210B)
1 • [1]Johan Halse 2 • [2]Blog 3 • [3]Mastodon 4 • [4]GitHub 5 • [5]LinkedIn 6 7 [avatar] 8 Johan wrote this 9 @ 2024-03-05 10 11 Churn 12 13 I’ve been using Web Components lately. I quite like them. 14 15 I wouldn’t call myself a heavy user, or power user, or whatever. It seems like 16 every other article I read has things to say about the Shadow DOM, declarative 17 or otherwise, or maybe about slots. These things seem divisive, but I don’t 18 have an opinion because I’m not using any of them. My experience is limited to 19 my patience and coping strategies finally having failed with regard to [6] 20 Hotwire being absolutely mahoosive (132kB minified! WHAT!!) which lead to me 21 writing my own Stimulus replacement called [7]Musculus. It uses the Web 22 Component lifecycle hooks, and basically nothing else. Those are an absolute 23 godsend, though! Before they came along, we had to build our own awkward 24 lifecycle handler (probably via MutationObserver) and that came with a lot of 25 plumbing and performance gotchas, whereas WC lifecycles are crazy simple: you 26 register the component with customElements.define and it’s off to the races. 27 Just write a class and the browser will take care of elements appearing and 28 disappearing for you, regardless of whether they came from a full reload, a 29 fetch request, or—god forbid—a document.write. The syntax looks great in 30 markup, too: no more having to decorate with js-something classes or data 31 attributes, you just wrap your shit in a custom element called 32 something-controller and everyone can see what you’re up to. Since I’m firmly 33 in camp “progressively enhance or go home” this fits me like a glove, and I 34 also have great hopes for Web Components improving the poor state of pulling in 35 epic dependencies like date pickers or text editors. 36 37 Felling the beasts 38 39 I won’t pretend to have an answer to how they would replace React and its 40 intellectual brethren, though. I stand by my belief that [8]ninety-five percent 41 or so of us will be absolutely fine without ever having to pull reactivity or 42 two-way binding into our sites. That doesn’t stop others from trying to tear 43 down the current world order, of course! I’ve seen a bunch of speculation and 44 heated discussion as to what Web Components would need in order to oust the 45 current breed of component libraries, mostly in service of reducing your 46 dependence on the tiresome and ever-churning world of JavaScript frameworks. 47 Build your site with Web Components, it’s said, and you’ll have offloaded the 48 Sisyphean task of staying on top of updates and version bumps to evergreen 49 browsers! Since this is the web, where we’re VERY SERIOUS about backwards 50 compatibility (you can still use document.all if you like—it’s a bad idea, but 51 you be the boss) you can let the Chrome team shoulder some of your burden and 52 you’ll never again be stuck in the purgatory of having to rewrite your code to 53 use Hooks or Signals or Runes or whatever we’re doing this year. 54 55 I don’t really buy it, though! 56 57 Anyone who wants to has been able to go it alone and build library-less for 58 many years. It’s what everyone started out doing, after all. And that usually 59 leads to what’s colloquially known as [9]Big Ball of Mud architecture. The 60 browser APIs are cool and all, but they’re a motley collection of weird 61 imperative operations: a few decades’ worth of functions and properties that 62 people figured would be useful, and then some paved-cowpath convenience stuff 63 layered on top. The APIs work, it’s hard to argue otherwise, but they’ve never 64 been fun or even ergonomic to use. So we’ve had libraries papering over the 65 various cross-browser cracks and improving DX since… well, basically forever. 66 Staying close to the metal sounds like a good idea in theory but just doesn’t 67 shake out very well in practice. It comes with a whole lot of ceremony and 68 drudgery, something I touched on [10]a while back (how was that five years ago 69 already oh dang oh nuts my life slipping through my fingers like grains of sand 70 impossible to catch oh no whyyy) and any abstractions or DSLs you write are 71 likely going to be sub-par reimplementations of other peoples’ libraries. So 72 it’s usually a good idea to find a battle-tested library or framework that gels 73 with your style. 74 75 Money and fame 76 77 The main reason Web Components aren’t going to save you from the JS treadmill, 78 however, is that the JS treadmill is first and foremost a cultural product. 79 80 It’s easy to forget since the webdev world moves so quickly nowadays, but the 81 preferred mode of distribution for frontend JavaScript was “go download this 82 .js file from, like, SourceForge” well into the latter half of the 2010s. NPM 83 and Big Tech stewardship of open source changed all that. Suddenly you could 84 get a well-paid job and a form of rockstardom from releasing a popular library. 85 Gone were the days of “hey I’m Johan and I made a [11]tiny search engine, 86 download my file if you want” and instead we found ourselves in the days of 87 smarmy overpromising brochure sites and Twitter catfights about data mutability 88 or codes of conduct. That milieu rewards high-profile Architectural Thinking 89 and popularity contests, and so we’re stuck in a constant churn of new ideas 90 and one-upmanship. Look, library X implemented Y, we have to come up with an 91 answer!! 92 93 If you want a good example of what we could have had, look at jQuery. They’re 94 still out there, quietly releasing stuff that really doesn’t break anyone’s 95 builds. It’s a solid and unassuming library that does what it says it does. 96 What would’ve happened if React had just stayed with their class components? If 97 they didn’t keep uprooting their community with things like Hooks or Effects or 98 Reducers? They could’ve stayed on a steady beat of polishing a more-or-less 99 finished product, and let other libraries explore those other ideas. That would 100 probably have saved everyone a massive amount of rewriting, reskilling, and 101 [12]bugs. But the social context demanded otherwise, and that has infected 102 basically the entire ecosystem now. I would love it if Web Components could 103 change those dynamics, but I’m not holding my breath (although the current 104 epidemic of Big Tech layoffs is probably doing more to shake things up than any 105 browser standard could!) 106 107 I still hope the APIs can open up a new frontier of library-agnostic and easily 108 distributable components, maybe using some kind of middleware spec (similar to 109 Ruby’s [13]Rack) that doesn’t change very much over time? I really hope that 110 works out. But for now, I’m going to keep using the parts I enjoy using, and be 111 cautiously optimistic about the future. 112 113 I'm Johan Halse: web developer, feared duelist, renowned lover, compulsive 114 liar. I made this fat footer because that's how footers are supposed to look 115 these days! 116 117 While you're here, consider following me on [14]Mastodon. Am I always correct 118 on Mastodon? No. But am I always hilarious? Also no. But I'm angling for enough 119 followers to credibly call myself a "thought leader" and retire to a quiet life 120 of picking shameful public fights with JavaScript celebrities. 121 122 If Mastodon's not your jam, maybe star one of my [15]GitHub repos. It's really 123 the least you can do. 124 125 Also: if you found my technical writing interesting, you should know that I 126 founded a company called [16]Varvet many years ago and they're still going, so 127 give them a buzz if you want help with web stuff. 128 129 Copyright © Johan Halse 2024 130 131 132 References: 133 134 [1] https://johan.hal.se/ 135 [2] https://johan.hal.se/wrote 136 [3] https://ruby.social/@hejsna 137 [4] https://github.com/johanhalse 138 [5] https://www.linkedin.com/in/johan-halse 139 [6] https://hotwired.dev/ 140 [7] https://github.com/johanhalse/musculus 141 [8] https://johan.hal.se/wrote/2024/01/24/concatenating-text 142 [9] https://en.wikipedia.org/wiki/Anti-pattern#Software_engineering_anti-patterns 143 [10] https://web.archive.org/web/20230327144118/https://www.varvet.com/blog/the-importance-of-elegance/ 144 [11] https://github.com/johanhalse/pucko-search 145 [12] https://johan.hal.se/wrote/2024/02/28/care/ 146 [13] https://github.com/rack/rack/blob/main/SPEC.rdoc 147 [14] https://ruby.social/@hejsna 148 [15] https://github.com/johanhalse 149 [16] https://www.varvet.com/