Goal of this project 🚀

[cornerman]

This project is great, I am super happy to see this port (also because I wanted to do so since a long time). Potentially, it might also be very useful for outwatch :)

What I would like to know: Is the goal of this project to be a scala-js clone of snabbdom or should it evolve independently from now on? I think being a clone is great, but I think, there is room for improvement in snabbdom. Given that we have scala and can build really typesafe APIs on top of the dom, we could make optimizations in regards to usability and performance.

[buntec]

Hi @cornerman 👋

Thanks so much for your feedback!

My immediate goal was to have a pure Scala.js drop-in replacement for Snabbdom so that I could remove the JS dependency (and hence the bundler) from my other project, ff4s (which took a lot of inspiration from OutWatch, by the way). Writing a naive line-by-line translation (more or less) seemed the fastest way to get there. Once this has been achieved, however, and I think we are getting close, I'm very open to evolving it away from a mere clone to a more idiomatic (and functional) Scala vdom library with all its potential benefits. Contributions are certainly very welcome! 😉

[cornerman]

Awesome! That is what i hoped :)

One question is certainly: Do we consider this library directly user facing or is it more like a low level library powering, e.g., ff4s and outwatch.

Just to mention a few things that bother me with snabbdom and maybe start a discussion:

• Mutability of vnodes (specifically having var elm): this makes it impossible to reuse vnodes. I think, there is a big potential for performance improvements.
• Having classes and ids mixed with the tag name (sel). There is some string manipulation involved for every vnode processed by snabbdom. Even without it, patching can still be influenced independently with the is property on vnodes - besides the key.
• Automatically adding the xml namespaces. We can actually do this directly from scala-dom-types.

Looking forward!

[davesmith00000]

Just my ten cents:

I'm enjoying the library's current state more than I expected to. I had considered writing a Scala.js VDom implementation myself, but won't bother now. This one is great!

Selfishly, I'd hope the library aimed to be a low level implementation for others to build on - which is how I think of Snabbdom. That being the case, I'm not so bothered about it being functional or not, as long as it's fast, reliable, and low on its dependency requirements. Which incidentally are all the reason Snabbdom is so popular as far as I can tell.

For example: It would be tempting to make this lib go the full pure FP, I'm sure, but I think the choice of exposing a purely functional API ought to be down to the people building on top of this, rather than it being a concern for this library. If you did that it would be harder for the no/low-FP-Scala crowd to make use of it if they wanted to. Just my opinion.

That said, it certainly feels like there's tons of scope for the API's to feel more idiomatically Scala-like.

But again, I'm thrilled this exists, I look forward to shipping Tyrian on it as soon as possible. With the occurrence of libraries like these it feels like we're edging towards a critical mass of actually not needing the NPM ecosystem in Scala.js - at least in terms of core functionality - which I find really exciting.

Bravo 👏

[armanbilge]

With the occurrence of libraries like these it feels like we're edging towards a critical mass of actually not needing the NPM ecosystem in Scala.js - at least in terms of core functionality - which I find really exciting.

Music to my ears!

---

Do we consider this library directly user facing or is it more like a low level library powering, e.g., ff4s and outwatch.

Selfishly, I'd hope the library aimed to be a low level implementation for others to build on - which is how I think of Snabbdom. That being the case, I'm not so bothered about it being functional or not, as long as it's fast, reliable, and low on its dependency requirements.

In addition to those adjectives, I would add stable, in the API/bincompatibility sense. Probably, it is easier to agree on a stable low-level API than it is a higher-level one. See also:

• Boilerplate trade-offs in APIs #20
• Lockdown all the things #19

---

Mutability of vnodes (specifically having var elm): this makes it impossible to reuse vnodes. I think, there is a big potential for performance improvements.

It would be tempting to make this lib go the full pure FP, I'm sure, but I think the choice of exposing a purely functional API ought to be down to the people building on top of this

I think it is worth exploring immutability, in that it is more-or-less an idiom of Scala itself. Particularly if there's performance improvements as Johannes is promising 😉 I'm not sure what the full pure FP version of this lib would look like, and agree it is probably less justified, esp. if it can be done in user-land libraries.

[buntec]

@cornerman, regarding immutability of vnodes, I've made an attempt here. Your feedback is welcome 😉 !