hyperscript

hyperscript copied to clipboard

Deno is a new JS server environment that was created from ground up in attempt to fix Node.js's drawbacks. It looks like this library somehow confused it with a browser (uses process to distinguish Node and browser probably?) Deno doesn't have process, it has its own Deno object in the global namespace, and it uses ES6 modules and not NPM packages.

Hyperscript is small, compact and relatively self-contained, just like Deno. I think they would play together rather nicely.

Hyperscript does not check for process, it does a standard window check to determine browser vs Node: https://github.com/hyperhype/hyperscript/blob/4c0d558e7a1f2cd7068cd577d05642ef52c5a5ad/index.js#L4

it does a standard window check to determine browser vs Node:

This is an older assumption that window means "browser". Deno also has globalThis.window.

The next line is where the assumption goes wrong:

https://github.com/hyperhype/hyperscript/blob/4c0d558e7a1f2cd7068cd577d05642ef52c5a5ad/index.js#L4-L5

(If environment is unknown, each feature should be tested before being used.)

All that being said, Hyperscript predates Deno by quite a bit, back in a time where a JavaScript "client" meant "browser" and "server" meant "Node.js".

@kisik21 Deno doesn't have any DOM support yet, so it would need to provide that feature before something like hyperscript could support it as an environment.

In Node there's html-element used to simulate a minimal DOM enough to make HTML. If the check in L4-5 is changed to detect absence of window.document instead of just window (which Deno has, unlike Node), then one could easily make it work with Deno via a proxy that rewrites requires to ES6 imports (that's how I originally tried to launch this package, and it would've worked if the check didn't failed.

I may try to make a PR in the near future. Something like extending the L5 with var document = typeof w.document === 'undefined' ? require('html-element') : w.document - should probably make it work with Deno after rewriting imports.

should probably make it work with Deno after rewriting imports

@kisik21 It's a little more complicated than that. Neither html-element nor its chain of npm dependencies provide ES modules (they only support CommonJS). Because Deno only supports esm with explicit specifiers, you'd have to refactor every module in every dependency (and dependency of dependency... and so on: all the way to the end of the module graph) to that format.

If you don't want to go that route, you could look at other community modules for DOM in Deno (e.g. https://deno.land/x/deno_dom).