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

Htmx Is a Erlang

matt.sh

Post reply on HN
Print view View original

51–60 of 80 posts

Re: Htmx Is a Erlang

#51

Post by pcthrowaway »

felixgallo wrote: post #28
ch4s3 wrote: post #16

Earlier quoted context omitted.

> there is no way any competently written back end system takes 5-7 seconds for any reason whatsoever. I'd argue that even a well written system that allows arbitrary date ranges and filtering of data can easily run past that limit. You just can always know ahead of time what some client might request and some strategies for making normal queries fast can make some queries slower. Its tradeoffs all the way down.

definitely not. If you don't already know ahead of time what a client might request, and just let them request anything arbitrarily without regard for whether that data is indexed or cached, then you are not competently writing a backend system.

I didn't realize that a search engine needs to be able to predict 100% of the phrases a user might search for in order to be competent

Re: Htmx Is a Erlang

#52

Post by WkndTriathlete »

pcthrowaway wrote: post #51
felixgallo wrote: post #28

Earlier quoted context omitted.

definitely not. If you don't already know ahead of time what a client might request, and just let them request anything arbitrarily without regard for whether that data is indexed or cached, then you are not competently writing a backend system.

I didn't realize that a search engine needs to be able to predict 100% of the phrases a user might search for in order to be competent

And yet somehow Google, Bing, etc. manage to return results in much less than 3 seconds.

Re: Htmx Is a Erlang

#53

Post by gedy »

felixgallo wrote: post #7
coolhand2120 wrote: post #5

Reading that entire thing was a struggle. Really feels like _everyone_ is wrong here. Yes the current state of FE development is overly dogmatic and cultish. But it always has been. On the other hand the frameworks and build systems are solving actual problems, they're not there for looks. 5-7 second skeleton loaders are there because backend systems are slow, not because of the front end application. You can say "oh…

there is no way any competently written back end system takes 5-7 seconds for any reason whatsoever. A middling back end system with median complexity is doing 10-100K requests per second per server and is near-perfectly horizontally scalable.

I've seen this with pretty normal Rails apps that some folks like to praise for the "productivity"

Re: Htmx Is a Erlang

#54

Post by bsder »

felixgallo wrote: post #7
coolhand2120 wrote: post #5

Reading that entire thing was a struggle. Really feels like _everyone_ is wrong here. Yes the current state of FE development is overly dogmatic and cultish. But it always has been. On the other hand the frameworks and build systems are solving actual problems, they're not there for looks. 5-7 second skeleton loaders are there because backend systems are slow, not because of the front end application. You can say "oh…

there is no way any competently written back end system takes 5-7 seconds for any reason whatsoever. A middling back end system with median complexity is doing 10-100K requests per second per server and is near-perfectly horizontally scalable.

> there is no way any competently written back end system takes 5-7 seconds for any reason whatsoever.

Sure there is--ad networks.

Remember when 100ms was considered fatal? Funny how that went right out the window when the big companies decided that shoveling more ads at users was more profitable than anything else.

The current state of web development is all to paper over the idiocies brought along by serving ads.

Those of us who do web development and don't have to serve ads can pretty much use anything and hit metrics under 100ms and can scale for a very, very long time.

Re: Htmx Is a Erlang

#56

Post by c-cube »

troupo wrote: post #49

I find all the marketing, advertising intentional or not, around HTMX really obnoxious. Does it have its merits? Maybe? I don't know, I can never get past the memes and shit-slinging. Or past them superficially co-opting terms they have nothing to do with like Erlang, or hypermedia. It's a toy mascarading as a serious tool.

It's related to hypermedia though? The whole point is to go back to servers returning hypermedia (ie html) instead of json. How is that not related?

Re: Htmx Is a Erlang

#57

Post by recursivedoubts »

troupo wrote: post #49

I find all the marketing, advertising intentional or not, around HTMX really obnoxious. Does it have its merits? Maybe? I don't know, I can never get past the memes and shit-slinging. Or past them superficially co-opting terms they have nothing to do with like Erlang, or hypermedia. It's a toy mascarading as a serious tool.

if you want to just have a serious look at htmx, I recommend the book, which is free online:

https://hypermedia.systems

i am willing to admit that i get a little wild on the ol' twitters and understand if that isn't everyone's cup of tea (otoh, you probably wouldn't have heard of htmx if i went at things the normal way: i'm a solo dev in montana.)

Re: Htmx Is a Erlang

#58

Post by financltravsty »

spinningarrow wrote: post #32
felixgallo wrote: post #7

Earlier quoted context omitted.

there is no way any competently written back end system takes 5-7 seconds for any reason whatsoever. A middling back end system with median complexity is doing 10-100K requests per second per server and is near-perfectly horizontally scalable.

I cannot fathom how you arrived at that conclusion - there are so many systems that need to display the results of complex data queries where caching or precomputing the results does not make sense - waiting several seconds for results would be normal in those cases.

I will echo what the parent said: there’s no way your backend is taking seconds (fucking seconds) to return data unless there is something terribly wrong with your system.

Complex queries should be optimized. The only time I have run into query issues is when: I was lazy, and didn’t want to optimize the query/schema/data layout and structures; the system was built by someone of questionable sanity and skillset; or the generated data is legitimately compute intensive, requiring lots of math i.e. more ops and cycles, but at that point it’s a report and the user can wait for it to gen (but in this case it is a lot of math that hasn’t taken advantage of parrallization).

In the wild, I’ve mostly seen people having zero clue what they’re doing (this includes management, who are as culpable for not caring about perf).

Re: Htmx Is a Erlang

#59

Post by nightlyherb »

davedx wrote: post #17

It's powerful to have your front-end library automagically run code returned by your API, sure. But you can't hand-wave the security concerns of that away by ridiculing the people trying to discuss them. There is a fundamental difference between your server returning data versus returning code. If you don't want to accept that, fine, it's your project, or career, whatever. But if you conduct extensive ad hominems aga…

Security-wise, how is a server returning HTMX any different from a server returning HTML with forms? The clients both have the same capabilities, no?

Re: Htmx Is a Erlang

#60

Post by szszrk »

ljm wrote: post #39
herrkanin wrote: post #10

Earlier quoted context omitted.

Not everyone has the luxury to work with competently written backend systems.

There was a time where a request taking even 500ms was considered to be slow, and then all of a sudden it just became normal to see API traces where requests would take over a second, or multiple seconds, and people would just shrug at it. Even a backend roughly cobbled together in PHP4 with Varnish running on top of it would considerably outperform some of the stuff that is accepted as 'good enough' today.

> with Varnish running on top

Like it's a trivial task. If it is... the whole system wasn't that complicated and likely similar results could be achieved without external caching.

Post reply on HN