Forem: Ibrahim ben Salah

JavaScript SSR made easy

Ibrahim ben Salah — Tue, 21 Feb 2023 18:24:40 +0000

Server Side Rendering (SSR) in any JavaScript framework, with preservation of the reactivity behavior of the application, depends on the ability to hibernate the runtime state (at server), so that it can be later (at client) hydrated back to its previous state.

Video

https://www.youtube.com/watch?v=HXmWYlhQCeU
(PS, this is my first video in a decade, I hope my coding skills make up for the video quality ;)

Source code

kitchen-sink

The following code snippet is a basic SSR simulation of how hibernation and hydration could work.

// ~/pages/hello-world.ts
export default function server() {
      console.log("Hello World");

   function client() {
      console.log("Hello World");
   }

   return client;
}

I was hoping I could use an existing solution for a UI library that I wrote called @xania/view but all solution that I could find are specific to other UI frameworks.
So I decided to build a UI agnostic solution. It is extremely hard and it evolves writing code transpiler/compiler but I did it anyway and I am hyped to share with you the results.

Introducing `vite-plugin-resumable`

This plugin is a UI framework agnostic solution for hibernating and hydrating javascript closures. You can say we found a way to serialize functions. It is the foundation for SSR feature of @xania/view but it can be used with any other UI library.

Continue reading to learn how to setup your project or visit github here for full working source code of the example.

Setup

Currently we have only support for vite projects.

create new vite project

npm init vite my-vite-app
install resumable package

npm i vite-plugin-resumable
next step is to add the plugin to your vite configuration

import resumable from "vite-plugin-resumable"

  ...
  plugins: [
    resumable();
  ]
  ...

By default, this plugin looks in pages folder for all files with .tsx extension and creates a server entry for each file found.

So go ahead and create a page called hello-world.tsx script in pages folder


// ~/pages/hello-world.ts
export function view() {
   console.log("Hello server");
   const counter = new State(1);
   counter.subscribe({
     next(value) { 
       console.log("counter", value);  
     }
   });

   function client() { 
      console.log("Hello client");
      document.body.addEventListener("click", 
          () => counter.set(x => x + 1));
   }

   return client;
}

The resumable package will automatically infer the client code from the result of the server entry function.
In this case the client code is generated from the function declaration of client. This function will be executed on client and will use the hydrated instance of the counter object, including the registered next-observer.

Let's start the application and see this in action

npm start

Open a browser and navigate to http://localhost:5173/hello-world

// terminal output
Hello server

// browser output
Hello client

Clicking on the document will increment the counter and trigger the observer which will print current value to the console of your browser.

// browser output
counter, 2

Conclusion

This plugin streamlines the development process by simplifying the code structure required to make a web application that can be executed on both the server and client side.

This is currently an alpha (aka proof of concept) version to verify usefulness of this approach. So far, this plugin captures the generic features of SSR so that any UI library could benefit from it.

We optimize the amount of client script that is sent to the client, but in the future we will be looking for more opportunities to optimize the state data (e.g. if we only access a property of an object then we may want to sent only the value of that property instead of the whole object.

next is to try this out with React and I will also build an adapter for @xania/view

SSR in javascript is hard

Ibrahim ben Salah — Mon, 02 Jan 2023 22:57:36 +0000

I started working on Xania Web's Fastest JSX based Library since back in 2014.

Before that I was 90% backend 10y .NET developer and my focus has shifted since then more towards JavaScript. And because of my background I am hyped about the new trend shift towards backend, but...frontend has evolved and we don't want to loose the capabilities of our beloved libraries in favor of SSR. but it's hard.

SSR is mainly hard because of serialization of runtime state. Part of it is the need for javasript bundler at runtime. Basically we need to examine the data we are sending to the client, determine what types are used, track back where those types are defined in code (which I am not sure is even possible), create a hydration script which imports these types. And, it get even hard if we also want to serialize closures. After that framework specific handling can take over...which is relatively easy to do.

There are a couple of framework solutions with support for hydration (rehydration/resumability/lazy/partial,etc....) like SvelteKit, Next.JS, Qwik, Astro, Marko, etc... but it is sad to see that none allows an incremental / progressive adaption. They all are coupled to either a view library, routing or toolchain, I just want to use Vite and Xania and add Hydration to the mix.

Here is the challenge I am taking on:

Is it possible to statiscally generate rehydration script at compile time? I am thinking of a solution that is using rollup transform plugin,
Or otherwise, create a serializer, runtime bundler and hydration script.

I have little to no experience in this area, so any suggestion are very welcome.

Immutability is overrated

Ibrahim ben Salah — Tue, 20 Dec 2022 23:59:49 +0000

Immutability fine, but not always, right?!

As the author of Xania a javascript UI library I ask myself this question countless times.

Immutability as an unbreakable rule does not make sense to me and I have been thinking about this for years, Could you help me make sense of it? I've heard all the popular arguments but I am still not convinced, let me explain..

Sure I do agree on the importance of immutability, and to be very precise I dont argue that, but disallowing immutability always and in all cases feels like a handicap in programming languages or in some case libraries in language like JavaScript where mutability is possible but make it inconvient to work with mutable data.

Pure functions have side-effects

I found this article that inspired me investigate this more

take for example the functions f and wasm

function f(x, y) {
  return x + y;
}

function wasm(esi, ecx) {
  let eax = ecx;
  eax += esi;
  return eax;
}

It is generally accepted that f is pure, and it is. But wasm mutates the variable eax so it is generally accepted to say that wasm is inpure, but is it really?
Suprisingly wasm is kind of how f would look like if it was compiled to WASM. We can also image how wasm can be decompiled back to f, so without going deep into theory we can say f and wasm are the same, correct me if I am wrong but I think this is called isomorphic in category theory, because following rule applies...

| f o wasm == wasm o f == id

Despite the fact that wasm has mutations we should consider it as pure just as f because they are the same.
In general, a mutation does not always conclude if the given function is pure or not.

Rules for Mutability

Like in the article above by John D. Cook, pure functions only make sense at certain the level of abstraction. sounds like we can agree on it but this raises the question, what are pricesly those levels where we allow mutations in a pure function? Is the level boundary defined by the language runtime?
Is it thinkable to extend the mutation to the user code (even in haskell) if rules of mutability are satisfied?

This is where my brain starts to hurt. What are your thoughs and do you know if there are resources on this subject?

If I would rewrite React from scratch it would look like this

Ibrahim ben Salah — Thu, 15 Dec 2022 18:47:07 +0000

Keep JSX and functions

function MyComponent() {
   return <span>Hello, React<span>;
}

Keep useState, but add full HTML syntax support, use click not onClick, class not className

function MyComponent() {
   const [count, updateCount] = useState(0);
   return <button click={_ => updateCount(count + 1)}>
      Count: {count}</button>
}

useState with objects

function MyComponent() {
   var me = useState({ firstName: "Ibrahim", lastName: "ben Salah"});
   return (
      <div>
         fullName: {me.get("firstName")} {me.get("lastName"})
      </div>
   )
}

true first class support for async/await and promises, not the fake `use` hook

async function MyComponent() {
   const ditto = await fetch("https://pokeapi.co/api/v2/pokemon/ditto")
      .then(e => e.json());
   return (
      <div>
         {ditto.name}
      </div>
   )
}

Add support for async iterator

Not sure if one would expect this to end up with one final div and auto dispose all the previous, or all div's should be retained

async function *MyComponent() {
   for (const delay of this.delays) {
      await this.wait(delay);
      yield <div>`Delayed response for ${delay} milliseconds`</div>;
   }
}

Add support for observables (e.g. rxjs)

function MyCounter() {
   const time = timer(0, 1000).pipe(map(() => new Date()));
   return (
      <div>Current time: {time}</div>
   )
}

Conclusion

Do you agree on using the platform instead of inventing dubious hooks with many gotcha's? Or do you think it's an impossible idea? If the latter then you would be surprised to hear that the fastest UI library in the krausest js framework benchmark is already built with these concepts, it's called xania (named after a small district in Morocco).

benchmark results:
https://krausest.github.io/js-framework-benchmark/2022/table_chrome_104_windows.html

benchmark code:
https://github.com/xania/krausest-js-benchmark/blob/main/src/app.tsx

Forem: Ibrahim ben Salah

JavaScript SSR made easy

Video

Source code

Introducing vite-plugin-resumable

Setup

Conclusion

SSR in javascript is hard

Immutability is overrated

Immutability fine, but not always, right?!

Pure functions have side-effects

Rules for Mutability

If I would rewrite React from scratch it would look like this

Keep JSX and functions

Keep useState, but add full HTML syntax support, use click not onClick, class not className

useState with objects

true first class support for async/await and promises, not the fake use hook

Add support for async iterator

Add support for observables (e.g. rxjs)

Conclusion

Introducing `vite-plugin-resumable`

true first class support for async/await and promises, not the fake `use` hook