111–120 of 175 posts
Earlier quoted context omitted.
I am sure you must be referring to someone from the Katholieke Universiteit Tilburg.
it's a funny meme, but it was never called that. See from wikipedia: >Omdat Katholieke Universiteit Tilburg tot een ongewenste afkorting zou leiden, werd het Katholieke Universiteit Brabant (KUB).
One of the problems I see is that now anyone that was using intercooler is using an outdated and quite likely to become unmaintained library and be forced to migrate/rewrite things.
Similar projects: https://github.com/stimulusjs/stimulus https://github.com/alpinejs/alpine https://github.com/intercoolerjs/intercooler-js
Earlier quoted context omitted.
Yes, but you shouldn't use it as a simple drop-in. The minified version via CDN is like 1.7 MB ... at least they mention you should not use it in the docs and instead configure it to your needs.
tailwind is 1.7MB of CSS? ....whyy?
Similar projects: https://github.com/stimulusjs/stimulus https://github.com/alpinejs/alpine https://github.com/intercoolerjs/intercooler-js
You are comparing apple to oranges :) alpine and stimulus are frameworks (doing all sorts of stuff: css animation, data objects, etc) while htmx is a library focusing solely on ajax. From your list, the only similar project to htmx is intercooler-js, but... htmx is actually the new version of intercooler-js (both projects by the same author).
htmx supports animations too, and it has extensions to add further functionality. Of course those projects differ in their functional range, but they share the way they work; by adding attributes to HTML.
Earlier quoted context omitted.
I'm not sure I get what you're saying? I think you're saying that having html returned from the backend "seems questionable" and is a "type of bad programming". But that can't be right because that's mostly how the web works? Make a request to a server, server returns html. Is your issue that it's partial "random" content? How does that make it worse? It's a tried and true solution. The hamburger menu in amazon.com d…
I agree that the objection doesn't hold up given how many websites are made, but I think they mean that a REST API shouldn't be returning HTML, which is true. Unfortunately using the replace feature would mean rewriting existing APIs. Or, you could use the client side template feature of htmx which supports rendering JSON into HTML using a templating language: https://htmx.org/extensions/client-side-templates/
For 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…
hello, 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
This way they can create entire products with zero backend code by simply calling 3rd party API.
This is probably also some very nice static blog engine concept to imagine around this.
And some mix with VueJS as well.
Earlier quoted context omitted.
tailwind is 1.7MB of CSS? ....whyy?
id imagine that you get a lot of rules when you have a whole bunch of different "margin-top- ". the idea is probably to rely on some CSS tree-shaking/"dead CSS elimination" tool to only keep the ones you need
Earlier quoted context omitted.
On a related note, I recently discovered that when you use semantically styled HTML, the difference between a JSON payload and an HTML payload is almost negligible (basically, the close tags). Why not transmit in a format that the browser already understands natively?
yeah, the payload is almost zero difference, a round off error compared w/ connection latency a lot of folks conflate AJAX w/ JSON apis, and can't easily imagine an endpoint returning partial bits of HTML that have nothing to do with a public JSON API worse, people have been misled to believe that JSON APIs are REST-ful we have a lot of work to do
That matches by experience and is kind of ironic, considering that the X in "AJAX" once stood for XML. ;)