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

211–220 of 458 posts

Re: I'm betting on HTML

#211

Post by flagrant_taco »

feitingen wrote: post #168
bob1029 wrote: post #164

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 idea of maintaining two entirely different versions of the same side gives me flashbacks to the days when they sir had a separate "m." codebase for mobile. There's a reason we found better solutions there, building and maintaining the same site twice is almost never worth it.

Re: I'm betting on HTML

#212

Post by rapnie »

troupo wrote: post #169
rapnie wrote: post #143

Ian 'Hixie' Hickson gave his view on the future of the web in January this year in a public Google doc titled "Towards a modern Web stack" [0]. On its HN submission (referencing the wrong URL, so I resubmitted [1]) he defends against criticism [2] Quoting from the doc here's the stack: - WebAssembly (also known as Wasm) provides a portable compilation target for programming languages beyond JavaScript; it is being ac…

> On its HN submission (referencing the wrong URL) he defends against criticism [1] And it's a very weak defence. There are great rebuttals to whatever he writes in there. I mean, he rants that HTML failed, and then literally proposes "By providing low-level primitives instead, applications could ship with their own implementations of high-level concepts like layout, widgets, and gestures, enabling a much richer set…

Ah, that is enlightening, thank you. I knew he works for Flutter, but I know very little about Flutter and the standards it uses. That WebHID I hadn't heard of till this doc, so figures if this is a non-standard. More Google worrying power play then, similar to the web integrity bomb under the open web.

Re: I'm betting on HTML

#213

Post by o1y32 »

lelanthran wrote: post #52
jamamp wrote: post #22

Earlier quoted context omitted.

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

There's a scroll indicator! It tells you, by looking at a thin bar, how far down the page you are! What a novel idea! I wish browsers had this builtin so that we didn't need to implement a bar for showing the user how much of the document is left to scroll. (Seriously though, wtf did firefox make the scrollbar autohide? In order to see it the user has to interact with the page. It's worse in the debugger, where horiz…

I guess you never used MacOS, where the default system scroll bar behavior is even more interesting.

Re: I'm betting on HTML

#214

Post by asim »

Honestly, what we need is a new browser. I think everyone is sort of done with the URL bar, point click GUIs and we're going to see the need to transform things as LLMs become a more dominant query medium. It means the starting point is a search interface, it means much of what we want is automatically rendered as an embedded app in the page and it probably means we stop "browsing" and start consuming information on the web in a slightly different way.

Re: I'm betting on HTML

#215

Post by gryfft »

asim wrote: post #214

Honestly, what we need is a new browser. I think everyone is sort of done with the URL bar, point click GUIs and we're going to see the need to transform things as LLMs become a more dominant query medium. It means the starting point is a search interface, it means much of what we want is automatically rendered as an embedded app in the page and it probably means we stop "browsing" and start consuming information on…

Wow, thanks for the nightmares.

Re: I'm betting on HTML

#216

Post by flagrant_taco »

iamflimflam1 wrote: post #188
renegade-otter wrote: post #108

Earlier quoted context omitted.

I just ran into "datalist" and my first impression was "wow, game changer". The behavior is the same across browsers but the appearance is strictly browser-specific. You can't style it with CSS. Sometimes the list displays the text of the data, sometimes, the text and the "value" attribute. So you are not selecting "Atlanta" - you are selecting "234290780 Atlanta" (the ID and the value). And with the on-click action,…

That's the problem with most of these things, half assed implementations that just tick the box of "compliant with a standard". There's a reason why we have all these frameworks built on top of HTML - it's because the browser manufacturers have not done their jobs.

That's am incentive alignment problem, browser vendors' job is ultimately to make money not improve the specs.

Anyone that's interested can get involved in the specs process though. If anything it's web developers who haven't done our job there, it feels to me good specs are more our concern and responsibility than anyone else's.

Re: I'm betting on HTML

#217

Post by TeMPOraL »

kevinstubbs wrote: post #151
wruza wrote: post #133

Earlier quoted context omitted.

if you encode the DOM as a list of options for ChatGPT to choose from Not sure if I understand this, does it mean you have to pre-cook DOM in a specific way? If yes, then isn’t the answer to my question “no”, like “no, it can’t take any site and use it as is”?

You have to give GPT an objective, like "find an apartment in Florida" and then say something like "given the following options, which one would you interact with to get closer to your objective." So if you assume that you start on google.com, then your options are like 1.) Input with name "search", placeholder "search anything", value "" 2.) Button with label "I'm feeling lucky" 3.) Button with label "search" Obviou…

Remember HATEOAS? I have a feeling LLMs would excel at navigating proper REST (not "RESTful") APIs - HATEOAS is, in principle, just what you did here: providing a list of possible/useful next steps along with the response.

In fact, the problem of HATEOAS is exactly what LLMs seem to be good at - inferring the interface at runtime, from dynamically received metadata. This should even be easy to try in practice today - HATEOAS can be trivially mapped to the "function calling" feature of OpenAI's GPT-3.5/GPT-4 APIs.

Re: I'm betting on HTML

#218

Post by klaplume »

I'd argue that the modern markup elements you're showing are still way off from what the Semantic Web (as Tim Berners-Lee proposed) would enable. Image the possibilities of an 'AI' if it could understand the relationships between data and not just be a statistical parrot like LLMs are. Combined with something like Solidproject, that give users back control over their data, THAT would be a major leap!

Re: I'm betting on HTML

#219

Post by Gigachad »

zelphirkalt wrote: post #146
Gigachad wrote: post #56

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…

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 path to do this. You have to totally scrap the HTML version so you may as well start with a JS library that does everything you need today and everything you will need tomorrow. Which you can theme to fit in with the rest of the app rather than looking like a pimple on a pumpkin that UX and end users spot and complain about instantly.

Re: I'm betting on HTML

#220

Post by kybernetikos »

kaba0 wrote: post #130
KronisLV wrote: post #119

Earlier quoted context omitted.

> The LLM will look at any .exe and determine if it halts. At that point you'd need an AGI that can figure out something we can't. Edit: but yeah, sarcasm. Nowadays I can't even tell sometimes.

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.
Post reply on HN