Snabbdom dependency

[Eduardo Asafe]

Currently, the library outsources dom patching to snabbdom. This has a few issues (that may or may not be worth being worked on):

• As an external npm dependency, it adds friction to the development process

• We can't update snabbdom at all since newer versions use ES modules which the PureScript compiler doesn't support yet

• These might be eased by the latest changes (e.g., keyed), somehow managing to upgrade snabbdom, or just some work around code in our part, but there are many things that the current snabbdom implementation doesn't play nice with. From the top of my head: externally modifying nodes (in cases where hooks don't apply, usually with server side rendering), conditional rendering (e.g., if and else in views), content editable usage...

• There is something to be said about improving bundle size and performance, but I am still looking into these (and snabbdom doesn't really maintain benchmarks)

A couple solutions come to mind:

1. Simply wait out on the PS compiler, and then upgrade snabbdom

This is the easiest course of action, for obvious reasons. There is no time frame guarantee, though, or that all points will improve.

2. Fork snabbdom and iron it out for usage with the library

This one could solve most of the outlined problems. I don't know how much the associated maintenance cost would increase, however.

3. Use something else

Likely a lot of work. We can just fork any other JavaScript library -- as long the library current user facing API stays the same -- no need to go full NIHS. Feature matching might be a concern (e.g., if the new implementation doesn't use a virtual dom), specially given all of @chekoopa recent work 🙃.

[Mikhail Chekan]

Have you tried using the newest Snabbdom? Something tells me that we still can befriend Flame with Snabbdom through packers, like Parcel and Webpack.
AFAIK, ES support is about FFI code, not linked libraries. It's to be experimented and checked.

Maintenance is not an issue, Snabbdom is still maintained.
Performance? I'm not sure I can tell something.
Bundle size? Snabbdom itself is quite sleek, for something else we have Zephyr.

My opinion is to throughtly check a possibility to use ES-based Snabbdom with Flame, and if we can't, wait for compiler. It would become more and more tedious to even try reverting that CJS deprecation.

For a different backend and feature set it's more sensible to start a new library. 😌

[Eduardo Asafe]

Have you tried using the newest Snabbdom?

Yes, snabbdom can't be required anymore, which breaks Renderer.js.

Maintenance is not an issue, Snabbdom is still maintained.

I meant in the case of a fork.

My opinion is to throughtly check a possibility to use ES-based Snabbdom with Flame

I think this is the most resonable. Just needs a good work around -- tho bundling it with the library might be a good idea.

[Mikhail Chekan]

Yes, snabbdom can't be required anymore, which breaks Renderer.js.

;( after bumping to 1.0.1

internal/modules/cjs/loader.js:638
    throw err;
    ^

Error: Cannot find module 'snabbdom'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15)
    at Function.Module._load (internal/modules/cjs/loader.js:562:25)
    at Module.require (internal/modules/cjs/loader.js:692:17)
    at require (internal/modules/cjs/helpers.js:25:18)
    at Object.<anonymous> (/home/user/projects/purescript-flame/output/Flame.Renderer/foreign.js:3:13)
    at Module._compile (internal/modules/cjs/loader.js:778:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
    at Module.load (internal/modules/cjs/loader.js:653:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
    at Function.Module._load (internal/modules/cjs/loader.js:585:3)

Something similar with Parcel:

yarn run v1.22.0
$ parcel serve index.html
ℹ️ Server running at http://localhost:1234
🚨 Build failed.
Error: ENOENT: no such file or directory, open '$PROJECT_DIR/node_modules/snabbdom/tovnode.js'
Error: ENOENT: no such file or directory, open '$PROJECT_DIR/node_modules/snabbdom/tovnode.js'

I meant in the case of a fork.

Well, it we sync it once at every release till Purs obtains long-awaited ES support... Doesn't look like a chore.

Just needs a good work around -- tho bundling it with the library might be a good idea.

MIT license enables us to do that.

[Mikhail Chekan]

There's a plenty of Hyperscript-based VDOM (or no-VDOM) libraries, such as Maquette and RE:DOM.
I'm only confused about properties argument which contains all props mixed (attributes, styles, and event handlers).

[Eduardo Asafe]

Performance? I'm not sure I can tell something.

I will open a PR later, but with the addition of thunks and keys, it stacks the same as hedwig on the js-framework-benchmark. I have yet to review it but oddly I couldnt do a non-keyed version -- neither with hedwig.

MIT license enables us to do that.
There's a plenty of Hyperscript-based VDOM (or no-VDOM) libraries, such as Maquette and RE:DOM.

For sure. I will see about embedding snabbom as current goal, then take a preemptive look at other options to see if it makes any sense. But yea, as far as js framework go, there couldn't be more variety.