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

Htmx Is the Future

quii.dev

Post reply on HN
Print view View original

131–140 of 875 posts

Re: Htmx Is the Future

#131

Post by yawaramin »

obpe wrote: post #81
pphysch wrote: post #34

Earlier quoted context omitted.

Some validations require capabilities that you don't want/need the client to have. There are also validations that can improve UX but aren't meaningful on the server. Like a "password strength meter", or "caps lock is on". Religiously deploying the same validations to client and server can be done, but it misses the point that the former is untrusted and just for UX. And will involve a lot of extra engineering and un…

I see, I have never implemented those types of validations. We do religiously deploy the same validation on client and server to explicitly avoid the mismatch of client/server validation. Having the client submit "valid" input only to have server reject it is something we have run into. Having only client side validation is something I have never run into. Also, in my opinion things like you suggest you shouldn't do.…

> A password strength metre is only going to give attackers hints at the passwords you have in your system

No, it's not. A password strength meter just shows you the randomness of an input password, it doesn't have anything to do with passwords already in the system.

Re: Htmx Is the Future

#132

Post by jksmith »

You know, nobody likes this argument, but desktop is still just better. Yeah, yeah, the updates, security issues, I get it, but the tools are simple better, render faster, better functionality/complexity ratio, less gnashing of teeth.

Re: Htmx Is the Future

#133

Post by lolinder »

aidenn0 wrote: post #12

> Managing state on both the client and server This is a necessity as long as latencies between the client and server are large enough to be perceptible to a human (i.e. almost always in a non-LAN environment). [edit] I also just noticed: > ...these applications will be unusable & slow for those on older hardware or in locations with slow and unreliable internet connections. The part about "slow and unreliable intern…

> This is silly; I almost exclusively use compiled languages, so compilation is happening no matter what; targeting JS (or WASM) isn't that different from targeting a byte-code interpreter or hardware...

I agree with everything else you said, but having followed the development of Kotlin/JS and WASM closely I have to disagree with this statement.

JavaScript is a very bad compilation target for any language that wasn't designed with JavaScript's semantics in mind. It can be made to work, but the result is enormous bundle sizes (even by JS standards), difficult sourcemaps, and terrible performance.

WASM has the potential to be great, but to get useful results it's not just a matter of changing the compilation target, there's a lot of work that has to be done to make the experience worthwhile. Rust's wasm_bindgen is a good example: a ton of work has gone into smooth JS interop and DOM manipulation, and all of that has to be done for each language you want to port.

Also, GC'd languages still have a pretty hard time with WASM.

Re: Htmx Is the Future

#134

Post by fogzen »

Server-side apps cannot provide optimistic UI. No matter how you feel about it, they are limited in this capability compared to client-side apps. The user doesn’t care about the technology. For example, imagine a todo app that shows a new todo immediately. Or form validations that happen as soon as data is entered. That’s a superior experience to waiting on the server to continue interaction. Whether that’s harder to engineer is irrelevant to the user. We should be striving for the best possible user experience, not what we as engineers personally find easy or comfortable.

HTMX is cool. HTMX may fit your needs. But it’s not enough for providing the best possible user experience.

Re: Htmx Is the Future

#136

Post by 0x445442 »

chasd00 wrote: post #97
Veuxdo wrote: post #45

I like how the cons of SPA are "you have to manage state" and "clients have to execute code". I mean, aren't these baseline "get computers to do stuff" things?

back in the olden days a web browser was largely considered just a program to read documents stored on other systems that can be linked to each other sent over a simple stateless protocol. Then we started to be able to collect user input, then a hack was invented to maintain state between requst/response pairs (cookies), then a scripting language etc There are many use cases out there where not treating a browser as…

When do you want the browser to be anything more than a hypertext document viewer and why?

Re: Htmx Is the Future

#137

Post by minusf »

BiteCode_dev wrote: post #93
hirako2000 wrote: post #76

Earlier quoted context omitted.

I have no love for unnecessarily bloated dependency graphs, but we can't have the cake and eat the cake too. Next.js for example, comes packed with anything and everything one might need to build an app. Sitting on the promise of hyperproductivity with "simplicity". Plus, is made of single responsability principles set of modules, kind of necessary to build a solve-all needs framework. And it does that. A bit like An…

Django comes with a lot: auth, caching, csrf protection, an orm, the admin, form workflow, templating, migrations, i18n, and yet doesn't come with thousands of deps.

it comes exactly with 2 on latest python versions

Re: Htmx Is the Future

#139

Post by PaulHoule »

I worked for a startup that built a React + Scala system for building training sets for machine learning models. At the time I was involved this had a strong research component, particularly we frequently had to roll out new tasks, and in fact we were working actively with new customers to adapt to their needs all the time.

The build for the system took about 20 minutes, and part of the complexity was that every new task (form where somebody had to make a judgement) had to be built twice since both a front end and back end component had to be built so React was part of the problem and not part of the solution. Even in a production environment this split would have been a problem because a busy system with many users might still need a new task added from time to time (think AMZN's MTurk) and forcing people to reload the front end to work on a new task defies the whole reason for using React.

It all was a formula for getting a 20 person team to be spinning its wheels, struggling to meet customer requirements and keeping our recruiters busy replacing developers that were getting burnt out.

I've built several generations of my own train-and-filter system since then and the latest one is HTMX powered. Each task is written once on the back end. My "build" process is click the green button on the IDE and the server boots in a second or two. I can add a new task and be collecting data in 5-10 minutes in some cases, contrasted to the "several people struggling for 5 days" that was common with the old system. There certainly are UIs that would be hard to implement with HTMX, but for me HTMX makes it possible to replace the buttons a user can choose from when they click a button (implement decision trees), make a button get "clicked" when a user presses a keyboard button and many other UI refinements.

I can take advantage of all the widgets available in HTML 5 and also add data visualizations based on d3.js. As for speed, I'd say contemporary web frameworks are very much "blub"

http://www.paulgraham.com/avg.html

On my tablet via tailscale with my server on the wrong end of an ADSL connection I just made a judgement and timed the page reload in less than a second with my stopwatch. On the LAN the responsiveness is basically immediate, like using a desktop application (if the desktop application wasn't always going out to lunch and showing a spinner all the time.)

Re: Htmx Is the Future

#140

Post by dpistole »

majormajor wrote: post #101

> HTMX allows you to design pages that fetch fragments of HTML from your server to update the user's page as needed without the annoying full-page load refresh. I've been on the sidelines for the better part of a decade for frontend stuff, but I was full-stack at a tiny startup in 2012ish that used Rails with partial fragments templates for this. It needed some more custom JS than having a "replacement target" annota…

From a front end perspective I think the selling points I see pitched for these new server side frameworks are "SEO" and "speed".

SEO I personally think is a questionable motivation except in very specific use cases.

Speed is almost compelling but the complexity cost and all the considerations around how a page is structured (which components are server, which are client, etc) does not seem worth the complexity cost IMO. Just pop a loading animation up in most cases IMO.

I think I'm stuck somewhere in the middle between old-hacker-news-person yelling "lol were just back at index.html" and freshly-minted-youtube-devs going "this is definitely the new standard".

Post reply on HN