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.

[andykais]

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

I think the first part of this is true. I think deno has a lot of interest because a lot of people find it more ergonomic than node, and because for most cases, users do not need to set up build systems. So, there has been a lot of interest in porting frameworks that have complex build systems (like react, solid, svelte, vue) into deno. The problem though, is that these frameworks do require build systems.

I hate advocating for waiting, but there is a ticket in deno for allowing external compilers denoland/deno#1739. This is really the ideal case, where you can hook into deno's build system and it will handle caching and executing the compiled javascript for you. If this is also your ideal case (and for anyone reading this), I would recommend giving the issue a 👍 so the devs see the interest.

If you are interested in getting solid off the ground in deno now, you probably could, but youre going to have to maintain your own build system within solid, and handle whatever requirements your users have as well (do they want TS in their jsx files? Do they want babel macros? Do they want webpack module loaders?) I imagine it would look something like this:

const solidModules = solid.ssr({ index: 'index.jsx' }
console.log(solidModules.index(props)) // outputs an html string

[edit] I just saw your runtime options https://github.com/ryansolid/solid#no-compilation which is definitely something you can drop into deno for.

[ryansolid]

@andykais Thanks so much. That is the sort of perspective I was looking for. I agree for compilation we wait. My tact with Solid to date has been use what is already there because as an individual with a small set of contributors I'm not going to rebuild the world. The use of Babel and JSX are testaments to this approach where I was able to move much faster at the beginning than having to build my own template system.

I think if someone wants to go the no-compile route in the meantime I would definitely try my best to support them in that effort, but I will need them to take the first step and do some exploration to see what works and what doesn't. This issue seems prudent to wait to see where things land. As much as it would be nice to get ahead of it, I'm not going to be able to spearhead this.

[andykais]

Totally valid. You have built a wonderful library here that does things in an extremely efficient manner, but also has very little friction to adopt. I think familiarity is a fine pillar to stand solid on top of. Im sure this conversation will come up again when deno has a better answer on external compilation. Ill be interested to see how we can solve it here then 🙂

[shadowtime2000]

I think if you have support for SWC (ryansolid/dom-expressions#10) you could then run it through deno_swc and it should work.

[shadowtime2000]

It seems that deno_swc doesn't have full support for the plugin system of Node's SWC so that may not work. Probably the best way would then have to be just take the AST and manipulate in some way without a visitor API, or build a visitor API for it.

[ryansolid]

@shadowtime2000 That sounds promising. On the list so if that gives a direction here I think that would be great. I was worried custom plugins would be a non-starter but that would be incredible.

[aadamsx]

Wish we could see a Deno integration!

[chasm]

I'm using babel and the jsx plugin, calling it from node despite my app being in Deno. Sigh... Considered using the solid jsx but I see what you mean. But I'm a bit confused... Deno is TypeScript, isn't Solid? Is it that other libraries are missing? TSC just passes the JSX through...

[trivikr]

I see that

• Ryan has now joined Netlify.
• Netlify Edge Functions use Deno.

Is it just me, or first-class support for Deno in Solid is coming soon? 🤔

[andykais]

My work’s focus on open source means I get to continue collaborating closely with other projects shaping this new world. Projects like Marko, Qwik, Astro, Vite, Deno and so many more, pushing the limits of hydration, compilation, reactivity, and routing, and working with these teams to make these futures a reality.

🤞

[yavko]

I don't know if this is a sign or anything, but a bunch of solid packages were just added to deno.land/x/ with no releases

[wrnrlr]

I've been using Solid on Deno and it's workable as long as you don't use JSX, just do hyper dom expressions instead

[yavko]

can't you also use template literals?

[wrnrlr]

Thats should work too but I don't like this solution once you use multiple nested components. This leads to a very verbose syntax.

[yavko]

true

[andykais]

just unifying some discussions here: solidjs/solid-start#458
solidjs-start has some deno issues as well

[Hubro]

I just started a blank Solid Start project using the Tailwind template. My node_modules folder is 180 MB and contains 10 000 files, right off the bat.

I'm sick and tired of having this gigantic hulking folder in all my projects. It kills my Dropbox and it complicates a lot of my tools. (For example, I have to alias tree to tree -I node_modules to prevent my terminal from exploding.)

If Solid / Solid Start could be used without NodeJS, that would be such a relief.

[aifrim]

@Hubro 180mb is small.

Plus, don't use Dropbox to sync node_modules 🤣

[Hubro]

180 MB for a blank project is not small, it's atrociously huge. Are you joking?

I'm not using Dropbox to sync node_modules, I'm using Dropbox to sync my projects. Unfortunately NodeJS projects must have a node_modules folder, and it must be inside the project directory. It can usually be symlinked out, but this causes weird bugs with some packages.

[johanmontorfano]

It's kinda weird that you have a 180MB node_modules directory, even if you use Solid. I have a huge project based on Solid and Tauri and it's node_modules is 181MB.

To use Solid with Deno, you could start looking here: #873

[danieltroger]

You should maybe look into using yarn berry (an alternative to npm) which doesn't have node_modules anymore (it works with a virtual filesystem and only has a few small zip files on the actual file system) if you want to get rid of the bloat.

https://yarnpkg.com/features/pnp

[lino-levan]

It feels like getting solid with JSX working on Deno shouldn't be a huge task with CDNs.

Currently, this just works out of the box for Deno:

import * as React from "https://esm.sh/react@18.2.0"

function MyComponent(props: {name: string}) {
  return <div>Hello {props.name}</div>;
}

console.log(<MyComponent name={"Dev"} />)

If I set the typescript JSX settings in my deno.json to:

{
  "compilerOptions": {
    "jsx": "react-jsx",
    "jsxImportSource": "solid-js/h"
  },
  "imports": {
    "solid-js/": "https://esm.sh/solid-js@1.6.11/"
  }
}

then

function MyComponent(props: {name: string}) {
  return <div>Hello {props.name}</div>;
}

console.log(<MyComponent name={"Dev"} />)

doesn't give any type errors but it crashes at runtime with this error:

$ deno run -A test.tsx
error: Uncaught SyntaxError: The requested module '/v110/solid-js@1.6.11/deno/web.js' does not provide an export named 'assign'
    at <anonymous> (https://esm.sh/v110/solid-js@1.6.11/deno/h.js:2:20)

Any ideas on why it claims to not provide an export named "assign" @ryansolid?

[ryansolid]

My only guess is it is getting the server version. Since we run deno deploy we typically map deno imports to server versions and we don't support SSR with our HyperScript version currently as it generates and works with DOM nodes. There is some other complexity there as well as we'd need to use a slightly different version for client Hydration as well. Given the immense benefits of our custom transform this just hasn't been a priority.

[JLarky]

I played with Astro on Deno a bit, and while it doesn't mean that "Solid is ported to Deno now", but you can use Deno (without installing node) to run astro dev, astro build and deploy it to Deno Deploy. So I have high hopes for new SolidStart to work without node :)

https://twitter.com/JLarky/status/1667384897030483968

[atk]

This was asked a lot of times already. Solid-start has an adapter that deploys to deno: https://github.com/solidjs/solid-start/tree/main/packages/start-deno.

[benatkin]

This was asked a lot of times already.

The question was asked on Apr 5, 2020.

[JLarky]

more importantly, the question is not about the Deno adapter but about porting Solid to Deno. Let's look at the gradient:

• running build in node to produce output compatible with Deno (you are here <)
• running build in Deno to produce output compatible with Deno
• running dev in Deno to develop locally
• porting SolidStart to Deno
• porting Solid to Deno (original question asked <)

and yes, in 2020 we didn't even have npm compatibility in Deno :) different worlds :)