[Feature]: Server Side Rendering Support For Languages, SSR Everywhere

[wakaztahir]

@ryansolid

Usually people have servers written in different languages, Other than javascript / typescript. To serve my website on different servers in different languages, I could create a static build and copy the public folder and serve that directory under a route.
This works, However not for server side rendering. Because everything is loaded on client side.

This got me thinking, and usage of template engines in golang, gave me a great Idea. What if we can server side render our app everywhere.

Template engines work by replacing values inside the template. What we need to do is generate a file for every route in that language. That declares a function taking an instance of the object and making references and replacing the values in the string

for example, Our source is following

interface Courses {
   title : string
}
export function routeData() : Course[]  {
    const [res] = createResource(async () => {
        return getPublicCourses().catch((e) => {
            console.log("ERROR GETTING PUBLIC COURSES", e)
        })
    })
    return res()
}
export default function Home() {
    const data = useRouteData<typeof routeData>()!
    return (
        <h1>Courses</h1>
        <For each={data}>
        {course => (
             <h2>{course.title}</h2>
        )}
        </For>
    )
}

For the following source, generated template file in golang would look like this

struct Course {
    Title string
}
func GetHomeRoute(model Course[]) string {
     str := ""
     str += "<h1>Courses</h1>"
     for _, course := range model {
          str += "<h2>" + course.Title + "</h2>
     }
     return str;
}

This is a basic example, Users can use useLocation and Javascript expressions over a property present inside "model"

For useLocation the variables could be added to the model, The model could be renamed from "Course" to "InjectionModel", Containing inside it all the properties of request required

For javascript expressions, they could be generated as is, most languages differ slightly in syntax, Which could be improved later on

Ofcourse generating templates for multiple languages like this, requires a lot of effort, I say only a singe language implementation is required and other implementations could be written by users who are willing to contribute.
This is a lot of work and I don't want you to say no because of that.

If there was a single implementation of a JavaScript template, I would write other languages that I require myself. Because generating code is not that hard, The hard part is interacting with API's I don't understand. So a single implementation can serve as a reference and that's all that's needed. A single bare bones not that good implementation of template generation.

Motivation 🔦

I have a GoLang server, I need to install NodeJS on a different container, I also need to make requests server side to my other container which causes some overhead.

If this feature would be implemented, I can write servers in any language I desire. I can server side render everywhere I want. All this without overhead of making http calls or RPC calls.

[ryansolid]

This requires changes all over the map. It starts with generating the right compiled output for other languages. I've thought about this path somewhat, but our templating is so much more than templating. JS interpolation happens all over the place. It isn't necessarily impossible. Solid's client and server compilation are different, so picturing a different server compilation isn't completely impossible. But a lot of Solid isn't compiler analyzable so we actually have a different server runtime (one without reactivity). Like the <For> component in your example isn't special from a compiler standpoint, it could be any component. So we have a different runtime for client and server <For>.

I don't think this issue belongs in SolidStart, but I'm not sure where it belongs. This feels like a discussion topic for Solid in general. I'm going to try to move it there. But it might take a few hops.

[AlphaNecron]

You can use sockets to mitigate overhead, but its flexibility is still kinda bad, if only there’s a way to embed an entire JS engine into a Go program lol. That seems illusory as there is no working implementation of such engine tho.

[AlphaNecron]

Assuming a working JS engine does exists (like goja), language architecture would be another hinderance. Since JS is a single-threaded language with literally no thread-safety precautions, using it in a concurrency-centric language like Go may pose various issues related to race-condition and performance which can't simply be fixed with some arbitrary workarounds. So using UNIX sockets should be the best approach at the moment. Maybe we can use something like hooks to dynamically mutate stuff on the Solid's side? Sounds sensible enough.

[wakaztahir]

I went on to create my own programming language that will solve this issue, It's called Chemical

https://github.com/chemicallang/chemical

The language would allow to generate normal html, templated html or a server directly. It may not allow you to write a server in golang, but we currently have a goal to generate C / C++ headers so our language can be called from other languages, chemical may also allow to generate bindings for Go, Rust.

However mixing languages is pretty nasty when it comes to servers and frontend, It's best to write a server and frontend in the same language, but people usually have a need to mix languages, because one language provides features that the other doesn't, for example writing the frontend in NodeJS makes sense due to support for tooling like JSX, nested html, importing stylesheets directly, however the backend doesn't because it doesn't compile to a single executable, It's not native and is not performant enough. Not every frontend can also be just a static output that could be served on different routes. It's not going to solve that, But focus more on providing all the features required for creating proper websites in a language that's native, fast.

[AlphaNecron]

Nice, but you'd better make a native implementation for Go since CGO is pretty dumb lol.