ClojureScript?

[Quantisan]

Any interest in making this portable for both clj and cljs with cljx? Don't know how it might work yet, but if it does, this might save some duplicate efforts, i.e. enlive vs enfocus.

I can look into it and help out you're up for it.

[cgrand]

Hi Paul,

Work on Enliven has been a bit slow after the initial sprint. Clojurescript is my main focus at the moment (I'm refactoring the code for that purpose). However like I envision it it won't be a port of Enliven to Clojurescript. Enliven will emit some Clojurescript to dynamically (reactively) render templates. The goal is to have one template definition and run it everywhere. The initial sprint was on the static end, the current effort is on the dynamic end.

How did you envision the interaction of Enlive(n) and CLJS?

Thanks,

Christophe

PS: Sorry for the delay this message lingered in drafts for no reason.

On Mon, Jun 2, 2014 at 11:37 PM, Paul Lam [email protected] wrote:

Any interest in making this portable for both clj and cljs with cljx https://github.com/lynaghk/cljx? Don't know how it might work yet, but if it does, this might save some duplicate efforts, i.e. enlive vs enfocus.

I can look into it and help out you're up for it.

— Reply to this email directly or view it on GitHub https://github.com/cgrand/enliven/issues/7.

On Clojure http://clj-me.cgrand.net/ Clojure Programming http://clojurebook.com Training, Consulting & Contracting http://lambdanext.eu/

[Quantisan]

What do you mean "The goal is to have one template definition and run it everywhere"? I totally missed that in the readme. Would it be able to do what Enfocus does? Do you envision Enliven to work for client-side cljs projects too?

[limist]

+1, curious to hear more thoughts from @cgrand on the high-level direction questions from @Quantisan thanks.

[cgrand]

@Quantisan @limist my stated goal for Enliven (when I get time/funding) is to create a continuous "templating" system. The continuity has a double meaning: temporal and spatial. Spatial: a template can be compiled as a classic[1] server-side template or a client-side template. Temporal: a template can be compiled as a "static" client-side template or as reactive components with specific sync semantics.

How do I plan to achieve this: the template depends on a model (which is accessed/scoped by lenses), when the user "compiles" a template he/she provides a description of the "lifecycle" of each piece of data of the model. (By lifecycle I mean: server-only, server-push, client-transient, client-persistent (eg local storage), client-push, and replication/conflict strategies.) Depending on those lifecycles Enliven will compile differently different parts of the same template (static or server-only parts don't get the reactive treatment for example). So this description of the lifecycles is what controls where in the spatio-temporal continuum the template must be applied. As a bonus point dynamic pages may come prerendered with the piece of state known to the server (making ROCA-style application easier http://roca-style.org/ by @stilkov et al.).

[1] I've worked on being able to compose templates and the underlying encoding. I tested directly emitting UTF-8 bytes (skipping encoding for static parts), I experimented with directly emitting compressed output too and I also explored using (direct) bytebuffers and gather writes to reduce copying.

[cgrand]

I'm pretty sure it all sounds fuzzy and hand wavy.

[johnwalker]

I'm not sure what you mean by reactive or dynamic. Are there examples of the system you're trying to build? Also, wow!

I think that the objective is to build a templating system wherein members can be compiled by just the server, just the client, or both the client and the server, and the client can synchronize a scope when its requirements are met (lifecycle) and javascript is enabled. In the event javascript isn't available, the client at least gets the evaluated template. Let me know how on track this is.

Also, this might be of interest to others who are also catching up:

https://gist.github.com/cgrand/da6a59ee4bb0bbcd253e

[cgrand]

What's a template? A template describes a binding between representation and data. In conventional templating engines this relation is one-shot: the representation is only in sync with the data at render time.

Traditionally keeping the representation up to date was achieved through different means:

1. the user frantically clicking the Reload button
2. js fetching updated (server-rendered) fragments
3. reimplementing the presentation-data binding in a js framework (and adding various "api" endpoints to the server)
4. same as #3 but getting rid of the server-side templating
5. same as #4 but also trying to run the JS server-side to serve static pages to bots.

(I've probably forgotten a couple of options.)

By making this binding more declarative in Enliven I expect to be able to use it both server-side and client-side but also to have the client picks up where the server has left (so the server may prerender with whatever it knows from the model and the client is then in charge of updating – less "please wait, initializing" time for the user, better for SEO).

Of course it means that Enliven will have to provide way to handle events too (so as to update the model, the update to the model triggering sync and repaint).

[cgrand]

@johnwalker

I think that the objective is to build a templating system wherein members can be compiled by just the server, just the client, or both the client and the server, and the client can synchronize a scope when its requirements are met (lifecycle) and javascript is enabled. In the event javascript isn't available, the client at least gets the evaluated template. Let me know how on track this is.

That's a correct approximation however I don't promise enliven rendered templates to be fully usable for nojs clients. Just a bit less useless.