9

Recently, I have come up with some idea about how to improve the overall performance for a web application in that instead of generating a ready-to-show html page from the web server, why not let it be fully generated in the client side. Doing it this way, only pure data (in my case is data in JSON format) needs to be sent to the browser. This will offload the work of html generation from the server to the client's browser and reduce the size of the response packet sent back to users.

After some research, I have found that this framework (http://beebole-apps.com/pure/) does the same thing as mine.

What I want to know is the pros and cons of doing it this way. It is surely faster and better for web servers and with modern browser, Javascript code can run fast so page generation can be done fast.

What should be a downside for this method is probably for SEO. I am not sure if search engines like Google will appropriately index my website. Could you tell me what the downside for this method is?

Ps: I also attached sample code to help describe the method as follows:

In the head, simple javascript code will be written like this:

<script type='javascript' src='html_generator.js'/>
<script>
   function onPageLoad(){
      htmlGenerate($('#data').val());
   } 
</script>

In the body, only one element exist, used merely as a data container as follows: 

  <input type='hidden' id='data' value='{"a": 1, "b": 2, "c": 3}'/>

When the browser renders the file, htmlGenerate function which is in html_generator.js will be called and the whole html page will be generated in this function. Note that the html_generator.js file can be large since it contains a lot of html templates but since it can be cached in the browser, it will be downloaded once and only once.

woraphol.j
  • 1,301
  • 5
  • 14
  • 22
  • I use ExtJS for this: http://www.sencha.com/products/extjs/ – PiTheNumber Dec 21 '11 at 08:05
  • 1
    If you're building a web app with real user functionality (ie, an email system or whatnot), the client-side generation approach could work nicely. If you're building a way to provide (mostly staticly viewed) content for public consumption (docs, for instance, or a company marketing website), send HTML and use unobtrusive JS methods. – Jared Farrish Dec 21 '11 at 08:15

5 Answers5

7

Downsides

  • Search Engines will not be able to index your page. If they do, you're very lucky.
  • Users with JavaScript disabled, or on mobile devices, will very likely not be able to use it.
  • The speed advantages might turn out to be minimal, especially if the user's using a slow JavaScript engine like in IE.
  • Maintainability: Unless you automate the generation of your javascript, it's going to be a nightmare!

All in all

This method is not recommended if you're doing it only for speed increase. However, it is often done in web applications, where users stay on the same page, but then you would probably be better off using one of the existing frameworks for this, such as backbone.js, and make sure it remains crawlable by following Google's hashbang guidelines or HTML5 PushState (as suggested by @rohk).

If it's just performance you're looking for, and your app doesn't strictly need to work like this, don't do it. But if you do go this way, then make sure you do it in the standardized way so that it remains fast and indexable.

Herman Schaaf
  • 46,821
  • 21
  • 100
  • 139
  • It depends on what the site's focus is going to be. A marketing site for a company, html and unobtrusive Javascript. For dedicated web apps, single load sites are not out of the question and perhaps can be more appropriate using this type of approach. – Jared Farrish Dec 21 '11 at 08:19
  • @Jared Farrish's comment on the question summarizes it nicely. – Herman Schaaf Dec 21 '11 at 08:20
  • @Jared Farrish And then you commented on my answer as well! Very true. – Herman Schaaf Dec 21 '11 at 08:21
  • Oops, didn't see your edit. All I know is, I genuinely dislike html-based, non-modern email web apps (Yahoo, for instance). But fancy-cuz-we-can company websites miss the point, which is to communicate the message of the company as succinctly as possible. The user doesn't care how the page is "generated" in that case, and browsers are built to parse HTML. Also, the rule of KISS should be in effect, and this type of functionality for a story-driven site would not always be "faster". There are other considerations. – Jared Farrish Dec 21 '11 at 08:24
  • 1
    Hashbangs are obsolete and used only by Google (so no indexation for other engines)... Use HTML5 pushstate for crawlability - http://lostechies.com/derickbailey/2011/09/26/seo-and-accessibility-with-html5-pushstate-part-1-introducing-pushstate/ – Romain Meresse Dec 21 '11 at 08:27
  • Thank for your answers, Let me clarify my website a bit more, It's like Twitter in that each user has his own profile page that anyone can view. Since each page html layout will be very similar, loading the same html layout over and over when a user browses each user profile can be wasteful. And since my website is meant to be highly dynamic, so a user without javascript will not be allowed to use it and this is for me acceptable. Maintainabilty can be a problem but I think I will be prepared for it. I also restrict that users of my site should use modern browsers so Javascript could be fast. – woraphol.j Dec 21 '11 at 08:57
  • What I fear the most is SEO since I want each user page to be indexed and can be found separately when searched in search engines. Do you have any tips for me? At least I can change my design a bit to help in SEO. – woraphol.j Dec 21 '11 at 09:02
  • @s4510488 If your goal is profile pages that load fast, AJAX is a good solution - just make sure you employ a technique such as hashbangs or HTML5 PushState to make sure it remains indexable. Check out any of the many javascript templating libraries available to help you with the templating side, too. – Herman Schaaf Dec 21 '11 at 09:11
  • @HermanSchaaf Thank for your answer. If I use Ajax, then the returned result from the server should be JSON or already-generated html? I am a little bit confused. – woraphol.j Dec 21 '11 at 09:24
  • @s4510488 Either one can work fine. If there might be some variability in your profile pages, I'd suggest rather sending the already-generated html. That also helps maintainability somewhat. Otherwise, JSON accompanied with some javascript filling in the fields will also work. Personally, I recommend saving some trouble and sending the HTML. – Herman Schaaf Dec 21 '11 at 11:07
  • Thank all of you for enlightening me but I still want to persist with this idea. What if I check if a request is Googlebot (check the header user-agent) then a full html page is created and sent back to a user. If not a Googlebot, the blank page is sent and will be generated by Javascript. Please share your thoughts if this should work. – woraphol.j Jan 23 '12 at 07:46
3

Client-side templating is often used in Single Page Applications.

You have to weight the pros and cons:

Pros :

  • More responsive interface
  • Load reduced on your web server

Cons :

  • SEO will be harder than for a classic website (unless you use HTML5 PushState)
  • Accessibility : you are relying heavily on javascript...

If you are going this way I recommend that you look at Backbone.js. You can find tutorials and examples here : http://www.quora.com/What-are-some-good-resources-for-Backbone-js

Examples of SPA :

Also look at this answer : https://stackoverflow.com/a/8372246/467003

Community
  • 1
  • 1
Romain Meresse
  • 3,044
  • 25
  • 29
  • "Fluider interface" - What does this mean? – Jared Farrish Dec 21 '11 at 08:25
  • @browser history: You can create every page completely or use hashtags. That is not really a con – PiTheNumber Dec 21 '11 at 08:26
  • @JaredFarrish : User experience will be perceived quicker as you are reloading only parts of your page using ajax – Romain Meresse Dec 21 '11 at 08:29
  • That's usually referred to as a "responsive interface"; "fluidity" at least in my mind refers to whether the page layout is proportional to the browser viewport width or some variation of that. And it's entirely possible that the gains achieved aren't worth the cost of building and managing a system like this in many cases. – Jared Farrish Dec 21 '11 at 08:35
  • In fact... I would argue that, other than true "web-based apps", the same types of sites that would lend themselves to this type of methodology (ie, relatively simple content-driven websites) also don't inherently gain much from eliminating full round trips. Large-scale sites where it would seem it could work better (Dell's product site, eBay, etc.) are so monolithic and have so many moving parts that simplifying the browser interface could be a ROI decision. – Jared Farrish Dec 21 '11 at 08:42
1

Yikes.

jQuery templates are closer to what you are thinking. Sanity says you should have some HTML templates that you can easily modify at will. You want MAINTAINABILITY not string concatenations that keep you tossing and turning in your worst nightmares.

You can continue with this madness but you will end up learning the hard way. I employ you to first try some protypes using jQuery templates and your pure code way. Sanity will surely overcome you my friend and I say that coming from trying your way for a time. :)

Its possible to load content in dynamically of the template you need as well using AJAX. It doesn't make sense that you will have a panacea approach where every single conceivable template is needed to be downloaded in a single request.

King Friday
  • 25,132
  • 12
  • 90
  • 84
  • Isn't jQuery templates now a dead project? As a jQuery spaghetti coder, I was hoping they had something like this as I already understand the framework, but I have since read that this is dead in the water. – Michael Giovanni Pumo Feb 13 '13 at 15:44
  • Yes. I think it is. I answered this Dec 21, 2011 so yep. I would try EJS as you don't have to learn anything new to use JavaScript with your template and you can reuse this in Node.js which I program in over asp.net as well as a change from when I wrote this last. – King Friday Feb 13 '13 at 15:49
0

The pros? I really can't think of any. You say that it will be easier in the webserver, but serving HTML is what web servers are designed to do.

The cons? It goes against just about every best practise when it comes to building websites:

  • search engines will not be able to index your site well, if at all
  • reduced maintainability
  • no matter how fast JS engines are, the DOM is slow, and will never be as fast as building HTML on the server
  • one JS error and your entire site doesn't render. Oops. Browsers however are extremely tolerant of HTML errors.

Ultimately HTML is a great tool for displaying content. JavaScript is a great way of adding interaction. Mixing them up like you suggest is just nuts and will only cause problems.

Graham
  • 6,484
  • 2
  • 35
  • 39
0

Cons

  1. SEO
  2. Excluding user without javascript

Pros

  1. Faster workflow / Fluider interface
  2. Small load reduce

If SEO is not important for you and most of your user have Javascript you could create a Single Page Applications. It will not reduce your load very much but it can create a faster workflow on the page.

Btw: I would not pack all templates in one file. It would be too big for big projects.

PiTheNumber
  • 22,828
  • 17
  • 107
  • 180