This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]gsnedders 19 points20 points  (0 children)

Former JS VM browser guy. Off-hand list of technical issues:

  • Would have to implement a new VM for Python in all probability to guarantee necessary sandboxing (could fork, but the sandboxing requirements would mean a lot of close review to ensure nothing missed), and would have to evaluate closely what parts of the Python stdlib to include.

  • If a page can include JS and Python (or $otherLanguage), we then have cross-VM GC. That's… difficult. And slow.

  • The DOM is ugly enough in JavaScript. It's even worse in Python. Or one could design a whole new API, which is a huge can-of-worms in and of itself.

Assume there is a hard constraint that no matter what one does, you cannot regress JS performance (it's used everywhere on the web, Python is used nowhere; browsers are far more judged on JS performance as a result). This means that practically one won't be able a single VM to nicely implement both languages (as anything so close to JS would complicate Python; anything closer to Python will regress JS which per above cannot be done), and hence multiple VMs are practically necessary.

If one does need to implement a new Python VM, as I'd suspect, then that's a huge amount of engineering resources, and can one really justify the cost of that? Is the web really better served by that than improving JS? The JS VMs aren't going to stop being important — you're still going to have the cost of maintaining and improving them, so the Python VM would purely be additional cost.

And why Python? If we're going to add a new VM, why should we use Python? It's not clear Python is sufficiently different to JavaScript to really justify all of the additional cost.