Currently Prism compiles functions for rendering components and pages. These functions are built up of string concatenations so are incredibly simple and fast. These also feature string escaping etc... But they are very generic and simple to create as most of the work is done during templating.
But Prism only compiles these functions for JS engine use. Many other server side rendered sites use other backend languages such as golang, rust, ruby, python, c#, c++, ... . Which is a problem for building isomorphic sites as manually adding ssr templating desyncs the process of client side and server side views and templating. There are currently ways of calling JS code in golang and such and some have used that to achieve ssr of react apps. But as Prism is a compiler and there is not lot of complexity in the render functions I don't think it would be to hard to add the ability to output native golang, rust, ruby... functions for use with a backend framework.
This would be beneficial:
Enable isomorphic rendering for other languages that are used because they are the language currently used for a codebase or have packages that do not exist in the JS ecosystem
Enable isomorphic rendering for more performant languages to enable super fast ssr and reducing server latency and strain
Three current considerations:
Some languages have there own templating library/syntax would Prism compile to those? Golang has its own html templating language and C# has .cshtml. These seem to exist for DX, ease of use and compile time checking. However Prism offers all of this during compilation so they are not needed and add additional nuance. And prism output is designed to be run rather than analysed.
There is more that just syntax in the difference between programming languages This is very true. Functions, imports, string, concatenation and objects/structs exists in nearly every languages but actual runtime functions vary significantly in naming and existence. For example Intl.NumberFormat class does not exist in any other language in form or name. So sending it straight over to python would not work.
But there could be something like:
@returnValueIfUnderNonJSBackendLanguage(`f"{x:,.3f}"`)
function formatNumber(x: number) {
return new Intl.NumberFormat('en').format(x)
]
That during ssr compile time could do some switching of the return expression ...
Interfaces / type definitions Currently if you build a Prism application with backendLanguage as ts it will include all the type information in the .ts server render function. (this works becomes of some specific things in chef and the fact ts is a superset of js. the ts info exists in the server module ast but is never rendered out...). It should be quite simple to transpile the interface ast (struct for golang and rust). Howerver actual data types do not exist across languages. This should be simple for some things like arrays. However types like number do not exactly map over. Whereas number exists in ecmascript, in rust there are u8, u16, i8, f64, .... and none of the quite match up. I think for this case it would be assume f64 and then you might have to do some casting when using this function. This problem is similar to the last point.
This does sound quite complex to implement but I think it would be quite simple. Just implement a fraction of syntax into chef (no parsing just render() methods) and add some step for transpilation. There would need to be a little work to implement the structure to build to non js based languages but once that is done then I think adding support for a language would be simple (especially after the first language support is implemented).
Implementing this would follow a common development characteristic of Prism where implement support for basic templating and add more complex templating later.
Currently Prism compiles functions for rendering components and pages. These functions are built up of string concatenations so are incredibly simple and fast. These also feature string escaping etc... But they are very generic and simple to create as most of the work is done during templating.
But Prism only compiles these functions for JS engine use. Many other server side rendered sites use other backend languages such as golang, rust, ruby, python, c#, c++, ... . Which is a problem for building isomorphic sites as manually adding ssr templating desyncs the process of client side and server side views and templating. There are currently ways of calling JS code in golang and such and some have used that to achieve ssr of react apps. But as Prism is a compiler and there is not lot of complexity in the render functions I don't think it would be to hard to add the ability to output native golang, rust, ruby... functions for use with a backend framework.
This would be beneficial:
Three current considerations:
.cshtml. These seem to exist for DX, ease of use and compile time checking. However Prism offers all of this during compilation so they are not needed and add additional nuance. And prism output is designed to be run rather than analysed.Intl.NumberFormatclass does not exist in any other language in form or name. So sending it straight over to python would not work.But there could be something like:
That during ssr compile time could do some switching of the return expression ...
backendLanguageastsit will include all the type information in the.tsserver render function. (this works becomes of some specific things in chef and the fact ts is a superset of js. the ts info exists in the server module ast but is never rendered out...). It should be quite simple to transpile the interface ast (structfor golang and rust). Howerver actual data types do not exist across languages. This should be simple for some things like arrays. However types likenumberdo not exactly map over. Whereasnumberexists in ecmascript, in rust there areu8, u16, i8, f64, ....and none of the quite match up. I think for this case it would be assumef64and then you might have to do some casting when using this function. This problem is similar to the last point.This does sound quite complex to implement but I think it would be quite simple. Just implement a fraction of syntax into chef (no parsing just
render()methods) and add some step for transpilation. There would need to be a little work to implement the structure to build to non js based languages but once that is done then I think adding support for a language would be simple (especially after the first language support is implemented).Implementing this would follow a common development characteristic of Prism where implement support for basic templating and add more complex templating later.