Live data from Hacker News

I'm betting on HTML

catskull.net

171–180 of 458 posts

Re: I'm betting on HTML

#171

I had heard of almost none of these HTML elements, and that's such a shame, because they could seriously help put the "we need JavaScript for every gosh darn thing" ecosystem to an end (or at least return JS to what it was originally meant to be: a way to add some flair, some interactivity, some whatever, but not necessarily a replacement for all of your markup and a full-DOM manager). I'm starting to think my dream…

In general the issue with these built in components is that you can't theme them. And they stick out like a sore thumb when you get a windows 7 style component in the middle of a modern looking app. They also have basically no extensibility so when you inevitably need to do something half complex, you have to scrap it and start again with JS. So you may as well have just started with JS which just works, gives you fu…

This is my biggest criticism of all these modern HTML pseudo components. It’s a wonderful idea, truly, but if you don’t provide style hooks to customize and theme them they are useless.

A month ago I wanted to use the input + datalist to have a searchable drop-down but there was no way to control where the dropdown will appear when popped open and what width will it have. Eventually I just gave up. Such a shame.

Re: I'm betting on HTML

#172

Tangent. > I wrote this post and then GPT-4 fixed my grammer and spelling I wrote an Autohotkey + Go script that I constantly use for fixing grammar using ChatGPT's API. You can select the text, press F8, wait a bit, and your input will be replaced by correctly grammatical text. The only catch is that it "fixes" the tone and makes it professional, which is kinda annoying. Feel free to try it out: https://github.com/a…

> The only catch is that it "fixes" the tone and makes it professional, which is kinda annoying.

Then why send your text to a slow third-party in the first place? There are craptons of spelling and grammar checkers available which will work offline, be significantly faster, consume less resources, and not change the meaning of your text. We solved this problem decades ago, we don’t need to shove AI in everything.

It’s not like the ChatGPT solution is flawless anyway, there are still basic mistakes in the text:

> Can by styled quite aggressively.

Re: I'm betting on HTML

#173

Earlier quoted context omitted.

This seems reductive to me. There's "HTML" and then there's the kind of website where the final DOM isn't known until the user has already been attempting to read it for 10 seconds. There is a substantial difference in the % of browser capabilities that need to be exercised between the extremes of use. Complexity of implementation is what ultimately separates the good from the bad. Any tool can be operated skillfully…

Lots of websites already present a machine friendly site to google-bot and some other spiders. I don't see why they can't offer the same to other bots and only serve the Javascript-heavy pages to humans.

The point is that a lot can be done without the need for Javascript. Also in pages served to humans.

Re: I'm betting on HTML

#174
post #95
post #26

HTML is the solution to walled-garden lock-in? What? Those walled gardens already use HTML, including some of the semantic elements mentioned (plus ARIA semantic attributes, which are much more sophisticated). > ChatGPT-like interfaces are likely the future of human data access. And the whole point of artificial intelligence systems is that they don't require specialized "machine-readable" annotations in order to pro…

ChatGPT (and its future offspring) can navigate regular websites the same way humans do It seems to be at least a not-yet-true claim, but let’s ignore that for now. It’s interesting if LLMs actually could do this. As I understand it, LLMs are trained on texts and source code among other things. But lacking… let’s name it a reasoning apparatus, can they really look at a DOM tree and tell what it is/does? It’s not a te…

LLM would find it easier to browse through a browser. Like us. Implying image model linked.

Re: I'm betting on HTML

#175
post #80

Earlier quoted context omitted.

In general the issue with these built in components is that you can't theme them. And they stick out like a sore thumb when you get a windows 7 style component in the middle of a modern looking app. They also have basically no extensibility so when you inevitably need to do something half complex, you have to scrap it and start again with JS. So you may as well have just started with JS which just works, gives you fu…

JS does not 'just work'. This is why a lot of these custom components have bad touch interaction and no accessibility. Take the datepicker; the native mobile version works great, why annoy users with a custom component?

> the native mobile version [of datepicker] works great

Strong disagree. It does work for simple forms, but definitely has a variety of quirks on different browsers/devices. Blank dates are especially quirky. Try “tabbing” through a date on iPhone or iPad and have some poor UI. datepicker really doesn’t work well for some less common situations (cut n paste, copy, from/to date, restricted date min/max past/future, year pick, month pick, etcetera).

Re: I'm betting on HTML

#176
When browsers finally have full and first-class WASM ecosystem integrated (and ecosystem developed), we'll be looking back on this "pretend-that-HTML-is-an-UI-framework" thing with genuine horror.

Re: I'm betting on HTML

#177
post #176

When browsers finally have full and first-class WASM ecosystem integrated (and ecosystem developed), we'll be looking back on this "pretend-that-HTML-is-an-UI-framework" thing with genuine horror.

And the old timers will look upon the WASM mangled unreadable mess that webpages have become with equal horror.

Re: I'm betting on HTML

#178
post #165

ugh I was so excited to see pure HTML modals were a thing with only to find out there's no way of triggering them without JavaScript. Using pure HTML you can only dismiss them, not trigger them. https://github.com/whatwg/html/issues/3567 > dialog elements are a great addition and I'm glad they're getting implemented, but a key part of their functionality relies on JavaScript: to open a you need to use JavaScript to s…

You can show or hide it depending on the current hash. Though admittedly that does require CSS.

Re: I'm betting on HTML

#179
post #22

I had heard of almost none of these HTML elements, and that's such a shame, because they could seriously help put the "we need JavaScript for every gosh darn thing" ecosystem to an end (or at least return JS to what it was originally meant to be: a way to add some flair, some interactivity, some whatever, but not necessarily a replacement for all of your markup and a full-DOM manager). I'm starting to think my dream…

You might like this: http://youmightnotneedjs.com/

You might not need JS, but you will need a SCSS transpiler.

Re: I'm betting on HTML

#180
post #176

When browsers finally have full and first-class WASM ecosystem integrated (and ecosystem developed), we'll be looking back on this "pretend-that-HTML-is-an-UI-framework" thing with genuine horror.

And the old timers will look upon the WASM mangled unreadable mess that webpages have become with equal horror.

Web pages can still be in HTML. It's a bad choice for UI apps.

(With current state of web ecosystem it's hard to tell the difference between what is page and what is an app, of course. But imagine we had a real choice on the outset of web.)

Post reply on HN