I began to study Clojure(script) with the desire to know the language enough to (some day) be able to contribute to Penpot. I was surprised by the expressiveness that can be achieved with Clojure, although I must admit that it is not easy for me to change the mind set from the traditional object and statement oriented languages.
Fortunately, there are several great free books to learn Cloujure an ClojureScript.
The one I’m reading (“Learn ClojureScript” from Andrew Meredith) use Reagent as the interface between ClojureScript and React, but I realized that Penpot use Rumext, a library written by @niwinz.
I don’t know about Rumext yet, but I was wondering why do you have preferred to use a proprietary library in this case.
Could you please share with us what were the main reasons that led to the decision to use Rumext instead of Reagent? Do you think it might be useful for newbies like me to contribute by working on the Rumext documentation and examples?
I think I’m the most appropriate to answer this question hehe
The rumext is not proprietary, is open source in the same way as reagent. And it a very lightweight wrapper on top of react. Very in the same way as reagent. The rumext born as rum library fork with some tweaks, but with time it is evolved in a completely separated library.
Rumext in contrary to the great majority of libraries that wraps react in cljs, is focused on performance and usability with depth react knowledge. It is not suitable for general use like reagent because many design decisions may be not understood on the first steps. Reagent is focused on make it very easy to use but it is also very easy to make code that do not has good performance (in general is not a problem but penpot has challenges that are not very common); when you need go deep and you need squeeze react performance, reagent API is not very comfortable to use; it is not bad it just a design decision. This is just my opinion obviously; I have nothing agains reagent.
An objective advantages of rumext is that it tries to hide very little from react and have no dynamic interpreter of template/jsx code. Rumext compiles (on compile time, so no possible runtime interpretation all the components so when it executes, it just executes the react code, 0 runtime overhead. This decision is a tradeoff, and has its implications on usability, where reagent brights better. But an application like penpot requires every ms of cpu on render path.
Also, a good and not less valuable reason is have whenever possible and makes sense code under our control, and rumext is a very little library that anyone with some cljs and react experience can maintain. Having less core dependencies as third-party makes maintaining the code and solve deep tricky problems a little bit simpler.
In any case, this is my opinion, and it worked for us. It is not a silver bullet and all have trade-offs.
To be honest, I don’t know how to answer that. Every person is different on learning mechanics, and I only can give you hints on how I have done it myself. Choice a good starting point, that can be the examples directory of rumext repository or just a simple project for experiment, and try to imagine different use cases, starting from the basic one and start digging deeper and deeper using rumext (it also applies to other libraries). If you understand something and looks like there are no documentation or documentation is outdated, you can generate your own notes (that later you can consider contribute back ad documentation improvements, but it is not mandatory, I mean, this is for you).
However, I also need to say that rumext in penpot is a very thin layer; there are so much to understand on how penpot is done, than learning rumex. In any case, I do not discourage you, I only mention it so that you can manage your own expectations well.
Small contributions to penpot are just as important as any other. I’m just saying don’t get frustrated, penpot is a big and very complex project; where we ourselves, the core developers do not have deep knowledge of all parts of the code.
This week I will try to configure a local development environment on my notebook using the instructions that @diacritica directed me to.
I will comment in a post my experience in the configuration process, contributing as much as possible, sharing with you if I have any difficulties or if I have any suggestions that may improve that documentation.
After that I would like to start writing a series of posts (perhaps one or two per week) titled something like “Improve your Clojure with Penpot”.
The idea of that posts is presents “use cases” found into the Penpot code that illustrate different part of the theory of your book “ClojureScript Unraveled”.
In that way I hope to simultaneously, improve my knowledge on Clojure and Penpot, and attract the interest of other developers with concrete real examples using the book as roadmap.
Any suggestion will be bery welcome and I greatly appreciate the support you give to the Community.
