A worthwhile experiment, absolutely, but I can’t see myself ever using this for a serious production application. I hope we keep iterating on this before settling for a non-turing complete, directive-driven language that gives Angular 1.0 PTSD flashbacks
@keithjgrant@skwee357 it's a screenshot that is omitting the line just below the piece of code saying that is has hyperscript in it. Doesn't seem fair to say that the documentation does not make that clear.
OK, I get what's happening here. Example goes hard out of scope than what HTMX serves. No wonder we get confussed Pikachus around this breathe of fresh air.
@sergi@skwee357 What is clear, then, is that HTMX is extremely limited in its capability, and it isn’t even able to offer this simple example without augmenting itself with Hyperscript or something similar. IOW, it's no replacement for a proper frontend framework.
I guess that's fine for what it is, I guess, but that's not something I'm interested in using
@keithjgrant I think of htmx as being more about a server-driven application architecture. That code block is showing off some advanced scripting stuff with hyperscript, but htmx is really about the hx- attribute bits.
The core idea with htmx is to get back to a model of hypermedia that adheres to HATEOAS, by allowing interactions on a granularity smaller than a whole document.
@MangelMaxime …I hope they at least have syntax highlighting and editor autocomplete tools built for that. Because if they don’t, that’s 100% a non-starter for me
@keithjgrant@MangelMaxime No, htmx does not “use” hyperscript (nor is it implemented in it). You can decide to use hyperscript along with htmx but you don’t have to. Htmx is only the hx- attributes.
@keithjgrant@cferdinandi So you're saying that you don't wanna use standard interfaces, & retaining your favorite opinionated tools (which intentionally break platform features by incorrectly reimplementing them) for a "developer experience" (read: personal sense of being very clever indeed) overrides all other considerations
Lion: white label, themable
MWC, FAST, vaadin, PFE: all themable
Your problems only exist for those unwilling to learn and adapt
I play nice with the other kids just fine, but I have no need for the other kids to use the components I use in my web app. So I use what gets the job done.
@bp
And yes, developer experience is a huge part of that equation. If it's a painful DX, work will take longer, be more soul sucking, and the product won't receive updates in a timely manner. I get that DX is not the most important factor, but it is a factor, and no amount of idealism washes that away
@bp I code in React. And believe me, I'm ready to move on. There are such better options these days.
But in the real world, shipping actual products for a major company, things like an active ecosystem, a large community for finding answers to questions, and available hiring pool skillsets are a major factor
@keithjgrant It's real pretty to imagine that the world ends 2 levels above you in the org chart and that no one else matters, but in actual fact there are opinions out there that don't conform to your framework's constraints and the only way to satisfy those needs is through standard interfaces, whether or not you think they're yucky
and don't get me started on 'recruiter-driven-development'
@cferdinandi@bp Styling is the key thing. The Shadow DOM approach makes no sense to me.
I've come around to the idea of WC without Shadow DOM. It's an approach I mean to play with. But I still feel like a WC is a lower-level thing than a framework component. I'd still need the affordances of a framework above my Web Components
@cferdinandi@bp What gets me, though, is once I add that framework, it does almost everything WCs provide out of the box, and I no longer see the argument for using WC (except in the specific cases where I need to export them, which isn't really my problem space these days)
@keithjgrant@cferdinandi No no no no. You don't get to say that your fw's non-standard, siloed, forward-breaking reimplementation is "out of the box"
The platform provides your legacy fw's userland features out of the box, but with less tech debt, lockin, & org-silo
I get that you built up career clout & job title by wrangling/genuflecting to fw tooling, & now that you've paid that cost & imposed it on your teams you get to feel like it's all a given
@keithjgrant@cferdinandi Look, we all know that Facebook was founded on principals of Open Web technologies, interoperability, local ownership, diversity of opinion/experience, & software quality
So when their engineers flatly claim title as alternative & superior standards body for brogrammers of all backgrounds which pass as highbrow on their conference circuits, we can trust them when we adopt their wide-ranging, team-blocking, standards-breaking opinions.
@keithjgrant@cferdinandi if i'm a little spicier than normal it's because islamofascist terrorists are trying to killl me and half of mastodon is cheering them on
@bp@keithjgrant Half of mastodon is not "cheering on Hamas." They're rightly pointing out that Israel has oppressed Palestine for years and is murdering their children actively RIGHT NOW.
Almost all of Those same people will rightly tell you that Hamas is a terrorist organization.
@bp@keithjgrant Benny, you're being weird. Keith can say whatever the fuck he wants, and in this case, he's right.
His framework does provide what he needs out-of-the-box.
There's a valid argument to have that something portable and not-third-party dependent is a better choice for most projects, or that React is actively harmful to most client projects.
I think Web Components in a React project are a bad fit, personally. That's not what they're for.
Add comment