I'm a little confused here, React might have a SSR component, but the thing that makes it React is that it runs client-side. So... how are you putting Python in the browser?
React, but in Python
81–90 of 179 posts
Re: React, but in Python
#82I'm a little confused here, React might have a SSR component, but the thing that makes it React is that it runs client-side. So... how are you putting Python in the browser?
React doesn’t have to run client side. The DOM renderer is just one possible output, albeit the most popular. The output doesn’t even have to be human consumable.
Re: React, but in Python
#83Controversial, but I think that rather than trying to make Web stuff (e.g. React) work in Python, a more fruitful direction would be to make ML stuff (e.g. PyTorch, OpenCV) work in Typescript. Javascript/Typescript is way faster than Python, is ubiquitous and can run pretty much everywhere, has many engine implementations, has an incredibly wide ecosystem, has a type system (Typescript) that blows any Python type sys…
TS is a joke
tsc is the only compiler I've had to step through with a debugger multiple times.
No DS/ML researcher wants to deal with VM args just to use more than 1GB of memory. That alone would cause so much frustration.
Not to mention unpredictable generational GC.
Or the crazy crap people do with the type system (what you call better other people call a mess).
At least Python has some semblance of runtime type safety.
Re: React, but in Python
#84Controversial, but I think that rather than trying to make Web stuff (e.g. React) work in Python, a more fruitful direction would be to make ML stuff (e.g. PyTorch, OpenCV) work in Typescript. Javascript/Typescript is way faster than Python, is ubiquitous and can run pretty much everywhere, has many engine implementations, has an incredibly wide ecosystem, has a type system (Typescript) that blows any Python type sys…
The speed of the output of the compiler of the glue language almost does not matter. Whether it is Python or TypeScript, it will not matter. Typically people will not use pip directly in serious projects, except for quick and dirty package installs to prototype something. In any serious project I would expect people to use any of the package managers, that support creating a lock file. But then NPM for example is not better than poetry. Or at least I have not had a single case, where I thought: "Ah, if only it was behaving like NPM." Rather the opposite.
But anyway, the whole language specific package manager business is starting to annoy me. I would like to be able to simply use something like GNU Guix and sometimes I am able to do just that.
Re: React, but in Python
#85Could be fun to see this replacing jinja in old frameworks like django. Although inheritance had a better feel with templates..
ReactPy dev here. We're actually contributing to a WIP PEP that would add JS-like tagged template literals to Python. We think this will open up a whole new world of templating and DSL possibilities: https://github.com/jimbaker/tagstr
Is reactpy a fork of IDOM or a rebranding of it?
Re: React, but in Python
#86Long ago, before jsx and react, before hack, Facebook had a fork of php called xhp, which allowed xml data within php. I'm not suggesting anybody should maintain a fork of python with xml support but a pre-processor could parse xython and generate standard python with trees of html.xx() calls. https://en.wikipedia.org/wiki/XHP
Check this project:
Re: React, but in Python
#87Earlier quoted context omitted.
Yep. And nowadays you can deploy apps really close to users so latency is really low. If you have <100ms you don't really notice the latency.
A no-op API call to FastAPI takes more than that. Even when running on localhost. And FastAPI is one of the better contestants.
On my mobile i5 10-gen it's 23 ms.
Re: React, but in Python
#88Controversial, but I think that rather than trying to make Web stuff (e.g. React) work in Python, a more fruitful direction would be to make ML stuff (e.g. PyTorch, OpenCV) work in Typescript. Javascript/Typescript is way faster than Python, is ubiquitous and can run pretty much everywhere, has many engine implementations, has an incredibly wide ecosystem, has a type system (Typescript) that blows any Python type sys…
TS is a joke tsc is the only compiler I've had to step through with a debugger multiple times. No DS/ML researcher wants to deal with VM args just to use more than 1GB of memory. That alone would cause so much frustration. Not to mention unpredictable generational GC. Or the crazy crap people do with the type system (what you call better other people call a mess). At least Python has some semblance of runtime type sa…
> TS is a joke
I'll discuss facts
> tsc is the only compiler I've had to step through with a debugger multiple times.
99.9% of Typescript developers never ever had to do that. Sounds like a "you" problem
> No DS/ML researcher wants to deal with VM args just to use more than 1GB of memory. That alone would cause so much frustration.
You're talking about NodeJS, which is just one of the many JS engines. It's also 200% easier to start NodeJS with a flag to increase the (sane) default memory limit, as compared to the insanity of setting up a Python environment.
> Not to mention unpredictable generational GC.
Is Python GC better? Really? The good thing with Python is that the whole language is so slow that GC is just a drop in the bucket. On the other hand, Millions (Billions?) have been spent optimizing JS engines and it shows. Also: GIL.
> Or the crazy crap people do with the type system (what you call better other people call a mess).
I don't know what you're talking about, TypeScript go Brrr and I get magnificent Intellisense and subtle type checking, while MyPy and friends keeps crapping their pants
> At least Python has some semblance of runtime type safety.
No. And critically it has no semblance of comp time type safety either.
Re: React, but in Python
#89Controversial, but I think that rather than trying to make Web stuff (e.g. React) work in Python, a more fruitful direction would be to make ML stuff (e.g. PyTorch, OpenCV) work in Typescript. Javascript/Typescript is way faster than Python, is ubiquitous and can run pretty much everywhere, has many engine implementations, has an incredibly wide ecosystem, has a type system (Typescript) that blows any Python type sys…
The speed of the output of the compiler of the glue language almost does not matter. Whether it is Python or TypeScript, it will not matter. Typically people will not use pip directly in serious projects, except for quick and dirty package installs to prototype something. In any serious project I would expect people to use any of the package managers, that support creating a lock file. But then NPM for example is not…
> But then NPM for example is not better than poetry.
Poetry is good exactly because it copied the concepts from NPM / Yarn. It's almost a port of NPM to the Python ecosystem, 8 years later.
Re: React, but in Python
#90Controversial, but I think that rather than trying to make Web stuff (e.g. React) work in Python, a more fruitful direction would be to make ML stuff (e.g. PyTorch, OpenCV) work in Typescript. Javascript/Typescript is way faster than Python, is ubiquitous and can run pretty much everywhere, has many engine implementations, has an incredibly wide ecosystem, has a type system (Typescript) that blows any Python type sys…
The speed of the output of the compiler of the glue language almost does not matter. Whether it is Python or TypeScript, it will not matter. Typically people will not use pip directly in serious projects, except for quick and dirty package installs to prototype something. In any serious project I would expect people to use any of the package managers, that support creating a lock file. But then NPM for example is not…
> The speed of the output of the compiler of the glue language almost does not matter. Whether it is Python or TypeScript, it will not matter.
Depends on the use case. For ML, sure, it doesn't. For web servers, it depends. For stuff like this React-like tool, it matters.