Slashdot Mirror
Sun Debuts JavaFX As Alternative To AJAX
r7 writes "Internetnews is reporting on Sun's introduction of JavaFX at JavaOne today. Looks like a combination Applet, Flash, Javascript, and AJAX with a friendly programming interface. Does this really spell the end of AJAX? I sincerely hope so. Nothing built on Javascript will ever achieve the security, cross-platform reliability, and programmatic friendliness that Web 2.0 needs. Proprietary solutions and vendor lock-in are also dead ends. JavaFX has the potential to satisfy this opportunity even better than did Java over a decade ago. Along with AJAX, let's hope JavaFX also puts paid to Microsoft's viral Active-X and JScript, and, more importantly, that it really is a web scripting language that developers can grok."
It's the first instantiation that matters.. Applets are so uncommon that the average user will only come across them once per reboot.
Also, because of the most stupid thing Sun ever did, people tend to deliberately close the JVM after that first initiation. Why? Cause Sun puts a stupid little Java icon into the systray. It immediately draws attention to the fact that the JVM is in memory and people think they might get a speed boost or something by closing it. (Or something equally irrational that users think.) This was a pretty predictable result.. and the icon serves no purpose anyway, so why bother?
How we know is more important than what we know.
A demo of JavaFX (embedded in Java WebStart--yuck) can be found at http://blogs.sun.com/chrisoliver/ . Seeing as flash comes up instantly in browsers, even if it takes some time to download code, etc, and that web pages with ajax also render near instantly, I don't see how JavaFX is really going to appeal to end users. The JVM plugin still takes time to load on all browsers and platforms and is quite big. And on almost all browsers and platforms I've ever used, tends to lock up the browser for 10-20 seconds at a time. Further how will JavaFX integrate with HTML? Javascript?
.NET don't have these problems, mainly because flash is a fraction of the size of the entire JVM adn runtime, and .NET is always loaded and ready to go on windows.
.NET (mono notwithstanding). I really want to like Java, I really do.
Flash and
Anyway, given the current state of Java technology in the browser, I don't see this as being any different from WebStart, which everyone loves to hate because it is so clunky.
I dislike the idea of Silverlight entirely, particularly anything that relies on
If it means I can write web apps in a statically typed language that is compiled I'm all for it too.
How we know is more important than what we know.
It's the first instantiation that matters.. Applets are so uncommon that the average user will only come across them once per reboot.
And thus it really depends upon how this is used. If its used deep into a page say for something like an online word processor, where you know and expect to be waiting, versus a homepage which you expect to open instantly. Really its up to the developers to use it where it makes the most sense. Sadly few do.
If Sun is successful in releasing Java under the GPL, this could end up being an open source alternative to Flash/Flex and Silverlight. All three of them claim to be THE alternative to AJAX.
-1 Uncomfortable Truth
Actually, he was off by 100%. But that's beside the point.
.net didn't support, or worse when .net just didn't work and you had to dig into the javascript and html mess that your neat little .net app generates to find the problem and fix it.
:)
People may be annoyed by 2, 4 or even higher wait times, but they'll put up with them in the right circumstances without complaint.
Showing people a blank screen, not so much. Show them a progress bar, and they might wait for it; especially if it contains something they need.
The whole 'get it on the screen in 2 seconds or you've lost them' applies to online shopping, product reviews, forums, etc. But people are willing to wait 5-10 or even longer for their bank, their credit card, to file their taxes, to play a game, or to edit a spreadsheet. (As long as the 'start up time' is at START UP, and not after every click.)
If 'web2.0 apps' like gmail took 5-10 seconds to start up, but didn't exhibit the html/javascript flakeyness that would be worth it. And a lot of the load time could be addressed with caching, and having the VM preloaded, if that was the only stumbling block, hell they really are more *application* than *webpage* -- with some browser support they could be ready to go in the background, selected like wii channels or something, for commonly visited 'sites'.
AJAX is a mostly a train wreck on par with the spaghetti code that we inherited from the Basic/C/Cobol era. Html/javascript just wasn't designed for this sort of use. AJAX is like writing multithreaded real-time applications in Windows 3.0 or MacOS9 cooperative threading models... you can do it... and it can even mostly work most of the time if you don't bang on it too hard. But its never going to be great.
asp.net was a decent move forward, as at least it mostly shielded the developer from the ajax mess. Unless you needed to do something
But we *really* need to see a good standards based framework on the browser side, that applications can be written against.
Of course, we've always had Java and ActiveX. But Java was proprietary, and was hampered immensely by Microsofts attempts to discredit it, and embrace/extend/destroy it, including their own incompatible MSJVM, and "Visual J++" version of the language. Plus it was plagued by its own problems. Not to mention that the language itself I always found cumbersome. (I think Microsoft really did a good job with C# by comparison.) And ActiveX? Well, the less said about that plague on mankind the better.
JavaFX, at first blush, looks like it might fit the bill.
The difference here is that you're going to java.com, whereas the GP is going to java.sun.com (which is the first two hits on Google if you search for "java"). Incidentally, I never knew java.com existed until now: at some point I Googled for "java" when I needed a JRE, and once I somehow navigated the labyrinthine recesses of sun.java.com to download what I wanted - seriously, it's reminiscent of getting the free RealPlayer - I just bookmarked that page.
AJAX is an overused acronym. It doesn't do anything that you couldn't do with frames or popups anyways.
The limitation was never that the XMLHttpRequest object wasn't around. The limitation was that you had to deal with the realities of sending your pages over modems, creating this pressure for dynamic pages, but older computers were too slow at processing JavaScript to allow you relief by moving much display logic into the client. You'd end up locking the whole browser.
These problems are all dealt with now because of faster networks and faster computers. The tools in this area are just the same old shit with a shiny coat of paint for the most part.
-1 Uncomfortable Truth
My Glade point was a loose analogy. My point about XML UI was centered around Firefox and XUL (+ CSS + Javascript). So I am omitting your Glade bits from my reply because I don't think they pertain. Look at the contents of the jar files in the chrome directory from Firefox if you want a better idea of what I mean.
1 31423436&rl=1
The biggest issue is the underlying logic that controls the interface. For example, Cocoa allows for observers, which can be updated when state changes. Both Gtk+ and KDE do this as well (though they use the signal/slot terminology). Last time I remember looking at the Windows API, it instead used a callback method.
You can write listeners in Javascript. They are behind a good deal of the Firefox interface, iirc.
My main point is this: creating an interface in HTML is not an ideal medium. It doesn't provide many native elements, and creating large libraries to compensate this is hard. It is actually quite easy to imagine someone creating a platform that isn't done in an HTML page -- especially since Java already exists.
Take a look at:
http://www.phptr.com/bookstore/product.asp?isbn=0
It covers the whole XUL (which is *very* similar to HTML) + Javascript thing. It isn't that hard to set up most of what you describe. The real issue is that, like Motif or TK, the widgets available are still pretty unintelligent. Everything you need for a framework on a low level is there, however.
LedgerSMB: Open source Accounting/ERP
Because it lets you abstract easily and quickly. You don't have to worry about what type something is, you can interface with most everything the same way. In Java, this is dealt with by having a huge inheritance tree. If you want high-level behavior for a low-level class, you have to make sure it inherits all the way back up to class x, then write a method that takes the abstract class and operates on it. But half the time this still doesn't work (especially when the primitive types get involved.) So you end up with wrappers and the same object adhering to about 12 different interfaces just to use a *single* function. And don't get me started about how much of a pain it is to pass functions as arguments... In JavaScript, if I receive an object, I can just iterate over it to look at its properties - I don't even need to know what they are. I can construct functions on the fly, pass them in as arguments along with an object (that I just recently constructed, without any class definition), and have that function run on each property of the object. It's one step away from having first-class continuations. The apparent advantage of Java is having strict types - so if something adheres to an interface or abstract class, you just "know" it will have x,y,z and can do m and n. But very often (mostly sloppy programming), this isn't the case, so you have to check for things anyway. And why did you even try to pass in something that wasn't going to work with that function to begin with? In JavaScript, you have the flexibility to just pass it in. If it works, it works, if not - why did you pass it in? Ultimately, you still have to know what you're doing, so compile-time checks aren't really useful for catching more than typos. As far as I'm concerned, Java doesn't even come close to the power of JavaScript. Java likes big, bloated classes that are fixed at compile-time with LongNamesLikeThis. It has most of the drawbacks of C++ with almost none of the benefits. The only thing it has going for it is a huge API, but even that is so slow as to be useless for anything like graphics code. Heck, JavaScript is even more cross-platform than Java - and that's what Java was designed for! (Everything has a browser these days.) AJAX programming is weird, young, unpolished and tricky. But it already has more promise than a Java applet ever will. (Reserving judgement on this new JavaFX or whatever...but not holding my breath.)
Hellooooo everyone, the issue is not that historically the JVM takes forever to load or that Flash can be annoying. The key trend is that AJAX/Html are hitting a limit, which leads to all this recent energy about Flash/Flex as a better way to construct rich UIs, witness Microsoft's Silverlight.
... well gee it seems historically this has led the winning vendor treat us all like crap. That's a real bummer when you have this expensive time investment in your website, but it's locked in to some vendor's intellectual property. The only other open rich alternative -- SVG + Javascript -- appears a bit dead.
... that would be awesome. Even if the technology is just ok, the openness would make it worthwhile. Just think ... it could work properly on Linux and phones and what have you. This is very much like what happened with HTML originally. Just an ok spec, but the openness catalyzed all sorts of growth and competition.
Now both Flash and Silverlight are totally proprietary. That's a huge problem. If one of them were to "win" and get a zillion developers
So what's neat about this announcement, is that it's a Flash workalike that's OPEN SOURCE. If it were to "win"
Another way this could work out is that it bluffs Adobe into opening up Flash, which I figure would be just as good an outcome. The key is to not be stuck developing your expensive web app, but with some vendor controlling the underlying technology.
And the experienced engineer knows that cross-platform problems follow you everywhere. At some point you need to stop whining and get the work done. If we simply complained about the platform technologies all the time, there would be no POSIX programs, no Win32 programs, and a much smaller pool of good Java programs. Specs are specs, and they tend to get interpreted differently. As an experienced engineer you should have long ago learned how to normalize these differences rather than simply throw up your hands in frustration.
How does one answer this question? Of course you don't need Javascript for a "simple HTTP request". You need Javascript to dynamically modify the DOM, restyle the layout, respond to user input, and manage a less-than-simple HTTP request all at the same time. And like the "vealed calf" that I supposedly am, I've been finding that this design has many superior aspects when compared to a Java or Flash program. (Even though I'm actually supporting Flash with an AS2.0 version of the same APIs.)
Here's something for you to ponder. I am creating these APIs because the target environment does not support Java. It supports Flash and it supports advanced Javascripting. So like the "vealed calf", I am targeting the platform out of necessity. And you know what I've found? It's not actually as bad as everyone is making it out to be. The pitfalls are well documented and/or testable. Mostly minor cross-platform issues that will go away with each browser release. So it becomes quite easy to patch minor holes in the interim.
You know what we didn't have 10 years ago? An internet on which the vast majority of the world's population performed financial transactions. An internet that targeted your average consumer rather than business folk or hackers. An internet through which financial gain could be obtained by disrupting the normal flow of traffic.
You may be too young to remember when "Client/Server" was the latest hotness, but I remember it well. And I can tell you right now that we would have been no safer with those programs than we are with some of the moronic coders we have today. I just loved it when it was possible to telnet into a port and start executing commands before passing login credentials, because no one had ever tested the no-credential situation. All their code assumed that things happened in a certain order without ever verifying the case.
If you want to point a finger at the security problems of the web, then how about starting with yourself? Specifically, you and every programmer who writes software for the web. Computers Software is an engineering discipline just like any other. If you fail to apply proper engineering principles, you will fail. Those principles don't get learned overnight. They take years to cultivate and grow. Unfortunately, the industry wants fast answers and cheap programmers. They are rarely willing to pay for older programmers with strong skills to head up teams and ensure that the engineering is done right. Instead, they first try junior programmers, then outsourcing, then offshoring. All in an attempt to make a process cheaper by cutting corners.
You accuse me of trying to show off my "l33t"ness (whatever the hell that is). Well, how's this for "l33t"ness: A recent security advisory revealed that JSON objects were vulnerable to a cross-scripting exploit by the very nature of being serialized Javascript objects. It was mentioned that it was the first exploit that could target only AJAX-enabled applications. Well, I use JSON. And you know what I found when
Javascript + Nintendo DSi = DSiCade