71–80 of 81 posts
Earlier quoted context omitted.
But why?
Fetching data from APIs I have no control over, or ones that serve multiple purposes and use a single response format
Obviously you _could_, and it might even work well, but I think that's using the tool against its grain.
Earlier quoted context omitted.
> But they're still too new and unproven for the React-embroiled companies to switch just yet. I've seen a few of HTMX projects attempted in production, at my previous employer. Decently sized, moderately complex web products for serious commercial purposes I will say though, all three were complete disasters.
But why? And what is a moderately complex web products? For example is Gmail a moderately complex web products? I am guessing there is a whole generation of developers growing up where front end equals React and HTMX / HTML / CSS is somewhat of an alien. Compared to some of us growing up with HTML, DHTML and Ajax.
In the end what you get out of your React code after your build process is vanilla HTML, CSS and JS. While you might be able to abstract some of those things away using libraries, all you‘re doing in your React code is building and manipulating HTML DOM trees within your React code and styling them using CSS (or using some abstraction like CSS-in-JS, CSS modules, etc.). To do so efficiently, you not only require knowledge of how exactly HTML and CSS work but also what React tends to do under the hood to render out your application. Even more so when things like a11y are required. A good dev also knows when to use JS to reimplement certain interactions (hover states, form submits, etc.) and when to use the native functionality instead (for example CSS pseudo selectors or HTML form elements).
All this is to say that I disagree with the notion that React devs don’t know or understand the underlying technologies. It might be different and more abstracted, but it’s still the same technologies that require the same or more understanding to be used efficiently.
Earlier quoted context omitted.
Then what's the point of using HTMX? If you're not sending just exactly the necessary HTML to replace the target's HTML; if you need to parse JSON, then even jQuery would be better suited. The whole idea of HTMX is to get rid of the extra steps.
I don't always have control over the remote end or due to business reasons the format can't be changed. And since htmx also has template plugins, being able to feed JSON values into it makes sense to me... a similar project, EHTML has this feature.
Earlier quoted context omitted.
> But they're still too new and unproven for the React-embroiled companies to switch just yet. I've seen a few of HTMX projects attempted in production, at my previous employer. Decently sized, moderately complex web products for serious commercial purposes I will say though, all three were complete disasters.
But why? And what is a moderately complex web products? For example is Gmail a moderately complex web products? I am guessing there is a whole generation of developers growing up where front end equals React and HTMX / HTML / CSS is somewhat of an alien. Compared to some of us growing up with HTML, DHTML and Ajax.
You need to be catastrophically bad to mess something like htmx.
If you are doing things like eCommerce, form heavy, read heavy, websites (the majority) instead of full apps like a paint/game/code editor (that I say should start with htmx and small components with whatever), htmx IS so simple.
What kind of messy backend this projects have that failed it? Because this is the point: htmx is just html with a bit of more interactivity.
To fail with htmx then you MUST has failed to render html well, and if that is the case, with react will be even worst.
An outcome like this suggest that if the project were made in react or similar it will have failed even harder
Earlier quoted context omitted.
But why?
Fetching data from APIs I have no control over, or ones that serve multiple purposes and use a single response format
If you're calling APIs that you have no control over, you do so on your server.
That's the entire point of HTMX: the minimal necessary addition to browsers/HTML to allow HTML REST APIs to update pages without full page loads.
I got a wave of shudder reading the acronym "HAM stack". Yugh. MEAN, MERN, RERN–once hyped up hot air which now sounds so dated and hackneyed. It's cool to be excited about tech but if your main selling point is building "faster and cheaper", I don't know if picking up a minimalistic framework you know nothing about is faster than just re-using your trusty boilerplate. Be it React or Svelte or whatever. With serverle…
cute stack names have gone downhill since LAMP
This seems like a good place to plug my own lightweight, compilation-free library that adds reactivity and local styles to native web components: https://vorticode.github.io/solarite
Interesting. It seems like an easy way to get JS to interact with HTML bits on the client side (if I understand it correctly). Maybe it could be useful alongside HTMX even: client-side HTML manipulation for simple things and server-side HTML hydration and rendering for complex things.
At what point are we going to say browsers with JS is outdated and painful? Every few months there’s some new framework. I think it stems from the fact that we refuse to change the browser. HTML was nice but all these solutions to make it modern are…ugly. And don’t get me started on JS. I just want an elegant solution that’s intuitive and built for modern applications.
Earlier quoted context omitted.
"works". name one thing using "flutter web". Flutter is just the thing startups use until they can hire a dedicated IOS person and fork the "app" codebase.
InvoiceNinja uses it, works pretty well for them.
Earlier quoted context omitted.
InvoiceNinja uses it, works pretty well for them.
went as far as their login screen, doesn't look like it's flutterweb.