+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
On 18 Feb 2012, at 16:45, Tristan Sloughter <> wrote:
> 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
> _______________________________________________
> erlang-questions mailing list
>>http://erlang.org/mailman/listinfo/erlang-questions-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120218/6f7866db/attachment.html>