25

Typically when I put together dynamically generated HTML markup, I've been using PHP to store the information and then looping through that to create elements on the page. One example is navigation; create an array of objects and then loop through them to echo the markup. This helps out a lot for times that I might have to make minor (or major) changes during development or maintenance.

Lately I've been wondering if I should use JavaScript to do this instead. Same principle, but using addElement.

Just wanted to get some opinions on this; pros, cons, php vs js, seo considerations, etc.

Thanks folks!

Eric
  • 2,061
  • 8
  • 28
  • 37
  • 1
    Thanks to everyone for their input. This has helped confirmed my suspicions, especially on the SEO. Stack Overflow FTW! – Eric May 24 '11 at 13:42
  • 1
    Well it appears, despite the consensus here, JavaScript is the way to go now (Angular, React, etc). One important pro for JavaScript that no one mentioned, is no page reload, resulting in much better user experience. – Sarsaparilla May 18 '16 at 19:25

6 Answers6

44

Doing it client side means:

  1. Doing it in lots of different environments instead of a single one
  2. Having it break whenever a user comes along without JS (for whatever reason)
  3. Having it fail to work for the vast majority of bots (including search engines)
  4. Investing development time in converting all your logic
  5. Requiring the browser to make additional requests to the server, slowing down load times

When deciding if you should do something client side instead of server side, as a rule of thumb ask yourself two questions:

  1. Would the user benefit from getting instant feedback in response to them doing something? e.g. An error message for improper data in a form they are trying to submit. If so, then doing it client side would be beneficial.
  2. Can it be done server side? If so, do it server side first as it is more reliable (and for non-cosmetic things, harder to interfere with). Build on things that work.
Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
  • 3
    My rule of thumb is "do as much as is possible server-side". JS only for progressive enhancement. Anywho, good answer. +1 – mpen May 24 '11 at 06:30
  • @Mark — isn't that what I said? :) – Quentin May 24 '11 at 06:47
  • Yeah........I think I read until the end of point 1 and then my brain shut off or something. – mpen May 24 '11 at 15:28
  • I think you should update your answer)) nowadays there are cool frameworks like angularjs, backbone, ember that render html very nicely, bindings are perfect way to write html. Why to load server? I agree that recently we were not able to write maintainable code because of lack of structure on client side (i'm using angularjs and it's possible to have very good mvc structure on client side). – karaxuna Mar 26 '14 at 18:47
  • Using something like Angular doesn't stop any of the 5 points in this answer from being true. – Quentin Mar 26 '14 at 19:40
  • 1
    True angular doesn't counter your arguments in itself. But you fail to acknowledge that javascript isn't inherently a client side language, although commonly used on the clientside. Even at the writing of this answer nodejs had already made a big splash in the world. Argument 3 also fails to acknowledge that html can be served in a headless browser to bots, which google itself recommends for JS driven applications. With these considerations most of your agruments are negated. – codewizard Aug 29 '14 at 23:00
  • "Requiring the browser to make additional requests to the server, slowing down load times" Wouldn't client side code use LESS server requests because it doesn't have to keep asking the server to do everything? "Build on things that work." JavaScript works pretty well to be honest. – Yay295 Jul 13 '15 at 04:59
  • @Yay295 — No, because you'd generally making requests for JS files and data files as well as the HTML file instead of just requesting an HTML file. JavaScript works pretty well except when it doesn't, delivering working client side code to a variety of different clients on different networks meets many more possible points of failure than plain HTML. – Quentin Jul 13 '15 at 17:28
4

It's not an either one or the other type of situation; generally you will need to do both.

Doing it client side will probably be slower, as the server still needs to figure out all the data but the client needs to render it; this will involve multiple requests (most likely) and DOM manipulation is slow (especially on older browsers).

El Yobo
  • 14,823
  • 5
  • 60
  • 78
4

Best practice would be to produce any necessary markup on the server side. Reasons for this include:

SEO: Most crawler bots won't parse Javascript, so they'll skip over anything crucial that you're generating with addElement.

Accessibility: Your site should basically functional without Javascript. Consider people who might be browsing your site on Kindles, older Blackberries, Nokias or other feature phones with data. They don't need all the fancy styles and effects, but they should at least be able to get around your site.

Consistency: JS can add yet another level of cross-browser variability. Why rely on client-side rendering of necessary markup? Do it server-side.

Of course, this advice can be taken in stride if you're developing an all-JS desktop app or using something like the Sencha Touch framework.

Charlie Tran
  • 49
  • 2
1

If SEO is your concern, things are simple: JS is not indexed.

There also are UI issues: if JS is not enabled, no JS-dependent stuff will load.

Denis de Bernardy
  • 75,850
  • 13
  • 131
  • 154
0

PHP is good for some things, including Handlebars type templating, and fast server-side content replacement. But it is also not great for some things, like single page applications and games, real-time updates to websites. Those things are where JavaScript is strong.

Gort
  • 1
0

One possibility would be to detect what kind of user is viewing your site :

  • If it's a bot: parse on the server-side, you may just output what is needed by the bot, without graphical things,...

  • If it's a mobile : show a mobile optimized version, using something like Sencha Touch, as Charlie pointed out

  • If it's a standard browser, without javascript : render the page on the server side

  • If it's a standard browser, with javascript enables : just send the data from server side (or load it with Ajax) and render the data from the client-side

You may use something like Mustache, wich is a template engine running on many server-side languages (PHP, Ruby, Java,... but also on Javascript, enabling client-side page rendering!

And try to use a Javascript framework like jQuery, Mootools, Dojo or ExtJS, they will help you to write code that will run on every browser.

ygosteli
  • 231
  • 2
  • 7
  • Using those "frameworks" will only get your code running on a small number of reccent browsers. Certainly not "every browser". Much better to use sever-side logic and cache static (or mostly static) pages as much as possible. – RobG May 24 '11 at 07:25
  • Most of them are supporting old browsers as well, and for what I tried with jQuery it worked pretty well. And hopefully we'll soon been able to throw away IE6... (I know it's not the only one old browser... but one of the ugliest for sure...) – ygosteli May 24 '11 at 08:13