# SSR JS components without Node?

You want to author your components in JS?
You want to render those components server-side?
You must run JS on the server.

It's as simple as that, right? Well, yes. That's the principled conclusion, anyways.

But lets assume running NodeJS on the server is impossible. We still want to maximize the developer experience while maintaining uncompromising performance - and that means SSR is non-negotiable. Without Node, we're talking about building cross-platform solutions. Write once - run in multiple languages.

Your natural next stop is a templating language. These will obviously be restricted - only letting you express what is possible in their respective various backends. Maybe you even consider a full-fledged cross-platform system like [Kotlin Multiplat](https://kotlinlang.org/docs/multiplatform.html#kotlin-multiplatform-use-cases) or [Flutter](https://flutter.dev/).

The downside of both of these is that you probably don't want **all of your code** in these systems, and bridging the gap back to native JS can be cumbersome.

But you *really* like JSX. That's basically a templating language, right? Perhaps we can transpile that just enough to render on the server. Let's pursue this idea.

### The role of JSX

First, let's be clear - JSX is JavaScript + XML syntax. It **is** possible to hijack the syntax to perform complex compiler transforms while reusing the nice type checker and IDE features. That's what SolidJS does. We will keep this in mind when considering solutions, but know that JSX still JavaScript, and it does not fundamentally change the equation. Everything *inside and out* of the XML tags is still arbitrary JavaScript.

In the case of SolidJS, they are still running your user-authored JavaScript; it only moves it around. It's not transpiling it to another language.

### The Fundamental Problem

A component is a black box. Props in, DOM out. We don't know what occurred within that function to produce the DOM it did. Without recovering that information, it's impossible to reproduce the output in another language.

If your idea is to transpile, you are essentially attempting to extract this information from the AST. This can work in the simple case, but without the ability to actually evaluate the JavaScript, you'll always be limited to what is statically expressable. No computing constant values, local state, classes from other files, etc.

That got me thinking - what if we could collect the relevant computations at runtime, and statically render anything that doesn't change between initial renders (like local state and globals) at build time? This sent me down a rabbit hole exploring a desperate alternative.

These constraints may seem absurd, but sometimes constraints spur innovation. Even if these requirements are too esoteric to make this work generally relevant, I hope we can still learn something in the process.

This led me to the idea of **[change-sourced values](https://hackmd.io/@3yCr5XvoTZSrmFitduJ1gw/B1Do2u4l6)** and how they might enable a novel alternative in **[change-sourced values for cross-platform SSR](https://hackmd.io/@3yCr5XvoTZSrmFitduJ1gw/BksFxkUxp)**.