6 ms·

This article started out interesting and then there were a series of baffling claims that... didn't quite make sense to me and feels like they are just trying t

by morcus 1y ago

This article started out interesting and then there were a series of baffling claims that... didn't quite make sense to me and feels like they are just trying to set up a straw man. 1. The author complains that React devs don't understand addEventListener when it is used and required reasonably often as far as I have seen? Also, "Again: the web had this. The browser’s event system is fast, flexible, and well-understood. But it wasn’t controlled enough for the FP ideal of a closed system." The stated purpose of the synthetic event system was to normalize differences in browser behavior back when React was created. It's not as necessary these days because browsers have gotten better, but saying it's about "FP Idealism" seems off. 2. The author complains about re-inventing the <dialog> element. This is valid, and new code should obviously use it. That said, it only became available across all major browsers in March of 2022, and still isn't supported by some minor browsers. All of the popular component libraries were made before that, and thus ought to keep their JS implementation for backwards compat. As far as tutorials, when I search "React dialog tutorial" the first result regrettably does show how to build your own, but the next two focus on using the built in element. 3. Then the author turns to customized select, and complains that JS frameworks don't support them. This would be valid but the very MDN article they link literally starts with: > This article explains how to create fully-customized <select> elements using *experimental browser features* (emphasis mine)

reactordev 1y ago
I can see from a new developer point of view, their frustration. Why aren’t things standard? Why not use builtin tags? Why this or that? Valid questions we should all be asking. Sometimes, just because “that’s the way it was” doesn’t mean that’s the way it should be. Often times I find myself deleting code that is now more readily available as either part of the platform I’m on or part of the framework I’m using. Your points are valid too, that they don’t know about the history that got us here and why it is the way it is but nevertheless we should all be asking ourselves daily, “do we still need this?” and trim the fat.
- totallykvothe 1y ago
  That's not what the article was about though. It wasn't only a complaint about not using built in niceties of the platform. It was an assertion that the reason we aren't is because of some kind of functional bro boogeyman.
fleebee 1y ago
> That said, it only because available across all major browsers in March of 2022, and still isn't supported by some minor browsers. `<dialog>` only got full compatibility with Firefox about two months ago with Firefox 141. Safari still doesn't support `closedby`. Given that, I still regard `<dialog>` as experimental, and that'll remain the case as long as the "Baseline Widely available" label comes with an asterisk.
hungryhobbit 1y ago
It only became obvious at the end that the whole (WAY too long) article was just a giant troll to promote the author's personal pet technology (HTMLX). But it was a highly disingenuous one, because (as the poster above noted) it was giant straw man, not a legit critique. I felt cheated just by having read the article: I'm all for a long and winding article that has something to say, but this one was telling a bad joke for WAY, WAY too many paragraphs.
- rs186 1y ago
  The article does not go into the disadvantages of server-side rendering (or more specifically, fetching html from server). I am sure the author is well aware of the choice between client- and server-side rendering but skipped it and seems to present technology like htmlx as “solutions" to all the problems the article mentioned which is quite a stretch.
librasteve 1y ago
I spent the whole time thinking "yeah, we need HTMX" - took a long time to get there eventually.
troupo 1y ago
> That said, it only became available across all major browsers in March of 2022, and still isn't supported by some minor browsers. And the only reason it suddenly reappeared in 2022 was because browsers want to get rid of alert/prompt dialogs. The spec was (and probably still is) so riddled with issues that it never went anywhere for 10 or so years, and Chrome at one point argued it should be removed. > This would be valid but the very MDN article they link literally starts with People involved with HTMX play really fast and lose with anything that doesn't fit their conclusions hoping no one will call them out.
- recursivedoubts 1y ago
  > People involved with HTMX play really fast and lose with anything that doesn't fit their conclusions hoping no one will call them out. Do we? https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/#on-the-other-hand https://htmx.org/essays/#on-the-other-hand https://htmx.org/essays/alternatives/ https://htmx.org/essays/alternatives/ Do other libraries talk as much about when they are and when they aren't appropriate to use? Do they link to alternatives? Do they link to bad experiences with their own software?
  - troupo 1y ago
    > Do we? > https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ Yea, yes you do. Hypermedia is a great example. Your conclusion is "HTML is the only true hypermedia". So all the facts that don't fit your narrative get ignored or twisted: https://dmitriid.com/hypermedia-is-a-property-of-the-client https://dmitriid.com/hypermedia-is-a-property-of-the-client Edit Even the links to "When you should use hypermedia" and "Alternatives" you provided literally work backwards from that predefined conclusion, and there's no time in the world to go through each of them to dissect them, but the post I linked to should provide enough context
    - recursivedoubts 1y ago
      "HTML is the only true hypermedia" would be a funny conclusion for me to come to when i included another hypermedia, hyperview, in the book that I wrote on hypermedia: https://hypermedia.systems/hyperview-a-mobile-hypermedia/ https://hypermedia.systems/hyperview-a-mobile-hypermedia/ agree w/you to an extent regarding the importance of the client in a hypermedia systems: https://htmx.org/essays/hypermedia-clients/ https://htmx.org/essays/hypermedia-clients/ EDIT: did you take this statement on twitter seriously: "yes, I believe HTML is the Only True Hypermvedia"? I was being sarcastic (making the same point I made above) so maybe this is a language issue? I'll read your blog and respond in a bit...

by morcus 1y ago

reactordev 1y ago

I can see from a new developer point of view, their frustration. Why aren’t things standard? Why not use builtin tags? Why this or that? Valid questions we should all be asking. Sometimes, just because “that’s the way it was” doesn’t mean that’s the way it should be. Often times I find myself deleting code that is now more readily available as either part of the platform I’m on or part of the framework I’m using. Your points are valid too, that they don’t know about the history that got us here and why it is the way it is but nevertheless we should all be asking ourselves daily, “do we still need this?” and trim the fat.

totallykvothe 1y ago
That's not what the article was about though. It wasn't only a complaint about not using built in niceties of the platform. It was an assertion that the reason we aren't is because of some kind of functional bro boogeyman.

fleebee 1y ago

> That said, it only because available across all major browsers in March of 2022, and still isn't supported by some minor browsers. `<dialog>` only got full compatibility with Firefox about two months ago with Firefox 141. Safari still doesn't support `closedby`. Given that, I still regard `<dialog>` as experimental, and that'll remain the case as long as the "Baseline Widely available" label comes with an asterisk.

hungryhobbit 1y ago

It only became obvious at the end that the whole (WAY too long) article was just a giant troll to promote the author's personal pet technology (HTMLX). But it was a highly disingenuous one, because (as the poster above noted) it was giant straw man, not a legit critique. I felt cheated just by having read the article: I'm all for a long and winding article that has something to say, but this one was telling a bad joke for WAY, WAY too many paragraphs.

rs186 1y ago
The article does not go into the disadvantages of server-side rendering (or more specifically, fetching html from server). I am sure the author is well aware of the choice between client- and server-side rendering but skipped it and seems to present technology like htmlx as “solutions" to all the problems the article mentioned which is quite a stretch.

librasteve 1y ago

I spent the whole time thinking "yeah, we need HTMX" - took a long time to get there eventually.

troupo 1y ago

> That said, it only became available across all major browsers in March of 2022, and still isn't supported by some minor browsers. And the only reason it suddenly reappeared in 2022 was because browsers want to get rid of alert/prompt dialogs. The spec was (and probably still is) so riddled with issues that it never went anywhere for 10 or so years, and Chrome at one point argued it should be removed. > This would be valid but the very MDN article they link literally starts with People involved with HTMX play really fast and lose with anything that doesn't fit their conclusions hoping no one will call them out.

recursivedoubts 1y ago
> People involved with HTMX play really fast and lose with anything that doesn't fit their conclusions hoping no one will call them out. Do we? https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/#on-the-other-hand https://htmx.org/essays/#on-the-other-hand https://htmx.org/essays/alternatives/ https://htmx.org/essays/alternatives/ Do other libraries talk as much about when they are and when they aren't appropriate to use? Do they link to alternatives? Do they link to bad experiences with their own software?
- troupo 1y ago
  > Do we? > https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ Yea, yes you do. Hypermedia is a great example. Your conclusion is "HTML is the only true hypermedia". So all the facts that don't fit your narrative get ignored or twisted: https://dmitriid.com/hypermedia-is-a-property-of-the-client https://dmitriid.com/hypermedia-is-a-property-of-the-client Edit Even the links to "When you should use hypermedia" and "Alternatives" you provided literally work backwards from that predefined conclusion, and there's no time in the world to go through each of them to dissect them, but the post I linked to should provide enough context
  - recursivedoubts 1y ago
    "HTML is the only true hypermedia" would be a funny conclusion for me to come to when i included another hypermedia, hyperview, in the book that I wrote on hypermedia: https://hypermedia.systems/hyperview-a-mobile-hypermedia/ https://hypermedia.systems/hyperview-a-mobile-hypermedia/ agree w/you to an extent regarding the importance of the client in a hypermedia systems: https://htmx.org/essays/hypermedia-clients/ https://htmx.org/essays/hypermedia-clients/ EDIT: did you take this statement on twitter seriously: "yes, I believe HTML is the Only True Hypermvedia"? I was being sarcastic (making the same point I made above) so maybe this is a language issue? I'll read your blog and respond in a bit...