5 ms·

The need for a native mobile app (or any kind of platform-agnostic behavior) probably negates much of the value of these stacks. That said, many projects don't

• gavinray 5y ago
  > That said, many projects don't have or need mobile apps, and many more can probably get away with a web-first mobile app. To me this is like building a house that can never be expanded, instead of starting with an open-ended design. > For those apps this stack can vastly simplify and streamline development I guess this is an opinion/subjective? I am very open-minded and experimental. I love trying new things. I've tried these technologies (HTMX, it's precursor Intercooler.js, Turbolinks + Hotwire, LiveView, etc) and for me they are less productive than the ways I know how to build API-first, JavaScript web apps. Have nothing against them, just genuinely having a hard time seeing the appeal.
  • nauticacom 5y ago
    I've tried these technologies ... and for me they are less productive than the ways I know how to build API-first, JavaScript web apps I think I feel the same way you do, except the other way around. I genuinely can't understand how you build apps productively with a separate client/server model. How do you do form validations? How about authentication and authorization? What about a consistent domain model? Is there one copy of it on the server and one on the client? Or does your client just treat everything as dumb data and make network requests for every question of business logic? What about data consistency throughout the interface—when you update e.g. Document(id=45) with new data, how does that update get propagated to every other place in the app? Does that involve a client-side identity-map? Or are you manually trying to send updated data to other places with callbacks/whatever? etc. for ever and ever. Every time I try to build an app where the frontend and backend are split into a separate client and API, it ends up adding so many more considerations and so much more complexity than the traditional model. Mostly because now everything that just required a database query or method call before now also requires a network request, but also because data consistency in a long-running app is so hard to get right.
    • nawgz 5y ago
      Your questions are all... contrived? > How do you do form validations? How do YOU do form validations? Is it entirely on the backend so it requires a round-trip before the user gets feedback, and additionally requires you to wire both the HTML endpoint for user feedback AND for rendering some results? For myself, I have a reusable Form component I can plug in arbitrary tests. You can run the tests when the user changes an input or on submit, with some options/conditions for when you clear the feedback. Then, of course, my API gives feedback as well; usually, it's harder / more awkward to wire the API feedback to highlight the offending Form fields, and I certainly don't see how HTMX would accomplish this, so without some machinery I already feel your side lacks QOL features like "highlight error fields" and "autofocus first offending entry". > How about authentication and authorization You are joking or what? There is no difference in how an HTMX app would authenticate to its endpoints and how an SPA would Finally, you ask a bunch of questions that clearly aren't any better in an API-endpoint-randomly-renders-HTML paradigm... > Is there one copy of it on the server and one on the client Obviously, but you load the client version from the server at API request time... just like an HTMX powered client... except an SPA keeps objects instead of a rendered representation so you can do more in-depth things without network trips... > What about data consistency throughout the interface—when you update e.g. Document(id=45) with new data, how does that update get propagated to every other place in the app? Because you use singletons like a not-crazy person... how does this happen in HTMX world where you have no data representation on the front-end? Does your form have to be manually wired to update every single present data view that is holding that document? Seems like you're worse off than me. I hold a stateful representation and update the views when that representation changes, automatically... Wow, literally no work required because it's declarative > Does that involve a client-side identity-map? Or are you manually trying to send updated data to other places with callbacks/whatever? Laughable. the HTMX paradigm is clearly worse off here > Every time I try to build an app where the frontend and backend are split into a separate client and API, it ends up adding so many more considerations and so much more complexity than the traditional model You clearly did not bother to understand how state & views relate in an SPA then. Your complaints make no sense either, this happens in HTMX world more than mine: > now everything that just required a database query or method call before now also requires a network request, but also because data consistency in a long-running app is so hard I honestly can't tell if you're trolling me. Let me break it down for you. In client/server world, client asks APIs for the data. Easy. Imagine a paradigm like GraphQL, the client literally just loads the data. It's the same as it would be on your server endpoint for HTMX, that's literally the client in your world. I hold a global singleton representation if my app is interconnected, or I load different singleton representations for unrelated subtrees if it's only partially interconnected. Next, if "collaboration"/real-time features are important, you make this data loading "aware" of when the data changed server-side, and you refresh your data. Easy as pie; you use the same function to reload. Lots of options on how to update the data, but if you correctly make your "load" function idempotent it is clear this is trivial. Finally, you write views that describe, declaratively, how to render the data. Since application state automatically re-renders these views, ideally not in their entirety if you used a good state management, you've already solved every single concern you listed about "stale data" by how you wired your data loading. So, great, in conclusion, HTMX endpoints are like a scattered version of a client that makes all nice "application" tricks virtually impossible, giving you no gains in any fashion that relates to data consistency or continuity, and requiring loads of manual wiring and awkward data-HTML manipulation in places that have no business doing it.
  • andybak 5y ago
    > To me this is like building a house that can never be expanded, Or alternatively it's a good application of YAGNI. There's always a difficult balance between that as a principle and "do work upfront as it will take you longer to do later down the line" Everyone makes this decision based on client budget, time constraints and a host of other factors. My clients tend to prefer to save money in the short term. That's not uncommon and it's a rational position to take for many.