5 ms·

I was wondering if we should not code a Python renderer for one JS framework and be done with it. We already have one JS engine in Python (https://github.com/k

I was wondering if we should not code a Python renderer for one JS framework and be done with it. We already have one JS engine in Python (https://github.com/kovidgoyal/dukpy https://github.com/kovidgoyal/dukpy). We even have pluggable renderers (https://pypi.python.org/pypi/PyExecJS https://pypi.python.org/pypi/PyExecJS). Later we will have webassembly renderers in Python, so you will be able to take frontend frameworks, compile them and execute them in Python. Finally, we have some fantastic framework that are powerful, yet not that big, such as Vue.js, that already have a pluggable architecture for rendering without a DOM on the server side (https://ssr.vuejs.org/en/basic.html https://ssr.vuejs.org/en/basic.html) The Python community has done much more complicated projects already, and half the work is there, so my guess the reason it hasn't happened yet is we REALLY hate js and most of us just touch it to get the job done and go to the next task. It's a bit like the async situation. We have the tools, but there is no Django of the asyncio because we love our tools as their are so much. I'm so guilty of this. The problem is: the rest of the Web is moving ahead, and while it's still relevant to do DRF + Vue.JS right now, one day stuff like meteorjs will be so crazy yet stable it will be hard to compete. I was hopping webassembly would let us eventually run Python on the client side. But I doubt it will happen. However, I'm thinking more and more than it will allow JS tooling to be plugged in many other languages on the server side.

vosper 9y ago
I've just got back into the Javascript world after several years of Python programming. My gut feeling is that we will end up with APIs in some language, and universal [0] Javascript apps that can render both client and server side. I don't think there's a place for non-Javascript server-side templating in the long run. JS (as a language, forgetting about the frameworks) has really come a long way in the last few years, to the point where I don't think you'll be able to justify having two different HTML rendering systems for much longer. [0] aka isomorphic, but universal seems to be the new (IMO better, less overloaded) term for that
- RobertoG 9y ago
  You are, my friend, an optimist. After learn and forget a few js frameworks, see develop the "compile to javascript" fashion, javascript jumping to the server, the different flavours of MVC, "isomorphic programming", subsets of javascript that compile to whatever and etc..; my gut feeling is that it will never end. If that is a good or bad thing is left as an exercise for the reader.
- sametmax 9y ago
  I don't know, I put Vanilla, jQuery, Angular, React and Vue in production. I used gulp and webpack and manual setup. I used node and static js. In in end, nothing is well integrated. You would think the whole bloody "one language to rule them all" concept would make the JS stack the most integrated one of all. Well to my surprise, far from it. It's a mess of hundred of moving unstable badly documented always changing components that your job is to make work together. There is no django of the JS word. None. And because of that, most JS projects I worked on were disposable projects, prototype in production. Now there is no meteor in the Python word neither. But professionally, I need something solid, not an ongoing experiment. You can make fantastic stuff with JS, but only because the platform is fantastic. The web is genius. The JS ecosystem is terrible. But wish, I really wish the JS community would pick on the seriousness of other communities and the python one would take more risks and innovations like the JS one.
  - vosper 9y ago
    Oh, yeah, it's a mess right now. Debugging especially sucks. I'm hoping that given 5 more years of work on server-side JS we'll get to something that's not miserable, and that transpiling will be a thing of the past
Mizza 9y ago
I actually took a stab at this for a now out-of-favor JS framework, Knockout.js. You can see the project here: https://github.com/Miserlou/django-knockout-modeler https://github.com/Miserlou/django-knockout-modeler It allows you to take a single Django QuerySet and turn it into a SPA with in-page listing, sorting, filtering with a single Django template tag: {{ my_query_set|knockout }} I used in production in a few projects and was very happy. If I were to do this again, I'd re-do it for Vue.js and make the data-syncing bi-directional. But I hope we see more stuff like this.
- sametmax 9y ago
  Cool. Does that parse JS in Python or generate JS from python ?
  - Mizza 9y ago
    Generates JavaScript from Django QuerySets in a single template tag.
no_wizard 9y ago
Why not just something like this? https://transcrypt.org/ https://transcrypt.org/ It's Python to JS in a way that makes sense to me at least. JavaScript and Python have a lot of similarities in the languages imo especially around classes and functions
- sametmax 9y ago
  Because it's a joke. It's just not Python. Not half of the Python libs work on those things. You don't have serious introspection, most of the stdlib is missing, the stack trace doesn't work as expected, you can forget about async / await and yield from, etc. To run Python in the browser correctly, you need the entire 3Mo Python VM. Transpiling is not enough because Python semantics are complicated as it is very, very rich. Comparatively, js is incredibly basic.
captainmuon 9y ago
Or, the other way around: Write a react clone in Python (complete with "pyx" files), and then use one of the python to js transpilers to compile to js on the frontend. On the backend, you'd use "react" just as another simple template language, whereas on the frontend, you'd also have the reconcilation algorithm.
- sametmax 9y ago
  You will never get a perfect Python on JS, only a mockery of it. It would be more confusing than anything. Beside, transpilers add tons of complexity, and this complexity increase more when the language is very different from JS.
  - mixmastamyk 9y ago
    Aren't ES6+ more like Python (or Coffeescript) now than ever? But yes, complexity.
    - sametmax 9y ago
      More yes, they have catched up on syntax. But they are far, far away in term of features. Even if we completly discard the huge and fantastic python stdlib (but really, no hashing or uuid in web language ?), Python has still: - operator overriding - look up interception API - metaclasses - embdedded design patterns: iterator, singleton, context manager, etc. - multiple inheritance - standardised imports, with hooks - controlled gc - dict comprehension - generator expressions - type hints - string formatting language and operations - much more comfortable lists - rich built ins (all, any, enumerate, zip...) - no weird implicit type casting and comparison rules - stack traces and very explicit error messages - support of a lot of charsets out of the box - multiple notations for text and numbers - types for bytes - support for imaginary numbers And so much more. Because Python is such an easy language to use, it's easy to think it's just a simple scripting language. It's not. It is very, very powerful. But it has such a smooth learning curve and you can be productive in it so quickly a lot of people never need to see it. You can compare Ruby to Python. Or Go. But JS ? It's not even on the same planet. The only reason this abomination has this success is because it has an accidental monopoly on the most awesome and popular platform of the human race: the web.

vosper 9y ago

I've just got back into the Javascript world after several years of Python programming. My gut feeling is that we will end up with APIs in some language, and universal [0] Javascript apps that can render both client and server side. I don't think there's a place for non-Javascript server-side templating in the long run. JS (as a language, forgetting about the frameworks) has really come a long way in the last few years, to the point where I don't think you'll be able to justify having two different HTML rendering systems for much longer. [0] aka isomorphic, but universal seems to be the new (IMO better, less overloaded) term for that

RobertoG 9y ago
You are, my friend, an optimist. After learn and forget a few js frameworks, see develop the "compile to javascript" fashion, javascript jumping to the server, the different flavours of MVC, "isomorphic programming", subsets of javascript that compile to whatever and etc..; my gut feeling is that it will never end. If that is a good or bad thing is left as an exercise for the reader.
sametmax 9y ago
I don't know, I put Vanilla, jQuery, Angular, React and Vue in production. I used gulp and webpack and manual setup. I used node and static js. In in end, nothing is well integrated. You would think the whole bloody "one language to rule them all" concept would make the JS stack the most integrated one of all. Well to my surprise, far from it. It's a mess of hundred of moving unstable badly documented always changing components that your job is to make work together. There is no django of the JS word. None. And because of that, most JS projects I worked on were disposable projects, prototype in production. Now there is no meteor in the Python word neither. But professionally, I need something solid, not an ongoing experiment. You can make fantastic stuff with JS, but only because the platform is fantastic. The web is genius. The JS ecosystem is terrible. But wish, I really wish the JS community would pick on the seriousness of other communities and the python one would take more risks and innovations like the JS one.
- vosper 9y ago
  Oh, yeah, it's a mess right now. Debugging especially sucks. I'm hoping that given 5 more years of work on server-side JS we'll get to something that's not miserable, and that transpiling will be a thing of the past

Mizza 9y ago

I actually took a stab at this for a now out-of-favor JS framework, Knockout.js. You can see the project here: https://github.com/Miserlou/django-knockout-modeler https://github.com/Miserlou/django-knockout-modeler It allows you to take a single Django QuerySet and turn it into a SPA with in-page listing, sorting, filtering with a single Django template tag: {{ my_query_set|knockout }} I used in production in a few projects and was very happy. If I were to do this again, I'd re-do it for Vue.js and make the data-syncing bi-directional. But I hope we see more stuff like this.

sametmax 9y ago
Cool. Does that parse JS in Python or generate JS from python ?
- Mizza 9y ago
  Generates JavaScript from Django QuerySets in a single template tag.

no_wizard 9y ago

Why not just something like this? https://transcrypt.org/ https://transcrypt.org/ It's Python to JS in a way that makes sense to me at least. JavaScript and Python have a lot of similarities in the languages imo especially around classes and functions

sametmax 9y ago
Because it's a joke. It's just not Python. Not half of the Python libs work on those things. You don't have serious introspection, most of the stdlib is missing, the stack trace doesn't work as expected, you can forget about async / await and yield from, etc. To run Python in the browser correctly, you need the entire 3Mo Python VM. Transpiling is not enough because Python semantics are complicated as it is very, very rich. Comparatively, js is incredibly basic.

captainmuon 9y ago

Or, the other way around: Write a react clone in Python (complete with "pyx" files), and then use one of the python to js transpilers to compile to js on the frontend. On the backend, you'd use "react" just as another simple template language, whereas on the frontend, you'd also have the reconcilation algorithm.

sametmax 9y ago
You will never get a perfect Python on JS, only a mockery of it. It would be more confusing than anything. Beside, transpilers add tons of complexity, and this complexity increase more when the language is very different from JS.
- mixmastamyk 9y ago
  Aren't ES6+ more like Python (or Coffeescript) now than ever? But yes, complexity.
  - sametmax 9y ago
    More yes, they have catched up on syntax. But they are far, far away in term of features. Even if we completly discard the huge and fantastic python stdlib (but really, no hashing or uuid in web language ?), Python has still: - operator overriding - look up interception API - metaclasses - embdedded design patterns: iterator, singleton, context manager, etc. - multiple inheritance - standardised imports, with hooks - controlled gc - dict comprehension - generator expressions - type hints - string formatting language and operations - much more comfortable lists - rich built ins (all, any, enumerate, zip...) - no weird implicit type casting and comparison rules - stack traces and very explicit error messages - support of a lot of charsets out of the box - multiple notations for text and numbers - types for bytes - support for imaginary numbers And so much more. Because Python is such an easy language to use, it's easy to think it's just a simple scripting language. It's not. It is very, very powerful. But it has such a smooth learning curve and you can be productive in it so quickly a lot of people never need to see it. You can compare Ruby to Python. Or Go. But JS ? It's not even on the same planet. The only reason this abomination has this success is because it has an accidental monopoly on the most awesome and popular platform of the human race: the web.