1st Meetup for Reagent if you're in SF/Bay Area come join us on Monday!

http://www.meetup.com/Reagent-Minimalistic-React-for-Clojure...

See you there!

See ya :)

How does it compare to Om?

edit: Found this write-up http://getprismatic.com/story/1405451329953

The biggest difference is that, unlike Om, Reagent does not require you to reify an interface to define a component. Instead, components are defined with functions which return a hiccup-like datastructure. If you need access to React's other lifecycle methods, you can provide metadata, but in general, you don't need to bother. Personally, I find this easier to reason about.

The other major change is that state is managed through a special, customized, reactive atom. Everytime the atom is updated, any components which use it are updated. You can have as many of these atoms as you want and you can use them from as many components as you want.

Take a look at Prismatic's om-tools(1).

It adds a defcomponent macro that removes a lot of boilerplate.

1)https://github.com/Prismatic/om-tools

I actually used om-tools before I switched to reagent. Om-tools does cut out a lot of boilerplate, but I like reagent's approach more from the outset. One thing I found confusing about Om with or without om-tools, was how to manage communication between the components. The tutorials used a lot of core.async to manage that but it was clearly unnecessary.

In Reagent you can pass arbitrary parameters to component functions. You don't have to make each component correspond to a branch on your applications state's tree. You can, and you can use a cursor analog if you want to, but you don't have to and I found that very freeing.

Om is over engineered, Reagent takes the simple-made-easy approach.

Om has extra constructor syntax and functions for dealing with cursors; that's it. I get the initial perception that Om is "over-engineered" but it just isn't.

I actually quite like the "boilerplate" for dealing with cursors.

React/Clojurescript is a funny beast. On the one hand clj is all about immutability and referential transparency. On the other hand FRP has state baked in: there has to be something to watch, after all, and even paradigms that try and sidestep this conceptually by saying "everything is a stream" (flapjax) end up dealing with state in terms of how the streams interact, under what conditions, etc.

I like the Om model because it says: OK, we're going to have to deal with state, no way around it. Is there a way we can bring sanity to the process?

Reagent has cursors too, and the latest version is quite ok.

Reagent is still very early in its development but so far much simple to use than Om ...

Reagent is very stable and has been for a long time now. Many people, myself included, are using it in production without any problems. The API has been very stable without any breaking changes as well.

I've found reagent's simplicity very appealing. If you check the github.io page for it (http://reagent-project.github.io/), you can see some short and sweet examples.

Dmitri, who runs the Reagent project, is the single most responsive OSS maintainer I've ever worked with. I highly recommend the experience.

Dan Holmsand is the man behind Reagent. I believe Dimitri maintains the overall Reagent Project? Still getting to know who's who :)

You're right, I hadn't actually paid enough attention. He's responsible for the overall project (and Luminus, obviously) but doesn't actually do that much with core reagent. (Which isn't to say he isn't extremely active...)

I only contribute some small things like the template and data bindings lib, Dan Holmsand is the brains behind the project and the one who actually maintains it. He's doing a fantastic job at that. ;)

Actual Changelog https://github.com/reagent-project/reagent/blob/master/CHANG...