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

131–140 of 458 posts

Re: I'm betting on HTML

#131

Post by toyg »

b112 wrote: post #90
lelanthran wrote: post #52

Earlier quoted context omitted.

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…

Because firefox devs are... weird. I don't even mean that detrimentally, just observationally. You can un-hide that bar permanently, but when you do, it always covers the edge of the webpage. # scrollbar fixes user_pref("widget.non-native-theme.scrollbar.style", 1); user_pref("layout.testing.overlay-scrollbars.always-visible", true); I literally cannot see the benefit in hiding the scrollbar. It sounds like an edge c…

FF devs have to justify their jobs like any other. Someone was promoted for shipping a fancy-looking feature that some other browser, somewhere, probably has as default.

Still better than the Borg, at least you can fix it.

Re: I'm betting on HTML

#132

Post by fauigerzigerk »

azangru wrote: post #114

> With the advent of large language model-based artificial intelligence, semantic HTML is more important now than ever. It's odd: I remember seeing an argument recently, though can't remember where exactly (perhaps [0]?), that LLMs make semantic HTML obsolete, because they "understand" the text anyway. After all, humans didn't need html to be semantic in order to be able to read it — machines did. And if machines are…

Humans interpret text as rendered by the browser. That includes a lot of visual information and even text that only becomes visible in response to user interaction.

For an LLM (or an AI in general) to do what humans do, it would have to process the rendered output and interact with the site like we do (such as clicking on a dropdown to make the available options visible).

The same information represented as semantic HTML (i.e text) is far cheaper to process for an AI. I think cost is a key consideration in everything AI. If it's too expensive then it won't happen, even if it could theoretically be done.

Re: I'm betting on HTML

#133

Post by wruza »

kevinstubbs wrote: post #116
wruza wrote: post #95

Earlier quoted context omitted.

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…

> can they really look at a DOM tree and tell what it is/does Yes, if you encode the DOM as a list of options for ChatGPT to choose from. In fact I developed a proof of concept of this for a client. https://jarvys.ai/ although they seem to have pivoted from automating just the browser to automating all software.

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”?

Re: I'm betting on HTML

#134

Post by geysersam »

mattmanser wrote: post #122
tannhaeuser wrote: post #117

Earlier quoted context omitted.

> I had heard of almost none of these HTML elements I'm not disagreeing with the gist of your post, but come on, these elements have been around for ages. It's definitely on you to become acquainted with the basics before your HTML critic can be taken seriously ;) The post links to MDN (arguably the most useful short reference) but there is of course also WHATWG's HTML spec or, if that's too voluminous, SGML DTD form…

Most of them don't work properly and/or look terrible by default in all browsers. So no-one uses them, so lots of people don't know about them.

What do you mean with "they don't work properly"? Could you give an example?

Re: I'm betting on HTML

#135

Post by dgb23 »

marcus_holmes wrote: post #41

I use a lot for debugging Go html templates. {{if .DevMode}} Data {{.}} {{end}} It's nicely unobtrusive when collapsed, doesn't mess up the page completely. Then expands to the full glory when needed.

You can use it for all sorts of things on web pages, including collapsible menues and such.

Github markdown lets you use it too. People use it for examples and inline explanations.

Re: I'm betting on HTML

#136

Post by devjab »

klardotsh wrote: post #98
devjab wrote: post #19

I find it interesting that many of the comments here seem to view this as an anti JS article. To me a lot of these are going to be immensely useful tools in combination with the TS heavy frameworks we use for modern Enterprise App frontends, exactly because they are HTML native tools that aren’t going to require a bunch of stuff. Like the meter tag, which I assume will replace every loading module we currently use in…

I think (at least with my comment that's one of the kind you alluded to) my hope is that it replaces huge piles of JavaScript code. I have, sadly, no illusions of a JS-free web, but at least we could get rid of huge gobs of it and have more-standard UX that the system can help guide and shape (with the benefits that entails). It also enables a whole slew of new applications to be made that need way less JS than we us…

I've worked with Enterprise Frontends since the Mainframe CICS systems and I'm not sure why things like React and Angular gets such hate for Enterprise apps. I can't think of a single way of doing client server applications in an enterprise setting that's ever been nicer to work with. To be completely honest CICS was better than most GUI attempts from Java and C#, and it was a console UI.

I'm not saying JS frameworks can't be overused. I'm not personally afraid of the page refresh, but it's not like it was a joy to work with websites before these enterprise frameworks.

Maybe WebGPU and to some extend WASM (and whatever is going on with that) will change things, but probably not.

Re: I'm betting on HTML

#137

Post by reichstein »

KronisLV wrote: post #119
delusional wrote: post #112

Earlier quoted context omitted.

> “LLMs will look at any .exe and be able to integrate with it immediately”. The LLM will look at any .exe and determine if it halts.

> 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 itself a finite-sized program, something we run on computers, it cannot possibly solve the halting problem.

And _any_ non-trivial property of programs is undecidable, so an AI "integrating with any .exe file" isn't really meaningful. It's just words.

Re: I'm betting on HTML

#138

Post by klabb3 »

infogulch wrote: post #82
klabb3 wrote: post #55

Earlier quoted context omitted.

I like htmx too for its simplicity but it’s actually antithetical to another key HN trope: responsiveness. Round-tripping to the server is much slower than client-side JS. It should be terrible for fast keyboard navigation, for instance. You might not notice on a server on localhost or on fast internet (which is very user-hostile to assume). That said, this is me speaking about htmx based on what I know about it. The…

That's a common argument, but how often are you navigating around in a web app and you don't need data from the server? IME you do like 80+% of the time so "responsiveness" is false anyway, and when you don't you could get pretty far with basic http caching. And assuming high bandwidth is just as bad if not worse than assuming high latency, where typical web app dev platforms perform abysmially not to mention multipl…

You make good points. And these are different use cases, where one is simple client behavior where JS is suitable, whereas the other needs a round trip anyway.

I wouldn’t go as far as 99%. There are a lot of web apps where you toggle between panes, expand certain things, and so on. But I think you are still right in the sense that htmx is a very fruitful starter kit that can cover many if not most “boring” standard use cases.

One thing is for sure, this SSR hydration shit show is not a good state of affairs. It’s way too much complexity for what it does. And now you have to worry about reaching the same logical state from two different starting points.

> I'm betting that you can make a whole interactive site on top of Go's html/template library + htmx, using a pattern I'm developing

This is cool, and indeed reminiscent of PHP. Cycle of life!

Re: I'm betting on HTML

#139

Post by troupo »

satvikpendem wrote: post #75
troupo wrote: post #46

Earlier quoted context omitted.

> compared to other desktop or mobile apps, there is literally no difference between rendering on a canvas to rendering on Qt or SwiftUI. Except, you know, accessibility. > just get up in arms about the web that does not happen with other technologies. And for a good reason.

Do you realize that Flutter has an accessibility system that is often more advanced than most desktop UI frameworks? [0] I notice this often from non-Flutter devs, Flutter has some pretty good a11y. [0] https://docs.flutter.dev/accessibility-and-localization/acce...

Good to know! For the longest time ever their export to web was just canvas with no attempt at making it accessible.

Re: I'm betting on HTML

#140

Post by DharmaPolice »

anyfactor wrote: post #21
billforsternz wrote: post #11

Earlier quoted context omitted.

The misspelling of grammer instead of grammar is a little ironic in this context. Sorry:-)

Grammer, should of, datbase, mangement, timzone, accept/except, except/expect ..... We should accept these as part of normal written conversations and try to understand the context. With the amount of AI-generated content that is being produced, misspellings should be celebrated! But who am I to say that? I am literally converting my rants on the internet into professional arguments and using sophisticated synonyms l…

I'm going to have disagree with you on misspellings. AI can trivially replicate them (the Elizabot you used to get on old school BBSes would make deliberate mistakes/corrections) and they just make it ever so slightly harder for your audience to parse what you've written. If nothing else - expect/except sounds quite different from a screen reader.
Post reply on HN