Skip to content
DevMeme
5346 of 7590
Frameworks Post #5863 · source on Telegram

HTMX's Simplicity vs. React Server Components' Existential Complexity

Description

This is a two-panel comparison meme that contrasts the perceived simplicity of HTMX with the perceived complexity of React Server Components (RSC). The top panel, labeled 'HTMX,' uses a simple three-frame comic strip to illustrate its process: 1. 'Client sends an HTTP request,' 2. 'Server responds with HTML,' and 3. 'Client inserts the HTML response into the document.' The visuals are clean, with simple stick figures on a linear path. The bottom panel, labeled 'React Server Components,' is a chaotic, surreal, and densely packed illustration. It's filled with an overwhelming wall of text that begins, 'Now let me try to explain RSC:' and lists numerous, complex types of application state (ephemeral, local, persistent, server cache, etc.). The accompanying imagery is frantic, showing stick figures entangled in bizarre contraptions, being sprayed with water (labeled 'rendered DOM'), and driving a car, all meant to represent the convoluted nature of RSC's architecture. The meme humorously critiques RSC as being over-engineered and difficult to grasp, while positioning HTMX as a refreshingly straightforward alternative in the world of web development

Comments

36
Anonymous ★ Top Pick Explaining HTMX takes one sentence. Explaining React Server Components requires a ten-part blog series, a PhD in distributed systems, and a support group for the engineers who have to maintain it
  1. Anonymous ★ Top Pick

    Explaining HTMX takes one sentence. Explaining React Server Components requires a ten-part blog series, a PhD in distributed systems, and a support group for the engineers who have to maintain it

  2. Anonymous

    HTMX is basically cURL with a DOM patch, while RSC feels like you accidentally rebuilt CORBA in JSX just to toggle a CSS class

  3. Anonymous

    After 15 years of progressively enhancing JavaScript frameworks to handle server-side rendering, we've finally innovated our way back to... sending HTML over the wire. The only difference is now we need a PhD in distributed systems to understand the hydration boundaries

  4. Anonymous

    When your framework's explanation requires a PhD thesis and hand-drawn stick figures to convey the mounting existential dread, while the alternative is literally 'server sends HTML, browser shows it' - maybe we've overcomplicated the web. RSC advocates will spend 20 minutes explaining why their two-stage reduction with serialized component trees is actually simpler than a POST request, and honestly, watching them try is the real entertainment value here

  5. Anonymous

    HTMX ships markup; RSC ships markup after crossing a serialization boundary, streaming pipeline, hydration ritual, and two caches - because a button click shouldn’t happen until the architecture diagram does

  6. Anonymous

    HTMX: POST -> innerHTML; RSC: Flight payload -> streaming shell -> hydrate client boundaries -> debate cache ownership - all to render the same dropdown

  7. Anonymous

    HTMX: Server owns state, browser renders happy. React: State's an exercise left to the reader - client cache, server serializer, or dev's nightmares?

  8. @Araalith 2y

    Despite React being the front-end equivalent of PHP, and Redux being significantly worse, the first approach is only suitable for certain student tasks.

    1. @anatoli26 2y

      Use Dioxus instead - full stack in pure Rust for all 5 platforms

      1. @sylfn 2y

        and horribly wrong rendering in terminal and DOM reimplementation

    2. @TheUnstupidOne 2y

      I yearn to bring back the Web 2.0 times, when the best web designers could do were some fancy shapes and pastel colors, yet the websites only took a couple of seconds to load even on single core 6W Atom Z CPUs

      1. @Agent1378 2y

        One can still achieve it. Use vanilla JS (or with absolute minimum foreign libraries if needed), no JS framework of any kind. Use custom written clean HTML. And you're done!

        1. @TheUnstupidOne 2y

          see, you've perfectly described the issue nobody does that anymore

          1. @Johnny_bit 2y

            Billions of CPU cycles wasted on processing and rendering shite...

            1. @TheUnstupidOne 2y

              It's not even shite, it's just bad code written in unfairly popular (bc they have an absurdly low barrier of entry) frameworks, that haven't been refactored and optimized since initial public release some 5-10 years ago, and are themselves written in fucking Python in the best case scenario to begin with

              1. @Johnny_bit 2y

                I know a multiple cases of huge performance gains happening just from adding index to table... Damn active model... Add index and boom, suddenly queries are orders of magnitude faster. And docs & examples don't show nor tell would-be-devs that this shite ain't gonna optimize itself.

                1. @TheUnstupidOne 2y

                  I think, most if not all actually talented software/hardware engineers heavily suffer from teacher paradox syndrome. It's very easy to gloss over a very minor, but important thing, when explaining something you find extremely simple to somebody who doesn't understand the principle. And it's even hard to come up with a simple enough and understandable explaination in the first place. Using any kind of math makes things infinitely less understandable. And that's on top of the fact modern code monkeys don't get taught to think in algorithms. I'm a relatively inexperienced project manager (bachelors major in production plant management, minor in cellular biology, lmao) with some rudimentary C# skills that i use for personal applied automation, yet somehow i know more about how software works than like 90% of CS bachelor juniors coming in. What the actual fuck?

        2. @Araalith 2y

          And you will spend 3x-10x more time to achieve the same (or even worse) results, encountering countless bugs and lacking cross-platform/cross-browser compatibility. The days when everyone used only IE at a 1920x1080 resolution are long gone. For a school pet project, pure JavaScript will suffice. However, for anything more significant, you've already lost.

          1. @trainzman 2y

            Bro, don’t even start trying to defend js web-frameworks

            1. @Araalith 2y

              Oh, I'm not defending frameworks - they already create better-performing code than 99% of developers can with vanilla JS for any real project. Even if vanilla fans drop cross-browser and cross-platform support. It's like old "I'll code it in ASM."

              1. @trainzman 2y

                ”Honey, it’s time for your 40kb simple dropdown script loading” yeah, seems pretty better-performing

                1. @Araalith 2y

                  Sorry, I'm too busy doing another absolutely useless 64k asm demo.

          2. @Agent1378 2y

            Maybe 3x but not more. Supporting old shit is not needed anyway. And your misconception about IE as most used browser in fhd era only shows how young and inexperienced you really are 😉

            1. @Araalith 2y

              During 2000-2007, IE dominated the browser market with > 80% share and half of this time even > 90%, being the most advanced option available. While W3C was just beginning to discuss new standards, IE was already implementing these features.

              1. @Agent1378 2y

                https://gs.statcounter.com/screen-resolution-stats/desktop/worldwide/2010 I told you you have no idea about resolution used in IE era

                1. @Araalith 2y

                  But I agree that it was most likely 1024x768. I've already started to forget the exact details. The point was the dominance of one desktop resolution.

                  1. @Agent1378 2y

                    So what's the problem anyway? responsive design is easy. Css media queries are very cool, so what's the point?

      2. @CcxCZ 2y

        I'd rather have Web1.0, if that. Kthnxbye. https://drewdevault.com/2020/03/18/Reckless-limitless-scope.html

    3. @oljimenez 2y

      Nobody use Redux anymore

      1. @Araalith 2y

        GOD! I have faith! You've heard my prayers and cleansed the world of this scourge of absurdity! The previous ones were XML/XSLT. These two were able to reduce both server and client to mere rocks.

        1. @CcxCZ 2y

          TBF I would have preferred XHTML over what we got with HTML5. But that's a such low bar that it's detectable only with a scanning electron microscope.

  9. @sylfn 2y

    done

  10. @trainzman 2y

    I can understand Svelte or anything written not in javascript, because it at the very least TRIES to optimise what you’re doing

  11. @Johnny_bit 2y

    A good dev will be able to create very well performing stuff in pretty much everything. A bad dev, while kinda-sorta able to stick together something from copy-pasted examples and stack-overflow (and chatgpt) answers, won't be able to create anything without the nice framework :)

  12. @Johnny_bit 2y

    Also - in ye olde days, jquery was a godsend because have fun trying to do stuff cross-browser. Now, vanilla js is great because you can do everything pretty much on point. And yet jquery is still being used.

  13. @Agent1378 2y

    Exactly. I showed you the link where even in the 2010 the 1920x1080 is less than 5%. You can imagine that 3 years earlier it was even less.

Use J and K for navigation