[erlang-questions] ANNOUNCE: adapter_pattern for mochiweb/cowboy/misult and scripting language

[Michael Turner]

OK, here's a bizarrely purist, contrarian, turn-the-problem-inside-out
response to EHE, from someone who has yet to look at any existing
Erlang web frameworks in any detail:

I don't want to embed code to generate HTML *within* HTML, to be sent
to a browser. After all, what is HTML but just a clunky notation for
specifying DOM objects? No, I want to communicate with DOM objects in
the browser, having created them there in whatever way seems most
natural in Erlang terms.

To me, the most natural Erlang representation of a DOM object is the
same as for any "object": it's an Erlang process. Now, I can't have an
Erlang process in the browser itself (unless someone writes a web
browser in Erlang, or implements Erlang in the browser[*]). But I
*can* have Erlang processes on the server side, to interrogate and
update page state as if its corresponding DOM objects were all Erlang
processes.

Assuming you're still with me here: If you don't care so much about
reusing existing template libraries, the best static representation of
a web page on the server side would seem to be some kind of Erlang
record specification of the target DOM document object, describing the
page-representation process tree you'd like to build if the page were
ever instantiated. That record (and subrecords within it) might
include funs; these funs would correspond to (and ultimately be
translated to) javascript on the client side.

With most other languages, you'd blanch at the idea of creating what
might (for a large web page) end up as thousands of server-side
processes just to represent each little leaf DOM object in a browser,
with the overwhelming majority of these leaves being static DOM
elements. But spawning processes in the thousands is what Erlang eats
for a light breakfast. So maybe it's not so crazy. Or anyway, not so
crazy after some sane person takes this idea and works back to what
makes sense. (Maybe somebody already did.)

And this addresses Richard's point "Diabolic Corollary" point: This
way, you just end up writing Erlang, and only Erlang, and can enjoy
full tool support.

-michael turner

[*] Yes, I'm aware of recent work on the latter, mentioned recently on the list.


On Mon, Feb 20, 2012 at 4:12 PM, Ulf Wiger <ulf@REDACTED> wrote:
>
> On 20 Feb 2012, at 02:19, Richard O'Keefe wrote:
>
> None of the HTML or XML editing, checking, or validation tools available to
> me knows anything about Erlang syntax, at least not when processing HTML
> or XML, and similarly,
> none of the Erlang editing, checking, or validation tools available to me
> knows anything about HTML or XML, at least not when processing Erlang.
>
>
> And I believe this was one reason why people have moved away from embedded
> template languages and gone for things like Enlive and PURE JS
> (http://beebole.com/pure/).
>
> As a curiosity, the company that developed PURE JS also uses Erlang (for the
> backend).
>
> http://beebole.com/blog/erlang/why-erlang/
>
> BR,
> Ulf W
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>