Slashdot Mirror

← Back to Stories (view on slashdot.org)

Browser Bindings for Python, Perl, and other Languages?

Posted by Cliff on from the why-just-java dept.

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?"

3 of 239 comments (clear)

  1. Because it's hard by Xthlc · · Score: 2, Insightful
    The Java platform was meant to serve as a networked computing platform, so it's got quite a few things built in that one would have to write as part of a plugin for another language:

    flexible security model
    Permissions are split into several categories, and a user can grant or deny permissions for each category instead of a blanket grant-permission for everything an applet might want to do to your machine.

    platform independence
    the Java standard library's API is written to abstract away a lot of platform-specific foo that you find in the standard library of other languages.

    performance
    yeah, Java takes a lot of crap for its performance problems. But Sun has spent almost a decade optimizing their VM to make it as fast as possible. An applet language MUST run inside VM or interpreter (for security and platform independence reasons) and writing one that provides even marginal performance for computationally intensive stuff is no easy task.

  2. Applets Were for UI, Now Better Choices by rjsjr · · Score: 2, Insightful
    The fundamental problem that most java applets were solving in the early days of browser applets were user interface issues. Early HTML standards provided a very sparse set of interface behaviors, relatively little control over screen organization, almost no dynamism of interface elements, and made interaction with the server tedious for the user. JavaScript was still floundering as a confused little Netscape introduced scripting language (perhaps it still is). Additionally, most links and servers were considerably slower than they are now, so you had a greater need for accomplishing.

    Java presented itself as a rich medium in which to be able to effect much more complex interfaces. Sure, there were much more grandiose plans, but this is what most people wrote applets for. Ultimately, this proved to be a problematic architecture for a number of reasons (not limited to flaky OSes, lousy java implementations, limited sandbox behavior, and the problems of native UI elements across platforms). I spent many long nights frustrated while trying to develop mission critical communications applications in an applet environment.

    A combination of more advanced HTML behaviors (including DHTML, XHTML, etc.), better client side scripting, and robust server side environments has emerged as the dominant model and has a lot of strengths to speak for it. Compared to applets, we get more flexible, supportable, and scalable environments and can much more easily reuse behavior across into other areas.

    With some apologies to Perl/Tk, wxPerl, and other projects, building a nice user interface has never been a strength of Perl. I love perl and think its a great tool, but its not what I reach for out of my toolbox when user interface problems present themselves. Python is arguably a little more relevant here, but I still don't see a compelling extension of behavior worth the costs of runtime footprint, learning new code, and inevitable incompatibilities. mod_perl is clearly a compelling use to me as I can do innumerable little tasks quickly and easily on my webservers, do I really need super nifty regexps and unix tool linking in my browser's client runtime?

    Where you really do need more advanced behavior (which is far less often than people think), Flash and Shockwave are probably better solutions, particularly from the perspective of designers and content people. And beyond that, an ActiveX control (face it, windows is the dominant user platform, like it or not) lets you accomplish whatever you need more flexibly.

    Lanugages can be a lot of fun to play around with (Ruby and Haskell come to mind right now), but generally speaking its better to minimize the number of tools used and requirements imposed (particularly as we start focusing more on embedded browsers).

    ... rjs

  3. Standard Virtual Machine by Myopic · · Score: 2, Insightful

    Well, since the Java Virtual Machine runs bytecode, not source code, you should be able to compile any language into Java bytecode.

    g++ can compile C/C++ into Java bytecode, can't it?; I'm sure it or other compilers can do the same for other languages.

    Then, assuming everyone has a Java virtual machine, you're all set; except for languages like Perl which aren't compiled -- that sucks, but hey you can't blame the virtual machine for the limitations of the language.