Slashdot Mirror

Yes, in theory -- anyone else who has the GPL'd source can fork it.

Unfortunately, I can think of another case where this wasn't quite true -- ExtJS 3. For those who don't know the story, basically, they released ExtJS as LGPL, but then switched to GPLv3 ... and started making claims that no one else had ever heard (that you'd have to release all source code to your backend services for using their javascript toolkit, and there were questions of if users downloaded the javascript files, was that 'distribution') Due the the Sencha "interpretation" of LGPL, they then claimed the fork wasn't legal.

For more background:

• http://www.alittlemadness.com/2008/04/24/ext-discovers-step-2-of-the-slashdot-business-model/
• http://ajaxian.com/archives/openext-the-fork
• http://www.sencha.com/forum/showthread.php?33096-License-Change

... and after all of that badmouthing, it seems like they might've wised up, as they now list an 'Open Source License Exemption', so those of us using BSD, artistic, or GPL2 can use it. I guess I'll have to look to see if they're still claiming you have to release your server code:

• http://www.sencha.com/products/extjs/license/

Right, so they put a language designer (a theorist), a developers relations manager (a PR guy) and an infrastructure engineer (someone who talks wires and servers) to talk about front-end development. How about calling actual front-end engineers to talk about their craft? How about asking the guys behind the Aves game engine what can be done realistically with HTML5?

Wow! Flash is Turing Complete! Who woulda thunk it? Now if only it could be implemented in Javascript so as to also be unusable within another interpreted / bytecode environment....

I see you have a problem using google

Apple was stalling things for a while. Not sure about the whole story on this, what changed, when and how long it took for the IE team to get things done once the legal stuff was sorted out. Here is an original email form apple.

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-March/010129.html

and some background http://ajaxian.com/archives/microsoft-canvas-and-the-whatwg This is all several years old at this point. But this was an IE history lesson, not current events.

Hi Hellop,
Thanks for your corrections!

It was actually from my bookmarks. I've played quite a bit around with the canvas element myself, and that's why I've got a lot of bookmarks.
Sorry about the confusion about "library". English is not my first language, and in my language library can also mean "collection of", so that's why I used that word.

The 3rd link was actually not the link I intended to post, I intended to post a link to this HTML 5 Game engine (More info in this article) which looks pretty good. It's in beta though, and I've got no hands on experience with it, but it looks promising.

The link I posted is still valid though, and can be found here: http://tommysmind.com/ It might not be updated any more but it's still a nice resource, if you've just started using the canvas element.

No

Understandible. It can be hard to seperate HTML5 content from flash content these days. However, there is games popping up at a pretty constant rate. For example, look at these links:

• HTML 5 games library
• 10 HTML5 Games
• Canvas game library

Another thought: The HTML5 canvas element and Java's AWT "Graphics" element are very alike. I wonder how long it takes for someone to program a converter, so all java applet/mobile games are available as HTML5 games?

Since Firefox 3.1, it's javascript engine does the same (it compiles the code on the fly to native code). "We have, right now, x86, x86-64, and ARM support in TraceMonkey." [1]

I don't know about how chrome handles this, but firefox will still interpret the javascript code for the parts of the code that it hasn't generated native code for.

[1] http://ajaxian.com/archives/javascript-jit-the-dream-gets-closer-in-firefox

If I was to say my biggest greatest annoyance with Linux, it's media plugins and flash in particular. If only Firefox would stop being so patent-freaky and decode H.264 when it is available then we could kill flash and live happily ever after. *buntu seem perfectly capable of shipping a video player that'll use the x264 codec if installed, so should Firefox.

Can they send the bill to you when the lawsuit hits?

If only Firefox would stop being so patent-freaky and decode H.264

There is a reason they, and lots of others, in the IT industry are 'so patent-freaky'. Might have something to do with all the patent litigation thats continuously going on...

If they distributed FF with H264 playback, they'd be violating the law, because they haven't paid MPEGLA their blood money. This isn't being 'freaky', its merely behaving sanely in an insane world.

when it is available

Apple has no problem using H264, since they've got the money to pay the royalties, and they don't need to worry about violating the GPL (since they don't use it)... never mind that some of those H264 patents are their *own* anyway. Did you know that Apple gets part of the H264 royalties thats collected by MPEGLA?

No, its pretty darn clear why Apple would love for H264 to win and any open alternatives, that they won't either be able to control nor make money on, fail...

*buntu seem perfectly capable of shipping a video player that'll use the x264 codec if installed

Which is not the same thing as shipping a video player with H264 builtin and active, which not even Canonical can do.

Secondly, making FF work with existing codecs on a user's system... kinda requires intimate knowledge of that user's system. Now the FF package distributed by Canonical obviously has that info for their own distro, but Mozilla, after all, isn't a distro maker, so as long the MPEGLA stranglehold continues, it'll be up to the distros and the users themselves to 'solve' the problem.

Here's my take on Linux support: Not that long ago, I'd have to chase high and low to find any Linux compatible hardware and certain things like wireless cards was near impossible. These days I have no problems finding Linux-compatible hardware, even though not all or even most hardware is compatible with Linux. There's usually some well-supported official drivers in most categories instead of the "best of the reverse engneered" there used to be. I don't remember this machine having a kernel panic ever, though X did have an oops a month ago because I've upgraded to a beta KDE/X release.

If I was to say my biggest greatest annoyance with Linux, it's media plugins and flash in particular. If only Firefox would stop being so patent-freaky and decode H.264 when it is available then we could kill flash and live happily ever after. *buntu seem perfectly capable of shipping a video player that'll use the x264 codec if installed, so should Firefox.

This whole thing should be very embarrassing for Microsoft... but apparently it isn't. Microsoft is co-sponsoring a conference about SVG, which is being held in Google's Mountain View complex, of all places. That in itself is disturbing enough, but to think that the one company that's prevented SVG from gaining traction on the web is now pretending to be interested in SVG (as opposed to promoting their Silverlight tool as the only *real* solution) is, excuse me, fucked up.

If they really want to help the advancement of SVG, they should finally release a browser which implements it natively. Apparently every other browser vendor can do it. For IE, at the moment, we have to rely on a fragile JavaScript/Flash workaround provided by Google.

I'm really not ranting about Microsoft just for the fun of it; I'm usually pragmatic, bordering on stoic. But I (like many others here) have spent weeks and months trying to work around Microsoft products' shortcomings, and this kind of hypocrisy is making me angry.

CJ

I prefer a javascript assembler

There is already a Ruby VM that runs in a browser: Hotruby : http://hotruby.yukoba.jp/

John Resig even blogged about it ages ago: http://ejohn.org/blog/ruby-vm-in-javascript/

Also, JS.class, while not a Ruby VM, is pretty cool and actually useful: http://blog.jcoglan.com/2009/06/08/jsclass-21-an-improved-pacakge-manager-proper-hashes-and-lots-of-ruby-19-goodness/ - http://ajaxian.com/archives/jsclass-21-released

A common comparison that has been made is that WebGL would be used like Canvas whereas O3D would be more like SVG. (WebGL will be *part* of canvas, of course, but I mean in terms of uses and applications)

If you want links to many discussions about the approaches and comparisons, check out this page.

Since canvas is already known territory (comparatively), and JavaScript is being optimized like crazy by all browser developers, I'd bet that you should expect to see WebGL picked up much faster than O3D. Developers that are already comfortable using canvas for some 2D representations will have only a small step to take to reach WebGL.

More control for one. Flash is essentially a self contained program running in your browser. HTML5 will allow things like audio volume per tab, or per domain, more interaction between the page itself, the content, and the user.

The fact it's self-contained doesn't mean it's isolated from the page. It's in fact a benefit, because it quickly becomes a burden to serve your app as a hundred of tiny images and js files. The "minification" and "sprite" techniques the community is forced to use in JS/HTML/CSS apps, are tedious, limited and just a poor-man's compilation technique, a sign that in practice a compressed one-off-download container is the better choice for web apps.

There is also fast two-way connection between JS and Flash that works in all browsers today. Anything the browser provides as settings and per-tab controls and so on, which is accessible to JavaScript/DOM, is accessible to Flash as well. As an example of this feature in action, you can see the HTML5 features like canvas and SVG implemented transparently via Flash. You can also use most of the essential Flash features directly from JavaScript with libraries like Aflax.

Here's a fantastic example of the sorts of things this'll make possible, which simply can't be done with flash: http://www.double.co.nz/video_test/video.svg [double.co.nz]

Would you care to elaborate what is in that demo that Flash can't easily top today. I see scalable rotatable rectangles with transluccent video in them. Nothing Flash couldn't do few years ago. Today, in Flash you can also map videos like that on waving flags in 3D space or have full-blown alpha mask for dynamic compositing, if you wish. I shouldn't need to mention also that Flash provides consistent codec support (including H264/AAC) on all platforms and browsers in turns on, today. All this while even non-MS browser makers can't agree on a common codec to use (let alone Microsoft joining them any time soon).

You have true 3D engines with shader support or full-blown music synthesis and sequencing applications built directly on top of the flash platform.

All in all, most arguments against Flash I've seen, are arguments out of ignorance and bias. I would be the first to call out a poor use of Flash when I see one, but it works the other way too. In the end, can't we have both instead of either? Who stands to win by "eliminating" either option when they both fill different, though partially overlapping roles?

http://ajaxian.com/archives/canvas-reflectionjs

Or canvas reflection?

I am 99.999999999999999999999999999999999% sure that his name is supposed to be typed as Ryu Sung-tae (Sung, not Sunt; there is not in my studies of Korean some such name, given, or family...). Besides, g and t on the US / Latin keyboard are adjacent, and all the more this seems to be a typo. If it was a phone interview, with the interviewer making corrections, it's then even possible that his name is Seung, not Sung, as in the director http://www.koreanfilm.org/films2008.html Ryu Seung-jin.

Unfortunately, it appears the opensource site seems to have it wrong. But, *i* could be wrong, so maybe you can e-mail him and ask him if his name is actually misspelled on the site.

For those not aware, the "WI" as in wizard or whiskey in the US/English speakign areas is written in Korean charactes that look in English like "oi", but pronounced making for it to look like "uh-wee-zard". So, it's neat/nifty a spin to have UI and Wi merged for UIzard, instead of just using Wizard....

Just my two cents...

Oh, Ajaxjian Link:

http://ajaxian.com/archives/uizard-a-web-mashup-generator-written-in-yui

DZone link:

http://www.dzone.com/links/uizard_a_web_mashup_generator_written_in_yui.html

And another, unrelated item:
http://technews.am/conversations/ajaxian/uizard_a_web_mashup_generator_written_in_yui
http://technews.am/conversations/ajaxian/3d_cube_using_new_css_transformations

As a developer of an AJAX-based web framework, I'm upset to see IE8 being thrown out the door so quickly. RC1 was nothing short of a disaster: it had a performance bug where nesting absolute-positioned DIVs would result in exponential performance decreases.

Test case here: http://echo.nextapp.com/content/test/ie8/

The 25-nested DIV test would require killing the browser. Nesting absolutely positioned DIVs is somewhat fundamental to delivering application-style user interface layouts in a web browser.

I reported this bug everywhere I could, and Microsoft actually did a great job in responding to it. They say they've found it and fixed it. But there is no way for us to test this. We must simply take their word for it and wait. They're going from RC1 to final, and begging and pleading for an interim build didn't warrant much of a response.

From reading forums (e.g. Ajaxian: http://ajaxian.com/archives/push-back-digital-tv-or-ie-8), my IE8 experience is not uncommon with other web frameworks as well. The average developer's opinion there suggests RC1 is nowhere near ready for a final release. Every build of IE8 (beta1, beta2, win 7's "beta2+", and the RC) have each had major unique problems not found in other releases.

I have developers asking me if their software will work in IE8 on day 1 and the only honest answer is "I have absolutely no idea." Anyone (without a final build) who tells you otherwise, even offerring a rough estimate, is a liar, IMHO.

I don't understand the point of putting out a "release candidate" and then not using feedback to determine whether the next release is a "candidate" or a "final". Our bug alone means that IE8 RC1 has never been publicly tested with many complex web-based applications.

When you put together a complete test suite, it's possible that both browsers score around the same -- just saying..

I understand what you're trying to get at, but it's simply not correct. Take DOM2 support for example. IE8 is missing the ENTIRE Events section of the standard. In fact, most of DOM2 is MIA. That's a rather massive hole right there. And if you go through the list of items I posted above, you can find how many of the bugs they documented went unfixed in IE8.

You know the most frustrating part about the lack of DOM2 Events support? Microsoft closed the bug on DOM 2 Events with "Closed (By Design)". BY DESIGN?!?! What the--?

Worse yet, Microsoft ventured into HTML5 territory with IE8 but decided to pay it little more than lip service. The comments I've seen on the WHATWG list have them pushing proprietary extensions that would already be covered if they'd just implement the entire part of that spec! (e.g. They implement local storage, then attempt to include a transaction model for it. All while ignoring the part of the storage spec for local, transactional database storage.) Somehow Microsoft is attempting to implement various events features from HTML5 without supporting DOM2 Events. How in the world can they suggest that such broken implementations would even be close to the spec if their event system is wrong? (Closed "by design" remember!)

Interestingly, Microsoft has also seen fit to ignore the most implemented part of the HTML5 standard: The CANVAS tag. Internet Explorer thus remains the only web browser with no Canvas support.

These features that Microsoft is ignoring are the very foundations of modern web browsers. Without them, web developers have to work on a variety of workarounds to make their sites work with IE. Embrace, Extend, Extinguish is the name of the game.

That's a little strong, to say the least. It works, it's fast, it's feature rich, and it's secure.

I posted a link above so that you could understand how BROKEN IE is. Why don't you take a tour and see how broken it is? Or more to the point, take a look at my sig. The game in it is a real-world application that is written to the standards. With no special work, the game worked in Opera, FireFox, Chrome, and Safari. If I had another standards compliant browser to throw at it, I'm sure it would work as well.

Yet nearly every feature it needs to operate is not supported by any version of Internet Explorer. No canvas, no DOM 2 Events, no Opacity (also "Closed (By Design)"), NUTH-ING. It simply will not operate in IE8.

I have the technology to patch IE8 at runtime. A Java Applet with a LiveConnect interface, a wrapper around Microsoft's event system, conditional use of opacity, it could all be made to work. But the God's honest truth is that I simply don't want to. Microsoft's piss-poor attitude toward developers has finally caught up with them. From the day I saw their blasted "closed by design" bug, I decided that it's simply not worth investing the effort in Microsoft any longer. Microsoft refuses to invest in their customers, so they can burn for all I care.

Apologies if I'm getting a bit melodramatic, but your comment about IE8 being "feature rich" is a bit of a trigger for me. As a web developer I have patiently worked around IE for the better part of a decade. I figured that support for the (OVER!) decade-old W3C standards would eventually arrive in future IE versions. But first Microsoft ignored pleas in their IE7 development. That was somewhat ok. They were just getting started again. IE8 was supposed to be the big standards fix'em up. Microsoft promised the development community upside down and backwards that IE8 would be the most standards compliant browser yet. In fact, they advertise I

Both IE6 and IE7 leak memory even after you close the page. Most well known Ajax apps don't leak memory because they have spent plenty of man-hours working through the problems and designing the libraries around the issues by using leak detection tools. I personally have spent weeks and weeks resolving leaks.

Stability? You what?! It bloody crashes all the time. Their own web outlook client completely crashes IE regularly (and no, I am not talking about ActiveX plugins crashing IE - I have been forces to implement many hacks to work around plenty of horrid crashes in IE.)

On second thought perhaps you have just trolled me - although I try not to underestimate an IE user.

Both IE6 and IE7 leak memory even after you close the page. Most well known Ajax apps don't leak memory because they have spent plenty of man-hours working through the problems and designing the libraries around the issues by using leak detection tools. I personally have spent weeks and weeks resolving leaks.

Stability? You what?! It bloody crashes all the time. Their own web outlook client completely crashes IE regularly (and no, I am not talking about ActiveX plugins crashing IE - I have been forces to implement many hacks to work around plenty of horrid crashes in IE.)

On second thought perhaps you have just trolled me - although I try not to underestimate an IE user.

Er. More like...

KDE's Webkit which trails behind Apple's, but is "stable" in that it's not a moving target, it's simply not as up to date.

Apple's Webkit which trails its internal builds by anywhere from months to years.

Google's Webkit which could be anywhere from two months newer to two months older than Apple's, and demonstrates that no such proprietary hacking is necessary to get ActiveX to work.

MS's Webkit which would probably be a direct copy of Google's, with a hack to require all sorts of extraneous metadata to turn it on. MS won't do any other hacking because they believe it is not possible to do.

ActiveX can't be done by another plugin - the browser has to parse it and host the AX objects. Doing that kind of scale changes to Webkit would fork the code, and I'm not convinced the web would benefit. - Chris Wilson, Platform Architect of the Internet Explorer Platform team at Microsoft (and ex-Group Program Manager)

Would MS still be interested in hosting ActiveX controls in the browser, though? Might be that MS has more of an interest in pushing people over to whatever .net equivalent might exist...

That said, I'm sure MS wouldn't try to kill an existing technology... I can barely remember FoxPro... J#... XP....

I'm just glad I made the switch away from MS a couple of years ago... My "grep", my "C++" and my "Linux" ain't goin nowhere - which is good, cause they kinda just works.

Er. More like...

KDE's Webkit which trails behind Apple's, but is "stable" in that it's not a moving target, it's simply not as up to date.

Apple's Webkit which trails its internal builds by anywhere from months to years.

Google's Webkit which could be anywhere from two months newer to two months older than Apple's, and demonstrates that no such proprietary hacking is necessary to get ActiveX to work.

MS's Webkit which would probably be a direct copy of Google's, with a hack to require all sorts of extraneous metadata to turn it on. MS won't do any other hacking because they believe it is not possible to do.

ActiveX can't be done by another plugin - the browser has to parse it and host the AX objects. Doing that kind of scale changes to Webkit would fork the code, and I'm not convinced the web would benefit. - Chris Wilson, Platform Architect of the Internet Explorer Platform team at Microsoft (and ex-Group Program Manager)

Great idea when over 50% of deployed web browsers can't render SVG at all.

So there is no version of Flash that is open source then?

Actually, a month or two ago, Adobe started the Open Screen project. While this isn't an open source flash per-se, it does open up the chance for people to start working on a better port of Flash to Linux. So for anyone complaining about Linux on Flash: patches welcome.

Yahoo isn't interested - give it up MS!
They don't want to tarnish their good name.

They've pretty much already done that on their own. I used to use yahoo for services, google for search. Yahoo maps *used* to be the best mapping app out there, but then google outdid them. At that point in time, I still used Yahoo for movies and tv listings. They screwed those up horribly, and Google did better with their movie listings.

Yahoo was on top. They became complacent. Then in an effort to 'catch up' they alienated their user-base by releasing unusable crap.

Slapping a "no commercial use" clause on LGPL isn't possible, at least not while claiming that the project is licensed under the LGPL.

They didn't claim that. They claimed it was "licensed under the terms of the LGPL" for non-commercial projects, claiming a distinction between that and actually licensing it under the LGPL. Of course, that was complete nonsense too, as the terms of the LGPL include such things as stripping additional requirements and redistributing under the terms of the LGPL, neither of which they claim are legal. Once everybody pointed and laughed at them for this idiocy, they came up with their unique interpretation of the GPL that just coincidentally is not viable for most of the people their commercial license is aimed at, and switched to that.

In fact, people have attempted to fork the last "LGPL-terms-licensed" version of ExtJS, and the ExtJS team have claimed that it is illegal. Apparently whatever the ExtJS team think the terms of the LGPL are, they preclude forking.

Like I said in another post, the ExtJS team just don't want open source. They pretend to be open-source to gain mind-share, and then pull the rug out from under you when you attempt to use it as such. Consider this post on the lead developer's blog. He quite clearly doesn't want ExtJS to be open-source:

At this time I contemplated switching to a strictly commercial framework. I openly discussed this decision with the community in the Ext forums.

In the end, after much discussion with the community, I decided to go to the LGPL.

Basically, he wanted strictly commercial, but realised everybody would abandon ExtJS if he did so overtly.

Shortly before 1.0 is released, there numerous Ext "clones" started popping up that were hacking Ext themes, css and other resources from 1.0 - before we had even released 1.0. Here I had 4 new themes for Ext JS 1.0 that I had spent countless hours working on (I am not a great designer) and what could now be considered competitors were already using it before I even have a chance to release Ext 1.0.

That's why the proprietary license on the "Assets" (CSS and images) was introduced in Ext 1.0.

If you get pissed off because people (yes, even competitors) copy your stuff, then open-source isn't for you.

Ext JS 1.0 is released under the LGPL, minus the Assets license as mentioned above. Shortly thereafter 2 major publicly traded corporations (names withheld) embedded Ext JS into their development frameworks. With no mention of Ext JS except in credits files that no one ever saw. No support for all the work that had been put into the framework. Neither one of them even contacted us.

If you want people who distribute your code to "support" you, or if you want people who distribute your code to contact you first to ask permission, then open source isn't for you.

How can that be possible? Can they do that?

Of course they can! Is this guy even remotely familiar with open-source, or is it just a buzzword to him?

How can we compete with them taking such a large chunk of our potential customers?

And that is what the ExtJS license shenanigans are all about. They want all the benefits of open-source development, but none of those pesky developers copying code without paying for it.

One site covering this noted plans to 'stay up to date with the most recent bug fixes' of the hosted libraries -- this sounds like blindly upgrading the hosted libraries to new versions, which is a very bad idea.

As a commenter there noted, it's a much better idea to use version-specific URIs, allowing users to choose the versions they wish to use -- otherwise version mismatches will occur between user apps and the Google-hosted libs, creating bugs and the classic 'dependency hell' that would be familiar to anyone who remembers the days of 'DLL hell'.

I'm hoping that they bring forward Tamarin support in Firefox. Any chance of getting fast javascript before Firefox 4?

Firefox 3 will pass the acid 2 test. You can try a nightly build if your curious and flame me later if it's currently broken. I believe Firefox 1.0 through 2.0 used the same Gecko branch (1.8?) which was why there weren't very many display changes between the browser versions. Firefox 3 will use Gecko 1.9.

Heh, that's funny. I like the part about the tricycle.

Unfortunately, your post is completely void of any actual content to respond to so let me just say this. Sometimes you don't want to be stuck with the space shuttle - its old 70s technology that is being retired.

Turns out you actually get more when you dump the old crufty architecture and start with a clean slate:

Acid 2 support (back in April 2005)
http://en.wikipedia.org/wiki/Acid2

Mobile support
Safari has a code base that is small and fast enough to be used in Apple's iPhone, Google's Android and Nokia's S60 series phones.
Nokia funded Minmo for years and realized that they couldn't get the bloat out of Gecko and moved to WebKit. Google is a huge supporter of Firefox and I'm sure they had some strong technical reasons for doing so.

CSS3 support that Firefox should be jealous of:
http://ajaxian.com/archives/safari-3-and-css-3

HTML5 Client-side Database storage with SQL
http://webkit.org/blog/126/webkit-does-html5-client-side-database-storage/

HTML5 Media support
http://webkit.org/blog/140/html5-media-support/

CSS Animation
http://webkit.org/blog/138/css-animation/

CSS Transforms
http://webkit.org/blog/130/css-transforms/

There is lots more info over at http://webkit.org/ and http://webkit.org/blog/ the website for Safari's open source engine.

Don't get me wrong Firefox has some great stuff too. I think its great to have as many people pushing for an open web as we can get. If you want to actually have a conversation with like, content, and stuff I'd love to hear why you're such a Firefox fan.

Till then I'm going to be having fun on my tricycle. Be careful on that 'ol shuttle.

    -cj

It's not that they're necessarily bad, but that they pack in dozens of features that you don't necessarily need (potentially bloating the size of your page download by tens to hundreds of K) or even want.

If you're doing a complex website, you'll probably be better off with a custom library for now.

Some of the open source JavaScript toolkits can be used to draw charts on a browser window with inline SVG and VML. This makes it possible to draw charts on the web browser instead of having the web server draw them.

Some examples:
Dojo Toolkit
I think I've seen a live charting demo on Dojo's official website, but it seems to be no longer there.

WT Toolkit
This one seems to be a new project, judging from the activity charts on their SourceForge page. The way they can draw 3D charts (like, pie charts, 3D bar charts) with inline SVG and VML is quite amazing though.

Web apps tend to be far more susceptible to failure than traditional desktop-based applications. This is a widely known fact, that many people have written about. Here are a few such articles talking about when web apps go bad:

7 More Reasons Why Web Apps Fail

What's The Worst Web Application You've Ever Seen?

Web 2.0: A serious case of diarRIA.

AOL's AIM Today Beta: When Good Web Apps Go Bad

Web apps remain a trouble spot

Web apps ready for MySQL 5?

Technorati listed a lot more articles beyond those. So it's safe to say that web apps just don't offer the quality and reliability we'd expect from even the lousiest of desktop apps. At least when a desktop app fails, you usually are able to try to recover your data on your own, from files stored on your own system. But that's not something you can do with web apps. You'll just have to hope and pray that whoever manages the web app that just failed is able to recover your information.

Well in the nightly Webkit builds the javascript engine has been overhauled, so chances are it's "already" fixed, in a sense. Up until now it's looked like Apple's been prepping that for a Leopard release, but maybe this will prompt them to move it up.

By the way, those Webkit nightlies are really looking strong.

You don't even have to wait.

Firefox 2.x supports DOM:Storage objects that will already let you store arbitrary data client-side, and IE supports something similar with Persistence and DHTML Behaviors. If you want the same mechanism for multiple browser types you can do some crazy Flash-based stuff as well.

Within the browser storage objects there are some limitations as to size, so that could be part of the new versions. But make no mistake: this feature is already a reality. See Ajaxian or Dojo for more of the same, including concrete implementations.

My first thought was, "Is Google Web Toolkit prior art or infringement?" After a bit of looking around, it seems this patent was filed on September 5, 2006 while GWT 1.0 was released in May 2006. Sorry Morfik, but your patent is invalid. (Thank God, too. This patent appears to be overreaching and far too broad. It could prevent an entire industry from developing.)

All I can say is: where was your due diligence, Morfik? It doesn't make a whole lot of sense to spend time and money on filing a patent that will be useless to you after it's granted. The best they could do is scare a few Open Source projects into submission. Anyone with a vested interest in the technology is going to do the due diligence that Morfik didn't, and take the matter to court.

The only "out" they have available is to show evidence that they disclosed the inner workings of their JST product prior to GWT being released. In which case they might have protection from the "one year to file" rule. Maybe. Or maybe they're just trying to carry out this threat in a laughably oversimplified fashion. (They're lawyers must be telling them it won't work?) Go figure.

For those who are unaware of what GWT is, it's basically a toolkit that takes Java programs and converts them down to Javascript. By coding Java to the GWT toolkit*, you gain all the benefits of the Java compiler and type checking without sacrificing the ability to deploy on browsers that do not have Java installed. I'd rather code in Javascript myself, but it has its place. :)

There is a poker ajax game. Ryan Dewsbury has written a multiplayer ajax poker application written with GWT. The front end is written with Java which the google web toolkit compiles to javascript.

From the article: "The only thing AJAX is are a set of extremely important best practices and patterns developers use to create compelling web clients. Why can't JEE be more AJAX like?"

I still see many of the best practices in AJAX being fleshed out in the year(s) to come. Hopefully things like Comet will become a reality in the near future and the many different toolkits/utilities (dojo, dwr, jmaki, et al) can continue to mature and make the development of AJAX apps faster, easier, and more reliable but the current amount of hacks required to get any decent app working in all the various browsers is just downright fustrating. J2EE has its own set of best practices which I dare say are much more tried and tested than most of those for AJAX. But in some cases best practices are easier to lay down for JEE as all things JEE must be "blessed" by the JCP/Sun so you have a "standard" target. This can be a good and bad thing and the article does touch on those points.

I think system engineers have become to realize that you don't need EJBs and all its baggage to solve every problem and that some problems can be solved by lighter weight solutions, but when you need atomic distributed transactions, fail over, horizontal and vertical scaling, and all that other enterprise jazz what are the current alternatives?

Like always (well mostly anyway), the good engineers/developers who are "free" to do their jobs will find the right mix of technologies from AJAX and JEE (or something else) to solve their given problem(s) despite what the industry tries to shove down their throats.

Interesting idea - Lingr is the coolest implementation I've seen so far. Super-realtime chat. Much less latency than normal Ajax-only chat

http://ajaxian.com/archives/slashdot-having-cows-o ver-ajax

Ouch. Adding a script tag dynamically is old hat in Ajax. See the DOM Based On-Demand Javascript pattern.

In fact, there are a number of project under way that use dynamic script injection to emulate cross-domain XHR. See http://ajaxian.com/archives/jsonp-json-with-paddin g

But worse yet, the argument that developing web applications with Ajax is hard is a straw man. Imagine you had to design a desktop GUI by twiddling with the screen bits directly or, worse yet, implementing application logic in the graphics controller. Blech!

That's the situation with Ajax and webapps right now: writing code in the wrong places and at the wrong level of abstraction.

If you want to simplify how you write webapps using Ajax, try a server side framework like Echo2 or ZK. These allow you to write webapps much like a desktop GUI while working in only one language context -- Java on the Server side.

Why is it so important to you?

Because, as I already said, JavaScript is not a compiled language. Convience methods are strictly convenient for the programmer, not for the person on the other end of the pipe who's actually using the program. They couldn't give two shits if you saved yourself from future RSI. Because it's not a compiled langauge, convenience methods come at a cost of execution speed. Which means every cutesy $() or A() function is slowing down your user's environment. A lot? No, of course not. But it adds up. And that's the problem with these libraries: a series of steps to make JavaScript appear--at least to the programmer--like a real programming langauge (getters and setters, classical inheritance, etc.). But these are abstractions that offer no real benefit, just useless cycle overhead on the client's machine.

Anyway, if you're manipulating hundreds of elements every second and are concerned about the overhead of the $ method, perhaps javascript or even a web app is not for you. In fact, maybe it isn't regardless.

One doesn't have to be manipulating hundreds of elements every second to see a performance hit. And I don't even understand the last part--why wouldn't a web app be for me because I care about performance? You wouldn't happen to work in Redmond, would you?

I think you might be talking about "Comet"

Yes, there are ugly hacks to keep a connection alive, but it is exactly that, a hack, and introduces problems of it's own.

There are some ugly hacks to allow the server to "push" to the client (embedded flash objects, never-closed-connections, etc.)--mostly encapsulated by the moniker COMET (get it? Ajax... Comet...)

But if you get to pick your app server, there are some ready-made solutions. The problem with traditional web servers is their IO method. It's not their fault that the HTTP spec is out-of-date, but there are already new developments on the horizon that get around the current limitations. Take a look at GlassFish, Sun's new open-source enterprise application server, and pay particular attention to NIO socket writes. The performance benefits of NIO over straight IO are astonishing, with the side-benefit that it supports server-push out-of-the-box.

You don't have to poll with Ajax/HTTP - you can keep a connection open: http://www.ajaxian.com/archives/comet-a-new-approa ch-to-ajax-applications

The issue is that existing web server frameworks generally don't support keeping connections open to clients, or perhaps they just can't scale if they do.

Of course, this technique is yet another hack (like most everything in the browser world ;) but it does work.

Try TIBCO General Interface: http://ajaxian.com/archives/tibco-general-interfac e-version-31-professional-edition-released

It was developed using AJAX. It's the most cool AJAX application (Yes, I mean it's better than Google map).

The article linked to in the top level post is a cleverly crafted imitation of Jakob Nielson's original frames discussion. It is made to look like Jacob Nielson's work, which it isn't.

On his home page, Jakob Nielson specifically states that.

Even the sites that reported about the Nielson 'Alertbox about AJAX' have now realized they were hoodwinked.

It must very much suck for Nielson to have other people imitate him, to the point where it is difficult to distinguish his viewpoint from the imitations. Chris McEvoy, the author of the spoof, goes on to both apologize and gloat over the success of his prank.