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

Moving from React to htmx

htmx.org

Post reply on HN
Print view View original

171–180 of 326 posts

Re: Moving from React to htmx

#171

Post by jbverschoor »

throwawaysfdc wrote: post #158
jbverschoor wrote: post #142

Earlier quoted context omitted.

I’ve used JSF when it was still beta. It was chosen by an external “architect” as the front end for a big site with millions of views (he was anticipating that JSF would be come popular, and a big project with it would be good on his resume). Salesforce (classic) is JSF. It’s full of bugs and quirks. But it’s kind of nice in certain situations. The big problem here is performance load on both client and server. State…

> Salesforce (classic) is JSF. Here's a little bit of trivia... The Visualforce framework (that customers can write interactive pages in, and a small minority of the standard UI is build in) is based on JSF, but most of Salesforce classic standard UI is written in a home-grown system that generates HTML described in imperative Java. It's more akin to an HTML generating Tk.

Makes sense and they had a few big architectural changes of their front end. Lighting is unbelievably slow

Re: Moving from React to htmx

#172

Post by kaetemi »

runald wrote: post #127
qwertyzxcvmnbvw wrote: post #71

Earlier quoted context omitted.

Side note: in Thailand and the Philippines, at least, mobile internet is blazing fast and not more expensive.

As someone living in one of those countries, I beg to differ. Cheap maybe, but mobile internet is neither fast nor stable.

It's mostly the metal roofs everywhere blocking the signal.

Re: Moving from React to htmx

#173

Post by withinboredom »

singularity2001 wrote: post #156
mediumdeviation wrote: post #56

Earlier quoted context omitted.

For a real world example of this, GitHub uses server-side rendered fragments. Working with low latency and fast internet in the office, the experience is excellent. Trying to do the same outside with mobile internet, and even with a 5G connection, the increased latency makes the application frustrating to use. Every click is delayed, even for simple actions like opening menus on comments, filtering files or expanding…

Github does? Maybe that's the reason why I often get the error message: "page took too long to render" after ten seconds of waiting. example: https://github.com/pannous/hieros/wiki/%F0%93%83%80 this is admittedly a complicated markdown file, however it often fails on much simpler files.

I hate it when devs implement their own timeouts. That’s handled at the network level, and the socket knows if progress is being made. I was stuck using 2G data speeds for a couple of years and I loathed this behavior.

Re: Moving from React to htmx

#174

Post by kaeshiwaza »

kgeist wrote: post #151

Doesn't server rendering increase load on the server? I like to off-load as much processing to the user's browser as possible. We have ~1 million users and I like to think that when we off-load a lot of processing to the browser, we basically have 1 million servers for free.

Rendering html doesn't consume a lot more than rendering json, specially that with htmx you'll render small fragments... Anyway the bottleneck is most of the time on the database.

Re: Moving from React to htmx

#176

Post by temp20202020 »

I am in a remote village in India, Assam, Barpeta, Maranadir par. htmx or hotwire or pjax works great here on my 4g mobile network (Jio, Airtel) and surprisingly 3g BSNL (govt. supported isp). I think at least in India internet speed problem is a solved problem.

Re: Moving from React to htmx

#177

Post by deniz-a »

ksbrooksjr wrote: post #81
flexterra wrote: post #77

Earlier quoted context omitted.

Validating data on the client and not doing it again on the server will lead to security vulnerabilities. At the very least you will end up duplicating that validation code.

If I were using htmx I would still want to validate data on the client and the server. If you don't validate data on the client, then you're effectively allowing clients to DDOS your server with invalid data.

Client side validation does not protect against that. You can't prevent people from making requests to your server without your client, i.e. `curl https://example.com/api --data 'dkfjrgoegvjergv'`.

Re: Moving from React to htmx

#178

Post by nathanappere »

nine_k wrote: post #130
jaytaylo wrote: post #28

Earlier quoted context omitted.

How was it worse than the current state of affairs of complexity with React? Bowser, npm, typescript, obfuscation, compressors, build pipelines.. it’s a lot. Life at the front-end today is so discombobulated, creating a bunch of backend APIs which will generally only be used and consumed by a single browser front-end. I’m genuinely curious, because I never used JSF except for a single school exercise

Frankly, with yarn, typescript, and a packaging / compressing tools of your choice, web frontend development is pretty pleasant and efficient these days. (To say nothing of using Elm, if you can afford it.) Typescript is particular is nice compared to, say, Python, and even to Java (though modern Java is quite neat.) The only unpleasant part is dependency management, but you have the same, or worse, with Python or Ru…

Really curious, how is it worse with Ruby?

Re: Moving from React to htmx

#179

Post by ksbrooksjr »

deniz-a wrote: post #177
ksbrooksjr wrote: post #81

Earlier quoted context omitted.

If I were using htmx I would still want to validate data on the client and the server. If you don't validate data on the client, then you're effectively allowing clients to DDOS your server with invalid data.

Client side validation does not protect against that. You can't prevent people from making requests to your server without your client, i.e. `curl https://example.com/api --data 'dkfjrgoegvjergv'`.

Well yeah obviously you can bypass the client code and directly connect to a server. That's not my point.

Client side validation doesn't prevent a malicious user from sending invalid requests, but it can prevent legitimate users from sending invalid data to your server accidentally. In fact, if I see validation failures showing up in my server logs for something I know should have been filtered out via client side validation, I can mark that ip address as being potentially malicious and rate-limit their future requests.

And as a user I would rather find out about validation issues immediately instead of waiting for a network round trip to the server. If I'm typing in a password for example and it doesn't meet the website's length/complexity requirements, I'd rather know as I'm typing instead of waiting for an HTTP request to complete. That extra HTTP request is wasting the user's bandwidth and the server's resources.

Re: Moving from React to htmx

#180

Post by thdespou »

wruza wrote: post #167
Winsaucerer wrote: post #155

Earlier quoted context omitted.

Here's one I've experienced. Suppose you have a table of customers, and you want to show an extra column of data on that page showing total orders, if and only if the viewer of that table has the manager role. With an SPA, you'll be building an API (perhaps a 'REST' one, or GraphQL) to expose all the data required, such as customer name, email, etc, as well as the extra 'total orders' field iff they have the manager…

manager role column Tbh, I’d prefer a runtime which would be itself aware of such metadata, knew the role out of a request/session context and could build a ui table based on all-columns-ever template, from a query automatically built for this specific case, because querying and throwing away totals may be expensive. This manual “do here, do there” is a sign of a poor platform (not that we have a better one) and code…

Yes. It's a poor design. The UI shouldn't care about permission or visibility rules. Instead It should only take data and render tables based on their data+metadata. All the permission logic should be done in the API level based on the caller ID/context.
Post reply on HN