Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • Archive link: https://archive.ph/bLu1Z
    by Ralfp
  • I used htmx but had to migrate to svelte for storybook for development, I wish htmx had that sort of tooling
    by jackhalford
  • > A lot of pages in Misago are implemented twice: as Django templates and React.js components.

    I think this tells all about the level of competence of these devs. That’s literally unmaintainable. So instead of fixing the problem and have a nice api + interface + ssr, they patch it up with a yet worse approach in htmx.

    > there's a lot of forum software out there that still does the old way of rendering as much as possible on the server and using some JavaScript on client to improve its interactivity here and there. And people are happy with that

    Yeah, server returns class xxx and jquery needs to target that. Once is out of sync silent bugs will appear. And will be many, not a few. No way to check at compile time.

    by skeptic_ai
  • MISAGO MONGO DJANGO BUN

    WHY WILL NOT MY FORUM RUN

    MISAGO MONGO DJANGO BUN

    PERFECT CONFIGURATION

    MISAGO MONGO DJANGO BUN

    IF YOU ARE THE CHOSEN ONE

    MISAGO MONGO DJANGO BUN

    REWRITE MY APP AND MAKE IT RUN!

    by rubyfruit
  • In the realm of Server-Side rendered pages and replacing bits of the DOM, I'd recommend https://pyview.rocks/. Borrows from Elixir Phoenix's Liveview and works really nice and patches are light to apply.
    by gchamonlive
  • This happened 3 years ago... wondering what makes it news worthy today?
    by thrownaway561
  • We need a follow up, how this change panned out, how much did performance improve?
    by butz
  • Using Django w/ frontend frameworks has been a struggle for me. (I only dabble as a hobbyist.) I think splitting the backend off into a restful API makes the marriage work. I've looked at django-rest-framework (https://www.django-rest-framework.org/) and django-ninja (https://django-ninja.dev/). Of course,, then you're discarding a lot of batteries that come with the django framework. Perhaps using Django templates for admin / internal facing work only, and React for customer-facing sites can be a healthy compromise?
    by hazrmard
  • That's the architecture my B2B SaaS uses, except Vue instead of React. We deploy the SPA to a CDN and it feels snappy. Some clients access the API directly via OAuth. django-allauth is the other critical piece. Works great altogether.
    by scorxn
  • Replace React / Vue with HTMX 2 years ago and still going strong.

    Hono + WebComponents + HTMX + serverless is the backend for my apps now.

    by n4pw01f
  • What is the point of using HTMX if your backend is JavaScript(Hono)?
    by foxygen
  • Happy they did this. Htmx is a great fit for server rendering - which in many or most cases is what you should do in any case. You can always put a mini VueJS or ReactJS app inside of a template for a very custom interactivity.
    by sgt
  • I've been saying for years: All buildings should be parking garages.

    Because you can always just put a mini residential building inside a parking garage if you need tenants.

    Need an office? Just put a mini office in the parking garage. It's perfect.

    Parking garage construction is so clean and simple. Other buildings are too complex! From now on, I'll only build parking garages.

    (Then I guess you have the opposite example of the residence without the parking garage! It's a great place to live, but there's nowhere to store my things and park my car!)

    by rubyfruit
  • That’s basically a massive hack. Every real world app will need enough js that htmx will require you to put js on front end and you’ll need to hack it together. Just like we did php+js 15 years ago.
    by skeptic_ai
  • Putting ReactJS or VueJS for a little interactivity is hardly the correct approach. It makes no sense to bring them in for "a little". What made React and React-like (Angular v2, Vue.js) frameworks stabilise is that they're about the right abstractions and everything else for managing dynamic html converges to about the same thing.
    by asdfsa32
  • I basically use HTMX for all my Web Apps, including PWA(s) that run as ~near native apps on iOS/Android. It's great! I aso pair this with DaisyUI+TailwindCSS. YOu really can't go wrong, there is something quite pleasant about writing your web apps in ordinary HTML with partials and the extensions that HTMX adds to the browser for SPA-like interactivity.
    by prologic
  • I know that you can have a shortcut on the users phone home screen but I've run into a bunch of problems with that setup where hitting it multiple times opens multiple tabs etc.

    Have you found nice workarounds for that?

    by johsole
  • Big fan of bDaisy and TW ...all thats missing is jQuery and Razor .cshtml to rock my 2026 mistersoft web stack. HTMX is very cool but $...
    by rahabash
  • How does the PWA work offline with HTMX? The “hit the server for fresh markup fragments” approach seems like it has to be abandoned here, however simplifying it is for online apps.
    by wwweston
  • I think HTMX is a great fit for forum software. Forum websites mostly deliver non-interactive content in the form of text and maybe some audio, video, or image content. All of this can be represented as HTML and CSS.

    With HTMX you can do partial rendering and live updates via server-sent events. This gets you most of the way to the "client side" feel where things load dynamically based on user actions.

    The only properly dynamic SPA-like feature in a forum I can think of is a WYSIWYG editor, but that you can build as a web component. Maybe a flexible highlight and quote system would be a bit difficult in pure HTMX (think of the comment functionality in Medium posts). So you'd want to build a few things in client side JS. But the main experience could very well be built with HTMX.

    by snorremd
  • > The only properly dynamic SPA-like feature in a forum I can think of is a WYSIWYG editor, but that you can build as a web component. Maybe a flexible highlight and quote system would be a bit difficult in pure HTMX (think of the comment functionality in Medium posts). So you'd want to build a few things in client side JS. But the main experience could very well be built with HTMX.

    That's how interactivity has always worked.

    Server-side render everything + ship interactivity via js on top of it.

    I feel like most of the web developers forgot that React/Vue/etc solve a specific problem: single-page application.

    This is a very narrow and specific problem: navigating from page to page not causing full page reloads.

    But the web has changed since SPAs were needed in major ways:

    1. the average device and connection is insanely faster than 10-15 years ago. Receiving and rendering content is not the problem it once was in the age of 2g connections and limited hardware mobile devices. Even the very low end phone from few years ago has nowadays 0 problems loading and parsing few hundred kbs of html and js.

    2. Web technologies moved at all levels. Server technologies, cloud ones, browser ones. React and company are solving problems that barely belong to the modern web.

    In short: today you can have an app-like, spa-like experience even out of fully server-side rendered applications. While also benefitting from shipping much less code to the client.

    There's a very minimal amount of websites and applications out there that benefit, and aren't crippled by these rendering libraries: those that vastly leverage offline capabilities of the platform and want to keep working regardless of internet being available. I'm talking the notions and linears.

    But bar from those, still working with this React slop is just not good for the user. Even multi billion companies hiring leetcode ninjas can't get acceptable user experience and performance out of those libraries, and it's not a coincidence: they keep forcing the wrong tool for the wrong problem.

    They keep living in 2018 and at the end of the day the only excuse for those react/angular+tailwind slop is that there's an entire generation of developers that doesn't know anything else and has long lost any proper engineering skill (if there is any) in finding the right tool for the problem. This is a familiarity issue, not sound technical decisions. It's the "you can't go wrong with oracle/mysql/ibm", but actually you can, and it shows.

    What's worse: it's incredibly cheap to experiment different solutions and approaches via LLMs in 2026, but people keep slopping the same monstrosities.

    by epolanski
  • Agreed very much.

    I'd extend this to "web apps that revolve around forms, views, filters and pagination" when it comes to "Ajax" stuff (yes, I'm old).

    The part of htmx that's relevant to these topics being discussed here, I once wrote an inferior clone of, some years ago.

    It was "isomorphic", tailored to our PHP-based CMS, and could handle filters, search forms, and pagination.

    Suitable for forums definitely, and current PHP-based forum software vendors that are still on the market follow the same paradigm.

    by moritzwarhier
  • > Forum websites mostly deliver non-interactive content

    I'd say that "Endless Scroll" is a good example of something that is... well maybe not interactive but still breaks the "just an HTML document" page metaphor that plays nice with such things.

    Now, personally I find the UI compromises it takes to make endless scrolling happen are abhorrent (like not being able to ctrl-F or export the page content). But other people obviously like them.

    Is that the kind of thing you'd be giving up as you move to a platform like HTMX?

    by Pxtl
  • To paraphrase: "I think HTMX is a great fit for <majority of websites on the internet> save for a few that want to be an _APP_"… :)
    by ktosobcy
  • I actually tried to use HTMX on a site recently. I used the 4.0 beta. The site needed an interactive filterable product-listing-page-type experience to list out all their vendors. Form filters on the left and the list of results "cards" on the right.

    The problem I had was that the entire experience became really slow when I had it all working together as one "response". Sending back all that HTML for an entire form with some large select lists as well as the response of results became noticeable laggy when there was more than a half dozen results.

    I ended up switching to Alpine Ajax (https://alpine-ajax.js.org/) and pulled the form out of the response and just used a local x-data on it to track the state. This greatly reduced the HTML I needed to send back to just the list of results. I did make the form a bit more complicated but the experience felt a lot snappier. Both versions just synced the form state from the URL and kept the initial render as full HTML from the server.

    I found that Alpine + Alpine Ajax was SMALLER than HTMX 4 even though (in my opinion) it offers a lot more features in a more approachable and intuitive way if you need to do interactivity and don’t want to trigger a request just to toggle some classes or attributes. Of course you can use both together (I started down that road) but you are mixing worlds and making the bundle size bigger at the same time.

    I still like HTMX and will probably use it again. I just found that with an interactive experience like a product listing page, where the HTML response was quite large/expensive to fetch, it wasn’t the best choice for that.

    by james2doyle
  • have a look at https://segor.de/ - it just downloads 2MB of product listing data (pre-dating JSON!) and then does all filtering client-side
    by inigyou
  • Is there a reason why you don't have an endpoint + template that renders only the result list. The form could be separate thing and issue a form submit request with all the selected filters? Seems better than rendering the whole page. You could even display a loader while the results are loading, and swap the list html element on success.
    by papanoah
  • You can bring anything to its knees when requesting too much data at once. There's always another bottleneck. Getting all data in a single request is an antipattern to me. Fetching a lot of data unless absolutely necessary with no other option is an antipattern to me. But that of course is relative to a specific purpose.
    by HackerThemAll
  • For some reason this subthread reminds me of the old joke about how to get Linux tech support. https://www.reddit.com/r/ProgrammerHumor/comments/7p88zj/ask...
    by Elzair
  • Despite the fact that HTMX is a good solution in many cases, it's not the best solution in all cases. Ditto for React, and for any technology actually. Planning and consideration are always required, if you care about the end result.
    by nine_k