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 system out of the water, runs in browsers, has non-stupid package management systems (PIP is a joke), is easy to get started, etc.
<The world if data scientists/ML/CV people used Typescript.JPEG>
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.
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.
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.
TypeScript requires you to compile, the whole point of Python for ML and data science is you're running in an interpreted environment where you delegate as much code out as you can for both data processing and algorithms to invisible C++.
The interpreted part is key as ML is about experimentation. It's not like there's any overlap between current web developers and ML people anyway to need an unified bridge.
I guess you have completely missed people running language models on WebGPU then.
I think webasm + webgpu will be a target for a lot of new ml libraries.
I think the key difference is that it’s hard to setup good governance for JavaScript. You’re going to need a fascist linter that is actually enforced, and you’re going to need a tight grip on your developers to force them to really, really, think about their dependencies, but once you have that it’s quite honestly the best language I can think off. The ability to use isolated functions instead of putting them into “classes” is just such a great way to do a solid mix of functional OOP programming, which is obviously heresy to hardliners of either, but it’s just so magical when you do it right.
I think Python is getting there, it was such a great language for such a long time that it sort of forgot to improve. But now it has copied the NPM/Yarn package handler, and hopefully it’ll soon be possible to actually do a Typescript sort of Python, so maybe it’ll be able to win me back. Or to be fair, I think it’s a great language until you have to work together. It’s just so hard to get the codebase governance up with Python that it only really becomes worth it in ML shops where your developers want to work with Python. I’m not sure how Instagram managed, and there are certainly the projects that fit into the Django box which absolutely should be put into the Django box, but the only general purpose language to me personally is currently JavaScript.
Part of that is because we need initiatives like this one. We need “React” in Python or Rust or whatever if we want small dev teams in non-tech enterprise to be able to work with other languages than Typescript. Yes I know we have some C++, and a little Rust, but unlike the rest of our many different projects I’m the only one who can maintain them. Which is actually the primary reason we work with JavaScript, because if we don’t, then the React developer won’t ever be able to go on a vacation. :p It helps that JavaScript has become such a great language, and it likely has exactly because the React dev wants to go on vacation in a trillion IT departments. But I’m all for Python having this React Python so ML heavy shops don’t need that React dev.
But to say JavaScript is atrocious is sort of silly to me and I’m not sure you would have that opinion if you gave it a real chance.
Is that fixed by Typescript, or does it inherit all those kinds of weird JavaScript behavior?
What other languages, besides Python, does this builtin list comparison work in? What's the result when the comparison is `[1, 2] < ["10", "2"]`?
But of course yes, The ML stuff should be Wasm and WebGPU. The point is you can access it from Typescript. Just like most data science libraries are not Python, they just have Python bindings.
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.
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.
Excuse me what
React builds interactive UIs (web, mobile). After each interaction, the virtual DOM is programmatically recreated and reconciled to the actual DOM.
But reactpy is running on a backend sever??? Is each interaction resulting in a server call?
Can someone explain what is going on?
EDIT: Ah, okay, thanks. Every re-render is a network call. If people complained about web UI performance before..... :)
For those types of apps, this 'backend-driven reactive apps' paradigm could be more efficient, because programmers don't have the option to build stuff like an inefficient network protocol or bloated frontend stack.
You'd have to conscious of this.
It's defiantly not a "write a usual React app, but in Python"...every dropdown, menu, modal, etc interaction interaction is a backend call.
I understand the benefits, then again if interacting with these elements requires calling the backend then the cost is quite high.
Making a 'server call' on each interaction is also what web apps used to do before SPAs were a thing. And in many cases it's what SPAs do as well.
Of course, it depends what counts as an 'interaction', but that's been the case since JavaScript existed.
One of the reasons behind the popularity around webapps was that they would no longer need to make 'a server call' on each interaction.
> And in many cases it's what SPAs do as well.
I feel you're grossly misrepresenting what SPAs do. SPAs do calls to send and receive data, not to fetch server-side rendered content.
Then there's the fact that your backend framework has to define the subset of all frontend features it supports in Python. The moment you hit on a usecase that isn't supported in Python, you have to learn JS anyway and write code in the frontend. Except it's the worst kind of frontend code: hacks around broken or missing frontend features that depend on implementation details specific to the framework that are subject to change at any time.
I feel that these kinds of frameworks are better suited towards researchers or backend devs who really do not want to have to set up an NPM project just to have a simple (and I really mean simple) frontend UI to interact with. But don't dare try to write the next gigantic ML app on top of it or you'll have to deal with the performance and maintenance issues that follow.
Blazor was the pioneer here.
Similarly to this library, it gives you a `@component` decorator that allows you to create components out of functions. But it also: 1. Includes all existing React hooks (use_state, use_memo, etc) -- so you don't have to learn new patterns. I believe this results in a bit less magic (and so easier debugging) than just using raw variables. 2. Works with ipywidgets, so many existing data apps can be ported over very easily -- Jupyter users celebrate.
I'm not associated with the project, but I know the maintainers (creators of Volia [2]) and they are honestly excellent. I haven't use the project in production, but the getting starting guide is pretty compelling.
[1] https://github.com/widgetti/reacton [2] https://github.com/voila-dashboards/voila
The follow up of that is Solara: "NextJS, but in Python" :)
Now you (and the OP) have me pondering about building UIs in notebooks…
Not sure doing something in React is better than just learning the standard tools, but it's a good option to know exists.
A brief summary of what I did:
* Python-powered apps, like this
* React was used to handle lifecycle. Basically, I avoided writing any kind of lifecycle management because I just wanted to do exactly what React would do. This was achieved via events firing when React lifecycle events fired. If props changed on the server, I'd send the new props to React to see if it would trigger a lifecycle event. If a lifecycle event was triggered, I'd replicate it onto the server which could again render new props.
* The result was a nice seamless support for both native React components and the newfangled Python components (which could be made up of either more React components or Python components).
* The purpose of all of this was to cater to ML engineers who didn't particularly like JavaScript and just wanted to build their analyses with Python and share them with coworkers. We had an automatic deployment system for them to share these.
* Only caveats were around session management. Much of the state was handled on the server via a websocket, so if your connection dropped, you lost all ability to update the layout. Load balancing was going to be tricky, since the sessions would have to be shared somehow. I was thinking about serializing and deserializing using Pickle but never really got around to deployment.
See also: [Dash](https://github.com/plotly/dash)
From the README: Write your Python interfaces in a declarative manner with plain render functions, component classes or even single-file components using Vue-like syntax, but with Python!
- Reactivity (made possible by leveraging observ)
- Function components
- Class components with local state and life-cycle methods/hooks
- Single-file components with Vue-like syntax (.cgx files)
- Custom renderers
PysideRenderer: for rendering PySide6 applications PygfxRenderer: for rendering 3D graphic scenes with Pygfx
It is possible to create a custom Renderer using the Renderer interface, to render to other UI frameworks, for instance wxPython, or even the browser DOM.
Flavour is a fast, batteries-included, type-safe framework for making modern SPA web apps in Java (and other JVM languages).
* Great Lighthouse scores? Check!
* Real SPAs without sluggish network round trips? Check!
* Modern path-based routing? Check!
* Components (built-in and user-defined)? Check!
* Effortless service calls? Check!
* Refactor frontend and backend simultaneously using your current IDE? Check!
If this sounds interesting, check out these other resources:
* Article in Java Magazine: https://blogs.oracle.com/javamagazine/post/java-in-the-brows...
* 100% Flavour 5-letter word game: https://frequal.com/wordii
* Flavour podcast (created with Castini, a Flavour app): https://castini.frequal.com/cast/show/Flavourcast/f7e171e8-2...
This site can’t be reachedCheck if there is a typo in frequal.com. DNS_PROBE_FINISHED_NXDOMAIN
pyjs, streamlit, brython, pyodide, pywebio, gleam, dash, bokeh, gradio, pglet, idom, anvil, pynecone, onu
The last two are YC-funded.
Edit: add https://flet.dev which has superseded pglet
I do not have the answer to your question, parent, but I feel the need to evangelize vanilla JS/ECMA.
You can do everything you could do with jquery and react with very simple constructs now. Web components are slightly awkward, but damn! Possible, and easier than it ever was before js components.
Introducing any additional technologies or node is no longer necessary. The frontend has evolved.
Now. You still have to learn ECMA, but that’s what browsers definitively run as of my writing.
I can pray to mdn for wasm to be a go-to every day tech, but that day is not today.
(Not complete. Pull requests welcome.)
(this is a joke, it was my immediate thought when seeing this. More seriously, probably not for me but looks interesting technically, I'll need to check out how it works)
There was also ComponentKit, which was used heavily in fbobjc: https://github.com/facebook/componentkit
I've been working on a similar thing in Ruby. https://github.com/mayu-live/framework
I find it so ironic that js, a language that runs in the browser, is now used on a server, to rebuild code that is sent back to browser.
https://github.com/pyxl4/pyxl4
example:
# coding: pyxl
from some_module import x_user_badge
user = User.get(some_user_id)
content = <div>Any arbitrary content...</div>
print <user_badge user="{user}">{content}</user_badge>
A huge draw for React is that it _extends_ the JavaScript Syntax. If you still had to compose your React components with a bunch of nested `React.createElement('Component')` calls (instead of `<Component />`) it wouldn't be nearly as useful.
On first read, I thought by "generating html from function calls" the author was referring the react-style way of building a UI by writing a reactive function that returns HTML.
In this case, I think it's also clear that most things you'd call an "application" abhor this behavior, which is why heavy clients are so popular, and small shops without frontend engineering talent are making a big push away from heavy clients which raises all the hubbub about HTMX etc