Jaspy – A Python VM written in JavaScript | Hacker News Reader

Jaspy – A Python VM written in JavaScript

github.com

126 pointsmmariani49 comments

People often look at things like this like 'why would you...' But it is an interesting experiment that might make web programming more accessible. I think of my physicist cousin who uses python for data analysis. An option like this might lower the barrier to sharing data on the web - less JavaScript ecosystem knowledge required. JavaScript frontendy land moves so fast it can be overwhelming to outsiders, even if JavaScript itself is "easy."

You need exactly zero knowledge of Javascript to share data on the web. Plain server generated HTML + some CSS framework is more than enough for most cases. Even if you want some more interactive stuff you don't need to know the "Javascript ecosystem". It's still possible to link a couple pf JS files in script tags, you know. It's even possible to link XSLT 1.0 stylesheet for some non-interactive clientside processing.

If you want interactive stuff, there are plenty of Python plotting libraries that can produce interactive visualizations, e.g. Bokeh, MPLD3, or Plotly.

And IPython notebooks allow you to not only share the results but an interactive copy of the process as well.

This was my first reaction, but one of the examples allows dom manipulation. https://github.com/koehlma/jaspy/blob/master/example/hello.p...

As with everything, there are trade offs and in this case, I don't think they are worth it.

What are the most common use cases for JS, that might be a barrier to an unfamiliar developer, requiring some learning? I believe that making an ajax request and some trivial DOM manipulation covers a lot (say, send ajax request to the server and add some text returned to a dom element). In order to do that, you don't need some fancy framework, plain simple JS will do it. Arguably, it will be even easier to do it in JS than in e.g. Python, because there are tons of examples on the web in case you need to extend the functionality. Occasionally, you will need some visualization (chart or something), but then it's mostly just finding some library and transforming the data into the required format, that's simple enough to do with a language that you are not an expert in.

After all, isn't web development already accessible? I would argue that this is the most accessible of software development, with huge amount of high quality, accessible learning resources and various frameworks that enable to develop complex features rather quickly, if needed.

True, there's always something that can be improved but I don't think that Python-to-JS solves anything.

However, I genuinely believe that a project such as this is a cool side project to explore and improve your software development skills :) so often 'why would you...' can be answered with simply 'because it's fun'.

Web development only moves at fast speeds if you want to adopt the frontier solutions. If you want, you can still use Wordpress or Joomla or whatever, you can still use Bootstrap, you can still use Jquery. These are all optional and have been stable for a decade.

A person without interest in web development, such as a scientist who wishes to publish a blog, should be fine with a pre-baked solution like Wordpress. Even if they're comfortable with Python, there's no reason to replicate what "core" Wordpress does, which is no small undertaking. Also, a person working in a field that just happens to use a sprinkle of programming would have to learn a lot of tangential junk just to replicate what pre-baked solutions do, and they would probably do it poorly.

It would be better if such individuals just paid for an affordable solution or used something like Wordpress.

Things like this will totally make sense once they are done in WebAssembly.

I actually embarked on a similar Python VM called Ninia [1] awhile back, but shelved it as other projects became more important. Ninia supports multiple threads and preempts execution to give the browser breathing space, just like my JVM in JavaScript, DoppioJVM [2].

One of the challenges of Python is its objects are quite complex/ad-hoc, and can be overridden by the user. I mapped out [3] how I wanted to map Python objects to JavaScript objects, but never had the time to implement it fully. (That document covers Python 2.7; I'm sure there are differences for 3.) It looks like this project has a lot of work to do if it wants to have parity with a native Python VM! But that's part of the fun of writing these things.

Best of luck on the VM! If you need a file system to plug into the VM for loading modules/implementing the FS API, do check out my BrowserFS library [4], which is currently in use at the Internet Archive [5] and is also used in Ninia/DoppioJVM. You can also cop things from Ninia, as it is MIT licensed.

Oh yeah, and if you need a Python compiler/parser, you can simply run the PyPy interpreter's parser+compiler [6] in your intepreter once it is reasonably complete. It is written in 100% Python!

[1] https://github.com/plasma-umass/ninia

[2] https://github.com/plasma-umass/doppio

[3] https://github.com/plasma-umass/Ninia/wiki/Mapping-Python-Ob...

[4] https://github.com/jvilk/browserfs

[5] http://ascii.textfiles.com/archives/4924

[6] https://pypy.readthedocs.org/en/latest/interpreter.html

Cool, I will have a look through your code and BrowserFS seems especially useful to me.

I often see this wish expressed (also in here by somebody):

>JS engines in browsers should evolve to more general VMs, for which you can implement/port other languages.

You do understand that when this happens (and is spread enough to use in production), the web framework and tooling fatigue will be 2-3 times worse.

It's not just that everybody and their dog will write their own framework (as now), they'll split even more and do it for 10 languages... And expect the same dilution of effort for libs too...

I'd actually prefer a better JS replacement, that is, a new, single, language that draws from it and gets rid of all the caveats fixed (lack of ints, coercion rules, small std lib, optional types, even better designed for high speed JITing etc), than seeing Python, Clojure, Ruby, Lua, PHP and 200 others re-implemented in web assembly...

I agree with this assertion. Albeit, isn't this what's to come with WebAssembly?

Where is this "dilution" in the java world? I don't see it.

The Java world has 1/10 the programmers Javascript has (which is basically everyone doing web work).

The Java world also historically had a parent company giving strong guidance.

The Java world also has strong standard libs and tended to include everything and the kitchen sink in them (including full blown servers, XML/XSLT parsers) in the SDK (and EE SDK). Heck, it even has a full JS interpreter there.

Even so, there was huge fragmentation of effort for things like web frameworks (Struts, WebWork, Spring, Cocoon, Turbine, Tapestry, and many many more). Actually, if you were doing Java in 2000-2010 it was a running joke how everybody would write their own framework.

And I would argue that all the resources diverted to numerous Java-derivative languages (like Kotlin, Ceylon, Xtend, etc) would be better of in making Java better, or creating a single, community driven, Java successor, if there was a process (and access) for that.

As it is, they are all doomed to remain niche players, and ultimately fail, while languages like C# and Swift march on.

Web needs domain-specific declarative languages that are oriented toward non-programmers. W3C is often painted as a villain of some kind when it comes to HTML5, but it's important to remember that there are different working groups and some of those groups were working on specifications that were sound, but never got browser support.

In any case monopoly is bad. People are writing frameworks and languages that transpile to JS because they are not happy with the default option. In addition to more general VM there also should be a more robust standard library, that any language targeting it will have access to.

As a general trend with reimplementing stuff in JS, I don't quite know whether this is exciting or horrifying...

JavaScript may very well have the doubtful honor of being the language that people have spent most resources to avoid writing in.

It's probably 2nd place. I imagine avoiding writing in C gets the top honor.

Nope, every single programming language and computing interface is an attempt to avoid writing machine code. :)

Maybe, but the step away from assembly has been more about portability than avoiding the language.

Which begs the question: why haven't browsers adopted another scripting language?

You can find answer to this easily enough. Some at Google were pushing Dart, read reaction to that from Mozilla, Apple and Microsoft.

I wish people would take time to actually learn javascript. I used to see it as a shitty toy language up until 2012. It opened me up to a completely different style of programming.

I totally agree about actually learning javascript. While the opinion about the language itself is arguable, it's not 2006 anymore. Plain simple JS can get a lot of stuff done nowadays and there's no point to include the whole jquery to hide a dom element or make an ajax request. In addition, understanding the underlying language opens up a lot of doors, compared to just gluing frameworks and jquery extensions together.

I saw it as a shitty language until I worked with it full time in 2016 after which I forgot all about clunky syntax and focused on the too-small standard library and web standards nuttiness.

Don't forget the confusing ADHD garbage tooling!

I feel like TypeScript could make JS a decent language if Microsoft starts going more ambitious with it - they really need to do a Dart style integration - official package manager, build system, full es5 transpiler, std lib polyfill included.

So far they have been conservative and focused only on typing but they could offer insane value if they started offering a full language expirience like Dart

It's an excellent tool. It does make JS a decent language.

A package manager is not necessary, it can work with npm.

A build system is not necessary, existing build systems support it.

I believe they will eventually do full polyfill. However, the compiler is very high quality and that doesn't happen by accident. They have to make hard design decisions to keep releasing features so regularly (they release features faster than I can keep up with sometimes).

For now, you can target es6 and chain with babel.

It's better than javascript but it's still poor. You still run into wierd this scoping issues, the JS it actually produces is pretty fugly, there's still no standard libraries like decent languages have, every property accessor has to be prefixed with 'this.', etc. etc.

And, ultimately, your code still ends up being a load of garbage boilerplate code like you're writing oldschool Java from the early 2000s.

It's a nasty language written on top of a nastier one, lipstick on a pig.

The extent to which all your points matter really depends, but I find myself able to use types just for some logic, and code in a functional style far removed from oldschool Java with lots of destructuring / structuring. I'm not denying it's a lipstick pig, but the improving-JavaScript situation is what it is, and it does a good job at doing it in an unopinionated way (which is why it's succeeding)

It all matters a lot. There are great languages available today and typescript isn't one of them. Why should we be forced to choose sub par languages?

I don't see it as a long term solution. It's just the next coffeescript. It's part of the problem rather than a solution, the problem being the massive churn in the JS ecosystem as we desperately hunt for a way of writing JS code that isn't awful.

The actual solution is to give us other languages in the browser. We need Python or Ruby or Go or C# or PHP or whatever. We need real choice, not javascript 2.0.

If Firefox wanted to stay relevant today it could stop dogmatically promoting a broken language and that's what they'd be working on right now. They're too rigidly fixated on the past though.

How did PHP end up in that list?

>A package manager is not necessary, it can work with npm.

It can work with NPM - but what about bower, JSPM, whatever else hipster package manager everyone else uses ?

It should specify TS supports NPM by default and it's the official package manager - you can use others at your own risk. Ditto for build system.

Saying you can target ES6 with babel is completely missing my point - Dart developer experience is much much better than TS simply because it does all of these things - out of the box and without any decisions/interventions/ridiculously complicated build setups and dependency chains

> It opened me up to a completely different style of programming.

What style would that be? JS is a dynamic language, but as dynamic languages go it isn't the first and it is certainly not the best. What is has going for it is near monopoly in browser space and a ton of optimization.

I suspect functional programming. I don't like Javascript, but getting away from the typical OO garbage is a plus.

Of course I'd prefer Haskell, but if one can earn money with JS...

JS engines in browsers should evolve to more general VMs, for which you can implement/port other languages. Hopefully WebAssembly is a start of that. That is the proper way, not writing it in JS with caveats such as

> Speed is explicitly not a main goal of this project.

I totally agree with that. Actually that's the reason why speed is not a main goal and it is more about the style of programming and exploring new ways. The long term goal is to use new upcoming technologies to implement it in a faster way although.

I think the most salient application for client-side Python (or Ruby) are for companies already entrenched in server side frameworks like Django and Ruby on Rails. For all Django provides, developing in it still feels constrained to a server heavy mid-2000's web development paradigm. While frameworks like React and Ember are pushing the envelope on web applications by allowing you to render HTML apps on the server and on the client, to do something similar in Python means duplicating rendering logic between a server-side template language and a front-end framework like Angular, React, or Backbone/Marionette.

Some technologies tackle a part of this problem, like pybars, which allows using Handlebars templates in both a python and javascript process. But it would remove a mountain of mental overhead and code duplication, if feasible, to write an entire web application in Python.

I prefer the web to still be the place where people share HTML documents and do simple data input/retrieval. Rather than shoving a square peg in a round hole. I'm rather happy with the state of Django as a result. I suspect Django Channels will provide all the stateful connectivity most people will need without tossing the baby out with the bathwater.

And it's not all roses on the other side either, I've looked into the fullstack solutions that are all JS and promise the world and best future possible but ended up being lackluster in things like SEO.

Oh wow, thanks for the great feedback to all of you!

This will be interesting for codeschool.com and elearning projects, now they can have everything without requiring the backend at all to evaluate the commands that the user sends.

I'd be interested to see how threading support was implemented, seems difficult to do in a browser environment.

It's easy: you could just run n instructions of thread one, then n instructions of thread two, and so on in a loop. To not freeze up the browser, you could periodically yield to it and set a timeout to start running the next thread again.

I guess so. I think I was thinking about concurrently running multiple threads.

That is already concurrent. Do you mean in parallel? Yeah not easy to do that, you'd have to set up web workers and I think sort of manually recreate the shared state with your own coherence protocol!

are we limited to certain libraries for now? I am guessing we can't do pip install, but maybe this version of Python can interact with other javascrupt (e.g. JQuery)?

Most of the builtin types and functions are not fully implemented yet, but if they are, you may use any library that is implemented in pure Python.

There is already support for threading and I am also planing to implement a filesystem as well as multiprocessing using WebWorkers. Even sockets will be possible with node.js.

Then yes, you can do "pip install".

There is also a module that allows you to use native JS libraries like JQuery.

Going through the code and finding new unknown stuffs already!

But why?

Reply on news.ycombinator.com