They are all are cool projects. They diligently solve 73.56% of the problem of Python to Javascript translation, and the other 26.44% remains a very hard task. This is not unlike many other problems in programming (well, even in real life). So it is not for the lack of knowledge, experience or hard work, it is just a very hard problem.
I tried to use pyjamas and it was just almost impossible... It seems to be strictly for GWT (widgets, rpc) style sites. No easy way to build some small python written library or integrate with other pure JS libraries from what I could tell.
How would one go about writing an HTTP call in Python and converting to appropriate XMLHttpRequest in JavaScript? Is this project capable of something like that, and using the native JavaScript ability, rather than a predefined jQuery variable?
Trying to understand what this would be used for besides basic object mapping, iterating, etc.
XMLHttpRequest is a facility provided by the browser - when you are making a request, you are just accessing objects and functions provided by the host environment.
In Python, the "host environment" is generally CPython with the standard library. In JavaScript, the "host environment" is typically the browser with the DOM.
This is a project that translates code in Python syntax to JavaScript, so you would use XMLHttpRequest just as you would in JavaScript, but with Python syntax.
So if I get the names perfect, I can use the js API's provided by the browser and only need to compile to test my code? Next. No...not next. Please no more next. Make it stop. Just stop. Please. There are so many projects that can use your assistance. I can give you ten open issues off the top of my head that I would like fixed. So many useful, interesting, thought-provoking programs are just dying to be written.
If they haven't already, they could hide the DOM and nasty host-provided objects behind something more Pythonic. As long as it transpiles to XMLHttpRequests, it doesn't matter what the Python looks like.
And I'll build a mock environment so that I can run my python script as if there is a real DOM to manipulate, and then I'll write a test rendering system to actually display the page as if everything is running in Python. Eventually I'll just implement every single aspect of a web browser so that I can be sure that after I stop transpilfering Python, I can indeed just start putting <script type="text/python"> everywhere and convince everyone to use it, so my giant mock environment will become the latest, greatest browser, and Google will spend millions adding a tune-able JIT to cpython, leading someone to decide what a great idea it would be to use this JIT as the runtime for server-side Python, and Pode.py will take over the web, and "isomorphic" Python frameworks will sprout faster than TCP connections on a DDOS'd server.
And after that, we can start writing and re-writing everything to "transpile" to PHP and use hip-hop to make it C++. I can't spend any more attention on random me-to JS without feeling like I'm waiting for my vestigial appendix to fall out.
I'd prefer a real solution to the JavaScript problem: put a real language in a web browser. JavaScript has done very well for what it is, but even Brendan Eich openly admits it was a rushed project and was never intended to be the One True Client-Side Programming Stack.
We have lots of people writing very complex programs meant to alleviate some of the problems with JavaScript, when that effort could reasonably go into making Python a first-class web language by including a VM in browser distributions and writing bindings that allow DOM manipulation.
It's called asm.js. Make your real language compile to that. asm.js not Javascript. It's an assembly languange (well, at least an IR) for a simple static virtual machine. It's easy to write intepreters and JITs for that virtual machine, and modern browsers are starting to do so. It's not much of a stretch to think of asm.js as a way for browsers to run native code. Asm.js is the clever hack that lets you shoehorn any language you want into the browser and to run it fast.
These kinds of things are cute and fun—but does anyone use these sorts of language x to language y translators in practice? Not talking about specialized language interpretation. With JavaScript, the most common operation is to manipulate and capture from the DOM—something that this tool is not capable of readily doing, not, at least, without getting one's hands dirty with JS.
The challenge is to do that is that there is no "Pythonic" way of manipulating the DOM. When we were building a similar translator we included a way to interact with JQuery through a js object (i.e. js.document.addEventListener) -- but it still required the user to think about and understand javascript.
I wonder how multiple inheritance is handled by this webdev holy grail. I know CoffeeScript had some issues handling its certain attributes* within its constructors, so it'll be interesting to see how pythonium does the same and beyond.
Not quite. Key-value properties use the colon syntax. Regular assignment is for local variables. Your "c" is a local variable within the class body of "b", and should absolutely not be visible from the constructor of "a".
Here's the corrected version:
class a
constructor: ->
console.log @c
class b extends a
c: 3
new b() # logs 3
I hope your object model doesn't require understanding the MRO to trace the code, unless you're doing some serious library plumbing that I can't even really fathom using in front-end code right now. But I'm fairly certain you could mimic those semantics with wrappers around prototypal inheritance somehow.
If you like Python you should really look at CoffeeScript and even better ToffeeScript. You can write code that looks a lot like Python. Actually the spirit of Python is to be close to pseudo code, and if you want to you can write CoffeeScript/ToffeeScript that beats Python in that respect.
As an experienced backend developer and newbie at JS, I tried Coffeescript. JavaScript itself has lots of WTF stuff, but CoffeeScript makes it a nightmare with lots of implicit rules and assumptions about things you know. I assume it makes sense for an experienced JS developer, but as a newbie, it didn't help at all.
I really like CoffeeScript, but I don't think it's really closer to pseudocode than Python. Python, for example, eschews anonymous functions in favor of forcing you to name things. It also tries to avoid terse symbols for language features in favor of verbosity. To me, CoffeeScript syntax is somewhere between Python and Ruby.
ToffeeScript makes callbacks go away. Its very nice. Far as I can tell not popular yet but makes code much more readable and writable so I take advantage of it.
I do find the number of options hard to choose from. The hacker approach seems to be to learn a bit of everything (and enjoy it) but for people like me where programming is a necessary tool to get shit done, trying to decide between these 10 options and pick one that will turn out to be the best/still be useful in 3 years is hard.
Did i say that? I just prefer pure javascript the way its meant to be for reasons of consistence with coworkers, documentation and reading other peoples code.
That and i simply dont find JS to be all that bad.
I don't think that is good idea. Javascript has it's own idioms and also gotchas. You are not going to learn them by looking at translated python code. Read JavaScript The Good Parts instead.
Pyjamas: http://pyjs.org/
Skulpt: http://www.skulpt.org/
and another one I forgot.
They are all are cool projects. They diligently solve 73.56% of the problem of Python to Javascript translation, and the other 26.44% remains a very hard task. This is not unlike many other problems in programming (well, even in real life). So it is not for the lack of knowledge, experience or hard work, it is just a very hard problem.