151–160 of 175 posts
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.
This looks amazing -- seems like you can accomplish a significant amount of what constitutes front-end work these days with htmx. The examples are compelling: https://htmx.org/examples/ There is a slight deal-breaker for me. Much of the functionality revolves around hx-swap'ing i.e. writing the contents of a response as HTML into/around tags. This requires the server-side to return HTML instead of JSON. From the docs…
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?
I wish some of this ( or All of it ) are implemented inside browser and no longer need any Javascript to function. Web App still has its place. But 90% of the web are Web Pages or Interactive Web Page, not Apps. While Every time I point this out there will be someone stating Gmail as an example of Web Apps, but we will soon have Hey.com to prove it doesn't need to be that way. However browser vendors and standards bo…
It's actually web app developers doing the most to push the web in the direction of web apps.
I wish some of this ( or All of it ) are implemented inside browser and no longer need any Javascript to function. Web App still has its place. But 90% of the web are Web Pages or Interactive Web Page, not Apps. While Every time I point this out there will be someone stating Gmail as an example of Web Apps, but we will soon have Hey.com to prove it doesn't need to be that way. However browser vendors and standards bo…
- make something close to an html5 equivalent to asm.js: remove all ambiguous variants, everything we know is slow.
- "ban" all Javascript except some small pre-defined libraries like this.
- make a catchy name (html-core? web-core?) and a validator for it. Call it a standard.
It will be fast in all browsers, maybe really fast in browsers that care to optimize for it.
If it becomes a thing we can create new simpler pure web browsers (as opposed to todays application platforms that we will then start calling old or legacy html :-)
Earlier quoted context omitted.
> How does one use this for AJAX without rewriting existing backends? I've never actually used a backend that couldn't return arbitrary content types. Those exist?
> Those exist? For sure. Most of the backends we write only return JSON. If you request HTML or any other content-type, we return nothing. We just don't implement it. If you write your backend from scratch and only intend for it to be used only with your web front-end, you can make it return bits of HTML (I have several applications in jQuery that work like this -- the value of the response just gets inserted via ("#…
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
What about accessibility? It'd be great to see the docs and examples put more focus on accessibility, both for non-JS clients and for clients that may be better served by not replacing elements, like screen readers. And, based on some of the comments here, it seems like some people may have forgotten how to do anything that doesn't depend on AJAX. ;-)
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?
Maybe one could make a service worker to intercept and transform the JSON to HTML.
Earlier 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?
It wouldn't be the prettiest HTML but you could work with it via CSS and JS.
Earlier quoted context omitted.
> Those exist? For sure. Most of the backends we write only return JSON. If you request HTML or any other content-type, we return nothing. We just don't implement it. If you write your backend from scratch and only intend for it to be used only with your web front-end, you can make it return bits of HTML (I have several applications in jQuery that work like this -- the value of the response just gets inserted via ("#…
But it could
Much easier to use client-side templating as suggested by the author.