Personally, I like CoffeeScript syntax combined with JavaScript's "a hash is an object" better than Python's object syntax (too much unnecessary use of "self" and class method decorators could be better achieved with the @ sigil).
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.
Speaking of coffeescript, there's a python/coffeescript inspired language that I stumbled upon recently: http://breuleux.github.io/earl-grey/ Basically es6-ified coffeescript it looks like.
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.
>Neat, but can I add few methods to my Entry touple?
Yes, 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.
I like your idea of a language that can compile to Python or JavaScript. I wish there were a straightforward & proven business model that could be applied to programming languages. I have a feeling we would see much more interesting development in this area if there were bigger rewards for coming up with something better than the status quo.
Haxe can target both JS and Python (as well as many other things). It doesn't seem to be very well known, probably because it originally came about for developing Flash content.
Routing could also be shared; you could declare endpoints in one place, but the implementations for client and server would be different.
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 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.
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.
> 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.
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.
> 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.
I do have reservation about Python to be the language to be cross-compiled to anything, then there is NodeJS on server side as well, so what the hell :(
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.
This looks really old. It doesn't even mention anything about Python 2.7, let alone 3.x. Shouldn't we date the post?
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.
> 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)
It's really not about javascript getting better or worse - it's the fact that I don't enjoy coding in javascript anywhere close to how much I enjoy coding in Python. Javascript would have to morph out of all recognition for that to change.
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.
I saw this movie almost a decade ago. It's called GWT, and the end result is code that needs to be debugged at two levels, falls behind both primary platforms, ends up requiring more tooling, and introduces another step to the build process.
>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.
No thanks. I'll write my Python in Python and my Javascript in Javascript. To do otherwise just adds another layer of cruft and makes it harder to debug.
I know, I know. There's others out there who dispute this. Okay.
These "Python in the browser" projects are 1/ very cool 2/ seem entirely doomed. Try the pyjs demos. They're like "the best of the responsive web circa 2007." Some of the demos don't even work, and none of them are particularly snazzy, modern, HTML5-ish, etc.
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.
> 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.)
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 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.