0

I searched a lot, but nobody seems to have explained this nor given a proper example.

I have a page like this:

enter image description here

My team says they want to design the code such that the Title section, Menu section and Footer sections would each be kept in separate HTML files and they'd have separate JSP files for every page, where each JSP file would dynamically load the title.html, menu.html and footer.html files using JQuery.

My suggestion to them was to use a single JSP/HTML file which already contains the Title, Menu and Footer, and just load the Center content dynamically (single page app).

I have three questions:
1. For a web app that needs to use as less network bandwidth as possible, is it better to use a single page app approach or the load-multiple-pieces-of-a-page approach? Percentage-wise, would it result in a large change in bandwidth if the Title only contained a small brand logo and text, and the Menu and Footer just contained text and styles.

  1. If content is to be loaded dynamically into a page, since frame is deprecated and I hear that iframe is not encouraged, is an ordinary div the best option to load Center content or the Title, Menu, Footer etc. OR is there a better way to load it such that it'd work in IE too?

  2. When pages are kept split as title.html, menu.html etc., do they have to contain the <html>' andtags or can they just contain the necessary's? Do the loadedHTML` pages inherit the parent page's properties?

closed as too broad by gnat, GlenH7, Bart van Ingen Schenau, user40980, Dan Pichelman Jan 19 '15 at 15:50

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • What about AJAX & websocket techniques? – Basile Starynkevitch Jan 16 '15 at 10:55
  • Not very familiar with those. I've already tried with iframes, but the iframe borders don't disappear even after using border: none. So tried loading into div and it loads only some elements. Problem is, I have to take a decision in a few hours and proceed. – Nav Jan 16 '15 at 11:14
  • You should read more about AJAX & websocket & HTML5 – Basile Starynkevitch Jan 16 '15 at 11:16
2

Basically, I find it very good to keep the 'title', 'menu' and 'footer' in independent files.

What I really wonder about is: why don't you put them together on the server side???

<%@include file="title.jsp" %> <%@include file="menu.jsp" %> <%@include file="footer.jsp" %>

Don't worry about bandwith

The difference between your two solutions will be negligible and I wouldn't worry about. Most browser will cahche the files and retrieve them only once anyway. Having a picture on your website would consume much more bandwith, so avoid any picture. You want to save bandwitdh right? ...just kidding. It's just not a place to worry about. Bandwitdh is cheap.

There are much more important things to worry about

Is it safe?

The more javascript you have on your site, the more likely things can go wrong. With the large diversity of browsers/OSes/devices, you must be careful! If your javascript breaks somewhere, because of you or a dependency, it may cause that nothing works anymore. ...and your users will not be happy if the navigation on your site doesn't work anymore.

Taking this into account, your solution is more error-prone.

Is it webby?

You know, bookmarking pages? History? Previous page? Share a link? ;) ...with dynamic loading, you don't get all that stuff ...or it's a lot of extra work and bug sources.

Your solution doesn't provide that.

Is it maintainable?

...you know, easy to read/understand/change. I personnally find it easier to serve full pages with normal links rather than understanding javascripted navigation. My 2 cents.

I think your way is more complicated

Single page web apps is a trendy concept, but not all that is new and shiny is better than good ol' stuff.

Doing the "merging" on server side has several benefits

  • It's simple
  • It's easy to understand
  • It'll never break on the client because not javascript dependent
  • It's good for SEO because crawlers can index you easely
  • People can "bookmark" pages and so on, you know
  • The page is fully loaded in a single request
3

It would be interesting to know what your team thought about your suggestion. I think it's got a lot of merit. To answer your questions.

  1. Bandwidth, for both options I would say that caching either on the end-user's browser or via an ADN or CDN would solve this problem for you. If a web application is getting three files: Title, Menu and Footer, that don't change then these can be cached. For both there will be the initial hit whilst everything is got for the first-time.
  2. If you are using jQuery then the AJAX methods within it should enable you to write content into any tag you choose. DIVs should be fine.
  3. Included files that form part of a web-page shouldn't have and tags, otherwise you'll have invalid HTML in the final page.
1
  1. Yes, but most browser already cache thing like image/css/js so the bandwidth saving wouldn't blow you mind but still no screen bleeping and less request is nice to have

  2. iframe has it place but I think for your case, AJAX is the best. there's other technique like using knockout so server only send JSon (instead of partial view) and later it will be rendered into html by knockout.

  3. if you don't want to use iframe html tag isn't necessary.

Not the answer you're looking for? Browse other questions tagged or ask your own question.