Hacker News Reader

Comment by osullivj | Hacker News Reader

Interesting. I've been looking for alternatives to React or Angular for some time. I've enjoyed playing with Elm recently. My preferred back end is Python Tornado RethinkDB, so browser GUIs in Python is appealing. I looked at https://github.com/skulpt and it looks like the compile to JS step happens on the client side, unlike Elm. What's performance like?

View on HN

Strictly speaking, that compilation happens in JS, not necessarily client-side ;)

(Right now, it does run in the browser, but we'll be moving it to the back-end soon to improve performance. For now it's good enough.)

Can you elaborate on this?

From the Skulpt website: "Skulpt is an entirely in-browser implementation of Python."

It sounds like you implemented python in JS, so there is no compilation to JS. The application code is always python and is evaluated on the client, no?

If you move it to the back end, would that not be something like Trascrypt?

Check out my talk on the Skulpt compiler from PyCon US this summer: https://anvil.works/blog/pycon-talk

Skulpt has a separate compiler stage that compiles Python to JS, and a runtime library. There's no need to eval() that code in the same JS VM that compiled it, so it's totally feasible to ship the JS to the client and run it there.

As far as I can tell, the footprint is around 1MB for the combined skulpt-min.js and sculpt-stdlib.js (not sure why the latter apparently isn't minified). That's pretty huge and makes for a large barrier against using Anvil for a public-facing app. Moving the compilation to the back-end would eliminate the footprint problem -- or would you still have the stdlib running in the client? Any further comments on footprint issues? As it is, we're talking about about two orders of magnitude bigger footprint than some javascript options.

Also, can you give any estimate at al as to when you'll have client-side compilation working?

Reply on news.ycombinator.com