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

[Fred Hebert]

On Wed, Feb 22, 2012 at 11:16 PM, OvermindDL1 <overminddl1@REDACTED> 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 <https://github.com/ferd/erlpass> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120223/0e38b5f9/attachment.htm>