For years, advocates for web standards, performance, and accessibility have implored web developers to “use the platform”. I’ve often been one of those…
Firstly, #usetheplatform is regarded as false a premise by many, because the “platform” they talk about is 90% controlled by Google and their most recent motivations, and usually “Works best in Google Chrome™” until their competitors are bullied into implementing those features as well.
As a “React developer” I personally enjoy working at a higher abstraction level while building web UIs, and dropping down to the imperative browser APIs causes me to do a mental gear change. I would never want to mix this with business code, and containing it to a reusable component in the end looks the same as pulling a dependency from npm with much better testing and coverage, if I can find one.
I think the IKEA effect can be reversed as well. If you can use something from npm, building it yourself instead is kind of fun and challenging. There are many npm packages that only exist to wrap a non-ergonomic browser API to adapt it to the React world. And I’ve seen many junior engineers (and agents) make the mistake of never bothering to check if this was already packaged on npm and roll their own version of it.
React vs browser APIs being in different abstraction levels may not be obvious to everyone, so let me elaborate a bit further. React–and most of its modern alternatives–let me write and compose components declaratively, and you pass things directly using variables and import/exports. Web components, the cited platform alternative to React and its ilk, use string references as component names, and pollute a global namespace. That’s just the tip of the iceberg for me for never even considering web components.
To set the record straight, even though the platform is controlled by an evil company, most of it is still great. I get excited by code that I get to delete thanks to the new browser feature! And I usually consider non-ergonomic web APIs as a compile target anyway and write my code at a higher abstraction level. I find npm to be a treasure trove if you know how to navigate it, but it’s still useful to take a few minutes to see how your dependencies work under the hood.
#usetheplatform hashtag tries to make this picture black and white. There are horrendous web APIs that I wouldn’t touch with a ten foot pole, but I still use web APIs directly or indirectly, and I see it as my responsibility to keep up with the additions to see how I can make my code easier to maintain, more performant, and more accessible.
I think it’s a fair point that “use the platform” originally came out of Chrome DevRel (at least, that’s where I first heard it). But I can’t recall any other browser vendors taking exception with it, and I imagine that the non-Google engineers working at the CSS Working Group would be delighted if more web devs used their stuff!
One of the reasons I didn’t get into web components is that they’re a very touchy subject and not an obvious slam-dunk win like “replace 100 lines of JS with 1 line of CSS.” Also keep in mind that nobody (or very few) people in the web components space ever expected web components to replace frameworks entirely – there’s a reason that Lit, Fast, LWC, etc. are built on top of web components. So some of the “use the platform” marketing there was directed at framework authors themselves (React, Solid, Svelte, etc.), who I think had very reasonable gripes with the limitations of web components (SSR, accessibility, etc.). Anyway I had twoentire posts on the topic, so no need to rehash it here. 😆
Until recently, I thought web components looked kinda cool, but were also impractical for real work because of the requirement to use javascript. The benefits they bring can mostly be done other ways too… like I have server side expansions around, can use delegated event handlers in the dhtml case, etc. What convinced me to finally try it again was a blog post (i don’t think from you but possible) here on lobsters that said use it without the shadow dom as a progressive enhancement hook.
I just started playing with that on Friday and I’m already really happy with it - keep the server side expansion, then implement the same thing in javascript as well (both based on just three substitution rules from a template, my impl was about 100 lines in both D and Javascript), and put a little framework around concatenating stylesheets using the relatively new nesting stuff in css and… it is coming out really nice and I’m not sacrificing the nojs users. And actually, it enhances a bit even for them, because it makes the noscript bit a little easier to support - putting all the script-required bits in the attach element thing and allowing some <noscript> bits in my template does a nice bit of encapsulation.
Like I said, only started playing on Friday, so too premature to delcare Mission Accomplished but I am really happy with it so far. I might even actually use the shadow dom sometimes now lol
As a user, I utterly despise react as the reason why every indivifual browser tab these days takes 20 seconds to load and hydrate, and then eats up good half a gig of memory while providing absolutely no value over a plain server-side-rendered html page.
That is no value. A web server that can render JSON can also render HTML. And if one builds a static JS website that needs no API to work it can also be static HTML instead. There is simply no HTML that is expensive to render on a web server, ever, a web server will never reach CPU load capacity off of rendering HTML.
Oh boy I have a lot of thoughts about this.
Firstly, #usetheplatform is regarded as false a premise by many, because the “platform” they talk about is 90% controlled by Google and their most recent motivations, and usually “Works best in Google Chrome™” until their competitors are bullied into implementing those features as well.
As a “React developer” I personally enjoy working at a higher abstraction level while building web UIs, and dropping down to the imperative browser APIs causes me to do a mental gear change. I would never want to mix this with business code, and containing it to a reusable component in the end looks the same as pulling a dependency from npm with much better testing and coverage, if I can find one.
I think the IKEA effect can be reversed as well. If you can use something from npm, building it yourself instead is kind of fun and challenging. There are many npm packages that only exist to wrap a non-ergonomic browser API to adapt it to the React world. And I’ve seen many junior engineers (and agents) make the mistake of never bothering to check if this was already packaged on npm and roll their own version of it.
React vs browser APIs being in different abstraction levels may not be obvious to everyone, so let me elaborate a bit further. React–and most of its modern alternatives–let me write and compose components declaratively, and you pass things directly using variables and import/exports. Web components, the cited platform alternative to React and its ilk, use string references as component names, and pollute a global namespace. That’s just the tip of the iceberg for me for never even considering web components.
To set the record straight, even though the platform is controlled by an evil company, most of it is still great. I get excited by code that I get to delete thanks to the new browser feature! And I usually consider non-ergonomic web APIs as a compile target anyway and write my code at a higher abstraction level. I find npm to be a treasure trove if you know how to navigate it, but it’s still useful to take a few minutes to see how your dependencies work under the hood.
#usetheplatform hashtag tries to make this picture black and white. There are horrendous web APIs that I wouldn’t touch with a ten foot pole, but I still use web APIs directly or indirectly, and I see it as my responsibility to keep up with the additions to see how I can make my code easier to maintain, more performant, and more accessible.
score 1 · canonical
I think it’s a fair point that “use the platform” originally came out of Chrome DevRel (at least, that’s where I first heard it). But I can’t recall any other browser vendors taking exception with it, and I imagine that the non-Google engineers working at the CSS Working Group would be delighted if more web devs used their stuff!
One of the reasons I didn’t get into web components is that they’re a very touchy subject and not an obvious slam-dunk win like “replace 100 lines of JS with 1 line of CSS.” Also keep in mind that nobody (or very few) people in the web components space ever expected web components to replace frameworks entirely – there’s a reason that Lit, Fast, LWC, etc. are built on top of web components. So some of the “use the platform” marketing there was directed at framework authors themselves (React, Solid, Svelte, etc.), who I think had very reasonable gripes with the limitations of web components (SSR, accessibility, etc.). Anyway I had two entire posts on the topic, so no need to rehash it here. 😆
score 1 · canonical
Until recently, I thought web components looked kinda cool, but were also impractical for real work because of the requirement to use javascript. The benefits they bring can mostly be done other ways too… like I have server side expansions around, can use delegated event handlers in the dhtml case, etc. What convinced me to finally try it again was a blog post (i don’t think from you but possible) here on lobsters that said use it without the shadow dom as a progressive enhancement hook.
I just started playing with that on Friday and I’m already really happy with it - keep the server side expansion, then implement the same thing in javascript as well (both based on just three substitution rules from a template, my impl was about 100 lines in both D and Javascript), and put a little framework around concatenating stylesheets using the relatively new nesting stuff in css and… it is coming out really nice and I’m not sacrificing the nojs users. And actually, it enhances a bit even for them, because it makes the noscript bit a little easier to support - putting all the script-required bits in the attach element thing and allowing some
<noscript>bits in my template does a nice bit of encapsulation.Like I said, only started playing on Friday, so too premature to delcare Mission Accomplished but I am really happy with it so far. I might even actually use the shadow dom sometimes now lol
score 1 · canonical
As a user, I utterly despise react as the reason why every indivifual browser tab these days takes 20 seconds to load and hydrate, and then eats up good half a gig of memory while providing absolutely no value over a plain server-side-rendered html page.
score 3 · canonical
Alas, the “value” is in pushing the HTML rendering expense onto the client so that you don’t have to buy servers to render the HTML.
score 1 · canonical
That is no value. A web server that can render JSON can also render HTML. And if one builds a static JS website that needs no API to work it can also be static HTML instead. There is simply no HTML that is expensive to render on a web server, ever, a web server will never reach CPU load capacity off of rendering HTML.
score 1 · canonical