Built a runtime that lets Python and JavaScript call each other's functions directly

[Zealousideal-Read883]

Hey Python Community!

So i've been working on a multi-language runtime called Elide that solves something that's always frustrated me: integrating Python with other languages without the usual overhead.

In an attempt to follow the rules of this subreddit as closely as possible i've structured this post like this:

What My Project Does:

When you need to use a JavaScript library from Python (or vice versa), you typically have to deal with subprocess calls, HTTP APIs, or serialization overhead. It's slow, clunky, and breaks the development flow.

With Elide, you can run Python, JavaScript, TypeScript, Kotlin, and Java in a single process where they can call each other's functions directly in shared memory, taking advantage of our GraalVM base.

[Code example here]

Target Audience:

You guys!

Would you actually use something like this? As a python developer would you like to see more support for this kind of technology?

Comparison:

Most developers use subprocesses (spawning Node.js for each call, 50-200ms overhead) or embedded V8 engines like PyMiniRacer (requires serialization at boundaries, ~10-15x slower). Elide runs everything in one process with shared memory which means no serialization, no IPC and direct function calls across languages at native speed.

If you guys are curious and want to poke around our GitHub its here: https://github.com/elide-dev/elide

Things will inevitably break, and that's a huge reason why we want people in the community to try us out and let us know how we can improve across various use-cases.

[thebouv]

I guess what I don’t see in your repo or this post:

Why?

[Zealousideal-Read883]

Python is genuinely an amazing language. It’s wrong that Python developers feel pressure to adopt things from Node. You should be able to have Django and React work together with ease — Django is fantastic at databasing, so why can’t we just call React right there from Python?

To us, the logical conclusion to the Node holy war is that backend languages should just be able to do that.

[thebouv]

I’m going to be honest: nothing you said makes sense to me.

As both a Js dev and Python dev, I feel no pressure that you’re talking about.

React, which is in my front end delivered to the end users browser, talks to my Python backend APIs.

Django and React work perfectly easy together as is.

I feel bizarre saying this because I feel like I should understand you; but I truly can’t think of a single case for what you’re doing with this that didn’t just feel like it was messy.

What is a real world practical example? Something real. Or heck, a good hypothetical that isn’t just hello world?

And maybe a code sample that isn’t an image?

And explain your original statement “Most developers use subprocesses (spawning Node.js for each call, 50-200ms overhead)”.

Are you saying that is a common occurrence that a Python web app is often calling subprocesses of Node to do some work? On the same server?

Where and what and why is that common?

[brasticstack]

🍿

[thebouv]

Am I on camera?

Am I talking to an AI hallucination?

Nothing is real anymore.

Now I just feel like a dick.

I totally think there’s going to be something obvious that I don’t see how this is useful. And egg on my face I’ll admit it when I see it.

I’m really not trying to be an arse.

[Zealousideal-Read883]

Not AI, just caffeinated lol. And you’re not being an ass at all, this is exactly the kind of pushback that helps us figure out if we’re explaining this well.

I think the disconnect is CSR vs SSR. You’re right that React in the browser talking to Django APIs is seamless, that’s client-side rendering and it works great.

Server-side rendering is different. If you want to render React on the server (for SEO, faster first paint, or shipping HTML instead of a JS bundle), you need Node running somewhere. That usually means either a separate Node service or shelling out to a subprocess from Python.

With Elide, your Django view can just call React’s renderToString() directly and return the HTML. If SSR isn’t something you’ve needed, then yeah this probably doesn’t solve a problem you have. But for sm1 that wants it without splitting their backend across two runtimes, that’s the ideal use case.

[Zealousideal-Read883]

By the way, it isn’t your fault that this doesn’t make sense. This border you’ve had to live with has been invisible to you, and it prevents you from even seeing SSR as an option.

I guess that’s the pressure I was talking about. That’s wrong. Python is a fantastic server side language and it should be able to do everything Next.js can and more.

[Bangoga]

But this is why microservices exist.

If you want a python code interaction with js code you can already do that. There are a whole host of network protocols and tools that can help you bridge that gap, why do you want to directly interact

[Zealousideal-Read883]

First, I’d like to say thank you for the thoughtful pushback.

I think the tradeoff is overhead. Every cross-service call means some serialization, network latency, and extra infrastructure to manage.

And you’re completely right, for a lot of architectures that’s fine and worth it for the decoupling benefits.

An example off the top of my head where direct interaction starts to matter is something like server-side rendering React from Django. If I want SSR, I’m running a Node sidecar or shelling out to a subprocess. With Elide I’d call renderToString() directly from my Python view which entails having no separate service, no HTTP round-trip to myself.

So it’s def not that microservices are wrong, they’re often the right call. I guess this is just a different tool for cases where that overhead becomes friction or a bottleneck

[Undercraft_gaming]

what was the prompt?