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. :) _______________________________________________ erlang-questions mailing list erlang-questi...@erlang.org http://erlang.org/mailman/listinfo/erlang-questions
On 19 February 2012 10:52, Adam Rutkowski <adam.rutkow...@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. _______________________________________________ erlang-questions mailing list erlang-questi...@erlang.org http://erlang.org/mailman/listinfo/erlang-questions
On 19 February 2012 14:17, Tim Watson <watson.timo...@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! _______________________________________________ erlang-questions mailing list erlang-questi...@erlang.org http://erlang.org/mailman/listinfo/erlang-questions
> 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.
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. _______________________________________________ erlang-questions mailing list erlang-questi...@erlang.org http://erlang.org/mailman/listinfo/erlang-questions
> 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.
> 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. _______________________________________________ erlang-questions mailing list erlang-questi...@erlang.org http://erlang.org/mailman/listinfo/erlang-questions
On Sun, Feb 19, 2012 at 9:17 AM, Tim Watson <watson.timo...@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):
> 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.
> 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. _______________________________________________ erlang-questions mailing list erlang-questi...@erlang.org http://erlang.org/mailman/listinfo/erlang-questions
> On 19 February 2012 03:39, Steve Vinoski <vino...@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.
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...
> 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:
> 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):
> On 20 February 2012 12:23, Steve Vinoski <vino...@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....
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...
> 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-questi...@erlang.org > http://erlang.org/mailman/listinfo/erlang-questions
> On Mon, 20 Feb 2012 01:17:19 +1100, Tim Watson <watson.timo...@gmail.com> > wrote:
>> On 19 February 2012 03:39, Steve Vinoski <vino...@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.
> 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...
>> 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:
>> 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):
>> Is there something else in YAWS like appmod that'll do a filter chain, >> or am I better off using annotations?
> 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.
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. :) _______________________________________________ erlang-questions mailing list erlang-questi...@erlang.org http://erlang.org/mailman/listinfo/erlang-questions
On Mon, Feb 20, 2012 at 12:13 PM, Tim Watson <watson.timo...@gmail.com> wrote: > On 20 February 2012 12:23, Steve Vinoski <vino...@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.
On 21 February 2012 12:26, Steve Vinoski <vino...@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! :) _______________________________________________ erlang-questions mailing list erlang-questi...@erlang.org http://erlang.org/mailman/listinfo/erlang-questions
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. _______________________________________________ erlang-questions mailing list erlang-questi...@erlang.org http://erlang.org/mailman/listinfo/erlang-questions
On Wed, Feb 22, 2012 at 11:16 PM, OvermindDL1 <overmind...@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 <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?
> 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....
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 <monon...@gmail.com> wrote:
> On Wed, Feb 22, 2012 at 11:16 PM, OvermindDL1 <overmind...@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?
