Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

htmx

htmx.org

Post reply on HN
Print view View original

281–290 of 291 posts

Re: htmx

#281

Post by yawaramin »

hardwaregeek wrote: post #273
yawaramin wrote: post #267

Earlier quoted context omitted.

Sure. With evergreen browsers. For anyone using old devices with outdated hardware--tough luck! They can, I guess, go buzz off and leave you in peace to write Modern JS. After all, that's the most important thing.

At this point you'd need a 10 year old never-updated browser to run into this issue. Which, sure, maybe you need to cater to people who use browsers 10 years out of date. I don't think it's a huge market frankly and 10 year old browsers have larger issues like security.

I mean, JavaScript doesn't just run in browsers. Some older forms of JavaScript run in all kinds of software--embedded in Windows (JScript), embedded JavaScript engines in other runtimes (Java, Qt Quick), older Node.js software that people are stuck on for whatever reason. I'm sure many people don't care about making all of those devices obsolete but maybe with a slight amount of effort we can try to slow down the inevitable filling of landmines with perfectly workable devices?

Re: htmx

#282

Post by hardwaregeek »

yawaramin wrote: post #281
hardwaregeek wrote: post #273

Earlier quoted context omitted.

At this point you'd need a 10 year old never-updated browser to run into this issue. Which, sure, maybe you need to cater to people who use browsers 10 years out of date. I don't think it's a huge market frankly and 10 year old browsers have larger issues like security.

I mean, JavaScript doesn't just run in browsers. Some older forms of JavaScript run in all kinds of software--embedded in Windows (JScript), embedded JavaScript engines in other runtimes (Java, Qt Quick), older Node.js software that people are stuck on for whatever reason. I'm sure many people don't care about making all of those devices obsolete but maybe with a slight amount of effort we can try to slow down the in…

Okay, those cases seem like situations where you'd need to be explicitly targeting those devices. Like if you're shipping new code to users that is being run on an old runtime, then sure, you should make sure that code is legacy JS. I don't see how that is unreasonable?

Re: htmx

#283

Post by JodieBenitez »

0xblinq wrote: post #244
replwoacause wrote: post #237

Earlier quoted context omitted.

I am also interested in why you like Unpoly more. Genuinely curious because I use and like HTMX and don’t really understand what you get with Unpoly that you don’t with HTMX.

I could ask the same question I guess, what do you get from HTMX that I can't get from Unpoly?. I think you can achieve the same thing with both, but Unpoly is higher level, that means I have to write less attributes/code to achieve the same stuff I guess. "Compilers" are also a nice way to attach custom code. All the helpers for form validations, the extremely easy way it provides to do modals, and layers in general…

from the tutorial:

"You can update multiple fragments from a single request by separating selectors with a comma."

"The server still renders full HTML pages, but we only use the targeted fragments and discard the rest"

Wow... Of course full pages should have a lean markup, otherwise a lot of data transfered could be useless, but that's a pretty neat feature

Re: htmx

#284

Post by thinkingemote »

winrid wrote: post #197

I really want to use htmx on the next project but I am not sure how to make it handle poor network connections yet. The app I'm building will be used in areas with poor mobile connections - I want to submit a form, add it to a list and say it's pending saving, while the user can add more. Have to use hyperscript probably? Can trivially do it in vanillajs so I'm sure it's possible?

Browser dev tools have a throttle mode, might help.

Re: htmx

#285

Post by 0xblinq »

JodieBenitez wrote: post #283
0xblinq wrote: post #244

Earlier quoted context omitted.

I could ask the same question I guess, what do you get from HTMX that I can't get from Unpoly?. I think you can achieve the same thing with both, but Unpoly is higher level, that means I have to write less attributes/code to achieve the same stuff I guess. "Compilers" are also a nice way to attach custom code. All the helpers for form validations, the extremely easy way it provides to do modals, and layers in general…

from the tutorial: "You can update multiple fragments from a single request by separating selectors with a comma." "The server still renders full HTML pages, but we only use the targeted fragments and discard the rest" Wow... Of course full pages should have a lean markup, otherwise a lot of data transfered could be useless, but that's a pretty neat feature

You can always detect server side if it’s an Unpoly request, and which fragments it is asking for as that information goes in the request headers.

Or point the request to another view that just returns those fragments.

But I don’t think many apps need this level of optimizations.

Re: htmx

#286

Post by tentacleuno »

PaulHoule wrote: post #48
tentacleuno wrote: post #40

Earlier quoted context omitted.

You don't have to build JavaScript; it runs natively in the browser. In fact, the only time when you would have to consider a dedicated build step is if you were using something like TypeScript, or if you wish to use external modules. In the case of external modules, check out ES6's import syntax. You can import from a URL just like it's an NPM module. I believe a few CDNs are designed to facilitate this use-case too…

That's how I use D3.js. But for the React programs I work on at work we are already committed to a build process, there are bits of Typescript, SCSS, and for production at least tree-shaking and minimization seem a most for something with that many moving parts.

SCSS? Never used it myself -- normally CSS in JS. I definitely understand that it's hard to move away from big build processes though.

Re: htmx

#287

Post by JodieBenitez »

0xblinq wrote: post #285
JodieBenitez wrote: post #283

Earlier quoted context omitted.

from the tutorial: "You can update multiple fragments from a single request by separating selectors with a comma." "The server still renders full HTML pages, but we only use the targeted fragments and discard the rest" Wow... Of course full pages should have a lean markup, otherwise a lot of data transfered could be useless, but that's a pretty neat feature

You can always detect server side if it’s an Unpoly request, and which fragments it is asking for as that information goes in the request headers. Or point the request to another view that just returns those fragments. But I don’t think many apps need this level of optimizations.

I am now converting an app from htmx to unpoly. Indeed, much less attributes to write and now my app has proper browser history and full page rendering linked to this history, all with minimal effort. This is brilliant, how come I never heard of unpoly ? Thanks for pointing to it.

Re: htmx

#288

Post by 0xblinq »

JodieBenitez wrote: post #287
0xblinq wrote: post #285

Earlier quoted context omitted.

You can always detect server side if it’s an Unpoly request, and which fragments it is asking for as that information goes in the request headers. Or point the request to another view that just returns those fragments. But I don’t think many apps need this level of optimizations.

I am now converting an app from htmx to unpoly. Indeed, much less attributes to write and now my app has proper browser history and full page rendering linked to this history, all with minimal effort. This is brilliant, how come I never heard of unpoly ? Thanks for pointing to it.

It has a marketing problem for sure, given how everyone loves HTMX and nobody even heard of Unpoly.

Not that I'm a fan of doing marketing of tech, but... that's the explanation I find for it.

Re: htmx

#289

Post by roguas »

halfcat wrote: post #73
jhp123 wrote: post #15

My problem with this approach is the same one raised by Dijkstra against the goto statement. These update actions are too unrestricted and don't offer any way to analyze the program's progress systematically, based on the program source code.

The same can be said of a React frontend that talks to a JSON API. There is some structure, organization, and convention to the API endpoints, one-way data flow, and so on. Otherwise it’s chaos. On our most recent project we do the same with Django and HTMX. Organized endpoints by component. Composable, reusable server-side components with django-components [1]. And we’ve been orders of magnitude more productive, shi…

How same could be said? React makes calls to json api typically - both sides are very inspectable. Given that you have to resort to session for state, things can get messy on the data layer (a poison pill for stateless rest json api)

Re: htmx

#290

Post by elchief »

egeozcan wrote: post #64
trog wrote: post #34

Earlier quoted context omitted.

> You could follow something like this: https://learn.svelte.dev/tutorial/welcome-to-svelte I think if you are, like me, someone who for various reasons never followed the JavaScript ecosystem for various reasons over the last few years (in my case because I was working on exclusively backend APIs in C#), coming back into trying to do any frontend website is just ten thousand people saying "it's not that hard, just f…

htmx is yet another one of those forty hundred humongous different frameworks. It also uses a DSL that has no application outside of its specific corner. It also forces you to return HTML fragments via AJAX. By the way I did use intercooler.js (prev. iteration of htmx) intensively and while I liked it at first, it really added up to being an HTML/JS soup when other developers started extending.

> humongous

14kb

> It also forces you to return HTML fragments via AJAX.

not true, you can return anything. support client-side templating for JSON etc

Post reply on HN