[HN Gopher] Htmx Is a Erlang
       ___________________________________________________________________
        
       Htmx Is a Erlang
        
       Author : alfonsodev
       Score  : 92 points
       Date   : 2023-12-12 11:19 UTC (11 hours ago)
        
 (HTM) web link (matt.sh)
 (TXT) w3m dump (matt.sh)
        
       | eddd-ddde wrote:
       | The whole "htmx is the most dangerous thing to exist" is so funny
       | to me.
       | 
       | Someone that does not understand sanitisation boundaries has no
       | business working on web development. This is how you end up with
       | html in your database, people just render whatever piece of data
       | because it "just works" in frameworks like react (I've seen it
       | myself in production).
        
         | moritzwarhier wrote:
         | Replace htmx with alpine js and I think the twitterers have
         | some point. Eh, probably even with htmx.
         | 
         | It is true that the average WordPress developer might not care
         | about XSS, and to refute one specific point: I have seen third-
         | party returning HTML, plenty of them.
         | 
         | Deliberately acting on the contents response instead of
         | directly executing code from said party forces you to think
         | about XSS.
         | 
         | But it's not specific to htmx of course, it would be the same
         | when using innerHTML or something while using a field in a JSON
         | API response.
         | 
         | It's true that frameworks like React have safer defaults than
         | Vanilla JS in that regard.
        
       | nesarkvechnep wrote:
       | A Erlang, yeah...
        
       | jlundberg wrote:
       | This read has a surprising amount of depth and funny style.
       | Recommended if you enjoy conversations about web security.
        
         | aidenn0 wrote:
         | YMMV: I agreed with the points, but found the depth to be
         | rather minimal and the style to be completely off-putting.
        
           | ahmedfromtunis wrote:
           | The style is rather confusing, and hinders comprehension
           | rather than improve it.
           | 
           | The text jumps from one topic to the other so abruptly that I
           | had to check multiple times if I'm still reading the same
           | article.
        
             | ezekg wrote:
             | It also jumps between relevant embedded tweets and
             | irrelevant tweets, which I found hard to comprehend.
             | 
             | I guess I'm just not jiving with the author's thought
             | process.
        
       | coolhand2120 wrote:
       | 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
       | but you can pre-render", but there are times when you can't. You
       | could render the whole thing on the backend, but then you'll wait
       | 5-7 seconds at a white page vs. progressive loading. Whatever is
       | taking 5-7 seconds (LCP) is not going to get faster for you in
       | your region by some magical front end dance.
       | 
       | Not every business is the same and no one solution will work for
       | everyone. And concluding that we should "go back to jQuery"
       | really speaks volumes of the author. jQuery was not "the good old
       | days".
       | 
       | The problem with FE is that they seem to be wannabe nodejs BE
       | devs instead of the W3C experts they should be. If FE devs focus
       | on web standards and less on Rube Goldberg machines they would be
       | well served.
        
         | shakabrah wrote:
         | here here. I am very thankful that when i started out a decade
         | ago the first book i read was Designing with Web Standards. I
         | still recommend it to noobs but i can't necessarily blame them
         | for not getting through it when there are more shiny things
         | like React and Vite to learn about.
         | 
         | To read that book now would be largely a history lesson because
         | we no longer have to fight to maintain some quirk between a
         | handful of browser versions. But man, knowing about semantic
         | markup and really getting why that is a thing in the first
         | place is super important.
        
         | felixgallo wrote:
         | 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.
        
           | herrkanin wrote:
           | Not everyone has the luxury to work with competently written
           | backend systems.
        
             | lacrimacida wrote:
             | Not everyone has the luxury to work with competently
             | written front end systems.
        
             | weego wrote:
             | The entire Internet apparently did for years because
             | frontend JS monoliths only appeared halfway though my
             | career.
        
             | ljm wrote:
             | 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.
        
           | ch4s3 wrote:
           | > 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.
        
             | felixgallo wrote:
             | 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.
        
               | pcthrowaway wrote:
               | 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
        
               | WkndTriathlete wrote:
               | And yet somehow Google, Bing, etc. manage to return
               | results in much less than 3 seconds.
        
           | coolhand2120 wrote:
           | If you serve data from a DC in California to the west coast
           | of Australia it will take 10 seconds of just network transfer
           | time. Sometimes data has a high degree of cardinality and
           | cannot be cached. Some companies cannot afford to, or for
           | other reasons cannot, have regional instances of their
           | compute surfaces. This is just one common scenario, there are
           | many others.
           | 
           | > A middling back end system with median complexity is doing
           | 10-100K requests per second per server and is near-perfectly
           | horizontally scalable.
           | 
           | You know perfectly your SLAs without knowing anything about
           | the business, data, or the user access pattern? You don't
           | even need a budget? Impressive!
        
             | hipadev23 wrote:
             | > If you serve data from a DC in California to the west
             | coast of Australia it will take 10 seconds of just network
             | transfer time.
             | 
             | What? Is this a typo or do you think that's true?
        
             | willsmith72 wrote:
             | > If you serve data from a DC in California to the west
             | coast of Australia it will take 10 seconds of just network
             | transfer time
             | 
             | Where did you get that calculation? Looks way way off
        
             | felixgallo wrote:
             | You have no idea what you're talking about. Perth is about
             | a third of a second away from Los Angeles. There is no data
             | that cannot be cached owing to 'high cardinality'. There
             | does not exist a company that is trying to serve Perth
             | traffic from a US CA DC that cannot afford a server that
             | can do 100k RPS.
        
             | firecall wrote:
             | As a fellow Australian here in South Australia, I can say
             | with certainty that I've never had it that bad!
             | 
             | I can measure the difference between US, Singapore and
             | Sydney based DCs, but it's milliseconds.
             | 
             | 10 seconds is abnormal and would indicate to me that
             | something isn't functioning as expected!
        
           | Spivak wrote:
           | Yeah, for anyone reading this that doesn't know these are
           | _embarrassing_ numbers. We call it an outage if our p95
           | latency goes above 100ms for more than a minute. Even if you
           | think this is aggressive 50x slower is not normal. There will
           | be necessarily be tasks that take longer than that but don 't
           | make your user sit there with the page just spinning. Post
           | back when the task is finished asynchronously. Especially on
           | mobile where those kinds of delays are assumed to be issues
           | with the network and users will just hit the x and refresh.
        
           | spinningarrow wrote:
           | 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.
        
             | felixgallo wrote:
             | I've been building backend systems for over 35 years across
             | many industries.
        
           | willsmith72 wrote:
           | It's not 1 request. It's a request waterfall in almost all
           | cases. See the remix homepage for a great demo and pitch on
           | why remix is awesome
           | 
           | https://remix.run/
        
           | sesm wrote:
           | 10-100k RPS is throughput, not latency. There is a well-known
           | latency-throughput tradeoff. For example, Erlang's BEAM VM is
           | optimized for low latency, while JVM is optimized for high
           | throughput.
        
           | firecall wrote:
           | I'm with you on this!
           | 
           | Sure, I can allow users to run reports that take multiple
           | seconds, but I'm generally not delivering that to the browser
           | to be rendered.
           | 
           | And if I was, I'd crash the browser tab. Which is
           | surprisingly easy to do...
        
           | gedy wrote:
           | I've seen this with pretty normal Rails apps that some folks
           | like to praise for the "productivity"
        
         | truculent wrote:
         | > The problem with FE is that they seem to be wannabe nodejs BE
         | devs instead of the W3C experts they should be
         | 
         | What are the best resources for someone interested in being a
         | W3C expert? (Aside from just slogging through
         | https://www.w3.org/TR/)
        
           | codeptualize wrote:
           | MDN is one of the best resources imo
           | https://developer.mozilla.org/
           | 
           | Generally more practical than W3C.
        
             | truculent wrote:
             | Thank you!
        
         | ljm wrote:
         | I think most of the post fell wide of the mark and as much as I
         | hate to be cynical, I feel like the completely tangential
         | Erlang piece is just there to game HN because HN lately can't
         | get enough of Erlang and Elixir.
         | 
         | I don't think there was much to take away from this article
         | except that the author should perhaps spend less time paying
         | attention to the opinion of randos on Twitter.
        
         | troupo wrote:
         | > 5-7 second skeleton loaders are there because backend systems
         | are slow, not because of the front end application.
         | 
         | There are very, cery, _very_ few cases of this. The vast
         | majority of  "applications" we have are due to people not
         | caring.
         | 
         | E.g. a recent Reddit redesign was praised because their time to
         | paint was 2.4 seconds. Their backend rarely responds in more
         | than 0.4 seconds.
         | 
         | > If FE devs focus on web standards and less on Rube Goldberg
         | machines they would be well served.
         | 
         | Why do you think we have these Rube Goldberg machines?
         | Precisely because standards are utter garbage. And doing
         | anything with them leads to _more_ Rube Goldberg machines.
        
       | moritzwarhier wrote:
       | Really enjoyed the tangents and the point makes sense. I hate
       | idiotic frontend hate and I am not a fan of htmx, but I still
       | like its approach - if it makes sense for the website.
       | 
       | I think every developer who has worked using a CMS using
       | traditional templating + "ajax" has reinvented parts of it at
       | some point in their career. At least I have.
       | 
       | If I would find myself in this scenario again, I'd gladly reach
       | for htmx.
       | 
       | Apart from the social media observations, topics tend to be
       | random here, but I like train-of-thought writing.
        
       | slj wrote:
       | The jab at pg referenced in the tweet screenshot's caption was
       | quite funny
        
       | qwertthrowway wrote:
       | Also, check out elixirs EEX (a mix of erlang and htmx, in spirit)
        
       | _dain_ wrote:
       | you know I think this guy doesn't like elon musk. just a feeling
        
         | camdenlock wrote:
         | It's very trendy
        
       | davedx wrote:
       | 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 against people (I'm not a fan of "Devrels"
       | but jeez, that part of this post felt like blatant character
       | assassination) instead of just debating the facts then you're a
       | douche and no better than the people you're disparaging.
       | 
       | I think HTMX is an interesting project that I'll probably give a
       | try at some point. But breathless cultish hype of it has already
       | turned me off. I don't even know if React got this much
       | attention!?
        
         | aidenn0 wrote:
         | Your server already returns code if you are running javascript
         | on your frontend.
         | 
         | Your server already returns arbitrary html (which can include
         | executable code) unless you are running a fully static backend.
         | 
         | HTMX _moves_ where the trust boundary is a bit, but it doesn 't
         | change that it exists at all.
        
         | couchand wrote:
         | > But you can't hand-wave the security concerns of that away...
         | 
         | What security concerns, exactly?
         | 
         | > There is a fundamental difference between your server
         | returning data versus returning code.
         | 
         | If my server returns a bit of something, and then my
         | application code running in the browser takes conditional
         | action based on that return value, was it data or was it code?
        
       | sshine wrote:
       | > _also, 25,000 hours in 15 years? what kind of rookie lazy piece
       | of shit numbers are those? [...]_
       | 
       | Since we're bashing dumb comments with dumb comments, the Twitter
       | comment is actually saying:
       | 
       |  _over 25,000 hours_
       | 
       | Assuming                 - 5 weeks of vacation each year       -
       | 8 hours of work, 5 days a week
       | 
       | That's                 (52 - 5) * 5 days * 8 hours * 15 years =
       | 28.200 hours
       | 
       | If he worked any harder than that, _that 's still over 25,000
       | hours._
        
       | snowstormsun wrote:
       | > ah yes, the famous XSS coming from your own backend API
       | calls...
       | 
       | Author does not seem to understand the concept of XSS. Of course
       | your own API could return user-provided data to trigger XSS
       | attacks. Entering <script>alert(1);</script> in a messenger to
       | see whether its rendered value is escaped correctly is a famous
       | example.
        
         | freen wrote:
         | If that's the case, and your backend doesn't sanitize inputs,
         | you've already been owned, regardless of your front end
         | framework.
        
         | andrewflnr wrote:
         | Hence the mentioned hx-disable. Presumably you wrap any user
         | content with that, right?
        
         | kitd wrote:
         | You missed the response though, that the same user input would
         | also cause problems if it was supplied unsanitized via JSON.
        
       | miki123211 wrote:
       | > htmx, a disciple of hypermedia, available only in hardcover do
       | not look for alternatives, has been manifesting itself into
       | existence recently
       | 
       | As a screen reader user with no way to read words written on
       | paper (short of getting a scanner and spending hours on putting
       | books through it), I _have_ to look for alternatives. I hate it
       | when authors do this. I get why, but it 's still frustrating.
       | 
       | There's also the fact that the author of this article decided to
       | embed X posts as unlabeled screenshots for some unknown reason.
       | This breaks accessibility, copy/paste, translations, flexible
       | screen layouts and probably a bunch of other things I'm not aware
       | of. Putting text in images is never a good idea, much less so
       | when there's a perfectly fine embeds API for GOd's sake.
       | 
       | I'm really saddened to see somebody who claims to care about web
       | standards be so dismissive of accessibility concerns.
        
         | thraxil wrote:
         | I don't know what they're talking about with "available only in
         | hardcover". Hypermedia Systems is here:
         | https://hypermedia.systems/ available in HTML online, ebook
         | format, hardcover, or you could go to the github repo and
         | probably transform the source into whatever format you want:
         | https://github.com/bigskysoftware/hypermedia-systems
         | 
         | X posts as screenshots suck though.
        
         | throwitaway1123 wrote:
         | > htmx, a disciple of hypermedia, available only in hardcover
         | do not look for alternatives, has been manifesting itself into
         | existence recently
         | 
         | I think this whole sentence was meant to be a joke. This
         | "article" is filled with juvenile humor, random tangents, and
         | twitter screenshots. The irony of complaining about people not
         | properly using hypermedia while omitting some of the basic
         | accessibility attributes of hyper text markup language (alt
         | text) is astonishing.
        
       | troupo wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2023-12-12 23:01 UTC)