4 ms·

For a HTML survey, there was a heck of a lot about JS in there so I quit it. Not for me. I quit JS for HTMX because time in JS, fully loaded time with framewo

For a HTML survey, there was a heck of a lot about JS in there so I quit it. Not for me. I quit JS for HTMX because time in JS, fully loaded time with framework knowledge and maintenance, is just not very important for my use case which is CRUD apps. The change to HTMX saves me time, it saves users' time, it gives a consistent experience for both. That's not to say JS is bad. I'm not dying on that hill as it's not true - pick the tool for the job. But a HTML survey this is not, it's a HTML for JSers survey.

deleted 3y ago
[deleted]
dgb23 3y ago
HTMX is a JS library that perfectly illustrates how HTML is too limited and unfinished.
- nsonha 3y ago
  [flagged]
  - PaulHoule 3y ago
    Definitely something better than HTMX is possible but to really reap the benefits of that approach you need an opinionated back end, probably more use of WebSockets, Phoenix is somewhat in that direction. A lot of it is backlash against React and various things like Vue and Svelte that are pretty much the same. People haven’t really grokked how much the hassles of working with React have to do with its very success, it is just so easy to have a big app with 7 different widget sets to master and not just that, the conceptual simplicity of React makes it a leaky enough abstraction that you can never really count on just using a widget set and having it look good but you have to mess with the CSS not just to please clients, managers and customers but even yourself as there are always cases where the spacing of things is just terrible without getting deep into it. Since CSS is not really appropriate for programming in the large you will also wind up sucking in widgets that use things like Emotion which never let you forget about CSS but rather give you more complicated things to learn.
    - dgb23 3y ago
      CSS is great until it isn't. The abstraction layer it provides is clever and useful, but also incomplete, opaque and so idiosyncratic that getting better at using and understanding it provides you with close to zero transferable skills (in our out).
      - PaulHoule 3y ago
        Back in the 1990s developers were very happy with Visual Basic on Windows where everything was laid out by pixels which of course didn't make the most of every possible screen size but you could have a dev- and designer- UI builder that people understood. I've never seen devs or designers really be happy with any system for flexible layout.
  - dgb23 3y ago
    The point of these types of libraries and patterns isn't necessarily that, although that might be a nice side-effect. It's to provide a simpler, less bloated alternative to trending JS UI patterns and libraries by leaning more into what's already there. In the grand scheme of things, I think it's absolutely necessary that we start removing and saying No to cruft and bloat.
  - moron4hire 3y ago
    I'm so sick of people complaning about "reinventing the wheel". Even for the literal wheel, I can think of at least 3 times off the top of my head that it was usefully reinvented in just the last 20 years. There is nothing that is perfect for all use cases. People who say "don't reinvent the wheel" should come up with something new to say. But they can't, because they hate innovation so much.
    - nsonha 3y ago
      You are right and I was wrong, reinventing the wheel is the least harmful thing of the like of htmlx. The actual dumb thing is that they cling on to a fundamentally wrong abstraction to build apps (form method), simply because that’s the web they’re familiar with.
      - basique 3y ago
        Why is it a wrong abstraction?
        nsonha 3y ago
        It assumes a lot of things: - Submitting a form results in an immediate network request (offline-first apps, hello?) - The network event is HTTP-based - The network event is REST - The payload is contained within the... markup (like why?) - What about network requests that are not CRUD? If your API is designed propperly, that should be most of the endpoints. Do you make dummy forms for them? How?
        basique 3y ago
        The point of htmx is to be able to do the interactivity on the server, so using it with your existing, general API isn't really the point - the backend (or, well, frontend backend?) just serves the needed data directly in the markup. This isn't really ideal if you think of your site as a separate frontend/backend, but it makes sense if you already have a backend and don't want to make an API just to then write JS that consumes the API and shows you stuff. Granted, this doesn't really work well with offline-first apps, but it's nice if you need to actually poke the server whenever you need to do something.
deleted 3y ago
[deleted]

deleted 3y ago

[deleted]

dgb23 3y ago

HTMX is a JS library that perfectly illustrates how HTML is too limited and unfinished.

nsonha 3y ago
[flagged]
- PaulHoule 3y ago
  Definitely something better than HTMX is possible but to really reap the benefits of that approach you need an opinionated back end, probably more use of WebSockets, Phoenix is somewhat in that direction. A lot of it is backlash against React and various things like Vue and Svelte that are pretty much the same. People haven’t really grokked how much the hassles of working with React have to do with its very success, it is just so easy to have a big app with 7 different widget sets to master and not just that, the conceptual simplicity of React makes it a leaky enough abstraction that you can never really count on just using a widget set and having it look good but you have to mess with the CSS not just to please clients, managers and customers but even yourself as there are always cases where the spacing of things is just terrible without getting deep into it. Since CSS is not really appropriate for programming in the large you will also wind up sucking in widgets that use things like Emotion which never let you forget about CSS but rather give you more complicated things to learn.
  - dgb23 3y ago
    CSS is great until it isn't. The abstraction layer it provides is clever and useful, but also incomplete, opaque and so idiosyncratic that getting better at using and understanding it provides you with close to zero transferable skills (in our out).
    - PaulHoule 3y ago
      Back in the 1990s developers were very happy with Visual Basic on Windows where everything was laid out by pixels which of course didn't make the most of every possible screen size but you could have a dev- and designer- UI builder that people understood. I've never seen devs or designers really be happy with any system for flexible layout.
- dgb23 3y ago
  The point of these types of libraries and patterns isn't necessarily that, although that might be a nice side-effect. It's to provide a simpler, less bloated alternative to trending JS UI patterns and libraries by leaning more into what's already there. In the grand scheme of things, I think it's absolutely necessary that we start removing and saying No to cruft and bloat.
- moron4hire 3y ago
  I'm so sick of people complaning about "reinventing the wheel". Even for the literal wheel, I can think of at least 3 times off the top of my head that it was usefully reinvented in just the last 20 years. There is nothing that is perfect for all use cases. People who say "don't reinvent the wheel" should come up with something new to say. But they can't, because they hate innovation so much.
  - nsonha 3y ago
    You are right and I was wrong, reinventing the wheel is the least harmful thing of the like of htmlx. The actual dumb thing is that they cling on to a fundamentally wrong abstraction to build apps (form method), simply because that’s the web they’re familiar with.
    - basique 3y ago
      Why is it a wrong abstraction?
      - nsonha 3y ago
        It assumes a lot of things: - Submitting a form results in an immediate network request (offline-first apps, hello?) - The network event is HTTP-based - The network event is REST - The payload is contained within the... markup (like why?) - What about network requests that are not CRUD? If your API is designed propperly, that should be most of the endpoints. Do you make dummy forms for them? How?
        basique 3y ago
        The point of htmx is to be able to do the interactivity on the server, so using it with your existing, general API isn't really the point - the backend (or, well, frontend backend?) just serves the needed data directly in the markup. This isn't really ideal if you think of your site as a separate frontend/backend, but it makes sense if you already have a backend and don't want to make an API just to then write JS that consumes the API and shows you stuff. Granted, this doesn't really work well with offline-first apps, but it's nice if you need to actually poke the server whenever you need to do something.

deleted 3y ago

[deleted]