Why I started?
All the applications I worked were built on top of JSP and Portal.To gain rapid response time of Web and to meet the desire for front-end technologies, Freemarker replaced JSP stack.As a result, we support JSP/Freemarker applications.
It seemed like we had the best of both worlds for a while, but we gradually realized how difficult it had become to write reusable front-end features.Each tech stack used a different strategy to render pages. This made it very difficult to share UI code.
Why to Use Templating?
Migrating all of our apps onto a single tech stack would've been a very expensive and time consuming project. Instead, we began to explore a unified rendering layer : client-side templates.
It is both more maintainable and more developer friendly to extract the structure within a template of some sort and leave logic to JavaScript
Instead of using a JSP/Freemarker to assemble a page server side and send back HTML, I had the server send back just the dynamic data as JSON and have the page assembled in the browser using a static client-side template served from a CDN.
Moving the view logic to the browser meant that our different tech-stacks could share UI code:
Picking a templating technology
The open source community has created a huge number of client-side templating solutions. When i did my initial research, I came up with a list of 6 templating technologies.
Below are criteria I used for shortlisting
The Candidates
The Test
To pick between the 6 templating options, I created sample code from each framework to render JSON data as HTML with static template.I chose jsperf.com to create the benchmark
The JavaScript snippets were run across the browsers to test the expected features.
Result
http://jsperf.com/hadlebars-vs-hogan-vs-mustache/49
All the applications I worked were built on top of JSP and Portal.To gain rapid response time of Web and to meet the desire for front-end technologies, Freemarker replaced JSP stack.As a result, we support JSP/Freemarker applications.
It seemed like we had the best of both worlds for a while, but we gradually realized how difficult it had become to write reusable front-end features.Each tech stack used a different strategy to render pages. This made it very difficult to share UI code.
Why to Use Templating?
Migrating all of our apps onto a single tech stack would've been a very expensive and time consuming project. Instead, we began to explore a unified rendering layer : client-side templates.
It is both more maintainable and more developer friendly to extract the structure within a template of some sort and leave logic to JavaScript
Instead of using a JSP/Freemarker to assemble a page server side and send back HTML, I had the server send back just the dynamic data as JSON and have the page assembled in the browser using a static client-side template served from a CDN.
Moving the view logic to the browser meant that our different tech-stacks could share UI code:
Picking a templating technology
The open source community has created a huge number of client-side templating solutions. When i did my initial research, I came up with a list of 6 templating technologies.
Below are criteria I used for shortlisting
- Size of the JavaScript - compressed
- Speed of Execution across browsers
- Cross browser compatibility
- Active Updates to Project
- Precompile Templates on Startup
- Compatibility with Node.js
- Can be used with Plain JavaScript and Other JS frameworks.
- Faster in Mobile platform with Response Web design
The Candidates
- Mustache
- Hogan
- jsRender
- dust
- template
- underscore
The Test
To pick between the 6 templating options, I created sample code from each framework to render JSON data as HTML with static template.I chose jsperf.com to create the benchmark
The JavaScript snippets were run across the browsers to test the expected features.
Result
http://jsperf.com/hadlebars-vs-hogan-vs-mustache/49
- Hogan came out as the best bet for our needs
- It performed faster across all the browsers , particularly Mobile devices.
- It is comparatively Slower than underscore.js in IE. But underscore’s performance in Mobile and modern browsers is not up to the mark.
- Hogan has separate scanning, parsing and code generation phases.
- Performance increased when the templates are precompiled.
- Hogan is used by Twitter for 3 reasons - good performance, standalone template objects, and a parser API.
No comments:
Post a Comment