Is Python back-end or front-end?In google some say that it's front-end some back-end and even both,so I want to know from you?

Answer 1

Python on web frontend is really not a typical scenario, but it is possible in two ways:
- python code is transpiled to javascript, there are several JS libraries that do this:
https://brython.info/
https://skulpt.org/
- python code is compiled to webassembly:
https://github.com/iodide-project/pyodide

Answer 2

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

Answer 3

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

Answer 4

[Part 3 of 6] - Clarifications to other Responses
------
1. Regarding Python as a Frontend Language
---
I would consider Python a frontend language for web development when using a transpiler like Brython. That is not to say that Python is a native language for the browser or that I recommend it for professional web development. It makes no difference that the language used to implement the code is transpiled into Javascript, then compiled into bytecode and finally machine code. It makes no difference if a pre-processor was used to do that transpilation or if it occurs at runtime within the browser. The language in which the source code was written and is maintained is the language used. Period.

I also consider Python to be a frontend language as it can be used to build "client" apps with user interaction that integrates with unattended processes.

------
2. Regarding SCSS, SSRs, etc
---
I don't consider pre-process compilations / asset bundling (used for scss, less, minification, obfuscation, server static rendering, etc) to be a "backend" process. Rather, these are more related to prepackaging deployment of a development workflow rather than the network topology of runtime processes.

------
3. Regarding DLLs
---
DLLs are libraries linked to application executables or a loaded server process similar to jar files in Java; SO files in linux; modules in Python; or NPM packages in NodeJS; etc...

DLLs are in-process components that must run within the memory space of an existing process. Whether or not DLLs are used makes no difference to qualifying a process as "frontend" or "backend". This is more about reusability of deployed code than runtime integration.

Answer 5

[Part 4 of 6]
------
4. Regarding Usage of Design Patterns like MVC:
---
It was stated earlier...

>"But by definition, frontend is what the client sees and interact with. Clients should not interact with a backend directly but with an abstraction layer(called controller in MVC). I hope this was helpful."<

The problem with this explanation is it's now attempting to narrow the scope of "frontend" even further to apply only to View templates and visual design. This would disqualify Javascript as a "frontend" skill. It would also change server side View templates into "frontend", even though those are part of the so-called "backend" services.

Attempting to conflate the meaning of "frontend" to apply to one part of any MV* design pattern is a slippery slope that will only lead to more confusion. But... that's just my opinion. 😉

------
5. Regarding "Frontend" as an Abstraction:
---
The reference to this in an earlier response sounds like an attempt to make "frontend" fit the same definition as a "view" in a Model View *Whatever design pattern. In that case, the differences between "backend" and "frontend" are going to get even more confusing.

At this point, I would just drop the usage of "frontend" to eliminate ambiguitous interpretations. It would be clearer to refer to HTML / CSS / View Templates more explicitly than trying to force fit multiple meanings by different people. 🤷‍♂️

Again... just my opinion. 😜

Answer 6

First of all, tell me your understanding of frontend and backend.

Answer 7

[Part 5 of 6]
------
6. Regarding Backend Running in a Browser
---
It was stated earlier on:

>--
"Sometimes the backend might run in a browser.

Consider a single page application whose model is in cloud storage. The backend performs the CRUD... operations using ajax and displays a dynamic frontend using client side rendering and routing."
--<

Here, it appears that "backend" is being more narrowly scoped to refer to "business" and "data" layers.

The introduction of SPAs might have been the cause of this confusion. For instance, ReactJS is simply a library for the view layer. But, it's purely Javascript and contains logic that could be classified by some as more than "presentation".

------
7. Regarding Interactivity as a Feature of the Front End
---
It was stated earlier:

>"Interactivity is just a feature of the front end and ... Interactivity can never occur in the back end."<

I would say that "interactivity" is the distinguishing requirement that qualifies a "client" process as "frontend".

------
8. Regarding the statement:
---

>"Abstraction is not front-end. Abstraction is back-end."<

It's all relative to the subject in question.

When comparing to a monolithic application, separation of concerns are indeed abstractions regardless of how they're referred to:

- frontend / backend
- client / server
- presentation / business / data

That said, abstractions exist within each of these layers and externally to these layers. Like I said... it's all relative.

------
9. Regarding OSI Model:
---
Layer 6 (aka Presentation) of OSI refers to the raw data formatting that typically occurs before the application receives or sends data over network protocols. For example, SSL is an encryption protocol that an application wouldn't necessarily deal with unless it was the web server or low level communication library.

Layer 7 (aka Application) of OSI refers to any application processes, including what we're referring to as "frontend" and "backend". Again, "separation of concerns" are a bit relative here.

Answer 8

[Part 6 of 6] - Wrapping Up...
------
10. Regarding rants about Python being overhyped (by me 🙃):
---
I don't recall ever saying Python isn't one or the other in regards to "frontend" or "backend". If I did, then my bad. 😉

For clarification, I think I have been or am just as critical about other languages as I am about Python. The reason people would characterize my criticisms about Python speaks to the root of the issue where the massive number of Python supporters will not stand for anyone criticizing this G.O.A.T. of all languages. I'm not targeting anyone in this thread... I'm speaking in general. This is the hype I'm referring to. While I would have gotten some flack in the past when I used to criticize Javascript, C#, PHP, VB.NET, or Java, most people were also very objective and recognized the respective limitations.

For example, when criticizing Javascript about lack of block scoped variables, it was always a productive discussion. Bring it up about Python and I'm the joke of programmers who like to over complicate my code and complain about things that aren't needed. In reality, the language design decisions of Python make block scope variables simply not possible, even if deemed important. Rather than acknowledge this, I'm labeled an elitist who rants.

But... that's fine... if that's the reputation I have with Python. It's unfortunate though as I think this overall mindset is what will prevent Python from evolving into the great programming language I believe it could become.

------
Conclusion
---
Whew... if you've made it this far, you're a champion in my book.

I hope no one feels targeted in my responses. I was only responding to statements that stood out, not the person making the statements.

I've likely skipped over other statements worth addresssing... but, I think this is far more than anyone would have wanted.

So, I'll stop here and hopefully, this was useful information for everyone.

And... if you disagree with my feedback... well then... Rock on! I'm completely okay with that. 😉👌

Answer 9

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

Answer 10

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.

Answer 11

Ore I think a good use case for transpiled python, is when someone is proficient with python but not so much with Javascript, they can take advantage of their programming knowledge. An excellent example is HonFu 's beautiful chess code, written entirely in Python.
https://code.sololearn.com/W5v76nCjupV7/?ref=app
Of course the drawback is that you can only use a limited set of the python standard libraries like this, and nothing external.

As for WASM I recommend to read this article, Pyodide is still just an experimental project but its aim is to run the Python data science and machine learning tech stack inside the browser. So technically no other software is required to run these things. Comes at the price of large size, though.
https://hacks.mozilla.org/2019/04/pyodide-bringing-the-scientific-python-stack-to-the-browser/

Answer 12

Tibor Santa, thanks for the flowers! 🙂

Well, with Brython, the main problem is that it has to be translated to (suboptimal) Javascript.

As I see it, it runs really slow.

It's right, I am less fluent in Javascript, and since that chessboard was quite challenging for me, I didn't feel confident to tackle it in JS.

But it clearly comes at a price.

So as long as browsers don't start to actually efficiently work with Python code, I'm not sure how much sense it makes in web frontend...

Btw, I use a personal definition of frontend and backend, treating them flexibly. Dunno if that's wrong.

If there's a function checking for prime number, I'd call it backend.

If another layer of the program calls this function with a user value and gives them the result, I'd call that frontend.

So I'd personally use these terms contextually, if that makes sense...

Answer 13

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/

Answer 14

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

Answer 15

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.

Answer 16

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.

Answer 17

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.

Answer 18

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.

Answer 19

Kode Krasher But in the context of the web, JavaScript is a much better fit as it has wide spread browser support and many of this alternatives compile anyway to JavaScript. I still don't know a good use case for any of this alternatives yet (including web assembly).

Answer 20

To better understand if something is a front end remember that the frontend only *abstracts* functionality. It does not solve anything. Without the frontend it is possible to still make changes to the database of a website and add a new user or product. The frontend is just an abstraction.

Sometimes the backend might run in a browser.

Consider a single page application whose model is in cloud storage. The backend performs the CRUD(create, read, update, delete) operations using ajax and displays a dynamic frontend using client side rendering and routing. The user does not interact with the CRUD controller directly but with the view (the visible controls on the page). Also note that this CRUD app also serves as a client for the storage mechanism.

Note: for accessibility and performance reasons it is not a good idea to build apps this way. Instead consider using SSR frameworks like Next, Nuxt or NestJS.