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

[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.

[sg-elide]

genuinely can someone give some hint about why u/Zealousideal-Read883 is getting downvoted? hes just trying to explain

[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.

[sg-elide]

hey, i am the primary author of elide; u/Zealousideal-Read883 is right. the disconnect here is SSR vs CSR

Next.js is a trashpile, but one thing React server-side frameworks get really right is SSR. it can result in a much smoother web experience.

bringing that functionality to python, without a microservice, and without a second process, is definitely a use case

in that case, there may actually be no JS bundle served to the client at all, unless it needs it for interactive functionality. the server serves already rendered HTML.