[web-devel] richer client experiences
gershomb at gmail.com
Wed Jan 26 00:48:49 CET 2011
Greg Weber writes:
> AFAICT this language is less featureful than coffee-script, its only
> advantage being the syntax is slightly more haskellish.
> Of course, it does provides a technique for inserting haskell values into
> better to add these features to the more widely used coffee script using
> that part of JMacro and/or Yesod's similar template tools.
Hi! Author of JMacro here. You're right that JMacro has a few less
features than CoffeeScript. In particular, it lacks pattern matching.
Outside of that, however, most CoffeeScript features are to make
CoffeeScript more rubylike in syntax. Haskell-style anonymous lambdas
coupled with whitespace function application on their own, however,
suffice to allow exceedingly Haskell/ML-like code. JMacro can be used
shared namespace with surrounding Haskell code. So bear in mind also
that JMacro syntax is infinitely-extensible in the sense that you can
combinators which produce JMacro that can be spliced directly back
into a block of code. Jeff and I have, for instance, written a tiny
set of infix combinators for chaining jQuery selectors.
Another feature of JMacro as opposed to CoffeeScript is that almost
code-sample or snippet from the web and place it directly into your
application, refactoring it into a more functional style incrementally
and at whatever pace you want. CoffeeScript allows for "escaping" into
JMacro as it now stands is more than sufficient for the paces that
Jeff and I put it through -- and we use it all the time for the
systems that we build. That said, if there was interest from others
who wanted to use it, there are plenty of features that could be
further developed. For one, the output could be made more efficient,
and hooked into hjsmin as well. Syntax-wise, destructuring bind could
be added as well as infix composition and a pleasant sugar for partial
application. So if there are more JMacro users, and they want more
features, I'll be as responsive as possible within my time
constraints. The parser is also pretty straightforward to hack on if
you want to add anything yourself.
One reason that we haven't needed more out of JMacro is that we're
the complicated bits all into Haskell, which we communicate with via
lightweight ajax/json RPCs, with autogenerated stubs (a 'la haxr).
There's proof-of-concept code that demonstrates how to do this (with a
dependency on jQuery) in the package . Attempting to cut
dependencies down, this code is written to be generic over backends
rather than tied to any particular server/framework. So it'll take a
tiny bit of glue to get working on your stack of choice.
The really nice new stuff I've been doing isn't in the repo at all yet
-- I've been meaning to find time to abstract it out in the right way
so that it isn't too specific to one given setup. The RPCs I described
above are all served from a given directory. However, there's now a
concept of *conversations* which hold state local to a single load of
a webpage from a given client. Their RPCs are tied to the webpage
itself. This per-page state lets you write rich, stateful, web
applications which hold all the important bits in the Haskell server
and allow the browser-side client to act as a thin layer for display.
If anyone is interested in using JMacro, or, better yet, hacking on it
a bit, please let me know. Some users and/or collaborators would be a
big incentive for me to do more work on adding features and building
up the conversation/session machinery that I've been working with,
More information about the web-devel