PHP vs JavaScript For Dynamic HTML Pages

Question

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!

Solution 1

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.

Solution 2

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).

Solution 3

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.

Solution 4

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.

View more solutions

Comments

[Eric]

Thanks to everyone for their input. This has helped confirmed my suspicions, especially on the SEO. Stack Overflow FTW!

[Sarsaparilla]

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.

[mpen]

My rule of thumb is "do as much as is possible server-side". JS only for progressive enhancement. Anywho, good answer. +1

[Quentin]

@Mark — isn't that what I said? :)

[RobG]

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.

[ygosteli]

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...)

[mpen]

Yeah........I think I read until the end of point 1 and then my brain shut off or something.

[karaxuna]

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).

[Quentin]

Using something like Angular doesn't stop any of the 5 points in this answer from being true.

[codewizard]

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.

[Admin]

Can you please elaborate on these differences?

[Yay295]

"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.

[Quentin]

@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.

[Albert Rannetsperger]

Your "Build on things that work" link... doesn't work. Lol.