1. 11
  1.  

  2. 3

    It’s interesting to consider alternatives to hydration, but I’m not confident that resumability is the style all full stack JavaScript frameworks should use. I’d really like to see a benchmark for full-stack frameworks. The Lighthouse score that Qwik is hanging its hat on doesn’t measure interactivity performance, only the initial page load. Nevertheless, I thought it was worth sharing here for discussion.

    1. 4

      It’s a technique in which client-side JavaScript converts a static HTML web page into a dynamic web page by attaching event handlers to the HTML elements

      So I guess we’re giving up on the last vestiges of not requiring Javascript for basic functionality

      1. 6

        I think you’re missing some nuance. What you’re quoting is a description of hydration, which is a common technique for blending dynamic front-end functionality with server-rendered content. This article criticizes hydration for performance reasons and proposes Qwik’s “resumability” as an alternative.

        In theory, either style of framework could support fallbacks for browsers that have JavaScript disabled. In practice, it’s uncommon. I think someone’s done it with Nuxt but it doesn’t look like there’s a way to do it in Qwik.

        The goal of both styles is to get the performance of SSR and SSG and the benefit of being able to go beyond basic functionality. The trouble is, “basic functionality” is a subjective term. If you’re talking about a mostly static website with a couple of fairly basic forms, i.e. ones that can be modeled with native inputs, then sure, requiring client-side JavaScript is hard to justify. Once you go much beyond that, you’re going to need client-side JavaScript one way or another.

      2. 2

        I see how registering a single global event handler and bubbling everything up to it helps, since you never register event handlers on elements. But you have to set up routing in that global handler. So I guess I need to have a shadow DOM object that holds the routing table for events based on the event’s target? And the server generates the initial routing table while it generates the rest of the page, and views update it instead of setting event handlers?

        Have I got this right?

        1. 1

          React works same way.

          1. 1

            I did not realize that React doesn’t attach handlers to individual elements. So what is different in what they are saying from React?

          2. 1

            I don’t think you have to set routing up yourself from scratch. Here are the docs, which are admittedly scant on the details:

            https://qwik.builder.io/docs/advanced/containers#routing

            And here’s an example, although it appears to be broken or incomplete:

            https://qwik.builder.io/examples/partial/hackernews-index

            1. 1

              I’m almost certainly not going to use their library. I’m just more interested in how you would implement it. Gracefully having a page start with pre-populated state is an issue I have thought about off and on for a while.

          3. 1

            A global event handler that relies on event bubbling to intercept all events so that we are not forced to eagerly register all events individually on specific DOM elements.

            What about the old way of specifying event handlers in the HTML itself through attributes like onclick with inline JS? In theory, the browser could avoid evaluating that JS until the event actually occurs.

            While a global event handler with its own routing is an effective optimization, it eliminates a technique that some screen readers have used for guessing what was meant to be clickable (or otherwise interactive), in the absence of proper accessibility information (e.g. ARIA role). Yes, it’s better to have the proper accessibility implementation, but dirty workarounds can nonetheless unblock disabled users from getting things done, and IMO frameworks shouldn’t unnecessarily prevent those workarounds.

            I guess the big blocker now for those old HTML event handler attributes is the rise of strict content security policies.

            1. 2

              The biggest problem of those is they mix behaviour/code into the declarative structure of the HTML

              1. 2

                Real-world web development has always been about doing what’s most practical. The rise of HTML5 over XHTML was an endorsement, at least an implicit one, of this pragmatism.

                1. 1

                  HTML5 contains many of the same improvements as XHTML1.1 (and itself contains XHTML5 of course), including the deprecation of framesets, new form features, and proper section/heading structuring. It doesn’t promote using inline JavaScript any more than other HTML specs as far as I can tell?

                  1. 1

                    IIUC, though, HTML5 dropped the distinction between strict and transitional. That signals to me that the old attempts to purify HTML, going back to HTML 4.0, are no longer relevant.

                    1. 2

                      strict and transitional was an upgrade path. HTML5 rips the band-aid off and says “only the new parser is correct, everything else is wrong”