From my experience in web development, I know that languages like PHP,Java,Python..etc are used for backend development stuff (software that running on server), and for front end languages, JS/HTML/CSS are used.

But I see many companies say that they use, for example, PHP for front-end development, and python for the back-end.

Does that mean PHP is front-end for calling other services written in other languages via REST,RPC ..etc?

closed as unclear what you're asking by gnat, GlenH7, ozz, Michael Kohne, user40980 Oct 2 '13 at 18:39

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.


You have confused the terms "front-end" and "back-end" with "server-side" and "client-side". "Back-end" usually refers to systems which are not directly exposed to the user (database servers, middleware and so on), while "front-end" usually refers to the application (in the case of the Web, this normally means static and dynamic web pages) directly accessed by the client.

In a web application, the client (the user's browser), accesses web pages which are stored or dynamically generated "server-side" by "front-end" technologies. Those front-end components may, in turn, pull data or other information from "back-end" components. So a web application written in PHP would be "front-end" but "server-side". However, if the web pages contained any javascript to be executed by the user's browser, that javascript code would be executed "client-side".

Hopefully I have removed some confusion, but now I risk creating some more.

First, we have AJAX, which is code (usually JavaScript) executed in the client (so client-side), to create the web pages you see by pulling information from Internet-facing services which do not themselves generate web pages. The services are generating their information server-side on the front-end (since they are public and you can point your browser straight at them if you know the url).

Secondly JavaScript is not limited to client-side use, of course. It has become increasingly popular as a "server-side" language (see node.js for one example). As such, its most common use is for just the kind of Internet-facing services I described in the preceding paragraph.

Things used to be much simpler before Web 2.0. Back then, in the context of web applications, the front end was where web pages were generated, while JavaScript only ran client-side and made minor cosmetic to web pages like hi-lighting images when you moved the mouse over them. However, that simplicity made people lazy about their definitions. Now the situation is more complex, so it is important to be precise about these terms.

(Oh, and if you have to use PHP, please keep it on the front end. It is emphatically not a good back-end technology. And if you ever find anybody creating a browser that executes PHP client-side, shoot them.)

  • Given your last sentence, you may enjoy code.google.com/p/php-to-js :-P – Andrea Sep 17 '14 at 8:12
  • if every language can be used on frontend and every language can be used on backend isn't the distinction useless in the way it was asked? it can only be answered in a context of an application. – Claudiu Creanga May 31 '16 at 23:08

I think your question may be quite specific to PHP really, as I can't see any of the other back-end technologies you mention being used like this.

PHP is a funny example as it can be (in a rather ugly manner I may add) viewed as a all-in-one language with regards to a lot of web projects. You can do your traditional "back-end" tasks - such as file and database operations, whilst also building "front-end" mark-up.

This can clearly lead to a spaghetti mess where there is no real separation of concern, so it should really be frowned upon in my mind. For a great example, if you browse the wordpress source you can often get lost - and that is one project where I blame the language, the organisation of the codebase is actually very good.

This can be remedied, somewhat, by using a "templating engine" (such as Smarty)) - but it's still PHP which is building the "front-end" whilst also providing the "back-end" functionality. This was an intentional decision behind the design of PHP however, it is after all a "hypertext processor"!

So PHP can easily fit in to both "front-end" and "back-end" uses, which should clarify your example. Hence you are most likely correct in that PHP will be processing and building all the mark-up for a front-end, but it will be making requests somewhere else to gather the required data - most likely a service wrote in one of the aforementioned languages.

Personally, I feel the whole "back-end" and "front-end" terminology is a bit.. outdated perhaps. I'd rather things were just referred to a client-side and server-side; then there is no real ambiguity.*

Very recently I saw a client spec which required a back-end system wrote in node.js and associated tools, but wanted the front-end build using a PHP framework (Laravel). This comes with many associated costs, and in my mind - isn't an elegant solution and can cause a fair few issues down the line.

Personally speaking, these kind of configurations seem like someone has needlessly shoehorned PHP in to another stack - which means more resources are required than are actually necessitated, maintenance staff need exposure to a wider range of technologies and there are more points of failure.

Furthermore, I also think there are very few scenarios which warrant this kind of intermediary stack; most back-end languages/frameworks are perfectly capable of generating the mark-up required for the front-end. Although I stand to be corrected there.

*Although, to turn your question on it's head.. What about back-end systems built using Javascript? (node.js ;) )


After reading a comment by @itsbruce, I've decided to clarify what I mean by the ambiguity of my "front-end"/"back-end" terminology.

Traditionally this terminology would've been fine, architecturally web applications were a lot simpler - and dare I say it, a lot dumber. It's a lot cleaner in my mind to say "Server Side" and "Client Side", and this is getting clearer as the current trend of pushing more of the processing and logic in to the client is getting common.

It's becoming acceptable to do a fair amount of data processing client-side (just look at some of the javascript frameworks currently trending), yet is that really front-end? The user doesn't see it, they see the results of it - and by traditional criteria that would generally be viewed as "back-end"; but this is occurring in the browser now..

Similarly, and incredibly relevant to this question, is building the mark-up in PHP truly a front-end task? I doubt it, a quick browse of job boards show few front-end developer positions expect PHP experience or knowledge; yet intuition would suggest that the mark-up for the interface is inherently front-end.

The very fact that this question exists acts as an example of how "front-end" and "back-end" are inherently ambiguous, and will continue to be so.

By referring to tasks as "server-side" or "client-side" that ambiguity is lost, you know where the code is executing and what languages will be used. If you said "front-end" in the example the OP has provided, I doubt many people would go "Oh, so PHP on the server right?".

  • 2
    I didn't vote you down, but your answer is nearly as hard to read as the question and it really does not address the confusion over terms (if anything, it makes it worse). More importantly, there simply is no ambiguity between "front-end v. back-end" and "client-side v. server-side"; they describe different and distinct relationships. You might as well say "I'd rather we stopped taking about colour and shape; it's ambiguous that things can be green or blue and round or square and some things are green and square". – itsbruce Sep 27 '13 at 14:06
  • Doh, I didn't have enough time to proof-read as I had to get back to work. Cheers for the comment though, it's given me a heads up to edit. I do stick by my thoughts regarding terminology though, but will expand upon it somewhat. Ta. – Fergus In London Sep 27 '13 at 14:37
  • not necessarily - I consider a web-server language to be part of the client (considering how often webservers are hacked nowadays it should be considered compromised from day 1) so there is a need to distinguish server-side languages that are part of the presentation tier from server-side languages that provide application-tier services. So PHP could be considered a "front-end, server-side" language. – gbjbaanb Sep 27 '13 at 14:44

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