Renamed the "Sign In" button on the website to "Launch App". That way there’s no need to check if the user is authenticated to show the username.

IOW, I can serve the website statically. So no iframe is needed for dynamic parts, or allowing the cookie from a subdomain on the www.

Prefetching critical API data on the index.html of an SPA instead of using SSR.

https://github.com/ericfortis/aot-fetch-demo

A set of Wera lasertip screwdrivers.

Or, a Knipex Cobra pair of pliers.

TIL Lasertip:

https://www.wera.de/en/tools/highlights-great-tools/lasertip...

I love my wera kraftform

I'm experimenting with recreating the whole DOM tree like this:

  function render() {
    restoreFocus(() => 
      document.body.replaceChildren(App()))
  }

  function App() {
    return (
      createElement('div', { className: 'App' }, 
        createElement('h1', null, 'Hello, World')))
  }

  function createElement(tag, props, ...children) {
    const elem = document.createElement(tag)
    for (const [k, v] of Object.entries(props || {}))
           if (k === 'ref')        v.elem = elem
      else if (k === 'style')      Object.assign(elem.style, v)
      else if (k.startsWith('on')) elem.addEventListener(k.slice(2).toLowerCase(), ...[v].flat())
      else if (k in elem)          elem[k] = v
      else                         elem.setAttribute(k, v)
    elem.append(...children.flat().filter(Boolean))
    return elem
  }

`restoreFocus` is here:

https://github.com/ericfortis/mockaton/blob/main/src/client/...

Results so far:

Rendering the whole DOM tree (instead of VDOMs) is a fast process. The slow part is attaching (committing) elements to the doc. For example, I have a test of 20,000 elements which takes <30ms to render, while attaching them takes 120ms.

Since the performance is mainly bound to the commit phase, with a DOM merging library, or hopefully, if we get a native API such as `document.replaceChildren(...App(), { merge: true })`, this approach could be better.

Caveats:

Although it restores focus, that's not the only thing we need to preserve, we also need to preserve scroll position and cursor position.

So to work around that, I still have to step out fully declarative, by just replacing the part that changed. For example, here I had to do manually mutate the DOM:

https://github.com/ericfortis/mockaton/blob/main/src/client/...

Looks an awful lot like https://github.com/jorgebucaran/hyperapp

Both are based on the signature of React.createElement. JSX gets compiled to something like that.

https://react.dev/reference/react/createElement

I have hope, but websites after Flash became boring.

Here’s a screencast of one of my favorites in 2009:

https://x.com/efortis/status/1879712687896289471

Pfft! My website isn't boring :P

I don't think the issue is lack of features, because audio context and canvas2d are pretty good for making things shiny and nice. The issue is pretty much the rest of the DOM that has quirks everywhere if you want to use it that way. CSS3D as a scene graph is also kind of half baked, and not really integrated well with animations, and well, also too painful when it comes to scheduling and timing and chaining any transition.

SVG animations are also only half-ass implemented among browsers, so that's not really a reliable alternative.

What I liked about the Macromedia suite was the integration cross-IDE, where dreamweaver worked really great together with Flash and vice versa, and where flash was able to load HTML content, just in a more animated manner.

I mean, this was when XHR and AJAX was the "modern" thing in web browsers. Adobe could have dominated the mobile market if they would have decided to make it an open standard. Flash was really a decade ahead of its time.

I agree, the problem isn't tech capabilities.

People were more creative, and Flash had great UI/UX.

---

More 2009 flash websites:

https://www.youtube.com/watch?v=85UL3HhNq6Q

https://www.youtube.com/watch?v=zoUnzmaAV08

Experimenting with native css modules. They will land in Firefox in two weeks

https://github.com/ericfortis/mockaton/issues/2

another trick is adding speculation rules on MPA sites. so when you hover over a link the page gets prerendered. For example, my initial page takes ~80ms, but navigating to other pages take 20ms

    prerender: [
      {
         where: { href_matches: '/*' },
         eagerness: 'moderate'
      }
    ]

That doesn't work on Safari, FF, and Brave, but you could do something like this:

https://github.com/ericfortis/mockaton/blob/main/www/src/_as...

Most adblockers/privacy extensions disable this.

uBlock Origin does it by default for instance.

Do they block <link rel=prefetch> completely?

On Brave, the workaround on that linked snippet bypasses their blocking.

Well, uBlock Origin sets network.prefetch-next=false and network.dns.disablePrefetch=true, so yes.

The reason is that browser prefetching may hit URLs that were intended to be blocked.

Scanned mine:

https://crxplorer.com?extensionId=babjpljmacbefcmlomjedmgmke...

It's getting a 20% safety score on CSP, saying:

> The complete absence of a Content Security Policy (CSP) is a critical security vulnerability…

But absence means that it uses the default, which is fine in my case:

https://developer.chrome.com/docs/extensions/reference/manif...

---

And 65% on permissions, (it uses "download") and it says:

> …its necessity is unclear without an overview of the extension’s specific purpose.

but its purpose is stated

I was reminded of this MythBusters episode: Tesla's Earthquake Machine

https://www.youtube.com/watch?v=LHsHiKtjoag

Same here. I worked as a sign maker in high school and I always wanted a CNC.