1. 14

  2. 8

    I really like the idea of extending HTML to support many common UI patterns that currently need JS. In a sense this is nothing new. We have built in calendar picker, button hovers and form validation all of which requires JS before they where included in HTML or CSS.

    This would be the next logical step, allow HTML to make HTTP requests and replace small parts of the page.

    1. 3

      Precisely! Stuff like routing, data binding & http requests should be doable out of the box.

    2. 2

      I would love it if browsers also allowed things like U2F without Javascript. My login pages have zero javascript on purpose, but I would love to offer U2F.

      1. 2

        I don’t think that the goal should be to remove JS from the web but rather make the other fundamental technologies (HTML/CSS) as powerful as they can be without changing their nature.

        If this proposal or other like it is adopted it will extend the capabilities of HTML while remaining a declarative language that encodes UI, data and actions to perform on that data.

        1. 3

          agreed, I’m not saying JS should die a horrible death, it’s far to entrenched now to go away any time soon, and it’s not an abysmal language, though there are definitely some warts.

          I hope this or something like it gets adopted AND I hope the browser(s) continue to expand on what can be done without JS, as there are cases where JS is a bad idea, like say login forms and places where security matters. There are mitigations, like sub-resource integrity, CSP, httponly cookes, etc. But if one can avoid that, then one probably should. There isn’t really anything like veil/pledge or capsicum, etc for JS web code(CSP sort of attempts it), so once you allow execution of JS, your attack surface gets gigantic and very hard to reason about, especially as browsers continually add more attack surface daily. I’m not a browser developer, and I don’t want to have to become a browser developer to reasonably ensure security and I don’t think I should have to, but clearly browser developers disagree.

        2. 1

          The reason why JavaScript exists in the first place is to allow web pages to be rich and interactive without complicating HTML by adding in imperative logic - and U2F is so special-purpose (relative to HTML’s goal of delivering documents) that modifying HTML to accommodate it would incur significantly more complexity.

          1. 1

            U2F has 2 API calls, it’s not THAT complicated: https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html#methods

            The entire point of the OP is they figured out how to make it declarative.

        3. 2

          This is super interesting (unlike Gemini). However it feels the modern Web standardization process is buried under the current browser makers’ agendas and nothing from the outside would make it through. Unless everyone starts using the thing via a JS polyfill so that inclusion it in the browser implementation would become a too obvious thing to do.