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

81–90 of 551 posts

Re: HTML First

#81

Post by isodev »

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

The OP was making a point that the build step should not be required to run/display a web app.

For example, tailwind without a build step is just the entire library. This means one can go a long way and even have a functioning web application without introducing a build step.

I would say stripping unused CSS is in the same context as optimizing images, fonts etc perhaps generally a "cleanup & prepare assets for production" step.

Re: HTML First

#82

Post by lolinder »

usrbinbash wrote: post #51
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..

The only thing a build step changes about CSS/JS resources of this kind, is a minimization of the libs...which is entirely achievable without building, by simply including the already-minimized version. I think what the article is about when it says to steer clear of builds, is complex builds, where transpilations and similar changes in format have to happen, in order for the page to work.

> The only thing a build step changes about CSS/JS resources of this kind, is a minimization of the libs...which is entirely achievable without building, by simply including the already-minimized version.

This isn't true, though—Tailwind's build step isn't just stripping out white space, it removes unused selectirs, too, which can't be done in advance.

Re: HTML First

#83

Post by alib »

I love this. Could you please consider changing the example from a clickable div – which is an accessibility nightmare – to a button?

Re: HTML First

#84

Post by amenghra »

kyleyeats wrote: post #59
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 made an atomic CSS library that doesn't need a build step, if anyone wants one (spoiler, nobody does): https://casscss.github.io/cass/

Imho, bullet points on the border box seems weird to me (https://ibb.co/d0sDsQ2).

Re: HTML First

#85

Post by gemstones »

smallerfish wrote: post #76
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?

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.

Re: HTML First

#86

Post by andai »

The main thesis seems to be that the user should be able to press View Source and understand what's going on. I agree, at least for web sites. For web apps, at least anything over 50 lines, you are probably going to want to use a typed language. (Well, you could technically use .js with TypeScript compiler and type annotations in special comments but I did not find that very pleasant.)

I used to be really big on this, though (and it makes me sad that these days most sites are 1 big unreadable line of HTML). In fact, I find a beauty and elegance in shipping the whole thing as a single HTML file with no dependencies (1 network request!), though I did eventually make a "build system" (my build system is cat) so I could have a sane editing experience. Boom, self-contained portable software in 1 human-readable file!

Along the same lines, I think the coolest thing about web development is that you can make your first (interactive!) programs with Notepad and whatever browser ships with your machine. (Just drag the HTML file onto the browser!) It's magic!

Edit: Just found an unexpected benefit of self-contained HTML: makes your software immune to bit rot. I tried loading an old project of mine on Web Archive but it hadn't archived the external JS file! Sad! Meanwhile, this one loads fine because all the JS is in the HTML! Winning!

https://web.archive.org/web/20210508133239id_/https://andai....

This is my homage to the old SodaPlay Constructor. (Never made an editor, sorry!) Feel free to view-source!

Re: HTML First

#87

Post by cantSpellSober »

and are great, but animating them to slide open instead of "pop" is difficult to implement without JS when the contents are not a fixed height.

Sliding open guides the user that something has changed, improves the UX.

I've found that using the `open` attribute in CSS behaves differently across browsers as well. Sometimes it doesn't even work consistently in a single browser implementation.

Re: HTML First

#88

Post by gardenhedge »

This seems like it came from a newbie/inexperienced dev.

> substantially widen the pool of people who can work on web software codebases

This isn't a problem. There's already more people who can work on web software than there ever was.

> A second goal of HTML First is to make it more enjoyable and seamless to build web software

Subjective. If people enjoy it like this that is fine but these shouldn't be touted as principles everyone should follow.

Re: HTML First

#89

Post by codeptualize »

This is fun in to theory and in simple examples, but show me a big project that applies this and how it made a difference.

There are some bold objectives at the start that would be wonderful, but I’m a bit disappointed by the advice. I really don’t see how these would work in anything other than very basic scenarios, even less how they would achieve the objectives.

I’m all for using the web platform to the max, and I’m absolutely for reducing complexity as much as possible, but I’m highly skeptical these principles will achieve that and I would not be surprised if it increases complexity by having multiple ways to do something.

With peace and love but I can’t see from this list if you actually put these principles to the test or you just assumed it will do what you hope it will.

Re: HTML First

#90

Post by mattlondon »

1shooner wrote: post #45
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.

Inline CSS is a total anti-pattern apart from the absolute most basic pages IMO.

There is no harm in a plain CSS file, and applying classes at the element level in the HTML.

If you put in-line CSS in the HTML is not only leads to severe duplication, but is also a maintenance nightmare if you want to change anything. It works fine if all you are changing is a colour or whatever, but often there are margins, paddings, letter spacings, font sizes etc etc which lead to quite a lot of extra crap in each element on your page. Repeating those all over each if your HTML files is a real burden. Just use a single CSS file with sensibly named classes - it doesn't need to be sass or anything, just plain CSS is fine.

Post reply on HN