Closed buntec closed 1 year ago
rossabaker
commented
1 year ago Thanks, @buntec!
@typelevel/steering: please vote with reaction on the issue. 👍 for yes, 👎 for no, 👀 to abstain. Voting is open three business days (through Friday, April 28) and until quorum (7) is reached.
valencik
commented
1 year ago Hey @buntec, thanks for submitting this. I notice you list calico as an inspiration, for my own curiosity, could you say a bit about how ff4s differs?
I'm looking forward to playing with this. :)
buntec
commented
1 year ago Hey @valencik,
That's a great (and also difficult) question! I'm by no means an expert on UI frameworks and patterns so please take this with a grain of salt. I'll surely get things wrong, in which case I firmly rely on @armanbilge to correct me ;).
Let me first say that all of the mentioned Scala.js front-end libs are great and I certainly don't claim that ff4s is better than any one of them. The solution space for UI libs is huge (evidenced by the proliferation of such libs) and picking one over another is, in my opinion, a matter of trade-offs and taste!
With that out of the way, I think Laminar, Outwatch and Calico all differ significantly from ff4s. The architecture of ff4s is closer to Elm (and hence also Tyrian) and Redux: there is a single store holding global immutable state (the Model in Elm), a set of actions that describe (effectful) state updates (Msg/Cmd in Elm), and finally there is a rendering function (the "view") which is simply a pure function of the state. In particular, the data flow is unidirectional. Laminar, Calico and Outwatch are more flexible in that there usually isn't a single, global state container. Instead, each component can hold its own state, but may also have access to the state of other components in an ad-hoc fashion. Moreover, state updates don't have to be coordinated by a store. I think there are pros and cons to both approaches.
In terms of the implementation, the Elm/Redux pattern is a natural fit for virtual DOMs. Indeed, since every state update is global, we want to make sure that we only update (i.e. mutate) the part of the (real) DOM that's actually affected. VDOMs accomplish this using a diffing algorithm. On the other hand, Calico doesn't need a VDOM because state updates are local and each component is responsible for updating its part of the DOM. That's why components in Calico "return" real DOM elements, while components in ff4s "return" VDOM elements. Finally, (and I hope this is a fair assessment) what distinguishes ff4s from all other mentioned libs except Calico is that it is built on top of cats-effect and fs2 primitives and thus feels native to the ecosystem. In fact, this has been my main motivation for embarking on this project! Although completely anecdotal, we've been using ff4s quite extensively at my workplace, and people who know and love cats-effect and fs2 have taken to it very naturally.
I hope this helps!
armanbilge
commented
1 year ago 💯 excellent description, probably we can use it in a blog post 😃
Finally, (and I hope this is a fair assessment) what distinguishes ff4s from all other mentioned libs except Calico is that it is built on top of cats-effect and fs2 primitives and thus feels native to the ecosystem. In fact, this has been my main motivation for embarking on this project!
Exactly. ff4s is to Elm/Tyrian[^1] what Calico is to Laminar :)
[^1]: Tyrian's runtime is also written with Cats Effect, but the user-facing API is in terms of Elm concepts like Cmds (aka side-effects) and Subs (aka streaming subscriptions).
rossabaker
commented
1 year ago That's quorum and unanimously confirmed. Next steps are tracked in #104.
Project Name
ff4s
Project Short Description
Yet another front-end framework for Scala.js. Built on top of CE3 and fs2.
Project Type
In accordance with the Typelevel Charter, I am proposing the project be a:
Project Management
Typelevel projects are required to have an appropriate Code of Conduct. The Scala Code of Conduct is a good option, but not specifically required. Before submitting a project for inclusion, please ensure that a pointer to its Code of Conduct is clearly linked from its README, CODE_OF_CONDUCT.md, or website.
Similarly, Typelevel projects must have an appropriate license, as specified in the Typelevel Charter. Please make sure that the project's license is on the approved list.
Additional Notes
Suggested for submission by @armanbilge.