Live data from Hacker News

Replacing JavaScript with Just HTML

htmhell.dev

21–30 of 296 posts

Re: Replacing JavaScript with Just HTML

#21
post #7

Some of these new HTML features don't fully work in my "ancient" browser. But all of them partially work (ie opening the accordion element doesn't close others but it still opens and closes) and they still remain functional elements I can read and interact with. This puts them far ahead of any javascript implementation which almost universally fail to nothing.

What "ancient" browser are you using?

Probably something 300 CVEs ago.

Re: Replacing JavaScript with Just HTML

#22
HTML and JavaScript serve distinct purposes, making better or worse comparisons logically flawed. Complex/interactive web apps requires JavaScript, period. Attempting to build sophisticated apps solely through HTML (looking at you HTMLX) eventually hits a functional ceiling.

Re: Replacing JavaScript with Just HTML

#23
A pleasant surprise to see Aaron's post here, we worked together for a bit on frontend optimization in a multi-tenant international ecommerce platform. That work was a large part of my inspiration for building https://contentblocksjs.com which encapsulated a lot of the JS concerns into web components.

Re: Replacing JavaScript with Just HTML

#25
post #24

I didn't know about , but how are you supposed to use it with a non-trivial amount of items in the list? I don't see how this can be a replacement for javascript/XHR based autocomplete.

> If we can hand-off any JS functionality to native HTML or CSS, then users can download less stuff, and the remaining JS can pay attention to more important tasks that HTML and CSS can't handle (yet).

Re: Replacing JavaScript with Just HTML

#27

HTML and JavaScript serve distinct purposes, making better or worse comparisons logically flawed. Complex/interactive web apps requires JavaScript, period. Attempting to build sophisticated apps solely through HTML (looking at you HTMLX) eventually hits a functional ceiling.

It shouldn't have to be this way though. There is no reason html can't do things it needs to do to build complete apps. We could use reasonable defaults to allow a new type of html markup without JavaScript.

All the http verbs. Decent html input controls What else?

Re: Replacing JavaScript with Just HTML

#28

HTML and JavaScript serve distinct purposes, making better or worse comparisons logically flawed. Complex/interactive web apps requires JavaScript, period. Attempting to build sophisticated apps solely through HTML (looking at you HTMLX) eventually hits a functional ceiling.

I assume you mean htmx. It doesn't have to be either/or. You can supplement htmx with Javascript.

The core idea with htmx is that you transfer hypertext with controls and structure built in, not just a JSON blob that requires additional context to be useful.

I have just shipped a very useful and interactive app surprisingly quickly for my customer using just htmx with a little Javascript.

Re: Replacing JavaScript with Just HTML

#29

The details / summary thing absolutely kills me. There’s basically nothing you can’t do with them. Hiding and replacing markers is easy. But every component library just pretends they don’t exist. It even saves you the effort of all the aria control and expanded tags: these tags don’t need them.

Do they work well for when you want to preview text? Like show the first 100 characters of a paragraph and then click to expand?

Re: Replacing JavaScript with Just HTML

#30
I'm so not impressed by the toggle implementation... How nice it could have been.

Nesting the elements is a truly hideous choice. The summary is part of the details?? I thought they were opposites.

Should we also put the headings in the

from now on?

Identifying a target should be done by id or by name. That it does use a name because js can't target it without makes it even more stupid.

We already had labels for form fields. Inventing a completely different method for something very similar is a dumb idea. The old checkbox hack is more flexible and less ugly for some implementations.

Why force the hidden content to be below or above the toggle? We aren't gaining anything with this.

What is this nonsense for an element to not just be hidden or displayed but to have some weird 3rd state where only one of its children is shown?

How should styling it even work for this new state? If I apply a style to the hidden content it must also apply to the link? The text is hidden but the style is visible??? Preposterous!

Don't try style to avoid unexpected behavior. Try wrapping the hidden content in a new element to make it behave normally.

What is this ugly arrow? If you find 1000 websites using a toggle I doubt there is one using an ugly arrow like that.

The default styling gives no clue about it being clickable?

The pointer (awkwardly called the cursor) choice is the text selection?????

Blue underlined "more" is what everyone does and everyone is used to. The cursor should be pointer. (This is css speak for "the pointer should be a hand")

The number of js toggles you can find online where the button lives inside the hidden text is guaranteed to be zero. Forget about drop in replacement, you will have to reinvent your css.

Maybe I'm dense but I also want my url to reflect the state of the page. I would have been impressed if that was supported. Personally I use actual links and disable default action in the listener if js is enabled/working or modify the state on the server if js isn't available/working.

It would have been great if the toggle action was implemented as a simple attribute something like toggle="element name" so that anything can be clickable and anything can be toggleable. Have a "closed" as well as an "open" attribute for the target.

Doesn't seem very hard. An open/closed attribute would be useful for other things too. Using display:none is terrible as display: is used for many things.

Post reply on HN