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

[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.

On 23 February 2012 13:10, Fred Hebert <mononcqc@REDACTED> wrote:
>
>
> 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 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?
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>