Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Mozilla The Internet

Browser Bindings for Python, Perl, and other Languages? 239

Posted by Cliff 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?"
This discussion has been archived. No new comments can be posted.

Browser Bindings for Python, Perl, and other Languages? More

Browser Bindings for Python, Perl, and other Languages?

Comments Filter:
  • but IE's got COM bindings for quite some time now. (v3, and stabilized in v4).

  • This already exists on Windows, it's called ActiveScripting [microsoft.com]. Basically, the API's that both VBScript and JScript (JavaScript) use to integrate themselves into the browser are exposed to others as well. If you follow the API guidelines, then you can use any scripting language from any hosting program including IE.

    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 [activeperl.com] has versions of Perl, Python and TCL that follow these API's on Windows. Here is a session [activeperl.com] they were going to do at the cancelled O'Reilly P2P conference on using this stuff

  • Java was (and still is, to an extant) popular as web applets because it allowed developers to put multimedia content (animations, sounds, games) on their pages very easily. Perl and python, while great languages, really don't have that sort of multimedia ability (or bloat). For this reason, they're less desireable for client-side applets.
    • Back in the early days, everyone lauded Java as a means to add multimedia content to the web. However, specialized system (flash/shockwave) for this have proved so much better at this than Java that Java is essentially dead in this area. If someone is using Java for multimedia on a webpage nowadays it simply means they haven't learned how to use flash yet.
      • Or maybe they just don't want to shell out for flash.
      • Does flash/shockwave have the ability to open streams back to the server for updates (a good example is espn's gamecast - near realtime baseball game info updates)? Are the standard libraries on par with java? I am sure that Flash/Shockwave is better than java for flashing pretty pictures on the screen, but what about for real applications (not just animations)?
        • 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.
      • Back in the early days, everyone lauded Java as a means to add multimedia content to the web.


        That may have been its most obvious selling point, but that was far from it's only use. It was a cross-platform method of client/server programming. You could develop sophisticated applications with incredible performance characteristics (compared to simple DHTML) that you could distribute to a heterogenious intranet (Solaris/Linux/win32).

        Eventually DHTML got more sophisticated, and generating graphics for HTML was an order of magnitude simpler than for Java. Thanks to more reliable javascript, you can also produce many of the dynamic operations that previously required Java. (procedural drop-downs, tabbed pages, refreshing, etc).

        -Michael
      • The plain truth is, users don't want multimedia content on web pages. For most people it's a nuisance, especially the majority of us who use modem connections. Most people have Java enabled in their browsers and Flash disabled, but that's just because (a) nobody gave them an obvious way to avoid installing Java, and (b) they don't realize they can turn Java off, or allow applets to run only when they click on them.


        Once in a while you actually want to run client-side software via the Web, and then you want an applet. For most people, however, this is very rare. I'm not against applets (I wrote an open-source planetarium applet [lightandmatter.com], and it's moderately popular). I'm just against using them in stupid ways. And, as people have already said in other comments on this story, it's nightmarish to consider the security problems that would come up if you allowed applets in languages that weren't specifically designed with Java's security and no-crash features. The same things that make me enjoy programming in Perl more than in Java are also the things that make Java applets safe for users.

  • security (Score:3, Interesting)

    by johnjones ( 14274 ) on Sunday September 23, 2001 @11:43AM (#2337605) Homepage Journal
    how do you sandbox the implementation ?

    java has lots of features to run in a sandbox and verifying the bytecodes + grant access if you ask for it

    this would have to be added to any other implemtation

    fankly I dont need another way of downloading rubish

    text is enough to conveiw most information well why do you need anything else?
    (pictures are handled by jpeg and PNG )

    so WHY ?

    games I think are the most use I have played lots of flash and applet golf games on the net but appart from that I have never used applets

    oh and I think that phones running a java VM(so you can play games appart from snake) will be more prolific over the next 2 years so that battle is over

    regards

    john jones

    • how do you sandbox the implementation?


      If you're running FreeBSD, jail [freebsd.org]. I don't think linux has a decent jail system call, though, and chroot wouldn't really be effective enough.

      • I don't think linux has a decent jail system call

        The kernel developers are working on that... I'm not sure when it's supposed to be integrated, but there is code going in to support fine grained security, which is necessary for a system like this. I'm no kernel hacker, nor do I follow dev religiously - can someone who knows a bit more pop in and say if this would be useful? (Say, create a "webplugin" access level, and give your child process access to very finite system resources).

        --
        Evan

      • What does the *BSD jail system have that a non-root chroot system doesn't? (Not a flame - just asking.)

  • Because it's hard (Score:2, Insightful)

    by Xthlc ( 20317 )
    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.

  • Erm, isn't this simply because Java runs in a virtual machine. The point is that Java runs in a sandbox, which is supposedly separate from the rest of the processes running on your machine, so that it should be more secure, and can't run arbitrary code on your machine.

    If you're talking about simply letting a browser run any code on a computer simply by going to a page, then it's fairly obvious why this is a terrible idea - it lets a web page author run any code they like on the computers of anyone that goes to their page.

    Perhaps I'm being dim, and missing something, but if I'm not, that seems blindingly obvious to me.

    • If you're talking about simply letting a browser run any code on a computer simply by going to a page, then it's fairly obvious why this is a terrible idea


      That terrible idea is called ActiveX.

    • Re:Sandboxes... (Score:2, Informative)

      by ascholl ( 225398 )
      Yessiree. The important thing isn't the language, but portability & security. Implementing something equivalent to a jvm for your favorite language is decidedly not a trivial task.

      That said, there are over 160 [tu-berlin.de] languages apart from java which can be compiled to java bytecode. Jython [jython.org] is quite robust & can be used to create java applets w/ python. There's also a perl->java byte codes compiler [ebb.org] under development. (Though maybe it's been abandoned? ...)

  • The main reason Java Applets never became supper popular is the fact that there is a lot of overhead in them. And the fact that MS dosent want Sun to get the market share, makes sure that MS will try to hinder its performance. But Java Applets are still used a lot but now in mostly intranets or sites that expect broudband internet traffic. But for the coman user with a random selection of system the applet has not had its shine.
  • Applets didn't die ... they just went to a small niche, that is specific applications in an Intranet ... There you don't have to worry wether your customers want to download a 5-8MB java-plugin. The only Applets you see nowadays are cheap Flash-Replacements (most of these little Menus and Animations would be better done with Flash, and that wouldn't have given Java Applets such a bad image).

    The biggest problem with Applets was, that the browsers just supported 1.1 (at most), and that it was faulty. Noone liked to download the big Plugins, so noone wrote Applets that used the new API, so noone downloaded the plugins, ...

    The fact that MS provides no Java-VM in IE6 might be both good and bad for Java on the client. Bad for obvious reasons, good, because then you have to download the plugin, should you ever want to use Java. Doing this, you get a modern version of Java, and that is A Good Thing (tm).

    • No, it would not be better to use Flash instead of Java.

      Java applets have two big advantages over plugins:

      • Java is generic. Java applets can do pretty much anything, but you need to get a new plugin for each new task.
      • They are platform-independent.

      Two examples where Java is put to good use are ChemFinder [chemfinder.com] and the NIST WebBook [nist.gov]. Both these sites use Java to make it possible to draw chemical molecules and search for them in their databases. Using Java for this is a lot better than getting two different plugins which would only be available for a limited number of platforms.

      /Johan

    • I think there are a lot more applets on the net, getting a lot more hits, than most people think. If you go to many of the major games sites that offer things like spades online, you'll notice that their games are most often implemented in Java (shockwave being the likely second). There are a lot of people playing these games, and it makes sense that the IE users will eventually upgrade to IE6, and they'll go get Sun's Java plug-in so they can continue playing their games.

      I think the biggest thing Sun could do to get people to keep using Java is to raise the awareness of these sites, so that people use them and keep a Java-enabled browser around.
    • Most financial websites use Java to display live stock tickers. In addition, check out the heat map of the market at smartmoney.com. Pretty good stuff.

  • Hmnn.. not sure about CORBA, but perl applets? Doesn't make much sense to me. That's not what perl is good for, and it's certainly not what it was designed for. Anyway, Perl is already at large, on the internet, doing (arguably) what it does best - CGI.

    <offtopic> What I would really like to know is, when the hell is someone going to come out with a "psh"? Imagine it.... a Perl Shell. mmmmmmmmn

  • ActiveScripting (Score:2, Informative)

    by Idolatre ( 197068 )

    Internet Explorer can use any language supported by Windows ActiveScripting, which include VBScript, JScript, and even Perl and Python (with ActivePerl/ActivePython from ActiveState [activestate.com]).

    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.

    • VBScript and JavaScript need to go through COM objects to do file IO because there's no built-in facility. However, when running in the browser, there's a very limited range of objects they can access that prevents anything nasty happening.

      PerlScript does have Perl's bulit-in file IO, but by default it only runs from sites defined to be in the "Local" zone. link [adaptive.net]. But it's a good point that WSH's installable language facility could be a security risk with the wrong language runtime.
  • How about a browser plugin for C/C++ apps? ANybody know of one?
    • theoretically, you could get a c/c++ compiler which compiles to java bytecode...

      and as long as the same interfaces were exposed, aka the applet's run,init,start, etc; you could write an applet that would run in existing jvm applet space in c/c++.

      of course right now i cant remember any of the bytecode c/c++ compilers.
    • How about a browser plugin for C/C++ apps?

      In this case, the applet *is* the plugin. Simply write your "applet" using the plugin API of the given browser, compile for whichever platform you want, and there ya go!

      Of course, a much more "interesting" solution to this would be to write a browser plugin that contains gcc/g++ and all appropriate libraries. Your applet would then just be C or C++ source code, and when downloaded, the plugin would compile and run it for you! In addition, you'd be able to run your applets on any platform that you ported your plugin to. Aside from the obvious security issues with untrusted C/C++ code, and the *size* that this plugin would be, you have to admit, it'd be a very hack-worthy thing to do!

  • Basic Philosophical Difference (Score:4, Interesting)

    by NutscrapeSucks ( 446616 ) on Sunday September 23, 2001 @11:52AM (#2337633)
    IE ships with ActiveX/COM support, which provides a language-independent mechanism to plug anything you want into your browser. The user gets code-signing and some level of download control, but ultimately there's no 'sandbox' to prevent that code from doing what it wants (deleting your home directory, e-mail bomb, etc). They've been ripped for the security implications, as anyone who reads Slashdot knows.

    Netscape chose the safe route and only provided Java applet support. This relies on the Java security model to protect the user through sandboxing from anything that they might automatically download, but locks you into Java. Mozilla/NS6 may allow some sort of XPCOM application to be downloaded and installed, but it's not as seamless as ActiveX.

    The important point is that you don't get 'unsafe' languages like C++ and Perl in your browser without the security implications that everyone's roasted Microsoft's ass over.

    The MS .NET approach will be the hybrid. While you still have a Java-like runtime that has a security model, at least you won't be locked into a particular language.

    • Netscape chose the safe route and only provided Java applet support.

      Either I misunderstand your point, or you're rewriting history.

      What about the Netscape Plugin API? Much less elegant, download- and certificate-wise, than ActiveX, but it, too, provides access to 'unsafe' languages.


    • You're not actually locked into using Java. Many languages can be compiled into java bytecode, the most notable beeing Python (Jython) and Scheme. The only major drawback is that you must use AWT and/or JFC bindings to get anything on the screen.
      • ... 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.
    • wait a second... .NET is not a browser component. its a server component.

      .NET ~ java servlets
      .NET !~ java applets / plugins /activex virii

      (well its a virus for sure)

      but i dont think theres much in the way of .NET on the client side. although it wouldnt surprise me to find it coming.
    • Sorry, but Mozilla is extensible in a number of ways starting from the humble plugin, to chrome & skins, all the way through to writing your own XPCOM components and services which you can hook into Mozilla in all kinds of weird and wonderful of ways. It can even support different scripting languages via the wonders of XPConnect. For example ActiveState already have an XPConnect adaptors for their Perl and Python implementations.



      As for security implications, a script context is only as dangerous as the power you expose into it. Javascript is only considered a "safe" language because it typically doesn't have access to any objects that can do damage.



      The fundamental difference between IE and Mozilla is that IE automates this process of downloading and installing COM components, whereas Mozilla makes it quite cumbersome. It does have an automatic installation facility in the form of XPInstall but it hasn't been picked up by plugin developers.



      The principle problem of automating everything is that the user in general hasn't a clue whether a control is trustworthy or not. Yet a control can be downloaded, installed and run on their machine to do anything it pleases with a few mouse clicks. Manual installation may be more irksome but it gives a novice pause for thought and discourages web sites from using controls in the first place.

  • Jython (Score:2, Informative)

    by Shane Hathaway ( 210174 )
    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.

  • TCL (Score:5, Informative)

    by redhog ( 15207 ) on Sunday September 23, 2001 @11:58AM (#2337645) Homepage
    There is a plug-in for TCL/TK [demailly.com]. 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 :]

  • One Example (Score:3, Informative)

    by maggard ( 5579 ) <michael@michaelmaggard.com> on Sunday September 23, 2001 @12:01PM (#2337653) Homepage Journal
    Apple has had it's " Open Scripting Architecture [apple.com]" for a number of years. Apple's own AppleScript [apple.com] or Perl, Python, Java, JavaScript, Tcl/tk, etc. can all plug in and be used throughout the system. Indeed with the vast majority of MacOS applications being AppleScript-able they're all also automagically Perlable, Pythonable, Javable, JavaScriptable, Tcl/Tkable, etc [applescrip...cebook.com]. As all of the popular MacOS web browsers also support this it's not difficult to script things via web-pages.

    As this same functionality is in MacOS X (and I believe in it's peer Open Source " Darwin [apple.com]") 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.

  • Theoretically, there are bindings for several languages that can be run in a JVM, using the Bean scripting framework [ibm.com]. The list of languages that can be run in it [javaworld.com] include a subset of Perl, Rexx, Jython, Javascript...

  • I think the major technical stumbling block to allowing applets or scripting in any language is finding a language-neutral way of restricting execution along the lines of Java's security model.

    That's a really hard thing to achieve correctly - and if you don't get it right then your browser is swiss-cheese. Even harder is to get it right, cross-platform. Under a *NIX you could run whatever external code in a chroot environment to stop it from messing with any of your files... but what's to stop the code DoS'ing you by opening thousands of windows?

    Individual languages have their own security models and restricted execution environments (Python has the Bastion module for instance) but it would be a veritable Tower of Babel trying to support every security model that every language implements (and of course, many languages don't even have the concept).

    You could create a standard security model that is implemented through a very restricted set of APIs that are all that's exposed to foreign code, and attempt to disallow any other access (a la COM) but experience with COM tells us that this is not really tremendously secure at all without a generally more robust security model in the OS. You could achieve it using the Linux capabilities model and it would be secure, but then it would be impossible to implement cross-platform, and you'd probably still have to extend capabilities further in order to prevent external code from DoS'ing you with new windows.

    All in all, it's just too fraught with difficulties to really make it worthwhile.

    Then there's the question of support - implement a fantastic new security model that allows you to run any language within a completely foolproof sandbox, great. Now, how many IE/Windows users will download your plugin? How many of them have Perl or Python installed? I'd put the number at something approaching zero, and with 80%+ or whatever of the browser market being IE these days, I can't see this ever taking off, even if it became a standard feature in every other browser on the planet.

    Maybe it could work on an intranet, where everything is secure and controlled. But in an environment like that, you're probably better off writing a simple browser plugin that's installed on every machine anyway rather than having the machine download and then execute the code.

    On the open internet, I think it would probably be either a complete non-event or a security disaster.

  • The Grail [sourceforge.net] browser has python applets and has had them for many years (almost as long as Java applets have been out there). It even has a sandbox (or so the web site says, haven't looked too deeply myself). Rather than downloading a bytecode, it just downloads source code (a fairly clean approach). Now Jython [jython.org] or maybe even Parrot someday might be better ways of running Python applets but the Grail one is interesting at least as a historical footnote.

    Last time I tried Grail it wasn't really fast or reliable enough to be my main browser, but that was many versions ago.

  • The grail browser supports pythong plugins. It hasn't been supported in a while though but it was a fairly complete HTML 3.2 browser written in python and tk.


    It doesn't look like it would be too hard to make a new version of something like grail with pygtk and gtkhtml or maybe even mozilla.

  • A TCL plugin [demailly.com] exists, but that's about everything I know of it.

  • the browser-applet. as far as I know it did not make it, and I don't see many of them in cyberspace.

    followed by...

    I wondered why there never was a browser-plugin for languages like Python or Perl.

    Well, if applets aren't that useful in Java, it should be obvious that they aren't that useful in Python or Perl either. Try to imagine somebody at some company going to a VC with a business plan of "we're going to do something that will require the user to download a plugin and it will do the same thing Java does."

    I would like to hear about reasons why there is no effort to expand the capabilities of websites with language-plugins.

    There are now many languages for the JVM [tu-berlin.de]. There is a good chance that you can finagle your favorite language onto a JVM somehow. This is more work for the individual programmer, but it requires no effort on the part of users. Remember, when you put something on the web it has to be viewable by most users, otherwise it will just alientate them. When you get one of those boxes that asks you to download something just so you can view a website, how often do you click Yes?

    So, if [other language] had trumpted a platform neutral VM first we would probably be asking the same questions about [other language]. Java got there first and has established a huge installed base and name recognition, so until something comes along that just blows it away in terms of capability, programmer-friendliness, or installed base we are stuck with it. So far, MS CLR looks like the only thing that has a chance at doing that, and it is more friendly towards implementing a wide variety of languages than the JVM.

    The CLR/C# developers seem to have a thing for functional programming languages, so stuff like OCaml and Haskel (sp.?) could get a shot in the arm from C#.

  • "I would like to hear about reasons why there is no effort to expand the capabilities of websites with language-plugins"

    Probably because as a concept it just plain sucks. Why the hell do we need to add even more to our web browsers when what we have at present is already hugely bloated? Even Java applets almost go too far, but I suppose they make up the functionality that is needed and would only be duplicated by implementing even more client side scripting support.
  • Macromedia FLASH and its non-technical ways of giving a website rich multimedia.
  • The only reason the Java applets idea had a chance was that all browsers were going to support it, and even that didn't happen. Using an unusual plug-in which forces visitors to download and install a Python runtime and wrapper will quickly chase away everyone on your site. If you really need a rich GUI client-server app, there are plenty of better ways to do it than jamming it into a web browser. The browser is just excess baggage at that point.
  • I think others have already said it. This is 1) a bad idea, and 2) already implemented by Microsoft.

    The real trouble is that very few widely used operating systems can properly jail an executable. FreeBSD tries, but the jail [freebsd.org] facility in FreeBSD doesn't get used enough to establish that it's safe.

    NSA Linux [nsa.gov], which has mandatory security, is a big step in the right direction. A good exercise would be to make Mozilla run uner NSA Linux but insist that downloaded code run in an untrusted compartment, so it couldn't do much.

  • that is well, offtopic, but here goes.

    Smart bookmarks in Galeon allow you to search websites by inputting the search text in a text field from within a Galeon toolbar. This is quite cool for sites like Yahoo, but Amazon cannot be searched in this manner because it requires a FORM/POST method to search the Amazon site. Same for my fav website of all time, Digikey.

    Anyone know of a way around this?
  • "Couldn't there be a universal CORBA-like plugin for Mozilla to be used by most languages or such?"

    Right. Microsoft is so far ahead of Free Software in parasite hosting technology. Why can't Linux be a squirming mass of worms too?

    BTW, Java is the standard, is it? Funny that I don't have a single byte of it on any of my computers.
  • The new technology for client-side Java programs is Java Web Start [sun.com] (aka JNLP). It lets you add Java programs to your Web pages, but they're launched as applications in a separate window, not as embedded applets. But they still use the applet security model, so they're still safe to run.

    This fixes a lot of the problems that occur when you try to use applets to create real, useful programs (as opposed to little decorations, etc.) Many of these problems are caused by the conflicting requirements of trying to combine the Web world and the Java world in the same window.

  • Two reasons java applets didn't make it:

    1) Both Netscape and IE only supports an ancient version of java that nobody wants to work with. Writting an applet is a nightmare, nothing works like it is documented and you can't expect your code to work in other browsers than the one you are testing on. This would have been fixed years ago, but the first browser to use a recent JDK is Netscape 6.

    2) Applets can do almost nothing with the browser compared to javascript. This reduces the potential usefullness greatly. We could have had applets that worked like client side servlets, controlling a frame with ordinary HTML etc, replacing many of the more complex usages of javascript.

    If browsers used a recent JDK with usefull extensions like Java 3D available, maybe flash wouldn't have been that popular.

  • Web Client Language Plugins (Score:3, Interesting)

    by the eric conspiracy ( 20178 ) on Sunday September 23, 2001 @01:33PM (#2337863)
    I would like to hear about reasons why there is no effort to expand the capabilities of websites with language-plugins.

    Because the idea sucks. The place for code is on the server, not the client, for the following reasons:

    1. Security
    2. Compatability.
    3. Portability.
    4. Separation of presentation and logic.

    The only time where it is possible to put logic on a client and get reliable performance is where you have complete control of the client's software and hardware - i.e. a closed computing environment.

    That is NOT the web.

    • Separation of presentation and logic is good; what if the presentation is non-trivial? Do you want a server getting bogged down sending low-level instructions or generated images to clients? Do you want all presentation methods hard-coded into clients? Or might it be better to provide a way to specify complex presentation to clients, which is what Java does?

      Of course you can't guarantee performance on other people's hardware, but that's their problem. Making it your problem by assuming all of the load is just stupid. Equipment and bandwidth budgets are finite - a lesson learned to late by many other dot-bombs. If you only have X hardware and Y bandwidth, you can use client resources - via mobile code or otherwise - to serve more users than you can with the totally server-centric approach you suggest.

      Mobile code doesn't solve all problems, and it does create a few, but it's still a valuable part of the toolbox. If your control issues still prevent you from accepting that, see a therapist.

      • If your control issues still prevent you from accepting that, see a therapist.

        It isn't a matter of control, but reality. If you don't cater to the biggest audience possible, you are throwing away potential customers.

        This is why you don't see applets and flash on succesful e-commerce sites.

        • Designing for the largest possible audience is important, but that point really is not relevant to what we were discussing. I was addressing a specific technical issue: scalability of mobile or other client-based code as a vehicle for complex presentation, compared to the server-centric approach you suggested. In that context, the current situation is a mere historical artifact, inseparably tied to the newness of the technology and this week's performance parameters. It's extremely easy to imagine a world in which support for some form of mobile code is universal. It's also extremely easy to imagine a world in which even the most compact client can be assumed to have enough computational power to perform presentation tasks...not the whole application, just the presentation. In that world it would make absolutely no sense to load the server with presentation-related tasks, or the network with the associated extra traffic. That would be seen, rightly, as a stupid design.

          I would further say that the world I describe is not a distant one. It's practically upon us. If you were talking about deploying an application this week maybe your comments would have some merit, but in a general conversation that encompasses even something as close as next year your server-centric bias starts to seem rather pathological. None of the reasons you give for preferring server-side code really stand up to scrutiny; client-side code is going to become a more and more necessary part of serious distributed-application design whether you personally like it or not.

    • The only time where it is possible to put logic on a client and get reliable performance is where you have complete control of the client's software and hardware - i.e. a closed computing environment.

      I'd say that this is a fairly accurate descripion of the abstraction provided by a virtual machine for a language-- i.e. Java's JVM. While the JVM runs on many different hardware platforms, it provides a closed computing environment with a reasonably fixed set of APIs across all platforms it runs on. Performance (i.e. execution speed) does differ across the different speeds of the underlying host cpu, but this is also the case for natively compiled applications.

      As far as the four points you make go, I think they are all valid. Java (as an applet language) does a reasonable job of addressing the first three (security, compatability and portability). The fourth (separation of presentation and logic) is really up to the designer of the system to do in a sane way.
  • One of Macromedia's problems is they assumed the plug-in was the way to go because Flash worked out so well. But Flash was just that, Flash. Essentially vector graphics handling in a browser. It can be used to create complex and enchanting interfaces, but it's based on a set of standards that are already being incoorporated into newer browsers.
    Macromedia's product line can certainly do more than just vector graphics with paths and animations, but if you look at some of the more sophisticated tools in the product line, they required their own plug-ins and just never got good penetration because of end user hesitation to go for it.
    The plugins for higher level tools like Director and more so Authorware go way beyond the capabilites of a normal browser particularly in the sense that can they read and write and delete files as they please. And much more than that, they can execute remote system functions like shutdown reboot or add registry key. So, why didn't everybody download these plug-ins? They're free just like Flash plug-ins are. I think part of the answer is that these things give a browser powers that people don't want browsers to have and so they never get downloaded. If you can make it into the HTML specs, get in a browser, if not. . .
    This whole notion of letting the web turn into more than it is seems like it's the source of as many problems as it solves and it seems to be pushed by MS with this whole web sevices bullshit campaign. Fuck that, everything shouldn't happen on the web. Why does it have to be integrated into the browser instead of being its own application? All multitasking windowed computing environments allow multiple applcations to run at the same time. They can all use net bandwidth, why do they all have to be in a web browser?
  • 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

  • Grail was a browser written years ago in python + tk. Its features included python applets, that would be downloaded and run in a restricted execution mode in the browser. Not often mentioned, but python may have been the first 'applet'-capable language.

  • Smalltalk and Oberon have them... (Score:3, Informative)

    by RevAaron ( 125240 ) <revaaron AT hotmail DOT com> on Sunday September 23, 2001 @02:41PM (#2338030) Homepage
    Squeak Smalltalk has a plugin [squeakland.org] available for Linux, Mac, and Windows.


    Dolphin Smalltalk has a plugin [object-arts.com] as well. However, like Dolphin Smalltalk itself, it is Win32 only.


    One of the bigger, more business oriented Smalltalks, VisualWorks, also has a plugin [cincomsmalltalk.com]. 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 [uci.edu], 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.

  • 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.
  • The fact is that java applets sort of suck.. ever since Microsoft and Sun had their court battle, Microsoft started killing Java. If Microsoft does not support it many people stop using it. That is just the way it is.

    Well that is hot the only reason. Java applets do not perform the same way in all browsers. Each version of Netscape supports a different JVM. Even on different platforms, the same version of NEtscape did not support the same JVM. I tried this once and found my applet was different in IE on windows 95/98 and differnt on NT and different on LInux. Then mozilla is a different JVM, which crashes my browser, so I don't use it.

    There is also little reason to use applets. The only effective place I have seen a java applet was a chat application that was a trusted applet. Outside of trusted applets, you really cannot do a whole lot.

    I think the other reason is that they take to long to load on a page. I have only seen a few good applets.

    May your ass bleed profusely for every negitive moderation point this post gets!

    • 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.
  • ... you may as well use one of the most commonly installed one. Using Ming [opaque.net] you can generate Flash on the fly using PHP. Most popular plug-in + most popular scripting language = common sense to me!

    Phillip.
  • With Jython [jython.org] it is possible to make "Java" applets in Python [jython.org]. The first time you use a Jython applet, it downloads the Jython runtime which is slow. But it is much faster and more convenient than downloading a Java, Flash, Acrobat or ShockWave runtime, which many people do without complaint.

    Standard Python could also be used in Mozilla through XPCOM but you would have to be careful from a security point of view. You could only really run trusted code.

    • What code exactly are you going to trust? Without sandboxing you're left with the sort of security issues Microsoft gets bashed for ActiveX over. Also considering no one programs anything in "jython" for the client side it isn't more convenient then using Java or Shockwave which people actually use in the real world.

      • What code exactly are you going to trust? Without sandboxing you're left with the sort of security issues Microsoft gets bashed for ActiveX over.

        I don't really know what you are saying that is different than what I said. You should only use client-side Python with XPCOM under the same circumstances you would use Active-X: when you trust the code you are running. I don't know how to say it any more clearly.

        This isn't really a security "hole" anymore than RPM is. You should only use either when you trust the code you are installing with the permissions of the user you are running as. If you want to use Python in a client-side sandbox, you should use Jython.

        Also considering no one programs anything in "jython" for the client side it isn't more convenient then using Java or Shockwave which people actually use in the real world.

        The user asked about alternate languages to Java. Shockwave is not really a programming language and the embedded scripting language in it isn't really appropriate for many kinds of programs. I'm not sure why you are disparaging the existence of the option of Jython. If you personally don't have a project it is appropriate for, then just don't use it!

        -- Paul Prescod
        • I was confused as to what you meant by Jython because I had a bit of a muddled understanding of it. Thats why I was sort of disparaging the idea of it in general. I meantioned Shockwave not for it's amazing use for applets (since ther is none) but it is a popular method of creating interactivity over various media. It's one you can count on in alot of situations just like Java. One thing about Jython though is it seems like you end up on the short end of the stick using it instead of just using Java. It's sort of cool for turning your Pythod scripts into Java Servlets but I don't really imagine it being terribly useful in an environment where there is alot of random activity like in a client side applet. You're compiling to Java bytecode and all the syntax structure of the language just isn't designed for the use. Are there any Python scripts that have been turned into full fledged applets that are actually usable?

          • You're compiling to Java bytecode and all the syntax structure of the language just isn't designed for the use.

            Java wasn't designed for applets either. Java was largely designed for the Web was popularized. Jython applet/servlet code looks quite natural to me. In what sense do you think that the design does not fit?

            Are there any Python scripts that have been turned into full fledged applets that are actually usable?

            The goal is typically not to turn existing Python scripts into applets or servlets. Most often you want to benefit from Python's ease and speed of development while also leveraging the JVM's ubiquity. Many people just consider Python a much more productive language than Java and would prefer to use it.

            That said, Jython is much more often used as a scripting language for otherwise-Java applications (server side or desktop). The ability to use it directly for applets and servlets is just a side benefit.

            Paul Prescod

  • 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.

    • Java applets are also good for use in application hosting. If you build a bunch of applets that are going to replace some set of tools it's much easier just to write them in Java as you're able to run them on just about everything with no problem at all. Applix used to have a Java suite of their tools a couple years ago that worked pretty well IIRC.
  • There used to be a web-browser that did this with Python called Grail. It is now defunct, but you can see what's left of it at http://grail.sourceforge.net/.

  • I'm sure that once .net comes along IE will support running programs on the CLR, which has sandbox capabilities, much like the JVM. I know that Activestate has .net versions of perl and python, which should be able to run on a CLR-capable browser. With any luck the mono project can get incorporated into browsers such as Konqueror and Mozilla, so that we can have CLR-enabled browsing for everyone. I also hope that some platform-independant standard is developed for doing browser-based multimedia on CLR, but I'm less optimistic that that will happen.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close