[HN Gopher] Hotwire: HTML Over The Wire
___________________________________________________________________
Hotwire: HTML Over The Wire
Author : bpierre
Score : 138 points
Date : 2024-06-02 15:55 UTC (7 hours ago)
(HTM) web link (hotwired.dev)
(TXT) w3m dump (hotwired.dev)
| Zambyte wrote:
| Very cool. It's interesting to see REST become REST again. Also
| cool to see this come from 37signals. I use Basecamp for a
| makerspace that I am a part of, and it works quite well for our
| needs.
| agumonkey wrote:
| There was some news about phoenix, which seems to use similar
| approach. More on the backend, direct computed view elements sent
| over websockets.
| cpursley wrote:
| LiveView is the OG of this approach:
|
| https://phoenixframework.org/blog/phoenix-liveview-1.0-relea...
| reducesuffering wrote:
| It's insane to me we simultaneously have LiveView, LiveWire,
| and HotWire, all referring to somewhat similar but different
| frontends... I guess that's really LiveWire's fault for most
| recently combining those names, otherwise the other two would
| be distinct.
| ReverseCold wrote:
| So I guess if you're looking to start a new frontend
| framework with the same principal, name it HotView?
| chuckadams wrote:
| I recall Java Server Faces had something similar long before.
| But the JSF architecture was so twisty that it wasn't ever
| that practical.
| cientifico wrote:
| Phoenix live view is awesome. If you use Phoenix that's the way
| to go. If you don't want to go to the erlangvm, htmx or
| hotwire/turbo are the only options I would consider.
| cientifico wrote:
| This is by far the easiest way to do PWA without getting into the
| rabbit hole of react/Vue/svelte. I used them, and are awesome,
| don't misunderstand me.
|
| While comparing with htmx it feels more developer focus than tech
| focus, but I believe the race between the two will depend on
| which one is integrated with your backend framework.
| scosman wrote:
| What makes this less of a rabbit hole than the alternatives you
| mention?
| cientifico wrote:
| If you have discipline, probably none.
|
| The difference is developer behavior that each framework
| encourages.
|
| While htmx/turbo focus in just couple of helpers and then
| leave you with the full HTML/JS, in a react ecosystem you end
| having with 3 party components, and a state management system
| and build system that will change in 10 months. I don't say
| it isn't justify and that it have its pros, but it's a rabbit
| hole in my experience, where you easily end fighting with the
| framework than focusing on business.
| nosefurhairdo wrote:
| Huh, there hasn't been a significant change to our build
| system for our React application in the last ~5 years. Same
| is true for state management (redux). Our users include
| half of fortune 100 companies.
|
| Really don't understand the argument that React apps must
| be rewritten all the time. Most of our code is still old
| class components that still work in the latest version of
| React.
| CodeWriter23 wrote:
| I can't speak to React. But with Vue it's been like this.
| Vue 3 we're not deprecating the Options API. And we're
| not recommending the Composition API. But if you read
| into that you can mix and match the two, any pain you
| experience in the corner cases where they don't play
| nice, well, that's on you. All of your Vue 2 components
| might work but not really. Also the Vue 3 versions might
| happen. We're switching from WebPack to Vite as the build
| system. (Does Vite actually use WebPack as a component, a
| question that lingers in the back of my mind) Oh and now
| the "CJS build" of Vite is deprecated so you'll need to
| go from TypeScript 4 to 5. Your IDE may or may not work
| with the new Vue-specific tslint infra and when you're
| done sussing that out now you find code that worked just
| fine in your previous build is rejected when you do a npm
| run build (no longer prod btw).
|
| Can you imagine needing to fix a bug requiring a
| dependency (upon dependency and so on and so on and so
| on) update on code you haven't touched for a year and
| suddenly having a herd of Yak like that need shaving?
| nosefurhairdo wrote:
| Vite uses esbuild for fast dev builds and Rollup for
| production bundling, not webpack. Once the Rust port of
| Rollup is ready (called Rolldown) it is likely Vite will
| migrate both dev and prod bundling to that.
|
| Re: Typescript 4 => 5 that should be a trivial migration.
| All we needed was to bump our node version IIRC.
|
| And yes I can imagine the sort of bug you describe,
| because I'm the guy who fixes these sorts of things on my
| team. Usually just a few hours of head banging once or
| twice a year. Though the apps I've built on Vite have
| never required this. Really cannot recommend Vite highly
| enough for web frontend tooling.
| CodeWriter23 wrote:
| Yes getting the JavaScript community to just STFU when it
| comes to revising for the sake of revising is an entirely
| different issue. Some day they will have to maintain
| something they haven't touched in 5 years and then they
| will learn. Well, some of them.
| mardifoufs wrote:
| Lol react has been more stable than rails.
| CodeWriter23 wrote:
| Maybe if one's mobile apps are just a WebView. Otherwise you're
| maintaining a REST API for the mobile apps and the
| Hotwire/Livewire request handlers that deliver html fragments.
|
| IMO PWA is a client issue and should be handled client side
| without introducing server dependencies.
| cientifico wrote:
| For sure, there are cases in which a PWA focus is to add
| offline support, and you are totally right there.
|
| However, I will argue that 80% of PWA exist to have proper
| push notifications, or faster development than native.
| whartung wrote:
| How does this contrast to htmx?
| one-punch wrote:
| Hotwire integrates with Ruby on Rails. (EDIT: The linked page
| shows how to integrate Hotwire with Ruby on Rails. See fxn's
| comment https://news.ycombinator.com/item?id=40555577)
|
| I had the same question, then watched the video to get the
| answer.
| fxn wrote:
| No, Hotwire is framework agnostic it is web components and
| JavaScript, basically.
|
| You can Google Hotwire with Django, or Laravel, or many
| others (https://hotwire.io/frameworks).
| one-punch wrote:
| Thanks for the information.
|
| The linked page shows only integrating Hotwire with Ruby on
| Rails, giving me my original impression.
| fxn wrote:
| Some links do not have information yet, others do, for
| example https://hotwire.io/frameworks/laravel or
| https://hotwire.io/frameworks/django.
| nacs wrote:
| > framework agnostic
|
| Framework agnostic but Ruby-only it seems.
| fxn wrote:
| No.
| freen wrote:
| No. Turbo is js and HTML.
|
| If your backend can send templates down the websocket,
| you can use Hotwire.
| andrei_says_ wrote:
| Hotwire is in JS and is used by multiple back-end
| frameworks including Rails.
|
| Rails has a lot of affordances for Hotwire and is the
| back end framework for which Hotwire was originally
| written.
| felipemesquita wrote:
| Hotwire is the umbrella term for turbo, stimulus and strada.
| Turbo has client and server side components that enable easy
| ways to do partial page refreshes and send html templates
| (turbo streams) to initiate page updates from the server.
| That's all without writing any js (using mostly data attributes
| and custom html tags, like turbo-frame). Stimulus comes in as a
| small framework for the cases where you want to write some
| JavaScript, in a way that you still control the behavior from
| html, by attaching controllers to elements explicitly. These
| two aspects are similar to htmx: - send html from the server
| even for partial page updates - encode desired js behavior into
| the html The main difference is that turbo is designed with a
| convention over configuration attitude, as many of it's
| behaviors are automatic (like intercepting all form submissions
| and handling them using fetch, preventing a full page reload).
| When custom js is needed Hotwire defers to letting you write
| actual js code, htmx has this tailwind style shorthand that
| allows you to basically write js from the html.
| andrei_says_ wrote:
| I'd add - stimulusjs lets you write your own htmx-like
| functionality by providing a convention for triggering and
| passing data to js via html data attributes.
|
| The stimulus JavaScript controllers (not to be mistaken with
| the Rails mvc controllers) are reusable and nest-able which
| makes them very powerful and quite fun to write.
| eduction wrote:
| I thought "HTML over the wire" was literally what the web has
| always been about from the very start.
|
| Even if you redefine "the wire" to "XHR requests" or "Ajax
| requests" it's still weird to treat this as a revolutionary thing
| since the "X" in XHR and Ajax is "XML" which is just a sibling
| markup language to HTML.
|
| Also, IIRC the original Rails approach to Ajax like 15 years ago
| or so was sending page partials like this.
|
| It feels like we're going in circles.
|
| (I've also never been impressed with their "turbo links" which
| just seem like "we think we can do caching better than the
| browser makers" and thus dubious. Core Rails seems great but I'm
| always wary of this stuff at the edges with the extra dollop of
| hype.)
| nilamo wrote:
| Most dynamic websites do not pass html for updates, the
| communicate with a backend using json (normally) and the
| frontend figures out what to do with that data. Hotwire is
| about removing that JavaScript layer, to have a dynamic app
| without a heavy UI framework.
| eduction wrote:
| Yes obviously. It wouldn't have made sense to say "we are
| going in circles" otherwise!
| leviathan wrote:
| We've come almost full circle. I remember using this approach
| back in 2005 or 2006 by intercepting clicks and appending a
| parameter that just returned rendered html partials that just
| .innerHTML replace the main contents.
| ggeorgovassilis wrote:
| I'm doing something similar with [1] where pagination (scroll
| down, click on "Show more") is implemented by requesting the
| next page as an HTML fragment from the server, loading it into
| an invisible iframe and once it finished loading, appending it
| to the current page.
|
| [1] https://animasci.com/
| Terretta wrote:
| We used to let people browse and page through photo galleries
| by preloading the next columns or rows of photos, then on
| click URL swapping under the static HTML page grid. The order
| you replace the URLs gives a visual of a paging motion.
|
| And for infinite pages, a long forgotten technique: for
| scrolling or continuing content, you could use "multipart"
| since the 90s, effectively streaming the additional page
| content to the user as you got more bytes to send them.
| NelsonMinar wrote:
| Sometime in the early 2000s, before AJAX was a thing, Adam
| Rifkin showed me a demo from his startup KnowNow that was
| achieving the then-mind-blowing thing of a web page updating
| itself without refreshing. Their trick was to keep the HTTP
| request open and the server to send occasional updates. More
| HTML. I don't think they could even manipulate the DOM back
| then, it may literally have been a page that just never closed
| the <html> tag.
| eurleif wrote:
| Well, you could manipulate the DOM with that technique by
| sending <script> tags to do so.
| skeeter2020 wrote:
| Internet Explorer 5 introduced XMLHttpRequest (ActiveXObject)
| in 2001.
| eurleif wrote:
| Yes, but developers weren't widely aware of its power until
| the launch of Gmail in 2004, and the term "AJAX" wasn't
| used until 2005.
| deaddodo wrote:
| People were definitely experimenting with it before that.
| Developers were mostly using it to load direct server-
| side snippets of HTML, dynamically. It took the evolution
| of SOAP and (especially) JSON/RESTful APIs for it to
| start seeing mass adoption as the combined technology of
| "AJAX".
|
| Prototype.js and jQuery had a big hand in the latter.
| basch wrote:
| what made Gmail memorable was cross browser ajax. Prior
| to, you had things like OWA but it only worked right in
| IE.
|
| The big inbetween OWA and Gmail, was Oddpost, which was
| also IE only, and was purchased by Yahoo three months
| after gmails April Fool announcement, to become Yahoo
| Mail. In a roundabout way, you can argue gmail was a copy
| of what was eventually Yahoo Mail.
| leviathan wrote:
| It was fairly easy to communicate between frames with
| JavaScript, so before this was widely adopted, I remember
| the way we used to "fetch" new data was with an iframe that
| always had a meta refresh tag in it, and the server
| response would include JavaScript that would call into
| functions from the main window passing along any data that
| was needed.
|
| I might be wrong, but I think even early versions of Gmail
| did something similar.
| mbreese wrote:
| I did something similar (same time frame) that definitely
| manipulated the DOM, but I didn't keep the HTTP connection
| open, I used hidden Iframes. Clicks got redirected to the
| iframe, which returned <script> elements that would replace
| DOM elements (in the parent frame) using their .innerHTML.
|
| AJAX streamlined the process, but there were a lot of hacky
| ways to get similar dynamic HTML effects. I like the idea of
| keeping the HTTP connection open, but that seems quite
| resource intensive... particularly for the early 2000s.
| nosefurhairdo wrote:
| Rather than come full circle, I think it's more accurate to say
| that the different web UI paradigms are expanding their scope.
| Server rendered frameworks are making it easier to do client
| interactivity, and React is making it easier to do server
| rendering (via RSCs).
|
| For highly interactive web apps you would still benefit from a
| SPA since that's what they're designed for.
| gedy wrote:
| Yeah I was really into Wicket in late 2000s and while I
| personally liked it and hated JS, managing UI state and
| templates on the server was always kind of a foot gun for
| performance and scale in a team environment. Really hard for me
| to be excited about this approach again, especially after all
| the improvements to web, JS, and TypeScript in meantime.
| giancarlostoro wrote:
| I feel like everytime Hotwire and similar libraries get posted
| we hear this, but the reality is simple CRUD w/ AJAX never went
| away... Sure theres loads of SPA projects out there but that
| doesnt account for every single website ever.
| felipemesquita wrote:
| I haven't worked with web apps that need highly interactive
| frontends, but for our e-commerce stores and internal rails apps
| turbo and stimulus have really lowered the bar on how much new
| developers must learn to build a nice to use website.
| renegade-otter wrote:
| If you keep your stack simple, it's never been THAT hard. For
| example, with one Django project, I spun up whole office-facing
| tools using the tried and true KnockoutJS - which is kind of in
| the spirit of HTMX (and so is the still nascent Arrow.JS).
|
| Most of the complexity, especially the UI part, has been self-
| inflicted. The old ways are very much not outdated, and are
| actually coming back.
|
| There is a whole young generation of devs who came into the job
| at the stupidest possible time, when the industry convinced
| them that every web application has to be an overcomplicated,
| insufferable mess.
| bityard wrote:
| It looks like the only way to get a sense for what this does and
| how it works is to watch videos? If so, blegh.
|
| Surprised something like this wouldn't have any example code or
| demos to look at.
| devjab wrote:
| It does once you dig a little into the documentation, you need
| to click past the first two pages of self-flattering and you'll
| see that it's mostly just going back to writing old world
| JavaScript.
|
| It's really very disappointing.
| gedy wrote:
| Yeah your comment ironically points out the issue (at least I
| have) with this - you are maintaining state on a server, and so
| messing with a UI isn't just dealing with local UI state.
|
| I'm no JavaScript fanboy, but I'm also not bent on avoiding it
| at all costs _shrug_.
| danlugo92 wrote:
| It's html over a websocket. What is there to understand?
| Zambyte wrote:
| I passed the video to GPT4o through Kagi and then asked "What
| is Hotwire and how does it work?" and got a satisfactory write-
| up. I can email it to you if you'd like (I think posting LLM
| generated text here is frowned upon).
| tholman wrote:
| Here's the HN conversation from 2020 [1], a little closer to when
| this came out.
|
| - [1] https://news.ycombinator.com/item?id=25507942
| dang wrote:
| Thanks! Macroexpanded:
|
| _Hotwire: HTML over the Wire_ -
| https://news.ycombinator.com/item?id=25507942 - Dec 2020 (545
| comments)
|
| Also related:
|
| _Why Hotwire Could be the Future of Front-end Dev_ -
| https://news.ycombinator.com/item?id=26195969 - Feb 2021 (6
| comments)
|
| _Hotwire: A new old way to build web apps_ -
| https://news.ycombinator.com/item?id=25942864 - Jan 2021 (56
| comments)
| gkoberger wrote:
| For anyone curious why this is popping up now:
|
| Last week, someone posted online how Hey (created by DHH, who
| also created Hotwire and Rails) is slow when opening a modal:
| https://x.com/noahflk/status/1795758603577545035
|
| It created a bunch of heated conversation (DHH saying the
| original video was throttled, other people saying Hotwire is too
| reliant on the network if a modal needs time to load, people
| defending Rails/Hotwire, people disagreeing with its approach,
| etc...).
|
| Basically, it's been a big topic on Twitter the past week.
| dewey wrote:
| Direct link to DHH's response:
| https://x.com/dhh/status/1796163806650868149
| mardifoufs wrote:
| For context, people have been able to reproduce this with
| gigabit connections too.
| ChrisArchitect wrote:
| Thx for context!
| retrac98 wrote:
| Great library that's let down by its documentation. It's very
| hard to figure out how to do things in Hotwire without a YouTube
| tutorial.
| navs wrote:
| Theo dug into Hey and Hotwire only a day ago and has a less than
| flattering take. Not on the concept necessarily but some
| implementations.
|
| https://m.youtube.com/watch?v=5jIwILYjXrU
| DoesntMatter22 wrote:
| I think that has more to do with the fact that he is paid for
| by Vercel than anything. He's mostly been saying negative
| things about Rails despite not understanding how it works.
| NorwegianDude wrote:
| I agree that that calendar doesn't seem great, and the problems
| do exist. However, adding tons of latency while saying you're
| not doing so in order to make fun of someone's work is either
| malicious or extreme lack of competence.
|
| In the video he sets the chrome throttle option to slow 3G, and
| that adds large restrictions on bandwidth, and a ton of
| latency. He states that he is not doing so, and that adding
| latency can't be done in the browser. That is literally what
| the option does.
|
| If you add seconds of latency then requests will take seconds,
| who would imagine...
| gjsman-1000 wrote:
| To me,
|
| A. The complaint about how every keypress goes to the server
| says literally nothing about HTML over the wire. It's obviously
| how Hey chose to do things (or it was a bug), but Theo should
| be experienced enough to know that most approaches don't need
| to be like this. Attributing a sloppy implementation by Hey
| onto a video about Rails as a whole is inflammatory.
|
| B. And if he isn't, and doesn't realize that HTML over the wire
| doesn't mean you can't have any JavaScript, he should stop
| talking about what he does not understand.
|
| C. This is personal taste, but a man with his hair style shows
| he can't recognize good taste if it hit him in the face.
| CodeWriter23 wrote:
| I don't think you're intimately familiar with the concept of
| maintaining state server side vs client side. The field is
| reactive, therefore under Hotwire/Livewire/etx state changes
| (aka 'typing on keyboard') require a round trip to the server
| to get the state updated server side and to get the re-
| rendered component to update the client. Could he perhaps
| have chosen a different reactivity model, perhaps, or maybe
| not. In any event this is a clear illustration of client-side
| vs. server-side reactivity.
|
| This is why we abandoned DHTML 2 decades ago, invested in
| jQuery to encapsulate variations in JavaScript across
| browsers and worked hard on standardizing JS so you could
| write code once and have it work across vendors.
| gingerlime wrote:
| It's entertaining and he points to some bugs like race
| conditions that shouldn't be there, but I'm not sure if it's
| specific to Hoywire. Also his statement that DHH/Rails claim
| Hotwire is the _only_ way, or that you cannot also use React or
| plain JS is just silly and disingenuous.
| CodeWriter23 wrote:
| This should be the top comment. Unfortunately you've got the
| 37Bury Brigade out here in force. Mind your thoughts is their
| message.
| DandyDev wrote:
| Read the other comments. The video creator is literally
| adding artificial latency and then complaining about bad
| performance.
| gherkinnn wrote:
| Why does everything Theo touch go up in a flaming shitshow? DHH
| can be an inflammatory prick himself, but he just about
| balances it with competence.
|
| I hate how there are JS influencers now. And I hate how they
| repeatedly cause drama for clicks. There will be a fresh
| idiotic topic bubbling up every few weeks. It will be
| semicolons soon, I am sure of it. I hate it.
| start123 wrote:
| Is it me or does it look like JSP/ASP all over again?
| koolala wrote:
| Can we rip down all the "Don't use Eval() in a web browser"
| warning signs from 30 years ago yet? F of X FFS
| lxgr wrote:
| This isn't using eval() in a browser, this is /cgi-bin/ :)
| koolala wrote:
| wait, is that a directory of dynamically loadable web content
| thats interactive i can surf? please i do not know the old
| ways, i only know they were forgotten :(
| danlugo92 wrote:
| This is the future
| chuckadams wrote:
| I used to be really negative on Hotwire/Livewire but I now
| realize it's a horses-for-courses kind of thing. Sending partials
| over the wire is a hypermedia thing, and I just don't write
| hypermedia apps nowadays. It was htmx and re-reading RTF's REST
| paper that got me to this place: I still don't think hypermedia
| is inherently the superior architecture, but it is a legit peer
| among several, and it's nice to see it keep evolving, even if
| slowly.
| BillFranklin wrote:
| I've been using Hotwire for a greenfield project for the last
| year. The hotwire framework they've created is pretty nice but I
| miss React and will probably choose it for my next project.
|
| Not just because it's decoupled from the backend api. The
| React/Vue ecosystems have a lot more useful open source
| components, and you can build faster, more cache friendly front
| ends, among other benefits.
|
| I agree React is more complex, but as with many things if you are
| gonna need it then it's great to have started with it.
| buf wrote:
| Like what?
|
| I also use Hotwire/Stimulus and haven't run into any issues
| yet. Happy to share links with you on anything I know about.
| BillFranklin wrote:
| > Like what?
|
| Not sure what this is in response to, sorry.
|
| I appreciate there are projects which will hit no limits with
| the Hotwire/stimulus/turbo mix. I've worked on them before
| and would choose Hotwire when appropriate (eg for government
| services Hotwire is perfect).
|
| The SSR vs CSR debate is quite tired and played out at this
| point, and doesn't lend itself to thoughtful threads... While
| hotwire does make it easier to do SSR with progressive
| enhancement, for some projects it's easier for me to just
| build a single "enhanced" experience with React (for
| performance, ecosystem, and IME UX).
| chrisvenum wrote:
| For those looking for something similar in PHP/Laravel, I
| strongly recommend checking out Livewire: https://laravel-
| livewire.com/
|
| I still use React for more complex projects but it's always a
| breath of fresh air to be able to write everything in Blade/PHP
| while keeping the reactive UI elements.
|
| Edit: Although I have not used, I remember seeing this package
| which lets you render React/Vue components within Livewire when
| you need it: https://minglejs.unitedbycode.com/ an interesting
| escape hatch for when you want to pull in existing packages
| mosselman wrote:
| Turbo's morphing is insane. With 2 lines of code: 1 in the model
| and 1 in the view, you can make any previously static page an
| instant updating multiplayer experience.
| 65 wrote:
| I've used Hotwire for a few sites. I much prefer it to HTMX since
| it's significantly easier to implement.
|
| My No-React tech stack is Alpine.js, Hotwire, EJS, and Express.
| Works very nicely for simpler sites.
|
| Though for the majority of the sites I make, React wins almost
| every time since it's way easier to use as a templating and
| interactivity engine. And Tailwind works a lot better with React.
| carom wrote:
| A way less marketed version of this is htmx [1]. It is a single
| javascript file that enables this functionality. I mostly see
| people using it with Go backends but I think it is flexible. I
| have been meaning to try it out for a year or so.
|
| 1. https://htmx.org/
| DoesntMatter22 wrote:
| HTMX probably has the best marketing of any framework. The
| twitter is very active, it's all over The Primeageon's youtube
| channel. It's quite popular.
| lolinder wrote:
| At least as far as Hacker News is concerned, I'd call htmx _way
| more_ marketed. It has hundreds of HN submissions in the past
| year alone [0] including one that broke 1000 points. Compare
| that to Hotwire which is sitting at less than 30 submissions in
| the past year [1], the most popular of which is this one.
|
| [0]
| https://hn.algolia.com/?dateRange=pastYear&prefix=true&query...
|
| [1]
| https://hn.algolia.com/?dateRange=pastYear&prefix=true&query...
| carom wrote:
| I guess it is that HTMX just feels like one guy's side
| project. Granted he is great at posting. TFA feels like 37
| Signals took the same idea and is trying really hard to sell
| it.
| artur_roszczyk wrote:
| Live views in Phoenix were way before both.
| lolinder wrote:
| But not before Intercooler.js (the predecessor to HTMX)
| or Turbolinks (the predecessor to Hotwire). This is an
| idea that has been developing for as long as the web
| itself, I don't think it's important to assign
| inventorship of the concept as a whole to any one
| project. They've all been learning from each other and
| innovating in their own ways.
| basch wrote:
| Meteor, Ember, Derby were the "next big thing" 10 years
| ago.
|
| Principles of Rich Web Applications (rauchg.com) Nov 4,
| 2014 https://news.ycombinator.com/item?id=8559519
|
| https://www.infoworld.com/article/2612250/application-
| develo...
|
| https://shiggyenterprises.wordpress.com/2013/03/11/pickin
| g-a...
|
| https://blog.emberjs.com/inside-fastboot-the-road-to-
| server-...
|
| It's not just that the idea has been developed over and
| over, but it is constantly hyped as a return to the
| golden past, and yet never gets the love that new client
| side spa messes end up attracting.
| ranger_danger wrote:
| I'm curious as to what people think is the appropriate amount
| of time to wait before reposting the same story.
|
| I know people complain about any and all reposts in the first
| place (https://xkcd.com/1053), but obviously there should be
| a priority on teaching people things they didn't already know
| instead of punishing people that never read old news.
| lolinder wrote:
| You may have noted this from my links, but just in case--
| when I say the htmx has a lot of submissions I'm not
| referring to duplicate submissions, I'm referring to dozens
| of different submissions of different projects using or
| adjacent to htmx.
|
| Re: the meta question, dang's policy that he repeats a lot
| is that reposts are fine every year or so [0]. Individuals
| may obviously disagree, but that's the rule that's actually
| enforced.
|
| [0] https://news.ycombinator.com/item?id=40523838
| benhurmarcel wrote:
| Personally I also find value in those posts even if knew
| about those technologies before. I often find interesting
| and up-to-date information or opinions in the comments.
| creativenolo wrote:
| In fairness to the commenter, I don't know either of the
| projects but htmx's _page_ is way less marketing focused that
| hotwire's page. The hotwire page's marketing is crazy:
| 'turbo', 'stimulus', 'strada'... Crazy but yet commendable.
| wicz wrote:
| Also worth mentioning https://unpoly.com which packs other
| features.
| MrOxiMoron wrote:
| the Django community is pretty vocal about htmx too (in a good
| way)
| andrewstuart wrote:
| Less marketed? I'm flooded with htmx on every social platform.
| taberiand wrote:
| Grassroots evangelism != marketing
| Fire-Dragon-DoL wrote:
| I researched it yesterday and there are differences, htmx is a
| lot lower level, hotwire cover only some narrow usecases but
| from a high level, and finally unpoly is highlevel with a lot
| of usecases coverage
| ChrisArchitect wrote:
| Been some developments since 2020, this isn't new.
|
| Context for why this might be coming up now:
|
| https://news.ycombinator.com/item?id=40555541
| jrs235 wrote:
| Glad to see this is getting attention again. But for those that
| don't know, this is several years old. See
| https://news.ycombinator.com/item?id=25507942
| fofo44 wrote:
| all my 6 websites are using Hotwaire framework. and I love it
| llmblockchain wrote:
| For what it's worth, Hotwire isn't very interesting. The real
| magic is in Turbo or Turbolinks (the pre-Turbo version of Turbo).
|
| Turbolinks is the HTMX-Boost before HTMX was HTMX.
| josephernest wrote:
| With the same idea but more minimalistic, I have done Swap JS two
| years ago :
|
| https://github.com/josephernest/Swap
|
| Used it for a few projects it works well !
| gardenhedge wrote:
| I must be missing something but React seems more straight-forward
| than this.
| focom wrote:
| You should look at django-unicorn for the python equivalent
___________________________________________________________________
(page generated 2024-06-02 23:00 UTC)