I've been using John resigs neat micro templating javascript on a project I'm working on. The project pulls down a JSOn object and spits out a table with a bunch of input fields like so:
This works ok, however in IE it's slow and locks up the browser for a bit. Works great in Chrome though.
I've looked around the net, and have found a few articles on various templating engines, but they are all getting a bit old now, Jquery templates is a bit new, so I'm wondering, has anyone noticed any performance differences between those and resigs engine? Is it worth me swapping? Or should I give up on JS based templating and just generate server side..?
IE, especially the older versions, is slow. If you are noticing a delay then I guess you are dealing with hundreds of objects. I don't think it likely that there is a big enough performance difference between the various templating libraries to provide a solution. Having said that, jquery templates do allow you to compile your templates, which may help.
I don't know about the relative performance but underscore.js also has a simple templating feature if you don't need anything complicated.
Related
How does GWT compare (or can it be compared) to Javascript frameworks such as backbone.js, angularJS, Ember, JQuery, etc.? Do they aim to accomplish the same job, making them competitors, or can they be used together?
Yes and no. While GWT's compiler is essentially a Java-to-Javascript converter, the benefits it offers far outweigh anything I've seen from any popular JS libraries.
Since GWT-based apps are written in Java, they gain many of the benefits thereof, such as being strongly typed and extremely easy to refactor. If something changes that affects another class, you know it immediately. And for those things that Java isn't great at, you can always use Javascript to handle the case with JSNI. Google has also provided a great plugin for Eclipse which allows you to debug your code like nothing I've ever seen of a JS library. Another benefit of this is that you write your client- and server-side code in the same language, and GWT does the heavy lifting of tying them together.
There are also the benefits of the automatic generation of multiple permutations. GWT kicks out a copy of your code that looks and behaves identically (inasmuch as is possible) on the most commonly used browsers. Your clients all see the same thing without you carrying the extra weight. You aren't responsible for writing endless lines of code to deal with those countless browser idiosyncrasies that have plagued web developers forever. While to some extent these things are handled by some JS libraries, GWT makes it completely effortless.
In my experience, the libraries you mentioned are all great in their own right, but simply can't provide the powerful debugging, portability, extensibility, maintainability and portability that GWT does right out of the box. GWT isn't really built to work with other libraries, and instead gives you the capacity to do (mostly) everything those libraries can without their help. (Of course that isn't to say that you can't use other libraries wherever you want...you can if you really feel the need to do so.)
So in my opinion, no, there is no competition. GWT is the figurative heavyweight champion in this arena.
following this post, I took a look at kanso.
From this I learnt that people are not afraid to load to the database context complicated modules if they need them, and that encouraged me a lot.
So I tried kanso. It gave me some trouble that implied immaturity - however, it demonstrateds a great potential.
(mostly compatibiliy view with npm, with node 0.6.x, and some open edge-cases)
So I looked a little deeper.
I saw it comes with a templates engine of it's own.
But what if I want to reuse templates that are written already by another standard?
(for example - haml, or even better - jade that has also a nice text-to-text JS implementation, and a well growing jQuery plugin - same link - see end of document ).
Does anybody here know how coupled the templates engine with the kanso types mechanism, and how simple should it be to use other template engines instead?
Or, what are the limitations I take upon myself when trying to use my own templates?
As far as I can see in the source, DustJS (the template engine of kanso) is not pluggable (like in expressjs for example). That being said, it probably won't be that hard to plug in a different templating engine, the code doesn't seem very complicated.
You might want to add something to this issue on the GitHub page and request for a pluggable templating mechanism.
I'm looking at javascript templating for the first time and mustache and jquery-tmpl are the top contenders at the moment.
Some of my requirements:
templates will live in separate files to be included on multiple pages
all (or almost all) data will come from calls to a restful api which returns json
we're a java/eclipse shop, so syntax highlighting and compatibility with that would be nice, if it's an issue at all
Anyone know of any comparisons in terms of speed, ease of use, flexibility, stability? Any other factors I should be considering? Other top templating engines?
(I know there are other questions on this general topic, but I don't see any direct, broad comparisons between these two.)
My reason to choose mustache over any other template language was that it is implemented for any language you are likely to use. As it is also a true logic agnostic templating language your templates become portable. Therfore you gain the flexibility to choose to render your templates on the client or server side. Even though I have no benchmark available I don't think that performance should be an issue.
Initially I started out using jquery templates but development on that halted a long time ago.
Have a look at handlebar.js as an alternative to mustache.js ( see http://catchvar.com/jquery-tmpljs-vs-handlebarsjs )
handlebar.js seems to be about 2x faster than mustache.
I've been using handlebar in a few projects and mustasche in one or two. I much prefer handlebar and find it 'better'. Here's a nice tutorial by Andrew Burgess I found.
Edit Mar-2013: Also since then Twitter have released Hogan.js which looks awesome like everything else that Twitter does, so I'll be investigating that too at some point.
We are about to commence a redesign of our site and are exploring all options in improving performance. The site is fairly heavy in javascript loaded adverts, therefore we need to be really lean with the javascript we use.
Do any of you have any experience of lighter frameworks or more efficient frameworks that I could explore? Or any resources that you could point me toward? YUI looks like an interesting concept … has the loader being tested in anger? ANy good?
Any thoughts would be appreciated.
Cheers.
edit: Sorry, I wasn't clear. The sites performance currently is pretty good, we are not redesigning due to performance issues, it is due to a rebrand. We just wanted to take the opportunity to review best practices.
jQuery 1.4.2 is lean and mean. You'll be hard pressed finding something faster or more lightweight.
As an example, here is a framework test called slickspeed from mootools. It tests a framework's ability at finding elements in the DOM. The version of jQuery being tested is 1.2.6. Depending on your browser, jQuery performs exceptionally well. In my Chrome browser, jQuery beat all the others with a total time of 20 milliseconds.
And since version 1.2, jQuery has had astounding improvements in optimization and speed, especially with 1.4.
That said, a framework isn't going to make you code better. You can write some seriously slow scripts using any framework, including jQuery.
If, however, you write optimized code, jQuery can be so fast you don't even notice.
Pointy's comment above is spot on. All these guys do all day is worry about how to perform better. So it's pretty optimized.
addendum
This is from jQuery's blog:
While comprehensive benchmarks like Taskspeed can be interesting if deconstructed into individual sub-tests for further study, as a project we tend to stay away from using them as an accurate measure of true, overall, library performance. Considering how many aspects make up a library, not to mention the different techniques that they offer, cumulative results rarely reflect how an actual user may use a library.
So take that as you will.
I prefer YUI3 for larger apps and just about anywhere that 'load on demand' can offer benefits :)
I agree that slowdowns mostly stem from how you implement your app, which is one of the benefits, imho, of YUI, it lends itself naturally towards more modular implementations.
Using the yui loader to bring in page elements widget style allows for good code reuse (and caching) as well letting the user see 'something' quicker.
It won't really solve your JS ad issues though, for that, the best thing you can do is load it as near the bottom of the page as possible, and perhaps look at what loading options the adservers have.
Re: Stephen's comment
Well, raw speed for tight loops are sometimes meaningful, sometimes not. There is also the issue of the implementations used for the comparison, the YUI3 code posted in Ejohns version looks positively gimped compared to the jQuery code, look fx at the first one. Where jQuery adds almost the complete DOM element from a string while YUI3 is going thru all kinds of hoops, relatively speaking.
For a version that is written by someone who knows YUI3 have a look at http://yuilibrary.com/~msweeney/yui-tests/taskspeed/ the newest jquery isn't represented, but it does have YUI3 as ~4 times faster overall than jquery 1.3.2 in my Chrome.
Update
http://www.yuiblog.com/blog/2010/10/27/jquery-and-yui-3-a-tale-of-two-javascript-libraries/ a jquery users experience of yui3.
Probably the best place to start off is not to ask what frameworks can help but why your current site has bad performance. I would start off with tools like Yahoo's YSlow and also Dynatrace ajax edition. Dynatrace is nice because it will point out javascript/dom manip stuff that make your pages slow. You will want to use more than just two performance tools though since they all pretty much have their own idea's on what makes a page fast. Once you have that down then I would come into a forum and state that your having performance issues with X and what can I do to fix.
vapor.js is the world's smallest and fastest javascript library
http://vaporjs.com/
I think you should have a look at zepto.js
http://zeptojs.com/
this article gives you some advices for porting your jquery code
http://blog.pamelafox.org/2012/03/porting-jquery-plugins-to-zepto-tips.html
jQuery is plenty lightweight if coded properly. It sounds like which framework you are using is not the problem, but either a) why the javascript your writing is performing slowly, or b) why you are using so many slow loading ads to begin with.
But if you really want to look into other frameworks, here's a handy comparison chart: Comparison of JavaScript Frameworks
I just wrote an internal app for our company using jquery and jquery UI (http://jqueryui.com/), mixed in with c#. I found it to be extremely lean and fast - no problems whatsoever.
the jquery ui makes it easy to theme the website...
and by adding other components like blockui, jgrowl, etc you should be able to do anything you want!
Sprint is a tiny, fast alternative.
Check out the repo for benchmarks on a few functions, compared with recent versions of jQuery and Zepto.
I'm in a process of selecting an API for building a GWT application. The answer to the following questions will help me choose among a set of libraries.
Does a third-party code rewritten in
GWT run faster than a code using a
wrapped JavaScript library?
Will code using a wrapped library
have the same performance as a pure
GWT code if the underlying
JavaScript framework is well written
and tuned?
While JavaScript libraries get a lot of programming eyeballs and attention, GWT has the advantage of being able to doing some hideously not-human-readable things to the generated JavaScript code per browser for the sake of performance.
In theory, anything the GWT compiler does, the JavaScript writers should be able to do. But in practice the JS library writers have to maintain their code. Look at the jQuery code. It's obviously not optimized per browser. With some effort, I could take jQuery and target it for Safari only, saving a lot of code and speeding up what remains.
It's an ongoing battle. The JavaScript libraries compete against each other, getting faster all the time. GWT gets better and better, and has the advantage of being able to write ugly unmaintainable JavaScript per browser.
For any given task, you'll have to test to see where the arms race currently places us, and it'll likely vary between browsers.
In some cases you don't have another option. You can not rewrite everything when moving to GWT.
In a first step you could just wrap your existing code in a wrapper and if it turns out to be a performance bottleneck you can still move the code to Java/GWT
The code optimisation in GWT will certainly be better than what the majority of JS developpers can write. And when the Browsers change, it is just a matter of modifying the GWT optimizer and your code will be better tuned for the latest advances in Js technology.
Depends on how well the code is
written.
I would think so.
Generally look at the community around a 3rd party library before using it unless it is open-source (so you can fix bugs) and specifically look for posts concerning bugs - how quick do the maintainers respond to items. How long is a release cycle, etc.