Too many different reactive DOM libraries with similar goals

[Felix Dietze]

Hi everyone,

I noticed that there are several ScalaJS libraries following the approach of mapping reactive variables to the DOM: Binding.scala, Outwatch, monadic-html, scalatags-rx, MetaWeb (and probably some more I don't know, please post them here).
Involved contributors: @Atry, @LukaJCB, @OlivierBlanvillain, @olafurpg, @rtimush, @lihaoyi, @tindzk

Every library introduces some advantages and therefore defines shortcomings for the others at the same time (again, this list is probably incomplete):

• Virtual DOM for efficient updates (Outwatch)
• Delta updates of reactive lists and DOM (MetaWeb)
• Let the user access the reactive values as monads (monadic-html, scalatags-rx)
• Prevent memory leaks (scalatags-rx)
• Avoiding unnecessary updates by handling the diamond-case in the reactive dataflow graph (lihaoyi/scala.rx#79)
• The markup is written in XML/Scalatags/some other DSL
• Macro-based to avoid boilerplate / Library-based to avoid long compile-times and obscure errors

So each library is basically a compromise, because it lacks the advantages of the others.
I would like to see more collaboration between the authors and libs, since the goals are all very similar, although I'm unsure how this would look like in practice. Or is this already the case? I guess every library author has something to say here.

This is not about criticism of libraries. I'd like to talk about how we could move forward together.

[Otto Chrons]

This? :)

IMO at this point of time it's good to have a lot of libraries (and new ones popping up) as it's a sign of a healthy eco-system. This is like the first round of UI frameworks for Scala.js so there's bound to be a lot of opinions and angles. Most, if not all, of these libraries were created for some specific custom need, not really to provide a generic framework for everyone. Although some of them have evolved to be more generic over time.

The "market" will decide which libraries flourish and which wither away.

- Otto

[Felix Dietze]

I actually thought about this comic when I wrote this :)

I hope that this post encourages awareness and sharing of best-practices. We probably don't need another library in this early stage.

[杨博 (Yang Bo)]

在 2017年3月27日星期一 UTC+8下午11:15:52，Felix Dietze写道：

Hi everyone,

I noticed that there are several ScalaJS libraries following the approach of mapping reactive variables to the DOM: Binding.scala, Outwatch, monadic-html, scalatags-rx, MetaWeb (and probably some more I don't know, please post them here).
Involved contributors: @Atry, @LukaJCB, @OlivierBlanvillain, @olafurpg, @rtimush, @lihaoyi, @tindzk

Every library introduces some advantages and therefore defines shortcomings for the others at the same time (again, this list is probably incomplete):

• Virtual DOM for efficient updates (Outwatch)

Binding.scala's partial updating is faster than any virtual DOM library. Check the http://www.stefankrause.net/js-frameworks-benchmark5/webdriver-ts/table.html , the partial updating benchmarks are:  partial update, select row, swap rows and remove row.

• Delta updates of reactive lists and DOM (MetaWeb)

And Binding.scala 

• Let the user access the reactive values as monads (monadic-html, scalatags-rx)

And Binding.scala 

• Prevent memory leaks (scalatags-rx)

And Binding.scala and monadic-html

• Avoiding unnecessary updates by handling the diamond-case in the reactive dataflow graph (lihaoyi/scala.rx#79)

Scala.rx is not a good example, because Scala.rx requires manually managed ownership.

Binding.scala and monadic-html resolves this problem. 

• The markup is written in XML/Scalatags/some other DSL

For example, Binding.scala 's XHTML literal.

• Macro-based to avoid boilerplate / Library-based to avoid long compile-times and obscure errors

Binding.scala supports both.

• `@dom` is macro based.
  
• However, you can use scalaz's MonadOps with Binding.scala. It is library-based and it compiles very fast.
  

[Ólafur Páll Geirsson]

I agree with Otto, it's positive (and exciting!) that there is so much innovation happening in this space in Scala.js. 

> I'd like to talk about how we could move forward together.

How about making a TodoMVC-like test for Scala.js UI libraries? I think a Scala.js focused TodoMVC-like test could highlight attributes which may be extra relevant for Scala developers, for example

- type safety (esp. related to DOM).

- compile/link times (I personally care a lot about `~fastOptJS` times for small changes)

I believe such a test could be useful for both library authors (if they wish to participate) and library users.

Cheers,

Olaf

[杨博]

You are right. Binding.scala's `@dom` is not very fast. It's partially due to un-typecheck in macros.

I hope I can avoid the un-typecheck. However, Scala's typed AST is too vulnerable if I did not un-typecheck it

I don't know if there is any approach in Dotty to resolve this problem.

--
You received this message because you are subscribed to a topic in the Google Groups "Scala.js" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-js/77J_RdnWu_k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scala-js+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-js/9944426a-7a9b-49d4-9b00-3356c5c6f515%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

杨博 (Yang Bo)

[Felix Dietze]

What just came to my mind:

Are there common requirements for these libraries that everyone can agree on? At least the reactive programming part seems to have very similar requirements in every library.

When these requirements are met, the libraries can shine in what makes them special without compromising the base-case.

The requirements could be manifested in an Todo-MVC-like test, as Olaf mentioned.

Example requirements:

- Prevent memory leaks (there are different strategies to do that)

- Avoid unnecessary updates (Example: diamont-shaped data-flow graphs mentioned here: https://github.com/lihaoyi/scala.rx/issues/79)

To unsubscribe from this group and all its topics, send an email to scala-js+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-js/9944426a-7a9b-49d4-9b00-3356c5c6f515%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

杨博 (Yang Bo)

[Olivier Blanvillain]

> Are there common requirements for these libraries that everyone can agree on?

If everyone agreed on requirements they wouldn't be more than one library :-). For instance, I consider referential transparency to be essential, while it might not a priority for others, for example, Scala.rx filter is not RT).

@Felix Could you explain your motivation with all this? If you are worried that library authors don't benefit from each other's work, you shouldn't! I think everyone got heavily inspired by previous works (this seems clear looking at each project README), and we are also already collaborating, see for example [@Atry comment][1] on one of the first commit of monadic-html.

[1]: https://github.com/OlivierBlanvillain/monadic-html/commit/d4e03e8c95911aec773236ed76d41177adde439b#commitcomment-19392201

[Marius Kotsbak]

2017-03-28 10:26 GMT+02:00 Olivier Blanvillain <olivierbl...@gmail.com>:

> Are there common requirements for these libraries that everyone can agree on?

@Felix Could you explain your motivation with all this? If you are worried that library authors don't benefit from each other's work, you shouldn't! I think everyone got heavily inspired by previous works (this seems clear looking at each project README), and we are also already collaborating, see for example [@Atry comment][1] on one of the first commit of monadic-html.

I am most worried about the limited effort available is spread over so many reactive and HTML libraries that none of them gets any good. People might also be sceptical using a library with only one author (bus factor). Look at e.g. FB React how much effort they put into one library to ensure it is good, complete and update.

Maybe a solution could be to split the reactive library part and get some good alternatives there (Scala.Rx was dead last I checked) and then have multiple HTML libraries that adds compatibility to one or more of the common reactive libraries. The Unix/Linux philosophy in other words (make small utilities that does one task good, and then combine them using pipe/calls etc.).

Missing from the list:

Reactive/HTML: http://udash.io/

HTML: http://widok.github.io/ (not very active recently)

Reactive: https://github.com/MetaStack-pl/MetaRx (also not very active)

--

Marius Kotsbak

[Olivier Blanvillain]

> Maybe a solution could be to split the reactive library part and get some good alternatives there (Scala.Rx was dead last I checked) and then have multiple HTML libraries that adds compatibility to one or more of the common reactive libraries.

This is already the case. The libraries I know of have a clear
separation between the reactive part and the html binding part, the
former being independently tested, documented and published. If
someone wants to contribute additional bridges (xml syntax for
Scala.rx, scalatags for monadic-html & so on), there shouldn't be
anything needed from the library authors.

[Marius Kotsbak]

2017-03-28 10:55 GMT+02:00 Olivier Blanvillain <olivierbl...@gmail.com>:

> Maybe a solution could be to split the reactive library part and get some good alternatives there (Scala.Rx was dead last I checked) and then have multiple HTML libraries that adds compatibility to one or more of the common reactive libraries.

This is already the case. The libraries I know of have a clear
separation between the reactive part and the html binding part, the
former being independently tested, documented and published. If
someone wants to contribute additional bridges (xml syntax for
Scala.rx, scalatags for monadic-html & so on), there shouldn't be
anything needed from the library authors.

Yes, I mean problem is that they only support their own reactive library. I once proposed just that: https://github.com/widok/widok/issues/92

--

Marius Kotsbak

[杨博]

The interoperability is definitely the missing part of the eco-system.

It would be nice if there is an Android XML syntax working with Binding.scala

You can check https://github.com/ThoughtWorksInc/Binding.scala/issues/18 if you are interested.

--
You received this message because you are subscribed to a topic in the Google Groups "Scala.js" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-js/77J_RdnWu_k/unsubscribe.

To unsubscribe from this group and all its topics, send an email to scala-js+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-js/CAGOauttKZLnDBa8VvR-BrwgKGJhYcvZDa3fbe_QFE1RkY1dYQQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

杨博 (Yang Bo)

[Felix Dietze]

Marius phrased it well.

I was using some of the mentioned libraries, had some issues and tried others, just to find that they had different issues. I almost started my own library to finally get it right in a simpler way. It seems like many authors had the same motivation. My feeling is that too many people are reinventing the wheel, especially on the reactive part.

--
You received this message because you are subscribed to a topic in the Google Groups "Scala.js" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-js/77J_RdnWu_k/unsubscribe.

To unsubscribe from this group and all its topics, send an email to scala-js+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-js/CAGOautt4wSpwOB_xvZ-QjC1N4TopAQUAbWakps%3DzDgNHf36m0A%40mail.gmail.com.

[Justin du coeur]

On Tue, Mar 28, 2017 at 4:39 AM, Marius Kotsbak <mar...@kotsbak.com> wrote:

(Scala.Rx was dead last I checked)

This is a good illustration of the way that GitHub only provides a partial view.  There hasn't been development in Scala.Rx in some while, no -- but I'm using it in production, and I know I'm not the only one.  (Indeed, I'm not the only person who has written a higher-level framework on *top* of Scala.Rx.)  I haven't worried about the lack of new development because it works, and I haven't needed changes.

Seriously: for now, this is a solution chasing a problem.  Yes, we've had the usual Cambrian explosion of libraries, and we're still in the middle of it.  It'll settle down over time, but we are nowhere *near* ready to start pruning the tree -- there are new significant libraries still to come out in the not-too-distant future.  (Including ochrons' Suzaku and my sQuery.)  There will come a time to start standardizing, but it's way premature yet -- we're still figuring this stuff out...

[Marius Kotsbak]

2017-03-28 14:25 GMT+02:00 Justin du coeur <jduc...@gmail.com>:

On Tue, Mar 28, 2017 at 4:39 AM, Marius Kotsbak <mar...@kotsbak.com> wrote:

(Scala.Rx was dead last I checked)

This is a good illustration of the way that GitHub only provides a partial view.  There hasn't been development in Scala.Rx in some while, no -- but I'm using it in production, and I know I'm not the only one.  (Indeed, I'm not the only person who has written a higher-level framework on *top* of Scala.Rx.)  I haven't worried about the lack of new development because it works, and I haven't needed changes.

I think the situation is better now than when this issue came up: https://github.com/lihaoyi/scala.rx/issues/37

--

Marius

[Nikita Gazarov]

Five-ten libraries is not many. Look at Javascript, there are hundreds.

This variety is good. It shows community engagement. These libraries are not clones of each other, they take different approaches with different trade-offs.

UI management is a hard problem with no obvious best solution. Even years down the line we will have multiple competing libraries including many of the currently existing ones, and we will be happy that we have such choice.

[Felix Dietze]

You are right. Variety is good.

Just the exact tradeoffs and differences between the libraries need to be obvious for users and other library developers. If this is not clear, how should one know if they solve the same problems? And if they solve the same problems (for example in the reactive part), why are they not sharing code?

--

You received this message because you are subscribed to a topic in the Google Groups "Scala.js" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-js/77J_RdnWu_k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scala-js+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-js/88ef9080-0147-4e93-b0f8-da732f3d9057%40googlegroups.com.

[Christian Schmitt]

what I think is really really sad, is that there is no library that uses plain HTML files or some sort of that, and instead uses their DSL/Syntax directly inside Scala files.

Of course all people are Scala developers, but it might be helpful to have a seperate file, like a Twirl Template and compile/convert it. Something like https://github.com/glimmerjs, just more typesafe.

To unsubscribe from this group and all its topics, send an email to scala-js+u...@googlegroups.com.

[Marius Kotsbak]

2017-04-24 15:04 GMT+02:00 Christian Schmitt <c.sc...@briefdomain.de>:

what I think is really really sad, is that there is no library that uses plain HTML files or some sort of that, and instead uses their DSL/Syntax directly inside Scala files.

Of course all people are Scala developers, but it might be helpful to have a seperate file, like a Twirl Template and compile/convert it. Something like https://github.com/glimmerjs, just more typesafe.

Well, that is natural as we want a typesafe connection to the code and the IDs in the HTML document. Else you could just use e.g. an Angular facade.

--

Marius

[Erik van Oosten]

There is now. Pine (http://sparse.tech/blog/announcing-pine) uses macros to parse html. For example you can write val list = html"""<ol><li>$a</li><li>$b</li></ol>""". Any html errors are flagged at compile time. You can also load html from a file.

Unfortunately you need to use Typelevel's scala compiler (or wait for 2.13).

Kind regards,

    Erik.

Op maandag 24 april 2017 15:04:13 UTC+2 schreef Christian Schmitt:

[Felix Dietze]

Thanks for sharing, this looks great!

Are you aware of https://github.com/raquo/scala-dom-types and https://github.com/raquo/scala-dom-builder? Looks like you have similar goals.

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-js/2874fd67-4d05-482f-895f-795fbeee3b78%40googlegroups.com.

[Erik van Oosten]

Although scala-dom-types, scala-dom-builder and pine have in common that they provide a dom model and let you build dom fragments, only pine allows you to directly work with html.

I am completely new in this area so take this with a grain of salt. There are probably some gains by giving these libraries some common ground. For example pine's binding story is not so great. Also the lack of hierarchy in pine's model is sometimes a bit inconvenient.

Kind regards,
    Erik.

--
Erik van Oosten
http://day-to-day-stuff.blogspot.nl/
https://github.com/erikvanoosten/

Op 15-03-18 om 12:20 schreef Felix Dietze: