[HN Gopher] Htmx is part of the GitHub Accelerator
___________________________________________________________________
Htmx is part of the GitHub Accelerator
Author : jjdeveloper
Score : 830 points
Date : 2023-08-16 10:19 UTC (12 hours ago)
(HTM) web link (htmx.org)
(TXT) w3m dump (htmx.org)
| papruapap wrote:
| Personally I dont like it. I think this will look as good as
| "everything in YAML" for CI/CD on an non-trivial codebase.
| PedroBatista wrote:
| I've been a HTMX fan "since before was cool"..
|
| Very happy for the recent attention and "success". Also enjoying
| the shitposting and backlash mostly from the front-end crowd who
| believe the Web was invented in 2013 and they "made that city".
| :)
|
| I'm biased since the time Backbone.js came around, I understood
| part of the pain but was moderately skeptical, fast forward to
| React with the young energetic bros building dead simple 5 page
| websites with a Rube Goldberg setup of front-end frameworks, I've
| cashed out my tech chips and never touched those things.
| gemstones wrote:
| Do you think that the frontend crowd similarly thinks that you
| build dead simple 5 page websites with a Rube Goldberg setup of
| back-end frameworks?
|
| I certainly do.
| mstade wrote:
| Many of the ideas and concepts in htmx are things we worked on
| starting around 2012 at a top tier investment bank.
| Implementation details differ quite significantly, but the idea
| of hypermedia driven applications was core to everything we
| did.
|
| We unfortunately weren't able to win hearts and minds around
| these concepts in the long run, and blog driven development
| (a.k.a. cargo culting) replaced our efforts. I feel somewhat
| redeemed now that HTMX seems to increase in popularity, it's
| nice to see that we weren't alone in thinking along these
| concepts.
|
| Of course, if the concepts were strong that implies my
| execution wasn't, so maybe I shouldn't feel so good about it
| after all... :o)
| sodapopcan wrote:
| This was a time when people were shouting "separation of
| concerns" without really understanding what that meant.
| Mixing the html/css/js required to make up one discreet UI
| concern? Heresy! Requiring at least three files to describe a
| discreet UI concern? TheOneTrueWay!
| gedy wrote:
| I remember the issue to be also that managing UI state on
| the server side was a load issue that many places didn't
| want to deal with (e.g. Wicket, etc). The vibe at the time
| JS client apps came out in my circles was "thank God we can
| get rid of this UI stuff."
|
| That's still an issue I have with HTMX, but I understand
| for simple use cases it's fine. I'd rather use HTMX than
| JQuery that's for sure.
| bongobingo1 wrote:
| > blog driven development (a.k.a. cargo culting) replaced our
| efforts
|
| Ironic considering what the OP attributes to HTMX's current
| popularity.
| mstade wrote:
| Fair enough. :o)
| SmellTheGlove wrote:
| Nah, look at it this way:
|
| A good idea or a good product are never enough. You have to
| sell the product in order to have it be successful.
|
| In your situation, you were at a bank, so your TAM was
| roughly 1 enterprise (or maybe a dozen, tops, if divisions
| had federated or siloed tech). And your 1-to-a-handful of
| potential customers were probably of the large and difficult
| to change variety. That's a huge constraint, and not landing
| it there doesn't mean your idea was bad, it just means you
| weren't successful in selling it and I'm going to tell you
| that you probably _couldn't_ have been successful in selling
| it where you were, when you were there. I worked for your
| lazy cousins at the same time - big insurance - and had the
| same issues selling my own ideas internally, if that makes
| you feel any better.
|
| HTMX has no such constraints. It's a decade later and the TAM
| is more or less everyone doing or preferring to do SSR. The
| same/similar good idea, but different place and time.
| zogrodea wrote:
| Or your marketing might not have been the best possibly, or
| people didn't spend enough time with alternative approaches
| to appreciate their downsides and why hypermedia based
| solutions could be better. (Just pointing out other
| possibilities because I don't know if it's a good idea to be
| hard on oneself when one isn't sure about what went wrong.)
| mstade wrote:
| These were internally developed tools, so nothing we really
| marketed externally but yes we definitely could have done a
| better job at our marketing within the organization. A lot
| of the criticism to our approach was typically not so much
| that the ideas were bad, but that they were "different from
| how everyone else does it" and by everyone else they
| typically meant Facebook and Google.
|
| For example, global state management approaches like Redux
| were more or less incompatible with how we approached state
| management. We thought it was insane to build apps around
| the idea of global state stores (and I still do) but Redux
| became all the rage and eventually won the day. There was a
| lot of collateral damage as people then tried to shoehorn
| Redux everywhere. I left around that time, but hear that
| the cycle have repeated a few times since. Redux (and other
| tooling) didn't work out as expected so wheels have been
| invented again over and over. It's the way things go I
| guess, I don't dwell too much on it.
|
| We probably could've done a better job at communicating why
| our approach was better, but ultimately we had limited
| ability to force anyone to use our tooling. There's also a
| hiring aspect in there. As Redux and other libraries that
| were "the thing" started to make their way into job
| descriptions it became harder and harder to convince talent
| that they should join us, because we didn't have that brand
| recognition and used in-house tooling. At some point you
| have to make trade offs and sadly top tier financial
| institutions aren't necessarily known for leading the pack
| in terms of innovation. It's kind of sad really.
|
| Anyway I'm not particularly hard on myself or bitter about
| it at all actually. The self deprecating jab about poor
| execution should be read as tounge-in-cheek really, I'm
| very proud of the work we did back then.
| claytongulick wrote:
| Or it's because you weren't Facebook.
|
| Like angular, react got the huge initial boost in popularity
| because of the brand behind it.
| sesm wrote:
| That's not true, see for example initial announcement on
| HN: https://news.ycombinator.com/item?id=5789055
|
| React didn't get much adoption initially and FB didn't
| spend money on marketing their framework, like Google did
| with Angular. Developers started using React to speed-up
| table rendering in Angular application, and only after some
| performance-related blogposts adoption started to grow.
| mstade wrote:
| Absolutely, brand recognition is hugely important in
| whether something's a success. It can also go the other
| way, great ideas and tooling simply die because the brand
| is tainted.
|
| Not everything Microsoft has produced is terrible, but for
| a while there it seemed all developers I knew couldn't see
| past the brand even if the tooling/products/ideas were
| solid. I feel it's gotten better since Nadella took the
| reins, but the smell still seem to linger sometimes.
| claytongulick wrote:
| I agree - I'm a greybeard, so it's a bit of a bizarre
| world to me where Microsoft is actually a lovely, valued
| open source brand and probably the most ethical
| (depending on your definition) of all the big tech
| companies these days.
|
| Time to go snow skiing in hell, I guess. It's deeply
| frozen over.
| recursivedoubts wrote:
| :) I appreciate you being a long time user and I certainly do a
| lot of s-word posting on the ol' twitters
|
| on the other hand, my hope is that eventually htmx (and, more
| generally, hypermedia) is accepted as a tool, a useful too, but
| just a tool, even by the front-end folks who haven't thought
| very much about hypermedia in a while
|
| i don't see the two approaches as mutually exclusive and agree
| w/ Rich Harris' concept of 'Transitional' web applications that
| mix the two approaches. I would just draw the line where you
| abandon hypermedia for a more elaborate client side approach in
| a different place than him.
| Cthulhu_ wrote:
| I enjoyed building webapps with Backbone, it was rich web
| applications that felt like true apps instead of trying to make
| parts of a site more dynamic using jquery. It was a clean
| separation between front- and back-end.
|
| But Backbone was a bit sloppy, not very enterprisey, until
| Angular came around.
|
| Anyway, this string of web applications became popular (in my
| world) because it meant that we could separate back-end from
| front-end, and have one back-end (usually REST/JSON) fueling
| mobile and web clients separately. That was it, that was why we
| built SPA's, but by now that has been forgotten again.
|
| And in my world, it made sense because the apps were behind a
| login. But then They wanted to make SPA's facing the internet,
| for things like webshops. And I get that too; I've made a few
| websites using Gatsby, they're crazy fast for navigating AND
| still indexed by search engines.
|
| Anyway, in some cases it did get more and more complicated,
| then with server-side React and the like. I never had to touch
| that, thankfully.
| norwalkbear wrote:
| React is very diverse community, who are these react bros?
|
| I went to a series of JavaScript conferences and React is
| extremely diverse.
| PedroBatista wrote:
| I was recounting the past. I'm sure it is "diverse" (
| whatever that means ) now because it became kind of a
| industry standard for front-ends.
|
| Good to see diversity all around, I just wish there also
| would be diversity of thought and it comes to building web
| pages. But I guess that would lead to people admitting ~80%
| of all the stuff they build does not require React or
| equivalent js frameworks and that would be both an ego and
| economic/resume problem..
| steve_adams_86 wrote:
| > ( whatever that means )
|
| I inferred that the intent was to say that not all people
| using React fit into one category.
|
| > ~80% of all the stuff they build does not require React
| or equivalent js frameworks
|
| I'm well aware of this for some portion of the things I
| build, but I don't agree that these frameworks are
| generally unnecessary or not preferable. It's also hard to
| say when something "requires" these tools or not. Arguably
| you could say nothing requires them these days.
|
| I like to build with all kinds of tools though, and React
| and Vue are for example are often more helpful than harmful
| to my development experience. I'm speaking as someone who
| has been building things for the internet for around 20
| years, so I remember life without these tools.
|
| > that would be both an ego and economic/resume problem
|
| Maybe. I think this might be more true in roles that are
| closer to entry level, though.
|
| edit:
|
| From your previous comment,
|
| > fast forward to React with the young energetic bros
| building dead simple 5 page websites with a Rube Goldberg
| setup of front-end frameworks
|
| This is a good point. It's still a thing and will probably
| never go away, regardless of which frameworks we have. I
| think it stems from people fundamentally misunderstanding
| our core web technologies and not realizing how easy it is
| to do what they're doing without React or Next or Nuxt or
| what have you.
|
| In many cases I've worked with people who wanted to do the
| most trivial things in their UIs and they worked tirelessly
| and earnestly to implement it with React or Vue, but it was
| something that already exists in the Web API or HTML
| elements. Basic stuff like reinventing checkboxes. Or
| reinventing the button element by styling an anchor and
| altering its behaviour with JavaScript to submit a form. So
| many younger people have started their careers in web
| development on frameworks, and they genuinely don't
| understand how the fundamentals work.
| gochi wrote:
| It's an industry standard for people who like React. It's
| really that simple. This idea that they are so dominant and
| everyone is forced to use it is complete hogwash. JQuery
| and Wordpress still dominate the web completely.
| jddj wrote:
| I hear you're buying a synthesizer and an arpeggiator and are
| throwing your computer out the window because you want to make
| something real.
|
| I hear that you and your band have sold your guitars and bought
| turntables.
|
| I hear you rewrote your http endpoints to return JSON because
| that was REST.
|
| I hear that you and your band have sold your turntables and
| bought guitars.
|
| I hear you rewrote your http endpoints to return templated html
| fragments because that was HATEOAS.
|
| I'm losing (regaining/losing/regaining) my edge
| Alifatisk wrote:
| Is this some kind of metaphor?
| jddj wrote:
| An appropriation of James Murphy to make a common potshot
| about webtech trends being as circular as fashion / music
| ones
| cantSpellSober wrote:
| https://genius.com/Lcd-soundsystem-losing-my-edge-lyrics
| [deleted]
| zkldi wrote:
| BUT HAVE YOU SEEN MY TECH STACK?
| ElectricalUnion wrote:
| Is this supposed to be Rockstar? The reference Rockstar
| Satriani interpreter barfs on this input.
| bjconlan wrote:
| Haha, software has more seasons than the fashion industry. If
| you observe it for long enough everything seems somewhat
| derivative. But I wouldnt want it any other way. All
| diversions are welcomed within the choices of those working
| within the choices of those before us.
| norwalkbear wrote:
| I suspect VC distorts value in tech choices.
|
| I'm pitching a mobile app built in Unity and a custom ruby
| backend on digital ocean.
|
| They questioned my tech choices on a working app! Apparently
| if you want VC money you must use their approved tech stacks.
| pragma_x wrote:
| > I suspect VC distorts value in tech choices.
|
| I agree. I think what we're seeing is investment risk
| assessment as a proxy for a deep understanding in
| technology. After all, if you don't know how anything
| works, all you can do is look to what _has_ worked for you
| and other investors in the past.
|
| I'm guessing here, but it's plausible that once a given
| stack has proven to make money, the fix is in. It wouldn't
| matter if it's the best choice out there or not. The track
| record itself makes it more attractive. Example: Ruby on
| Rails.
| 0xdeadbeefbabe wrote:
| This is a fun semantic game. You can also tell them it
| uses a Von Neumann architecture and also 8 bit bytes. Or
| how about it uses Linux, or the latest Linux 6.5-rc6?
| aidenn0 wrote:
| I heard that you have a backup Data8 tape of every Unix
| release...
| silver-arrow wrote:
| Great news.
|
| I have had good success and a rewarding experience using htmx the
| past year. It has been so great in tandem with Clojure using
| hiccup for SSR.
|
| Once htmx clicks for you, you are almost left stunned by how
| simple and flexible it is. You can't believe that this isn't how
| HTML evolved to as a hypermedia. It becomes very obvious that
| this is how web development should have evolved. I hope someday
| that what htmx is doing through javascript becomes baked right
| into HTML and the browser clients.
|
| If you are mistakenly believing it is just some derivative of
| Angular or you are not grasping the significance of its
| advancement of the architecture of hypermedia, please do yourself
| a favor and read the excellent essays on their site; you will
| then truly understand what REST is and what the importance of
| real HATEOAS means: https://htmx.org/essays/
|
| They also have a free book here: https://hypermedia.systems/
|
| We made a costly wrong turn 10 -15 years ago by attempting to
| rebuild thick clients on the web with a JSON API architecture
| instead of expanding and enriching the new and powerful idea of
| the early web: hypermedia.
| ksec wrote:
| >You can't believe that this isn't how HTML evolved to as a
| hypermedia.
|
| That is why I wish HTMX to be merged into HTML5 spec. For
| something like 98%+ of the web it will be good enough. You then
| have a small JS library for the other 1.9%.
|
| The 0.1% left is just pure JS Web Apps.
| recursivedoubts wrote:
| i very much hope that htmx serves as inspiration for future
| HTML releases, I agree that this ideally should be part of
| the HTML infrastructure
| uxns wrote:
| Out of curiosity, I presume you were working on the frontend
| part using Clojurescript? Have you used some kind of wrappers
| around htmx or just a simple js interop was enough?
| silver-arrow wrote:
| We moved away from ClojureScript entirely. We just run a
| plain ole java uberjar with the Clojure/ring/hiccup/Compojure
| spitting out the HTML with whatever htmx attributes and
| response headers we need. There are instances where we may
| need to sprinkle in some javascript for some extra dynamic
| things - which turns out to be very infrequent. Instead of
| sprinkling in the javascript, we have been using _hyperscript
| instead - love _hyperscript.
|
| Yeah, so moving to htmx has allowed us to jettison
| ClojureScript which just entailed too many parts. As a matter
| of fact, before going more htmx with our projects, we had
| moved away from ClojureScript to React directly.
| sesm wrote:
| What are technical differences between HTMX and early versions
| of Angular 1? It has the same idea of sprinkling some
| attributes over HTML to make it dynamic for easy cases. There
| were many frameworks that started like this (Angular 1, Vue,
| etc), and after getting some traction they grew into full-blown
| SPA frameworks, because there is a real need for more difficult
| cases.
|
| If I had to pick an "Angular-1-like" framework, I would pick
| the one that clearly documents it's boundaries and provides a
| clear way to use a mature SPA framework when there is a need to
| cross those boundaries. If anyone is aware of such framework,
| please share.
| recursivedoubts wrote:
| htmx uses hypermedia, rather than client-side managed state
|
| as much as possible, htmx tries to take HTML to its logical
| conclusion (from my perspective) as a hypermedia, rather than
| imposing other ideas on top of it
| sesm wrote:
| Does this ideology lead to significant technical
| differences from early versions of Angular 1 and early
| versions of Vue?
| sesm wrote:
| Ok, I see, the idea is to render parts of the page on
| server and swap those parts on the client with things
| like: https://htmx.org/attributes/hx-swap/
|
| So it's not really an "Angular-1-like", but more like
| Vaadin in JS.
| criddell wrote:
| You keep using the term _hypermedia_ and I 'm not certain
| what is meant by that term (I was thinking it referred to
| linked media). _Hyper_ means _over_ , right? So is _hyper_
| media more about the environment media is in than it is
| about links?
| beders wrote:
| I think he meant just hypertext
| recursivedoubts wrote:
| yes, I prefer the term hypermedia over hypertext because
| it stresses the systemic nature of a hypermedia system: a
| hypermedia (e.g. HTML, a hypertext), a hypermedia client
| (e.g. a web browser), a hypermedia protocol (e.g. HTTP)
| and hypermedia servers.
|
| we have written a book on the topic here:
|
| https://hypermedia.systems/
|
| you can read chapters 1 & 2 for an overview of what
| hypermedia is at a systems level:
|
| https://hypermedia.systems/hypermedia-reintroduction/
|
| https://hypermedia.systems/hypermedia-components/
|
| As far as what the term _hypermedia_ means: it is a
| media, such as a text, that includes within it
| _hypermedia controls_. Those hypermedia controls allow
| non-linear branching and interactions with the media,
| hence the term _hyper_, that is, above, "normal" media,
| which is consumed passively.
|
| The hypermedia controls we are all most familiar with are
| anchors/links & and form tags. htmx attempts to
| generalize the concept of a hypermedia control.
|
| The book goes into gory detail if you are interested in
| further exploring the idea.
| afavour wrote:
| > It becomes very obvious that this is how web development
| should have evolved.
|
| I have to disagree with that. I'm happy htmx exists and that it
| works for many but in my professional life I've found few cases
| where it's the best choice. And that's fine! It's a wonderful
| thing that the web has been able to grow in so many diverse
| ways, there should be no one way it "should have evolved".
|
| IMO _this_ is the biggest mistake in web dev in the last decade
| or so: that there should be One Right Way. No matter if you're
| making the next Gmail or if you're making a static blog the
| cargo cult of an industry tells you it should all be done the
| same way when common sense would tell you that's not the case
| at all.
| giraffe_lady wrote:
| I'm kind of guessing / reading into their comment here but.
| Using htmx doesn't give me the feeling of "this is the only
| way I ever want to do this" but more "if html worked like
| this I wouldn't use js most of the time." The sense that an
| opportunity was missed and now we're paying for it in
| complexity.
| gochi wrote:
| The complexity is just shifted around from JS to HTMX (or
| hypothetically, html). Not a noticeable improvement.
| rakoo wrote:
| With JS you must use JS or TS and the steam factory that
| comes with it. With htmx you can use any language. That's
| a very high improvement for many.
| CharlesW wrote:
| > _With JS you must use JS or TS and the steam factory
| that comes with it. With htmx you can use any language._
|
| Can you elaborate on what you mean by this? Front-end
| framework don't care what language back-end logic is
| written in. For example, I have a Vue/Vite site that
| calls back-end functions that I'm gradually migrating
| from one language to another, and no front-end changes
| have been required.
| wrapperup wrote:
| Much of your business logic can live in the backend, and
| it keeps your frontend really tiny. The idea is to
| generate HTML on the backend, instead of using a front-
| end framework to generate HTML on the client from an API
| call.
|
| You can also do the same in Node if you want to, I
| currently have a TS website that is mostly templated HTML
| in production (without htmx). Htmx would be perfect for
| that site.
| CharlesW wrote:
| > _Much of your business logic can live in the backend,
| and it keeps your frontend really tiny._
|
| Ah, so "with htmx you can use any language" is true
| because its users are no longer using a programming
| language per se for the front-end, but instead are
| defining logic with htmx's DSL?
| rakoo wrote:
| htmx extends html to generalize a behaviour that already
| exists, so it's as much a DSL as html itself is a DSL
| CharlesW wrote:
| Or Vue, yes! ("DSL" wasn't meant as a negative, I just
| didn't know what else one would call htmx additions.)
| rakoo wrote:
| Yes, but you still need to write the frontend code in
| JS/TS
| wrapperup wrote:
| Yep, indeed. But htmx can reduce that a lot (to 0 even,
| in some instances), which is why it's really nice.
|
| There's also WASM, which is slowly gaining steam, but it
| still isn't a first class citizen like JS is.
| unshavedyak wrote:
| The difference is those were already tools we were using.
| You _(hypothetically?)_ can't eliminate the complexity of
| dynamic apps without limiting flexibility. However you
| _can_ move the complexity in-band, to a domain you are
| already using and preferring.
|
| Plus, if it's done right, you can get a lot of
| functionality while remaining No-JS friendly.
| spinningslate wrote:
| That's not my experience based on two scenarios:
|
| 1. Server-side rendered sites in Python using either
| Django or FastAPI/Jinja2 and htmx;
|
| 2. Dotnet back end with Angular front end.
|
| In practice - for the apps I've been involved with -
| option (1) provides a more than acceptable user
| experience. There's no doubt Angular can go beyond the
| capabilities of SSR+htmx. But, in practice, it's in the
| long tail. Throw in the odd js lib, e.g. for charting,
| and option (1) is good enough for the vast majority of
| things.
|
| The complexity is not comparable: (1) is much simpler.
| For a start, all logic is in one language. There's no
| separate build for the front end and back end; no need to
| reconcile state in a front end cache with the back end.
| There's no need to export every view as a REST API; it's
| a native function that gets called from the view handling
| function.
|
| Others will have different experience: I'm not saying
| this is universal. But in my experience, objectively,
| it's not true that the complexity moves from js to htmx.
| At least, not if that implies the complexity is
| equivalent. It's just not the case.
| gochi wrote:
| Not sure you've solved the complexity when you've just
| slotted in another front to a general solution that is
| over-engineered. You could have replaced either scenarios
| with a single NextJS or SvelteKit solution. Go above and
| beyond in "complexity", write your Node backend (keeping
| it one language, JavaScript), and use vanilla HTML and JS
| to consume that.
|
| To me, htmx isn't as revolutionary as people make it out
| to be, and possibly that's due to the fact I'm just not
| burdened by the old days of gigantic Angular apps and
| massive ASP.Net stacks. My history was mostly JQuery
| where needed (which was all the time before JS got its
| act together).
| adamckay wrote:
| > My history was mostly JQuery where needed (which was
| all the time before JS got its act together).
|
| htmx should remind you of those times.
|
| I certainly has for me - it's just (fundamentally) a
| fancy and clever wrapper around jQuery ajax requests made
| via HTML attributes.
| Xeamek wrote:
| I mean, that literally the core concept entire field of
| programming: making abstractions to shift complexity
| around (else where)
| giraffe_lady wrote:
| For many basic & routine web page interactions, I have
| not found that to be true.
| gochi wrote:
| I can only see that experience being true if you've never
| used jquery (aka the same shorthands you're relying on
| within htmx and likely hyperscript).
| giraffe_lady wrote:
| My frontend experience predates the rise of react etc. I
| have used jquery.
|
| The advantage of htmx over jquery is declaring the
| replace condition & behavior inline as part of the
| component. Conceptually this is easy to reckon with as a
| separation of concerns thing as well as a sandi metz-ish
| "when would this code need to be changed" thing. The html
| tag is responsible for its own update, and so its update
| is part of the html tag.
|
| Jquery does the same things but requires you to declare
| the behavior separately from the component, decide on &
| maintain abstractions and reuse patterns. And manage code
| organization so that for any updatable template code you
| can find the corresponding behavior declarations and
| understand their scope w/r/t other template code.
| Spivak wrote:
| I think the biggest change from jQuery flows is that the
| behavior is attached to the elements themselves instead
| of a script over here poking at the dom from the outside.
| andy800 wrote:
| I see it as much more, many things can be stripped out
| altogether. Client-side state management. Client-side
| input validation. Fallbacks for when data hasn't been
| loaded yet. Less async-based code, less coordination-
| required and event-driven code (this stuff happens but
| much easier and often code-free with HTMX).
|
| Its not a fit for every site or use case but more than
| any other front-end tool or library or framework, it has
| enabled me to actually realize the UI concepts in my head
| to the actual screen, and usually a lot quicker than I'd
| expect.
| dgb23 wrote:
| I fully agree with you. I'm a fan of htmx, can recommend it
| and have used it in some projects by now. But...
|
| For one, htmx is not a full solution to avoid JS. It's
| excellent for the parts that are AJAX/CRUD, which certainly
| covers a lot of ground. You still need something more if
| you're doing stuff that doesn't fit here like interactive
| visualizations and many other use cases. However, it
| integrates very well with other lightweight libraries.
|
| Secondly, htmx is great if you're developing full-stack (like
| GP). Meaning you touch every part of a site from the data
| model to coordinating messages to the frontend etc. If you
| want a much clearer separation between frontend and backend
| of a site, especially in terms of contributors/teams, then it
| might not be the right tool. IMO there are plenty of good
| reasons to do either.
|
| Third, and this is a bit of a combination of the first two
| points, if you directly fetch data from a third party, say a
| JSON API, then htmx doesn't help you at all.
|
| So really as you said, there is no one right way. For me it
| has been working very well though. People should look into it
| for sure though. There's an opportunity to combine htmx with
| orthogonal libraries that do the dynamic parts like lit etc.
| silver-arrow wrote:
| That's fair. I agree - that type of blanket statement is not
| helpful in the technical realm. I should have kept it at
| just: HTML should have continued to be expanded into what
| htmx is doing.
| Spivak wrote:
| I would have love to see rather than JS evolving to include
| HTML and CSS, HTML should have evolved to include JS and
| CSS as more first-class.
|
| Being able to write components in a single HTML file would
| be wonderful.
| grncdr wrote:
| I've mentioned it here on HN before, but I've been using
| https://jhuddle.github.io/ponys/ for this and I still
| think it's pretty great.
| Spivak wrote:
| Woah woah woah. This is a game changer.
| 0xParlay wrote:
| [flagged]
| taffer wrote:
| Please don't post insinuations about astroturfing, shilling,
| brigading, foreign agents, and the like. It degrades
| discussion and is usually mistaken.
|
| https://news.ycombinator.com/newsguidelines.html
| aCoreyJ wrote:
| You don't do your conspiracy theory any favors by making
| absurd blanket statements
| andsoitis wrote:
| > I have had good success and a rewarding experience using htmx
| the past year. It has been so great in tandem with Clojure
| using hiccup for SSR.
|
| What kind of app are you working on?
| PaulHoule wrote:
| I am happy with HTMX for my RSS reader. The issue with front
| end apps is, and always has been, the complexity of updating
| the UI after a user makes a change.
|
| For instance, inside an HTMX application, I just coded up a
| plain ordinary <script> (no framework, no build system) that
| displays a count of how many characters are in a text field and
| also disables or enables a submit button according to that
| size. It's 9 lines of code plus an attribute on the input. It
| might be less if I did it in
|
| https://hyperscript.org/
|
| Immediately it faces the problem that there are two paths: (1)
| the initial setting of the length display (the field is pre-
| populated with text, I ended up setting it in the SSR) and (2)
| what happens when the text content changes.
|
| If you use signals or hooks or useEvent or lifecycle methods or
| whatever you always see a certain amount of awkwardness that
| stems from the above.
|
| Note I could have done the above with "pure HTMX" in that I
| could have had the event handler trigger a server round trip
| that repaints the text field and the submit button, it wouldn't
| be as bad as it sounds in performance, but boy it seems like a
| waste.
|
| I've built applications that were a lot like Figma, Photoshop,
| or Eclipse, where the user could update some data and it could
| have very arbitrary effects on the UI because the user is able
| to add and remove many different UI elements and in a case like
| that you need some system that can manage dependencies at
| runtime.
|
| React has revolutionized how people build widget-based
| frameworks, there is never going to be anything like Tk, Cocoa,
| GTK, WPF, Spring, JavaFX ever again, or if it is it is going to
| be influenced by React. There's the awkward fact that React is
| overkill for the typical form processing and e-Publishing
| applications people write with it but it is not up to the task
| (without an additional state management frameworm) of
| applications like Figma.
|
| Personally I'd like to see a mostly declarative form processing
| framework with a sprinkle of scripting: before there was the
| iPhone there was WAP
|
| https://en.wikipedia.org/wiki/Wireless_Application_Protocol
|
| which had a way to send multipart forms to the client.
| Something like that designed to work with a software factory
|
| https://www.amazon.com/Software-Factories-Assembling-Applica...
|
| (one of the most visionary books of all time... the authors
| built an enterprise software development framework for
| Microsoft that was nowhere near as cool as their vision)
|
| or a "no-code" app builder could be great.
|
| I'm still trying to get my head around websockets. I've built
| some small demos that are awesome, like a program that controls
| the volume of my smart speakers and has the sliders move when I
| change the volume with the remote control. I really wish my RSS
| reader could update my "favorites" window as soon as I add a
| favorite in another window, but doing that efficiently requires
| answering questions all the way from the front end to the back
| end to the database. I'll probably find a half-baked way to do
| it but it's sad that I'm settling on a web application to have
| the limitations web applications had 15 years ago.
| t3estabc wrote:
| [dead]
| revskill wrote:
| React is JS in html.
|
| Htmx is JS in string.
|
| Goodluck stringify :))
| okeuro49 wrote:
| No, React is HTML in JS.
| basiskarten wrote:
| Very cool, congratulations!
| wildermuthn wrote:
| I started with Perl in '96 and have lived through what feels like
| everything -- PHP, jQuery, Drupal, Backbone, Node, Angular,
| ClojureScript, React, GraphQL, and NextJS. Htmx feels like a
| divergence from the trend, and is worth thinking about.
|
| Htmx asks us a good question: "does the complexity of your work
| reside essentially on the server or essentially on the client?"
|
| The complexity for the vast majority of websites resides
| essentially on the server. Most of us are not building Figmas and
| Google Sheets. Most websites, even if heavily interactive, are
| just CRUD apps with pleasant interfaces. Frameworks like NextJS
| attempt to rectify the problem of overly complex clients by
| moving React to the server, but this often magnifies complexity
| rather than minimizing it.
|
| Wouldn't it make sense to remove React from the stack? For
| complex clients, skip the DOM and JS with canvas and compiled web
| assembly. For complex servers, use some form of server-driven
| granular updates to the DOM.
|
| The problem I see with this approach is that although most
| complexity reside on the server for most websites, there are
| almost always a few high-complexity task that needs to reside on
| the client -- image editing, real-time
| sorting/filtering/calculation, drag-touch gestures, etc.
|
| A hybrid approach is necessary. It isn't good enough to allow
| compatibility. Although htmx and React can be used on the same
| web page, they need to be kept in isolation. But I'm not looking
| for isolation; I'm looking for fundamental integration.
|
| My ideal framework would allow for reactive granular updates to
| the DOM while also being tightly integrated with compiled web
| assembly powering complex client operations. I'd write all my
| code in a powerful language rather than JavaScript. My debugger
| would operate on both server and client because the difference
| between the two has disappeared. It would be true full-stack
| development -- a single-stack application (SSA)
|
| Clojure + ClojureScript comes close to being an SSA, but only
| superficially.
|
| If ever there was a killer framework for Common Lisp, I think an
| SSA fits the bill.
| jonahx wrote:
| Agree with your take.
|
| > A hybrid approach is necessary.
|
| This is "the islands" approach, as advocated by Astro, for
| example:
|
| https://docs.astro.build/en/concepts/islands/
|
| This approach is consistent with htmx and friends, and we're
| using it on an htmx project with simple vanilla JS for the
| pieces of interactivity. For small and medium projects and a
| small team, this can be enough, and it's a breath of fresh air
| to be able open up dev tools, point to part of a page, and
| understand everything there just by looking at the html and
| small snips of JS.
| hu3 wrote:
| > A hybrid approach is necessary. It isn't good enough to allow
| compatibility. Although htmx and React can be used on the same
| web page, they need to be kept in isolation. But I'm not
| looking for isolation; I'm looking for fundamental integration.
|
| Blazor United promises this hybrid approach. You code in C# in
| one way regardless of server or client. On first page load it
| renders everything from server-side. Then webassembly gradually
| takes over and it starts loading C# code on the client to speed
| up UI interactions that don't require server side data.
|
| It works well but their current challenge is reducing
| webassembly files size which is about multiple MBs.
|
| https://visualstudiomagazine.com/articles/2023/04/20/blazor-...
| jcmontx wrote:
| > Wouldn't it make sense to remove React from the stack?
|
| God hear your words
| WhitneyLand wrote:
| Have many open source projects have embraced htmx as their way of
| doing things? Or are there any non-IT projects that have adopted?
|
| It would be interesting to see how it's been working out for
| folks.
| DrDroop wrote:
| I've a hard time taking htmx serious for building a modern web
| app/site. It makes is impossible to build features that users
| have come to expect:
|
| * Faceted search with configurable filters, like filter date on
| before, between or after, but only show the filter if the user
| wants it.
|
| * Configure result view with different columns or even different
| views like maps or drawing something on a canvas like charts. You
| can maybe do some of this stuff with htmx but at some point
| you'll just need the json.
|
| Even Angular can do this, and with something like SolidJS it is
| actually a pleasant thing to do.
|
| A JSON api can be re-used by other apps while htmx feels like
| someone reinvented Thymeleaf
| zaphar wrote:
| Impossible is a strong word. I've looked at their API and I can
| certainly imagine ways to do everything you list above in HTMX.
| I would need to build and use it in anger to know if it's a
| good way to do so but I can imagine scenarios where it
| definitely is.
|
| The point about a JSON API is a good point and if you need a
| public API then you should probably factor that into your
| decision making but not everything has this constraint.
| CharlieDigital wrote:
| > The point about a JSON API is a good point
|
| In a well-designed system, these two are not mutually
| exclusive but simply two facets of the same request pipeline.
| The JSON API simply serializes the model as JSON.
|
| The HTMX-specifc API applies a template/transform over the
| model and returns HTML instead. If one thinks of hypertext as
| another serialization target, it's easy to see how one would
| easily be able to serve both JSON for pure APIs and hypertext
| for HTMX.
| zaphar wrote:
| Oh definitely. You could control it with the `Accept:
| text/html` http header too so you can use the same
| endpoint. But as I said, you need to take that into
| consideration if you adopt htmx.
| Cthulhu_ wrote:
| You don't have to use "pure" HTMX, you can mix and match where
| appropriate I'm sure.
| yohannparis wrote:
| Exactly, by using hmtx it's not like you cannot write
| JavaScript anymore.
| agumonkey wrote:
| from my limited understanding, any non trivial client state
| will require legwork in htmx, right ?
| withinboredom wrote:
| Depends on the framework and what you're using to render the
| html with. For example, in PHP Swytch Framework, you can just
| `$this->rerender($state)` in an api response.
| recursivedoubts wrote:
| i have build exactly a UI like this with htmx and _hyperscript
|
| something like this is complex enough to require some front end
| scripting, which I am not opposed to:
|
| https://htmx.org/essays/hypermedia-friendly-scripting/
| dvtkrlbs wrote:
| You can check this talk out https://youtu.be/3GObi93tjZI I was
| thinking the same but in the video they specifically talk about
| faceted search and how they did it with htmx.
|
| For the second part you probably go with your own javascript or
| get away with hyperscript
| DrDroop wrote:
| That is the talk I've watched before coming to the above
| conclusion. The faceted search demonstrated in the talk is
| still an order of magnitude simpler then what I have build.
| It is still a cool example of what you can do with htmx and
| it certainly pushes the envelope but the UX choices are
| dictated by what is possible in htmx. I also think that the
| talk is somewhat dishonest, it is by a backend developer that
| want to keep writing Django while I would suggest replacing
| that with Postgrest. I estimate that what is shown here can
| be done with 500 to a 1000 lines of SolidJS for the entire
| app.
| taffer wrote:
| > what is shown here can be done with 500 to a 1000 lines
| of SolidJS
|
| If you replace a 22,000 LOC React + Python app with 1,000
| LOC of whatever framework you choose, I would be very,
| very, very, very impressed. I don't believe you.
| atoav wrote:
| On the topic of filtering, this is literally something I tend
| to do only client side anymore, unless it is something where
| the size of the payload matters. Even smartphones don't have
| any issue with search through tables with a thousand lines.
|
| So for such things I would give the user a very broad set of
| data via htmx and then allow for further (realtime) filtering
| via JS.
|
| If I want them to be able to search through data that isn't
| displayed initially I just deliver it with a hidden css class
| and remove that class if it is searched for.
|
| Htmx, like any technology, is very well suited for a certain
| set of problems -- iif you don't try to make it do tricks it is
| not good at, you should be fine.
| norwalkbear wrote:
| I have the same thoughts lately. People expect high
| interactivity these days.
| kitanata wrote:
| [flagged]
| [deleted]
| neon_electro wrote:
| You can get your comment deleted if you contact Hacker News,
| I've done it
| kitanata wrote:
| I contacted them. They outright refused to delete any
| comments, all comments or my entire account. Hacker News by
| matter of policy WILL NOT delete your comments, even when
| requested in writing.
| kragen wrote:
| [flagged]
| 0ct4via wrote:
| Interesting how you equate a simple desire to have the
| ability to delete comments (ostensibly a site-supported
| function) with "concealing abuses" -- it says more about
| your own projection than anything else.
|
| All you've done above is make baseless assumptions and
| imply accusations against kitanata with no basis or
| merit.
|
| Might want to check your own actions out before you go
| accusing others of "egregious abuse" - and as you put it,
| dial back on the rhetoric ;)
| kragen wrote:
| [flagged]
| 0ct4via wrote:
| I never said anything about their behaviour, please don't
| have the audacity and arrogance to try and tell me what I
| do and don't "see" -- as, like everyone one of your
| baseless assumptions so far, you're without any shred of
| merit, evidence, or truth.
|
| Maybe you shouldn't keep trying to push Hasidism when
| you're made antisemitic analogies, and don't mansplain
| Judaism to Jews.
|
| If you can't say something without being a condescending,
| assuming tool, maybe don't say anything -- you've had
| plenty "killed" yourself, hypocrite.
| kragen wrote:
| your claim that you 'never said anything about their
| behaviour' is obviously false
|
| in your comment above, you said that the 'accusations'
| against kitanata had no 'basis or merit'. but the
| specific accusation i made in the comment i was replying
| to was 'egregious abuse of the site', which is a
| behavior. therefore, you did say something about their
| behavior; the accusation would be baseless and meritless,
| as you said it was, only if their behavior was not
| egregious abuse of the site or anything similar. which is
| to say, only if it is impeccable
|
| similarly, your claim 'you've had plenty "killed"
| yourself' is false; none of my comments on hn have been
| killed this year. it's been more than a month since one
| has even been flagged, which is pretty surprising, given
| the degree of hostility i often see
|
| (edited: until now! two of the comments above in this
| thread have now been flagged, plus _nine_ in the other
| thread linked, within the last hour, including the
| hasidic parable about _lashon hara_ and the one that was
| mostly quotes from the declaration of independence and
| the universal declaration of human rights. still none
| killed tho)
|
| similarly, i haven't made any anti-semitic analogies. the
| number of obviously false things you say is astounding.
| there are probably lots that i've forgotten to correct
|
| as for 'mansplaining Judaism to Jews', while i'm
| certainly mansplaining judaism to you, i don't believe
| that you're jewish any more than i believe you're
| chinese, as you implied you were in
| https://news.ycombinator.com/item?id=37152555. obviously
| jews _can_ engage in the kind of foolish, incoherent,
| discourteous, and anti-intellectual behavior you 're
| engaging in (being jewish doesn't immunize you against
| any human failing) but it isn't at all typical of jewish
| discourse, even when it is going badly
|
| instead, i think you're german, and hypersensitive on the
| subject of the holocaust because you believe that it was
| a genocidal atrocity that grew from uniquely german
| traditions, even though there have been many genocidal
| atrocities that did not (though you don't seem to know
| much about them). definitely at least northern european
|
| what i'm 'pushing' isn't something uniquely hasidic,
| though. i'm pushing for minimal standards of logic and
| coherence and judicious behavior. i just think the
| hasidic parable i quoted has a particularly good
| explanation of the relevant issues
| kwhitefoot wrote:
| I've skimmed the documentation and searched for the word server
| but I haven't been able to discover what is required on the
| server side. Can anyone point me in the right direction?
| hliyan wrote:
| Anything that can serve HTML.
| domh wrote:
| From what I understand, it's just HTML from the server,
| embellished with properties that get picked up client side by
| HTMX. So you can use anything on the server: nginx, node.js,
| go, php, whatever
| renerick wrote:
| Any server-side language with your favorite web-framework and
| HTML templates system. Static files, PHP, Go, Ruby, ASP.NET
| Core, Spring etc, as long as you can send HTML pages and HTML
| partials, you are all set
| kwhitefoot wrote:
| Thanks. So a static site, on neocities.org, for instance can
| serve files in response to requests such as the examples
| using hx-swap="outerHtml". Is there a simple example of a
| static site using Htmx somewhere?
| renerick wrote:
| > So a static site, on neocities.org, for instance can
| serve files in response to requests such as the examples
| using hx-swap="outerHtml"
|
| Exactly. It can serve HTML partials, or utilize `hx-select`
| attribute to extract required elements from a full page
|
| > Is there a simple example of a static site using Htmx
| somewhere?
|
| Not that I'm aware of unfortunately
| WeAddValue wrote:
| The code is not done yet but I can explain how we're going
| to use htmx and Hypermedia APIs for the static site of a
| national chess federation (it's static to avoid
| hacking/ddos from disgruntled russians). Every week, new
| chess ratings are calculated from the reports of in-person
| / over-the-board tournaments. At build-time (Hugo/Netlify),
| a static HTML fragment is created for each member and
| included in the site's static files. At run-time, when a
| member's info is requested, htmx will fetch the member's
| HTML fragment and insert it into the appropriate <div>. At
| run-time, there is no server-side code executing nor
| database so it's fast, highly available, and almost
| unhackable.
| [deleted]
| kitanata wrote:
| [flagged]
| kragen wrote:
| nobody has the right to be forgotten
|
| nothing you say can be unsaid; therefore speak judiciously
|
| https://uuliveoak.org/Story%20ideas%20-%20service%20or%20cla...
|
| > _"Now Yankel," the Rabbi began "go back through the town and
| collect all of the feathers. Put them back into the pillow and
| bring the fully stuffed pillow back to me."_
|
| > _"But Rabbi!!!" Yankel burst out. "That will be impossible.
| Even as I was walking away from the feathers, I saw that they
| were being blown from the doorsteps. How will I be able to find
| and gather up all of the feathers again?!?!?!"_
|
| > _"Ah..." the Rabbi began his explanation. "And the same is
| true for_ lashon hara, _for once you let it pass from your
| lips, you can never collect it back again. It floats and
| flutters away in whatever direction the wind carries it. That
| is why you must always watch your words carefully and avoid all
| talk of others. You will never be able to repair the damage you
| have caused, but I am hoping that you have learned a
| lesson..."_
|
| > _Yankel nodded with deep understanding. From that day
| forward, not only was he no longer the town storyteller, but he
| did everything he could to spread the word about the pitfalls
| of_ lashon hara.
|
| if you regret the damage done by what you have said, you cannot
| unsay it, but perhaps you can take responsibility, apologize,
| and make amends by some other means
| dontupvoteme wrote:
| EU Law Disagrees.
|
| Feel free to Geoblock the entire market if you disagree. Many
| small news sites in the states do this.
| tass wrote:
| Does that work?
|
| If I'm an EU citizen accessing a site from outside the EU,
| don't I still have the right to be forgotten?
| littlestymaar wrote:
| Yes
| kragen wrote:
| [flagged]
| littlestymaar wrote:
| So you equate laws protecting individuals against
| businesses and laws protecting government against
| individual, really?
| 0ct4via wrote:
| Please cite that law, otherwise cease repeatedly being
| disingenuous and fallacious.
|
| There is a massive difference between curtailing things
| like freedom of expression, and de-facto stating "Chinese
| law disagrees with..." when (a) no such law exists, and
| (b) you're making a ridiculous point in a transparent
| attempt to distract from your own failing -- namely being
| too ignorant to admit that the so-called "right to be
| forgotten" _is_ a thing, whether you choose to believe
| (or accept) it, or not.
| kragen wrote:
| [flagged]
| 0ct4via wrote:
| [flagged]
| kragen wrote:
| [flagged]
| 0ct4via wrote:
| You realize your Googling doesn't make you an expert,
| right? It's very easy to be an American sitting in BA and
| judging things from what you've read on Wikipedia, but
| that doesn't mean you have the slightest actual
| understanding of the law or its application in China.
|
| When you can read it in Mandarin and you've lived under
| and seen that particular law being applied in China, come
| back to me -- until then, keep your armchair-lawyering
| and racist condescension to yourself.
|
| No accusations, buy a dictionary and you'll see the words
| literally describe your actions and comments. Don't like
| being called arrogant and condescending? Don't make
| arrogant comments and be condescending towards others.
| Don't like the observation that your remarks are puerile?
| Try making remarks with a modicum of maturity and less
| transparent projection, then.
|
| Evidently you're too busy playing the victim to actually
| have any evidence to deny my point. Going "If YoU GoOgLe
| It" and making out like you're oppressed somehow is all
| you've got, then you don't have any kind of logical or
| sound basis for your "arguments" in the first place -
| such as they are.
|
| That's a lot of baseless assumption you've got there,
| buddy - all from the mind that gave us, "have you ever
| met a person"[1] ...which is the most transparent non-
| argument trolling attempts appear on HN of late.
|
| Bit hypocritical of you to try and harp on about kindness
| when all you've done is make baseless assumptions and
| false accusations to numerous people in recent threads...
| but then if you don't think you're being disingenuous,
| then you clearly won't have the forethought or self-
| awareness to realize that's not being "kind" ... which
| feeds back to the arrogance and narcissism observations,
| in a convenient little bundle.
|
| Going "I think x" is a bit ridiculous when you literally
| stated the "right to be forgotten" didn't exist -- then
| when you were shown otherwise, you got petulant and
| resorted to baseless assumptions and ad-hominems. You're
| not IMAX, so there's no reason to be projecting that
| much.
|
| [1] https://news.ycombinator.com/item?id=37149287
| kragen wrote:
| [flagged]
| 0ct4via wrote:
| Ah, so now you're telling me where I live, pretty
| arrogant of you, narcissism confirmed.
|
| SEVERAL people have literally linked you repeatedly to
| _multiple_ sources covering the (frankly old news by now)
| so-called "right to be forgotten" -- it isn't a literal
| right to be forgotten, it concerns data protection --
| which you well know, but you're evidently choosing to
| take it literally and make narcissistic trolling rants.
|
| You don't have much in the way of self-awareness if you
| can't grasp that trying to tell people where they
| supposedly live and what they supposedly think, while
| making antisemitic allegories, is completely ridiculous,
| and frankly a Nazi-esque move.
|
| (Cue you going "but Jewish girlfriend!" as if the "I
| can't be racist because I have a Black friend" argument
| has ANY merit, when it doesn't -- you can absolutely
| still make antisemitic remarks and connotations
| regardless of whoever you claim to be with)
|
| Five years from now you'll still be telling people what
| to do and having the audacity to tell them what they
| THINK, when (a) you haven't got a clue, and (b) you still
| blindly claim you're not arrogant, condescending, or
| narcissistic, when making remarks like you just did.
|
| Please, seek psychological help. If the evidence of your
| assumption-laden, baseless-claim-filled, farcical
| comments are anything to go by, you have serious issues
| that go beyond being a troll on HN.
| Timon3 wrote:
| You disagreeing with something doesn't make it wrong. I'm
| sorry, but people in other parts of the world have a
| right to be forgotten, no matter how much you want to
| pretend they do not.
| kragen wrote:
| [flagged]
| littlestymaar wrote:
| Company's rights aren't human rights, in fact companies
| right is antagonists to human rights.
| Timon3 wrote:
| Where do human rights come from? Did we have them from
| when we split off from our closest ancestors? Did they
| magically appear when someone first thought them up, and
| they just stayed? Why do our closest relatives not have
| human rights?
|
| You yourself mention that people in Belarus have human
| rights. Why can the government ignore their human rights
| then? Why isn't there some magic barrier stopping the
| government from trampling on the populations human
| rights?
| kragen wrote:
| [flagged]
| Timon3 wrote:
| I didn't ask you to tell you what I think. I asked you to
| tell me what you think. You are the one taking your
| position, I can't answer the questions from your position
| as you would.
| kragen wrote:
| [flagged]
| kragen wrote:
| various people are posting irrelevant things about laws,
| missing the obvious ethical point
|
| if anyone has the right to be forgotten, then nobody has the
| right to remember, and prohibiting people from remembering
| would be an appalling degree of totalitarianism (though not
| an unprecedented one: https://en.wikipedia.org/wiki/Censorshi
| p_of_images_in_the_So...)
|
| that doesn't, of course, imply that it's praiseworthy to
| repeat everything true that you remember; that is _lashon
| hara_
|
| with respect to which, there's an interesting halakhic
| discussion about whether portraying yourself in an accurate
| but very unfavorable light, as kitanata and 0ct4via have done
| in their comments, is also forbidden
|
| https://judaism.stackexchange.com/questions/30372/lashon-
| har...
|
| _vbspr `ly tmr `l hyrvshlmy shm hby sypvr `l b`l hkhpts
| khyym z "l shns` brkbt vpgsh yhvdy shl hkyr shhv hkhpts khyym
| vsypr lv shhv nvs` lbqr tsl hkhpts khyym brdyn vhplyg bshbkhv
| vhkhpts khyym mr lv lmh th hvlk lyv ky ynv gdvl kmv shth
| khvshb l hv yhvdy pshvt vvtv yhvdy htrgz `l dbryv vkhrpv
| vgdpv vhgy` lydy hkh vkhr kk kshr b lbqr t hkhpts khyym bbytv
| hshtvmm lglvt shhv hysh shytv rb brkbt vbqsh mkhylh vmr lv
| hkhpts khyym shdrbh hv syr tvdh lv hyvt vktb spr shlm `l
| hlkvt lshvn hr` vl `md `l hhlkh shsvr ldbr lshvn hr` gm `l
| `tsmv `d shh`mydv hv `l hdbr `k"l hsypvr vktb `lyv b`ly tmr
| shysh smvkyn lzh mhyrvshlmy hn"l. vvlm yn pvsqym hlkh mtvk
| sypvrym vkbr ktbty shyn ryh mhyrvshlmy vmh shl `md `l hlkh zv
| bspr khpts khyym vtv nqbl ky kn l nmts shm bl mh shmshm`
| shkhzr bv vdn dyn khdsh lysvr l nmyn lzh bly ryvt msh"s
| vpvsqym vb`yqr hsypvr bshlm m hyh vmr lnvs` ny hkhpts khyym
| vyny kmv shth khvshb l ny yhvdy pshvt shpyr dmy vl hyth yvtst
| mzh shvm tqlh l hnvs` hyh mvsyp lv hbh b`d `nvvtnvtv hytyrh
| bl bmh shhstyr zhvtv vkylv dybr srh `l khr ysh bv mryt `yn
| shl lshvn hr` v`vd shhkshyl t hnvs` bysvr dvryyt shl gydvp
| vhkh l bvdy yn hsypvr mt_
|
| _In the book Alei Tamar on the Yerushalmi there he brings a
| story about the Chofetz Chaim, that he was traveling on a
| train and a Jew who did not recognize that he was the Chofetz
| Chaim met him and told him that he was traveling to visit the
| Chofetz Chaim in Radin and he was effusive in his praise. And
| the Chofetz Chaim said to him, "why are you going to him? He
| is not as great as you think; he is just a simple Jew." And
| that Jew got angry over these words and he disgraced him and
| cursed him and ended up hitting him. Afterwards, when he came
| to visit the Chofetz Chaim in his house, he was astonished to
| discover that this was the man he had been with on the train,
| and he requested forgiveness. And the Chofetz Chaim said that
| on the contrary he is thankful to him, for he had written an
| entire book about the laws of lashon hara but had missed the
| law that one must not speak lashon hara about oneself, until
| this fellow set him straight on this. This is the end of the
| story, and the Alei Tamar writes on it that there is support
| for it from the Yerushalmi mentioned earlier. However, we do
| not decide halacha from stories, and I have already written
| that there is no proof from the Yerushalmi. And that which
| [was mentioned in the story] that the Chofetz Chaim missed
| this law in the book Chofetz Chaim, we can accept because
| indeed it is not to be found there. But that which it implies
| that he retracted and judged the law anew for prohibitiveness
| we will not believe without proofs from the Gemara and
| Poskim. And with regard to the actual story it would have
| been fine had he said to the traveler, "I am the Chofetz
| Chaim and I am not like what you think; I am just a simple
| Jew" and no problem would have resulted. In fact the traveler
| would have increased his love on account of his extra
| humility. But that which he hid his identity and appeared to
| speak badly about someone else would be maris ayin of lashon
| hara, plus he caused the traveler to violate the biblical
| prohibition of cursing and hitting. Instead, the story is
| certainly untrue._
| okeuro49 wrote:
| Off topic, but:
|
| > The right to erasure is also known as 'the right to be
| forgotten'.
|
| https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-
| re...
| kragen wrote:
| [flagged]
| littlestymaar wrote:
| You realize that you're just claiming an imaginary "right
| for business to keep data forever" and ascribe it a
| higher moral value than the "right to be forgotten" you
| judge unnatural?
|
| Of course Google lobbyists are paid to argue that such a
| right exist and is higher up in the hierarchy than
| anything else, but there's no reason to listen to this
| arguments. I have no love for legislative bodies
| inventing artificial rights (like intellectual property
| rights), but corporations inventing artificial right is
| legitimately even worse.
|
| This time fortunately the legislators took the side of
| the people and created a "right to be forgotten" instead
| of a "right to hoard private data".
| [deleted]
| coldtea wrote:
| > _no such right exists; that would be like the right to
| rob with impunity_
|
| No, it's the same kind of thing as having your records
| "sealed", to not let a past deed haunt you.
|
| Not even sure what kind of logic jumps one has to make to
| equate something like this to "robbing with inpunity".
| For starters the punishment to robbing isn't remembrance
| of your robbing, it's jail time or fine etc. And, fun
| fact, the aforementioned "records being sealed" can even
| be applied to someone who e.g. did a robbery or other
| crime as a juvenile.
|
| Now, since a "right to be forgotten" does explicitly
| exist in EU and other jurisdictions, I'm not sure what
| denying its existance means.
|
| If you mean "there's no such right" as a thing in itself,
| outside laws and treaties and jurisdictions, then the
| same is true for any right.
|
| No right exists by itself, as if handed to us by nature,
| not even the right to not be murdered. All rights are
| based on people deciding some kind of assurances are good
| to have and putting them into laws and treaties and such.
|
| And all rights are only granted and protected based on
| power relationships and agreement, not based on some
| (non-existent) natural truths existing independenty of
| them in the cosmos. We might call some "self-evident" and
| "natural" but those are just fancy words. In actual
| history almost all of our so-called "self-
| evident/natural" rights have been unrecognized (even in
| quite recent history), and societies considered this just
| fine. In fact in some cases, actually giving the rights
| would be considered the violation of the natural law.
|
| > _of course clever demagogues and rhetoricians can write
| such things into legislation_
|
| Demagogue is someone who "who seeks support by appealing
| to the desires and prejudices of ordinary people rather
| than by using rational argument". Rhetorician is a public
| speaker who is good in persuading people with words.
| Neither have much to do with such legislation being
| passed (nor was it the work of some demagogues).
|
| It's simply about the internet making anything somebody
| does into a permanent record [1], and this being
| understood as not always necessarily being for the
| benefit of society.
|
| E.g. what some edgy/troubled teenager wrote on his social
| media account in his teens shouldn't necessarily be part
| of his "permanent record" for employers and others to
| judge them by decades afterwards. And in the past, it
| wasn't, unless it made the press (and even then, it was
| easily lost due to it being in print and ephemeral), or
| was deemed necessary so by the state (e.g. to register as
| a sex offender). Just because technology now makes it
| being a permanent record trivial doesn't mean we should
| be OK with it. We should be masters of technology, not
| slaves to it.
|
| [1] Doesn't matter if something like that could be
| accomplished in the past too - what matters is that it's
| far more prevalent, has several orders of magnitude more
| scale of the kind of stuff that can be kept, and is
| easier to achieve, and trivial to search with the advent
| of the internet. This changes the impact of this to
| society a lot.
| kragen wrote:
| [flagged]
| coldtea wrote:
| > _there would be no point in discussing ethical issues
| at all if moral relativism were correct (...) you wouldn
| 't have bothered to post a comment at all if you were the
| nihilist you are posing as_
|
| This is wrong on several levels, including practical and
| philosophical (and those aspects of it have been covered
| a lot in moral philosophy).
|
| For starters, whether morality is relative or objective
| has no bearing at all to whether it exists as a practical
| force in the human world - and thus whether it makes
| total practical sense to study it, shape it, apply it,
| benefit from it, use it to make things work smoother or
| more to your liking, and so on.
|
| (Not to mention how it also makes sense to examine it,
| document it, and discuss it, from a curiosity or
| historical interest perspective, even if it doesn't
| concern one directly as a practical matter. People do
| study the morality of other historical periods or distant
| societies, for example, even if it has no impact on their
| life in their society).
|
| Note that there are several other things for which
| exactly the same thing applies: religion, laws, taboos,
| and so on, even art and fashion.
|
| > _you wouldn 't have bothered to post a comment at all
| if you were the nihilist you are posing as_
|
| Rejecting natural rights and understanding that rights
| are historical constructions doesn't mean one is
| disintered in rights.
|
| I am very much interested in my right to my property, for
| example, and will vote, advocate, protest, demonstrate,
| etc, to maintain it.
|
| I don't have to believe there's some inherent natural
| "right to property" for that. Just that I find the legal
| enforcement of one beneficial to me, and that I'd rather
| live in a society where it is enforced, as opposed to one
| where it's not.
| kragen wrote:
| [flagged]
| bowsamic wrote:
| I'm confused, on what kind of metaphysical plane do you
| think rights live if you think they exist independently
| from the law?
| kragen wrote:
| [flagged]
| bowsamic wrote:
| I don't think that secular society posits some kind of
| natural inalienable objective moral law. I'm sure you
| know this but many, many people do not believe in
| objective morality
| abecedarius wrote:
| The idea of rights can be seen to emerge in large part
| from multiagent decision theory. This should not be
| surprising because moral intuitions arose as humans
| evolved living in groups. http://www.daviddfriedman.com/A
| cademic/Property/Property.htm...
| kragen wrote:
| this is a very interesting article; thank you
| kragen wrote:
| [flagged]
| bowsamic wrote:
| I have never met a secular person who appeals to an
| objective moral standard personally
| kragen wrote:
| [flagged]
| dontupvoteme wrote:
| digital computing machines did not exist when
| philosophers and thinkers were busy coming up with and
| refining the concepts of rights between antiquity and
| relatively recent human history.
|
| If you were familiar with the fallibility of human memory
| you wouldn't have made such a post
|
| some of us practice sufficiently OK OPSEC to prevent this
| from becoming an issue but it doesn't mean that we don't
| have to look out for the greater good of society against
| unwarranted centralization of technological power.
|
| feel free to breach such legislation if you deem it in
| your best interests
| aatd86 wrote:
| European citizen have such right. You can ask for your
| removal from Google search results for instance.
| 0ct4via wrote:
| "no such right exists" - the law would disagree with you
| on that one.
|
| "Under Article 17 of the UK GDPR individuals have the
| right to have personal data erased. This is also known as
| the 'right to be forgotten'." [1]
|
| "The right to be forgotten appears in Recitals 65 and 66
| and in Article 17 of the GDPR. It states, "The data
| subject shall have the right to obtain from the
| controller the erasure of personal data concerning him or
| her without undue delay and the controller shall have the
| obligation to erase personal data without undue delay""
| [2]
|
| [1] https://ico.org.uk/for-organisations/uk-gdpr-
| guidance-and-re...
|
| [2] https://gdpr.eu/right-to-be-forgotten/
|
| https://support.google.com/legal/answer/10769224
|
| https://en.wikipedia.org/wiki/Right_to_be_forgotten
|
| This obviously varies depending on jurisdictions, but a
| great number of users (EU citizens, and people resident
| in the EU - but additionally, the UK) absolutely have a
| "right to be forgotten," and brazenly claiming "no such
| right exists" is ignorant and fallacious, and such
| unfounded arrogance is a distinctly USian trait. For
| someone who purportedly lives outside the US, you don't
| seem to grasp that there are laws in other countries than
| the US.
| kragen wrote:
| [flagged]
| 0ct4via wrote:
| You'd do well to read
| https://news.ycombinator.com/newsguidelines.html -- all
| that baseless assumption and disingenuous false
| accusation really isn't in any way civil or useful... but
| then when you're cheap enough to bring the Holocaust into
| a discussion about data protection legislation, you're
| really not in a position on _ethics_ - or indeed anything
| else.
| kitanata wrote:
| [flagged]
| kragen wrote:
| [flagged]
| 0ct4via wrote:
| LMAO, you think claiming to have a Jewish girlfriend
| means you're incapable of making anti-Semitic remarks...
| What's next, you can't be racist because you have a Black
| friend?!
|
| You've done nothing but assume, make absolutely
| ridiculous stretches in your attempts to bring irrelevant
| points in to try and bolster your assumptions and
| baseless claims, and -- as for your "ideological battles"
| claim in another comment -- the only one bringing
| "ideology" into a discussion about data protection, is
| YOU.
|
| Perhaps rather than being a toxic, condescending
| hypocrite, you could take a moment to step back and look
| at how hard you're projecting -- if you projected any
| harder, we'd be able to see you on the moon.
|
| I won't be taking lectures on "elevated thinking" from an
| anti-Semitic narcissist who knows only baseless
| assumptions and false accusations, but keep raging on the
| internet.
| kitanata wrote:
| [dead]
| dang wrote:
| As you've been posting dozens of these comments in the last 24
| hours and starting flamewars all over the place, I've banned
| this account. Please don't create accounts to break HN's rules
| with.
|
| https://news.ycombinator.com/newsguidelines.html
| strangescript wrote:
| Htmx's biggest upside is no pressure to use JS/TS on the backend.
|
| So many stories start with "I used htmx with
| (rust|go|ocaml|django|etc) and had good results".
|
| Feels hard to not use JS/TS on the backend if you are already
| using it on the frontend (unless you have a specific need node
| can't fit). Why intentionally use two different languages, yadda
| yadda, etc, if you don't have too.
|
| Its refreshing.
| pjs_ wrote:
| . > looking for a nice framework for website
| > ask dev if their framework is hypermedia or javascript >
| doesn't understand, pull out long essay on hypermedia as the
| engine of application state > dev laughs and says "its a
| good framework sir" > check github > its javascript
| [deleted]
| 3cats-in-a-coat wrote:
| It's so odd to live long enough and see the steady pipeline of
| "look at this much simpler way of doing web apps, just write
| HTML, not like the previous complex way" projects, which then
| turn into the previous complex way as the eyes turn towards the
| next "simple way of doing web apps, just write HTML...".
|
| Angular and React started this way on the frontend, while ASP and
| PHP started this way on the backend (of course eventually they
| all grow "full-stack" solutions).
|
| EDIT: And how could I forget, Tailwind, whose tagline reads:
| "Rapidly build modern websites _without ever leaving your HTML_ "
|
| The fact your HTML barely reads like HTML after Tailwind, and
| reads more like your file is corrupted is I guess not mentioned
| in the tagline.
| savanaly wrote:
| >The fact your HTML barely reads like HTML after Tailwind, and
| reads more like your file is corrupted is I guess not mentioned
| in the tagline.
|
| Not my experience for the record. I use Tailwind in my side
| project, and it is exactly as convenient as it sounds to write
| my styles directly into HTML rather than think of a class name,
| add it in HTML, switch to the proper CSS file (or create it if
| it doesn't exist and make sure it's part of the build step),
| forget what name I had decided on, check the original HTML to
| remember the name, then go back to the CSS file and write the
| class name and then finally within that block add my style.
| 3cats-in-a-coat wrote:
| Are you programming on a phone?
| graypegg wrote:
| I've messed around with tailwind a bit now, and honestly I
| could never use it in even a moderately complex site without
| some sort of "component" framework.
|
| I think you're talking about just serving a .html file for
| every page in a site right? Having all of your styles
| duplicated everywhere would be much more confusing than
| writing CSS (and having to invent one name per groups of
| common things.)
|
| IMO it's only viable if you can create your own components.
| Which you will also have to give a name.
| dpedu wrote:
| Is this how Tailwind is supposed to work? I've never used it,
| but this sounds awful. How do you keep styles consistent
| across different areas of a website? Do you manually write
| matching styles into HTML every time you need them?
| SmellTheGlove wrote:
| I used it to build my saas template for my side projects.
| It's not awful at all - quite the opposite. But I'm an old
| guy using python+flask+tailwind+htmx. I try to inherit as
| much from my base template as I can, and then for different
| sections that are a bit more bespoke, an intermediate layer
| there to inherit from. It's not perfect, but the things
| that I tend to want to tweak or play with are as much in a
| single place as I can make them. I hadn't designed it this
| way from the beginning or it'd probably be cleaner.
| uxp8u61q wrote:
| Sounds like you're using a rather poor IDE.
| LordDragonfang wrote:
| What does your IDE/workflow look like that you avoid this?
| nonethewiser wrote:
| Style attributes' values being long doesnt make it any less
| html-like.
| alentred wrote:
| Almost all of these projects bring something innovative too. My
| take: we are missing the "refactor" step from the loop. It
| probably concerns other areas more than web dev by the way, but
| I would like to see more projects that not only build on top of
| the past experiences, but also remove the complexity from the
| solutions, instead of adding the features to deal with it.
| Achieve the same result with fewer layers, less code, less
| "stuff". For what it's worth, HTMX looks exactly like the
| latter kind.
| Cthulhu_ wrote:
| Don't forget Polymer, whose main marketing was that it's the
| tech behind... McD's menu screens. It turned into lit html, I
| have no idea what the state of that is now, haven't heard from
| it for a while now.
| greenyouse wrote:
| Polymer powered a few other things at Google too. Look at the
| DOM for YouTube, that dev team started with Polymer for Web
| Components and talked about how they built an internal
| library of custom HTML for the site. Doing that shared
| library approach seemed like a good way to scale out
| development across teams. It seems like it's still alive and
| well over there. (also used at ING, Comcast, Vercel, and
| others)
|
| I still have hope that frontend will eventually turn back to
| web components now that HTML templates, Custom Elements,
| Shadow DOM, and ES Modules are fully adopted. One of the
| problems is that this stack is foreign even to professional
| web devs that hail from React land. It's weird because it's
| native browser tech adopted by the W3C and painstakingly
| built into the browsers. Maybe it picks up after someone
| rewrites the react-dom internals to support web components
| and adds a new tooling layer over it?
|
| It's not bad tech and web components are built into the
| platform of the web now so they're not really going
| anywhere...
| peebeebee wrote:
| WebComponents are still very much alive. :) And LitHtml is a
| very nice wrapper around them.
| PaulHoule wrote:
| ASP had some strange things where you could write what looked
| like a client side handler on a button and it would call a
| function in the server.
|
| Circa 2007 or so it seemed a to be a huge mistake because it
| didn't play well with the so-called "model-view-controller"
| paradigm where, most importantly, the request handler could
| decide which view to render. (e.g. you fill out a form and if
| you mad a mistake it redraws the form with an error message,
| otherwise it might render one of several different forms
| depending on what you filled out on the first form.)
|
| He thing about HTMX is that it really wants support on the
| server side. For instance, you might have a <select> that gets
| drawn as part of an HTML page or that gets updated with new
| <option>(s) via HTMX when you push a button. Similarly you
| might have a form that can be rendered as the only form on a
| page or that can be rendered as a modal dialog that is pulled
| from the server when you open the modal (as opposed to unhiding
| it.). Either way the code that draws the HTML fragment (both
| the template and any database fetching/thinking) has to be
| runnable in more than one context. (Modal dialogs are so fun to
| implement with HTMX.)
|
| It's something you can do in a situational way or that you
| could have a framework to help with, but it is part of the HTMX
| puzzle.
| matwood wrote:
| I wrote ASP then, and it worked fine. We also wrote our own
| htmx like handlers. The main reason that people forget is
| that js was just too slow on the client to really do
| anything. The only way to get performance was render pieces
| on the server and replace the client html.
|
| I remember having the server render js multi-dimensional
| arrays consisting of key and html snippet that client js
| could reference to do html manipulation more quickly.
|
| Good times.
| 3cats-in-a-coat wrote:
| I'm not sure JS being slow was the reason. It's rather lack
| of trust that JS can and should be used for such things,
| and the difficulty of mixing client and server logic
| together. You kinda want to simplify things and relegate JS
| simply the role of detecting an event and delegating it to
| the server for processing and injecting the result back.
|
| But JS, from the moment it was introduced, was quite
| capable of carrying out a great number of interactions. We
| tend to project our subjective beliefs on the objective
| world. We don't see potential in JS and so we didn't use it
| up to its potential.
|
| I recall working on a webshop back in the day that opened
| in an embedded IE in the app for a popular music company
| (so I had also full control over the browser engine and
| could rely on JS), and there was a complex system of
| discounts as you add plugins to your cart and so on, and I
| thought: I'll use JS for this. And despite the discounts
| were verified on the server side, all my coworkers and my
| boss were intensely worried about me using JS for this,
| because I'll make the store insecure, and this is a very
| noob thing to do and I shouldn't be using JS for this.
| And... it worked fine. The tech was always capable of this,
| but none of then would've even TRIED, because they "KNEW"
| it's not supposed to be done.
|
| Eventually the tide turned, but it turned to another
| extreme, that is even more BS now. Many websites load more
| JS code than they load images. Why? Because we subjectively
| believe the server is not capable of all the richness that
| JS can deliver. Basically we didn't get smarter about any
| of this.
|
| We're stupid and led by superstitition about the tech we
| use, we don't really understand it, we don't grok it. We go
| by fashion and trends. Most do. And that's the danger of
| starting a stupid trend. It may take years before the
| bubble pops.
| tracker1 wrote:
| Most C#, .Net devs and even VBScript devs had very little
| desire to learn JS. Not to mention that prior to IE6
| becoming dominant there was a lot of very painful
| variance between browsers. JQuery helped to normalize
| this a lot. Part of why the ASP.Net (and others) were
| modeled with a full server postback. It worked fine when
| the server was in a server room in the corner of the
| building you were in, over the internet on dialup, not so
| much.
| PaulHoule wrote:
| In that time frame I was building very complex
| applications (semantic graph editors, decision support
| software for sales teams with 10,000 salespeople, etc.)
| in frameworks like GWT (Java compilers to Javascript)
| this wasn't long after the firstversion of Google Docs
| came out.
|
| Javascript was fast enough back then to make much more
| complex applications than most people were making back
| then but the complexity was mind-numbing, particularly
| considering that you didn't have tools like async/await
| to help manage asynchronous communications.
|
| I built frameworks for managing the flow of data in that
| kind of application and didn't feel it was so
| catastrophic when Microsoft banned synchronous
| communications in Silverlight... I knew what to do.
|
| Having had that experiment I tend to laugh at today's
| Javascript frameworks because they work really hard but
| aren't suitable for the kind of apps I built back then.
|
| Sometimes it seems there is a lot of "lost" technology in
| software like the production rules systems of the 1980s,
| CASE systems and Lotus notes from the 1990s, Google docs
| in the 2000s that are like Stonehenge or the Egyptian
| Pyramids seen from the state of programming in 2023.
| 3cats-in-a-coat wrote:
| Entropy creeps into everything, unstoppably, masked under
| the pretense of a sequence of individually logical
| choices. To recover from this we will have to take a few
| steps back before we can make more steps forward. But we
| keep pushing and pushing, until either the tower we're
| building collapses, or us and what we do simply gradually
| become more and more complicated, with smaller and
| smaller gains that we focus on more and more, until it's
| all indistinguishable from background cosmic noise. Fermi
| paradox resolved.
|
| Sorry, poetic diversion.
| tracker1 wrote:
| ASP.Net is different than Classic ASP... ASP.Net had a
| "WebForms" model, where the default behavior was a postback
| with a rerender on a lot of handler actions. That also
| included a ViewState input attached to your page/forms that
| was used for (re)hydration to handle change and other event
| detection. The use of viewstate with a lot of the component
| libraries at the time was pretty aweful. Not to mention
| feature/browser detection was just plain wrong as Firefox
| started to gain traction, before Chrome.
|
| I can say I migrated away and mostly separated
| render/js/backend with ASHX handlers until MVC took hold.
| These days, I tend to prefer the modern SPA models for
| browser applications. Though will also use static generators,
| server generation or other techniques if you don't need an
| interactive application.
|
| HTMX seems pretty interresting as a kind of in-between,
| closer to the ASP.Net Webforms without the complete excessive
| overhead in the box.
| wink wrote:
| The "beauty" of ASP was (is?) that it could be so many
| wonderful things. For me it was inheriting a codebase that
| was basically many HTML pages with VBScript AND JScript
| dynamic parts, in the same file.
|
| Imagine what everyone was saying about spaghetti PHP
| intermixed with HTML - but with 2 backend languages plus HTML
| and CSS, at least that was early enough that clientside JS
| was limited to changing images on hover...
| xtracto wrote:
| Aaaah php, cpanel and html/js : the mother of all
| buzzwords: serverless server side rendering.
| throwaway290 wrote:
| > Either way the code that draws the HTML fragment (both the
| template and any database fetching/thinking) has to be
| runnable in more than one context.
|
| I'm sure it's the matter of time for isomorphic HTMX-based
| frameworks... but they won't degrade gracefully. but then
| they will, as a new feature. the circle of life!
| strangescript wrote:
| "The fact your HTML barely reads like HTML after Tailwind, and
| reads more like your file is corrupted is I guess not mentioned
| in the tagline."
|
| There are a ton of ways to solve this issue but most people
| just look at tailwind on the surface and go shitpost about it
| on social media.
|
| Its the equivalent of saying "I wrote this 2k line program in
| one file, its so bad and disorganized <insert language here> is
| bad!"
| AtlasBarfed wrote:
| Coldfusion may have been one of the granddaddies, which java's
| JSP copied shamelessly.
|
| So many web revolutions touted as "don't use Java and all that
| big stack, instead use our SUPER SIMPLE stack called:"
|
| Rails: wow did rails eventually encompass a massive stack of
| dizzying extensions options and frameworks.
|
| React: I laughed when I saw basically a full rewrite of various
| Java unit testing frameworks in javascript.
|
| But HTMX seems to get love that angular/react/etc never got
| from a HN front page perspective.
|
| I take a dim view of AI so far, but one thing it could be
| fantastic for is "take this basic HTML application and write it
| in framework X" so I can finally see a good comparision.
|
| The web framework landscape has needed a "reference web app"
| since the year 2000 where frameworks could demonstrate their
| way of doing rendering, layout, validation, forms, routing,
| error handling, data binding / data retrieval, tables/grids,
| media. As in your web framework isn't even close to prime time
| unless you can show WHY it is novel or useful.
| Dylan16807 wrote:
| > React: I laughed when I saw basically a full rewrite of
| various Java unit testing frameworks in javascript.
|
| Why?
|
| Can't run java in a browser. (And don't bring up applets.)
|
| I suppose you could keep _most_ of a testing framework as
| Java code, and adapt the rest for testing javascript, but
| that seems fussy enough for a rewrite to makes sense.
|
| Edit: Okay, if people are going to downvote, then I'll
| elaborate. I understand amusement in people moving from one
| server language to another, only to recreate the same things
| they already had, because they could have just stuck with the
| original. But you _can 't_ just stick with a server language
| when you're writing an interactive web page. Trying to port
| the tools you like is making the best of the situation, not
| creating work out of nothing.
| montenegrohugo wrote:
| Have loved HTMX for small projects so far, quite delightful.
|
| Does anyone know what they have on the roadmap for 2.0? I'm
| curious what they are working towards.
| elliottinvent wrote:
| Very active, helpful community on Discord [1] and a #htmx-2-dev
| channel for discussion on this very topic
|
| 1. https://htmx.org/discord
| samsquire wrote:
| HTMX reminds me of pjax which I really liked
|
| I did a lot of sideprojects in Knockout and one large one in
| Angularjs 1.
|
| I feel all the frontend frameworks need to talk about what they
| see the problems are and decide how to fix them.
|
| I would like some solid foundations and avoidance of common pain
| and gotchas of scale and complexity.
|
| My old sideprojects are broken because I didn't fix library
| versions. My JSBIN sqlite file with my knockout projects in is
| also in an unknown version of JSBIN which latest JSBIN doesn't
| work with.
|
| The speed that frontend development moves has broken lots of my
| code.
|
| EDIT: Screenshots of my old experiments:
| https://github.com/samsquire/interface-experiments
| recursivedoubts wrote:
| yes, intercooler.js (which was the first version of htmx) was
| heavily influenced by my experience with pjax!
| JodieBenitez wrote:
| I used this in the past: https://malsup.com/jquery/taconite/
| mikece wrote:
| Am I the only one who looks at HTMx and thinks "this is like CICS
| all over again"?
| jaipilot747 wrote:
| This CICS? https://en.m.wikipedia.org/wiki/CICS
|
| Could you elaborate?
| mikece wrote:
| Yeah that one: full screen sent down from the mainframe on
| the beginning of a page-interaction, then only the parts of
| the screen that need to be changed are sent over the wire
| based on commands and input. With CICS it was all about
| reducing the number of bits moving over the wire to an
| absolute minimum which isn't the case here but partial screen
| replacement without refreshing or reloading the entire page
| is very reminiscent of the design.
| varispeed wrote:
| It looks like Angular on crack. I can see how this can quickly
| turn into unworkable mess.
| ris58h wrote:
| Not at all. What makes you think that it looks like Angular?
| samsquire wrote:
| Angular 1, I don't know about Angular 2 had syntax like ng-
| repeat <a class="item" ng-repeat="action
| in activeField.actions" ng-click="follow(action, $index,
| $event)"> {{action.text}} <i
| class="{{action.icon}} icon"></i> </a>
| hliyan wrote:
| A syntax-based comparison feels a bit... superficial. One
| is an MVC based SPA framework. The other is best
| described (in my mind) as syntactic sugar over AJAX calls
| that replace inner HTMLs of selected targets.
| itslennysfault wrote:
| Yeah, honestly (ignoring syntax) it looks A LOT like the
| original ROR ajax implementation. Having the server
| render a partial and swaping out the inner html to do a
| partial page update.
| samsquire wrote:
| No - from my perspective - it's important and for
| understanding maintainability. The syntax helps
| understand the mechanism of using HTML directives that
| are picked up by clientside javascript at pageload or
| AJAX HTML partial replacement, which is what GP was
| getting at with its comparison to Angular 1. Angular 1
| picks up directives the same way (and Knockout).
|
| In react you don't use the mechanism of directives, you
| use JSX or React.createElement in standard Javascript
| statements or expressions.
|
| I think it's important because it decides your templating
| and composition, which is what React solves with its
| Components.
|
| I played with pjax which is similar.
|
| EDIT: For example, you might not want ng-click in your
| HTML if you think that is wrong for example, as it's like
| DHTML and onclick="" (I don't have a perspective on this
| at this time)
| ris58h wrote:
| There are a lot of frameworks/libraries/template-engines
| that use custom attributes and similar syntax and Angular
| definitely wasn't the first one.
| jbergens wrote:
| I think Angular looks like Htmx on crack but I do remember
| that Angular was first.
|
| We used it in a project and it worked perfectly. If you have
| the need to write a lot of logic and changing of most of the
| UI parts dynamically on the page then
| React/Vue/Svelte/Angular is better suited. If you on the
| other hand has page that could be server rendered and some
| parts or lists that should load new parts into the page this
| may be the easiest way to do that.
|
| You can also combine it with any backend language instead of
| us having one framework for C#, one for Java, one for Go and
| so on. I think this is one of the biggest USPs for Htmx.
| synergy20 wrote:
| it does not work well with the ever growing restful API backend
| services to me.
| WeAddValue wrote:
| That's the whole point. Those "restful API backend services"
| are not really REST-ful. The essay, "How Did Rest Come To Mean
| The Opposite of REST"[0], explains this better than I ever
| could in a HN post. Maybe we should stop growing these Data-
| APIs (returning JSON) and switch back to Hypermedia-APIs
| (returning HTML).
|
| [0] https://htmx.org/essays/how-did-rest-come-to-mean-the-
| opposi...
| simonbarker87 wrote:
| How so? (no snark, genuine)
|
| Your frontend makes a request to your server, the expectation
| is that will respond with html.
|
| If you have other services you need to bring in to the mix that
| responds with JSON then make the request to them from your
| server, have that parse the JSON in to HTML (most likely some
| kind of templating system like handlebars) and then send that
| back to your frontend as html for htmx to handle.
|
| Or am I missing something?
| suction wrote:
| [dead]
| withinboredom wrote:
| Dear god. Have we forgotten about the ACCEPT header? If you
| get a request with ACCEPT application/json, return json. If
| you get one with text/html, return html.
| bpicolo wrote:
| JSON APIs are typically more general. Here, you'll need
| different endpoints/handling for every flavor of HTML you
| may show that uses that same dataset. It's not so simple as
| Accept headers unless you always use exactly the same html,
| in every context on your site, to represent a "user with ID
| <foo>"
| withinboredom wrote:
| Not at all. Post a form submission, send back either the
| same form with errors displayed, or simply return out-of-
| band updates to error message divs. You can redirect from
| the response as well using htmx, so if the form
| submission is successful, you can redirect to a success
| page ... or simply update a div with a success message.
|
| If you get a request asking for json, you just return a
| json with the same thing. Not much changes with API
| design if you were designing the API well in the first
| place.
| simonbarker87 wrote:
| Not sure if your "Dear god" is negatively targeted at my
| comment - I'll assume it's a general show of exasperation.
|
| How likely is it every API will adhere to that though?
| withinboredom wrote:
| Yeah, just exasperation. For the longest time, most APIs
| would return json if you asked for json, or xml if you
| requested xml. Many older api's still do content
| negotiation, many gave up because 'xml bad'.
| monknomo wrote:
| Yeah, I remember a lot of apis that were something like
| `resource/instance.json` or `resource/instance.xml` and
| they'd give you `instance` in whatever the requested
| format was
| simonw wrote:
| I don't think using the accept header is a good idea.
|
| The main reason is that it doesn't necessarily play well
| with proxies. Most notoriously, Vary: Accept is not
| supported by Cloudflare (with the exception of images).
| This means it's not safe to use the accept header if your
| site will ever be backed by Cloudflare, as you could end up
| returning cached HTML to a JSON client or vice-versa.
|
| https://developers.cloudflare.com/cache/concepts/cache-
| contr...
|
| My other problem with it is that it's not very discoverable
| - it can be surprising to interact with an endpoint that
| varies based on the accept header. It's not commonly used,
| so many developers are unfamiliar with it.
|
| And even if you do understand it, it's still hard to tell
| which endpoints support Vary and which don't.
|
| Finally: I like to debug things by copying and pasting URLs
| around. The Accept header doesn't support that kind of
| communication - you need to share not just the URL but also
| the accept header you were using when you saw a specific
| response.
| withinboredom wrote:
| I'm not a fan of vendors "not supporting something" as a
| reason to not use something. Either get a new vendor, put
| pressure on the vendor, or ignore the feature you want to
| use.
|
| I personally don't care about what cloudflare does
| because I don't use them.
|
| The rest is RTFM for whatever API you are calling and you
| usually have to send auth or cookies anyway, so an accept
| header isn't that big of a deal.
| simonw wrote:
| I dropped Accept header support from
| https://datasette.io/ because it's open source software
| that I build for other people to use, and I knew that it
| was very likely one of my users would choose to run it
| behind Cloudflare (or run it on a vendor like Vercel who
| might have a partnership with Cloudflare).
|
| https://github.com/simonw/datasette/issues/1534
| mikece wrote:
| The twists and turns my career has taken had me pretty much skip
| the whole front-end JavaScript framework wars so it's nice to see
| "plain old HTML" make an enhanced comeback.
| buro9 wrote:
| The site and it's examples do not work with JavaScript
| disabled.
|
| This is a regression on graceful degradation.
| airtag wrote:
| Yes but for your own projects you could have a first page
| with a "no JS" div and attach a HTMX load request. That's how
| I did my first HTMX project and it works well informing you
| to turn on JS.
| throwaway154 wrote:
| That's a shame, and bad use of htmx, these examples shouldn't
| be showcase examples.
|
| It takes careful but not extraordinate thinking to think of
| ways to get consistent results with or without JavaScript
| turned on. Indeed, when a visitor hits a site for the first
| time they get the full response so everything for a graceful
| degradation should already be there to use. If I can figure
| it out, I'm sure big CS brains can.
| michaelchisari wrote:
| Love Htmx but confident the hardest part of implementing will be
| convincing managers and designers to fully rethink how to
| approach UX and product in a way that privileges simplicity over
| presentation.
| ilaksh wrote:
| If you think htmx is cool, check out _hyperscript
| https://hyperscript.org/. Made by the same people, available with
| htmx I believe.
|
| After seeing _hyperscript, it looks like they may have invented
| that first, and a lot of people's heads exploded, so they decided
| to try to make a "gateway drug" to sneakily introduce
| _hyperscript, and came up with htmx.
| recursivedoubts wrote:
| :) hyperscript came after htmx
|
| htmx is version 2 of intercoolerjs:
|
| https://intercoolerjs.org
|
| which had a proto-scripting language in it, the `ic-action`
| attribute:
|
| https://intercoolerjs.org/attributes/ic-action
|
| i dropped that attribute (along w/ the jQuery dependency) when
| I created htmx, but I felt there was some merit to the idea of
| a lightweight scripting language that abstracted away async
| behavior. Once htmx had stabilized I revisited the idea,
| remembered my experience w/ HyperTalk as a young programmer,
| and decided to take a shot at that, but for the browser.
|
| I'm very happy with how it worked out, although I expect it
| will always be niche when compared with htmx, which has much
| broader applicability and isn't as insane looking. :)
| ilaksh wrote:
| Well, congrats on both projects. _hyperscript especially to
| me looks like an amazing technical accomplishment, to make
| something so similar to natural language. What sort of parser
| is it? LL? LR? Because I would need to use an _LLM_ to handle
| that. Lol.
| recursivedoubts wrote:
| just recursive descent w/ some hacks in there to make
| things "look right" :)
| keb_ wrote:
| The practice of cramming a DSL into an HTML string attribute
| seems like it would get cumbersome and hard to read after a
| while. You can really tell in this example on the htmx site
| [1]. I imagine you can write that long string in your server
| code somewhere, but that also seems weird especially since you
| won't have _hyperscript syntax highlighting in your
| Ruby/Go/Clojure/whatever file. Does anyone have any real world
| examples of this?
|
| [1] https://htmx.org/examples/confirm/
| imbnwa wrote:
| Htmx strikes me as what we would've gotten earlier if we didn't
| throw XHTML and namespaces out with the bath water. Namespaced
| attributes, perhaps even tags, that already package and compose
| behavior seems like the natural outcome of browser spec writers
| reifying community conventions over time, and that kind of
| superimposing is precisely what XML facilitates.
| dontupvoteme wrote:
| What is github now?
| avisser wrote:
| A wholly owned subsidiary of the Microsoft Corporation.
|
| So this is ... marketing?
| podgorniy wrote:
| Secondhand marketing: people with popular repositories are
| praising github who praises them
| pictur wrote:
| In recent years, I have not seen another tool that is so
| inflated. The attention it can garner for a tool where all it
| does is do simple things by adding attributes to html elements is
| really weird. Anyway, we need to act as if adding an attribute to
| the button and changing the value written in it is a very big
| need. Great job congratulations.
| basique wrote:
| It can do a lot more than just changing the value written in a
| button. I'd say that the hype is more centered around the fact
| that it helps you to do much more interactive and SPA-like
| websites without needing a full JS framework and on your
| favourite server stack, which is honestly really cool.
| elliottinvent wrote:
| > all it does is do simple things by adding attributes to html
| elements
|
| It's extending html to make the most of http by adding some
| simple attributes.
|
| Like all great things - the building blocks are simple, but the
| possibilities of what you can build with them is vast.
|
| I think this is really well dealt with in the "opportunities"
| to extend html in this chapter of the Hypermedia Systems book:
| https://hypermedia.systems/extending-html-as-hypermedia/
| esseti wrote:
| is it a june news? the url is 2023-06-06
| RileyJames wrote:
| Man. Love this. React for a purpose. Htmx and Hotwire for the
| rest. The debt years saved are for humanity.
| fleetfox wrote:
| There are many applications where htmlx is objectively the best
| tool. But i really hate all the hype around it and people pushing
| it as react replacement.
| agumonkey wrote:
| Had an heated debate with someone that was really angry at
| everything react, for good reasons, but being oblivious that
| htmx can't replace client side logic. React hype + backend
| crowd I guess.
| thefreeman wrote:
| as a primarily backend dev I really don't see the appeal
| here. So now I need to make endpoints for every little UI
| element that I want to be updated by user interactions? And
| somehow keep it styled and matching all of the UI elements
| rendered on the frontend? No thanks, I'll just give you data
| and you can present it however you please.
| lucidone wrote:
| Most applications that would leverage this (e.g. server-
| side rendered Rails or Laravel or Django) already have
| those templates as partials for their views, so leveraging
| the functionality is trivial.
| purerandomness wrote:
| > So now I need to make endpoints for every little UI
| element that I want to be updated by user interactions?
|
| What's the alternative?
|
| You want interactivity that users can trigger. You'd need
| to call an endpoint in some way or another, giving you
| updated data, no?
|
| > And somehow keep it styled and matching all of the UI
| elements rendered on the frontend?
|
| Wait, how are your other UI elements rendered? How are they
| styled?
|
| _Somewhere_ in your code, you 'll have a step where you
| generate HTML with CSS classes. It's popular to use React
| for this step, or some form of SSR where you render HTML
| templates.
|
| With HTMX, you can simply reuse the same backend SSR
| templates that you were already using, and extract some
| parts of it which you want to be interactive. These will be
| rendered whenever you trigger an action, by HTMX fetching
| that part of the template.
|
| If you want to strictly split frontend and backend
| development for some reason, you can totally do it: You'd
| have a business logic layer that provides data to the view
| layer within your app (be it JSON, or POJOs), and the
| frontend team styles that data in the view layer however
| they please.
|
| And the benefit is that you'd all render it on the server.
| No need for the client's browser to do anything anymore.
| It's all coming pre-rendered, cacheable and indexable.
| Done.
| suction wrote:
| [dead]
| Skinney wrote:
| > So now I need to make endpoints for every little UI
| element that I want to be updated by user interactions?
|
| No. Htmx supports extracting a subset of received HTML and
| merging it with the current page.
|
| So, for a typical form, you _could_ do a request to
| validate the entire form then extract the relevant error
| message for the input field that triggered said request.
|
| This would re-use most code of the actual form submit
| endpoint except it _only_ does the validation.
|
| > And somehow keep it styled and matching all of the UI
| elements rendered on the frontend?
|
| When using Htmx, the backend would typically own the
| frontend. So the styles and UI elements are already
| "matched" as it were.
|
| > No thanks, I'll just give you data and you can present it
| however you please.
|
| This makes sense when there are multiple frontends and/or
| consumers of the API. When there is exactly one API
| consumer, and that API consumer is the frontend, Htmx can
| save a lot of time by reducing the overall complexity of
| the project.
| doesitbollocks wrote:
| Could you link to an example on extracting parts of the
| form? I have a feeling I'm using way to many routes to
| handle every specific case!
|
| Thanks.
| Skinney wrote:
| I think you'd use hx-select:
| https://htmx.org/docs/#selecting-content-to-swap
| withinboredom wrote:
| No, you just submit the form like normal and redirect (via
| htmx) to a success page, or return errors using out-of-band
| updates in the response.
| chainwax wrote:
| Congratulations! I had a fun time making a little project with
| Htmx, though ultimately went with something else as I ended up
| heavily using a openlayers, and map libs are notoriously heavy
| with clientside javascript and Svelte ended up being a better
| tool for the job.
|
| I plan on using it again for a future Golang project and look
| forward to following it's development. If you're in need of a
| simple/medium complex front end for your app, and _especially_ if
| you're already using template fragments[0], I really recommend
| giving HTMX a shot. It's pretty fun to work with coming from
| Javascriptland.
|
| Also, the guy who runs their Twitter account[1] is hilarious.
|
| [0] https://htmx.org/essays/template-fragments/
|
| [1] https://twitter.com/htmx_org
| PaulHoule wrote:
| I've had good luck combining HTMX with D3.js but I've treated
| D3.js visualizations as "just another HTML element" with any
| particularly complex interaction with the rest of the site.
| chainwax wrote:
| My map has a _bunch_ of controls overtop of it that let the
| user mess around with what's displayed.
|
| Could I have made it work? Yes
|
| Could I have just made the map it's own self-sufficient
| component and left the rest of the app as is? Also yes
|
| Did I do these things? No. As one tends to do, I just nuked
| it and started over
| RGBCube wrote:
| The guy that manages their Twitter account is the creator
| himself: @recursivedoubts
| T3RMINATED wrote:
| [dead]
| norwalkbear wrote:
| Coming from the Unity world, I find frontend development on the
| web weird as hell.
|
| When accounting for the limited amount of time and mental load
| people have, wouldn't the best bang for your buck be doing
| react/vue/js?
| danpalmer wrote:
| Arguably you've got to learn HTML, so why then add learning
| React/etc on top of that?
|
| HTMX is more limited, but also _radically_ simpler to modern
| frontend development.
| norwalkbear wrote:
| People want and expect pretty and interactive experiences. I
| don't think they care how they get there. I've written some
| Unity "web" apps by using the port to webgl feature, so I
| have no deep fondness of html or js. I just need results.
| avisser wrote:
| > People want and expect pretty and interactive
| experiences.
|
| Counterpoint: a majority of websites are for business where
| they want the form to submit and update the database.
|
| And to me, pretty = CSS + removing full refreshes, which is
| what HTMX does.
| danpalmer wrote:
| Sure, I'm just suggesting that "best bang for the buck" may
| well not be React/etc, because it's a lot more "bucks" for
| often not much more "bang".
| andy800 wrote:
| With a little creativity, HTMX can enable some extremely
| UX-friendly interactive sites. Keep in mind that it makes
| it trivially easy to entirely swap out small, or large,
| sections of a web page. So things that used to be standard
| boring forms can be interactive step-by-step pathways that
| adapt to the user's selections. Very easy to deliver
| progress updates and validation cues to users that seem to
| appear magically without page reloads. It's still early but
| HTMX continually inspires me (a poor designer) to execute
| new UI ideas because it makes it very simple to
| conceptualize how they can be built (and simple to actually
| build). Tailwind is also essential in this process, for me.
| robertoandred wrote:
| You have to learn whatever templating system you're using on
| the backend as well, so not really much simpler.
| zenith035 wrote:
| Awesome news. I have been a user since intercooler.js days and
| then moved to htmx.
| recursivedoubts wrote:
| hi there, as many of you know, i am the creator of htmx and I'm
| happy to answer any questions about it
|
| htmx has seen a surge in popularity, triggered by a video by
| fireship dev (https://www.youtube.com/watch?v=r-GSGH2RxJs) and a
| series of videos by ThePrimeagen, a popular twitch streamer on it
|
| hacker news readers might be interested in the essays I have
| written on htmx & hypermedia in general here:
|
| https://htmx.org/essays
|
| and in a book I authored with a few other writers that we
| recently released on hypermedia, htmx and a mobile hypermedia
| called Hyperview:
|
| https://hypermedia.systems
|
| while I am a fan of htmx, obviously, I think the deeper concept
| that it touches on is hypermedia, which is a worthwhile idea for
| people to explore even if they don't plan on using it in day-to-
| day programming.
|
| There are also lots of other great hypermedia-oriented libraries
| worth checking out such as Hotwire from 37signals, or, my
| favorite after htmx, https://unpoly.com
| tommica wrote:
| Stupid question, why doesn't htmx parse the response html and
| extract from that the relevant data out needs to fulfill the
| configuration? Feels a bit cumbersome to return the exact part
| of the response on server side, like the next page of the
| table, if it was requested with htmx, else return the full
| page.
|
| This way htmx would be even easier to implement in any front-
| end.
|
| Or maybe I am just crazy.
|
| Edit: or is it this? https://htmx.org/docs/#selecting-content-
| to-swap
| Lukas_Skywalker wrote:
| Rails does this with Turbo Frames [1]. When clicking a link
| that is contained in a <turbo-frame> element, the frame is
| automatically replaced if the response contains a frame with
| the same ID.
|
| 1: https://turbo.hotwired.dev/handbook/frames
| spapas82 wrote:
| This is how unpoly works (it receives the whole response and
| patches the page with the correct part of that response).
| tommica wrote:
| Oh that's cool!
| phplovesong wrote:
| One minor thing. This is not an issue directly with htmx, but
| more on the backend. This always feels clumsy for me:
|
| I land on the index page, and get the full site, then click on
| about page, and now htmx swaps the content for the about page.
| However if i refresh the url stays the same, but i now only get
| the content without the container.
|
| I know this can be solved with checking for a htmx header, but
| i feel like "there must be a better way" like raymond httinger
| of python fame has said multiple times.
| recursivedoubts wrote:
| i typically have a middleware component that decides whether
| to render the "chrome" around a given response, so my
| controller methods aren't junked up with it
|
| worth thinking more about though
| logankeenan wrote:
| What plans do you have for 2.0?
| recursivedoubts wrote:
| No major changes, it should be about 99% API compatible with
| htmx 1.x. Big things:
|
| - Websocket & SSE support will be completely pulled out to
| extensions (already available in 1.0)
|
| - We will drop IE support
|
| - We _may_ include a "morph" swap strategy based on
| idiomorph (https://github.com/bigskysoftware/idiomorph/)
|
| - We will change a few defaults around how HTML is parsed,
| taking advantage of the removal of IE support
|
| Hopefully transparent to the vast majority of htmx users.
| bardak wrote:
| Will HTMX 2.0 have a smaller bundle size since you are
| removing things? I don't think HTMX is too big or anything
| but I have a love tiny libraries.
|
| And on that note do you think that a smaller striped down
| version of HTMX is feasible like petite-vue is for vue
| recursivedoubts wrote:
| I don't think the bundle size will shrink too much,
| especially if we include the morph-style merge, which is
| somewhat complicated
|
| yes, I think you could do a stripped down htmx that
| doesn't support a lot of the stuff htmx does,
| particularly life cycle events and more elaborate
| swapping mechanism
|
| for example, most response headers could be just done as
| the HX-Trigger response header + some client side
| scripting
|
| history support and form-value gathering is likewise a
| source of complexity and code that could be omitted or
| done less completely
| bardak wrote:
| Sounds like reasonable places to strip out stuff while
| keeping the fundamental features. I think the history
| support would be important enough to keep though.
| grose wrote:
| Just wanted to say thank you for what you do. I've long been a
| fan of HATEOAS and I'm very happy that there's finally a
| movement towards it and ecosystem growing. Also, the memes are
| unparalleled.
| habosa wrote:
| Not the point if your post but it's amazing how influential the
| Fireship team is! A true developer influencer, without being a
| cult of personality.
| recursivedoubts wrote:
| yeah, he was the one that really started the madness:
|
| https://star-
| history.com/#bigskysoftware/htmx&bigskysoftware...
|
| his video posted on july 7th
| foxy4096 wrote:
| https://twitter.com/foxy4096/status/1691432812870828032?s=20
|
| This is a boon to many django developers.
|
| I remember few month ago I was making a post liking system,
| before htmx, I had to use jQuery to fetch the json api server
| and update the like count, but with the use of HTMX, oh boy it
| was like I was just writing plain html along with my django
| logic.
|
| This is one of the greatest thing I've found.
|
| Also, handling forms with HTMX is also very easy.
|
| HTMX really improve both user and developer experience.
| nicois wrote:
| I've also found htmx a great way to retain server side
| rendering with minimising the recalculation cost of client
| changes.
|
| By avoiding needing to add lots of client side logic to still
| get very low latency updates, it's given me the best of both
| worlds.
|
| The way Django's template system works also makes it so easy
| to render a full page initially, then expose views for
| subcomponents of that page with complete consistency.
|
| On a tangent, Django's async support is still half-baked,
| meaning it's not great for natively supporting long polling.
| Using htmx to effectively retrieve pushed content from the
| server is impeded a little by this, but I slotted in a tiny
| go app between nginx and gunicorn and avoided needing async
| he'll without running out of threads.
| eddd-ddde wrote:
| The other day I wrote an htmx extension for aws api. You
| could describe an element using the common htmx tag such as
| for confirmation, triggers etc, but the ajax fetched any aws
| object like ec2 instances, pipelines, whatever. It's awesome!
| perpil wrote:
| I'd be interested in learning more about this can you share
| any links?
| recursivedoubts wrote:
| i'm very glad to hear you are finding it useful :)
| paczki wrote:
| As someone relatively new (few months in) to full-stack
| development, what can HTMX offer me? I've been semi interested
| since Prime mentioned it a handful of times, but I feel maybe
| I'm too new to fully understand what I gain from it. As soon as
| I'm finish with my current project, I'd like to check it out.
|
| For reference, I'm currently working within the T3 Stack.
| internet101010 wrote:
| Simplicity. You don't have to become another React Andy and
| deal with all of the complexity that comes with it.
| riskable wrote:
| HTMX is just a convenient way of handling user-initiated UI
| updates AJAX calls (for whatever purpose). So instead of
| writing some JavaScript that looks for a specific element to
| attach an `onclick` event and subsequently makes an AJAX call
| then again searches for an element on the page to update with
| the result you can put some (very simple) HTMX code in the
| HTML directly and it'll handle that sort of thing
| automatically; "without having to think."
|
| It's just a nice, convenient way of handling such things. The
| argument in the article is that "this is how HTML should've
| been from the start" because it lets you do some pretty
| sophisticated stuff just by adding some simple/intuitive
| attributes to the HTML.
| nonethewiser wrote:
| So my apis need to return html specific to the page its
| called from with the data embedded? I guess my apis would
| need different endpoints that return json for other
| clients. And different endpoints for the exact same data if
| they need to be displayed differently? It just seems like a
| bad thing to couple. What about CSS? I guess you have to
| look at what the server returns to figure out how to
| select/style it.
|
| I recognize thats how templates work but for some reason it
| seems weirder when applied to the element, rather than page
| level.
| throw1234651234 wrote:
| This will just die like Web Components and RxJS after a few
| people write blog posts and do conference talks on it for hype,
| right?
|
| Does this work with Web Assembly? Of course Web Assembly will
| die too since it can't do SEO.
|
| In all seriousness though, what is the "core" reason to
| actually adopt this over the current approach?
| recursivedoubts wrote:
| if you sincerely wish to understand how htmx is different
| than the current SPA-talking-to-a-JSON-API approach I would
| start here:
|
| https://htmx.org/essays/hypermedia-driven-applications/
|
| and then work through the rest of the essays:
|
| https://htmx.org/essays/
| throw1234651234 wrote:
| Thank you, reading now - do genuinely want to know. I
| understand how my message came across, but I do
| intentionally reflect how many attempts there have been to
| change the paradigm so far.
| recursivedoubts wrote:
| no problem, i try not to take things personally online:
| i've said plenty of things that either were mean or came
| across as mean in my life, especially when I was younger
|
| i think one of the strengths of htmx is that it isn't
| really trying to change the paradigm to something brand
| new, it is instead going back to the original web
| paradigm of hypermedia and asking how HTML could have
| advanced within that paradigm, in contrast with the SPA
| paradigm that replaced it
|
| so less of a wild bet, with more known advantages and
| disadvantages
| andy800 wrote:
| Not a valid excuse, dude. You have every right to be
| skeptical or to avoid "bleeding edge" but to assume the
| whole thing is just a front to raise someone's
| speaking/blogging/social media profile, to buzz in from
| nowhere and start off by declaring that it's going to
| "die" is not the way to act if you "genuinely want to
| know."
|
| Recursivedoubts has legitimately demonstrated he's not a
| one-trick pony (previously built intercooler,
| concurrently building hyperscript) and he deals with
| skeptics like yourself dozens of times every time an HTMX
| article gets posted on this site (which all seem to go to
| #1, if that serves as an indicator of the library's
| popularity). He handles himself with grace and patience
| and humor, far better than most of us would do.
|
| You don't even state what your "current approach" happens
| to be in order for him, or anyone else, to provide you
| with a satisfactory answer.
| enahs-sf wrote:
| Hello,
|
| Maybe stupid question, but what are the downstream implications
| for folks like Vercel/Netlify/etc. who bet the farm on complex
| server rendered JS pipelines?
| recursivedoubts wrote:
| i don't think there are major implications: the web
| development world is still very react/javascript/JSON-centric
|
| there is no reason that they can't tweak their services to be
| more hypermedia friendly if and when this approach becomes
| more popular
|
| netlify (which offers free hosting for https://htmx.org, so
| is a sponsor of the project) is very HTML/hypermedia friendly
| as far as I can tell, and I don't have enough experience w/
| vercel to say much other than a vague sense that they are
| extremely react-oriented
|
| no reason that can't change as the market changes though:
| hypermedia pushes the main value locus of applications back
| on the server side and so server-side companies should like
| that
| nchmy wrote:
| Fuck those hucksters...
|
| https://twitter.com/rauchg/status/1619492334961569792
| [deleted]
| javajosh wrote:
| _> a video by fireship dev
| (https://www.youtube.com/watch?v=r-GSGH2RxJs)_
|
| That's a great video explaining the core use-cases of htmx in
| 100 seconds. Would be great if all projects had such a thing!
| Htmx reminds me of tailwind in that you've created a set of
| attribute names and values that are picked up at runtime by a
| singular library. There's no front-end build required, which is
| a Very Big Deal for most devs who don't want (and shouldn't
| have to) to mess with npm and webpack. It looks like the
| "breaking point" for page size is something like a small SPA -
| when it gets to big, make another SPA.
|
| Particularly for react/vue devs I think the thing they'll miss
| is the _idea_ of a uniform, singular object representing global
| state that is rendered by a single function (defined
| hierarchically in your component codebase) into the UI.
| However, it must be accepted that this idea is very demanding
| in itself, resulting in lots of opinions and hurt feelings, and
| in addition comes with the weight of a front-end build (and all
| the confusing variation there).
|
| I don't use it but I'm already a big fan. Congrats!
| guggle wrote:
| > my favorite after htmx
|
| That's interesting. I discovered Unpoly after HTMX (which I
| like) and decided to stay with Unpoly for a few reasons. Do you
| think hypermedia libraries will converge or do you think there
| is space for different interpretations ?
| recursivedoubts wrote:
| i definitely think there is room for multiple implementations
|
| unpoly is higher level than htmx, with different design
| sensibilities and concepts like 'layers'
| (https://unpoly.com/up.layer) which is something that doesn't
| make sense from htmx's "just extend HTML" perspective
| silver-arrow wrote:
| Exactly! I love the sweet spot that htmx hits; please don't
| change that!
| recursivedoubts wrote:
| :) i will not
| mollerhoj wrote:
| Same path for me here. In particular, I found unpolys
| codebase to be of higher quality.
| recursivedoubts wrote:
| henning is an excellent programmer, I really admire him and
| his work
| phplovesong wrote:
| The htmx author is an excellent programmer, I really
| admire him and his work
| recursivedoubts wrote:
| :) thank you I appreciate you saying that
| jeremyloy_wt wrote:
| I can't believe you aren't crediting your hilarious and
| pervasive ~~psyops~~ meme campaign
| recursivedoubts wrote:
| first rule of psyops...
| scoofy wrote:
| I owe you a beer or 6. Let me know if I can pitch you a few
| bucks.
| dylanjcastillo wrote:
| Awesome work! I love the simplicity of htmx. It's one of those
| tools that makes me feel super productive.
|
| Will there ever be a "htmx" for building mobile apps?
| recursivedoubts wrote:
| there already is!
|
| https://hyperview.org/
|
| Adam Stepinski, the creator of Hypreview, built it after his
| experience with intercooler.js, the predecessor to htmx. It
| is a very interesting piece of technology and, through the
| magic of HATEOAS, allows you to update your mobile app
| instantly for all your users, without dealing with the mobile
| store!
|
| There is an entire section on Hyperview, written by Adam, in
| part three of our book:
|
| https://hypermedia.systems/book/contents/
| dylanjcastillo wrote:
| Amazing! Gonna check it out. Thank you!
| foxy4096 wrote:
| It might be a weird question,
|
| But why are the websockets and SSE are migrating to extensions?
| recursivedoubts wrote:
| doing them right requires a fair bit of code and I'd like to
| keep the core AJAX-focused functionality as small as possible
| mildred593 wrote:
| Do you think that at some point in the future, browsers could
| bundle in htmx or something similar, and that we could imagine
| web pages that have javascript disabled but with great
| interactivity due to htmx? This could perhaps be used as a
| security feature.
| pyrossh wrote:
| I've enjoyed using htmx and created a simple library in golang
| to help out. Here is an example app
| https://github.com/pyrossh/gromer/tree/master/_example
| hdlothia wrote:
| Gonna try this out!
| RileyJames wrote:
| Legend. Well done for supporting, and for putting your money
| where your mouth is and laying down some code.
| doitLP wrote:
| Are you also the writer of https://grugbrain.dev/?
| recursivedoubts wrote:
| yes :)
| GenericDev wrote:
| I love you. Thanks for making the web feel like the web again
| <3
| recursivedoubts wrote:
| :) i hope htmx is useful to you
| sdesol wrote:
| > htmx has seen a surge in popularity
|
| For those curious, here's some numbers for the last 6 weeks to
| put things into context:
|
| - 4147 new stars
|
| - 86 new contributors
|
| - New contributors account for most of the commits and issues
| created which is a very strong sign of growth. Even in very
| popular projects, it is usually existing contributors that
| contribute most of the code.
|
| https://devboard.gitsense.com/bigskysoftware/htmx
|
| Full Disclosure: This is my tool
| recursivedoubts wrote:
| very cool tool!
|
| we've had a new person come on the project who is focused on
| auditing PRs and getting the good ones in front of me, which
| helps a lot w/ getting new contributors in
| sdesol wrote:
| > focused on auditing PRs
|
| Something like this
|
| https://reviews.gitsense.com/insights/github?q=pull-
| age%3A%3...
|
| might help as well. Click on the different pills (Authors,
| Targets, Days open, ...) to get a different view of the
| contributions.
| pragma_x wrote:
| This is a great project, and reminds me a lot of where folks
| saw hypertext going many years ago.
|
| I have read a little of the website and picked through many of
| the online examples. One thing I did notice is the preference
| to update client state (DOM rewrites) based on server HTTP
| request responses containing full-blown markup. Does the HTMX
| framework provide concessions for client-side-only triggers and
| client generated content?
|
| The reason why I ask is that an advantage of the current crop
| of JS heavy-client frameworks is they offload as much work to
| the browser as possible. This can result in less resource use
| on the server end (e.g. data, CPU), which is a big deal for
| web-scale apps. Is HTMX able to meet these kinds of engineering
| goals or is the project intended to do something different
| entirely? I totally get that something like a Facebook client
| is not at all hypermedia oriented, but folks are going to draw
| the comparison anyway.
| recursivedoubts wrote:
| we do have a client-side template extension:
|
| https://htmx.org/extensions/client-side-templates/
|
| however, I would encourage most folks to use HTML as the
| network format: it typically isn't much more CPU to generate
| the equivalent HTML string that corresponds to a JSON string
| (sometimes even less, as with tables)
|
| for pure client-side, htmx is largely hands off. We support
| an `hx-on` attribute to address the fact that HTML doesn't
| support general `on*` attributes, but that's it
|
| it does, however, emit a large number of events that you can
| hook into to extend things:
|
| https://htmx.org/reference/#events
|
| And it plays well w/ scripting solutions like Alpine.js or,
| our our own scripting solution, _hyperscript:
| https://hyperscript.org
| lcnPylGDnU4H9OF wrote:
| Another benefit of using HTML is ease of progressive
| enhancement. If the default behavior of the server is to
| render a full HTML page, anyone hitting that URL directly
| will get the full HTML from the server with no additional
| back-end work. Additionally, if JS is disabled in the
| browser, links still work as traditional links.
| the_gipsy wrote:
| Generating some HTML instead of JSON isn't that much
| data/CPU. But doing all that in the browser might have a big
| impact on UX performance-wise.
| intrasight wrote:
| This doesn't make sense. Can you elaborate? If it's not
| much work for the server, why would it be work for the
| browser?
| the_gipsy wrote:
| JavaScript is single-threaded, so whatever CPU work is
| going on will compete with the UI responsiveness. Even
| mobile apps, which run a dedicated thread for each,
| probably won't do one single clean UI update in response
| to the server-response.
| crabmusket wrote:
| Nolan Lawson demonstrated using a web worker to perform
| virtual DOM updates in 2015. Sad it hasn't caught on in
| any of the major frameworks.
| https://pocketjavascript.com/blog/2015/11/23/introducing-
| pok...
| chrisweekly wrote:
| I'm not the GP but I'd say it's not "just" doing that
| render-blocking work on a single thread on a potentially
| under-powered mobile device, it's also introducing
| significant latency to fetch, parse and execute the code
| that will render to the DOM.
| abrahms wrote:
| Mobile phones have less powerful CPUs. Parsing large json
| objects and then building up a corresponding html
| structure may be more difficult than on the server (where
| you already have it loaded into memory anyway).
| intrasight wrote:
| > Mobile phones have less powerful CPUs
|
| True - but not by much
|
| > Parsing large json objects and then building up a
| corresponding html structure may be more difficult than
| on the server
|
| I doubt it. And you'd only be doing "large JSON objects"
| for a desktop web app, where CPU differences vs web
| servers are even smaller
|
| > where you already have it loaded into memory anyway
|
| Likely not true if implementation uses streaming
| semantics
| nchmy wrote:
| > true - but not by much.
|
| False. https://infrequently.org/2022/12/performance-
| baseline-2023/
| spion wrote:
| How do you organize a backend for a htmx based frontend?
| Specifically getting templates that serve as reusable
| components, but also endpoints (there is some proliferation of
| endpoints which I remember from my days with ASP.NET MVC
| partials.
| recursivedoubts wrote:
| depends a lot on what your backend gives you
|
| i agree it can spiral out of control if you try to do too
| much, e.g. a routes file that is just incomprehensible
|
| i often end up reusing the same controller method to handle a
| few related routes, using pattern matching in the route
| declaration
|
| i think also picking your battles and not getting too fiddly
| with screens that don't matter so much also helps a lot here
| traverseda wrote:
| So you start by just re-sending the entire page but with
| content changed. Generally you'd use query parameters, like
| say you have a page with a table and you need to sort it. Add
| to your query parameters what order you want them in, re-
| render the whole page.
|
| Then once you've got it figured out you just return the part
| of the template that you actually need to. Makes sense when
| you think of it as a progressive enhancement on a plain html
| page.
| toddmorey wrote:
| Congrats on the GitHub program! Very cool.
|
| I just had a fresh read of the docs and htmx is refreshingly,
| gloriously simple--such a breath of fresh air. So natural,
| self-documenting, and well thought out. It _does_ feel like a
| natural extension of html.
|
| To me, the only "missing" piece of htmx is a component model,
| but for anyone looking for that, htmx would pair amazingly well
| with Astro[1] which allows you to define and use html
| components without the runtime overhead of say Vue or React.
|
| [1] http://astro.build
| toddmorey wrote:
| Also: I think every project / saas service should be required
| to have a footer haiku: javascript fatigue:
| longing for a hypertext already in hand
| nraf wrote:
| Curious if anyone familiar with Drupal's AJAX implementation (at
| least how it was in v5-7, I haven't used Drupal v8 onwards) back
| in the day and has used this can offer a comparison?
|
| A sense a lot of familiarity
| nologic01 wrote:
| I think we need an impressive "made with htmx" example that will
| trail blaze an new class of web experiences.
|
| People have typecast htmx as something to use for simple use
| cases that dont "warrant" getting out the serious guns. There is
| something to that, but it is limiting. Htmx and related 'back-to-
| the-server' approaches are a distinct category that could have
| been explored much earlier but for various reasons isnt
| KodingKitty wrote:
| Another "Made with HTMX" example. E-shop frontend coded in HTMX
| and Hyperscript. https://www.makaron.cz/
| cyber_kinetist wrote:
| There was already a pretty good non-trivial real-world example
| where a company replaced their entire React site with htmx and
| got impressive results:
|
| https://htmx.org/essays/a-real-world-react-to-htmx-port/
| keb_ wrote:
| Where is the source?
| withinboredom wrote:
| There's literally a talk linked to in the essay.
| keb_ wrote:
| A link to a talk is not the same thing as source code.
| withinboredom wrote:
| Ah, I thought you meant "source" as in "news source" not
| "source code."
| keb_ wrote:
| Oh my mistake. I probably should have been clearer.
| dvtkrlbs wrote:
| I don't think it is open source they show some parts of
| their code in the talk but that is it.
| dartos wrote:
| > trailblaze a new class of apps
|
| I think you misunderstand HTMX. It's the revival of an old
| class of apps in a backend agnostic way. It's not doing
| anything new, or anything that warrants a "new class of apps."
| It's a way to build hypermedia (read: content) focused sites.
| Classic sites like shopping catalogs, forums, admin front ends,
| blogs, etc.
|
| It's just jquery/liveview/turbolinks, but backend agnostic and
| without needing you to maintain much (or any) frontend js
| logic.
|
| Once you need heavy interactivity (think google docs or figma)
| it stops providing much benefit.
| nologic01 wrote:
| Do you think we have exhausted the space of "hypermedia"
| apps? I dont think so.
| renerick wrote:
| https://zorro.management
|
| Not affiliated with them in any way, but it's made with htmx
| and some JS for more complex features
|
| As for "new class of web experiences", given that htmx
| explicitly aims to expand upon what is considered the Old Good
| approach, not sure if it can provide that
| tracker1 wrote:
| The problem with that is you need (one of many) server-side
| options to respond to the events... you could do a TodoMVC HTMX
| front end, but what would you use for the backend to work with
| it? Go, C#, Rust and a handful of others seem like pretty
| natural options, but as with all things, YMMV.
|
| I mention C# in that ASP.Net MVC + Razor seems like a very
| clean match to the HTMX paradigm.
| dhucerbin wrote:
| I was helping with an application that used htmx and had two
| issues. I'm wondering if anybody had similar experience and if
| these issues are from misusing technology or maybe there's some
| ongoing work to address them.
|
| 1. A lot of custom middleware in controllers to decide if
| endpoint should return HTML for whole page or only fragment that
| htmx needs. On the side of htmx that sounds simple but it is
| something that probably every project using htmx have to
| reinvent.
|
| 2. Bookkeeping around `hx-trigger`. If UI is getting complicated,
| many elements need to react to external changes. Instead of
| reading some state and hope that framework will schedule updates,
| I have to manage a list of events to react by hand.
|
| Anybody had similar impression?
| sriku wrote:
| Also https://hyperscript.org/docs/ - works together with htmx.
| varispeed wrote:
| Sorry to sound mean but, what is the point of this?
|
| I've gone to the home page it poorly explains what it is and
| doesn't say why would you want to use something like this.
|
| Seems like another distraction.
| sibit wrote:
| > poorly explains what it is
|
| Seems clear to me but I've been watching this project grow for
| a few years now. If you read the brief introduction,
| motivation, and quick start on the homepage what do you think
| the project does?
|
| > why would you want to use something like this
|
| I would agree that part wasn't clear to me either, at least not
| right away. When compared to something like a SPA the state has
| to persist on the server while an ephemeral state exists on the
| client. With HTMX the state only needs to exist on the server.
| If this sounds like the MPAs of yesteryear, it is. You render
| the HTML using the frameworks/tools/languages you fancy. HTMX
| provides custom attributes you can use to update content within
| a page without having to reload the entire page.
| varispeed wrote:
| > and quick start on the homepage what do you think the
| project does?
|
| It adds some special attributes to HTML that magically
| perform some logic and it is not clear how and why. Why would
| I use something like this over React? What this thing is
| trying to solve?
|
| > You render the HTML using the frameworks/tools/languages
| you fancy. HTMX provides custom attributes you can use to
| update content within a page without having to reload the
| entire page.
|
| I still can't see what's the point of it. Why would I want to
| do it?
| sibit wrote:
| > I still can't see what's the point of it. Why would I
| want to do it?
|
| It depends on how you like to build projects. If you like
| the current state of client-side rendering there is no
| point to using HTMX. If you like server-side rendering (my
| personal preference) then HTMX fills the gap of doing
| partial DOM updates without needing to reload the entire
| page. Some people will argue about perf metrics until
| they're blue in the face. I mostly rely on personal
| preferences.
| criddell wrote:
| > With HTMX the state only needs to exist on the server.
|
| Is this HATEOAS?
| sibit wrote:
| I believe so. At least this is my understanding of HATEOAS.
| basique wrote:
| Yeah. The author even has an essay about it:
| https://htmx.org/essays/hateoas/
| mekster wrote:
| Before people explore stuff that may not matter, I just don't
| understand why people don't just graduate writing raw HTML and
| write something like Pug which is like saving 30% typing that
| doesn't break or change your workflow.
|
| There's a stable implementation for PHP too.
| [deleted]
| martijn_himself wrote:
| Can anyone explain why Htmx is such a big deal? I really don't
| get their 'motivation' section on their landing page.
|
| I mean, for example, the first motivation it lists is 'Why should
| only <a> and <form> be able to make HTTP requests?', why is that
| an issue? And 'Why should you only be able to replace the entire
| screen?', I mean that hasn't been an issue since XMLHttpRequest
| or am I missing something?
| tracker1 wrote:
| HTMX is meant to relatively cleanly interact with updating
| portals on a rendered page. Where the serve-side handles the
| post data and simply returns the HTMX fragment that gets
| injected/replaced.
|
| I can see the appeal, it's what ASP.Net WebForms probably
| should have been. And for that matter could probably cleanly
| fit with ASP.Net MVC and Razor views.
| tempaway47811 wrote:
| Isn't this how jQuery worked about 10 years ago?
| recursivedoubts wrote:
| to an extent, there was `jQuery.get` but it wasn't tightly
| integrated with HTML
|
| the original version of htmx was intercooler.js:
|
| https://intercoolerjs.org
|
| released in 2013, and that version depended on jQuery
| aembleton wrote:
| How does HTMX work with Tailwind? If I return some HTML from my
| backend, then the Tailwind scanner won't have found the css
| selectors, so it won't be in the generated CSS.
|
| What am I missing?
| Capricorn2481 wrote:
| Tailwind does let you specify files other than HTML/css. I
| point mine at .cljs files. Can you point it to whatever files
| are generating your html?
| cwales95 wrote:
| Have tailwind scan your backend files as well or have a list of
| classes needed included in your tailwind config which should
| not be purged.
| AtNightWeCode wrote:
| Before I break my neck completely. Htmx is still JS? No?
| qbasic_forever wrote:
| Congrats. I will be very curious to see how this (and other
| companies that are built around an open source frontend/web
| library) work on monetizing themselves. Are there any successful
| businesses in that space?
|
| I worry it will be truly challenging without a big compromise to
| morals/openness/etc. I kind of wonder if stuff like htmx should
| just be funded with a big grant so it never needs to worry about
| selling out users for profits and operating income. Or at the
| very least that it learns to run extremely lean, to not chase
| expensive fads, and to build itself into something that can
| survive off a modest "please donate/buy some stickers/tshirts or
| my book" income stream. I hope we don't see the day that suddenly
| there's no download link on their site and it's replaced with a,
| "please contact our sales team for a demo!".
| kayo_20211030 wrote:
| This is great news. It's an unfortunate fact, but the validation
| of htmx simply by its inclusion in the GitHub OpenSource
| Accelerator may unstick some folks that were on the fence about
| its "legs"; not its utlity as such, but more about its safety for
| adoption. Nobody wants to be fired for selecting a library that
| may just go away. It's a very good library and it (and things
| like Turbo) are incredibly useful when developing canvases that
| slot into SFDC with the least amount of friction, allowing you to
| simplify interactions between SFDC and your back-end systems,
| where those systems themselves depend on SFDC data.
| duxup wrote:
| It's amusing to read all the "it's great to just write html"
| comments here, in a thread about some company going through a
| startup accelerator.
|
| Not that the comments are "wrong" but it feels slightly
| contradictory, in a way.
| adamckay wrote:
| It's not a company - it's an open source project.
|
| It's not a startup accelerator - it's a part of GitHub's
| efforts to support open source projects with funding and
| mentorship.
| jokoon wrote:
| Can somebody explain to me how I am supposed to use this?
| dontupvoteme wrote:
| I haven't written anything meant to be seen by the wider web
| since geocities/myspace and I don't know anything front end
| besides apache and PHP -- is this a return to roots?
|
| (I don't like javascript and i think making websites sentient was
| a mistake)
| jonny_eh wrote:
| A refreshing lists of startups, nothing related to HealthTech,
| Crypto, or AI.
| jray wrote:
| A question, has anyone managed to integrate htmx with select2 or
| tom-select? I'm trying to create a remote livesearch, but I can't
| achieve it.
| jdthedisciple wrote:
| HTMX the framework that sends a server request to put a textfield
| into edit mode?
|
| Nah sorry, not convinced.
| globalreset wrote:
| Htmx doesn't prevent anyone from using JS, and using a tiny bit
| of localized JS is explicitly encouraged.
| recursivedoubts wrote:
| relevant:
|
| https://htmx.org/essays/hypermedia-friendly-scripting/
| can3p wrote:
| Great news! I'm not using the full feature set (e.g. hyperscript)
| but really like the general approach as opposed to usual suspects
| like react or svelte. One of my last projects runs just fine on
| htmx + 3-4 stimulusjs controllers for all interactivity
| WeAddValue wrote:
| hyperscript is a separate project. It is not a feature of htmx.
| htmx handles the hypermedia interactions with the back-end
| server. For pure in-page interactivity (hiding/showing side-
| navs, etc), you get to decide how you want to do it: VanillaJS,
| AlpineJS (my favourite), hyperscript, Web Components (lit.dev,
| etc), StimulusJS (what you used), a big framework component
| (Svelte, Vue, React, ...), etc, etc. htmx does not bundle
| anything into itself to make that decision for you. You may
| have thought hyperscript is a feature of htmx because sometimes
| you'll see the two used in examples (both have the same
| creator).
| rs_rs_rs_rs_rs wrote:
| It's time to bring jquery back in the limelight.
| hliyan wrote:
| document.querySelector(x).[addEventListener|innerHTML|... etc.]
| is usually enough for most use cases. You can alias it to $()
| and .on() if it looks verbose.
| dchuk wrote:
| So who is using this/hotwire/unpoly and something like capacitor
| or maybe react native wrapper or turbo-iOS to make "native"
| mobile apps that are mostly just web apps? Any good war/success
| stories?
|
| I have to assume that just like most web apps don't need
| aggressive SPA front ends, many mobile apps fall in the same
| boat...
| rglover wrote:
| I don't want to bag on Htmx but if you're looking to just use
| vanilla HTML (seriously, no extra/custom attributes or weird
| syntax gotchas), please check out Joystick [1]. UI framework
| that's part of a full-stack framework that uses vanilla HTML,
| CSS, and JavaScript for building components.
|
| [1] https://github.com/cheatcode/joystick
| justmedep wrote:
| After reading the linked website for like 2 hours I still can't
| tell if this is a joke or for real...
| elliottinvent wrote:
| Wait til you see the Twitter account:
|
| https://twitter.com/htmx_org
| recursivedoubts wrote:
| false dichotomy detected
| simonw wrote:
| Which part of it seems like a joke?
| als0 wrote:
| Shouldn't HTMX be a W3C proposal?
| nprateem wrote:
| This page made me realise I'm better off with just vanilla JS or
| jQuery: https://htmx.org/examples/update-other-content/
|
| Solution 3 gave me a good laugh though.
| [deleted]
| sourcecodeplz wrote:
| Not to mention there is no mention of error handling.
| basique wrote:
| You just return an HTML fragment that describes the error
| with a header that says where to put it. The htmx JS API has
| events for errors too, if you want to do client-side
| handling.
| EspressoGPT wrote:
| Why the heck would you use jQuery in 2023 though?
| nprateem wrote:
| My main use case will be basic UI interaction, mostly just
| posting or fetching data from a backend then updating the
| innerHTML on some element. Vanilla might be enough, but I'm
| keeping my options open.
|
| Also, no compilation step, so no need for npm, etc
| maxboone wrote:
| IMO that's where alpine.js complements HTMX, you can use
| HTMX mainly for interfacing with a server and then use
| alpine.js for any special interaction that does not require
| a round-trip with the server.
| bardak wrote:
| That's my thought as well. Anything that needs new data
| from the server uses HTMX and if you need to manipulate
| something already on the page use Alpine, Jquery,
| vanillajs, or whatever other framework you prefer.
| rodorgas wrote:
| JQuery would make sense when we didn't have querySelector
| and fetch API. I can't think of any reason to use it today
| on a new project, there are not advantages over vanilla.
| synergy20 wrote:
| jQuery's syntax is 10x better than vanilla javascript
| antiatheist wrote:
| Bullshit, the jQuery "Ajax" API is a hellish convoluted
| nightmare with zero consistency.
|
| https://api.jquery.com/category/ajax/
|
| Have you seriously looked at this and thought "yeah thats
| better than using a single native function (fetch)"?
|
| As for the rest of the API - what would you even use
| besides the css and selector functions? Which again, the
| native `classList` and a simple bind to the selectors are
| simpler and less verbose.
| mejutoco wrote:
| Jquery does not solve everything, but it does have a nice
| api $(this).closest(".cont")
|
| for example, is pretty nice in jquery.
| tambourine_man wrote:
| The native API is much more verbose and less composable.
| It was a real lost opportunity.
| antiatheist wrote:
| const $ = document.querySelector.bind(document)
| const $$ = document.querySelectorAll.bind(document)
| tambourine_man wrote:
| Oh, I wish it was that simple.
| EspressoGPT wrote:
| I'd strongly suggest using something like ArrowJS instead
| of jQuery for that.
| tambourine_man wrote:
| Because it's much cleaner, readable code than anything
| created since.
| varispeed wrote:
| It's a boring and battle proven tool that just works and has
| no use by date, by the way.
| EspressoGPT wrote:
| It has. The issue jQuery was designed to solve doesn't
| exist anymore, hence there's no reason to rely on this
| heavy and convoluted library any longer. There really are
| better solutions.
| varispeed wrote:
| What do you mean the issue doesn't exist?
| guggle wrote:
| > "I need to update other content on the screen. How do I do
| this?"
|
| This is a complete non-issue in unpoly as you can have multiple
| targets: <a href="/posts/5" up-
| target=".content, .unread-count">Read post</a>
|
| https://unpoly.com/targeting-fragments
|
| HTMX gets a lot of attention, but I think it's not the best
| option in its field.
| mordae wrote:
| And also up-hungry to opportunistically update navigation and
| cart item count. :-)
| nprateem wrote:
| That's what I was expecting to see, a way of specifying a
| target. Certainly not returning custom headers for the
| benefit of such a 'simple' frontend library.
| foooorsyth wrote:
| Solution 2 is clearly the best option. htmx authors would be
| wise to get opinionated and champion that approach. Forget
| about IE11 compat. Completely rearranging the DOM (Sol. 1) and
| a two request chain for one update (Sol. 3) are non-starters
| treis wrote:
| This page illustrates why I just don't get HTMX. It seems like
| a ton of effort to save not a lot of server cycles and html
| over the wire.
|
| I've done tabbed UIs that worked like HTMX. But instead of
| trying to do div surgery it replaced the entire tab. It was
| like 20 lines of JS and a few lines in Rails to render without
| a layout based on a URL query param.
|
| When we're talking dozens of KBs of HTML for a tab it's not the
| extra complexity to try and slim that down.
| mejutoco wrote:
| Htmx advantage is not that it sends less bytes, but that it
| effectively removes frontend. Getting rid of the frontend
| dependencies, builds systems, and languages can bring a lot
| of speed to a project.
|
| Of course the downside is everything must go to the server.
| While not perfect, many spa also do not work nicely without a
| connection, although they could.
|
| Another thing is that the templates can get a bit crazy
| quick.
|
| I found a good solution is to use swap-oop
| (https://htmx.org/attributes/hx-swap-oob/) for everything and
| have a "component" wrapper server-side to abstract the ids
| and which template to choose.
|
| Then, some kind of typed data structure tracking all the
| element ids, since you need to refer to them from the
| templates to know which element to update. This way you can
| easily find all the templates that update a specific id or
| all the ids that are updated by a template.
| treis wrote:
| >Htmx advantage is not that it sends less bytes, but that
| it effectively removes frontend.
|
| Right, which you can achieve by replacing the main content
| div. HTMX takes it many steps further and allows you to
| slice the HTML up into small bits and replace only those.
| This adds a lot of complexity for little benefit.
| wslh wrote:
| Sidetopic: is there anything similar to GitHub Accelerator but
| for companies instead of individual developers?
| jjkeddo199 wrote:
| For first-time-devs, configuring + understandings development
| environments is usually 10 times more daunting than "learning to
| code". With respect to Typescript, NPM, Webpack, React,
| transpiling, sourcemaps, broken IDE probably makes webdevnewbies
| quit before actual code syntax.
|
| In my dream world, HTMX could become part of the HTML6 spec, and
| beginners could spend more time dipping their toes in the water
| testing their .html files in Chrome before they face getting
| gobsmacked by the greater JS ecosystem.
| [deleted]
___________________________________________________________________
(page generated 2023-08-16 23:00 UTC)