Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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?
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.)
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 ;) )
Edit:
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?".
