Have you ever considered porting solid to deno?

[matthewharwood]

It would be quite the lift but might get some really interesting traction with solid.

http://deno.land/

[ryansolid]

Yeah I honestly have no idea what this would take. Although given Solid is TypeScript and is designed to run in the browser primarily it would just be a matter of running the build tools. I imagine SSR would take some effort given Solid uses DOM apis. But maybe after I get a string renderer working looking into this could be worth it.

[matthewharwood]

https://gist.github.com/matthewharwood/e0bfba1f52fd9831a6c5a243212be5e2

here's a gist of it working with preact

[ryansolid]

Right so that is just a matter of setting up an import map similar to what you would do in the browser. I imagine JSX transpilation would be a bit harder. But the HyperScript and TaggedTemplate literals could work in exactly the same way as your Preact example. Minus the fact that they currently work with DOM APIs so I handle this in node by patching DOM environment with BasicHTML or JSDOM.

Is it common to execute deno with an import map like that? Are people making special builds or different repos for that? In any case I think the JSX transpilation and the need for DOM env on the server are both going to be the immediate challenges here.

[matthewharwood]

It works with jsx out to of the box today... and you can override the tsx config https://deno.land/std/manual.md#typescript-compiler-options

import { serve } from "https://deno.land/std@v0.39.0/http/server.ts"
import React from "https://dev.jspm.io/react"
import ReactDOMServer from "https://dev.jspm.io/react-dom/server"

const s = serve({ port: 8000 })

console.log("http://localhost:8000/")
for await (const req of s) {
  const body = ReactDOMServer.renderToString(
    <div>deno</div>
  )
  req.respond({ body })
}

About import maps ... I hve no idea... i just learned about them today and the reference is pretty small. Moreoever bundling in deno with import maps was released today lol (I had to bundle master up via rust lang run it all)
https://deno.land/std/manual.md#import-maps

[ryansolid]

I need babel. TypeScript can't transform Solid's JSX effectively. They only know how to do React style VDOM JSX. I imagine stuff like that could just work, and truthfully it's at build time so while it would be cool for it to all be deno it doesn't need to be to use deno at runtime. At which point it's much simpler because it would already transformed. Throw in rollup and there is no need for import maps because it's already bundled.

So if the idea is to use deno as direct runtime without a compilation step it can work (hyperscript/tagged literals) but it would never be as good as precompilation.

I guess with precompilation that part simplifies unless your end-user code use node APIs. Solid is built for the browser so itself doesn't have any calls that would make it incompatible minus the DOM calls themselves. So I guess that's the only question. When I get string gen SSR though this should be smooth.

[chasm]

I would really like to see solid usable with deno. I haven't looked closely at this yet, but I believe you can use babel with deno using jspm.io.

https://stackoverflow.com/questions/62058070/how-to-use-babel-in-deno

[sophiabrandt]

There is an open issue on the Babel repo for adding Deno. As @chasm mentions, it seems that you can use babel/core via jspm: babel/babel#11543 (comment)

@SaekiRaku, just a note, I was able to use babel/core via jspm in deno, it works, but you don't have any typesafety.

import babelCore from "https://dev.jspm.io/@babel/core";
import babelSyntaxJsx from "https://dev.jspm.io/@babel/plugin-syntax-jsx";

const result = babelCore.transform(svgText, {
    plugins: [babelSyntaxJsx],
    configFile: false,
  })

I enjoy Solid and it would be great to be able to use it with Deno. ❤️

[ryansolid]

Well that's great. I guess the challenge is node/npm consists of a much wider ecosystem than just the node runtime. Like we use Rollup or Webpack to bundle code for the browser which uses node but never actually runs the generated code on the server. What is more interesting to me, since I compile for the server as well, is does the compiled output have to be different. It writes import statements and it feels like node import statements would differ?

I've done work so that import maps can work in the browser. But admittedly there is just so much I don't understand about Deno,

[andykais]

just to be clear, the babel snippet above is not actually running at compile time, it is transforming code at runtime. It would need an eval block to actually execute. I dont know how this actually fits into your use case, but I believe that you solidjs needs a compile time step in order to function properly

[ryansolid]

Yes. Doing it at runtime just adds unnecessary complexity. From that perspective ignoring the build tools it doesn't seem to far of a stretch to make an output that is Deno friendly. The only node native API solid uses on the server is readable stream. I've moved away from JSDOM and just use string concatting. A simple entry point like the examples in the solid-ssr package would probably do the trick assuming we had a module solution. That being said prebundling would probably remove most of the headache.

So let's say I used Rollup and Babel to make a server bundle what sort of obstacles would you see Deno having?

[andykais]

first, lets lay out what your plan is here. Are you suggesting end users write a server that is only compiled by deno?

[andykais]

If so, I think if you developed solid to be a deno friendly ssr module you could potentially get a working server, but its going to be a bit hacky. A solidjs ssr server ran with deno run cannot do compile time babel compilation. Therefore, you will either need users to run their project through babel (or babel + rollup) before calling deno run or your solidjs compiler will need to read in the jsx files as text files, transform them using your custom jsx transpiler, and then eval them. This is a possibility, but its definitely a little hacky. You could perhaps make this "as fast" as it is in nodejs by create an in memory cache of the outputs so that the server just passes in a filename and can immediately get back the compiled module.

This is assuming you want deno to be the single compilation step though

[ryansolid]

I mean that is sort of the problem I've been trying to figure. Someone asks "consider porting Solid to Deno" at a point Solid didn't even have SSR really. I don't even know what the expectation would be here. Do they want to build with Deno? Do they want it to run SSR in Deno? Are people interested in Deno interested in the fact having native typescript and bypassing the npm ecosystem stuff would be primarily runtime based at which point people might not be interested in compilation? That's an option too just not a great one.