HTMX is closer to REST than your so-called JSON REST API.
What it's like to run Htmx in Production
11–18 of 18 posts
Re: What it's like to run Htmx in Production
#12I would say that it misses one of the main drawback of using Htmx: it does not force you to create a proper API. When you create a standard single page application, you generally start by building a JSON API on the server side, and a client application that can consumme that API. Htmx server code is different as it just returns HTML code to be inserted back in the page. So while, writing an app with Htmx is very easy…
This is actually a feature. A good API for public consumption is a specific thing to build with intentionality.
If your tech stack forces you to build an API in order to put a basic webpage together and handle form data, that is the red flag.
Re: What it's like to run Htmx in Production
#13I'd really like to see some production web sites that use htmx.
Re: What it's like to run Htmx in Production
#14I'd really like to see some production web sites that use htmx.
Re: What it's like to run Htmx in Production
#15I would say that it misses one of the main drawback of using Htmx: it does not force you to create a proper API. When you create a standard single page application, you generally start by building a JSON API on the server side, and a client application that can consumme that API. Htmx server code is different as it just returns HTML code to be inserted back in the page. So while, writing an app with Htmx is very easy…
Re: What it's like to run Htmx in Production
#16HTMX is closer to REST than your so-called JSON REST API.
Re: What it's like to run Htmx in Production
#17Concedes that there's extra network requests and then just completely handwaved it away.
Re: What it's like to run Htmx in Production
#18Interesting claim here about engineering org dysfunction: > FE code has gotten so complex that many orgs now have specialized positions - FE and BE. In practice this means that it's very hard for any one developer to get a fullstack change out. > Short-term this means that all changes incur extra cost due to context switching and collaboration overhead between FE / BE dev > Long-term this means a general architectura…
I see this in my job, so at least for me it's not a claim, it's reality.
I can only recommend everyone to learn both FE and BE programming, to avoid this situation and the overhead.