Live data from Hacker News

HTML First

html-first.com

211–220 of 551 posts

Re: HTML First

#211

This 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 suspect this is a 'List of tips' written explicitly to promote hyperscript. Its example is also pretty weak. Vanilla solutions (Tip 1) works just as well:

Which makes the example even more egregious. There are certainly better ones that:

1. Can't be easily done with vanilla JS and so can justify using a library.

2. Don't need a library with a DSL in direct opposition to the claimed principle (avoid DSLs).

Re: HTML First

#212

For the sake of being precise - the “form_with” is not equivalent to the presented HTML. The form_with helper injects an additional hidden input element that makes sure that the form cannot be submitted “illegally”.

I think this is a great example of all the small details we take for granted in the tools we use, and we would miss without realising when following these tips.

That hidden CSRF field can be added without form_with though, and Rails still protects against not including it. I left it out of the example as it didn't seem relevant

Re: HTML First

#213

I’m sorry but what? This is terrible advice. I have never understood the desire to keep the web “inclusive”. Is the web not already inclusive? Can someone not already build a website with simple html/css? The web has evolved and taken the place of desktop apps by and large. That is what SaaS has done. These websites are built to be fully functioning pieces of complex software. Using some tiny tools to markup html is…

"fully functioning pieces of complex software" - in my experience a majority of software is simply not that complex. And the few places where it is are not on the view layer. To make sure we're not talking past each other, can you give examples of the kinds of software you're talking about? We do quite a lot of react work too, but it's ~20% of the projects we work on, when advanced frontend interactivity is needed.

Re: HTML First

#214
post #201

Earlier quoted context omitted.

"No one is afraid of writing code, we're afraid of maintaining code, and solving tedious and repetitive problems that already have solutions." Then, enjoy maintaining React apps once React inevitably bites the dust and ends up in the JS framework graveyard.

The chances of this happening before your project is obsolete are pretty slim. Edit: it depends on what you mean by "bites the dust". If you mean "isn't cool anymore" then I'd say that's kind of irrelevant. If you mean "isn't supported anymore", I don't see that happening any time within the next decade at least. Rails isn't cool anymore but it's still supported and lots of people are still (more or less) happily usi…

Another good example is jQuery, the last release was 2 months ago, and there is plenty of activity on GH.

Re: HTML First

#215

Earlier quoted context omitted.

I suspect this is a 'List of tips' written explicitly to promote hyperscript. Its example is also pretty weak. Vanilla solutions (Tip 1) works just as well:

note that the tag does not use and does not need a closing slash and never has in any HTML specification. https://html.spec.whatwg.org/dev/embedded-content.html#the-i...

Yep. It’s one of a handful of void elements along with and
.

Also using a slash to self close a tag is not part of the html spec and it never has been part of the spec. The browser doesn’t know what that means on any tag. If you write the browser ignores the slash and thinks you still haven’t closed your Div.

Re: HTML First

#216

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…

37 Signals has adopted some of these ideas. Would their apps qualify as "big" for you?

Re: HTML First

#217

Relying on simpler frameworks when you can make sense. But the notion of getting rid of build steps is a complete lark, just be more efficient with build steps, and if necessary, don't include them in production. Also why would you want to prioritize adding your attributes to HTML? Are you making a document and hosting it as a website? In what other world is that preferred? CSS isn't hard to navigate, if anything one…

A lot of this stuff is a response to the worship of complexity by the webdev industry.

Re: HTML First

#218

OP Here. This got more engagement than expected, some of the bits I've picked up in discussion: "Recommends skipping build step then mentions Tailwind": We use static-tailwind, a version with no build step, in development. "Recommends hyperscript, a new non-js syntax" - Agree this isn't perfect & would prefer something which uses js. Was going to use Alpine but also have found that to be quite brittle in production.…

> We use static-tailwind, a version with no build step, in development.

So you do use a build step for production? Or are you shipping a bunch of unused styles?

Re: HTML First

#219

I get the sentiment of this, but I struggle to recommend it (not least for the spelling mistakes, especially in the code examples) My main criticism is that you cannot really advocate for "View-Source Friendly" HTML with the view of widening the pool of people who can work on it, and then simultaneously recommend that people use libraries like HTMX or Hyperscript that have their own unique syntaxes that aim to be com…

I was going to comment, but you've done it for me. Your additional advice is spot on. But I actually think, "do whatever you like, the web is designed to be flexible".

The most crucial (half made) point here is that if you want your website to be useable beyond the output, document it ... include comments, make your reasoning explicit and not implied. And yeah, a repo is probably a great place for this. It doesn't even need to be linked on the visible part of your site (I mean, who's the primary audience here), just do the old "we're hiring " trick and print a link to the site's GH in the console. The docs will probably solve a few problems for you too when you need to change things down the line (I constantly read and improve my own comments during refactors, and usually kick myself when I haven't made them).

Post reply on HN