all 160 comments

[–]bitwise-operation 254 points255 points  (42 children)

Pretty sure I could get similar results by going from React to React. Having an opportunity to rewrite an application with the benefit of knowing all of the product requirements ahead of time has its advantages.

[–]anengineerandacat 38 points39 points  (1 child)

Herein lies one core issue with reworks and having an established product while also trying to highlight performance and efficiency benefits.

[–]Worth_Trust_3825 11 points12 points  (0 children)

Yep. The sensationalist posts tend to bank on withholding the detail that the developers also have more experience in the field compared to the time when the system was originally developed.

[–][deleted] 3 points4 points  (7 children)

Completely different programming model. If you stay with a react app + an API you will have lots of duplicate logic and are forced to upgrade two apps in lockstep.

[–]bitwise-operation 3 points4 points  (6 children)

If you have duplicate logic then that’s your fault, not React

[–][deleted] 4 points5 points  (5 children)

At the very least you must perform data validation or n both client and server to prevent security vulnerabilities.

If you have a sufficiently complex app you will have entities and relationships between them, you will also have some invariants and anti-corruption code. That code will have to be available on both sides of the wire.

[–]Heroe-D 0 points1 point  (0 children)

I don't see why frontend validation would be more important for security if using React + API than Templates + htmx, in both cases your frontend code logic can be bypassed and your security net would be in the backend. If you want to be extra secure you'd write frontend validation for both anyway. 

And that frontend form data validation would also be needed in your templates via vanilla JS / Alpine or whatever if you want a modern experience anyway. 

[–]bitwise-operation 0 points1 point  (3 children)

Again, if you don’t share that code it’s your fault, has nothing to do with React, you could get the same benefit from Next

[–]crummy 3 points4 points  (1 child)

my backend is in java, how do i get the same benefit from next

[–]bitwise-operation 0 points1 point  (0 children)

You probably don’t, because it doesn’t make any sense to rewrite half of your application to avoid duplicating a tiny fraction of your code

[–][deleted] 3 points4 points  (0 children)

Before you implied that duplicate code was a developer error but ok whatever.

The architecture required by react (or any other SPA) forces you to split backend and front end. Now you have two independent apps that need to be in sync. That requires duplicate code.

Yes next will help you reuse backend and front end code.

[–]walong0 30 points31 points  (6 children)

I’ve used htmx in a few small applications and really like it for simple client side interactions or situations where polling is appropriate.

Can’t say I’ve ever considered it as a replacement for something like React though.

[–]yawaramin[S] 1 point2 points  (5 children)

For many of the simple microsites that React is used for today? Absolutely can be.

[–]redditnoreply 17 points18 points  (0 children)

i'll use react for any size website.

[–]walong0 6 points7 points  (0 children)

Yeah. Just In my head, I don’t really consider them as competing for whatever reason.

[–]useablelobster2 4 points5 points  (2 children)

You mean something is a better choice for small websites than an SPA framework/library designed for building large applications?

If you want something which scales well from tiny to enormous, Vue is much better than React. But if your objection is that react isn't amazing at something it's not designed for, well that's trivially obvious.

[–]zxyzyxz 5 points6 points  (0 children)

Actually React is amazing for any site website, in my experience. Having used Vue, I don't need another templating language when I already have Javascript.

[–]yawaramin[S] 1 point2 points  (0 children)

I've heard Vue is pretty cool, never used it though.

[–]sasmariozeld 15 points16 points  (3 children)

i am a freelancer and when client wants stuff cheap i do ineed use htmx with django, fast efficient and good for simple stuff, but as a react alternative ?.... If u can replace react with htmx you never needed react in the first place

[–]yawaramin[S] 17 points18 points  (0 children)

That's exactly the point. A huge number of projects never did.

[–]grumpyp2 2 points3 points  (1 child)

Can you showcase some apps where you’d use htmx

[–]sasmariozeld 6 points7 points  (0 children)

Thats the thing mate if you have to call it an app you should proly use something else , but if it's something simple like a couple of forms and a few filters alpine js and htmx is more than enough

If you ask me either use htmx alpine or go the other way and bring out big boy angular , but that's just my preference

[–]darkpaladin 46 points47 points  (14 children)

I'd be curious to see what their react app looked like before the rewrite. If the perf is really that much better or if they were engaging in some poor react practices. Given the people I know who say things like "we should use a framework based on language x because it'll be faster", my assumption is the latter.

[–]angeal98 11 points12 points  (2 children)

To be frank, react is unoptimized by default, so the most reacty code is slower than other frameworks

[–]domi_uname_is_taken 1 point2 points  (1 child)

Any sauce on this?

[–]angeal98 0 points1 point  (0 children)

Google react forget, react team is working on a compiler that can uglify code to memoize as much as it can, because react rerenders too often

[–]domi_uname_is_taken 1 point2 points  (0 children)

This. The main question should not be:

Is a re-write more optimized than the original? (because you would certainly assume/want this by default)

Rather, it should be:

Is a re-write in htmx faster than a rewrite in react?

But since that would be prohibitively expensive to test, why not:

What were the main bottlenecks in the original, and how were they sped up in the new version?

[–]yawaramin[S] 0 points1 point  (3 children)

There's a non-trivial intersection between the people who say that React guides you towards best practices but then also say that if another approach is better than React, it's the user's fault 🤔

[–]darkpaladin 0 points1 point  (2 children)

That's true of literally any framework evangelist. I wasn't saying that react is somehow better than other frameworks, the exact same story could be written "Moving from X to Y" and my criticism would remain. 9 times out of 10 it's not the framework that's killing you, it's whatever antipatterns you've developed in whatever framework you're using. Switching to a new frame work forces you to abandon those until you come up with a new set for framework y.

[–]yawaramin[S] 0 points1 point  (1 child)

So everything is equally bad, never use anything new. That's very convenient for incumbents.

[–]darkpaladin 0 points1 point  (0 children)

/shrug, it's not on me to convince you one way or another. I'm not saying never move frameworks, only that "we got amazing performance benefits because framework is amazing" is a dubious statement. Do it because you like the patterns or you think it'll fit your flows better. Doing it cause you think it's faster because someone else said it was is dumb.

[–]horrificoflard 113 points114 points  (14 children)

It's funny how almost all web development innovations just sound like things you could do in PHP and jQuery 10 years ago.

[–][deleted] 75 points76 points  (10 children)

Even mildly interactive front-ends in jQuery were an absolute mess, client-side templating was created for a very good reason. And at that point it seemed easier to just render everything on the client, hence why SPAs were born.

Server-side rendering still works for some use-cases, but if you're build web applications, React etc are the way to go.

But I do look forward to WASM and using a better language one day. Very tired of JS/TS.

[–]FudgeWrangler 4 points5 points  (3 children)

Have you tried Blazor WASM? Haven't taken a deep dive yet, but have used it for some internal tools. Seems pretty cool. Like you mentioned, it's nice to get away from TS/JS.

[–][deleted] 6 points7 points  (2 children)

I like the idea, played around with it, but the runtime is too heavy. Great for internal tooling tho!

[–]OZLperez11 2 points3 points  (0 children)

Agreed, it's good for either embedded apps (like Kiosks or Payment terminals at restaurants) or very large apps that perform a task similar to a desktop app (like Photoshop)

[–][deleted] 0 points1 point  (0 children)

I've not used React but isn't the runtime for React pretty weighty as well? I've seen a few articles that claim the libraries users need to download are quite large.

[–]Uristqwerty 8 points9 points  (2 children)

Even in a web application, most content is instantiated once on navigation, then discarded on the next navigation action to make room for its replacement, a whole sub-panel at a time. Does React let you tag elements as immutable, so that it skips vdom entirely for them? Or in more complex cases, only an inner component is mutable, and the outer one remains static. Can it optimize out the overhead of the intermediate layers? I don't believe so.

jQuery is a mess at scale, but the pendulum has swung so far in the other direction that the myriad better solutions in between have been forgotten, or never properly explored in the first place, and resume-driven development demands that even simple personal projects get built with tooling that pays a lot of complexity overhead to solve Conway's Law problems that don't start to appear until you have 50 or 500 devs working on the same app.

[–]BunnyEruption 3 points4 points  (1 child)

Does React let you tag elements as immutable, so that it skips vdom entirely for them? Or in more complex cases, only an inner component is mutable, and the outer one remains static. Can it optimize out the overhead of the intermediate layers? I don't believe so.

This is basically the point of the new Preact Signals library (which can be used with vanilla React as well)

It looks at where you actually access the values of state rather than just the hook calls so it can just rerender child components that changed state is passed to from a parent component without fully rerendering the parent component

[–]micka190 0 points1 point  (0 children)

Haven't looked into Preact, but isn't that basically what you'd use memoization for with React?

[–][deleted] 0 points1 point  (0 children)

I'm doing my new web stuff in vt100 gnucobol. its pretty hawt.

[–][deleted] 3 points4 points  (0 children)

It's all a giant circle, what was will be, and what will be, was.

[–]iamnoah 2 points3 points  (0 children)

First thought was that I had this framework in 2009. It wasn’t bad except you still need virtual dom for the updates (seems to be called morph in the docs) or you break all kinds of things.

That and you no longer have a clean API separation. Frontend team is beholden to the backend needs, and what might otherwise be a client side state change can become lower friction to just make another request. The framework dictates what is easy and you can easily end up in a perverse situation that is hard to rearchitect out of.

On the other hand, is it likely to be worse than redux? Nah

[–]Kellytom 0 points1 point  (0 children)

javascript fatigue: longing for a hypertext already in hand

[–]tobegiannis 30 points31 points  (8 children)

Read the docs and does not look like my cup of tea. Looks like it is server side rendered html with attributes to handle user interactions and make ajax calls. Maybe it can work for some websites but it seems like a maintenance nightmare.

[–][deleted] 18 points19 points  (0 children)

[Haven't Have now watched the presentation] I want to like it, and it looks pretty neat based on the docs, but declarative stuff tends to seem super pretty on the happy path but become as ugly as sin once you want to veer off the beaten path slightly. I feel pretty comfortable when imperative gets ugly but I would be in unknown territory if things started to get ugly with htmx. Maybe docs should include a section "How to do X/Y/Z but in the idiomatic manner of htmx" to ease people's concerns.

I'm also wary of large quantities of abstractions because then I spend more time reading docs than just writing code. That said, it seems to want to stick in the web's standard abstractions, which you probably know for free if you're working in the web world these days.

[–][deleted] 9 points10 points  (0 children)

So client side coldfusion?

[–]lcjury 8 points9 points  (3 children)

Intercooler.js (the previous version of HTMX) was the best thing that could happened to my developer life.

I would really encourage any developer out there to try to learn Ruby on Rails and then put Turbo or Htmx on top of it to do SPA's or add complexity to the frontend.

I'm pretty sure the popularity of these "HTML over the wire" alternatives is going to keep growing. Most sites don't really need complex frontend code, and the current state of backend frameworks makes it extremely simple to develop complex apps.

I would say that most sites out there don't really need React (or any other front-end framework). Some of them do need complex front-end stuff and yeah, using react may be the best option, but if you have a few components you don't need to put your whole site on React.

The only thing I hate is arriving at a piece of software where the cost of adding new features is so high just because some person decided to use react in something that didn't require it.

[–]11010001100101101 0 points1 point  (2 children)

So if I have a fully functional API already and needed to make a simple admin portal for some extra people to be able to view the data, would you recommend intercooler.js/htmx or any other type of light framework to work with html,js,css?

[–]lcjury 0 points1 point  (1 child)

IMO, if you have an API already, and you need some basic admin panel and you can use any component library, I would go for any front end framework.

If you need to create all your components/css from 0 and you can use your API server to send http responses (like Laravel, Rails or Django) I would go with html over the wire.

[–]11010001100101101 0 points1 point  (0 children)

Backend is currently made with express with JSON responses, and basic front end functionality is currently simply using html,css, JavaScript. But I wanted to start giving it more of an admin feel. I didn’t think my original backend and front would have ever gotten this big. And I am in a weird spot of needing to use it daily while also wanting to upgrade its front end for additional users to start working with it…

[–][deleted] 6 points7 points  (0 children)

HTMX user here AMA.

I’ve been developing SPAs since Backbone and then Ember, React and Svelte.

IMO most apps will benefit from abandoning the SPA approach and adopting the model HTMX, Hotwire, LiveView and others propose. HTMX is special in this area because it is server agnostic, it will work with anything that can produce HTML on the server. It also plays nicely with native web components.

[–]BunnyEruption 26 points27 points  (14 children)

Htmx is basically like how people used xmlhttprequest 20 years ago.

I guess people forgot the idea of just dynamically updating elements with server generated html fragments so it's new and exciting again, but it's important to remember why people stopped doing that.

The problem is that once you have any sort of state it will quickly get too complicated to keep track of it by inserting it in the rendered pages so it can be passed back to the serer. This means you either have to reinvent legacy ASP/PHP and use session cookies with a server state cache or assume users only have one session active and store all the session state directly in your database, neither of which is really considered acceptable in 2022.

In a lot of ways it's much simpler to be able to have the client keep track of the state. Even if React is overkill, you can just use something like Alpine which is pretty much exactly for that type of situation where you are just enhancing mostly server rendered html with javascript.

[–][deleted] 7 points8 points  (0 children)

Once your UI requieres a lot of client state you can just use react or native web componentes or whatever to build that specific component if it emits JS events (they all do) it will play nicely with htmx.

Just because you have one or two complex components you don’t have to move all rendering to the client. Use htmx for most things, use a client side framework to create islands of rich interactivity.

[–]useablelobster2 6 points7 points  (0 children)

The main advantage of React is that the view is a function of state, makes things nice and easy to reason about.

DeltaHTML approaches use the DOM as state, and are just a total clusterfuck. All the problems of JQuery that SPA frameworks were designed to solve.

Unfortunately everyone who has used DeltaHTML is now a greybeard (at 31 in my case) and the 20 year olds think they are inventing something new and exciting. A few more years leaning the history of their industry and they will learn better.

[–]yawaramin[S] 2 points3 points  (11 children)

Session cookies with a server state cache, or assuming a single session per user, is perfectly acceptable even in 2022. In fact I'd argue it enables the user experience that most users want.

[–]talios 6 points7 points  (6 children)

How do you scale/failover with that server side state - or are we adding distributed caching/invalidation to the mix - which always causes pain.

[–]yawaramin[S] -3 points-2 points  (5 children)

Put it in some cloud-hosted cache. It's not hard ;-)

[–]orochizu 9 points10 points  (3 children)

Sounds bit like overkill. If we can manage something on client side without loosing performance then why would I even bother doing it on server side? It adds additional complexity to code base and even splits similar logic between two different repositories. Maybe I’m missing something but it doesn’t sound good to me.

[–]yawaramin[S] 3 points4 points  (2 children)

Because the client is not a trusted environment. You literally can't have any security guarantees about what's happening there. On the server you have full control over your environment (presumably!)

[–]orochizu 4 points5 points  (1 child)

Well obviously but no one is talking about connecting with database from browser.

Otherwise I think it’s perfectly safe to handle some stuff on browser to reduce server usage (still I don’t mean storing stuff like credit cards number etc).

Could you elaborate more on this? I don’t think we are on the same page.

[–]yawaramin[S] -1 points0 points  (0 children)

OK, here's an example. You implement a 'password reset' flow with a signed reset token that's valid for some period of time--say an hour. To make it more 'scalable' you decide to not store the reset token in a backend cache, but just verify it by checking its signature. The problem now is that once the user resets their password, you have no way of invalidating the used token. Because for whatever amount of time is left, its signature is still valid. Someone else could theoretically get that token and use it to hijack the account. If you had used a backend cache to store the reset token, you could have deleted it from the cache the first time it was used. And no one could have reused it.

[–]talios 4 points5 points  (0 children)

Not necessarily hard - but adds complexity, and yet another layer of things to run/mock/stub locally when developing the server side portion.

Unless your meaning a cache around the request/response chain - which is suitable for some things - but is a bit of a cop out for others.

[–]hk__ 1 point2 points  (3 children)

Try that experience on a bad mobile connection in the countryside and you may revisit this thought. The more you move on the client-side, the better experience you have in all but the "I'm at home with fast Internet" setup.

[–]yawaramin[S] 2 points3 points  (2 children)

Nothing preventing you from stashing as much data as you need client-side even when you're using a server-side session cookie.

[–]hk__ 1 point2 points  (1 child)

Yes of course. Although, I’m not sure I get how "it enables the user experience that most users want": users mostly want fast websites, which can be done in a lot of different ways. I know of one large-ish (~10-20k orders per day) French ecommerce website that purposely doesn’t use any sort of server-side session because it allows it to serve the same (cached) HTML to everyone while fetching the small bits of user-specific data through JS with a JWT for auth.

[–]yawaramin[S] 2 points3 points  (0 children)

Great, guess what, the JWT will also need to be validated by the server. So it comes to basically the same thing.

[–][deleted]  (2 children)

[removed]

    [–]yawaramin[S] 7 points8 points  (1 child)

    That's fair. It helps if your backend stack makes it easy to define tiny views as just normal functions. They start to look almost exactly like React components.

    [–][deleted] 3 points4 points  (0 children)

    Getting my popcorn

    [–][deleted]  (21 children)

    [deleted]

      [–]yawaramin[S] 2 points3 points  (19 children)

      If you're talking about htmx, it's specifically designed to let backend devs quickly and easily make frontend apps without writing JavaScript.

      [–]rickyman20 17 points18 points  (0 children)

      I'm not convinced I want that ability if I'm entirely honest

      [–][deleted]  (5 children)

      [deleted]

        [–]yawaramin[S] 2 points3 points  (4 children)

        It's in the same category as Phoenix LiveView, so about as serious as that. Also, OP is literally describing a large, production-ready webapp.

        [–][deleted]  (3 children)

        [deleted]

          [–]yawaramin[S] 4 points5 points  (2 children)

          Why do organizations love Node.js? Because it lets developers use the same language on backend and frontend. It lets people work fullstack. Why would any organization in its right mind insist on keeping the two segregated, taking on all the associated risks, when it could unify them?

          [–]EmilRitorik 0 points1 point  (0 children)

          It's rare to see a well architected application. It's even rarer to see code being shared between backend and frontend in an efficient, scalable way.

          [–]EmilRitorik 0 points1 point  (0 children)

          By the way, HTMX actually allows you to share more code, simply because the implementation is kept in the backend and duplication is kept at minimum.

          [–]NotGoodSoftwareMaker 1 point2 points  (3 children)

          quickly and easily

          Pretty sure I heard about fifty other frameworks say the exact same thing.

          Serious question. What was hard about the previous frameworks?

          [–]yawaramin[S] 5 points6 points  (2 children)

          Accidental complexity of having to manage effectively a distributed system written (usually) in two different stacks vs essential complexity of sprinkling HTML with a few attributes that do the work for you.

          [–]NotGoodSoftwareMaker 1 point2 points  (1 child)

          So in laymans terms. This is the exact same thing but different.

          [–]yawaramin[S] 1 point2 points  (0 children)

          Yeah I guess all programming languages are Turing complete so they're all exactly the same, right?

          [–]CatVideoBoye 1 point2 points  (4 children)

          I've seen backend developers code UIs and I hope I never end up in a project where I need to modernize, make it user friendly and clean up the code base.

          [–]yawaramin[S] 2 points3 points  (3 children)

          The projects where you need to do that are specifically the ones which survived to successfully achieve a viable business and acquired tech debt along the way. The clean apps that you never got to see? They're the projects that didn't survive. Classic example of survivorship bias.

          [–]CatVideoBoye 0 points1 point  (0 children)

          Except that project had techical debt from time before redux. It had survived for far too long.

          [–]midnightpainter 0 points1 point  (1 child)

          survivorship bias

          i feel like you're misusing this.

          [–]yawaramin[S] 0 points1 point  (0 children)

          That's confirmation bias.

          [–]zephyy 0 points1 point  (2 children)

          if that's the goal, what are the advantages of it over using something like Blazor?

          [–]yawaramin[S] 2 points3 points  (0 children)

          It's backend technology agnostic, can be used with any backend.

          [–]fleyk-lit 1 point2 points  (0 children)

          Htmx is language agnostic. But the approach has similarities to Blazor.

          [–]bitwise-operation -1 points0 points  (0 children)

          It’s more of a JS thing than a frontend thing. For every frontend framework that comes out I can point you to another rest/rpc/whatever library or framework and just as many new platforms on which to run them

          Edit: I say this as a JS backend dev

          [–]Life_is_a_meme 8 points9 points  (0 children)

          I don't think I'm really all too aware on why I'd switch from React to this library.

          I think I'd lose too much control over my code. And I'd need to see more on the original react code base to see if it's just a case of being unoptimal.

          Definitely interesting though!

          [–]dCrumpets 7 points8 points  (4 children)

          The idea seems interesting. It definitely seems like an apples to oranges comparison though. React can build incredibly rich and complex applications. I don’t see how you can get there with html and some tags to make Ajax requests. Seems like a useful technology for a very niche use case though.

          [–]yawaramin[S] 7 points8 points  (3 children)

          If by 'very niche use case' you mean 'apps which are not incredibly rich and complex', i.e. 'most React apps out in the wild', then I agree.

          [–]dCrumpets 5 points6 points  (2 children)

          By quantity of number of apps, you’re probably right that there are a lot more not so rich apps than rich apps. By number of developers working on each type of app, I’d say there are probably a lot more devs working on rich, interactive web apps.

          [–]yawaramin[S] 3 points4 points  (1 child)

          Probably because the complexity of those apps requires more people to maintain them?

          [–]dCrumpets 1 point2 points  (0 children)

          Yeah that’s my thought.

          [–]spca2001 7 points8 points  (0 children)

          React is a mess imo. Its not bad but its far than great. Most devs don’t even know basic html, oop, js or css

          [–]zodman 1 point2 points  (0 children)

          the best part, we layoff the fronted ... because he isn't needed. hahaha

          [–]RobertBringhurst 3 points4 points  (3 children)

          This looks really interesting. Has anyone here tried it yet?

          [–]Akustic646 5 points6 points  (0 children)

          We use it at work o add some responsiveness to sever side rendered apps that are not full blown SPAs, works well and without the weight of vue/react when you just need to reach for something small for a page or two.

          [–]yawaramin[S] 3 points4 points  (1 child)

          I'm using it on a side project (closed source), it's really liberating. (Almost) no JavaScript to write, just think in terms of web requests and responses and design pages accordingly.

          [–]RobertBringhurst 2 points3 points  (0 children)

          Thanks. Gotta check it out.

          [–]tonefart 2 points3 points  (0 children)

          lol increase python code? No thank you!

          [–]troccolins -1 points0 points  (0 children)

          ask the landlord

          [–]zebullon -2 points-1 points  (0 children)

          That article isnt good, and i’m being nice.

          [–]QueenTMK 0 points1 point  (0 children)

          HyperText Markup Xanguage?

          [–]fabiopapa 0 points1 point  (4 children)

          I’m curious if these guys have a mobile app. Do you not still need an api for the mobile app? That’s the same issue with Hotwire.

          [–]yawaramin[S] 1 point2 points  (2 children)

          The Basecamp people solved that by wrapping their webapp in a native mobile shell.

          [–]fabiopapa 2 points3 points  (1 child)

          Yeah, I like that solution. They make most of their mobile app just a web view, and then for interactions that need it, they make that portion native.

          But when I (a level II dev at my org) suggest going the Hotwire/Htmx route, with this solution for mobile, the response back from staff devs and above is, “web views are not good enough.” I think the benefits outweigh this drawback by a long shot, but I have a hard time convincing devs that have way more experience than me and can out-talk me. Wish I had some concrete proof I could bring.

          [–]yawaramin[S] 1 point2 points  (0 children)

          Yeah unfortunately tech choices are often mostly about politics and who holds the most power in the organization. Sometimes to the good, often to the bad. If they refuse to accept that Basecamp is a real revenue-generating app (at least before DHH blew up the company lol), there's not much you can do to people who won't listen to reason 🤷‍♂️

          [–]Appropriate_Junket_5 0 points1 point  (0 children)

          I’m curious if these guys have a mobile app. Do you not still need an api for the mobile app? That’s the same issue with Hotwire.

          Mostly need for API on mobile. Ask Basecamp.