What is the use of frameworks like PURE or jQote etc. I can do dynamic things in plain javascript or JQuery using AJAX calls or an advanced library like DWR.
What new stuff do these templating frameworks bring to the table? I need to know since I have been asked to use a browser side templating framework without being explained why :(
I guess it depends on what you're using as your server code; it could be that the recommendation came from someone who hasn't heard about N/Velocity for example.
I think the main reason for client templating is that it removes the weight of transformation from the web-server.
It might also allow you to send your JSON from a dedicated box, and serve the template and client code from a different box.
To my mind, both of these 'bonuses' override the fact, that you're putting Data into the DOM that shouldn't be there. Firstly you'll have the JSON that is parsed by the template generator and then you'll have the HTML that is created.
Sure, viewing page source will look neat, but in terms of memory consumption for the browser it's bad, especially if you're in the UK and have Government contracts who mandate IE6 support.
Related
I've been working with ASP.NET MVC for about a year now. I enjoy the ability to create SPA's especially by using the following tools:
Partial views(via html.action() and renderPartial())
Ajax helpers (Ajax.Actionlink() and Ajax.beginform())
My question is, Is it safe to just continue without a JavaScript frameworks or am i seriously missing out on something by not utilising a Javascript framework like Angular JS.
This depends a lot of the type of application you are building, but in general you don't necessarily have to choose between ASP.NET MVC and Angular, you can use both in a project.
For example, if you have a page with a grid where the user will add rows and you have to calculate sums etc you could use angular on that page (and it will speed up the development process).
But if you have pages with static content you can just serve an html file there using ASP.NET MVC.
And you can even use both of them. For something like a blog post, you can use a static html file for the post content and then implement the comments are with angular.
Since ASP.NET is a server side framework, it can only go that far as AJAX insertions. Angular JS is a client side Framework, designed for SPA in mind. If you are going for a light SPA, ASP.NET will do nicely, but I think you should use the right tools for the right job. Don't hesitate to mix them in order to find the right place between server side rendering and client side dynamism.
You are definitely missing some things.
The purpose of frameworks such as angular is not just to handle your bootstrap tab switches or whatever to display just parts of the UI rather than everything. Sure, you can create small and simple SPAs by utilizing such logic but once you come to create real-world apps that approach will become unusable. The reasons to this are:
Your site will be highly unmaintainable
Frameworks like angular provide much more than just templating (more on that in a moment) but features such as routing, which allows on-demand content loading. That is, instead of sending the whole page to the client, much of which (s)he maybe will not even take a look at, you can load fragments of HTML on-demand, which reduces network usage. Imagine you had to download everything (posts, images, videos, chat messages etc) on Facebook and hide them until you actually want to see them.
Back to templating, this is a very powerful feature. Again, in the case of simple apps you can use custom JS code - that is, concatenate strings to create fragments of HTML and then insert them into the DOM. But even with simple apps this is a smelly thing to do. Imagine you had to write custom JS to concatenate your chat messages in an app like Facebook then insert them into the DOM. With angular2, for example, you can do something like this:
<ul>
<li *ngFor="let msg of messages">{{msg.Sender}} said: {{msg.Content}}</li>
</ul>
This way, Angular2 will do all the parsing and DOM handling for you. That is, you write declarative markup rather than imperative logic for what you want to display.
All in all, they help you to decouple the logic from the UI so you should definitely dig into any of the popular frameworks and get a taste of their capabilities if you want to create rich apps. You will not regret it.
I recent came across Javascript templates and have become quite intrigued.
I am building a large PHP application using the MVC pattern. Templating is handled by the rather awesome Twig.
I recently came across a javascript implementation of twig.
I have also read quite a bit about using javascipt template engines.
Now, in my application, the application generates a the full page for standard requests as fallback for users without javascript. For AJAX requests, it can generate the content part of the page (no <head>, <body> etc).
The ajax response object is currently just a the rendered HTML content, which is then inserted into DOM.
Should I instead return a response object containing a compiled javascript template and the objects to be inserted into the template? What are the benefits of doing that?
From the posts I have read, the javascript templates were only small snippets representing a small part of a page, for example displaying a comment on a blog post during the instant that the user has submitted it.
Are javascript templates only useful for inserting these sort of small "pieces" in a page?
Yes
A recent project I was on got "client-side template fever" and we used the dang things for every single template.
With every template library I've used (which is two or three), the error messages you get are not very good. If you have a huge template that operates on a fair amount of data, you'll quickly find the u.foo is null or not an object error message increasingly frustrating.
The best-practices I've settled on is:
Return a full HTML snippet (from the server) if it's a template that is seldom loaded. If you are only loading that HTML once on a page, then you might as well send it down populated right? This also encourages you to keep your logic up on the server, where it probably belongs.
Use client-side templates for small, repeated templates. Your blog comment example is probably a good one. I've found the most success when my client-side templates are pretty small (< 10 lines)
Use a logic-less template engine. The more logic allowable in a template, the harder they are to read/maintain. Plus, some of that logic should probably be in your business layer, not down in some JavaScript template. In other words, they force you to separate your presentation from your logic (which is good).
PS: It is cool that both your client and server-side templates could use the same templating engine. This will make developers on your project much more productive.
Depending on the scale and requirements of your application, you should take into considerations the following:
don't go rampant on Ajax; Ajax is not WebSockets, so use it sparingly. Plus, client-side execution speed is always key; AJAX is slow when compared to dumping as much resources as possible + using them when you need them; for example, you can send to javascript userdata = {name:'xxxx',address;'yyyy', ...} and using that, instead of requesting name and address via AJAX only when you need them.
it is recommended to use a global PHP var $sendData (or something like that) and right after plasting HTML, you send the $sendData with an easy <script>data = <?php echo json_encode($sendData); ?></script>
javascript templates add up to execution speed. which makes it reasonable to do the alternative, that is, separating everything that is dynamic and caching static resources like javascript functions
you can't, and I quote return a response object containing a compiled javascript template, not without residing to some server-side javascript engine that does the compile job prior to returning it
for your personal welfare, it will always boil down to how fast, easy and painlessly you respond to maintaining the application; there's no point in using super beta experimental frameworks, ports and kits over which you have limited control
Work smart, not hard.
Good luck mate.
You could also look into the Distal http://code.google.com/p/distal templating engine.
Being new to front-end website development, I can understand some stuff, things like routes, ORM, etc. What I don't understand is how they all play together. My understanding is, there are a bunch of components for a website built with Pyramid/Django etc:
A templating engine: Something for you to abstract away your HTML from your code. Makes sense.
SQLAlchemy et al: An ORM. Fine.
A renderer. No idea.
JS libraries: JQuery et al:
No idea what use these are except for adding pretty effects. How does this interact with the templating engine? How does this interact with the entire framework? Can I write code for jquery in Pyramid, or do I write JS separately, plug in my JS file into my template or...?
Form templating libraries (formish, formalchemy et al): How do these relate to the big picture? where do they plug in?
Any other important components that I'm missing?
So, could someone help me out and explain the stack?
1) A templating engine: Something for
you to abstract away your HTML from
your code. Makes sense.
There's several of these available. Mako tries to utilize many common Python idioms in the templates to avoid having to learn many new concepts. Jinja2 is similar to Django, but with more functionality. Genshi is if you like XML based templating.
As someone new to the whole thing, it's hard to say which is easiest to begin with unfortunately. Perhaps Jinja2.
2) SQLAlchemy et al. An ORM. Fine.
Yep.
3) A renderer. No idea.
A renderer is a Pyramid view configuration option, which tells Pyramid that if your view returns a dict, then it should be passed to the given 'renderer'. Renderers are setup to work with extension names, and Pyramid comes with several built-in:
http://docs.pylonsproject.org/projects/pyramid/1.0/narr/renderers.html#built-in-renderers
In short, the renderer option merely looks at the name you pass it, and finds a template engine that matches the extension (.mak, .pt, 'json', 'string', .etc), and renders the dict results with it.
In many frameworks you don't designate a renderer as configuration, but instead have some code inside the view which looks something like this:
def somefunc(request):
return render_to_response('/some/template.mak', {})
In Pyramid, you could do the same thing with:
#view_config(renderer='/some/template.mak')
def somefunc(request):
return {}
There are several reasons the latter is a useful capability:
When it's entirely in configuration, you can override the renderer without having to change the view code logic.
You can add multiple configurations that change the renderer based on other conditions.
Consider this example which changes the renderer based on if the HTTP request is an XHR (AJAX request that wants a JSON formatted result, instead of a general HTTP request that wants HTML spit out by the template engine).
#view_config(renderer='json', xhr=True)
#view_config(renderer='/some/template.mak')
def somefunc(request):
# lookup some_dict_data in a db, etc.
return some_dict_data
4) JS libraries: JQuery et al. No idea
what use these are except for adding
pretty effects. How does this interact
with the templating engine? How does
this interact with the entire
framework? Can I write code for jquery
in pyramid, or do I write JS
separately, plug in my JS file into my
template or...?
JS libraries make it easier to write Javascript. They interact in the browser with the DOM, and have no interaction with Pyramid beyond sending HTTP requests to your web application that might want JSON formatted results.
To begin with, I'd suggest ignoring Javascript entirely until you're much more familiar with HTML, the DOM tree, and getting a site that works with just HTML, CSS, and the web-application.
5) Form templating libraries (formish,
formalchemy et al) How do these relate
to the big picture? where do they plug
in?
I would highly suggest ignoring those entirely, and writing basic HTML form elements. You're new to the whole web stack, and there's really no need to jump straight to the most advanced aspects of web development without getting familiar with the basics first.
What you will need though, after writing basic forms, is you will want a form validation library that makes it easier to verify that the form which was submitted contains valid parameters. Back in the old days of PHP, people would write hundreds of lines of if/else statements that went through forms (some still do! ack!).
Nowadays we use form validation libraries which make it easy to declare what the valid parameters are for a form. I'd suggest FormEncode to begin with, as its fairly easy to use just for validation. For Pyramid, the easiest way to get going with FormEncode is probably pyramid_simpleform:
http://packages.python.org/pyramid_simpleform/
For now, ignore the form rendering part and write the HTML form elements in the template yourself, and use pyramid_simpleform just for the easy FormEncode integration.
In short, start with just displaying HTML pages with links using view functions and templates (and use URL dispatch, its easier to grasp than traversal for beginners). Then add forms, their HTML and validation, then add CSS to start styling things.
Next you can start with some basic Javascript with jQuery to make things move around on the page, and work your way up to interacting with the webapp via AJAX to get more data. Just don't tackle too much at once, and it should be easier to see how they fit together.
3) A renderer. No idea.
Generally a renderer takes your data/model and converts it into something that the client wants. If the client is just a browser then the renderer will usually mash your data through a template to produce HTML. If the client is some JavaScript code or a non-browser application (a desktop application, another server that is consuming your data, ...) then the renderer would usually produce JSON (or possibly XML). You can think of this as a serialization or marshalling system.
4) JS libraries:
These are what you use to program the user interface. The user interface may just be some pretty effects slapped on top of HTML but it could be a lot more. Google Docs, for example, is JavaScript and a bit more than pretty effects; Cloud9 IDE would be another example full application built with JavaScript (thanks to Raynos for another example).
5) Form templating libraries
You can think of these as (more or less) macro systems for the template engine. If you have a data schema then you can use these things to generate template chunks and to automatically handle the server side processing of the corresponding return data.
Any other important components that I'm missing?
You can think of the modern web stack as a traditional client server system; this will probably anger some people but there's nothing radically new here except possibly the scale. The client is built with HTML and CSS for the layout and JavaScript (possibly with a toolkit) for the functionality and eye candy. The server is a web server of some sort. Communication between client and server is usually done in a combination of JSON and HTML over HTTP. You can think of web-1.0 (may deity forgive my marketing-talk terminology) as old school dumb terminals where web-2.0 is more like an X-terminal with some brains on the client.
I'm building a Django web application which has a lot of html generated on the fly by ajax requests. Right now I use Django's templating language to build up html and then pass this new HTML as a string in JSON object which is then injected into the page with jQuery.
This works fairly well, but with Javascript being so fast in modern browsers and with so many javascript template libraries being made I'm wondering if I should push everything clientside.
So my question is: Given the that my average "page" with all requests to and from it has to compile around ~300 templates (each of about 15 or so lines with 5 or so substitutions) out into HTML during its lifetime is there significant performance advantage to doing templating in the browser?
In addition can anybody reccomend a 'fast' Javascript templating library? I've heard good things about underscore.js, mustache.js and jQuery template.
The (massive) advantage of sticking with Django templates is that you only need to use one templating language, which retains the same capabilities regardless of the page you wish to generate. If you find that you're having performance issues then you should consider looking into caching template fragments.
I don't think an hybrid client and server templating architecture is bad. As long as you code a template only in one of the environment.
Every time you generate a page server side, an amount of processing time and some network bandwidth is consumed. This is what you pay if you use hosted servers.
While the user's browser is awaiting idle on a generally idle computer for the response.
If you send the template on the client(HTML + JS), they can be cached, for the session or even days, if the user do not delete them.This reduces the network traffic to deliver the same content various times. As the data are generally smaller than their equivalent rendered HTML.
As you point today's Javascript engines are really fast, as well as the computer they run it. Each time you sent the rendering work to the client, you save some processing time for your server and deliver faster the data.
We're at the other extreme side, as we run all on the client and that's why we created PURE for an ultra-fast client rendering. Our app looks very fast as a result of this decentralisation.
Why do you pass the HTML as JSON? Just send back the HTML and use jQuery's $.html() function to put it in the <div> or whatever.
As for templating in Javascript, there's Pure. If you're using jQuery (I'd recommend it), it already has a template engine.
It may be possible to make templates of dual purpose - to that they could be rendered into placeholders for the replacement by js and at the same time they could be rendered normally for the server output. Only a few templates will need to be of dual purpose like that - the fragments that are to be replaced by the js.
I agree with Ignacio, it is much better to keep just one copy of each template, so that you don't have to write a separate one for the javascript, however there is definitely room for improvement from the approach that I've mentioned above.
Ideally you might want to have templates compiled into robust javascript function code as well as plain string for the output by the server.
Closure templates called Soy, solve the problem nicely but do not (perhaps just yet) work with python, but they do work with Java and Javascript. Hopefully one day there will be python support for that.
But even if that happens, the templating language will be probably more restricted as it will be tough to make things like .get_absolute_url(), filters, etc work both in python and javascript - all automatically.
I know you can just use CSS to hide the DIV or Silverlight Plugin, but is there a way to instantiate a Silverlight Component/App using JavaScript that doesn't show any UI element at all?
There is alot of great functionality in Silverlight, like MultiThreading and compiled code, that could be utilized by traditional Ajax apps without using the XAML/UI layer of Silverlight at all.
I would like to just use the standard HTML/CSS for my UI layer only, and use some compiled .NET/Silverlight code in the background.
Yes you can, and some of the reasons you make makes perfect sense. I did a talk on the HTML bridge at CodeCampNZ some weeks back, and have a good collection of resources up on my blog.
I also recommend checking out Wilco Bauwers blog for lots of detail on the HTML bridge.
Some other scenarios for non visual Silverlight:
Writing new code in a managed language (C#, Ruby, JScript.NET, whatever) instead of native (interpreted) JavaScript.
Using OpenFileDialog to read files on the client, without round-tripping to the server.
Storing transient data securely on the client in isolated storage.
Improving responsiveness and performance by executing work in the background through a BackgroundWorker or by using ordinary threads.
Accessing cross-domain data via the networking APIs.
Retrieving real-time data from the server via sockets.
Binding data by re-using WPF's data-binding engine.
Yes. I think this is particularly intriguing when mixed with other dynamic languages -- but then, I'm probably biased. :)
Edit: But you'd need to use the managed Javascript that's part of the Silverlight Dynamic Languages SDK and not the normal Javascript that's part of the browser.
Curt, using Managed JavaScript would still require you to have some Silverlight/XAML display layer being visible on the page, correct? Is there a way to entirely get rid of any Silverlight/UI element from being displayed?