A bunch of people have asked about the timeline for Pedestal 0.3 and
we want to fill everyone in on what we're doing and why.
Pedestal is made up of two parts, Service and App. Service is a
library for building HTTP endpoints that supports routing and async
processing in a Ring-compatible way. App is a library for building
rich client apps in the browser.
The main idea in Pedestal App is that it makes sense to split
application state from rendering state, that events should be queued
up and dispatched to code that updates an application's state using
dataflow, and that as the application's state changes, instructions
are sent to the rendering layer to update the DOM. This approach gets
you out of having to decide what to do to the DOM by looking at its
current state, which gets very complex for sophisticated UIs. And it
updates the DOM incrementally, making only the necessary changes.
Since the original version of Pedestal App shipped in last March, two
other libraries have really change the landscape. The first is
core.async, which provides standard plumbing for event processing
using channels. The second is ReactJS.
At a high-level, the ReactJS model and the Pedestal model are similar:
application state is separate from rendered state. You process events
by modifying application state, then having UI components re-render
based on the updated state. The main difference in model is that,
where Pedestal App tracks changes in your application model and maps
them (via code you write) to a list of small DOM changes, ReactJS lets
you naively re-render entire portions of the UI as if you were
rendering them for the first time. Then it calculates what needs to
change in the UI and makes only the changes that are necessary. ReactJS
does this by giving your rendering code a pseudo-DOM to work with. All
actual DOM updates are managed by React itself. As with Pedestal App,
you don't have to decide what to do to the DOM by looking at its
current state - you just re-render. But unlike in Pedestal App, you
don't have to worry about how fine-grained changes to your App model
map to the UI.
So there is clearly conceptual overlap between Pedestal and ReactJS.
Further, David Nolen's work on Om has shown that ReactJS and
ClojureScript work very well together. So how do Pedestal and ReactJS
fit together, if at all? One possibility is that Pedestal starts using
ReactJS as the rendering layer, which would remove the need for
generating fine-grained UI updates (because ReactJS makes them
unnecessary). Another possibility is that React + core.async + some
atoms are sufficient to do what most people need. There are other
possibilities too - like ReactJS is useful for some types of UIs but not
others and Pedestal App should focus on those. There is only one way
to answer these questions: we need to build some real UIs with ReactJS
to gain experience with it so we can assess how it fits with the work
we've been doing.
To that end, we are doing the following:
- Splitting Pedestal App and Pedestal Service in two. Pedestal Service
will continue under the Pedestal name. Most of the work to integrate
channels with Service to support async operation is complete and so
0.3.0 of Service should be released relatively soon.
- Moving Pedestal App resources to a separate repo, and pausing
work on it at least until we gain experience with ReactJS (and
possibly some related projects like https://github.com/cgrand/enliven
). Based on that experience, we'll
decide when and how to proceed with work on Pedestal App.
These changes will be made over the next few days.
If you are putting effort into learning Pedestal App and wondering
what to do, look at ReactJS. The key concepts from Pedestal App
translate almost directly to the ReactJS world. If you dig into it,
share your experiences - as we will. We remain completely committed to
there being a great end-to-end Clojure story, including ClojureScript
UIs, wherever the solution(s) come(s) from.