What is the basic difference between Brython and PyScript?
Question:
I was trying to understand the difference between PyScript and Brython. So I read the following post:
and didn’t understand anything apart from the following line:
Brython converts Python code into native JavaScript, while PyScript is native Python code that is executed via Web Assembly.
So, what I understand is Brython is a clientside Python code that could be used instead of JavaScript.
However, I am not sure what PyScript is good for. Is it a replacement for PHP or AST.NET or JSP or similar technologies in the Python realm?
What is the basic difference between Brython and PyScript?
Answers:
The link you gave is exhaustive.
- Brython transpiles from Python code to JS; the generated JS then runs without relying on the original Python source code
- PyScript has a complete Python interpreter compiled to WebAssembly which interprets the original Python code without converting it
They both run entirely on the client-side, they just load the transpiler (written in JavaScript) or interpreter code (compiled from the original C code to WebAssembly), from a server, and then apply them to the Python code in the client’s browser. The tools you’re comparing to are all run server-side to generate pages to send to the client, they don’t fit the same niche. Both Brython and PyScript are intended to let you do client-side scripting in Python instead of JavaScript; other client-side scripting languages generally work in a similar way, allowing some other language to become JavaScript (or WebAssembly), or be interpreted by JavaScript code.
The different design decisions don’t require any particular differences in how they behave.
The main advantage to PyScript is that it’s easier to update; compiling existing C code to WebAssembly is a mostly solved problem (and the CPython project goes out of its way to try and help when something they’re doing doesn’t compile to WebAssembly properly), so updating to newer versions of Python just means recompiling the interpreter to WebAssembly again. Brython by contrast involves a custom Python-to-JS transpiler, which I suspect imposes a much higher maintenance burden on the developers. That said, Brython appears to already be Python 3.11 compatible, so clearly it’s not as hard to update as I thought, or they’re putting a lot of work into it to keep it in sync with the CPython reference interpreter.
It’s possible Brython might run a little faster (in exchange for potentially longer start-up) since it converts to native JS which the browser understands directly, while the browser would not be able to understand the meaning of the data (the Python code) the WebAssembly Python interpreter is interpreting, but given how over-complicated the Brython-generated JS is, I doubt the browser is able to optimize it much in any event. You’d have to test it on real browsers, to draw any firm conclusions.
PyScript and Brython are two different implementations of Python that can be used in web browsers. Brython is a transpiler that converts Python code into JavaScript, while PyScript is an interpreter that runs Python code natively in the browser using the browser’s JavaScript engine.
Both PyScript and Brython allow you to run Python code in the browser, but there are some differences between the two. For example, Brython is typically faster than PyScript because it converts the Python code into JavaScript, which is a more efficient language for running in the browser. However, PyScript has the advantage of being able to run Python code natively in the browser, which means it can more easily access browser APIs and other features.
In general, whether you should use PyScript or Brython will depend on your specific needs and requirements. Brython may be a better choice if you need to run large or complex Python scripts in the browser, while PyScript may be a better choice if you need to access browser APIs or use other features of the browser. It’s also worth considering other factors, such as the size and complexity of your code, the performance requirements of your application, and the level of support and maintenance required.
I was trying to understand the difference between PyScript and Brython. So I read the following post:
and didn’t understand anything apart from the following line:
Brython converts Python code into native JavaScript, while PyScript is native Python code that is executed via Web Assembly.
So, what I understand is Brython is a clientside Python code that could be used instead of JavaScript.
However, I am not sure what PyScript is good for. Is it a replacement for PHP or AST.NET or JSP or similar technologies in the Python realm?
What is the basic difference between Brython and PyScript?
The link you gave is exhaustive.
- Brython transpiles from Python code to JS; the generated JS then runs without relying on the original Python source code
- PyScript has a complete Python interpreter compiled to WebAssembly which interprets the original Python code without converting it
They both run entirely on the client-side, they just load the transpiler (written in JavaScript) or interpreter code (compiled from the original C code to WebAssembly), from a server, and then apply them to the Python code in the client’s browser. The tools you’re comparing to are all run server-side to generate pages to send to the client, they don’t fit the same niche. Both Brython and PyScript are intended to let you do client-side scripting in Python instead of JavaScript; other client-side scripting languages generally work in a similar way, allowing some other language to become JavaScript (or WebAssembly), or be interpreted by JavaScript code.
The different design decisions don’t require any particular differences in how they behave.
The main advantage to PyScript is that it’s easier to update; compiling existing C code to WebAssembly is a mostly solved problem (and the CPython project goes out of its way to try and help when something they’re doing doesn’t compile to WebAssembly properly), so updating to newer versions of Python just means recompiling the interpreter to WebAssembly again. Brython by contrast involves a custom Python-to-JS transpiler, which I suspect imposes a much higher maintenance burden on the developers. That said, Brython appears to already be Python 3.11 compatible, so clearly it’s not as hard to update as I thought, or they’re putting a lot of work into it to keep it in sync with the CPython reference interpreter.
It’s possible Brython might run a little faster (in exchange for potentially longer start-up) since it converts to native JS which the browser understands directly, while the browser would not be able to understand the meaning of the data (the Python code) the WebAssembly Python interpreter is interpreting, but given how over-complicated the Brython-generated JS is, I doubt the browser is able to optimize it much in any event. You’d have to test it on real browsers, to draw any firm conclusions.
PyScript and Brython are two different implementations of Python that can be used in web browsers. Brython is a transpiler that converts Python code into JavaScript, while PyScript is an interpreter that runs Python code natively in the browser using the browser’s JavaScript engine.
Both PyScript and Brython allow you to run Python code in the browser, but there are some differences between the two. For example, Brython is typically faster than PyScript because it converts the Python code into JavaScript, which is a more efficient language for running in the browser. However, PyScript has the advantage of being able to run Python code natively in the browser, which means it can more easily access browser APIs and other features.
In general, whether you should use PyScript or Brython will depend on your specific needs and requirements. Brython may be a better choice if you need to run large or complex Python scripts in the browser, while PyScript may be a better choice if you need to access browser APIs or use other features of the browser. It’s also worth considering other factors, such as the size and complexity of your code, the performance requirements of your application, and the level of support and maintenance required.