My only issue with Python being used for client-side web programing is that significant newlines/whitespace would be an incredible pain if you're inling things in HTML. Although you would pretty much be forced to use GZip rather than just minification, which is good-ish.
Plus, loading a 900KB file to run the Python client-side is probably a terrible idea when you could either transpile to JS or asm.js or (in the future) WebAssembly.
Items that are on the same "level" of indentation, I.e. in a codeblock can have all of them prepended with the whitespace, and then separated with semi-colons.
def func(param):
for i in xrange(5):
print("Inner");print("AnotherLine");print("YetAnotherLine")
From the example you see that whitespace is still necessary, but you could "group" items and not have to repeat the whitespace that forms their level of indentation.
I love the thought of being able to use Python on the client side of the web. We need more commonplace asynchronous paradigms, however.
I do like how this project makes sure to point out that the DOM interface is intended for consumption by any language and on any platform -- maybe one day we'll have browsers that come with several languages' runtimes baked in, or perhaps that can leverage the runtimes for languages already installed on the local machine.
I don't see how it does. You'll still have to download the language runtime (including a garbage collector for a language like Python). Perhaps it can be cached, but that's a heavy requirement for a web page, particularly on mobile.
By contrast, a language that compiles to regular JavaScript can use the GC built into JavaScript.
WebAssembly is pretty much going to be mapped to Asm.js initially. Most of the features it's getting that asm.js doesn't have yet are future asm.js features which wasm is also to be mapped too. This includes things like pthreads, SIMD and the ability to support GC languages.
Being able to use several languages natively does not actually mean "more security attack vectors." Nobody is asking or even talking about ActiveX. This is FUD.
And given "Empythoned is a build script that uses Emscripten to compile CPython for use in a browser", isn't compiling Python to C to Javascript going to end up a bit clunky compared to just writing Javascript?
I see that to use Brighton you need to import a bryton.js file and call "bryton()" on the onload event of the <body> element, and this rings my bell: isn't this a downside compared to normal javascript code?
Non-trivial web pages will take a bit to download fully and load, and sometimes you need your javascript code to act as quickly as it can (that's why very often the js <script> tags are all over the place in the HTML code, not just at the beginning and activated by the onload event).
Well, the Python-to-JS conversion could happen in the server and then this problem would not be there (but then there would be no Python when viewing the source of the page, I know... which is... less fancy?).
Yes, Javascript will still be the fastest option with the cleanest support. That's because browser vendors have intentionally put everything else at a disadvantage (Mozilla ensuring nobody puts Brendan Eich's baby in a corner). The most anyone can really do is generate slight variations on the spelling of Javascript, which has other big disadvantages. All of this is a downside compared to normal programming.
I'm not sure why we need python for the client side web programming, when JS is already used everywhere for that. Does it have to do any issues with JS or it's because Python is easy ? Please enlighten me here.
I've been using both for a while now -- JS for 15 years, Python for five. I expected some big revelation given the consensus that Python is clearly better.
I like working in Python, but I'm still waiting for that revelation. As I can tell, if you can't be as productive in JavaScript as you are in Python, you're either not actually productive in Python, or you never bothered to learn JavaScript.
(I appreciate people who are nevertheless insistent about Python's superiority without bothering to provide any kind of supporting argument, though -- it lets me know how safe I am in disregarding an opinion where I used to think I was probably missing something -- so if you want to recapitulate the quality argument I'm responding too, feel free.)
Python has a string library that makes some kind of goddamn sense (because it matches the C implementation). When I realized that in JS, foo.replace('bar','fizz'); only replaces one instance of 'bar', my head exploded. Then there is the lack of real integers, and all the bullshit ToStringing() that can happen at runtime if you aren't hyper-vigilant.
Looks very interesting! But I don't understand how python is being executed in a web browser. Is there any run time in the browser that I'm missing out(like V8 for JavaScript)?
Apparently the brython.js script translates Python into Javascript, on the fly in the browser and because of this the programs tend to run 3 to 5 times slower than normal javascript. (from the Brython faq)
[Question: ...] is it time to give up on python in the browser ?
Guido: I gave up on it in 1995, so yes. And please don't try to compile Python to JavaScript. The semantics are so different that you end up writing most of a Python runtime in JavaScript, which slows things down too much. (CoffeScript's strength is that it is designed to map cleanly to JavaScript, and the two are now co-evolving to make the mapping even cleaner.)
It's politics, not technology. One could make a browser scripted via python, but it would be an extreme minority position and would fail to gain adoption. One could add python support to any existing browser, but none of the stakeholders care enough to do it; they will always argue it is a waste of time because <insert other popular browser> doesn't do it.
There is nothing about JavaScript that is uniquely suited to the browser, it just "won out". It's hard enough to get browser vendors to agree to standards at all, say nothing about multiple standards for a single feature.
I think the lesson that the last few years have taught us is that you can do ambitious things, but to get buy in it needs to be an incremental and gradual. This is the cost of a large system with >4 largely independent implementors with significantly distinct plans and goals.
It's not too hard for me to imagine a near future with smooth python support in the browser. A webassembly python runtime with GC integration in the browser served trustlessly and with a high cache hit rate from a CDN using subresource integrity (and perhaps with even the popular runtimes packaged ahead of time in browsers). It might be possible to load and run the python source through the webassembly runtime using the ES6 module loader. I wonder if we'll even see JITs in webassembly-based interpreters that compile code that they're interpreting down to webassembly.
> There is nothing about JavaScript that is uniquely suited to the browser
There are, however, features about JS VMs that make them (almost) uniquely suited to browsers. Most notably, almost any other VM has a stdlib including things like open() for local system files — and that'd be considered a massive security exploit. Some languages have features (v. parts of the stdlib) that are insecure in the browser setting — for example the backticks operator in Python. Ensuring an existing VM has had all access to the local system closed off could easily turn into a massive project in and of itself.
> It's hard enough to get browser vendors to agree to standards at all, say nothing about multiple standards for a single feature.
I don't think that's fair — I don't think there's many cases of major browser vendors acting maliciously towards standards in recent times, the only particular examples that stands out to me are the whole pointer/touch events debacle (with Apple withholding patents from the W3C Patent Grant) and the AV codecs mess with various vendors acting selfishly. Otherwise, almost everything seems to be genuine disagreements about how best to do things, especially given market realities.
Politics ? I bet many programmers would like to develop their code for one browser if it supports python. If many apps are only supported by firefox because of that, users might just install firefox if it has an edge in term of app quality and quantity.
That's like why developers chose to use linux to develop web applications, and people used those websites, they did not stick to windows software solutions.
It's really important, I think, to keep having different technologies available so that developers can choose what is better. There are many python programmers already, the language is mature and used in many places and I'm sure it could be used in more places.
That isn't really related to language as much as it is to the API. JS is crap at handling asynchronous programming compared to Python (until it gets async/await/generators which Python already has) but most of Pythons standard library has blocking APIs.
Why? Print is a function instead of a statement? I don't do much python anymore, since I graduated from pygame to DirectX, but the differences in python 3 seem pretty minor, aside from needing external libs upgraded.
if you are using python on your server to parse and process Python dont use eval, and escape whatever quotes the input is coming in with... there at least 10 ways to spawn a command console on python.
Plus, loading a 900KB file to run the Python client-side is probably a terrible idea when you could either transpile to JS or asm.js or (in the future) WebAssembly.