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

391–400 of 458 posts

Re: I'm betting on HTML

#391

Post by d357r0y3r »

kethinov wrote: post #360
d357r0y3r wrote: post #323

Earlier quoted context omitted.

I think if the web apps we were working on were marketing landing pages, you'd be right. For any real application that software engineers are hired to work on, "learning HTML" would do very little. Most high-level front-end engineers do know HTML. There's not that much to know. The web today is basically a universal desktop client. Apps like Figma, Slack, Airtable, and thousands of others are not really websites, the…

Attitudes like that are why so many "real applications" have things like progress bars assembled from divs and JS instead of using a progress element or show/hide toggles assembled from divs and JS instead of using details/summary elements. Turns out there are so many HTML elements for a reason.

Attitudes like what?

How do you build Figma using "semantic HTML"?

Everyone likes the idea of keeping things simple and using web native constructs. The problem is that web native constructs can't do the things people them to do.

Even the progress bar example is a good one. Yes, there is a minimal progress indicator element shipped in the browser. It is completely useless for all but rudimentary cases.

Re: I'm betting on HTML

#394

Post by wruza »

reichstein wrote: post #137
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 think KronisLV's point, presented ironically, is that not even an AI superior to human reasoning, which can figure out things we cannot, can decide the undecidable. Being undecidable is a hard limit, not something that requires better algorithms. Another phrasing of it could be: No finite program can decide it. (And what even is an infinite program? Not something we can run on any current computer.) If an AI is its…

It has meaning. By looking at a table in e.g. getopt() call and an output of --help I can often infer modes of a program that I probably need, to do my job when someone asks me to. Whether this getopt() gets called or if a program does what it claims in usage() is not my concern. I was commanded to guess the usage and I do it without burying into the halting problem. And so does that hypothetical AI.

Decidable or undecidable is about maths, not practice.

Re: I'm betting on HTML

#395

Post by telotortium »

jerf wrote: post #358
zagrebian wrote: post #355

Earlier quoted context omitted.

Are you suggesting that AI will solve web accessibility, which is based on semantic HTML and ARIA? Because if not, humans will still be required to ensure that web content is accessible, and in that case semantic HTML remains important.

Actually, that sounds like one of the better startup ideas I've heard around AI. Automated accessibility compliance (or something close to it) would be very useful and definitely something people would pay money for. I fear LLMs are only about 80% up to the task, though, which is actually a very unpleasant place to be in that curve; sort of the moral equivalent of the uncanny valley. Whatever comes after LLMs though,…

Someone's on it already (but maybe there's room for competition, if https://adrianroselli.com/2020/06/accessibe-will-get-you-sue... is any indication): https://accessibe.com/accesswidget/artificial-intelligence

Re: I'm betting on HTML

#396

Post by mike_hearn »

troupo wrote: post #379
mike_hearn wrote: post #346

Earlier quoted context omitted.

So what are these great rebuttals? "Why not provide high-level powerful primitives out of the box?" So in practice most devs bypasses them and write their own high level primitives anyway, relying on the browser only for low level APIs. That's the point the article is making. Hixie is merely observing that this situation exists, has always existed and probably always will, so browser makers may as well embrace it. An…

> So what are these great rebuttals? Those that you apparently read but didn't understand. > the browser is a 30 year effort to do that and has always failed at it And so the "we will not give you anything at all, implement everyting including all layouts, all widget all interoperability etc. from scratch" will work? > browser implementations of even basic widgets aren't usable Great article on the topic: "You can't…

To more fully quote the Chrome PM:

You didn't solve the problems devs find challenging. Frameworks do. The existence of frameworks on the web is a feature, not a bug. Developers mostly don't want the assembly language of the web, they want their chosen frameworks to have excellent DX and the UX they produce to be fantastic.

We're shipping container queries, scope, nesting, style queries, state queries and a host of other features devs tell us they need to architect component systems

In other words, the Chrome team (today) assumes the use of frameworks as a given and sees their job as empowering frameworks. Note that "devs" here clearly refers to framework authors, the sort of people who architect component systems. She doesn't mean app devs.

So HTML as an all-inclusive app framework is going to die, arguably has already died, and the argument between Hixie and stubbornella is just an argument about what specific way to empower framework authors. Hixie argues that the focus should be on features for big frameworks that skip HTML entirely, stubbornella argues for features for smaller frameworks that still use some HTML, but they're both in agreement that raw HTML is just kind of useless and not the way devs want to go anymore. After all "state queries" is not either. There's less between these positions that may seem.

Now the real question is not could browsers theoretically ship really great HTML widgets. Sure, there's no rocket science in GUIs, in theory, browsers could do this. Yet after 30 years of immense effort they don't do so. That suggests some deeper structural issue. It might be team scalability issue. Chrome has a truly enormous team, but clearly they're struggling to do everything people might want from a browser. All that code has to be maintained after all, so as Chrome gets bigger we should expect them to slow down. Since the death of plugins the web is a completely monolithic platform. Given a choice between implementing some API that only a browser developer can do (e.g. WebUSB) or implementing an API that devs can hack up their own alternative to (a widget), it's clear why they always choose the former. Anything that browser makers can push off to web developers they clearly will, because there's so much to do that can't be pushed off in that way. Hence why HTML is still a poor UI toolkit and why JS frameworks are so widely used. It's a division of labor issue.

Re: I'm betting on HTML

#397

Post by multicast »

btbuildem wrote: post #299

What is the author suggesting? That instead of "social" networks, people will rush to building their own online presence from first principles? I can't see that working, for so many reasons: - most people are passive consumers of content, maybe interact a little, enough to tweak their feeds - a small minority creates content on the large networks / aggregators, and (I think) a large portion of that is spurred on by m…

You have just highlighted the main fact about the www that so many technical skilled people are missing to see. Most consumers have little to no knowledge about anything technical, which is not bad at all since there is no reason why they should care. Now imagine telling those people that everyone should have their own website instead of a social media account. What a horrible and illogical thought in my opinion. Digital consumers only change behavior if something is 10x better. So from a consumer perspective, who cares about things like decentralized networks? Or Duckduckgo.com for example is probably for 99% of the www users some chinese russian inbreed virus. People started using ChatGPT besides google because it is simply 10x better for many cases, and not because it promoted with more privacy feature and less ads than google.

Re: I'm betting on HTML

#398

Post by datagram »

wruza wrote: post #95
p-e-w wrote: 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…

There's already companies working on this: https://axiom.ai/

I would guess that it's just a matter of converting the DOM accessibility tree into text descriptions, e.g. "There is a button that says 'Start'" And then converting text like "Click the Start button" back into an actual action on the page.

Re: I'm betting on HTML

#399

Post by xp84 »

cratermoon wrote: post #10

The vs. thing, how did I never realize that before? I guess I'd never thought about them having a semantic meaning.

Same. This is mind-blowing! And just goes to show how different “markup” is meant to be from “formatting.” Not that you’d know it when so much content is made by people using a WYSIWYG editor that basically tells them “you are doing formatting.”

Re: I'm betting on HTML

#400

Post by datagram »

renegade-otter wrote: post #108
klardotsh wrote: post #9

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…

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,…

> You can't style it with CSS.

Unfortunately, I suspect that this is 100% intentional. datalists can draw outside of the browser window, which is fantastic, but also probably means that there are security considerations for letting it be styled by users. Imagine malicious ads/websites being able to draw outside the browser window.

Post reply on HN