PyJS: write your JavaScript-powered web applications entirely in Python
pyjs.org
pyjs.org
What I would really find interesting is a CoffeeScript-like language that can compile to both Python and JS (with snake_case for Python and camelCase for JS). Couple it with a JS client-side library that mimics Django's Model and Field APIs, while keeping the best parts from Ember.js (Handlebars/Emblem templates, Components with Actions for template events, Router, and Routes), plus glue code to make the whole thing seamless, real-time, and with an isomorphic feel.
If nobody does it, I plan to study compilers with the express goal of attempting it myself.
Edit: To clarify, I already know a decent amount of Python and JS/CoffeeScript. The problem is not in learning multiple languages, but in the amount of duplicated logic (especially in the model layer) that could be eliminated via shared code when you write in a single language.
> I don't mean to talk a bunch of trash about the idea, because it is a cool one and undoubtedly would be a great learning project. However, in trying to compile down to both Python and JS, you'll end up with a lowest common denominator language. Aside from libraries, it isn't obvious what compiling down to Python gives you; just use Coffeescript or something similar for your entire stack if for some reason ES6 is not an option.
> Truthfully you are just better off biting the bullet and getting good at multiple languages which are the best fit to their domains. The best tool for the job and all. Python is a good language, but not great enough to warrant hanging onto if/where it has been eclipsed.
My motivation isn't a love for Python (although I do confess one), but contempt for javascript.
I do like coffeescript just fine, so my solution is to "just Coffeescript" most of the time.
However - and I know I'm not alone here - I end up having to not only repeat but re-represent crucial pieces of logic in both Python (in a model method) and Coffeescript (in a scope method) in order to have complete coherence over my app.
In 2015, it doesn’t need to be this way.
Opinions like this make me very sad. And not because I love JavaScript: I love all the languages (take a look if you want to see the list: https://klibert.pl/articles/programming_langs.html). It's sad, because we have now more languages than ever before, yet almost no one uses them, because they all "contempt" some of them, "dislike" others and are "not interested" in the rest. "Using the best tool for the job" was never that easy, yet nobody wants to do it, choosing to try and translate completely incompatible semantics and features of one tool on top of another. It's really disappointing.
This presentation sums up my dreams about how development should look like pretty nicely: https://www.youtube.com/watch?v=qluiQgbXZBQ
JS is used to develop client-side web applications not because it's the best language for the job, but because it's the only language supported by all browsers.
Those who like the philosophy and/or reach of the Web but don't want to use JS have no alternative to using languages like CoffeeScript.
Could you explain what you mean by "languages like CoffeeScript"? If you mean it as "languages compiled to JS" then many of them are completely unlike Coffee in both syntax and semantics. There's a great many of them to choose from, too.
But I think you completely missed my point, which is that you have an alternative for JS (in the form of compile to JS languages, but why should it matter if a language is compiled to JVM bytecode of JS code? It's an implementation detail!). You have an alternative for every single language out there, and a wide array of languages optimized for different use cases. Yet, instead of embracing this diversity, people try to push their favorite[1] language everywhere. Yeah, it's easier to write something that way, but until we have "sufficiently smart compilers" the effect is going to be worse than if you just used a best-suited language for each component of your system.
[1] Maybe because it's the only one they know?
How about using PyV8 to run javascript on the server, so you can share validation logic between the frontend and backend?
At the risk of oversimplifying: on the server, routed actions are concerned with getting data from a database, serializing it, and sending it to the client. On the client, routed actions get data from the server and use it to render a template.
I simply love how I can wrap line from csv file in custom CoffeeScript object just by declaring class like:
class Entry
constructor: ([@id, @description, @amount]) ->
>>> Entry = namedtuple("Entry", "id description amount")
>>> Entry(*line.split(','))
Entry(id='1', description='an entry', amount='99')
Can it inherit from something else?
Can something else inherit from Entry?
Won't named touple have some of its own methods that my methods could have collided with?
class Entry(namedtuple('Entry', ('id', 'description', 'amount')), SomethingElse):
def more_methods(self):
passYes, if you subclass it.
> Can something else inherit from Entry?
Yes, it can be subclassed.
>Won't named touple have some of its own methods that my methods could have collided with
Yes and no, it has the "index" and "count" methods any tuple should have, which can easily be overridden by specifying them as attributes in the second argument to the contructor, through reassignment during initialization or method overriding.
Thanks for the link!
It's more python-like than CoffeeScript-like, but still looks lighter than Python, without the overuse of 'self'. It can compile to C for the server part and to Javascript for the client part. The obvious difference with your project is that it targets nim, not python, and thus cannot reuse any of the python libraries. Being so close to C it can use whatever is written in it though.
Check out this page for a good feel of it:
Whenever a new stack popup, I always wonder 1) who us it 2) why they use it 3) what they use it for
Hopefully more people share their stacks on http://www.stackbus.com/ (FYI, I build it) so that it help others to decide better.
Also, I think we have come a long way since the jQuery/AJAX spaghetti that was apparently a huge problem when this was conceived. I don't even think Node was a thing when this started. Things like Meteor and React address most of the issues and much more, such as live data and reactive UI.
Last updated June 14
> Things like Meteor and React address most of the issues and much more, such as live data and reactive UI.
They don't address one major issue - using a language of your choice.
(I don't use this project but I keep an eye on all 'Python in the browser' projects' and the minute one looks mature and sensible with some real-world takeup I'll be all over it)
I'm sure other people feel the same about their language of choice too. I'm hoping WebAssembly will open the floodgates for genuine choice in browser scripting.
In that case - on a related theme:
At least GWT gave you refactoring.
Not recommended.
>Overall, the general rule is that whoever wants or needs something, they either work around the limitations of JavaScript and the pyjs implementation, or they contribute code to improve the compiler/translator.
The lament of the transpiler
I know, I know. There's others out there who dispute this. Okay.
I think this project lost its mojo. I really loved the idea but personally decided it best to just use javascript.
It's difficult to straddle multiple languages, but you can either 1/ bite the bullet and start straddling or 2/ go all-in on JavaScript (or CoffeeScript, TypeScript, Dart... that compiles directly to JS) and a server-side JS implementation (node.js, Meteor, etc.)
We're years beyond some-other-langauge in the browser being a gleam in someone's eye, yet it still 1/ doesn't work reliably, with up-to-date or at least near-current Python/Perl/Ruby code, 2/ isn't practical in real life, 3/ has no in-the-wild success examples.
The problem, as I see it, is nobody in the node.js/io.js world (or anywhere else, for that matter) has built something that even approaches the power, simplicity, and elegance of Django(especially it's Model layer). I've looked at Meteor, but if I'm not mistaken, it currently does not support using a relational database. And Sails.js, while impressive, does not have as nice an ORM as Django's.
I initially wanted to build apps in Django. Then for a long time, I thought I could live with Rails because it made up for ActiveRecord's (in my opinion) clunkiness with the built-in asset pipeline and stronger out-of-the-box support for building JSON APIs. Then two things happened:
1) I realized I could just split the app into server and client codebases, and since Ember-CLI is the recommended way to develop Ember apps now, I didn't need the asset pipeline.
2) I discovered just how seamlessly Django Rest Framework integrates with Django, providing a more elegant solution for building JSON APIs than Rails.
Since then, I've switched back to Django and never looked back.
what this needs is a fully working app that is modern and source to accompany it.
Personally, I'm a huge fan of python, and has a big potential in the web if done right.