Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTML First

html-first.com

Post reply on HN
Print view View original

41–50 of 551 posts

Re: HTML First

#41

Post by troupo »

moritzwarhier wrote: post #39
varun_ch wrote: post #34

While 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..

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 what the OP meant is: Tailwind requires a build step to extract use classes. Otherwise you need to ship all of it.

Re: HTML First

#42

Post by graypegg »

moritzwarhier wrote: post #39
varun_ch wrote: post #34

While 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..

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.

Re: HTML First

#43

Post by ralmidani »

Maybe 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 stick with downloading minified Bootstrap for styling (Tailwind requires a build step, and I don’t think I have done well in the past when I waded into “class soup”).

Has anyone here tried something along these lines for a non-trivial app? How is it going?

Re: HTML First

#44

Post by weego »

gemstones wrote: post #29

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?

Having worked with it for 20+ years I've just been left convinced that the biggest mistake frontend dev has made in that time is to pretend that CSS is a language that should be 'engineered' instead of a design flavour that should be build up / torn down lightly on demand. It's esoteric corners should have been fixed and simplified so designers could learn and explore design through markup as needed, rather than double-downed on to where we are now.

Re: HTML First

#45

Post by 1shooner »

ricardobeat wrote: post #2

“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.

Tailwind is a build step with just as much 'spooky action at a distance'. If it wasn't, we'd just use inline CSS.

With Tailwind you're trusting a 3rd party library to abstract the CSS spec for you, and for that abstracted quasi-spec to be followed by your build configuration.

Re: HTML First

#46

Post by robinson7d »

moritzwarhier wrote: post #39
varun_ch wrote: post #34

While 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..

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…

Did your experience involve the (recommended) build step? It uses, at least last I checked, a purgeCSS step to remove unused rules and decrease the css size.

Re: HTML First

#47

Post by jbverschoor »

ricardobeat wrote: post #2

“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.

Problems are multidimensional.

If we look at HTML as a document / presentation language, we cannot deny styling. CSS is not only styling, but also adds animation.

In any case, CSS can be seen as aspect oriented programming.

The real problem described here is the lack of great tooling across languages / frameworks.

Re: HTML First

#48

Post by gbro3n »

paulryanrogers wrote: post #38
gemstones wrote: post #29

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?

This strikes me as a cynical take. Having floated between backend and frontend a lot, frontends naturally tend to become very complex; even before the web. And with three different Turning complete stacks (HTML+JS+CSS) the web already feels pretty heavy before adding in another stateful framework and build tooling to support them. Folks can disagree about how to keep the system simple when looking at it from differen…

JS frameworks seem inevitable. Any time I've worked with native JS in a reasonable size projects, it becomes necessary to create libraries and common conventions, that starts to look like something approaching a small framework. A framework is just common patterns for solving problems. I think what a lot of developers object to is the stack of build tools required to transpile, bundle and link code together when using these frameworks, in addition to the complexity that comes with dependency management, rather than the use of the framework themselves.

Re: HTML First

#49

Post by moritzwarhier »

listenallyall wrote: post #16
pc86 wrote: post #8

Earlier quoted context omitted.

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.

The whole point of this essay is to encourage developers to avoid heavy frameworks like React, Vue, etc and use "lightweight" tools, including vanilla JS and native HTML features, instead.

I once built a project-tailored combobox using Alpine.js - this is about where it breaks down.

It worked, it was a lot of fun to write because it went really fast, even with some bells and whistles. Whole thing was my escape hatch when datalist attribute didn't work. It also worked well.

Alpine JS feels like a simpler version of Vue 2 without a build step and without any of the complex or confusing stuff (and of course with a focus on HTML not rendered by JS).

But when I saw what this turned into as a BE colleague copied it to the next form, making some adjustments... oh my, I prefer external and reusable JS (or a JS-first approach to templating, like React) any day.

Still, Alpine is really awesome for minimal interactions and simple JS.

When working outside React, it's hard not to miss it for the simplicity of doing everyday stuff inline in the HTML.

Re: HTML First

#50

Post by epiccoleman »

varun_ch wrote: post #34

While 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..

Tailwind has a standalone CLI which can be used for the build step. I do sort of agree that it's a bit of an odd recommendation in the context of this article, but the build step can be extremely minimalistic, and another nice thing is that the results are still inspectable CSS.

I use tailwind on my personal site, which is otherwise entirely just vanilla HTML, and it doesn't feel very intrusive to run the CLI in watch mode when I'm writing styles.

Post reply on HN