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

441–450 of 458 posts

Re: I'm betting on HTML

#441

Post by guggle »

infogulch wrote: post #433
guggle wrote: post #426

Earlier quoted context omitted.

I almost have ptsd from these dark days, I won’t go into details ;-) but there’s plenty of literature about separation of concerns. Having the templates doing the data access takes me back 20 years ago, but I can see why this idea comes back in a web component era.

Check out: https://htmx.org/essays/locality-of-behaviour/ The proposal is that Locality of Behavior > Separation of Concerns. Maybe its true! We'll see. :)

I actually like htmx (I find Unpoly superior so that’s what I use, but it’s the same general idea) and the example given makes sense, but one should not extend locality of behaviour to the point of sprinkling SQL in templates. I don’t think that’s what the htmx folks had in mind in this essay either, their canonical example being the html/css/js trio. But hey… there’s no better experience than first-hand experience, you will find soon enough if it works for you.

Re: I'm betting on HTML

#442

Post by infogulch »

guggle wrote: post #441
infogulch wrote: post #433

Earlier quoted context omitted.

Check out: https://htmx.org/essays/locality-of-behaviour/ The proposal is that Locality of Behavior > Separation of Concerns. Maybe its true! We'll see. :)

I actually like htmx (I find Unpoly superior so that’s what I use, but it’s the same general idea) and the example given makes sense, but one should not extend locality of behaviour to the point of sprinkling SQL in templates. I don’t think that’s what the htmx folks had in mind in this essay either, their canonical example being the html/css/js trio. But hey… there’s no better experience than first-hand experience,…

I agree that it's taking the idea of LoB to an extreme that wasn't intended (at least not explicitly) in the essay. But I still don't see why it's a bad idea considering that SQL-level abstractions (views, procedures, etc) are available. What value does adding a layer of application-level abstraction provide? So I have to name and call a function that calls the sql; to what end?

Re: I'm betting on HTML

#443

Post by mythhabit »

kaba0 wrote: post #232
mythhabit wrote: post #187

Earlier quoted context omitted.

There is some nuances here. While the general halting problem for a general Turing machine is undecidable, and with a fairly easy to understand proof as well, the computers we run today are not a general Turing machine. They are of a weaker class called Linear Bounded Automatons and for the programs they can run, the halting problem is fact decidable, on a theoretical level due to their finite nature. So we will prob…

I have to admit my knowledge of complexity theory doesn’t extend too far, but isn’t the solution to LBAs just.. brute forcing? Also, is it even decidable a priori whether a program is LBA vs requiring a tape that is not only linear function of its input?

The naive way of deciding it it halts is executing it and keep track of all state between steps. If the machine halts, you're done, if it repeats a state, it's looping.

If you can represent a program with an LBA, it is by definition a context sensitive language and decidable. You could also show it by making a equivalent gramma for the language, that accepts the same input as the program. This gramma must be constructed in a certain way, and then you know it is a context sensitive language.

Re: I'm betting on HTML

#444

Post by mythhabit »

vidarh wrote: post #233
mythhabit wrote: post #187

Earlier quoted context omitted.

There is some nuances here. While the general halting problem for a general Turing machine is undecidable, and with a fairly easy to understand proof as well, the computers we run today are not a general Turing machine. They are of a weaker class called Linear Bounded Automatons and for the programs they can run, the halting problem is fact decidable, on a theoretical level due to their finite nature. So we will prob…

A machine we have to today in isolation with no form of IO are not general Turing machines, but almost all of them do have that and so if you consider them in isolation rather than the full system (which would include all sources of inputs) the halting problem applies. E.g. code to the effect of "while gets() {}" will either halt or not halt depending on the input, but which isn't decidable without knowing or constra…

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.

Re: I'm betting on HTML

#445

Post by lenkite »

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.

This is also why I think frameworks like Flutter that render everything to canvas are going to become more and more popular over time - as more and more WASM standards are implemented in browsers.

HTML will be used only for docs and not for web-apps.

Re: I'm betting on HTML

#446

Post by vidarh »

mythhabit wrote: post #444
vidarh wrote: post #233

Earlier quoted context omitted.

A machine we have to today in isolation with no form of IO are not general Turing machines, but almost all of them do have that and so if you consider them in isolation rather than the full system (which would include all sources of inputs) the halting problem applies. E.g. code to the effect of "while gets() {}" will either halt or not halt depending on the input, but which isn't decidable without knowing or constra…

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.

Re: I'm betting on HTML

#447

Post by guggle »

infogulch wrote: post #442
guggle wrote: post #441

Earlier quoted context omitted.

I actually like htmx (I find Unpoly superior so that’s what I use, but it’s the same general idea) and the example given makes sense, but one should not extend locality of behaviour to the point of sprinkling SQL in templates. I don’t think that’s what the htmx folks had in mind in this essay either, their canonical example being the html/css/js trio. But hey… there’s no better experience than first-hand experience,…

I agree that it's taking the idea of LoB to an extreme that wasn't intended (at least not explicitly) in the essay. But I still don't see why it's a bad idea considering that SQL-level abstractions (views, procedures, etc) are available. What value does adding a layer of application-level abstraction provide? So I have to name and call a function that calls the sql; to what end?

There’s plenty of literature (and debate !) about mvc/mvt (and its numerous variants and interpretations) in the context of web apps. It’s interesting that you challenge the consensus though.

Re: I'm betting on HTML

#448

Post by ric2b »

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…

But if they first need a browser to chew through the usual tens of megabytes of javascript so that they can finally get the 100KB DOM to parse through, they'll be way less efficient (and often run into the token limits) than if the page has some nice semantic HTML with some optional JS for interactivity (that the AI doesn't need).

Re: I'm betting on HTML

#450

Post by jitbit »

Every time I decide it's finally time to use HTML5 native inputs like `` instead of JS-datepickers, I stumble on so many problems.

No "placeholder" attribute support, no "show picker on focus" functionality, etc.

You end up including so many JS/CSS hacks and workarounds that you're back to having a huge datepicker.js file.

Post reply on HN