9 Matching Annotations
  1. Nov 2020
  2. Mar 2020
    1. Javascript, APIs and Markup — this stack is all about finding middleground from the chaos of SSR+SPA. It is about stepping back and asking yourself, what parts of my page change and what parts don’t change?

      JavaScript, APIs and Markup (JAM Stack) - middleground between SSR + SPA.

      Advantages:

      • The parts that don’t change often are pre-rendered on the server and saved to static HTML files. Anything else is implemented in JS and run on the client using API calls.
      • Avoids too much data transfer (like the hydration data for SSR), therefore finds a good tradeoff to ship web content
      • Allows to leverage the power and cost of Content delivery networks (CDNs) to effectively serve your content
      • With serverless apps your APIs will never need a server to SSH into and manage
    2. Somewhere on this path to render pages on the fly (SSR) and render pages on the client (SPA) we forgot about the performance of our webpages. We were trying to build apps. But the web is about presenting content first and foremost!

      Website performance break with Client-side Rendering (SSR) and Single-page App (SPA)

  3. Jan 2019
    1. the best performance is achieved by calling registerApplication immediately, but calling start after the AJAX request is completed.

      important note (and including paragraph) regarding how to achieve best performance when loading multiple apps (which is what single spa does...). Basically, registerApplication() first, but start() only after doing some other work, maybe like painting initial stuff on the web page.

    1. When called, this function should look at the URL to determine the active route and then create DOM elements, DOM event listeners, etc. to render content to the user

      this is the purpose of the mount function

    2. except that it doesn't have an HTML page

      I think they mean that it doesn't have its own html page with head and body section. Instead, it has only its own section of the DOM, without those 'upstream' parts.

    3. A reference to the singleSpa instance, itself. This is intended to allow applications and helper libraries to call singleSpa APIs without having to import it.

      important. can it be useful to share information between different apps called by single-spa? I know there are other recommended mechanisms for this in single-spa world but just a thought - could be useful for that.

    4. pass a reference to a common event bus so each app may talk to each other

      this seems like a recommended way to share events and data between multiple apps in one single-spa instance. i wonder how technically this should be implemented

  4. May 2015
    1. Medium's SPA navigation seems to foil Hypothes.is. I got back to your original Medium post by hitting the back button from a couple levels deep in Medium responses. Notice there are no Hypothes.is comment indicators:

      screen shot of Medium article Missing Hypothes.is comment indicator