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've been talking to a colleague that comes from AS3 to the HTML world. He has created a small website (there are apparently no dynamic contents) following the no-flash rules for his very first time, and as if you own a hammer you tend to hammer everything, he decided to create a framework in JavaScript, so he could do all "the AS3 way", with frames, pure X-Y coordinates animation and so, to animate contents. The page would be fully loaded at first, load the vast amount of JS at first and then the page would be accessible without changing url.

Views would turn into class methods (where the class represents a section, and the method stands for a view) which append text to a variable that is then added to a div. He defends this situation with many reasons:

  • Websites with a high amount of users do this to prevent server overloading.
  • It is easier to create new sections.
  • It is easier to translate, as translations, texts and almost everything is loaded from a JSON.
  • You can expand more sections directly from a JSON file.
  • Everything is smooth, as you don't move to another page.

Now, here comes the PHP-loyal developer, which defends the opposite side. I say that views should be split into smaller files but contained in .php or even .html files, with the business logic in a controller and the view logic in these files. This releases the client, as it can disable JavaScript and still show the content without a matter. Of course your server needs to make calculations, but it's just rendering files. Some benefits could be:

  • You don't need to load the whole website at first. Webpages loaded faster.
  • Your urls are always clean and (in case you did so) friendly, without plugins and working seamlessly in old browsers, as you move to another page.
  • Views are kept in independent files, so it is easier to work with them in a team.
  • Views are regular html files, instead of calls to methods appending strings, so editing them is just natural.
  • You still need PHP (or any other language) to load data from a server (NodeJS not considered here)

And, of course, here comes the real question. Should views be rendered on client or server side?

share|improve this question
8  
As with many things in software development, the answer is "it depends." –  Robert Harvey Apr 16 '13 at 17:31
    
The HTML5 History API allows you to implement both approaches simultaneously. See: github.com/blog/760-the-tree-slider That said, it sounds like the correct tool for this job is probably Wordpress. –  user16764 Apr 17 '13 at 5:01
    
It should work in IE8, as mentioned to @LucFranken, so History is not available yet. Plus the site is amazingly small, and Wordpress is too big, even for this case. But thanks for your comment –  Korcholis Apr 17 '13 at 5:58
    
"It should work in IE8". That is exactly why you would use the History API. Then IE8 users get the page-by-page site, and people with newer browsers get the cooler all-Javascript site that that you've progressively enhanced it to. –  user16764 Apr 17 '13 at 14:43

1 Answer 1

up vote 4 down vote accepted

@RobertHarvey is totally right. It depends. It could be a good solution but it is a terrible solution also for some projects.

In you question you state:

He has created a small website (there are apparently no dynamic contents)

Based on that he chose the wrong solution. Now you also note that there are animations. So maybe, if those are exceptional, it might be a good solution. Let's state those animation could also be made with normal solutions.

Whether it is good or right is then simple: If it should work like a normal website, so with a good ranking in search engines, good accessibility and all other standard webdevelopers take care of it is just wrong. You build a website with a goal. If that is: Have normal people visit it to subscribe/buy/view etc. it won't meet that goal.

His arguments:

Websites with a high amount of users do this to prevent server overloading.

Yes, but this is a small website right? http://c2.com/cgi/wiki?PrematureOptimization

It is easier to create new sections.

Likely he is unaware of other solutions. No problem, it's his first one. This is something where training / reading could do a lot.

It is easier to translate, as translations, texts and almost everything is loaded from a JSON.

Same here, localisation is something much more complex than just translating some pieces of text anyway. Education is here also the key.

You can expand more sections directly from a JSON file.

Might be correct, seems simple to do. If a user has to do it then it directly becomes more difficult. With a database for example it might be possible to create a form for that.

Everything is smooth, as you don't move to another page.

This is true but not undoable with other solutions. Loading pieces of content with ajax (with changing the browser history) might solve this well. https://developer.mozilla.org/en/docs/DOM/Manipulating_the_browser_history

To take this into a broader level: It is nonsense to build a dedicated framework if it is just a simple site. Use the basics or an existing system for it. On the other side, it's a nice learning experience. We all tried to build a CMS once right? ;) His arguments are not strong, if he want to work more in this area more knowledge would be advisable.

share|improve this answer
    
I agree with you in almost each point. And along with you and @RobertHarvey, the solution always depends. In this case, IMHO, PHP would have been better (and faster), because it has few effects (which can still be done in JS) and plenty of pages with contents which need to be translated, urls which need to be "friendlied" and frameworks which were already done (precisely we own a tiny framework that fits any microsite easily) –  Korcholis Apr 16 '13 at 17:58
    
On which point do you not agree? ;) However I would like to stretch out (think that's most important part of my answer): It is not about what we prefer. It's a project which has expectations. That's the thing which should be aimed for. The way it is solved (PHP/.NET/custom/JSON/whatever) if for the customer or visitor generally not interesting at all. It should be about the right solution for the real problem of the client. –  Luc Franken Apr 16 '13 at 18:07
1  
Hehe, I partially disagree with your last statement, but because I know the limitations of the project [it should run on IE8, thus history isn't available yet. We went across this thing too =( ], so I was playing with an advantatge. Apart from that, I agree with every point. And that's right, the specifications dictate the path to follow. Finally, we moved to an intermediate solution, with friendly urls from PHP and presentation+localisation from JavaScript. I'd personally have pushed localisation to PHP and presentation to HTML, leaving the behaviors to JavaScript. –  Korcholis Apr 16 '13 at 19:07
1  
Nice to see you give feedback! Sounds like a good intermediate for now! –  Luc Franken Apr 17 '13 at 14:16

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.