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

361–370 of 458 posts

Re: I'm betting on HTML

#361

Post by mike_hearn »

jll29 wrote: post #152

HTML was designed as an SGML application for networked hypertext. As an alternative to what the original post posits, we could leave it for that purpose, and design another (now XML) application for user interfaces: windows, buttons, scroll bars (if desired), text controls (no I'm not talking about textarea for CGI), the kind of controls that Windows or X11+MOTIF provide, expressed as tags in a UIML (User Interface M…

It's been done many times. Mozilla had XUL. Internet Explorer had XBAPs (XAML Browser Apps) [1]. Android has an XML UI language. Java has FXML, which IMHO is the cleanest and nicest of the lot.

It never works. Same reason as to why adding non-JS languages never works: because making a GUI toolkit or implementing a language is a huge amount of work, other browser makers refuse to get on board because it'd mean they're playing catchup. Then web devs refuse to use it, because not every browser supports it. The only acceptable way forward is to gradually glue lots of small things onto HTML, and see which ones get implemented by the others. Because this is such an incremental and random process you end up with a pretty inconsistent platform that lacks a lot of stuff you'd intuitively expect.

[1] https://learn.microsoft.com/en-us/dotnet/desktop/wpf/app-dev...

Re: I'm betting on HTML

#362

Post by odyssey7 »

kaba0 wrote: post #353
odyssey7 wrote: post #339

Earlier quoted context omitted.

It’s fun to think about. What about the Collatz conjecture? If we run it for arbitrary n, on a computer that represents numbers up to n_max, we could know if it will halt within n_max steps. Since only n_max numbers are representable, we could track all visited numbers to detect any cycle that might occur. If on the other hand any iteration would exceed n_max, then the program would halt by crashing. hailstone :: Int…

We have actually done something like that up to the 32bit n_max for sure (but maybe even 64bit?), without any number that would contradict the conjecture. But yeah, it is not even trivial to say whether it has a bounded max memory, so in case of an arbitrary precision int type, it may not be LBA, but Turing?

I guess I was thinking about indexing the visited numbers from a graph-traversal-algorithm-interview perspective instead of a CS theory one.

We can actually do it in O(1) space complexity in exchange for higher time complexity.

For i in range 1..n, compute n_i, the ith number in the hailstone iteration, and then continue the hailstone iteration n_(i+1)..n_max to see if n_i is equal to any of them. This takes us to quadratic time complexity, O(n * n_max), or constant complexity depending on how you look at it, but it only requires storing a single n_i at a time for cycle detection.

But then again, if you actually loop for n_max iterations without halting by reaching 1 or crashing, then you had to reuse a number somewhere, so the explicit cycle detection isn’t really important.

Re: I'm betting on HTML

#363

Post by JyB »

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…

I mean. Doesn't it always boils down to supporting all "old/different browsers" hence why all web-agencies have to use all those JS libraries that seamlessly abstract it all?

Re: I'm betting on HTML

#364

Post by willio58 »

is so close to being perfect but I know the people I work for would want it to show the full list always and just float the selected value or closest spelled value to the top. Right now if you select a value on chrome and then click the list again it just shows that one value until you delete your entry.

Re: I'm betting on HTML

#365

Post by zagrebian »

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

80% sounds way to optimistic to me. The problem is that screen readers (and other assistive technology) have bugs and different behaviors, and some people use older versions of those tools with even more bugs and quirks. The only way to make sure that a website has a high level of accessibility is to perform manual testing in different environments. I don’t see how AI can solve this problem. And the people who perform the manual testing need to be experts in semantic HTML and ARIA to be able to identify problems and create reports. That means that semantic HTML remains important.

Re: I'm betting on HTML

#366

Post by bob1029 »

sublinear wrote: post #348
bob1029 wrote: post #324

Earlier quoted context omitted.

> That may not work for a lot of sites that depend on client rendering Products that depend on client-side rendering don't deserve to have regression-free experiences. You are literally doing layout with javascript and wondering why things get funny on edge case clients. The web is fucked until it becomes truly popular to build vanilla, SSR applications again. I feel like we are almost at the end of the tunnel of cli…

This sounds regressive and the battle has been over for almost a decade now. Server-side rendering is silly and client-side rendering should not be used for the entire page. Even for complex web apps, the majority of the HTML is static. The best web experiences are static HTML with client-side rendering only used for the dynamic sections of the page. It's not even a choice to do it any other way anymore if you care a…

> This sounds regressive and the battle has been over for almost a decade now

This sounds like what google would like for everyone on HN to believe.

Using "a11y" and "SEO" to push bad technology abstractions is tantamount to petty bullying in my view.

Genuinely, I don't understand the position that SSR somehow makes accessibility worse. Can you walk me through how adding more javascript on top somehow solves the problem of making a website compatible with a screen reader?

Re: I'm betting on HTML

#368

Post by sodapopcan »

sublinear wrote: post #348
bob1029 wrote: post #324

Earlier quoted context omitted.

> That may not work for a lot of sites that depend on client rendering Products that depend on client-side rendering don't deserve to have regression-free experiences. You are literally doing layout with javascript and wondering why things get funny on edge case clients. The web is fucked until it becomes truly popular to build vanilla, SSR applications again. I feel like we are almost at the end of the tunnel of cli…

This sounds regressive and the battle has been over for almost a decade now. Server-side rendering is silly and client-side rendering should not be used for the entire page. Even for complex web apps, the majority of the HTML is static. The best web experiences are static HTML with client-side rendering only used for the dynamic sections of the page. It's not even a choice to do it any other way anymore if you care a…

> It's not even a choice to do it any other way anymore if you care about a11y and SEO.

Can you explain this?

Re: I'm betting on HTML

#369

Post by treprinum »

kaba0 wrote: post #347
treprinum wrote: post #344

Earlier quoted context omitted.

While that's true, halting problem is completely useless in the real world (nobody designs user-facing apps while thinking about whether the program halts), whereas picking data from speech is a much more useful one that was long unreachable for "clean" closed-formula math.

Ok, and it is completely irrelevant. Besides, guess what enables the training of those neural networks? I’m fairly sure gradient descent has a bit to do with mathematics’ closed-formulas. Of course ML has use cases where traditional tools are less fit, my gripe is the hype-based anti intellectual nonsense that often surrounds it. They are no magic tools, the fundamental limits these giants of math/CS discovered still…

Yeah, hype is driven by business and marketing who want to sell more of a new thing pointing out what was not possible before using all kinds of silly arguments. Still, there is some noticeable progress there (compared to e.g. crypto that outside logistics and large-scale fraud didn't bring much despite being based on super solid number theory concepts).

Re: I'm betting on HTML

#370

Post by pphysch »

I think the #1 issue with HTML (and CSS) is that it is portrayed as being trivial, easy, "not a programming language". Someone who has written a few `` "knows HTML". It's not respected. Consequently, people don't invest time in learning to use it well and keeping up with new features. And then they use it poorly, or run into awful examples of it, and come to the wrong conclusions about it.

While the idea of a markup/styling language is pretty simple, HTML+CSS deal heavily with difficult concepts like ontologies, cascading and non-imperative behavior, balancing UX & machine interpretability (accessibility), etc. Add in HTTP and browser APIs. Web dev is distributed computing par excellence, and is extraordinary deep and challenging, yet it's also viewed as among the lowest forms of programming. That's a big mismatch.

Post reply on HN