React Suspense (react.christmas)

They have been reluctant to discuss the details there, I guess it's because the details might change before the production release so they don't want to spell the actual inner workings out just yet.

They’ve already been banned from posting these to a site similar to HN.

Isn't the point that the 200kb is static code that can be served immediately, while the rest can't? Regardless of whether the remaining 1.8mb is built on the server or client, it still isn't available "right now"

There's a nice middle ground.

In the app I work on very little is included at start up. It's literally just the components for the first screen you see. Then it pre-loads more components whenever the browser is idle based on what the user is likely to need. If the user does something that needs a component that isn't available yet it lazy loads it as usual.

If you only use lazy loading the user has to do something that needs a component and then wait until it's available. The strategy I use means there's an additional phase that utilises the time when the browser is idle, so it's much more likely everything is available before it's needed. It works well.

Freudian slip? Sounds about right though. The usability of huge portions of the web has deteriorated markedly in the last few years due to the over use of client-side frameworks.

Browsers should have an option to let you send click events to what was under the mouse 200ms before it was registered. But it would be a colossal PITA to implement.

import Component from 'component'

instead of lazy loading it ?

If you do server-side rendered pages, you still have to make the round-trip to get the next full HTML page. Switching to Vue or Svelte or JSPs isn't changing that.

Have you had any particular problems / downsides of using it?

And lastly have you considered ReasonML instead? That's the other thing I've been following closely but it never feels quite ready to start working with, for someone not well versed in FP that is.

You'd still query and display your data in the same way. Suspense will just be a wrapper around the component displaying the data.

In most apps I've worked with, either (1) or (2) doesn't hold.

(1) The child is in control of the spinner:

    <Parent>
        <Child />
    </Parent>

    Child() {
        if (!data) {
            return <Spinner />
        }
        return <Data />
    }

    <Parent>
        { state.data
          ? <Child data={data} />
          : <Spinner />
        }
    </Parent>

    <Parent>
        <Suspense fallback={<Spinner />}>
            <Child />
        </Suspense>
    </Parent>

Suspense then seems to make it easier to parallelize the data requests, and have a spinner at the lowest parent with a child waiting for data.

If you try to make nested components load at the same time consequences can be unpredictable, suspense lacks fine grained control so it is basically a convenient shortcut, same as react state mixins were at the time.

That said, React Suspense looks like it's an improvement of a common pattern, simpler to write and understand. Perhaps it's achieved by pushing the complexity "down" into the library, instead of letting the user manage it every time.

My hope is that one day, all the lessons from React will be incorporated into browsers themselves, to clear the field for saner web development. Seeing how Web Components is going though, I'm not holding my breath..