5 ms·

But HTMX is a JS library. Anything done with it is basically done with JS.

by zelphirkalt 4y ago

mirekrusin 4y ago
Kernel is done with C. Everything is basically done with C. Even JavaScript.
- zelphirkalt 4y ago
  That doesn't address the implications of something only working with JS at all.
- hirvi74 4y ago
  It's all binary at the end of the day.
  - nudpiedo 4y ago
    It’s all just energy moving around
    - dunno7456 4y ago
      On sand.
      - I_complete_me 4y ago
        And those turtles that go all the way down lay their eggs in that sand.
- TechBro8615 4y ago
  The most popular JavaScript engine (V8) is written mostly in C++. Same with WebKit. Other JS engines are written in Rust, like Deno or Servo (used in parts of Firefox). I'm not aware of a major Javascript engine which is written in C, except for QuickJS, which is not "major" in any sense of popularity but is an efficient engine for embedded use cases (and anything from Fabrice Bellard is always work a look).
  - aabbcc1241 4y ago
    I suppose C++ is written in C. In similar relationships like Typescript and Javascript.
    - detaro 4y ago
      Not really, no.
deleted 4y ago
[deleted]
theptip 4y ago
The point you're missing here is that if you use HTMX, you often don't need to write any JS. You just write HTML with some special tags, and the library handles everything for you.
- drdaeman 4y ago
  Spoiler warning: it doesn't. Unless you only consider the happiest path, as in "I develop on localhost with zero latency, 100% uptime, and my backend validation logic perfectly matches my frontend policies" (and probably a lot more other "if"s and "only"s).
  - sandGorgon 4y ago
    this is an interesting comment. so it has been sold to me like that. Could you talk about where it fails. alpinejs does make the claim that it is a "better jquery". What is the development experience here? especially for backend teams (python, java, whatever) who are now also building HTMX.
    - adamckay 4y ago
      > Could you talk about where it fails If the HTTP request that htmx has made returns a status code >= 400 or times out then the response will not be swapped into the body. There are several events that htmx fires, once of which can catch `responseError` [1] and you can write some Javascript to handle it according to your requirements (throw a toast, swap anyway by setting `evt.detail.shouldSwap = true`. In a project I'm working on we use htmx to load the content for modals, so we have small handlers on htmx events to display the modal whilst the request is being made, put a spinner indicator in the modal body to show the user something is happening and then swap the body in once the request has completed. We've also used `HX-Trigger` response header [2] which htmx helpfully catches and allows us to easily hook onto, we've got ones to display a toast notification, hide open modals, refresh content divs, untick bulk action checkboxes, etc. All in, our project probably has around 200 lines of Javascript for the different event handlers we do, so it doesn't eliminate the need to write any JS, but it's significantly reduced and is pretty much all event handlers. 1 - https://htmx.org/events/#htmx:responseError https://htmx.org/events/#htmx:responseError 2 - https://htmx.org/headers/hx-trigger/ https://htmx.org/headers/hx-trigger/
drdaeman 4y ago
I'd say it's not about what can be done, it's about how it's defined. HTMX is a abstraction layer on top of an existing abstractions that you still have to know, because it's defined in terms of those abstractions. So when you write something like `hx-trigger="click" hx-put="/api/my"` you're actually actively thinking of an `addEventListener("click", ...)`, `this.innerHTML` assignment and `fetch("/api/my", { method: "PUT" }))`. Can't use HTMX without knowing the underlying principles and primitives. And then you still have to do JS because how else you're supposed to handle `htmx:responseError` and stuff. And maybe I'm wrong but it feels risky because the logic could end up all around the place and not in a single nice function/code block. So, basically, it's a nice DSL providing a bunch of shortcuts, but it doesn't magically alleviate knowing any underlying principles and nuances of JS and DOM. Again, it's even defined in terms of those systems (`hx-swap="outerHTML"` being a very clear indicator example).
devmunchies 4y ago
It’s almost like htmx is a byte code target that you feed to the htmx JavaScript library. It’s easy to generate htmx markup with any backend language. So instead of a backend language transpiling to JavaScript (like clojurescript), I can just generate htmx markup.
ksec 4y ago
Well, I hope someday HTMX will be HTML6.

But HTMX is a JS library. Anything done with it is basically done with JS.

mirekrusin 4y ago

Kernel is done with C. Everything is basically done with C. Even JavaScript.

zelphirkalt 4y ago
That doesn't address the implications of something only working with JS at all.
hirvi74 4y ago
It's all binary at the end of the day.
- nudpiedo 4y ago
  It’s all just energy moving around
  - dunno7456 4y ago
    On sand.
    - I_complete_me 4y ago
      And those turtles that go all the way down lay their eggs in that sand.
TechBro8615 4y ago
The most popular JavaScript engine (V8) is written mostly in C++. Same with WebKit. Other JS engines are written in Rust, like Deno or Servo (used in parts of Firefox). I'm not aware of a major Javascript engine which is written in C, except for QuickJS, which is not "major" in any sense of popularity but is an efficient engine for embedded use cases (and anything from Fabrice Bellard is always work a look).
- aabbcc1241 4y ago
  I suppose C++ is written in C. In similar relationships like Typescript and Javascript.
  - detaro 4y ago
    Not really, no.

deleted 4y ago

[deleted]

theptip 4y ago

The point you're missing here is that if you use HTMX, you often don't need to write any JS. You just write HTML with some special tags, and the library handles everything for you.

drdaeman 4y ago
Spoiler warning: it doesn't. Unless you only consider the happiest path, as in "I develop on localhost with zero latency, 100% uptime, and my backend validation logic perfectly matches my frontend policies" (and probably a lot more other "if"s and "only"s).
- sandGorgon 4y ago
  this is an interesting comment. so it has been sold to me like that. Could you talk about where it fails. alpinejs does make the claim that it is a "better jquery". What is the development experience here? especially for backend teams (python, java, whatever) who are now also building HTMX.
  - adamckay 4y ago
    > Could you talk about where it fails If the HTTP request that htmx has made returns a status code >= 400 or times out then the response will not be swapped into the body. There are several events that htmx fires, once of which can catch `responseError` [1] and you can write some Javascript to handle it according to your requirements (throw a toast, swap anyway by setting `evt.detail.shouldSwap = true`. In a project I'm working on we use htmx to load the content for modals, so we have small handlers on htmx events to display the modal whilst the request is being made, put a spinner indicator in the modal body to show the user something is happening and then swap the body in once the request has completed. We've also used `HX-Trigger` response header [2] which htmx helpfully catches and allows us to easily hook onto, we've got ones to display a toast notification, hide open modals, refresh content divs, untick bulk action checkboxes, etc. All in, our project probably has around 200 lines of Javascript for the different event handlers we do, so it doesn't eliminate the need to write any JS, but it's significantly reduced and is pretty much all event handlers. 1 - https://htmx.org/events/#htmx:responseError https://htmx.org/events/#htmx:responseError 2 - https://htmx.org/headers/hx-trigger/ https://htmx.org/headers/hx-trigger/

drdaeman 4y ago

I'd say it's not about what can be done, it's about how it's defined. HTMX is a abstraction layer on top of an existing abstractions that you still have to know, because it's defined in terms of those abstractions. So when you write something like `hx-trigger="click" hx-put="/api/my"` you're actually actively thinking of an `addEventListener("click", ...)`, `this.innerHTML` assignment and `fetch("/api/my", { method: "PUT" }))`. Can't use HTMX without knowing the underlying principles and primitives. And then you still have to do JS because how else you're supposed to handle `htmx:responseError` and stuff. And maybe I'm wrong but it feels risky because the logic could end up all around the place and not in a single nice function/code block. So, basically, it's a nice DSL providing a bunch of shortcuts, but it doesn't magically alleviate knowing any underlying principles and nuances of JS and DOM. Again, it's even defined in terms of those systems (`hx-swap="outerHTML"` being a very clear indicator example).

devmunchies 4y ago

It’s almost like htmx is a byte code target that you feed to the htmx JavaScript library. It’s easy to generate htmx markup with any backend language. So instead of a backend language transpiling to JavaScript (like clojurescript), I can just generate htmx markup.

ksec 4y ago

Well, I hope someday HTMX will be HTML6.