341–350 of 414 posts
I know, it's a ridiculous thought, right? There's always going to be challenging work to do, but some people are entrenched in VueJS/React/Angular, and relish spending 10x the time building CRUD apps.
I am burnt out (but recovering!) with web dev and htmx is what I am using for my project. Django, DRF, Postgres, tailwind and HTMX. I am so tired of all the front end frameworks and all the complexity that gets added. At some point I think you need it and you get returns from it but hearing more people in the industry recognize and talk about how JS everything isn't always the answer gives me hope. I like what HTMX h…
Can I ask you how long you have been using this stack for and what are your findings ? Do you have a complex UI heavy application and can you deterministically say that this stack can replace frameworks like React/Vue for JS heavy frontend ? Is HTMX really mature and stable for production and massive UI heavy apps ? I am asking because we are starting a big project in Django, Postgres, Tailwind and for frontend, stil…
1. One of the most painful thing with SSR forms is passing the data back-and-forth between the server and client when there are validation errors. Sometimes the data is very sensitive and you have to return the form with some values (like SSN) empty and make the user retype that along with with whatever field(s) were the actual issue. I'm also curious about how file uploads would work. 2. REST/GraphQL/gRPC API. Often…
Why can’t you hydrate the form with the SSN? If you’re serving it via TLS, there shouldn’t be any problem. It’s no different sending it up to the client than it is for the client to send it down to you. Unless you’re logging every rendered page for some reason, I guess.
However, looking at some of the more complex features it starts to feel like they are not all suited to HTML, but seem more fitting to CSS. Perhaps, even, we need something akin to CSS but dedicated to coordinating events and requests? I’m not sure. I get the feeling Htmx is a big step in right direction, but I don’t think we’re quite “there” yet.
I also think JSON has its place (b/c it’s pure data), and wouldn’t be too quick to completely chuck it out in favor of an all HTML replacement (data with markup).
Earlier quoted context omitted.
> I guess the main point of this library is to use HTML as the protocol payload between serve and client, instead of JSON HTTP is named Hypertext Transfer Protocol after all. Exchanging schema-less JSONs is conceptually pretty lame. It's plain old RPC architecture. That's why we end up needing to write API docs to line up the frontend and backend, or otherwise inspect backend code to figure out what's being handed ov…
This hits the nail on the head so hard that reading it feels like waking up from a bad dream. > Browsers are built to understand HTML. Whereas in the modern world we largely ignore that and write double the code we'd have to write otherwise passing arbitrary messages and it introduces a whole new set of problems making sure those codebases line up properly. This belongs in a manifesto. Put it on a shirt and I'll glad…
You see it all the time in software dev.
Earlier quoted context omitted.
> You can use the swap data attribute to update several fragments (imagine a saved icon) in several places declaratively. Yeah, but why? The javascript snippet to accomplish the same is absolutely trivial and avoids a dependency. > The price to pay for this is it does not work offline. For quickly prototyping and app it is very fast. The true price is that you've now rewritten your HTML code in a non-standard DSL and…
> absolutely trivial and avoids a dependency. I disagree with this other than in a simple example. Updating something that depends on sth is far from trivial. It looks trivial. > The true price is that you've now rewritten your HTML code in a non-standard DSL and are forever dependent on a third party library So, like React. Prob also a build and scaffolding tool, and a linter were added in that case. Regarding arsth…
heh, that's exactly what went through my head when I read the other posters comment, how is that different from the current SPA frameworks?
What i like with htmx is that it's very easy to upgrade step by step a legacy SSR app. And the opposite. I mean it will be easy to switch to an other ajax lib or if w3c add similar functionalities in 10 years. To use htmx is mostly to replace whole pages with fragments, that's interesting even when we don't use htmx, sort of server side web components.
In other world, just try !
I'm fighting myself to don't give back examples to the community but i'm so exited to upgrade my very old legacy apps !
Careful, it doesn't work inside shadow dom, nor hyperscript.
what does this mean ? i have been recommended hyperscript over alpinejs several times.
I am burnt out (but recovering!) with web dev and htmx is what I am using for my project. Django, DRF, Postgres, tailwind and HTMX. I am so tired of all the front end frameworks and all the complexity that gets added. At some point I think you need it and you get returns from it but hearing more people in the industry recognize and talk about how JS everything isn't always the answer gives me hope. I like what HTMX h…
[1] https://django-ninja.rest-framework.com
edit: typo
Earlier quoted context omitted.
Is the argument here that there are too many JS frameworks, or that the complexity of the frameworks themselves tends to grow over time? If the former, totally agree. If the latter, Java frameworks are plenty complicated. Also not sure how you've missed a lot of other frameworks; Spring and J2EE are certainly not the only ones that have been around for 10+ years. Dropwizard, Vert.x, akka-http, GWT, Play... just to na…
The argument is that I could learn Spring in 2002, find a Job then I could learn Spring in 2008 and find a job and then I could learn Spring in 2013 and find a job and then learn Spring in 2018 and find a job and then learn Spring in 2023 and find a job. Spring IS complex, but you learn it once and you are done with it.