For some time now I've been wondering why the primary scripting format consumed by browsers is JavaScript (a language intended for humans) and not some sort of standard bytecode that would be executed in a browser's virtual machine.
What we need is the JSVM! In other words, something like the JVM but adapted for the browser. That probably means it would have a more dynamic typing focus since it makes sense for JavaScript to be the primary language targeted by the system (though there's no reason this couldn't evolve over time just like the JVM has).
All of a sudden you don't need to build in Python support, or Ruby support or LISP support or whatever else you fancy into the browser. The browser no longer cares what you compiled the script from, it just gets the standard bytecode and everyone's happy.
All of a sudden you don't need to build in Python support, or Ruby support or LISP support or whatever else you fancy into the browser. The browser no longer cares what you compiled the script from, it just gets the standard bytecode and everyone's happy.
Yes please. Just define a straightforward VM in the browser and be done with it. Let the coders handle the rest, and compile any of their favorite languages to it (they will!). Java was on the right track, too bad the implementation (and APIs) were so clunky instead of nicely integrated, otherwise we'd never have needed the JS, Flash, Silverlight, Java applets, HTML5 mess that we're in now.
Anyway, hindsight is 20/20, now we can just settle on JS as a target VM. Too bad it's implemented slightly different in every browser, making it inconvenient as intermediate format. Also, going through a dynamic language is an inefficient level of indirection if you want to program in a static language. You throw away information that could have been used to optimize.
Lots of essential Python features are not part of the language, but belong to its standard library. The thing that makes JavaScript so portable is that it basically has no such thing (except maybe Date and Math).
So to make convenient use of Python in the browser (or even to be able to run currently existing Python code), you wouldn't just have to embed the interpreter – you would have to ship this huge library. And you would have to do that for each language you want to support.
I'm sure we could have some sort of JSVM, we could even have some sort of bytecode for the HTML, but it would destroy part of what makes the web so great: it's openness. The ability to view the source of any webpage, and even make chances and enhance it locally.
There is also the fact that certain optimization can only be done by the browser if it has the actual source code rather than the compiled bytecode.
For some time now I've been wondering why the primary scripting format consumed by browsers is JavaScript (a language intended for humans) and not some sort of standard bytecode that would be executed in a browser's virtual machine.
Because that's how it was initially. And initially - before github and minifiers - that was very important as a way of helping people learn by being able to study the code of other websites.
Parrot in the browser! Don't really know a lot about it, to be honet, but it could work :)
"Parrot is a virtual machine designed to efficiently compile and execute bytecode for dynamic languages. Parrot currently hosts a variety of language implementations in various stages of completion, including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6, APL, and a .NET bytecode translator. Parrot is not about parrots, though we are rather fond of them for obvious reasons."
This is called NACL. And as great as it is, what we really need are on-the-fly compilers/interpreters.
The web needs to be open. As much as this would appease those who want privacy/drm for their code, we all know what road this leads to. Eventually we will be forced to execute certain binaries to browse certain portions of the web. The Urchin.exe forced to execute while we divulge our lives in our browsing habits.
Google/Facebook will track us, we'll know it, and we won't be able to function without it.
We do need a vm. But more than that, we need transparency in the future choices of web standards. Their are powers-that-be that are simply salivating at how quickly developers will evangelize this technology.
All I'm trying to say is the battle seems quite planned and half-done already, and I'm not sure anyone understands the long-term consequences. I sure don't.
Python in the browser would ultimately lead to all the same problems as Javascript in the browser. In a few years, we'll be hearing: Clojure in the browser, Scala in the browser, Haskell in the browser.
I've been programming in Python full-time for the past 6 months, and it's main deficiency are the same as JavaScript's: no (optional) static typing - I'm really sick of writing checks whether my function got values of the correct types, and unittests testing if a class's/function's signature changed in an unexpected way.
What we need, in my opinion, is a dynamic language with powerful optional static typing (unlike Dart, where types are just comments), with sane object-orientedness, and support for immutable values. The core has to be really simple, but the language has to be powerful enough so that libraries can provide the missing functionality (math - rationals, matrices, ...; concurrency - channels, isolates, ...; GUI, IO (with formats, ...)).
> I'm really sick of writing checks whether my function got values of the correct types, and unittests testing if a class's/function's signature changed in an unexpected way.
Sorry to be blunt, but if every one of your Python functions and methods begins with isinstance() checks for every parameter, you just missed the point of the entire language. Python was built on a foundation of ducktyping, with the mantra that "it's easier to ask forgiveness than permission" (EAFP).
Just use your parameters in whatever way you expect them to be, and either catch the rare Exception there or allow them to bubble up. Here's some suggested reading on the subject:
> I'm really sick of writing checks whether my function got values of the correct types
That doesn't sound like a problem that you should be having. The "Pythonic" way to do things is just roll with the values you get and handle any errors that result.
Once you master GWT you can really be very productive in it, while allowing you to:
-Write statically-typed code
-Maintain large projects using packages and OOP
-Use unit testing, code generation, and refactoring tools
-Use many Java libraries out-of-the-box or with minor modifications (this part I often find mind-boggling)
-Write code that works on server and client (also mind-boggling)
-Ignore the DOM, just use widgets
-Ignore the vast majority of cross-browser issues
-Get great IDE support
-Readily deploy apps in servlet containers like GAE or Elastic Beanstalk
-Get very performant, minimized production code
-Get help implementing best practices such as safehtml
-Interleave with JavaScript
Main drawbacks are that there are few well-maintained widget libraries, compiler takes forever, Google has been a bit reluctant to expand JRE emulation, and the script format is a bit annoying. Java is also not a great asynchronous language since it lacks anonymous functions. However, if slightly uglier looking code really concerns you, you probably don't have your priorities straight.
I don't really know what the point of Dart is. I suspect it is being promoted more out of legal concerns over Oracle than out of technical merit.
Python in the browser would ultimately lead to all the same problems as Javascript in the browser. In a few years, we'll be hearing: Clojure in the browser, Scala in the browser, Haskell in the browser.
Did you miss this bit of the article: "Web browsers can be viewed as a zero install interface, a virtual machine for these applications. Such a VM has no reason to be language dependent."
I don't think the article is really about Python, just thats used as an example because that's the language the author uses. I think its really about wanting a VM in the browser that any language can compile to (without having to compile to a high level language like javascript).
tldr: capabilities you want already exist in languages. Non-mainstream stuff to check out for the curious.
What we need, in my opinion, is a dynamic language with powerful optional static typing...with sane object-orientedness, and support for immutable values. The core has to be really simple, but the language has to be powerful enough so that libraries can provide the missing functionality
Check out Strongtalk. I know it already has almost everything you just mentioned above:
http://www.strongtalk.org/
* optional static typing - Check!
* sane object-orientedness - Check! - superlative, actually
* the core...really simple - Check!
* language has to be powerful...libraries
can provide the missing functionality - Check!
I'm not sure if it has immutables, but VisualWorks Smalltalk has it, so it is feasible to add it. (Especially since the engineer who added it for the private vendor is now working on Cog, which is an open source VM.) In addition, Squeak/Pharo run with a >bit-identical model< on something like 50 platforms. (Including different ISA, not just OS.) That's an ideal capability for a browser language.
I'm not saying that we need to use a derivative of Smalltalk in the browser. Smalltalk doesn't have operator precedence, so it comes across as strange to lots of technical people. In fact, lots of things are elegantly different in a lateral-thinking weird way. Alan Kay said it best: the computer revolution hasn't happened yet -- it is in progress. It takes decades for the full impact of what comes out of research labs to really reach the mainstream. It's time for some far-sighted people to take stock of capabilities we're not aware of yet, but which are there to be used.
If you want to give your javascript some type-checking, try running it through the closure compiler. This is what we do, and we annotate our methods with type signatures like this
/**
* Queries a Baz for items.
* @param {number} groupNum Subgroup id to query.
* @param {string|number|null} term An itemName,
* or itemId, or null to search everything.
*/
goog.Baz.prototype.query = function(groupNum, term) {
...
};
And then the Closure Compiler tells us if we've broken some type contracts.
I also prefer typed languages. I also don't like, the way classes are implemented in Python (the whole self thing). But I think Python has enough good stuff to make up for it. To a degree this is psychological, if you only focus on the bad stuff, you will end up hating every programming language you work with.
I do agree that we need a language with static typing so that one can have some level of confidence before releasing the code to production. Having said that python definitely is much better than javascript.
Doesn't dart actually do type checking? It's been a month or 2 since I played with it, but I could swear that it did type checking and reported errors when the type was wrong.
We don't need Python in the browser. We need x in the browser, where x is every language and runtime.
Javascript isn't some sort of global optimum that's perfect for every possible application. The subset of Javascript that's supported by a wide range of current browsers certainly isn't. And the result is that people aiming for the web environment are limited by what Javascript can do - even though there are languages that are arguably more expressive than it.
The problem is right now, only browser makers get to decide what languages run in the browser. Browser makers have their own concerns, and supporting new languages hasn't been historically among them.
What would be nice to aim for is a model where browsers can support multiple language runtimes. Instead of the browser makers being the ones to support a language, that language's advocates would be responsible for the port - and I suspect the competition and cooperation would make them stronger.
Ideally, the language runtimes would be installed transparently. That's the big potential of a project like Native Client - if it lives up to its billing, it makes downloading the latest version of a language runtime to a browser safe, while giving near-native speed and abstract machine.
This would let Python, Ruby, Haskell, Scala, Closure, Java, non-legacy Javascript, and more exist in the same browser, giving the web platform the same diversity of languages as is available on the desktop.
(Mobile platforms seem to also have this problem. The recent move from general-purpose to language-specific platforms is sub-optimal.)
> Ideally, the language runtimes would be installed transparently. That's the big potential of a project like Native Client - if it lives up to its billing, it makes downloading the latest version of a language runtime to a browser safe, while giving near-native speed and abstract machine.
Native Client works behind a plugin API. That means all the languages you implement in it don't integrate as well with the web as JS does. For example, holding references to DOM notes, cycles etc. would work differently.
So I'm a little ignorant, but I think I'll benefit from answers more informed people give:
My question is, why aren't people out there (who are more experienced at programming/developing than I am) developing support for X language(s) in open source web browsers like Firefox. I'm sure I don't fully understand how this works yet, but can't anyone who wants to be developing this capability independently instead of waiting for browser makers to do it?
If you really want a VM, it already exists. It's called JavaScript, assembly language of the web.
I would hate for sites to start saying, "Requires the PyJSVM v0.8 or better to function, download it now!"
EDIT: in hindsight, this post was careless. I was wrong about the "PyJSVM" point, and I posted the minutewithbrendan link to provide commentary, not "Eich said it, so it must be true."
What I should have said:
JavaScript is so widely used today, that anything that comes along purporting to be better (such as bytecode, Dart, whatever) must be so much better as to provide a clear reason for developers and users. If it's just "better", then JS will remain dominant because it's good enough. Therefore, it makes sense to target JS from other langs. It's definitely not getting slower, and we're on the cusp of some great APIs!
With that installed, you can write extensions in Python and even include Python code in your HTML files if you want to: https://developer.mozilla.org/en/PyDOM
Source mapping (part of ES6) gives proper error messages for other languages compiled into JS, I believe this would include Pyjamas etc.
But do Python programmers who haven't programmed for the browser before realize how important async is?
Tornado and Twisted users are used to passing around functions, but they're very small subsets of the Python community, who, if asked to fetch something and do something with it, would generally wait until it's fetched.
"But do Python programmers who haven't programmed for the browser before realize how important async is?"
Not a very useful question. Anyone who has ever programmed on a GUI of any sort will know how important that is, anybody else will rapidly learn. The vague-but-pervasive idea that web developers invented async about two years ago and thus "async experience" can be presumed to have not penetrated out to those other less enlightened communities who still haven't discovered its Mighty Powers is... not exactly historically accurate, let us say. GUIs have always had to deal with async issues, going all the way back to the dawn of GUIs. It's not a new idea. It's probably older than you are. (It is older than I am.)
The subsets of people that do UI work right (Qt, Gtk, etc.) and people that do networking right (Twisted) are relatively large. I wouldn't worry about it too much.
Can the rpython translator support js as a target? Could you compile pypy to js that way, to provide a python environment in existing browsers?
To be honest though, JS is a perfectly OK language for web browsers, and if you really want to reuse python code it probably makes more sense to translate it before it gets to the browser, using automated tools or otherwise. Supporting everybody's favourite language natively in every browser would be horrible.
I like Python, but JavaScript is sort of good at what it does: evented programming. In javascript it's really easy write a closure. I have not worked with asynchronous frameworks like twisted, but I'd image it's a little more awkward. Am I wrong?
Personally, to me Javascript is horrendously broken at what it does. In addition to being fatally underspecified as a language, the asynchronous model as implemented in JS results in callback spaghetti (or black magic with Streamline or something). Most JS evented code has extremely poor readability, since logic flow is continuously interrupted.
The best asynchronous event programming idioms I've seen in Python use decorators and yield.
The language in the browser is not the problem to me. If I could use python it wouldn't change the fact that you still need to deal with the DOM, CSS and browser differences.
It seems that the primary method of disagreement used by only-JavaScript-in-the-browser advocates is as follows:
1. Talk about the "open web";
2. Tell you to compile to JavaScript.
I really don't understand why this is considered a reasonable response to people who just want to build things with the language they prefer, without being treated as second-class citizens.
Maybe because people are afraid to end up with a fragmented web all over again.
Preference of language shouldn't really be a factor. The real question is that any change must be properly standardized and implemented by all browser vendors else you end up with "This webpage is written in python and is only supported by Chrome 39+ and Firefox 43+".
Does using your prefered language really outvalue that?
I think the bytecode argument is a more feasable one, as long as it could somehow be compiled to javascript and support older browser versions effortlessly.
This is ridiculous. I love python, but it has no language support for an event loop, and if you put it in a browser, everything would have to be done in an event loop. It'd be ugly.
Javascript excels at evented programming. Use the right tool for the job.
I was just going to comment that at least Python has yield (generators) which helps to avoid callback spaghetti¹, but Javascript seems to have got it too in 1.7².
If your python eventually compiles down to JavaScript it's worth doing. That way you can get the developers to hop on because it's easier to program. Browsers could then implement functions to directly process the python source and not the JS which would have speed benefits.
But I really feel there is no need for python in the browser. JS is good enough. If you want an easier way to write it use CoffeeScript.
With a tool like Enyo you can write all the code in a sort of JavaScript, and it is converted to HTML + JavaScript. Google also has a tool to convert Java to JavaScript. Why not a similar tool for Python (or other language)? No practical need to have a lot of languages in the browser itself IMHO even if it would be nice to program web pages with his favorite language.
An ideal situation would be installable interpreters that still allowed you to use a system-wide rendering engine. I actually think Windows had something similar with ActiveScripting.
I assume something like QT allows you to script the webview with whatever language you have bindings for? Unfortunately QT+bindings is a pretty long way from 'zero install'
Sounds more like plugin hell to me. I think it's becoming increasingly harder to convince users to install browser plugins (for good reasons), and it's not even possible on most mobile browsers.
We don't need another language in the browser. We need a VM in the browser. As in byte codes. That way ANY language can be used. JS gets compiled down to a VM and then that is run in most implementations of JS. Why can't we just target that VM directly and use our own tools and compilers instead of being forced to compile it to javascript?
JavaScript is the bytecode that you can compile your python or whatever code too. Just make the standards committee implement some nice features that are useful for bytecodes and you are all set.
[+] [-] hetman|14 years ago|reply
What we need is the JSVM! In other words, something like the JVM but adapted for the browser. That probably means it would have a more dynamic typing focus since it makes sense for JavaScript to be the primary language targeted by the system (though there's no reason this couldn't evolve over time just like the JVM has).
All of a sudden you don't need to build in Python support, or Ruby support or LISP support or whatever else you fancy into the browser. The browser no longer cares what you compiled the script from, it just gets the standard bytecode and everyone's happy.
[+] [-] wladimir|14 years ago|reply
Yes please. Just define a straightforward VM in the browser and be done with it. Let the coders handle the rest, and compile any of their favorite languages to it (they will!). Java was on the right track, too bad the implementation (and APIs) were so clunky instead of nicely integrated, otherwise we'd never have needed the JS, Flash, Silverlight, Java applets, HTML5 mess that we're in now.
Anyway, hindsight is 20/20, now we can just settle on JS as a target VM. Too bad it's implemented slightly different in every browser, making it inconvenient as intermediate format. Also, going through a dynamic language is an inefficient level of indirection if you want to program in a static language. You throw away information that could have been used to optimize.
[+] [-] hannes2000|14 years ago|reply
So to make convenient use of Python in the browser (or even to be able to run currently existing Python code), you wouldn't just have to embed the interpreter – you would have to ship this huge library. And you would have to do that for each language you want to support.
[+] [-] Drakim|14 years ago|reply
There is also the fact that certain optimization can only be done by the browser if it has the actual source code rather than the compiled bytecode.
[+] [-] pornel|14 years ago|reply
Here is Python running in the browser:
http://syntensity.com/static/python.html
[+] [-] icebraining|14 years ago|reply
Because that's how it was initially. And initially - before github and minifiers - that was very important as a way of helping people learn by being able to study the code of other websites.
[+] [-] gizzlon|14 years ago|reply
"Parrot is a virtual machine designed to efficiently compile and execute bytecode for dynamic languages. Parrot currently hosts a variety of language implementations in various stages of completion, including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6, APL, and a .NET bytecode translator. Parrot is not about parrots, though we are rather fond of them for obvious reasons."
http://www.parrot.org/ http://duckduckgo.com/Parrot_virtual_machine
[+] [-] gringomorcego|14 years ago|reply
The web needs to be open. As much as this would appease those who want privacy/drm for their code, we all know what road this leads to. Eventually we will be forced to execute certain binaries to browse certain portions of the web. The Urchin.exe forced to execute while we divulge our lives in our browsing habits.
Google/Facebook will track us, we'll know it, and we won't be able to function without it.
We do need a vm. But more than that, we need transparency in the future choices of web standards. Their are powers-that-be that are simply salivating at how quickly developers will evangelize this technology.
All I'm trying to say is the battle seems quite planned and half-done already, and I'm not sure anyone understands the long-term consequences. I sure don't.
[+] [-] tomp|14 years ago|reply
I've been programming in Python full-time for the past 6 months, and it's main deficiency are the same as JavaScript's: no (optional) static typing - I'm really sick of writing checks whether my function got values of the correct types, and unittests testing if a class's/function's signature changed in an unexpected way.
What we need, in my opinion, is a dynamic language with powerful optional static typing (unlike Dart, where types are just comments), with sane object-orientedness, and support for immutable values. The core has to be really simple, but the language has to be powerful enough so that libraries can provide the missing functionality (math - rationals, matrices, ...; concurrency - channels, isolates, ...; GUI, IO (with formats, ...)).
[+] [-] Pewpewarrows|14 years ago|reply
Sorry to be blunt, but if every one of your Python functions and methods begins with isinstance() checks for every parameter, you just missed the point of the entire language. Python was built on a foundation of ducktyping, with the mantra that "it's easier to ask forgiveness than permission" (EAFP).
Just use your parameters in whatever way you expect them to be, and either catch the rare Exception there or allow them to bubble up. Here's some suggested reading on the subject:
http://www.canonical.org/~kragen/isinstance/
http://stackoverflow.com/questions/6092992/why-is-it-easier-...
[+] [-] jamesgeck0|14 years ago|reply
That doesn't sound like a problem that you should be having. The "Pythonic" way to do things is just roll with the values you get and handle any errors that result.
[+] [-] tybris|14 years ago|reply
-Write statically-typed code
-Maintain large projects using packages and OOP
-Use unit testing, code generation, and refactoring tools
-Use many Java libraries out-of-the-box or with minor modifications (this part I often find mind-boggling)
-Write code that works on server and client (also mind-boggling)
-Ignore the DOM, just use widgets
-Ignore the vast majority of cross-browser issues
-Get great IDE support
-Readily deploy apps in servlet containers like GAE or Elastic Beanstalk
-Get very performant, minimized production code
-Get help implementing best practices such as safehtml
-Interleave with JavaScript
Main drawbacks are that there are few well-maintained widget libraries, compiler takes forever, Google has been a bit reluctant to expand JRE emulation, and the script format is a bit annoying. Java is also not a great asynchronous language since it lacks anonymous functions. However, if slightly uglier looking code really concerns you, you probably don't have your priorities straight.
I don't really know what the point of Dart is. I suspect it is being promoted more out of legal concerns over Oracle than out of technical merit.
[+] [-] dkersten|14 years ago|reply
Did you miss this bit of the article: "Web browsers can be viewed as a zero install interface, a virtual machine for these applications. Such a VM has no reason to be language dependent."
I don't think the article is really about Python, just thats used as an example because that's the language the author uses. I think its really about wanting a VM in the browser that any language can compile to (without having to compile to a high level language like javascript).
[+] [-] stcredzero|14 years ago|reply
What we need, in my opinion, is a dynamic language with powerful optional static typing...with sane object-orientedness, and support for immutable values. The core has to be really simple, but the language has to be powerful enough so that libraries can provide the missing functionality
Check out Strongtalk. I know it already has almost everything you just mentioned above: http://www.strongtalk.org/
I'm not sure if it has immutables, but VisualWorks Smalltalk has it, so it is feasible to add it. (Especially since the engineer who added it for the private vendor is now working on Cog, which is an open source VM.) In addition, Squeak/Pharo run with a >bit-identical model< on something like 50 platforms. (Including different ISA, not just OS.) That's an ideal capability for a browser language.I'm not saying that we need to use a derivative of Smalltalk in the browser. Smalltalk doesn't have operator precedence, so it comes across as strange to lots of technical people. In fact, lots of things are elegantly different in a lateral-thinking weird way. Alan Kay said it best: the computer revolution hasn't happened yet -- it is in progress. It takes decades for the full impact of what comes out of research labs to really reach the mainstream. It's time for some far-sighted people to take stock of capabilities we're not aware of yet, but which are there to be used.
[+] [-] mhansen|14 years ago|reply
If you want to give your javascript some type-checking, try running it through the closure compiler. This is what we do, and we annotate our methods with type signatures like this
And then the Closure Compiler tells us if we've broken some type contracts.[+] [-] halayli|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] ma2rten|14 years ago|reply
[+] [-] cploonker|14 years ago|reply
[+] [-] rufugee|14 years ago|reply
[+] [-] jimhefferon|14 years ago|reply
[+] [-] trothamel|14 years ago|reply
Javascript isn't some sort of global optimum that's perfect for every possible application. The subset of Javascript that's supported by a wide range of current browsers certainly isn't. And the result is that people aiming for the web environment are limited by what Javascript can do - even though there are languages that are arguably more expressive than it.
The problem is right now, only browser makers get to decide what languages run in the browser. Browser makers have their own concerns, and supporting new languages hasn't been historically among them.
What would be nice to aim for is a model where browsers can support multiple language runtimes. Instead of the browser makers being the ones to support a language, that language's advocates would be responsible for the port - and I suspect the competition and cooperation would make them stronger.
Ideally, the language runtimes would be installed transparently. That's the big potential of a project like Native Client - if it lives up to its billing, it makes downloading the latest version of a language runtime to a browser safe, while giving near-native speed and abstract machine.
This would let Python, Ruby, Haskell, Scala, Closure, Java, non-legacy Javascript, and more exist in the same browser, giving the web platform the same diversity of languages as is available on the desktop.
(Mobile platforms seem to also have this problem. The recent move from general-purpose to language-specific platforms is sub-optimal.)
[+] [-] azakai|14 years ago|reply
Native Client works behind a plugin API. That means all the languages you implement in it don't integrate as well with the web as JS does. For example, holding references to DOM notes, cycles etc. would work differently.
[+] [-] skizzikskizziks|14 years ago|reply
My question is, why aren't people out there (who are more experienced at programming/developing than I am) developing support for X language(s) in open source web browsers like Firefox. I'm sure I don't fully understand how this works yet, but can't anyone who wants to be developing this capability independently instead of waiting for browser makers to do it?
[+] [-] carsongross|14 years ago|reply
We need a VM SPEC for the browser, so we can have whatever language we damned well please in the browser.
Why Google decided to go with Dart rather than publish a VM spec is beyond me.
[+] [-] kirbysayshi|14 years ago|reply
If you really want a VM, it already exists. It's called JavaScript, assembly language of the web.
I would hate for sites to start saying, "Requires the PyJSVM v0.8 or better to function, download it now!"
EDIT: in hindsight, this post was careless. I was wrong about the "PyJSVM" point, and I posted the minutewithbrendan link to provide commentary, not "Eich said it, so it must be true."
What I should have said:
JavaScript is so widely used today, that anything that comes along purporting to be better (such as bytecode, Dart, whatever) must be so much better as to provide a clear reason for developers and users. If it's just "better", then JS will remain dominant because it's good enough. Therefore, it makes sense to target JS from other langs. It's definitely not getting slower, and we're on the cusp of some great APIs!
[+] [-] tuukkah|14 years ago|reply
With that installed, you can write extensions in Python and even include Python code in your HTML files if you want to: https://developer.mozilla.org/en/PyDOM
[+] [-] nailer|14 years ago|reply
But do Python programmers who haven't programmed for the browser before realize how important async is?
Tornado and Twisted users are used to passing around functions, but they're very small subsets of the Python community, who, if asked to fetch something and do something with it, would generally wait until it's fetched.
[+] [-] jerf|14 years ago|reply
Not a very useful question. Anyone who has ever programmed on a GUI of any sort will know how important that is, anybody else will rapidly learn. The vague-but-pervasive idea that web developers invented async about two years ago and thus "async experience" can be presumed to have not penetrated out to those other less enlightened communities who still haven't discovered its Mighty Powers is... not exactly historically accurate, let us say. GUIs have always had to deal with async issues, going all the way back to the dawn of GUIs. It's not a new idea. It's probably older than you are. (It is older than I am.)
[+] [-] lucian1900|14 years ago|reply
[+] [-] Joeboy|14 years ago|reply
To be honest though, JS is a perfectly OK language for web browsers, and if you really want to reuse python code it probably makes more sense to translate it before it gets to the browser, using automated tools or otherwise. Supporting everybody's favourite language natively in every browser would be horrible.
[+] [-] ma2rten|14 years ago|reply
[+] [-] ak217|14 years ago|reply
Personally, to me Javascript is horrendously broken at what it does. In addition to being fatally underspecified as a language, the asynchronous model as implemented in JS results in callback spaghetti (or black magic with Streamline or something). Most JS evented code has extremely poor readability, since logic flow is continuously interrupted.
The best asynchronous event programming idioms I've seen in Python use decorators and yield.
[+] [-] justncase80|14 years ago|reply
items.select {|e| e.isFoo}
It's arguably more terse and superior to javascript in that particular feature as well.
[+] [-] okal|14 years ago|reply
[+] [-] mcdaid|14 years ago|reply
[+] [-] dhconnelly|14 years ago|reply
1. Talk about the "open web"; 2. Tell you to compile to JavaScript.
I really don't understand why this is considered a reasonable response to people who just want to build things with the language they prefer, without being treated as second-class citizens.
[+] [-] ttt_|14 years ago|reply
Preference of language shouldn't really be a factor. The real question is that any change must be properly standardized and implemented by all browser vendors else you end up with "This webpage is written in python and is only supported by Chrome 39+ and Firefox 43+".
Does using your prefered language really outvalue that?
I think the bytecode argument is a more feasable one, as long as it could somehow be compiled to javascript and support older browser versions effortlessly.
[+] [-] Joeboy|14 years ago|reply
That's a ridiculous and off-putting way of wording your complaint.
[+] [-] jnowl|14 years ago|reply
I would think that would help make it popular which would help compel other browsers to support such technology.
[+] [-] mhansen|14 years ago|reply
Javascript excels at evented programming. Use the right tool for the job.
[+] [-] Yaggo|14 years ago|reply
[1] http://www.tornadoweb.org/documentation/gen.html
[2] https://developer.mozilla.org/en/New_in_JavaScript_1.7#Gener...
[+] [-] martincerdeira|14 years ago|reply
http://webcache.googleusercontent.com/search?q=cache:Q-BEBq4...
but, sadly, nobody follows this idea...
[+] [-] spobo|14 years ago|reply
But I really feel there is no need for python in the browser. JS is good enough. If you want an easier way to write it use CoffeeScript.
[+] [-] scriptproof|14 years ago|reply
[+] [-] andybak|14 years ago|reply
I assume something like QT allows you to script the webview with whatever language you have bindings for? Unfortunately QT+bindings is a pretty long way from 'zero install'
[+] [-] hannes2000|14 years ago|reply
[+] [-] BrennanCheung|14 years ago|reply
[+] [-] Newky|14 years ago|reply
Are they talking about async frameworks such as twisted/tornado? or is there more core work that I don't know about?
[+] [-] voidr|14 years ago|reply