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

451–458 of 458 posts

Re: I'm betting on HTML

#451

Post by berkes »

boredumb wrote: post #255
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…

I don't think people realize how CSS3 and HTML5 will do everything they need. And also that no one actually enjoys using a SPA.

But with just a little JS you can have a full SPA. You don't need a virtual dom to manage some HTML tags. You don't need UI libraries to render a UI. You don't need complex state management hook flow whatevs to manage some state. You don't need routing frameworks to read and write the URL. And so on.

With just HTML and CSS you can get a very long way. And if that last mile is truly a requirement, DOM APIs and a few lines of JS (or TS) have it covered. Only when all that grows wieldy do you need npm, frameworks and complex trees of dependencies.

Re: I'm betting on HTML

#452

Post by berkes »

boredumb wrote: post #262
Spivak wrote: post #258

Earlier quoted context omitted.

But it does seem that no one enjoys actually building MPAs and that force is currently winning right now.

Using your favorite language, a simple http listerner+routing and what ever HTML templating engines are supported, MPAs are simple and enjoyable to build. I think product people enjoyed pretending they were facebook for a while and decided the world needed more infinitely scrolling SPAs and forced a lot of people into having to use react and other frontend heavy frameworks to try to wrangle all the (often times britt…

It's rather easy to add infinite scrolling to an MPA too, though. A few lines of JS is all you need.

I'd argue this is simpler and easier than investing in a full blown ui library and state manager or painting yourself into some corner of today's JS framework.

Re: I'm betting on HTML

#453

Post by asdfgeoff »

jerf wrote: post #332

Article's first sentence: "With the advent of large language model-based artificial intelligence, semantic HTML is more important now than ever." I think the sentence "With the advent of large language model-based artificial intelligence, semantic HTML is less important now than ever." is far more defensible. The semantic web has failed and what replaced it was Google spending a crap ton of money writing a variety of…

I am curious about what post-LLM SEO is going to look like.

> The semantic web has failed and what replaced it was Google spending a crap ton of money writing a variety of heuristics equipped with best-of-breed-at-the-time AI behind it.

Arguably, there were insufficient incentives to fully adopt semantic HTML, if your goal was just to have the most relevant parts of your content indexed well enough to get ranked.

> As AI improves, it improves its ability to extract information from any ol' slop, and if "any ol' slop" is enough, it's all the effort people are going to put out.

If the goalpost shifts from “getting ranked” to “enabling LLMs to maximally extract the nuance and texture of your content”, perhaps there will be greater incentive to use elements like or . Websites which do so, will have more influence over the outputs of LLMs.

Feels like the difference between being loud enough to be heard vs. being clear enough to be understood.

Re: I'm betting on HTML

#455

Post by devjab »

treis wrote: post #343
devjab wrote: post #136

Earlier quoted context omitted.

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…

Enterprises want stability and front end technology has been everything but stable.

I’m not sure about that. Some of the ASP web forms frontends that I build something like 13 years ago are still being happily consumed today.

The only thing enterprise really cares about is money, and IT getting in the way, in any way, is costing money. Web fronts have been instrumental in cutting down the hate on enterprise applications in any org that I’ve worked with over the years. You’d see something with a great WPF frontend score a 3/10 and something with a shitty Vue frontend score 9/10 because it just worked, was never slow and “never needed to be updated”.

Re: I'm betting on HTML

#456

Post by andai »

dleeftink wrote: post #302
Animats wrote: post #103

Earlier quoted context omitted.

then realized there's literally no way to tell. It's all flat. I hate that. I'm waiting for that fad to be over. I kind of liked material design, but it's too much of a pain to put into everything. Flat, borderless, and unidentified is so easy to do. The all flat approach encourages dark patterns. Lists of trackers you can opt out of, scrollable, with no scroll bar and no window border. There are important buttons hi…

> There are important buttons hidden which, if pressed, do things favorable to the user but unfavorable to the site operator. Could you elaborate a bit? How is the flat look benefitting users over site owners? (Is this regarding lists of trackers?)

I think the idea was that when dealing with UI elements where it can be unclear what even is a UI element, it's easier to shape user behavior. e.g. making it harder for the user to "opt out of all tracking".

Those cookie consent boxes are definitely full of dark patterns. My "favorite" one was one that would take 45+ seconds to save your changes. I sent a complaint to the company that makes the consent box, and they responded "website owner configured it incorrectly, nothing we can do" LOL

Re: I'm betting on HTML

#457

Post by johnnyworker »

berkes wrote: post #437
johnnyworker wrote: post #257

Earlier quoted context omitted.

Give me an incentive to use it. If it looks exactly the same and behaves exactly the same, "div" is half the characters of "footer" so it wins. Personally, the argument that search engines will do nice things with semantic HTML didn't convince me back then, and I don't even see it brought up today, because search, like fish, stinks from the head, and we stopped pretending otherwise. So that leaves accessibility. Is t…

Maybe invest in an editor that helps you write ooter> after typing f in the correct place. If amount of characters truly is your reason to avoid semantic markup.

I am not "avoiding" it, I am not going out of my way to implement something that has no effect on anything, other than taking up more characters in files.

If semantic markup is so important to you, give me a reason for why. If the reason is "because I told you so", you just added a reason not to do it.

Re: I'm betting on HTML

#458

Post by mythhabit »

vidarh wrote: post #446
mythhabit wrote: post #444

Earlier quoted context omitted.

IO is just state and can be represented on the tape. You can construct a machine for every conceivable input at every time during the execution and reason about them.

"while (gets()) {}" is undecidable because the "tape" is conceptually infinite. So, no, you can not construct a machine for every conceivable input without imposing an artificial constraint on the input size. Put another way: For every tape you construct and analyse, there is a tape one segment longer that might contain a symbol that can alter the outcome.

You can, theoretically, keep constructing machines for every input you need. Yes you are bounded, but you can say "this machine will halt for every input it can receive in the next 100 years", because you need to quantify the input in blocks of time.
Post reply on HN