241–250 of 551 posts
Earlier quoted context omitted.
Have you used HTMX? I am yet to find a reason for using frameworks like React instead of HTMX.
What's the reason to use a framework like HTMX instead of React?
- No complex build set-up (just link the script & use it)
- Less congitive load when reading the code. Especially if it's not yours.
- Very decent learning curve.
Earlier quoted context omitted.
I have used HTMX with Flask and Jinja. It makes the process much simpler to do the frontend development as a backend developer. But I can see its limitations. It's not suitable for anything bigger than a hobby project. Also, it doesn't help with keeping the frontend and the api totally separate. You have to return the html object from API which has its own set of problems.
> It's not suitable for anything bigger than a hobby project. This is patently false. It is being used in multiple significant production systems: https://www.commspace.co.za/ https://zorro.management/ https://www.contexte.com/ https://turboscribe.ai/ and many more. There are times where htmx isn't the right choice, but the idea that its not useful for anything more than a hobby project is simply false.
Earlier quoted context omitted.
> It's not suitable for anything bigger than a hobby project. This is patently false. It is being used in multiple significant production systems: https://www.commspace.co.za/ https://zorro.management/ https://www.contexte.com/ https://turboscribe.ai/ and many more. There are times where htmx isn't the right choice, but the idea that its not useful for anything more than a hobby project is simply false.
The middle 2 links are by solo developers - I wouldn't call those significant production systems. Generally tools like React are helpful for managing complexity across large systems where nobody understands the whole app and layers of of features, bug fixes and optimizations have been baked in over the years and nobody understands the whole app anymore
HTMX tries to reduce the complexity.
Earlier quoted context omitted.
> "Not that complex" Even if you have a fully static website you generally have a navigation bar and footer that needs to be on multiple pages. Things don't need to get very complex to benefit from frameworks and tooling.
Are you really advocating for using frameworks as a glorified #include directive? Frameworks are necessary when the job you're doing is highly abstract and you're not totally picky about the result. They shine at those things, but they are overkill for a static website. Something like Pelican or Hugo would be better suited for that. Shit, you could roll your own SSG in a weekend.
I've used all the things mentioned, and I quite like the ergonomics of frameworks for static websites. Added benefit is that I can make static sites dynamic if necessary.
And to be clear, these static exports are incredibly fast and performant.
> you could roll your own SSG in a weekend
Sure, I could do that, or I could build my app/website in that weekend..
Can the people that want this HTML-first world style it to look the ways they want themselves? My experience has been that proponents of HTMX and the like skew heavily backend and never feel comfortable with CSS. Why listen to UX thoughts from a population who are scared of UX?
Show me a powerful program with a "good" UI by modern standards and I'll show you a mess. VS Code is a prime example.
I get the idea - using the build-in capabilities of html is nice, clean, and simple. But that wasn't viable ten years ago, and it isn't today - and I don't particularly feel that htmx etc. is a better solution than something heavier like react. My go-to questions with anything like this are: how do things look if I want a dropdown? Multiselect? Datepicker? If we use do we get a datepicker across browsers? (Looks like…
> Is the look/feel/controls consistent across browsers? (No.) Can we style them to get there? (Also no.)
Assuming you design this website for users. Each users may use a different browser, but they probably use this same browser for all websites they visit. Hence IMO its more important that date pickers are consistent across all websites on 1 browser, then across 1 website on all browsers. (Its of course a different story if you need custom functionality.)
Earlier quoted context omitted.
Here to bust your assumptions. I skew backend but love CSS, and am one of the better UX engineers I know of. I also dislike javascript a lot, and find that the htmx approach cuts a significant amount of complexity out of your app (e.g. your views can talk directly to your daos.)
I’ve met enough people that aren’t like you that your lived experience, real as it may be, doesn’t really change my opinion much. For every one of you who isn’t scared of CSS there are like 40 people into HTMX that make bad UXs even by the standards of internal company tooling.
Interfaces are as unique as humans are. There's a reason we have emacs, vim, and Notepad.
Earlier quoted context omitted.
It depends, I think. For “apps” vanilla js isn’t enough. But for a blog with some animations or simple validation, things like next or gatsby is WAY too much
My rule of thumb is that if you're building something sophisticated enough that you want to reach for more "advanced" js frameworks then you shouldn't be building it as a web app.
I love this. Could you please consider changing the example from a clickable div – which is an accessibility nightmare – to a button?
A return to unsafe-inline? That feels like a bit step backwards when it comes to cross site scripting attack surface. Content-Security-Policy forces you to opt into unsafe for good reason.
I was about to comment that but luckily stopped to search if someone else already did. In our company this is taken pretty seriously and would trigger some raised eyebrows from the security department :)
In my opinion, it's consideration as unsafe isn't intended literally. It has more to do with:
- The human error aspect of understanding and tightly implementing CSP,
- Separating style and JS into their own files provides some security as is (and allows ignorance of CSP to continue even though it has it's use case here as well).
Now, if your company takes this pretty seriously, they likely require that CSP should be part of your security process already. If that's the case, any use of unsafe inline in your markup will be blocked by default until concrete steps are taken to have nonce or hash in place.
Edit: I did not intend to sound harsh - just wanted to chip in about the nuances about the possibilites we are provided :)
---
[1]: https://web.dev/articles/csp#inline_code_is_considered_harmf...
[2]: https://www.w3.org/TR/CSP/
[3]: https://content-security-policy.com/nonce/