I'm looking to develop a one page app, and will likely be using node.js for my server side coding.

I'm trying to get some advice regards the client-side coding. While i realise that something like backbone.js would really help me, since im very new to development the learning curve is very high for me.

So i'm going to be using something like dust.js for my client side templating. Currently i'm creating some mockup screens (there are 4 in total) that are being built in just plain html/css.

When i come to doing the client side and server coding, is it better for me to combine all my presentation code into one html file, or into multiple files and then call them separately, considering it's a one page app that i am creating?

2 Answers 2


It's not a question of singlepage/multipage, it's a question of source code organisation

To exagerate a little: it is like asking if you should have only one source file, since your result is only one executable.

How you present the page to the customer (1 page with js/4 pages with links) is a presentational issue, that should not interfere with how you organise your code.

How you keep your source files should determined by how easy it is for the coders to read, extend, debug them.

And how you meet these needs is determined by the actual tasks at hand, and not nesessarly by whether you present them to the user in a single page.

So, without talking about the projects details, i think, it's not easy to answer your question.

As a general guide how, imho, HTML-Templates should be structured, i would suggest the following:

  • The general page layout should be structured to provide some kind of inheritance, so that i easily can create new pages with the same header, columns, footer, etc, where only placeholders need to be filled.

  • each "widget" the page uses should be a functional unit, not depending on it's environment. for example, if you have tags, you should only change a single place in your source if you want all your tags to be dispayed as lowercase

Depending on your Technology Stack, these constrains may already imply a certain file structure: in Jinja2 (python templating engine), the general page layout inheritance needs seperate files, in Rails, the rendering of the widgets would be realised via "partials", which would be separate files, too.

Generally, i prefer small files, but that's more a preference. Before overengineering, just start simple (i.e., one file), and dont hesitate to split, as soon as it starts getting messy.

  • The app as far as the user is concerned is actually 4 different screens. I was wondering if i should render the different screens in the one page (its not just data that changes but the UI), or put the code together as 4 different pages. Does that help to explain better? Im happy to share project details further if need be. Jul 12, 2012 at 12:35
  • i extended the answer a little
    – keppla
    Jul 12, 2012 at 13:33
  • Thanks. I'm planning to use Node.js/MongoDB server side and dust.js client side. I am concerned about the transition between screens however. I'd like there to be a transition effect between each screen. I know that if this was a front-end only app then i would do everything in the one page in html with jQuery, but it would make the page very heavy and the code difficult to maintain Jul 12, 2012 at 13:44
  • 1
    why should the code more harder to maintain? What i say is that you are free to organize your code in one way, and present the resulting html to the client in another. Even if the clients gets everything in one big html-page, that does not mean the page is not assembled from many templates.
    – keppla
    Jul 12, 2012 at 15:11
  • Oh right. So essentially, to make life easier for myself, i could infact use different pages (as i find it easier that way) and then pass to the client the different elements that i need by taking advantage of the way node.js works - yes? Jul 12, 2012 at 15:20

I assume you're trying to create a single HTML page where the contents change depending on the data returned from the server.

Its not the programming model used by HTML, but I guess it can work... You can reload html sections using jQuery's .html() call - so the server can return chunks of html and you can display it dynamically. Put the sections you'll be reloading in a div and you'll be able to easily find the part of the page that gets reloaded.

  • The app as far as the user is concerned is actually 4 different screens. I was wondering if i should render the different screens in the one page (its not just data that changes but the UI), or put the code together as 4 different pages. Would that still work for me? Jul 12, 2012 at 12:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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