No, it’s not
Htmx Is the Future
471–480 of 875 posts
Re: Htmx Is the Future
#472Earlier quoted context omitted.
> "DO NOT USE YOUR BROWSER BACK BUTTON"? Yeah, state mutation triggered by GET requests is going to make for a bad time, SPA or MPA. Fortunately enough of the web application world picked up enough of the concepts behind REST (which is at the heart of all web interaction, not just APIs) by the mid/late 00s that this already-rare problem became vanishingly rare well before SPAs became cancerous. > going back to change…
> It's not only EVER done, it's regularly done. Perhaps you should interrogate some of the reasons why. Content in the app is reloaded, sure, but the actual layout and business logic? Code that generally changes almost never, regenerated on every page load? I know of technologies that are basically web wrappers that allow for doing that to bypass app store review processes, but I'd be pissed if an alarm clock app dec…
> here is an application (your browser), fetch whatever data you need (html) from whatever sources you need (my web server)
Parentheticals added.
Re: Htmx Is the Future
#473I don't like XML syntax.
Re: Htmx Is the Future
#474Earlier quoted context omitted.
Generally you don’t want to reuse the same API for different types of clients, you want backends for frontends (BFF) that are specialized for each use and can be moved forward in their own pace. The needs and the requirements differs a lot between a browser, app and server-to-server call. And just because you serve HTML doesn’t necessary mean that you backend code is tightly coupled with the view code, HTML is just o…
> you want backends for frontends (BFF) that are specialized for each use third time I've heard this thing and the reasoning still escapes me. First there's ownership. Backend team owns API. Frontend teams own clients (web/android/ios/cli) etc. Do you now have a BFF for each client type? Who owns it then ? Don't you now need more fullstacks ? there's confusion. Now you have 2 sets of contracts (API-BFF, BFF-clientIOS…
(not the op so this is jme...)
> Do you now have a BFF for each client type? Who owns it then ? Don't you now need more fullstacks ?
> there's confusion. Now you have 2 sets of contracts (API-BFF, BFF-clientIOS, BFF-clientAndroid, ...). You now have more human synchronization overhead. Changes take longer to percolate throughout. More scope for inconsistencies.
> Isn't is better to have the API team own the single source of ownership ?but... ideally this separation of ownership (backend backend, front end for backend) allows each to focus on the domain better without mixing up say localization in the lower level api's et
iow having a bff is sort of like having the view model as a server... that way multiple clients can be dead simple and just map the bff response to a ui and be done with it
(thats the ideal as i understand it anyways)
Re: Htmx Is the Future
#475What isn't mentioned is how there are intrinsic security issues with server side templating, including htx. Part of the reason react won is it has the best track record for client security with complex client apps when its used and configured and deployed correctly. With server side templating its easy to fall victim to injection attacks.
Re: Htmx Is the Future
#476Earlier quoted context omitted.
I'm not sure what you mean. htmx and alpine.js are both client-side frameworks. To me, they seem to have similar goals and similar functionality. What do you see as the difference?
They're neither different nor similar. In fact they work together, with Alpine managing client side reactive state (NOT app state, just interaction) and htmx managing the actual request model. That's why the htmx docs often refer to Alpine. They should be used in combination, not to displace each other.
This is also comparable to how Stimulus and Turbo work together, although I found to like using Alpine in place of Stimulus with Turbo and that combination works just fine as well.
Re: Htmx Is the Future
#477Earlier quoted context omitted.
> We moved away for MPAs because they were bloated, slow and difficult to work with. SPAs have definitely become what they sought to replace. Plus we now get the benefit of people trying to "replace" built in browser functionality with custom code, either The SPA broke it... Back button broken and a buggy custom implementation is there instead? Check. or They're changing things because they're already so far from def…
> The SPA broke it... Back button broken and a buggy custom implementation is there instead? Check. MPAs break back buttons all the damn time, I'd say more often than SPAs do. Remember the bad old days when websites would have giant text "DO NOT USE YOUR BROWSER BACK BUTTON"? That is because the server had lots of session state on it, and hitting the browser back button would make the browser and server be out of syn…
[deleted]
Re: Htmx Is the Future
#478Earlier quoted context omitted.
> We moved away for MPAs because they were bloated, slow and difficult to work with. SPAs have definitely become what they sought to replace. Plus we now get the benefit of people trying to "replace" built in browser functionality with custom code, either The SPA broke it... Back button broken and a buggy custom implementation is there instead? Check. or They're changing things because they're already so far from def…
> The SPA broke it... Back button broken and a buggy custom implementation is there instead? Check. MPAs break back buttons all the damn time, I'd say more often than SPAs do. Remember the bad old days when websites would have giant text "DO NOT USE YOUR BROWSER BACK BUTTON"? That is because the server had lots of session state on it, and hitting the browser back button would make the browser and server be out of syn…
> Remember the bad old days when websites would have giant text "DO NOT USE YOUR BROWSER BACK BUTTON"?
It was even worse when the page didn't warn you, but would lose state all the same!
Re: Htmx Is the Future
#479I don't disagree with the article, but I feel like the author almost landed on an interesting counterpoint. Author points out they didn't do this in ClojureScript, but writing apps in Reagent (the leading ClojureScript React wrapper) has looked almost identical across many years and many versions of React. Many of the state management epochs have also been avoided, because "manage state" is a core idea in Clojure, and so the stuff we had almost a decade ago is still perfectly fine today.
So, I posit that the churn, while definitely real, is not actually intrinsic.
Right now, at Latacora, we're writing a bunch of Clojure. That includes Clerk notebooks, some of which incorporate React components. That's an advantage I think we shouldn't ignore: not needing to write my own, say, Gantt chart component, is a blessing. So, specifically: not only do I think the churn is incidental to the problem, I don't even believe you need to give up compatibility to get it.
Fun fact: despite all of this, a lot of what we're writing is in Clerk, and while that's still fundamentally an SPA-style combination of frontend and backend if you were to look at the implementation, it absolutely _feels_ like an htmx app does, in that it's a visualization of your backend first and foremost (React components notwithstanding).
Re: Htmx Is the Future
#480I somewhat get where htmx is coming from. It's not bad per-say.. I actually like the general idea behind it (it's sorta like Turbolinks, but a bit more optimal using fragments instead of the entire page, though Turbolinks requires zero additional work on the markup side and works with JavaScript disabled out of the box). With that being said, I imagine it would become unmaintainable very quickly. The problems htmx is…
Turbo (the updated Turbolinks) uses fragments quite heavily... Turbo calls them frames. Turbolinks was more of a full page only approach though.