> Where possible, default to defining style and behaviour with inline HTML attributes Wow, have we just come full circle after 25 years?
And it isn't even done in the example.
>class="bg-green"
HTML First
71–80 of 551 posts
Re: HTML First
#72Earlier quoted context omitted.
I don't use Tailwind anymore at the moment, but in my experience, it does not lead to shipping massive CSS/JS resources. In fact I don't know about any client-side JS at all that is emitted by Tailwind (my last experience was 2.x, not sure if anything has changed). Regarding the CSS size, my experience was the opposite, Tailwind output was usually a lot smaller than hand-written CSS. I have nothing against plain CSS…
I think GP is talking about how, without the tailwind build step, you ship all of tailwind, which is unquestionably a lot of CSS that you aren't using. Maybe if you use a CDN, so hopefully the user might have a local cache of it from somewhere else, that can be avoided? Still though, tailwind is pitched WITH it's build step normally, making the author's point about avoiding a build step a bit odd.
> Maybe if you use a CDN, so hopefully the user might have a local cache of it from somewhere else, that can be avoided?
Browsers partition caches by origin now for privacy reasons, so this is no longer possible. If the user doesn’t have it cached from your website, they don’t have it cached.
Re: HTML First
#73Earlier 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.
Why?
The web has moved far beyond a document sharing platform. It’s the largest, easiest (for users,) and most compatible software development and publishing platform ever. By far.
It’s not good for everything all the time, but it is good for most UI focused software most of the time.
Re: HTML First
#74Re: HTML First
#75Maybe I’ve already drunk the koolaid, but if I end up building a new app from scratch, I would really like to experiment with something similar to what the author describes: Django for most (if not all) of the server-side code, Django templates generating HTML, htmx handling most interactivity with html attributes and, when necessary, hyperscript (for use cases that can’t be covered easily by htmx). I would probably…
I used this exact approach: Django backend, Django templates and htmx. It has been a delight.
Re: HTML First
#76Can 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?
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.)
Re: HTML First
#77This one confuses me: > Where libraries are necessary, use libraries that leverage html attributes over libraries built around javascript or custom syntax And then they demo using _hyperscript [0] as encouraged. However, that's a library built around a custom syntax. It's only using an HTML attribute to encode a script that's in a new language you need to learn. Is this serious? [0] https://hyperscript.org
I would agree - the example of an an attribute of `_` and then some obscure DSL statement as a value looks super weird and confusing.
I would rather there was just an explicit `onclick` (or some other event) in there with a vanilla JavaScript statement so I know what is happening.
Re: HTML First
#78“Locality of behaviour” is such a poorly defined rule. It’s just an invented name for going against separation of concerns. Calling CSS “spooky action at a distance” is a massive stretch too. Good principles here but the arguments are quite weak and could be much simpler.
(coming from a C# shop with too many interfaces) I think it's a natural counter-reaction to overly abstracted systems.
If "making the red-bouncy-plonk button instead become the blue-wobble-thunk button" requires chasing through a maze of 3-to-7 interfaces and classes to find which classes need new implementations and which can be reused... Suddenly what sounded like a 10 minute change becomes half a day of swearing under your breath at either the compiler or the previous engineer.
Sure, abstract things, but make sure there's also a way to bundle behavior together in one common spot, so I don't have to touch 6 files to update one component.
https://htmx.org/essays/locality-of-behaviour/#conflict-with...
Re: HTML First
#79Earlier quoted context omitted.
I don't think you'd mix in React with this approach.
Isn't it much easier to know you're going to use React (or Svelte or Vue or anything else) and just start there? Starting a build in HTML-first only to bolt on a JS framework after the fact seems like a lot of wasted effort.
It might be easier to staff for. But developing a React frontend takes way more time than just server rendering HTML and layering in JS for the vast majority of use cases.
Re: HTML First
#80While I agree with most of the arguments here, this article feels a little contradictory - it recommends Tailwind but also tells us to 'stay clear of build steps'. Shipping massive CSS/JS resources goes against the whole inclusivity principle - many people don't have super fast internet connections or powerful enough computers..
You don't ship Tailwind...