My new projects to extend React: Respo and Quamolit

176 views
Skip to first unread message

Jiyin Yiyong

unread,
Apr 21, 2016, 6:13:47 AM4/21/16
to ClojureScript
I want to see if anyone is already getting bored about React.js like me. It's still fun to try React Native but React.js is old, its 2012 technology(not quite sure about 2012, but old enough even 2013). React is not nicely decoupled, and not a great framework for animations. It's becoming as useful and as mature like jQuery. I think we can go beyond.

Well, I've been programming for 5 years only from learning C in school and trying Python on my own(not counting course on Visual Basic since it was only a course). I can't build a whole framework like React. However, I can see some vision ahead and try them with my code. So they are Respo and Quamoit. Both are experimental project and in early stages(Docs not ready, sorry for that). Just hope they may be sources of inspirations.

Respo

repo https://github.com/mvc-works/respo/
example app https://github.com/Memkits/wanderlist/

Respo is like React but a lot simplified and decoupled. I implemented a simpler DOM diff algorithm and bound events. By now I can build very simple apps with it. I think the shiny parts are:

* components are designed to fit with caching so that server side rendering would be faster
* DOM diff/patching are decoupled, so possible to diff on server and patch at clients
* element DSL in ClojureScript syntax, not JSX style
* component states are stored global, so not losing during hot swapping

You may find more on Hashnode and Youtube:
https://hashnode.com/@jiyinyiyong/stories
https://www.youtube.com/user/jiyinyiyong/videos

Quamolit

repo(alse example) https://github.com/Quamolit/quamolit
components source code https://github.com/Quamolit/quamolit/tree/master/cirru-src/quamolit/component

Quamolit is an experiment on canvas and it relies on Hit Regions APIs to work, so not even usable for build real apps. The nice thing is, in React it's difficult to make nice animations, in declarative canvas libraries there's no abstractions to compose components like React, Respo is maybe a way to combine them. You can browse the source code and take a look on my Youtube.

For each component, there's functions of `init-state update-state init-instant on-tick on-update on-unmount render`, you may see what's going on by the names. So besides **state**, Quamoit introduced **instant** as the animations states, and it will be updated by **on-tick**(as requestAnimationFrame calls) **on-update**(as global store and states changes) **on-unmount**(as the component start leaving).

Currently there are only videos and tweets(@jiyinyiyong) on Quamolit. I will add post when it's more stable.

Projects are in early stage and when I go back to work a weeks later I will probably spend much time on them. I think my experience is not enough for real world frameworks, I hope someone may pick my ideas and use them in their own projects. I used to write in Chinese at segmentfault.com/blog/jiyinyiyong and I will later write on Hashnode in English to see if someone is interested.

Hope you like my ideas. Thanks.

Jiyin Yiyong

unread,
Apr 21, 2016, 6:23:20 AM4/21/16
to ClojureScript
Not able to edit, corrigendums here... "declarative canvas libraries" shoud be "imperative...", most canvas libraries are object oriented with mutable state, unlink React. "go back to work...spend much time" should be "less time", real world apps are unlikely to pick immature code like Respo.

Julien Eluard

unread,
Apr 21, 2016, 11:56:44 AM4/21/16
to clojur...@googlegroups.com
Hi Jiyin Yiyong,

nice to see some alternatives to React in Clojure! I have to dig more into your blog posts to understand your ideas but it definitively looks interesting.
May I suggest to have some documentation/examples in raw ClojureScript to help people grasp the syntax?

You might also be interested in some libraries I wrote:
* https://github.com/jeluard/hipo create/reconciliate DOM nodes from hiccup syntax
https://github.com/jeluard/lucuma CustomElements boilerplate
https://github.com/jeluard/picada a collection of google material elements, built on both former libraries (WIP)

Julien


--
Note that posts from new members are moderated - please be patient with your first post.
---
You received this message because you are subscribed to the Google Groups "ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com.
To post to this group, send email to clojur...@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

jiyinyiyong

unread,
Apr 21, 2016, 9:19:36 PM4/21/16
to clojur...@googlegroups.com
So you created another React too?

My projects are not yet stable, I will add examples later.

You received this message because you are subscribed to a topic in the Google Groups "ClojureScript" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/3AojzHsh3u0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojurescrip...@googlegroups.com.

Julien Eluard

unread,
Apr 22, 2016, 3:58:11 AM4/22/16
to clojur...@googlegroups.com
It's more a merge implementation based on hiccup syntax. You can use it to replace React, especially to create components.
Maybe there is an opportunity to extract a generic diff/patch library?

jiyinyiyong

unread,
Apr 22, 2016, 5:59:45 AM4/22/16
to clojur...@googlegroups.com
I'm not a big fan of Hiccup actually. As you mention the diff/patch library, what's your solution? I tried in my project and only got a very simple solution with some bugs. How about yours?

Julien Eluard

unread,
Apr 22, 2016, 6:15:05 AM4/22/16
to clojur...@googlegroups.com
Currently I'm doing a one pass merge (similar to https://github.com/google/incremental-dom). I am considering moving to diff/patch to be able to diff in a service worker and patch in the main thread.

jiyinyiyong

unread,
Apr 22, 2016, 9:20:45 AM4/22/16
to clojur...@googlegroups.com
Reading code from others is always challenging. I've tried incremental-dom once, I suppose in the DOM the node path is already losing, which in virtual DOM I can always keep the path.

Julien Eluard

unread,
Apr 22, 2016, 9:59:56 AM4/22/16
to clojur...@googlegroups.com
If you want to keep the node path with an incremental-dom approach you almost implement a regular virtual dom.
Reply all
Reply to author
Forward
0 new messages