Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
add comment

2 Answers

up vote 4 down vote accepted

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.

share|improve this answer
    
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. –  Khuram Malik Jul 12 '12 at 12:35
    
i extended the answer a little –  keppla Jul 12 '12 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 –  Khuram Malik Jul 12 '12 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 '12 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? –  Khuram Malik Jul 12 '12 at 15:20
show 1 more comment

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.

share|improve this answer
    
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? –  Khuram Malik Jul 12 '12 at 12:34
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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