Slashdot Mirror
Browser Bindings for Python, Perl, and other Languages?
Garfycx asks: "Hi everybody! This week Slashdot linked to a story about Java and its roll over C/C++. While reading it I remembered one of the first strategies to make Java a de-facto standard - the browser-applet. as far as I know it did not make it, and I don't see many of them in cyberspace. But in combination with servlets they may come up again. I am not quite sure who is in need of applets but I wondered why there never was a browser-plugin for languages like Python or Perl. I would like to hear about reasons why there is no effort to expand the capabilities of websites with language-plugins. Couldn't there be a universal CORBA-like plugin for Mozilla to be used by most languages or such?"
Of course, the problem is that a web site owner can't assume that an end user has a given language runtime installed. So that limits how you can use it. But it could have great applications on intranets where you have more control over the client situation.
ActiveState has versions of Perl, Python and TCL that follow these API's on Windows. Here is a session they were going to do at the cancelled O'Reilly P2P conference on using this stuff
Internet Explorer can use any language supported by Windows ActiveScripting, which include VBScript, JScript, and even Perl and Python (with ActivePerl/ActivePython from ActiveState).
But the client needs to have these installed, and they are not as secure as JavaScript because they give access to the whole set of Perl's and Python's functions, allowing things like file i/o on the client's disk (which VBScript also allows if i remember correcly).
So they should never be enabled in a web browser, because of the security holes it opens.
Jython is one solution for Python applets. Jython is basically Python compiled into Java. It works well enough to be used for applets.
:-)
http://www.jython.org/applets/index.html
There are a couple of downsides:
- The Jython library has to be downloaded with the applet. It's about 200K. Over a cable modem it takes 0.7 seconds, though.
- Can't use Python extensions.
But there are also a few really good things:
- Jython lets you use the mature AWT/Swing libraries, which are better than Tk. They aren't as good as wxPython, though, IMHO.
- It's a stable platform that works with all Java-enabled browsers already. And Jython continues to receive improvements.
- The *HARD* part about applet-enabling a language is figuring out how to restrict applets without curtailing the language. Sun has achieved that to a reasonable degree and Jython takes advantage of their work.
What I'd like to see is the Java plug-in simply including the Jython library as a standard class library. That would eliminate the download time.
Use Zope!
There is a plug-in for TCL/TK. I don't know about Python and other languages (e.g., Scheme and other LISPs). But perheaps, no one else cares about stupid web-crap :]
--The knowledge that you are an idiot, is what distinguishes you from one.
As this same functionality is in MacOS X (and I believe in it's peer Open Source " Darwin ") the technology is availiable for others to review, compare/contrast, even appropriate. Whatever you think of Apple it's an interesting technology and has already proven it's worth with almost all MacOS applications being made AppleScriptable (and hence everything-else scriptable) for years.
I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
That said, there are over 160 languages apart from java which can be compiled to java bytecode. Jython is quite robust & can be used to create java applets w/ python. There's also a perl->java byte codes compiler under development. (Though maybe it's been abandoned? ...)
Umm..actually, yes it does. The scripting allowed in Flash, especially Flash 5.0, is amazing. We have built chat clients, news tickers, etc. The other great thing about it is that it can interact with whatever Server-side scripting language you are using, be it ASP, Cold Fusion, Perl, etc.
I think the challenge is that because Flash is still new, lots of people are just using it to use it. But just like with any other system, you will start to see more and more applications built out of it that utilize its true power.
Random Musings
... The only major drawback is that you must use AWT and/or JFC bindings to get anything on the screen.
I'm not sure about Jython or Scheme, but Java applets can communicate back to the browser window and use it to render html that they generate. In many cases, this is a much more appropriate way of displaying things on the screen, and isn't quite as ugly looking as AWT can be.
It's only software!
Dolphin Smalltalk has a plugin as well. However, like Dolphin Smalltalk itself, it is Win32 only.
One of the bigger, more business oriented Smalltalks, VisualWorks, also has a plugin. It looks like it too is Win32 only, but VisualWorks itself is cross-platform, and runs on Windows, Mac OS, and a big number of Unices.
The coolest plug-in for a language I've ever seen has got to be Oberon's Juice, by far. Unlike the Java and Squeak VM plug-ins, which take bytecode for their respective VMs, the Juice plugin takes pre-parsed Oberon code and compiles and executes it on the fly. This makes for really fast applets. I tried it a while back and it took a heckuva lot less time for Juice to download, compile, and execute the applet than it took for a comparitive Java applet to start up. Really cool stuff. However, it seems it's not been maintained in a while, and is Windows and Mac only. Seeing how Oberon itself has source available (IIRC), I'm sure that some Oberon enthusiast who wanted to get a generized Unix version going of Juice could do so.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
Hmmm... Where to start?
Microsoft started trying to kill Java back with IE 4 when they had a kick ass JVM, but decided to "forget" certain features such as RMI. The lawsuit simply formalized the animosity.
If MS stops including it, it will be a blow against Java. How big a blow remains to be seen. Alternative browsers are supporting Java through the Java plugin quite consistently. Also, many OEMs have committed to install Java on new Windows systems without Microsoft's help. MS still provides a JVM as a separate download, and Sun still provides the Java plugin for IE. It remains to be seen whether or not this will be a major issue or not.
Browsers that use the plugin have at least Java2 functionality. This allows a significantly greater featureset and raises the bar on compatibility.
With regards to differences, if AWT is used, yes they will look different from one another. This was the point with AWT, that it would look like the underlying platfrom (with the same widgets).
Mozilla (and Opera) uses the Java plugin (and not its own JVM like Netscape 2.0-4.x and IE). Also it is obvious that you haven't used Mozilla with Java recently. The crash bugs that you mention have been stamped out to a large extent. Is it bulletproof? No, but then again are most browsers bulletproof? The point is that I go to sites with Java applets on a regular basis (every day) and have not crashed due to an applet in a couple of months now. I'd say that was stable enough for most.
Chat applications do not have to be trusted applets. I know. I've written a few. Applets can do anything except for the following restrictions: You can only make a network connection to the server the applet came from, you cannot make local filesystem calls, and you cannot call native code. I don't know about you, but that has left quite a bit of room for me to fiddle before having to sign the applet. Your only real limitation is what the client's JVM version is right now. Note that the versioning runs into the same problem that we all face with HTML vs. XHTML vs. DHTML vs. CSS2 -- it's not just Java's problem.
Regarding taking too long to load, this is a programming issue. When Gnome took a while to start up, did you blame C? There are things that you can do to make the applet visible earlier (judicious use of init() and start()). Just as with every other language, there are crap coders in Java as well. And many of those crap coders make applets. Are applets perfect? Of course not, but bad coders have done more to tarnish the Java moniker than any inefficient JVMs.
Use the right tool for the job. Use HTML/DHTML to general presentation, Flash for multimedia, and Java for the things that the previous two just can't handle. In fact, both IBM (DirectDOM) and Mozilla (Blackwood) have make considerable inroads on having Java manage logic on the browser while leaving the UI to the browser widgets. Imagine! The power of a full, typed, OO language with the ease of a browser's DOM. Network-aware, portable programs can be a good thing. In this arena, Java is the best choice. What else are you going to use? ActiveX? In many cases, when it comes down to it, you use Java or you don't do it all. I prefer to use Java rather than sticking my head in the sand and pining for the simpler times.
The simpler times covered 40% of the problems on the 'Net. Some of us want to get the other 60% underway.
---------------
Now then, back to the main topic. Those out there who are worried about security in other languages, ActiveScript on IE (the framework behind VBScript, JavaScript, PythonScript, and PerlScript) does not allow you to instantiate objects that talk to the local filesystem. The trick there was that the various languages had to conform to the framework's security model as opposed to the framework trying to work with all of the different languages/versions out there.
- I don't need to go outside, my CRT tan'll do me just fine.
The reason that other languages do not work as well as java in the applet context, is that in order for an applet to be able to be used freely on the web, it must provide cross platform support. Also, it must have some type of security sandbox or no intelligent user is ever going to let it execute. Java provides both of these without any extra complicated programming hacks. As well as having already established itself as a comptent de facto standard.
The reason that applets have never really made it big is essentially two fold. The first is the shitty virtual machine that most browsers have. IE runs a semi 1.0--1.1 compliant browser and there have been significant changes since then (Swing anybody?). The other reason, and perhaps more important is that there are only a few instances where applets are really needed. If all you are doing is displaying semi-dynamic (aka database driven) content, which is all the pretty much every page on the web does, just use some sort of php/jsp/cgi type solution and your fine, it's faster, and easier in general. If you need a little bit of client side dynamics, you can throw in a little dhtml/javascript and have your form validation and pretty scrolling text or whatever. The real use for applets come when you need a much more interactive sort of web application, where the display needs to be updated constantly, or you need to do a lot of dynamically generated graphics or very complex data processing. These types of apps appear much more frequently on intranets than they do on the web in general, and provide a much richer interactive experience.