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

I'm betting on HTML

catskull.net

Post reply on HN
Print view View original

241–250 of 458 posts

Re: I'm betting on HTML

#241

Post by vidarh »

kaba0 wrote: post #232
mythhabit wrote: post #187

Earlier quoted context omitted.

There is some nuances here. While the general halting problem for a general Turing machine is undecidable, and with a fairly easy to understand proof as well, the computers we run today are not a general Turing machine. They are of a weaker class called Linear Bounded Automatons and for the programs they can run, the halting problem is fact decidable, on a theoretical level due to their finite nature. So we will prob…

I have to admit my knowledge of complexity theory doesn’t extend too far, but isn’t the solution to LBAs just.. brute forcing? Also, is it even decidable a priori whether a program is LBA vs requiring a tape that is not only linear function of its input?

The worst case solution is just brute forcing, yes.

An LBA is effectively "just" a Turing machine that has a finite tape.

A typical current computer is an LBA only if you disallow all IO of any sort or bound that IO and include it as part of the system you analyse and so fix the values which will be provided as IO, which of course is a very unusual situation, and so that constraint does not really make the halting problem more tractable in situations we usually care about.

Re: I'm betting on HTML

#242

Post by kaba0 »

kybernetikos wrote: post #220
kaba0 wrote: post #130

Earlier quoted context omitted.

I am 100% sure that parent poster was being sarcastic at the hype around LLMs and how many think they can solve everything, even if said thing is impossible to do, e.g. the halting problem. Do note that the halting problem is fundamentally true, no AGI will realize some new way around, unless are mathematics are flawed to the core.

The halting problem is absolutely solvable in some cases, it's just the general case in which it is unsolvable. If LLMs were able to decode web pages and executables in a high proportion of the interesting cases, that would already be extremely useful. Humans can't do this in the general case either, but we still hire them to do jobs like this.

> If LLMs were able to decode web pages and executables in a high proportion of the interesting cases

Why would it be extremely useful?

Re: I'm betting on HTML

#243

Post by berkes »

yyyk wrote: post #157
Sjeiti wrote: post #80

Earlier quoted context omitted.

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?

>Take the [HTML] datepicker * Lets you enter nonexistent dates like 31/2 * Can and often does accidentally place the user in American-style MM/DD format where it should be European-style DD/MM (I have a replicable case now on that page example). * No ability to force date style by design. So there's no way to fix the above from the server, or to use ISO-style dates. Only way to reliably prevent MM/DD by default is to…

> ...place the user in American-style MM/DD... > No ability to force date style by design.

There is datetime-local, date, and time. And there's a lot of control over what is allowed with min-max ranges, steps, etc.

The only thing I can imagine to go wrong here, is when a user has their browser set in US-en but when they are not aware of that. Which seems... weird; or at least not a problem a web-dev should solve.

> Lets you enter nonexistent dates like 31/2

This may be an issue in specific browsers/versions/os. But enabling the "validation" by setting required and/or some other attributes, gives an error for these dates AFAICS. But, in any and all cases: server-side validation is needed anyway. You just cannot trust a value sent by a user, whether that's "validated" with sixty npm-packages and their dependencies, or by the browser.

Re: I'm betting on HTML

#244

Post by treis »

berkes wrote: post #230
flagrant_taco wrote: post #209

Earlier quoted context omitted.

(I don't know what tools you use so this isn't a comment directed at you specifically) If web developers spent a fraction of the time required to learn react, tailwind, etc on learning HTML the web would be in a much better spot. There are definitely quirks and rough edges, but if every web devs knew how to get the most out of semantic HTML we'd likely have a lot less JS in the browser, fewer accessibility bugs, and…

> on learning HTML Anecdote. Was recently freelancing at a web-agency. They build complex web-apps. Lot's of senior and experienced web-devs there: react, mui, typescript, tailwind, and a large host of backend frameworks under the belt. But when I built a quick PoC using ` ` a few lines of JS and some of the elements used in the article (meter, dialog, details) they were flabbergasted. This was a whole team of experi…

Covered is stretching it. Most raw HTML elements look terrible and wouldn't pass muster with pretty much anyone.

IMHO, this is a big miss with browsers. Sites look awful without styling and you have to be pretty good with CSS to even make them look passable. Way easier to reach for a framework with prebuilt components

Re: I'm betting on HTML

#245

Post by sebastianconcpt »

It's about structuring text with a consensual function as every tag has an intention implied. Creating sites and webapps using this, results in a less contradictory foundation of the text and elements exposed in the UI.

Re: I'm betting on HTML

#246

Post by zelphirkalt »

Gigachad wrote: post #219
zelphirkalt wrote: post #146

Earlier quoted context omitted.

I think the idea is rather, that you "extend" by composing primitive elements, and not that you change the primitive elements. Kind of like "composition over inheritance".

Take the html select component, you can't extend or compose this in any way. A request so common that it goes without saying is that you should be able to search for items. This is impossible to implement with the default component. If you want to do another common thing like allow selecting multiple items, this is also impossible. It's not worth starting with the HTML one and then extending later because there is no…

I think you misunderstand what I mean by "compose".

You can compose most HTML elements including easily:

    
      What do you like?
      
        First Value
        Second Value
        Third Value
There you go, you did composition. The logic between those elements, how doing something with one element affects the other element, that is a different matter.

For some elements it might be invalid HTML if one is inside the other. Like a inside a or so.

Re: I'm betting on HTML

#247

Post by merdaverse »

berkes wrote: post #235
merdaverse wrote: post #222

The problem I see with sematic web is that no matter how easy it gets, developers refuse to use it properly. I have been looking closely at the tag since a browser extension of mine uses it, and although it is extremely clear what it should do in the MDN documentation (the documentation itself is a good example usage of , etc.), very little sites use it properly. Even the fancy professional sites wrap all the page co…

> simple element can't be used properly, I have no hope for all the others. The first solution that comes to mind, is stricter validation. Where the browser would just refuse to render a properly unless it's structure is correct. But we had that. Anything before HTML4 really. And it sucked even more. So maybe browser dev-tooling that throws warning or errors when devs are Doing It Wrong?

The browser approach is best effort at rendering, rather than enforcing conventions.

And I doubt that tooling can help with all the complicated ways in which HTML is generated (React, SSR etc). I was actually surprised at how underbaked editor support for CSS is in VSCode (the most widely used frontend editor). If the most modern tooling can't understand that a CSS variable is declared in a different file and autocomplete it for me in a .vue file, I get the impression that tooling is severely lagging behind the frameworks.

Re: I'm betting on HTML

#248

Post by chrisweekly »

berkes wrote: post #230
flagrant_taco wrote: post #209

Earlier quoted context omitted.

(I don't know what tools you use so this isn't a comment directed at you specifically) If web developers spent a fraction of the time required to learn react, tailwind, etc on learning HTML the web would be in a much better spot. There are definitely quirks and rough edges, but if every web devs knew how to get the most out of semantic HTML we'd likely have a lot less JS in the browser, fewer accessibility bugs, and…

> on learning HTML Anecdote. Was recently freelancing at a web-agency. They build complex web-apps. Lot's of senior and experienced web-devs there: react, mui, typescript, tailwind, and a large host of backend frameworks under the belt. But when I built a quick PoC using ` ` a few lines of JS and some of the elements used in the article (meter, dialog, details) they were flabbergasted. This was a whole team of experi…

This is one of the things I like best about Remix (https://remix.run) -- it leverages React in a way that "grounds" it in web fundamentals instead of piling on further layers of abstraction. Remix is refreshingly simple, and its docs are chock full of references to MDN as the more authoritative source for web platform APIs.

Re: I'm betting on HTML

#249

Post by berkes »

treis wrote: post #244
berkes wrote: post #230

Earlier quoted context omitted.

> on learning HTML Anecdote. Was recently freelancing at a web-agency. They build complex web-apps. Lot's of senior and experienced web-devs there: react, mui, typescript, tailwind, and a large host of backend frameworks under the belt. But when I built a quick PoC using ` ` a few lines of JS and some of the elements used in the article (meter, dialog, details) they were flabbergasted. This was a whole team of experi…

Covered is stretching it. Most raw HTML elements look terrible and wouldn't pass muster with pretty much anyone. IMHO, this is a big miss with browsers. Sites look awful without styling and you have to be pretty good with CSS to even make them look passable. Way easier to reach for a framework with prebuilt components

This anecdote was a "pixel perfect" HTML version of some figma design. I did some CSS tricks to style the `` and was lucky the designer was lazy and never specified the styles of all the dialogs around date/time pickers (they weren't that important anyway).

You can style a lot of these native elements. And where you cannot, I'd argue that's actually good. I've worked with designers who insisted that everything looked and feeled the way they had designed it. But I've also worked with designers who, when showed how the date-picker looked on IOS, OSX and even Gnome, were incredibly happy that finally there was design that just followed what the users were used to.

Point being: it will vary. But I'm certain we need all these JS UI-frameworks like MUI far less than we use them. I'm certain plain-old HTML, CSS and a little JS suffices far more often than it's currently used.

Re: I'm betting on HTML

#250

Post by speedgoose »

berkes wrote: post #243
yyyk wrote: post #157

Earlier quoted context omitted.

>Take the [HTML] datepicker * Lets you enter nonexistent dates like 31/2 * Can and often does accidentally place the user in American-style MM/DD format where it should be European-style DD/MM (I have a replicable case now on that page example). * No ability to force date style by design. So there's no way to fix the above from the server, or to use ISO-style dates. Only way to reliably prevent MM/DD by default is to…

> ...place the user in American-style MM/DD... > No ability to force date style by design. There is datetime-local, date, and time. And there's a lot of control over what is allowed with min-max ranges, steps, etc. The only thing I can imagine to go wrong here, is when a user has their browser set in US-en but when they are not aware of that. Which seems... weird; or at least not a problem a web-dev should solve. > L…

But the webdev has to solve this problem. Users with wrong locales and not aware of that are not very uncommon. I would also love the US to fix their stupid date format and even fully adopt the metric standard but sometimes you have to compromise and write code instead.
Post reply on HN