Should website frontends be rendered in client-side or server-side?

Question

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?

Answer 1

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.