[erlang-questions] Thoughts on EHE - the PHP killer

[Joe Armstrong]

Thoughts on EHE

I'm playing with a little language for writing web applications.
It's called EHE. All it is HTML with embedded Erlang

I like EHE very much since it is the simplest possible way of embedding
Erlang in a web page - I can think of no simpler method - the learning
gap (if you know Erlang and HTML) is pretty near zero. For me
simple = good.

What is EHE?

An EHE script is just a file with the extension .ehe. The file
contains HTML or XHTML with embedded Erlang.

The embedding syntax is

<?e ....... ?>

This syntax is chosen since this notation corresponds to an XML processing
instruction.

Inside the block is sequence of Erlang expressions.

The replacement value of the block is the last value of the sequence is
just the last value in the sequence, which must be an IO list.

Binding are propagated forwards between blocks.

Here's an example

<h1>Hello</h1>

<?e Name ="joe", "" ?>

<p> Hello <?e Name ?>

The first block binds the variable Name and injects "" into the text
The second block injects "joe" into the text.

Communicating with the environment:

Inside EHE the global variable SYS provides a bridge to the outside world.

We can imagine a library of useful functions that change the state of the
environment - like:

<?e SYS:get_db(Key) ?>
<?e SYS:put_db(Key, Value) ?>

<?e SYS:set_header(Header, Value) ?>
...

and so on

SYS is a parametrised module that is configured *outside* EHE - so
we can change
the database later *without* changing the EHE code.

There is an implementation of EHE at

https://github.com/joearms/adapter_pattern

(actually there is no SYS module in the git hub code, just an
object called Req)

Question: Do we need more than this in an embedded language.

On part of me says NO WAY - you have the full power of erlang at
your disposal.

Another part says

<? if_true_skip_block(X), ""?>
...
<? ... ?>

Might mean if X is true then omit the block of HTML immediately following
the erlang code block.

The problem with this is that it leads to a half-baked badly thought out
mess of language and a slippery slope where we want to add just one
more feature.

For this reason I would suggest that EHE only has the semantics I
have suggested
and nothing else.

Note - while EHE is interpreted it can easily be compiled if efficiency
is a problem.

Now the next question - what are the SYS functions:

SYS:lookup(Key) -> {ok, Value} | error

SYS is a parametric module that bridges you into Erlang - but what
functions should it
support?

/Joe
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Dmitry Kolesnikov]

Hello Joe,

This looks interesting! One of my worries is that it is too late for such language.
You are absolutely right about the gap in between erlang and xHTML UI and these solution would definitely facilitate but ....

xHTML UI is not only the bindings with run time. It is important to ensure availability of templates. erlydtl addresses this issue by building a compatibility with Python Django templates. From my side, I have been investigating an option to "compile" PHP templates into Erlang code but did not progressed due to time constrains.

If you are targeting a wide adoption of EHE then you should work out this aspect.... However, EHE looks cool and I shall try it in my UI projects...

Best Regards,
Dmitry

[Matti Oinas]

Hi Joe,

This is really great. Now it is simpler to take old page layout from PHP
sites and rewrite the application using Erlang.

There is one big problem with EHE, PHP, Django, ErlyDTL, etc and it is
that the template isn't plain HTML. Any of these needs some kind of
special syntax to inserted into HTML to control the generation of final
output.

Enlive (https://github.com/cgrand/enlive) solves this problem in a
really nice way. Enlive templates are nothing but plain HTML. This is a
big advantage because many times the HTML templates are written by
graphical designers. When using PHP I have to modify the templates to
insert PHP code to right places to make it work. It is the same with
django, erlydtl and ehe. When template is updated then I have to do this
again. With enlive I could just replace the old template with the new
one and no other changes are needed.

Template library like enlive can also solve most XSS vulnerabilities
without any help from developer because the library knows the context
where the dynamic data is going and can use proper quoting for that context.

In PHP and EHE it is easy to create XSS vulnerabilities.

<div id="<?e Id ?>">...</div>

If Id string contains " character then there is XSS vulnerability.
Developers must remember to escape data before using it. Enlive like
template library can execute proper escape functions because it is aware
of the context where that data is going to be inserted. ErlyDTL makes
automatic escapes, but the defaults aren't always enough because HTML is
a pretty complex beast that requires different characters escaped
depending on the context. Developer doesn't need to escape the data
because library makes it automatically so no more XSS vulnerabilities
because developer forgot to escape some data before it was inserted into
template.

Biggest problem with enlive is that it is written with clojure. Not that
clojure isn't great but it still isn't erlang.

I think it is time to rewrite some PHP code with erlang and EHE.

Matti

[Ulf Wiger]

On 18 Feb 2012, at 13:31, Matti Oinas wrote:

Biggest problem with enlive is that it is written with clojure. Not that clojure isn't great but it still isn't erlang.

I agree that this is a great way to keep the HTML/CSS side pure, and still have lots of power to enhance it with dynamic content.

There is an (experimental?) xmerl_sax_parser-based module that is able to parse most existing HTML - certainly enough to handle the kind of templates one should be able to expect from a professional web designer*. With it, and perhaps something like xmerl_xs, it shouldn't be that hard to come up with an enliven-inspired lib in Erlang.

BR,

Ulf W

* I think this is one of the harder problems in the mix: accepting more or less malformed HTML. I know yaws has a HTML parser as well (yaws_html), but don't know how robust it is.

[Joe Armstrong]

On Sat, Feb 18, 2012 at 3:26 PM, Ulf Wiger <u...@feuerlabs.com> wrote:
>
> On 18 Feb 2012, at 13:31, Matti Oinas wrote:
>
> Biggest problem with enlive is that it is written with clojure. Not that
> clojure isn't great but it still isn't erlang.
>
>
> I agree that this is a great way to keep the HTML/CSS side pure, and still
> have lots of power to enhance it with dynamic content.

I was thinking about this: In theory having a watertight
barrier between logic and presentation seems like
a good idea - but is it?

I was looking for a good template language that separates logic from
control so I looked around a bit. I looked at
wordpress (as far as I can see it's just PHP) so is phpBB
there are loads of different styles/skins for this so they must be
doing something right. Then I looked at the tumblr template language -
there are loads of nice templates for this, but this
language was highly structured to follow what I assumed was
the tumblr internal database schemas.

I think I see a pattern here. I have a similar problem with
markup language - I have implemented half a dozen markup
languages but at the end of the day, when I want to write a book I
turn to LaTeX or docbook or an XML markup.

The markup languages and templating languages get you a
long way very quickly. They solve 95% of the problem immediately (or
98% or something) - its the 5% or 2% in the
tail that's the problem. Simple markup languages are useless when you
find you want really beautiful output - then you have to sweat blood.

Same for web-sites - templating is fine until you want to do
something that the template writer had not imagined.

Full Erlang embedded in Html solves my problem - it might
not be pretty - it might not have strict separation of issues
it might not separate logic from control - but it is *very* powerful.

I keep hearing about script-kiddies who can understand
HTML but not "coding" (whatever that is) or people who
can do html but not css so this is not for them. I'm aiming at
people who are perfectly happy with mixing erlang/html/css/javascript
and I'm not so worried about
inversion of control or separation of logic and presentation.

This ehe that I mentioned - I just write <?e Erlang ...?>
slap bang in the middle of *anything* - ie HTML, CSS,
Javascript, C, java, makefiles, LaTeX - anywhere

No mess no problems easy semantics - but not separation
of control and logic and presentation.

I have been thinking about this for a very very long
time - and 100% separation of issues is incredibly difficult.

Some I'm back to embedded Erlang + parameterised modules
and erlhive thinking ...

/Joe

>
> There is an (experimental?) xmerl_sax_parser-based module that is able to
> parse most existing HTML - certainly enough to handle the kind of templates
> one should be able to expect from a professional web designer*. With it, and
> perhaps something like xmerl_xs, it shouldn't be that hard to come up with
> an enliven-inspired lib in Erlang.
>
> BR,
> Ulf W
>
>
> * I think this is one of the harder problems in the mix: accepting more or
> less malformed HTML. I know yaws has a HTML parser as well (yaws_html), but
> don't know how robust it is.

[Ulf Wiger]

On 18 Feb 2012, at 16:13, Joe Armstrong wrote:

Some I'm back to embedded Erlang + parameterised  modules
and erlhive thinking ...

Erlhive is the idea that won't die. :)

I keep coming back to how that was really, in many ways, a very, very promising idea.

There were some really hard obstacles in actual implementation, though. :)

It was also probably one of the most flagrant abuses of parameterized modules to-date. :)

BR,

Ulf W

[Ulf Wiger]

On 18 Feb 2012, at 16:13, Joe Armstrong wrote:

I was thinking about this: In theory having a watertight
barrier between logic and presentation seems like
a good idea - but is it?

To quote Yogi Berra (or Einstein, or van de Snepscheut):

"In theory there is no difference between theory and practice. In practice there is."

I've found that mixing Erlang into the Web design part drastically reduces the pickings when you need a professional web designer. The erlang community to-date hasn't attracted the kind of people who live to design beautiful HTML pages.

The cousin of this train of though is the idea to put Node.js on the server. It makes perfect sense in one way: JavaScript is the one programming language a Web designer MUST be good at. Unfortunately, Node.js is a very bad server-side programming environment.

Still, the question is how much that hurts you. PHP isn't a great language, but great websites have been built with it, mainly because enough great web designers make the effort to learn PHP.

Of course, for a team of Erlang programmers, the fact that they may be poor web page designers to start with isn't exactly helped by the fact that they have to build their web pages in a programming language they don't master well. OTOH, they can be greatly helped by stealing good open source web designs from the web. Doing so should be easier with an enlive-style approach.

Also, if you build a functional prototype, you can get away with a "developer-ugly" web UI, as long as you can hire a pro to make it beautiful later on. If you can stick to mainstream web design techniques as closely as possible, this step will be easier (or less impossible) to take.

BR,

Ulf W

[Tristan Sloughter]

I've found that mixing Erlang into the Web design part drastically reduces the pickings when you need a professional web designer. The erlang community to-date hasn't attracted the kind of people who live to design beautiful HTML pages.

And not just that but reusing components from others and debugging is complicated by embedding code in the client side markup.

That is why I've found using a client side MVC (in Coffeescript so its not as painful) with templates that are pure HTML (like Batman.js does, http://batmanjs.org/) and interfacing with Erlang only for dynamic data exchange with JSON is the best approach.

This approach allows the frontend to be developed separately with only worrying about what format the data sent and received must be. Now your frontend developer can even just throw test JSON into a basic Node server to test their work. And since its pure HTML templates you can even view the site just fine without any server running.

Now you can use any webserver and CDN to serve up your static frontend and your Erlang code not having to deal with templating or serving up static files.

Though I am finding Opa (http://opalang.org) and Play! with Scala (http://www.playframework.org/2.0) intriguing and they do not follow these rules at all :)

Tristan

[Matti Oinas]

On 02/18/2012 05:13 PM, Joe Armstrong wrote:
> In theory having a watertight
> barrier between logic and presentation seems like
> a good idea - but is it?

Sometimes it is and sometimes isn't. Most of the time at work I'm not
the one who writes the HTML. They just send these HTML templates to me
and I'll add necessary PHP code to these templates. With total
separation of logic and presentation I could just replace old html
template with new one without any modifications. It probably wouldn't
work every situations but in these situations I could just revert back
to the old way of inserting PHP into HTML. If this separation would work
even 80% of situations then I sure would benefit from that.

We need things like EHE for maximum flexibility, but enlive like
template engine would help us also a lot. I wouldn't mind mixing these
two into same application. Using enlive like engine when possible and
using EHE when other engine doesn't provide enough flexibility. When
writing HTML myself then enlive like template doesn't offer much
compared to EHE. Only thing enlive style engine could offer as a benefit
compared to EHE is automatic escaping for the dynamic content. I know
how things need to be escaped that they are safe to use, but I do forget
to do that escaping sometimes and will introduce XSS vulnerabilities to
the code. Even if vulnerability couldn't be used anything serious it
could still damage the reputation of the service and service could lose
its users.

Xmerl could be used to parse these templates if only XHTML would be
supported. We could also easily validate these templates for correct
markup using XML validators.

Matti

[Steve Strong]

+1, this is also my preferred way for building HTML; it keeps the server very clean (just a json Api), and I find that a good JavaScript library can keep the ui code well structured. It does put a requirement on JavaScript being enabled, so it may not be appropriate for every site, but if you're happy with that restriction then I think it's hard to beat.

Cheers,

Steve

Sent from my iPhone

_______________________________________________

[Gordon Guthrie]

+1 ditto 

There are still internationalisation issues to resolve but pure Ajax MVC is so much better than rendering.

Gordon

Sent from my iPhone

[Ulf Wiger]

On 18 Feb 2012, at 17:33, Matti Oinas wrote:

Xmerl could be used to parse these templates if only XHTML would be supported. We could also easily validate these templates for correct markup using XML validators.

Like I wrote, there is an unreleased version of xmerl_sax_parser with a 'html' mode, which handles most of the usual HTML badness (i.e. non-well-formed XML).

I would like to suggest that the OTP team release it. It doesn't have to be perfect. When parsing html, there is no such thing as perfect.

There is also the yaws_html module, which I admit that I've never used.

BR,

Ulf W

[Matti Oinas]

On 02/18/2012 07:21 PM, Ulf Wiger wrote:
> Like I wrote, there is an unreleased version of xmerl_sax_parser with
> a 'html' mode, which handles most of the usual HTML badness (i.e.
> non-well-formed XML).

Sorry, I forgot to quote you in my previous post and there was also a
major error in my text. I meant to say that if template engine supports
only XHTML syntax then xmerl will do as it is at the moment because only
XML parser is needed. That would be enough for me. I think I'll have to
try to write an erlang version of enlive library and allow only XHTML
syntax. Would be a great exercise and erlang doesn't have that kind of
template engine at the moment as far as I know.

> I would like to suggest that the OTP team release it. It doesn't have
> to be perfect. When parsing html, there is no such thing as perfect.
> There is also the yaws_html module, which I admit that I've never used.

Decent HTML parser would be great. I'm currently maintaining an
application that allows users to use normal HTML syntax to format the
content they send to the service. HTML parser is used to do some cleanup
and possibly modify the content a bit before it is stored into database.
Xmerl html support sounds really promising. Allready using xmerl to
parse XML in my erlang applications so this would remove the need for
external module for parsing HTML.

I have to try to rewrite my HTML cleanup code using the yaws_html module
while waiting the xmerl html parser. The rest of the application is easy
to rewrite using erlang so I might be able to get rid of PHP. Once this
is done I could get the new erlang version accepted and running in
production and eventually everyone would win. PHP isn't a good choice if
the application is run on several machines and every machine must be
able to communicate with others.

[Wes James]

On Sat, Feb 18, 2012 at 4:13 AM, Joe Armstrong <erl...@gmail.com> wrote:
> Thoughts on EHE
>
> I'm playing with a little language for writing web applications.
> It's called EHE. All it is HTML with embedded Erlang

<snip>

Isn't this what is in YAWS already?

http://yaws.hyber.org/dynamic.yaws

-wes

[Tim Watson]

Major +1 on this point. Joe, what is the difference between this:

<div>
<?e Erlang... >
</div>

and this:

<div class="make_this_pretty"/>

plus maybe a bit of config like this:

{template, "mypage.html", mymod}

with a bit of this:

make_this_pretty(Dom, BoundData) -> ....

-----

Because that, fundamentally, gets you away from having a web page that
a designer will puke over, and still gets you the full power of Erlang
where you absolutely need it. Obviously if you generate a hell of a
lot of content in the Erlang code, then the designer needs to vet that
and make *it* pretty, by which time you might as well use a templating
language that supports dynamic includes (e.g., within a for-each
loop). This approach is used by a number of frameworks (both client
and server side), the first of which I came across was Apache Wicket.

Also, I'm not convinced that making things truly gorgeous is outside
of what's possible with the Django Templating Langauge which ErlyDTL
implements most of. There are some really beautiful sites out there
built with it, and it's all the easier for designers because there's
very few code constructs for them to 'learn' (or at least need to ask
about) and this works well in practise for a lot of people. If
anything, I think a Template View works quite nicely as a pattern.

[Tim Watson]

On 18 February 2012 17:20, Gordon Guthrie <gor...@hypernumbers.com> wrote:
> +1 ditto
>
> There are still internationalisation issues to resolve but pure Ajax MVC is
> so much better than rendering.
>

It's not quite that simple in practise though is it. We have a large
(some would call it 'enterprise' but I hate that word) application
that services many client applications in front of a meta-data
registry/repository. The primary interface for this is a RESTful web
service exposure, although we do offer other interfaces (SOAP and
AMQP) and we serve up both JSON and XML.

In serving up XML, we have found that numerous clients want a slightly
(or sometimes significantly) different representation of the data, so
we allow some post processing of the request using XSLT before it is
delivered to the client. The clients are almost exclusively web
applications using Ajax calls to fetch the data and chewing on it in
various ways (depending on what javascript++ nonsense the UI is
implemented with).

So in that case, we've got your 'pure Ajax MVC' going on - although
I'm not convinced I really understand your use of MVC in this case,
but then I think it's a generally confusing and misused pattern name
anyway - but we also have Template View going on in the server.

[Tim Watson]

On 18 February 2012 20:05, Wes James <comp...@gmail.com> wrote:
> On Sat, Feb 18, 2012 at 4:13 AM, Joe Armstrong <erl...@gmail.com> wrote:
>> Thoughts on EHE
>>
>> I'm playing with a little language for writing web applications.
>> It's called EHE. All it is HTML with embedded Erlang
>
> <snip>
>
>
> Isn't this what is in YAWS already?
>
> http://yaws.hyber.org/dynamic.yaws
>

It kind of is isn't it, although I must admit I'm a bit confused by
the relationship between the erlang code and the surrounding HTML,
especially as none of the examples seems to have any html around them.
What's the difference between .yaws files and an appmod? The latter
'feels' more natural to me, although clearly I don't really understand
how the former works.

[Dale Harvey]

PHP 'died' along time ago with python (django) and Ruby (rails) and more recently Node.js or client side 'MVC'

Every one of those moved away from embedding the host language in the templates and used a basic interoperable templating system because embedded php / erlang just generated terrible code

erlydtl as I remember was quite nice

[Wes James]

On Sat, Feb 18, 2012 at 5:19 PM, Tim Watson <watson....@gmail.com> wrote:
> On 18 February 2012 20:05, Wes James <comp...@gmail.com> wrote:
>> On Sat, Feb 18, 2012 at 4:13 AM, Joe Armstrong <erl...@gmail.com> wrote:
>>> Thoughts on EHE
>>>
>>> I'm playing with a little language for writing web applications.
>>> It's called EHE. All it is HTML with embedded Erlang
>>
>> <snip>
>>
>>
>> Isn't this what is in YAWS already?
>>
>> http://yaws.hyber.org/dynamic.yaws
>>
>
> It kind of is isn't it, although I must admit I'm a bit confused by
> the relationship between the erlang code and the surrounding HTML,
> especially as none of the examples seems to have any html around them.
> What's the difference between .yaws files and an appmod? The latter
> 'feels' more natural to me, although clearly I don't really understand
> how the former works.

How I think of .yaws vs appmods:

.yaws files are like .php files. You can have html content with
erlang interspersed throughout the html with <erl> </erl>.

appmods are erlang modules where in yaws.conf you can control the url
paths that run the appmod web application

more details on appmods here -> http://yaws.hyber.org/appmods.yaws

-wes

[Steve Vinoski]

On Sat, Feb 18, 2012 at 10:20 PM, Wes James <comp...@gmail.com> wrote:
> On Sat, Feb 18, 2012 at 5:19 PM, Tim Watson <watson....@gmail.com> wrote:
>> On 18 February 2012 20:05, Wes James <comp...@gmail.com> wrote:
>>> On Sat, Feb 18, 2012 at 4:13 AM, Joe Armstrong <erl...@gmail.com> wrote:
>>>> Thoughts on EHE
>>>>
>>>> I'm playing with a little language for writing web applications.
>>>> It's called EHE. All it is HTML with embedded Erlang
>>>
>>> <snip>
>>>
>>>
>>> Isn't this what is in YAWS already?
>>>
>>> http://yaws.hyber.org/dynamic.yaws
>>>
>>
>> It kind of is isn't it, although I must admit I'm a bit confused by
>> the relationship between the erlang code and the surrounding HTML,
>> especially as none of the examples seems to have any html around them.
>> What's the difference between .yaws files and an appmod? The latter
>> 'feels' more natural to me, although clearly I don't really understand
>> how the former works.
>
> How I think of .yaws vs appmods:
>
> .yaws files are like .php files.  You can have html content with
> erlang interspersed throughout the html with <erl> </erl>.
>
> appmods are erlang modules where in yaws.conf you can control the url
> paths that run the appmod web application
>
> more details on appmods here -> http://yaws.hyber.org/appmods.yaws

To paraphrase:

.yaws file: sprinkle a little Erlang into your HTML
appmod: sprinkle a little HTML/XML/JSON/whatever into your Erlang

An appmod is like a servlet, I suppose. It's code that handles
requests made to a configured portion of the server URI space (the
path can be "/" to handle all requests to that server), and can do
pretty much anything it needs to in order to fulfill each request.

In my own development work with yaws, I use appmods almost exclusively
because they're totally flexible.

--steve

[Ulf Wiger]

Tuncer also pointed out that there is Mats Cronqvist's trane:

https://github.com/massemanet/trane

Which also aims to parse "real-world" HTML. Looks interesting.

BR,

Ulf W

[Matti Oinas]

On 02/19/2012 02:29 AM, Dale Harvey wrote:
> PHP 'died' along time ago with python (django) and Ruby (rails) and
> more recently Node.js or client side 'MVC'
>
> Every one of those moved away from embedding the host language in the
> templates and used a basic interoperable templating system because
> embedded php / erlang just generated terrible code

How come django is better than embedding PHP or erlang code into
template? Django just adds one language so instead of 2 you must use 3
to get a working template. It still fails to separate logic from the
presentation so embedding is a better option because you have one less
language to learn and you have all the power of the embedded language. I
have used many different template systems and I always end up using
plain old embedding when I'm writing software with PHP. Only thing that
is better with django than with embedded PHP is that the template code
looks a litle bit better in editor.

Matti

[Joe Armstrong]

(( Interesting - I haven't actually tried doing it this way -
This seems like how jquery does things only on the server

I was wondering about viewing pages as processes and sending them messages.

ie <div id="mynicetag"></div>

And in Erlang mynicetag ! {content, "<p>hello</p>"}

But never got round to implementing this ))

))

To answer your question the difference is all the code is in one place - I don't
have to go and look somewhere else to see the code.

Anyway I write all the html and erlang myself I don't live in
this world where one guy writes the html and another writes the code
and another writes the css and another writes the js and another
writes the bla bla bla

I'm just making a tool for me - the problem with programming is that
solving problems is one thing but solving problems subject to the
condition that the solution is beautiful and maintainable is really
really difficult.

My problem is not making web sites that work it's making
them with beautiful code.

/Joe

[Adam Rutkowski]

On Feb 19, 2012, at 8:37 AM, Matti Oinas wrote:

> How come django is better than embedding PHP or erlang code into template? Django just adds one language so instead of 2 you must use 3 to get a working template.

You can have an UI guy providing templates and he wouldn't be able to erase your hard drive with it.

Or even a team of them. They also don't want to know Python/Erlang/PHP/whatever. They will probably learn a dozen of templating markup commands though.

I personally like how Jinja handles things. http://jinja.pocoo.org/

--
AR

[Tim Watson]

On 19 February 2012 03:39, Steve Vinoski <vin...@ieee.org> wrote:
> To paraphrase:
>
> .yaws file: sprinkle a little Erlang into your HTML
> appmod: sprinkle a little HTML/XML/JSON/whatever into your Erlang
>
> An appmod is like a servlet, I suppose. It's code that handles
> requests made to a configured portion of the server URI space (the
> path can be "/" to handle all requests to that server), and can do
> pretty much anything it needs to in order to fulfill each request.
>
> In my own development work with yaws, I use appmods almost exclusively
> because they're totally flexible.
>
> --steve

Thanks steve, that was the understand I had come to from looking at
what's on the site. What I haven't quite figured out is how the stuff
in an out/1 function gets interspersed with the surrounding HTML and
what happens when there are multiple out/1 definitions and so on. But
frankly, I'm *much* more likely to use appmods anyway, as like you say
they're a lot more like a servlet.

I think I might go away and wire up some
https://github.com/hyperthunk/annotations with so that you can write a
handler that takes parts of the request URL and other bits from the
Arg record declaratively. I think it will be quite easy to write an
appmod that uses this to reroute the request, giving me something that
looks a bit like this:

-controller({"/accounts/{account_type}", 'POST', include_body}).
get_account(AccountType, PostBody, YawsArg) ->
....

-controller({"/accounts/{account_type}/{account_number}/", 'GET'}).
get_account(AccountType, AccountNum, YawsArg) ->
....

Obviously this isn't as cool as a webmachine-a-like running on YAWS,
but I *think* I can make it work quite easily and it makes for more
convenient mapping of URLs to controller/handler module + function.

Next question I have is, how hard would it be to do something like a
servlet filter in YAWS? I could do this quite well using annotations -
that's how ErlangWeb does it, albeit with macros instead - but is that
the best way? It would look something like this (and is quite easy to
implement using annotations):

-secured({auth_provider, oauth}).
-controller({"/accounts/{account_type}/{account_number}/", 'GET'}).
get_account(AccountType, AccountNum, YawsArg) -> ....

Is there something else in YAWS like appmod that'll do a filter chain,
or am I better off using annotations?

Cheers,

Tim

[Tim Watson]

On 19 February 2012 08:42, Joe Armstrong <erl...@gmail.com> wrote:
> (( Interesting - I haven't actually tried doing it this way -
> This seems like how jquery does things only on the server
>
> I was wondering about viewing pages as processes and sending them messages.
>
> ie  <div id="mynicetag"></div>
>
> And in Erlang    mynicetag ! {content, "<p>hello</p>"}
>
> But never got round to implementing this ))
>
> ))

Interesting concept. Either way, I think a separation like that would
appeal to many, although I suspect templating is the popular approach
nowadays.

>
> To answer your question the difference is all the code is in one place - I don't
> have to go and look somewhere else to see the code.
>

That isn't always beneficial though is it. Simplicity is best for sure
- I'm definitely with Dijkstra on that one - but even the agile maxim
"do the simplest thing that can possibly work" has to be balanced with
the right factors. For example, you don't put all you code into just
one module, because once a module has more than one axis for change
then it becomes harder to manage and maintain. The same is true for
the UI surely?

> Anyway I write all the html and erlang myself I don't live in
> this world where one guy writes the html and another writes the code
> and another writes the css and another writes the js and another
> writes the bla bla bla
>

And that is quite a rare thing in most medium to large teams and
almost completely unheard of in a large enterprise.

> I'm just making a tool for me - the problem with programming is that
> solving problems is one thing but solving problems subject to the
> condition that the solution is beautiful and maintainable is really
> really difficult.
>

But you're not just making a tool for you if you're promoting it as
something we should standardise on for all web servers.

> My problem is not making web sites that work it's making
> them with beautiful code.

My problem is that I can make a web page functional, but making it
look 'nice' is like black magic to me. :)

[Tim Watson]

On 19 February 2012 10:52, Adam Rutkowski <adam.ru...@jtendo.com> wrote:
>
> On Feb 19, 2012, at 8:37 AM, Matti Oinas wrote:
>
>> How come django is better than embedding PHP or erlang code into template? Django just adds one language so instead of 2 you must use 3 to get a working template.
>
> You can have an UI guy providing templates and he wouldn't be able to erase your hard drive with it.
>

More to the point, most developers I've come across seem to think that
code mixed with markup is an anti-pattern - admittedly these are
people who wouldn't touch PHP with a barge pole. I seem to remember
reading someone who compared the relationship between this and well
designed code with that of professional wrestling to real sport. The
tendency is that the 'script-let' approach makes both the code and
markup harder to read and comprehend despite their proximity and
obvious connection in context, encourages lazy developers to allow
business logic to become interspersed with presentation logic, makes
it harder to test both (certainly from a unit testing point of view)
and generally sucks from a maintenance perspective.

I mean for crying out loud, most people who're working on the pure
client side of web development with js libraries like
backbone/jQuery/etc are trying really hard not to mix up the content
and the layout, with backbone going as far as to separate the
model/backend, presentation logic (controllers) and rendering (views).
As I've said previously, I'm not a huge fan of MVC as a pattern, but
the premise upon which it is based is a good one even if the solution
is a bit over complex IMO.

Doing what's simple isn't always the same as doing what seems obvious,
which when I hear 'do the simplest thing that can possibly work' makes
me ask 'but is this *really* the simple thing to do?' Dijkstra, who
was obsessed by simplicity, also claimed that 'elegance' is not a
dispensable luxury but a quality that determines between success and
failure. I don't find anything 'elegant' about embedding code inside
of web pages, and that's not an aesthetic judgement, but one that
comes from working with medium to large, multi-disciplinary teams,
where 'sites' might have hundreds or even thousands of different views
and considerable logic behind many of them. In an environment like
that, especially when the system(s) are business critical and/or
customer facing, you fight for your life to keep a strict separation
of concerns, or you end up failing because of the inherent complexity
and loose your reputation as a team lead as well as your bonus.

[Tim Watson]

To clarify...

On 19 February 2012 14:17, Tim Watson <watson....@gmail.com> wrote:
>
> Obviously this isn't as cool as a webmachine-a-like running on YAWS,
> but I *think* I can make it work quite easily and it makes for more
> convenient mapping of URLs to controller/handler module + function.
>

What I meant there is a more convenient mapping than an appmod -
obviously it's not as good as the webmachine approach to routing!

[Matti Oinas]

On 02/19/2012 09:29 PM, Tim Watson wrote:
> I don't find anything 'elegant' about embedding code inside
> of web pages, and that's not an aesthetic judgement, but one that
> comes from working with medium to large, multi-disciplinary teams,
> where 'sites' might have hundreds or even thousands of different views
> and considerable logic behind many of them. In an environment like
> that, especially when the system(s) are business critical and/or
> customer facing, you fight for your life to keep a strict separation
> of concerns, or you end up failing because of the inherent complexity
> and loose your reputation as a team lead as well as your bonus.

That is true that you want to keep view separated but that is where
django and others fail. View still contains code like

{% for match in matches %}
<div style="background-color:
{% ifchanged match.ballot_id %}
{% cycle "red" "blue" %}
{% else %}
grey
{% endifchanged %}
">{{ match }}</div>
{% endfor %}

That is equally ugly with embedded code and it contains logic. Even
worse is that it added one extra language but still failed to separate
logic from the view.

Enlive on the other hand uses plain HTML templates which are transformed
with the help of CSS selectors. There is no logic in HTML template, only
plain old HTML. Tranformation code defines what elements will be left
and what elements contains what information.

http://cleancode.se/2011/01/04/getting-started-with-moustache-and-enlive.html

Now we have separated the view from logic and it is really simple to
change templates. That is a library that I would like to see written in
erlang.

[Tim Watson]

On 19 February 2012 20:17, Matti Oinas <matti...@gmail.com> wrote:
> On 02/19/2012 09:29 PM, Tim Watson wrote:
>
> That is true that you want to keep view separated but that is where django
> and others fail. View still contains code like
>
> {%  for  match  in  matches  %}
>    <div  style="background-color:
>        {%  ifchanged  match.ballot_id  %}
>            {%  cycle  "red"  "blue"  %}
>        {%  else  %}
>            grey
>        {%  endifchanged  %}
>    ">{{  match  }}</div>
> {%  endfor  %}
>
>
> That is equally ugly with embedded code and it contains logic. Even worse is
> that it added one extra language but still failed to separate logic from the
> view.
>

At least it is *presentation logic* and I could argue this both ways.
I agree that code isn't particularly elegant, but at least it is
specifically 'about' the rendering.

> Enlive on the other hand uses plain HTML templates which are transformed
> with the help of CSS selectors. There is no logic in HTML template, only
> plain old HTML. Tranformation code defines what elements will be left and
> what elements contains what information.
>
> http://cleancode.se/2011/01/04/getting-started-with-moustache-and-enlive.html
>
> Now we have separated the view from logic and it is really simple to change
> templates. That is a library that I would like to see written in erlang.

Yes I agree this is a far cleaner approach, and you will see that it
is very similar to what I proposed to Joe in a previous message on
this thread, although at the time I hadn't bothered to look at enlive
in any detail. Having spent a little time looking at enlive, I think
the approach is very neat and that it would be relatively easy to do
this in Erlang, although you'll need a 'non-strict' parser such as
https://github.com/massemanet/trane and of course the supporting
libraries for generating/munging HTML content using a nice API.

[Steve Vinoski]

On Sun, Feb 19, 2012 at 9:17 AM, Tim Watson <watson....@gmail.com> wrote:
> Next question I have is, how hard would it be to do something like a
> servlet filter in YAWS? I could do this quite well using annotations -
> that's how ErlangWeb does it, albeit with macros instead - but is that
> the best way? It would look something like this (and is quite easy to
> implement using annotations):
>
> -secured({auth_provider, oauth}).
> -controller({"/accounts/{account_type}/{account_number}/", 'GET'}).
> get_account(AccountType, AccountNum, YawsArg) -> ....
>
>
> Is there something else in YAWS like appmod that'll do a filter chain,
> or am I better off using annotations?

There's really nothing like servlet filters. I guess the closest thing
-- admittedly not very close, though -- is the ability to add a
rewriter, which sits in the dispatch path, takes in the #arg, and can
produce a modified one if it wants to.

Just off the top of my head, it seems like one could do something like
servlet filters with an appmod, I think. Register it on /, and give it
it's own dispatching configuration and allow plug-ins to register into
its request-reply path. It could then receive each request, arrange
the ultimate dispatch target (an appmod, a .yaws page, even a file) at
the end of plug-in chain, dispatch the #arg into the chain, and then
deliver the eventual reply back into Yaws. No doubt this would be
easier if it were built into Yaws, though, since reusing the existing
dispatch logic would be easier than writing your own.

--steve

[Tim Watson]

On 20 February 2012 12:23, Steve Vinoski <vin...@ieee.org> wrote:
>
> There's really nothing like servlet filters. I guess the closest thing
> -- admittedly not very close, though -- is the ability to add a
> rewriter, which sits in the dispatch path, takes in the #arg, and can
> produce a modified one if it wants to.
>
> Just off the top of my head, it seems like one could do something like
> servlet filters with an appmod, I think. Register it on /, and give it
> it's own dispatching configuration and allow plug-ins to register into
> its request-reply path. It could then receive each request, arrange
> the ultimate dispatch target (an appmod, a .yaws page, even a file) at
> the end of plug-in chain, dispatch the #arg into the chain, and then
> deliver the eventual reply back into Yaws. No doubt this would be
> easier if it were built into Yaws, though, since reusing the existing
> dispatch logic would be easier than writing your own.
>

Yes and presumably to do your webmachine-a-like you'll be using the
internal dispatch like this anyway, right? But it would definitely be
better for use the internal dispatch logic. Also is there a straight
API call back into YAWS for serving a request, especially a file one
(so that sendfile will kick in if configured) ?

BTW thanks for the feedback, this has been very useful and I'm going
to start playing with YAWS properly now I think.

[Edmond Begumisa]

On Mon, 20 Feb 2012 01:17:19 +1100, Tim Watson <watson....@gmail.com>
wrote:

> On 19 February 2012 03:39, Steve Vinoski <vin...@ieee.org> wrote:
>> To paraphrase:
>>
>> .yaws file: sprinkle a little Erlang into your HTML
>> appmod: sprinkle a little HTML/XML/JSON/whatever into your Erlang
>>
>> An appmod is like a servlet, I suppose. It's code that handles
>> requests made to a configured portion of the server URI space (the
>> path can be "/" to handle all requests to that server), and can do
>> pretty much anything it needs to in order to fulfill each request.
>>
>> In my own development work with yaws, I use appmods almost exclusively
>> because they're totally flexible.
>>
>> --steve
>
> Thanks steve, that was the understand I had come to from looking at
> what's on the site. What I haven't quite figured out is how the stuff
> in an out/1 function gets interspersed with the surrounding HTML and
> what happens when there are multiple out/1 definitions and so on.

Say you have a file:

...blah1...
<erl>.. out/1...</erl>
...blah2...
<erl>.. out/1...</erl>
...blah3...

IIRC, the individual <erl></erl> tags within the same file are compiled
into seperate Erlang modules at runtime when the file is first requested
and the compiled modules are cached. out/1 is then called for each module
and the outputs combined with the text outside the <erl> tags. Something
like...

send(Blah1),
send(mod1:out(Arg)),
send(Blah2),
send(mod2:out(Arg)),
send(Blah3)

This is a great idea. Your annotations tools would be really useful here.

What would REALLY be cool is a set of general-puprose reusable annotations
specifically for yaws, not only for code but for default content too.

- Edmond -

>
> Cheers,
>
> Tim
> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[Edmond Begumisa]

On Tue, 21 Feb 2012 04:13:50 +1100, Tim Watson <watson....@gmail.com>
wrote:

> On 20 February 2012 12:23, Steve Vinoski <vin...@ieee.org> wrote:

>>
>> There's really nothing like servlet filters. I guess the closest thing
>> -- admittedly not very close, though -- is the ability to add a
>> rewriter, which sits in the dispatch path, takes in the #arg, and can
>> produce a modified one if it wants to.
>>
>> Just off the top of my head, it seems like one could do something like
>> servlet filters with an appmod, I think. Register it on /, and give it
>> it's own dispatching configuration and allow plug-ins to register into
>> its request-reply path. It could then receive each request, arrange
>> the ultimate dispatch target (an appmod, a .yaws page, even a file) at
>> the end of plug-in chain, dispatch the #arg into the chain, and then
>> deliver the eventual reply back into Yaws. No doubt this would be
>> easier if it were built into Yaws, though, since reusing the existing
>> dispatch logic would be easier than writing your own.
>>
>
> Yes and presumably to do your webmachine-a-like you'll be using the
> internal dispatch like this anyway, right? But it would definitely be
> better for use the internal dispatch logic.

I presume that it's more URI-based modularity that you're looking for.
Note that you can achieve this by using the "yapps" feature by splitting
your web-application into small OTP applications. Actually, I find that
this approach promotes more manageable and reusable code.

Using your first example. You could have several OTP applications handling
auth(entic|oris)ation, accounts, payments, receipts, etc....

== yaws.conf ==
..

runmod = yapp

<server public>
port = 8000
listen = 0.0.0.0
docroot = /PATH_TO_MAIN_DOC_ROOT/www
arg_rewrite_mod = yapp
<opaque>
yapp_server_id = pub
bootstrap_yapps = accounts, payments, receipts, auth
</opaque>
</server>

<server admin>
port = 8001
listen = 0.0.0.0
docroot = /PATH_TO_MAIN_DOC_ROOT/www
arg_rewrite_mod = yapp
<opaque>
yapp_server_id = adm_gui
bootstrap_yapps = yapp
</opaque>
</server>
..

== PATH_TO_WEBAPP_OTP_APPS/accounts/ebin/accounts.app ==
..
{env, [
{yapp_appmods,[{"show", accounts_show_controller},
"configure", accounts_conf_controller}]}
]},
..

== PATH_TO_WEBAPP_OTP_APPS/accounts/src/accounts_show_controller.erl ==
..
out(A) ->
..

== PATH_TO_WEBAPP_OTP_APPS/accounts/src/accounts_conf_controller.erl ==
..
out(A) ->
..

== PATH_TO_WEBAPP_OTP_APPS/accounts/priv/docroot/ ==
Has it's own docroot!

Now whenever http://server:8000/accounts/* is accessed, the accounts OTP
application will handle it. If it's
http://server:8000/accounts/configure/*, then the accounts application's
appmod will handle it.

Then you write other OTP applications for payments, etc, etc. After a
while, you'll find yourself moving little useful OTP yapp applications
between projects.

> Also is there a straight
> API call back into YAWS for serving a request, especially a file one
> (so that sendfile will kick in if configured) ?
>

To preempt his response: the hard work has already been done...

http://steve.vinoski.net/blog/2009/01/05/sendfile-for-yaws/

- Edmond -

> BTW thanks for the feedback, this has been very useful and I'm going
> to start playing with YAWS properly now I think.
> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[Tim Watson]

I'd love to do that, but I actually have *no idea* when I'm actually
going to find time to even play with YAWS properly at the moment
(which I want to do) but I am making a mental note (on google :) about
this. :)

[Steve Vinoski]

On Mon, Feb 20, 2012 at 12:13 PM, Tim Watson <watson....@gmail.com> wrote:
> On 20 February 2012 12:23, Steve Vinoski <vin...@ieee.org> wrote:
>>
>> There's really nothing like servlet filters. I guess the closest thing
>> -- admittedly not very close, though -- is the ability to add a
>> rewriter, which sits in the dispatch path, takes in the #arg, and can
>> produce a modified one if it wants to.
>>
>> Just off the top of my head, it seems like one could do something like
>> servlet filters with an appmod, I think. Register it on /, and give it
>> it's own dispatching configuration and allow plug-ins to register into
>> its request-reply path. It could then receive each request, arrange
>> the ultimate dispatch target (an appmod, a .yaws page, even a file) at
>> the end of plug-in chain, dispatch the #arg into the chain, and then
>> deliver the eventual reply back into Yaws. No doubt this would be
>> easier if it were built into Yaws, though, since reusing the existing
>> dispatch logic would be easier than writing your own.
>>
>
> Yes and presumably to do your webmachine-a-like you'll be using the
> internal dispatch like this anyway, right? But it would definitely be
> better for use the internal dispatch logic. Also is there a straight
> API call back into YAWS for serving a request, especially a file one
> (so that sendfile will kick in if configured) ?

Not really, but I don't think it would be hard to add. Currently, an
out/1 function can return the {page, Page} directive to tell yaws to
re-dispatch the current request to Page, which yaws expects to be an
absolute URI path, but I think that's about it. I know for sure this
works for appmods re-dispatching to files, and looking at the code I
think it works for any general re-dispatch, but I've personally never
tried it for anything other appmods re-dispatching to files.

--steve

[Tim Watson]

On 21 February 2012 12:26, Steve Vinoski <vin...@ieee.org> wrote:
>
> Not really, but I don't think it would be hard to add. Currently, an
> out/1 function can return the {page, Page} directive to tell yaws to
> re-dispatch the current request to Page, which yaws expects to be an
> absolute URI path, but I think that's about it. I know for sure this
> works for appmods re-dispatching to files, and looking at the code I
> think it works for any general re-dispatch, but I've personally never
> tried it for anything other appmods re-dispatching to files.
>

Ok cool that's enough to get started. Now I just need to find 30 mins
of free time at some point this year to actually play with this! :)

[OvermindDL1]

/* snip */

So I am curious at all this template stuff. For years now I have been
writing my code as code and html/css/js/whatever as
html/css/js/whatever. My latest example here at work I needed a
python parser to parse out some nasty SOAP crap from our phone system
and it ended up growing to the point where I actually wrote in a
mini-webserver (I cannot use Erlang here... yet... I am trying!).
Even in this tiny webserver I just take a request and server out json.
If authentication needs to happen then I just return a 'keycode' that
should be sent with every request that should be authenticated, but
everything sent back in every single request is generated/cached json,
or a file out of the ../web directory (for the html/css/js/whatever).

I do not really have to 'remember' anything on the server side, I just
send what is requested. Only thing that I really have to remember on
the browser side is the order and entries and such that the json has
when it is sent back. I just make heavy use of jquery. All my code
on both the server and the client is *very* simple (practically
stupid-simple for all the 'ooo's and 'ahh's it is getting), very
self-contained, and very easy to modify, as well as it would be easy
to modify the html/css/js/whatever by someone other than me (of which
I have already done by having someone add in jquery ui themes, which
added like 6 lines to each support html file). Plus I could always
write something to access the servers API directly if I wanted.

But really, why templates? Just let the server do what it does best,
server dumb files and processing of data to give to those dumb files.
Leave the dumb files to process the data as they wish, there is so
much javascript code and so many pure javascript html templating
languages out there, just let the UI people work their magic on that,
they know that stuff, and they know how to parse json with a jquery
call, that is all they need. There is even a jquery for mobile
devices. If you really want to make javascript-less pages, well, then
fall back to the old stuff that no one really uses anymore. ;)

P.S. I am *so* looking forward to a REST-style interface for yaws, I
basically keep remaking one of my own for each project. Good session
management, although the 'capabilities' are not quite powerful enough
for my usage without a *lot* of boilerplate.

[Fred Hebert]

On Wed, Feb 22, 2012 at 11:16 PM, OvermindDL1 <overm...@gmail.com> wrote:

/* snip */

I do not really have to 'remember' anything on the server side, I just
send what is requested.  Only thing that I really have to remember on
the browser side is the order and entries and such that the json has
when it is sent back.  I just make heavy use of jquery.  All my code
on both the server and the client is *very* simple (practically
stupid-simple for all the 'ooo's and 'ahh's it is getting), very
self-contained, and very easy to modify, as well as it would be easy
to modify the html/css/js/whatever by someone other than me (of which
I have already done by having someone add in jquery ui themes, which
added like 6 lines to each support html file).  Plus I could always
write something to access the servers API directly if I wanted.

But really, why templates?  Just let the server do what it does best,
server dumb files and processing of data to give to those dumb files.
Leave the dumb files to process the data as they wish, there is so
much javascript code and so many pure javascript html templating
languages out there, just let the UI people work their magic on that,
they know that stuff, and they know how to parse json with a jquery
call, that is all they need.  There is even a jquery for mobile
devices.  If you really want to make javascript-less pages, well, then
fall back to the old stuff that no one really uses anymore.  ;)

You may work with government agencies or just have public websites where regulation forces you to support things like text readers and other tools for disabled users. These can't easily work with JS-only methods. This is also the case of some phone browsers that just won't support Javascript, or won't support it well. Knowing your public is also rather important. For Learn You Some Erlang, you'd be surprised how many comments about 'please add syntax highlighting' I had before I added a <noscript> tag telling users syntax highlight was done with JS. Some tech crowds seem quite fond of noscript and other JS blockers. Different audiences have different requirements.

Another reason might be a question of speed and/or efficiency. The things that often cost the most for a client making a call to a server aren't the processing time on the server, but generally the connection itself (and the roundtrips), downloading visual assets, reading and running Javascript. As such, it is entirely logical for some sites to prefer to have the text sent as part of a template in a single trip that requires no additional logic client-side than have it done in many calls then rendered afterwards. This also reduces the costs required for serving data in most cases and reduces the bandwidth; everyone wins.

Then you might have other things, like translations. Many templating systems allow you to have different templates or sub-templates that can be configured and have filters (custom or not) to help with different page translations, a thing that as far as I know, isn't very well supported in Javascript tools (or if it is, it is a recent development).

You could do it for ideological purity: HTML is for markup, CSS is for styling, Javascript is only for more interactive parts and shouldn't be about the structuring of the text or the styling itself. This kind of thing is less and less common nowadays I think, though, and people tend not to give a crap about that one as much anymore.

Things are also simpler to test using templates: you can just remove (or later add in) the place-holders and variables and there is no need for you to have a server or data coming from a mock server to be able to work on your files. It is likely simpler to develop the front-end and the back-end in parallel working with templates than requiring the backend guys to set-up fake data sending (or yet, real data sending) to work with a javascript set-up. Although it is in both cases possible to build the whole HTML and then fit them into the final system, there is less change required to do it from HTML -> Template than HTML -> JSON-pulling-thing-that-pushes-it-back-inside-the-DOM.

Lastly, there is no need to encrypt, filter, format, or even transmit what could be sensitive information that might be used to decide how to display content. This is often dependent to how clever you want your templates to be (very dumb vs. more powerful ones), but it's easy to think of a use case for this. Maybe you profile information coming from the database contains the hash and salts of passwords (or if you're better geared up, your bcrypt or scrypt-based hashes ;) ). Although this information is somewhat safe to have around, forwarding it to the browser is often a bad idea. Using templates, you could just push the whole 'profile' record and let the designers not use it and the filtering is implicit. This is usually much simpler and a general no-brainer.

I'm sure there are more reasons out there that support the idea of templates, but I figure this sample is enough to prove a point?

[Toby Thain]

On 22/02/12 11:16 PM, OvermindDL1 wrote:
> /* snip */
>
> So I am curious at all this template stuff. For years now I have been
> writing my code as code and html/css/js/whatever as

> html/css/js/whatever. ...

>
> I do not really have to 'remember' anything on the server side, I just

> send what is requested. ...

>
> But really, why templates? Just let the server do what it does best,
> server dumb files and processing of data to give to those dumb files.
> Leave the dumb files to process the data as they wish, there is so
> much javascript code and so many pure javascript html templating
> languages out there, just let the UI people work their magic on that,

Will your site work without JavaScript?

--T

> they know that stuff, and they know how to parse json with a jquery

> call, that is all they need....

[Tim Watson]

You are both right, of course. Server side methods for generating
dynamic content, such as templating, have their place. So do client
side technologies like jQuery, backbone and pure.js (and who knows how
many others). As you say Fred, it's about knowing your audience and
the constraints your solution needs to operate within. One approach
isn't right or wrong outside of the context in which it's being used.
Having said that, your list is a pretty cool rebuttal. :)

One thing I'd point out is that javascripty, ajaxy stuff doesn't have
to be chatty or slow. I've seen a client app that pulls large (10s of
mg) chunks of xml from the server at a time and renders them on the
client using XSLT. It wasn't particularly portable across browsers,
but to the credit of the guy that wrote it, it's bloody fast at
rendering large amounts of data.

Anyway, the answer to this is that there is not 'one way to do it' and
the best approach 'just depends' on lots of factors. This is why the
servlet API is successful - it is low level enough to let you build
any kind of application on top of it, but high level enough to avoid
getting stuck in the details or be tied to one implementation.