summaryrefslogtreecommitdiffstatshomepage
path: root/www/content/essays/is-htmx-another-javascript-framework.md
diff options
context:
space:
mode:
Diffstat (limited to 'www/content/essays/is-htmx-another-javascript-framework.md')
-rw-r--r--www/content/essays/is-htmx-another-javascript-framework.md2
1 files changed, 1 insertions, 1 deletions
diff --git a/www/content/essays/is-htmx-another-javascript-framework.md b/www/content/essays/is-htmx-another-javascript-framework.md
index d5917d61..9ee394b4 100644
--- a/www/content/essays/is-htmx-another-javascript-framework.md
+++ b/www/content/essays/is-htmx-another-javascript-framework.md
@@ -43,7 +43,7 @@ If you use htmx to handle a non-trivial number of your website's network request
You can definitely use htmx in a library-like manner, to add dynamic functionality to just a few sections of your web page. But you can write [React in this library-like manner too](https://www.patterns.dev/vanilla/islands-architecture) and nobody argues that React isn't a framework. Suffice to say that many people who use htmx in their applications are doing so in a way that bends to the demands of htmx, as a framework for building hypermedia applications.
-As they should! Building with htmx works a lot better if you play to its strengths. You can send JSON-formatted form bodies, [if you really insist](@/extensions/json-enc.md). But you shouldn't! It's simpler to just use `application/x-www-form-urlencoded` bodies, and write an endpoint that accepts them. You can write an endpoint that is re-used across multiple different clients, [if you really insist](@/essays/why-tend-not-to-use-content-negotiation.md). But you shouldn't! It's simpler to [split your data and your hypermedia APIs into separate URLs](@/essays/splitting-your-apis.md). Yes, htmx can be used as a library, but maybe let it be your framework too.
+As they should! Building with htmx works a lot better if you play to its strengths. You can send JSON-formatted form bodies, [if you really insist](https://github.com/bigskysoftware/htmx-extensions/blob/main/src/json-enc/README.md). But you shouldn't! It's simpler to just use `application/x-www-form-urlencoded` bodies, and write an endpoint that accepts them. You can write an endpoint that is re-used across multiple different clients, [if you really insist](@/essays/why-tend-not-to-use-content-negotiation.md). But you shouldn't! It's simpler to [split your data and your hypermedia APIs into separate URLs](@/essays/splitting-your-apis.md). Yes, htmx can be used as a library, but maybe let it be your framework too.
That does not mean, however, that htmx is Just Another JavaScript Framework, because htmx has a huge advantage that the other frameworks do not: HTML.