Browser Bindings for Python, Perl, and other Languages? 239
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?"
Dunno about Mozilla.... (Score:1)
Re:Dunno about Mozilla.... (Score:2)
Not really a very good system. Java or one of the languages it copied was supposed to fix all that but it obviously never made much impact in real life (most good Java I've seen was server-side). Embedded scripting languages such as Javascript help and having a few more choices such as Python and client-side PHP/SQL would be nifty but it still doesn't really address all the issues.
A client-side multimedia-oriented scripting language would be really cool and would handle what most plugins do. Maybe one of these XML'ized mutlimedia standards or Shockwave or something could fit this bill if used right. Anyone know?
Semi-related question.. why don't DVD's use XHTML plus some built-in scripting languages rather than using Windows-only extented shit and butt ugly menus? A good multimedia scripting language would kickass on such a platform.
It exists on Windows: ActiveScripting (Score:4, Informative)
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
Re:It exists on Windows: ActiveScripting (Score:2)
I'm not trolling. It's a legitimate answer to the guys question. Like or not, the vast majority of people who browse most web pages are using Windows. So if you want to build scriptable web pages to target those users, you are going to have to target Windows.
If someone is interested in adding pluggable scripting functionality to other platforms, it would certainly benefit the runtime authors if they could use similar integration API's on each platform. ActiveScripting [microsoft.com] or AppleScripting [apple.com] (mentioned elsewhere in this thread) could be ported to *nix to become that API, and new languages could become cross platform more easily.
I'm platform agnostic. I'm also pragmatic, and I'd rather use something that already exists than have to re-invent the wheel.
Re:It exists on Windows: ActiveScripting (Score:2)
My experience has been that most of the script-related security problems on Windows are not the scripting language itself, nor the API that binds it to the browser. They were caused by poorly written COM objects which were then accessed via scripts. Even NIMDA, though it uses JavaScript to launch off a web page, is actually exploiting a hole in IE/Outlook express.
I worked for Internet Security Systems [iss.net] for four years, and wrote alot of the guts of their Intrusion Detection System, so I think I have a decent familiarity with the security issues here.
But maybe I missed something, feel free to explain what...
Re:It exists on Windows: ActiveScripting (Score:2)
I dislike Microsoft's business practices as much as the next guy. But if you want to convince me that one of their technologies has a problem you have to back it up with facts, not religious zealotry.
Tell Mulder and Scully I said HI, clearly you live somewhere in their fictional world.
Not much multimedia ability in Python or Perl (Score:2)
Re:Java as a client side web applet is dead! (Score:3, Interesting)
Or they're just cheap (Score:2)
Re:Or they're just cheap (Score:1)
Re:Or they're just cheap (Score:2)
Take a gander at what platforms shockwave/flash runs on [shockwave.com]. And with most browsers (except older netscapes, icky icky) downloading a plugin takes a few clicks.
Re:Or they're just cheap (Score:2)
so it should run anywhere ?
Re:Or they're just cheap (Score:2)
Re:Or they're just cheap (Score:1)
Re:Or they're just cheap (Score:1)
Re:Or they're just cheap (Score:2)
Re:Java as a client side web applet is dead! (Score:1)
Re:Java as a client side web applet is dead! (Score:3, Informative)
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.
Re:Java as a client side web applet is dead! (Score:2)
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
Multimedia is dead, not Java. (Score:2)
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.
Re:Not much multimedia ability in Python or Perl (Score:2)
security (Score:3, Interesting)
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
Re:security (Score:2)
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.
Re:security (Score:2)
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
Re:security (Score:2)
Re:security (Score:2)
thats why java has an OS independent sandbox.
Java doesn't have an OS independent sandbox, java is an OS.
Because it's hard (Score:2, Insightful)
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.
Sandboxes... (Score:2)
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.
Re:Sandboxes... (Score:2)
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:1)
Re:Sandboxes... (Score:2, Informative)
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? ...)
Java Applets. (Score:1)
Applets not entirely dead (Score:1)
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).
Re:Applets not entirely dead (Score:1)
No, it would not be better to use Flash instead of Java.
Java applets have two big advantages over plugins:
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
Re:Applets not entirely dead (Score:1)
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.
Re:does the java plug-in work on ie 6? (Score:2)
Sun now has a beta version of jdk1.3.1 (in their early access program) that replaces the MS vm entirely. It is an activex plugin and it will even run applets defined in applet tags.
If you go to www.javasoft.com/jdc and sign in (for free) you can download it. You'll notice that sun has put up a call to testers to test it with existing applets in order to find compatibility problems.
It works great with IE 6 and I haven't found any applets yet that I can't run. It's stable too, no crashes so far.
Re:Applets not entirely dead (Score:1)
perl applets? (Score:2)
<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
Re:perl applets? (Score:1)
http://www.focusresearch.com/gregor/psh/
Imagine that.
Re:perl applets? (Score:2)
Anyone know where I can get a program [gimp.org] to manipulate images of gnus?
Lol!
Re:perl applets? (Score:1)
ActiveScripting (Score:2, Informative)
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.
Re:ActiveScripting (Score:1)
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.
What about C/C++ Applets (Score:1)
Re:What about C/C++ Applets (Score:1)
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.
Re:What about C/C++ Applets (Score:2)
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)
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
Re:Basic Philosophical Difference (Score:1)
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.
Re:Basic Philosophical Difference (Score:1)
Re:Basic Philosophical Difference (Score:1)
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.
Re:Basic Philosophical Difference (Score:3, Informative)
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.
Re:Basic Philosophical Difference (Score:1)
.NET ~ java servlets
.NET !~ java applets / plugins
(well its a virus for sure)
but i dont think theres much in the way of
Re:Basic Philosophical Difference (Score:1)
Re:Basic Philosophical Difference (Score:2)
.NET is everything. VB.Net or C# can be used to develop client programs just as much as they can be used for web development.
You haven't heard of WinForms?
Quite wrong (Score:2)
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)
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.
Re:Jython (Score:1)
TCL (Score:5, Informative)
One Example (Score:3, Informative)
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.
Bean scripting framework anyone? (Score:1)
Re:Bean scripting framework anyone? (Score:1)
Restricted execution is the problem (Score:2)
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.
Re:Restricted execution is the problem (Score:1)
Considering that ActiveX allows everything else, I don't see why it couldn't run a
But grail *does* have python applets (Score:1)
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.
Grail supports Python applets (Score:1)
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.
TCL-plugin (Score:1)
You Answer Your Own Question (Score:2)
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#.
Crappy Idea (Score:1)
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.
What killed Java Applets? (Score:1)
Plug-ins are useless without 100% market share (Score:1)
Lack of a secure OS is the problem with this. (Score:2)
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.
One question (Score:2)
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?
Parasitology (Score:1)
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.
Java Web Start (Score:1)
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.
Poor browser integration (Score:1)
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)
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.
Re:Web Client Language Plugins (Score:2)
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.
Re:Web Client Language Plugins (Score:2)
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.
Re:Web Client Language Plugins (Score:2)
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.
Re:Web Client Language Plugins (Score:2)
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.
Plug-ins don't go over well anyway.. (Score:1)
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?
Re:Plug-ins don't go over well anyway.. (Score:2, Interesting)
It still stands that people don't want to download the plug-ins even though they're only a meg or so. That was my point. I'm not acusing these tools of being a security concern or saying security concerns are why they aren't downloaded, the fact is these plug-ins aren't downloaded by most users for whatever reason. The Flash plug-in was an anomaly because people are like fish and other creatures possessed of eyes and they like to see flashes of light. It was stupid human trick. Plug-ins as a solution suck. Browsers are already way overloaded and it's all MS's attempt to focus everything on the web because it's the one part of the net where buzinezz ownz ur azz.
Applets Were for UI, Now Better Choices (Score:2, Insightful)
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
Python has it -- see grail (Score:2)
Smalltalk and Oberon have them... (Score:3, Informative)
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.
Standard Virtual Machine (Score:2, Insightful)
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.
Java Applets sort of suck... (Score:2)
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!
Re:Java Applets sort of suck... (Score:2, Informative)
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.
If you are going to use a plug-in... (Score:2)
Phillip.
Jython (Score:2)
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.
Re:Jython (Score:2)
Re:Jython (Score:2)
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 PrescodRe:Jython (Score:2)
Re:Jython (Score:2)
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 PrescodJava applet == simple, secure, portable (Score:2, Informative)
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.
Re:Java applet == simple, secure, portable (Score:2)
Grail (Score:2)
.net has the answer? (Score:2)
Re:Java Applets are too Slow (Score:2)
Not exactly. The two major speed issues with running Java applications are:
Those issues aside, Java is actually a relatively quick language. Using such tricks as just-in-time compilation to native code (this is done as the bytecode is running, and uses various code profiling techniques), the speed of a java program can approach that of a natively compiled one.
Re:Java Applets are too Slow (Score:2)