Similar projects: https://github.com/stimulusjs/stimulus https://github.com/alpinejs/alpine https://github.com/intercoolerjs/intercooler-js
Htmx – high power tools for HTML
161–170 of 175 posts
Re: Htmx – high power tools for HTML
#162Earlier quoted context omitted.
This is exactly the use-case for Content-Type and Accept headers. The client and server negotiates what type of content they can receive/send, so if you're sending application/json as the Accept header, you can only handle application/json, if you only send text/html in the header, then only HTML. If the client understands both, you do application/json,text/html. with the order signalling preference. Any serious fram…
THat's how you negotiate the content type; the original question was how they have a service returning json return html. I've never heard of a framework that can arbitrarily convert data into HTML - how would that even work?
I was part of a project that when I just joined it, RESTful APIs together with fat frontend clients was becoming the hot-new-thing. The application was originally returning text/html (templates) to be injected in various part of the frontend, at request-time.
To migrate to our flashy new Angular V1 application, we added a application/json content-type that instead of returning the template, returned the data that the template used. So we could endpoint-by-endpoint migrate to the SPA we were building.
Was simply a matter of making the data required for the views a bit more advertised internally, so the controllers could instead not render the views when the content-type is json.
Re: Htmx – high power tools for HTML
#163I'm a proponent of the natural web, where the focus of web development lies with W3C compliant HTML & CSS sprinkled with very small amounts of JavaScript (if necessary). Any JS frameworks that requires the user to modify their HTML to include non-W3C complient HTML attributes is a very poor architectural decision and should be avoided. Such frameworks include Angular. Unfortunately, your framework also falls into this category.
Re: Htmx – high power tools for HTML
#164hello, I'm the creator of htmx (and originally intercooler) I just released 0.0.4, so htmx is still very young, but it's got a decent test suite: https://htmx.org/test/0.0.4/test/ there is a nice extension mechanism: https://htmx.org/extensions/ and some very rough docs on how to pull off pure HTML animations: https://htmx.org/examples/animations/ happy to answer questions
[deleted]
Re: Htmx – high power tools for HTML
#165Earlier quoted context omitted.
Because oftentimes you’re retrieving data that will be stored in one central store and displayed / used in different ways in various components. Eg I might fetch user data and sometimes display their name, maybe another time compute their age from their birthdate, etc...
What's the difference between building seperate code paths on the client vs. 2 server endpoints though? Very few scenarios can't afford the behind-the-scenes extra http round trip...
Because I don't want to build and maintain an API endpoint to give me an HTML blob for the users age, and another one for their full name, and another one just for their first name, and another one for figuring out what day of the year is their birthday. I want adding these features to my UI to be a client-side-only change.
Re: Htmx – high power tools for HTML
#166The example on the front page already hints at the type of bad programming this may encourage. When clicked, the button sends a POST (this seems ok), and then the backend sends new html for the button. The idea of having random snippets of your frontend markup being returned from api servers seems questionable.
Woah I think this is misinformed on a very fundamental level, and I really would like to clarify where this idea is coming from (is it from a "modern" React or other JS-first bootcamp line of thought by chance? Not trolling, but genuinely interested). The entire point of the original web is that you send HTML to a browser rather than JS snippets or JSON payloads, and that you compose your documents from HTML fragment…
I've built web apps that didn't need much interactivity just using a regular ol vanilla web server sending html and then bootstrap.js for the menus, modals, etc.
When a client wants the interactivity of a full-on application, I would use an application framework at that point.
Using a system where the server needs to send back snippets of html for transitory states seems like you'd need to build yourself kind of a framework to handle the mechanics of that on the backend anyway. I'm not sure what the point is then. Sure, there is an asset in your project that is "just html" (the first loaded page), but you're going to need snippets of the interface's various states in different files so that the server can send them back.
It's like this framework is pursuing an aesthetic goal of "just html" which breaks when you actually try to use it for the stuff that you'd use a framework for.
Re: Htmx – high power tools for HTML
#167I'm a proponent of the natural web, where the focus of web development lies with W3C compliant HTML & CSS sprinkled with very small amounts of JavaScript (if necessary). Any JS frameworks that requires the user to modify their HTML to include non-W3C complient HTML attributes is a very poor architectural decision and should be avoided. Such frameworks include Angular. Unfortunately, your framework also falls into thi…
you can use data- prefixes if you like
Re: Htmx – high power tools for HTML
#168Reminds me of AngularJS... :) Much simpler overall though. I like it.
It reminds me more of jQuery. And while I see how it's great for quick prototyping, it's going to be a nightmare in a large project. I really like React, where data and HTML are clearly separate. I don't want to send raw HTML back and forth, I want to send only data.
Re: Htmx – high power tools for HTML
#169For similar-goal prior-art, see Unpoly[1]. Also the IETF asks[2] that you please stop using "X-" to prepend your custom HTTP headers[3] [1] https://unpoly.com/tutorial [2] https://tools.ietf.org/html/rfc6648 [3] https://htmx.org/reference/#headers
Off topic, but that's a shame about them recommending not to prefix X- for custom headers. Their entire reason (Appendix B) is that "well, if the header eventually becomes a standard header, then there will be old apps that will only work with X-, and we'll have to keep the X- version around forever!" That seems like a very weak reason to me. Most custom headers are not going to become standard headers, and those tha…
The // means use network, while / means use local file, so I think we need both.
Re: Htmx – high power tools for HTML
#170Earlier quoted context omitted.
intercooler looked cool. never got to try it due to jquery dependency. but will definitely give htmx a try. my current project will either be htmx or alpine.js. Thank you for your work, in preventing SPA bloat ie providing an alternative
htmx looks like the perfect thing between UnpolyJS and AlpineJS. In Unpoly I miss the optional clientside templating which htmx seems to support as extension. AlpineJS lacks the http stuff (headers, requests). Really exciting times for using old school html without downloading 5000 js files via npm.
What about using alpine and htmx together? So you get the front end reactivity as well