68 AnswersNew Answer
[Part 1 of 6] - General Context Apologies for one of my epic long responses. Hopefully, it's considered useful. FWIW, I'm but a humble software engineer who has personally witnessed and experienced the usage of these terms take shape over the years. Perhaps I can provide some anecdotal perspective on the various talking points through this discussion that may or may not align with what others have experienced. **DISCLAIMER** I'll be sharing clarifications according to my *personal* usages of these various terms and concepts in professional settings with other colleagues which have remained consistently understood over the past few decades. These professional settings include architectural and technical discussions for everything from small to enterprise scale development projects across a variety of languages and platforms. These are typically understood between experienced developers working within the same team, across teams within the same company, and collaborating with developers in other companies throughout the USA. This may or may not be different for people in other countries. Before I begin, I should clarify that the terms "frontend" and "backend" are rarely used in my circles in technical discussions. It's something I'm only now just realizing... but, it's true. We don't refer to "frontend" and "backend" as they are frequently used in communities like this and in job listings. I suspect "frontend" and "backend" usage has grown due to job recruiters trying to find a simple way to understand the positions they're trying to fill. Who knows? In my experience, we often refer explicitly to "SPA" or "web client" or "mobile / desktop / console app" for "frontend" processes. For "backend" it's typically "web / windows / micro service" or "deamon" or "scheduled task" to name a few. For the purposes of my responses, my treatment of "frontend" and "backend" will, for the most part, apply to the more explicit references I listed above. Now that I've set the context, I'll begin my responses in separate posts.
[Part 2 of 6] - Frontend vs Backend Historically speaking, "frontend" applies to any process that supports any user interaction. This includes console apps and desktop / mobile / web apps. "Backend" applies to any unattended process or service that typically responds to requests, events, or messages triggered from another process, scheduled task, or interval of time. Additionally, when multiple "frontend" processes are interconnected with one another and don't require a "backend" process as a central hub, they would be considered "peer-to-peer clients". Self contained applications with user interaction that don't connect to any other processes would simply be "standalone" as in a "standalone" desktop / mobile / console app. Note, "frontend" is a subset of "client". The difference is that "client" processes don't always have to have user interaction to be considered a "client" to another process. That is to say, one unattended service can be a "client" to another unattended service and neither be considered a "frontend" process. A process that is a "client" to another process could also be a "backend" service for another process. It's all relative. In fact, a "backend" can apply to processes on the same or different server as the "client". Therefore, the delineation may be that a "frontend" is a "client" process with user interaction that integrates with an unattended process. As more and more people are beginning their careers by first learning web development, it seems that the usage of terms like "frontend" and "backend" have grown. The meaning has also become more narrowly scoped over the years by associating "frontend" with web browser languages and "backend" with the web server development. It does appear that the terms are now broadening such that "frontend" is associated with GUI based client applications that communicates with any "backend" services over HTTP, like SOAP web services or RESTful APIs, etc. But, again, this is still very narrow in scope.
First of all, tell me your understanding of frontend and backend.
David Carroll Thanks for your response and I agree for the most part. Regarding (2. Regarding SCSS, SSRs) SCSS, asset bundling does not stand in the same box with SSRs. When I say SSR I mean "Server side rendering" not "Server static rendering" as you used it. Server side rendering occurs in the back end in response to a user front end input. I don't see how server side rendering is in anyway part of "prepackaging deployment". I agree about the other areas and thanks for shedding some light in this discussion. Tip: You can include a TL;DR for those who do not like long answers. Although that might be difficult considering the amount of info you covered. 😉
Kode Krasher There are several frontend python web frameworks out there. Brython is perhaps the most popular. You can look it up. Also frontend may not necessarily mean the frontend of a website. It can refer to that of a mobile app or desktop app. With frameworks like Kivy and Tkinter, Python does enough in "enhancing" the frontend.
Ore Ah... Thanks for clarifying SSR. TBH... I was completely lost by the reference to "ssr template engines". Specifically... in the context of the references below: 1. "scss assets, assets compilers and ssr template engines that assist in generating content to be displayed" 2. "SSR frameworks like Next, Nuxt or NestJS" The first reference put me in the context of pre-processors and the other reference reminded me of server-side static rendering to generate static HTML on the server as a caching mechanism for improved performance. I think of this as "isomorphic" rather than server-side rendering. But... that's my bad. 😉 I guess I've not noticed that "SSR" has been popping up as an acronym for "server-side rendering". ;) This happens. I remember being confused when I first saw references to "SOA" and, later, "microservices" long after I had been designing solutions that essentially followed those architectural models. I find it more challenging trying to keep up with how things get marketed after a while than I do just implementing the concepts. 🤓 For those unfamiliar with what I was referring to with isomorphic static rendering, I've included a few links: https://www.npmjs.com/package/react-isomorphic-render https://nextjs.org/docs/advanced-features/static-html-export https://docs.nestjs.com/recipes/serve-static https://nuxtjs.org/blog/going-full-static/ https://frontarm.com/james-k-nelson/static-vs-server-rendering/
Kode Krasher Your definition of backend as "a service not directly related to displaying content" is only true in a small project. In a typical project, there will be many helpers on the backend like scss assets, assets compilers and ssr template engines that assist in generating content to be displayed. Wikipedia explains front end and back end extensively here. https://en.m.wikipedia.org/wiki/Front_end_and_back_end
Translated: You can use Python for web frontend, but the result will be suboptimal, just like when you try to hammer in a nail with a screw driver.
I think 'marketing' is the wrong word. There's no company 'Python' profiting from us users spreading misinformation here. This is a beginner app, so users naturally first receive a simplified version of the reality. The qualifications come later. 'After you've learned Python, you can (alongside the more typical application areas) make desktop apps, android apps, homepages, games... so it's a versatile general-purpose programming language.' With more knowledge and experience, you learn the qualifications, the summary of them being that each task can probably be done better with other languages in cases where it really counts (professional settings). Over the years I've read enough rants about Python being overhyped (foremost by David Carroll), and if you just apply it strictly enough, you could even say Python is neither a frontend nor a backend language (because professionals likely prefer Java, C# or whatever). It's a bit like one of these discussions about HTML being a programming language or not.
I am still feeling my way around this whole developer mindset, that is why I asked the questions I ask. I work with a lot of web developers, from many different companies, but I never before paid much attention to what they do. I know there will always be different perspectives and the bias can be comical, so I take everything with a grain of salt anyway. I have a lot left to apply... personally and professionally being selective, so I don't waste what time I have left in the work force. 5-10 years from now it's possible this thread won't even be relevant. Some new language will be in the spot light, and we will have a new set of users chasing that new thing?! 😉
Python is mainly used for backend but you can also do front end work with python : https://www.fullstackpython.com/web-development.html#:~:text=How%20does%20Python%20fit%20into,in%20getting%20their%20application%20working.
It is backend. You can use it to serve html, but like php or perl, it is parsing the html, not simply serving it, the client is not rendering python, it is rendering the served html. My understanding is even the web frameworks that use python (like flask or django) are backend as well.
You clearly do not understand what backend or frontend mean. Why don't you search Google for that instead? From there you will understand that Python can be used to enhance the frontend as well as create the backend. It is general purpose.