Slashdot Mirror
The Future of Rich Internet Applications
Can't Get Enough Ajax writes "While Ajax continues to get most of the attention these days in the space of rich Internet apps, the future 'face' of Web applications may consist of a combination of Ajax and plug-in technologies based on the new Flash development platforms or other plug-in models. Why? The challenges of building and maintaining sophisticated software in Javascript and the lack of support for audio and video are just two reasons that any RIA strategy will involve a mixture of Ajax and one or more technologies like Flex, Laszlo, or others. But while there are significant advantages to the new RIA technologies, there are also important trade-offs including breaking the model of the Web, lack of HTML support, and more. ZDNet's Dion Hinchcliffe has a round-up of the latest generation of RIA technologies, pros and cons of each, and why there is likely a 'war' brewing among them."
While Open Lazlo and other open source client solutions are exciting, I think people generally want a fully integrated, front to backend solution for developing these Rich applications. Sure they provide data binding, but solutions such as Rails that provide server-side functionality to directly manipulate the client side give me a more comfortable feeling.
I want a full unification of the front and backend. That is why Rails, Turbogears and Cake appear to be more exciting.
Jim http://www.runfatboy.net/ - Fitness for web 2.0.
Flash and javascript are terrible technologies, the web was never meant for remote application delivery. Users running application code from machines on the public internet didn't impress me when it was called a Java applet or activeX and it sure as hell doesn't impress me now.
Look guys & gals, Web 2.0 is WONDERFUL. AJAX saved my life and anyone who says otherwise is a knuckle-dragging, HTTP 1.0-using moron who probably thinks that MP3 players without DRM is a good idea. In fact, Rich Internet Applications also has made me millions and will make you millions also.
All you have to do is believe. ALL of us HAVE TO believe. Clap your hands together and worship at the alter of increased complexity.
Those Unix-loving gorillas who think "Keep It Simple Stupid" are going to be left behind in our dust as we race to a higher plane of existance.
So you can't watch a streaming movie with some simple client side javascript?
XMLhttprequest isn't used to play mp3 files?
You may have to use more than 1 type of technology to build a website?!?!
Thanks for the informative article.
As did applets, as did activex. If macromedia wanted flash to be a serious tool, they should have developed a better platform for their actionscript to be developed in, because frankly the flash studio sucks. it comes no where close to real languages like java, c# for doing massive web projects.
Of course, none of them want to deal with the disabled-accessability part, despite a recent Court decision that's going to make this kind of stuff a very low priority for a long time.
Lacking <sarcasm> tags,
the tag should be enough for anybody.
B.G.
Ive been running applications people access on their cell phones (or blackberries) for years.
Its been common to run a backend server (tomcat/apache/oracle/Java) and use the phone as the frontend, and allow webaccess for easier changes.
AJAX is free, easy to use, and people are using it now. Not even going into first revisions of software and bugs that are associated with new software, or licensing fees.
That Adobe flex uses coldfusion, we stopped using that and migrated to Tomcat.
I predict if the WPF/E team pulls off what they are doing to bring WPF 2D applications to all browsers and platforms it could be the next generation of Rich Web Applications.
Unlike ActiveX and other things from MS in the past, WPF/E is very secure, easy to deploy, and brings a new level of functionality that surpasses JAVA/Flash/AJAX.
It will be a few years off, but it has potential to bring an XML based applicaiton model to the web where others have failed.
(Part of the reason behind this prediction is that WPF/E is far easier to develop applications for than JAVA/Flash/AJAX... So in a weird way, it will be like the VB of the early 90s and less 'technical' people will be able to write rather rich web applications easily.)
The web is already too 'rich'. You can barely go anywhere these days without a half dozen browser plugins. Just leave it alone and stick to the basics. Flash, Java, et al, are just a lethal concoction of poorly written code that can easily leak memory and cause system crashes. The last thing we need is more bloat.
If I wanted to do this kind of unified development, I'd look at haXe. It may be a nice way to do lite desktop apps and looks cool for server side stuff although delivering apps (flash, javascript) over the web is a no-no in my book.
Another technology to look at is Server-Sent Events (SSE), which takes AJAX one step further.
Opera 9 added support for SSE.
With the traditional AJAX implementation, the browser continually polls the server, sending requests to the server, asking to get data back, making new HTTP requests for every single poll, putting more strain on the server than needed.
In Opera 9 you can instead open a persistent connection to the server, sending data to the client when new information is available, eliminating the need for continuous polling.
Read more about it on the official Opera blog by their Web Applications team.
Opera Watch - An Opera browser blog.
(and always forgotten in those roundups):
http://www.nextapp.com/platform/echo2/echo/
If the future of webapps is based on a combination of ugly hacks such as the xmlhttprequest and other technologies which aren't meant to be used as some kind of thin client protocol, why not just let the framework do all that stuff, allowing you to concentrate on the business logic? Writing an echo2 app is like writing a normal, standalone gui app.
Carnage Blender
Is that it's becomming less of a end and more of a means, and an almost invisible means at that (no stupid plugins!).
I turned on free tagging on my website to set up categories (for use with Drupal Views to get a view-content-by-category system) and all of a sudden noticed that the tag input box had a find as you type feature to match against existing tags/categories.
Highly useful, very unobtrusive and just a regualar part of the system getting on with it's job with a gracefull fallback if client side scripting isn't available. 10/10.
Think of the Children; Sleep with your Sister
Interesting idea - Lingr is the coolest implementation I've seen so far. Super-realtime chat. Much less latency than normal Ajax-only chat
Adobe's inability/uninterest in keeping Flash truly cross-platform should be a splash of cold water for folks who see it as part of a new Web generation. Adobe has proven for once and for all that using proprietary, closed tech in Web standards is a great way to cut your own throat. The coming of new demands on the Web offers a golden opportunity to get it right this time and make sure everything there is available to everybody, on any platform. Here's hoping that consideration drives the next wave of development.
Why do we need two, brand new, incompatible protocols to push data to browsers?
... is why they are using the essentially useless HTML/HTTP stack with all the addtional layers (JS, AJAX, flash etc.) at all.
... and you can use your favourite GUI toolkit to build applications.
There are cross-platform thin-client network solutions like VNC or Nomachine's NX. They do exactly what the web x.0 wants to do, they do it fast and they do it without all the bloat and packing/unpacking of (essentially very simple) data.
Do not bring up the bandwidth argument before looking at NX first. It runs over really small links.
I also do not think that it allows additional security breaches in principle, as a web browser with all the additional plug-ins is also similar to a very high-level shell to a remote server.
I wish Webpage applets, whether Java, Flash, Javascript or other AJAX or just clientside execution objects, would all let me install them, rather than being bound to their page. Not just for easy access, rather than bookmarking their host page (which too often requires surfing several pages to build state). Also so I can combine them into single collected UIs. I want my own page with my banking client and a few shopping clients. And I want to be able to grant local access to a sandbox DB of my own data, like history and account info, that doesn't allow access to my other data, like other accounts.
If we could drag applets to our toolbars for local installation, rather than trapping them in their website context, they'd be a lot more useable. Hopefully this early stage of their development will incorporate that now/soon, rather than later when retrofitting and incompatibility will make problems last forever.
--
make install -not war
Having been around for IT for a while (20 years) and see quite a few revolutions come and go my sceptiscm with these kind of environments is that although the demo apps always look really good, the trouble comes when you take them out for a stroll in the real world and invariably you soon hit some sort of limitation on implementing something outside what the app was designed to do because the app hasn't been created with sufficient scalability or flexibility in mind. This is easily recognised when you brand-new tool whizzes through the basics as promised in a fraction of the time you would spend hand-coding, but then you loose all that time and more trying to code around the limitations when the going gets tough. Good mature development environments degrade gracefully with increasing size and complexity, poor and often new ones tend to have an asymptotic curve hidding in the undergrowth.
This isn't to say that Web 2.0 isn't wonderful. I'm doing a lot of contracts at the moment recoding old systems into browser-based ones and AJAX and partners are a joy to work with. My workbench at present is a mix of PHP using TinyButStrong http://www.tinybutstrong.com/ templates, AJAX using the xajax framework http://www.xajaxproject.org/, as much CSS 2.x as I can deploy that doesn't break on all common browsers, and whatever javascript widgets that meet the needs.
I can't recommend the two core tools in here highly enough - xajax is really nicely designed and I've only found one bug in it so far (when running a window modal), tiny-but-strong is even better - if you do any coding with PHP and havn't found this yet then you are missing the best templating system yet devised.
A quick response/overview from someone who is actually working with more or less all of these technologies.
The AJAX vs. Proprietary Debate
Isn't really a debate, which the article kind of notes but doesn't really state. AJAX doesn't compete directly with any of these tools... Asynchronous Javascript and XML is a data delivery mechanism, NOT a presentation layer (if I hear one more person use AJAX to refer to DHTML I'm gonna scream). Flex, Lazlo, Nexaweb, etc. have aspects that compete with AJAX (Real-time Push in Flex/Flash being one that competes and bests AJAX), but drawing them in parallel is misleading. With SVG more or less dead in the water (yeah, AdobeMacromedia doesn't have much of an interest in further developing an OSS competitor to Flex) and no SVG support for IE 7.0, there is no viable presentation component for AJAX to make this argument viable.
What the article gets right is that future application solutions are a combo approach that leverage a number of different technologies. For example, portals leverage AJAX/DHTML where possible to reduce page refreshes and increase basic interactive behavior (maybe with a framework to do the heavy lifting, though that has its own drawbacks) and something like Flex to supply visualization tools and whiz-bang interactive components on a more selection "superportlet" basis.
Cost Effectiveness of Proprietary Solutions
This is right on the money and a BIG reason to favor things like Flex. You'll actually spend more money developing and debugging tools in javascript and html than you will implementing with a robust end to end solution like Flex. From a UE perspective you're married to certain interactive behaviors the components you leverage (Flex isn't very good at exposing the underpinnings, read "Gold Support" here), but you get the benefit of tested methods and basic patterns that are generally at least "acceptable" from a usability perspective.
Java for Visualization
God help us all. I went there once on a trip... lost my granny, my dog got run over, and I came back with only 8 fingers.
Plug-in Limitations of Approach
Here we're mostly talking about Flash/Flex. I did an analysis not too long ago when I led a project doing a Flex 1.5 implementation (which sucked btw... don't even consider 1.5, not that Adobe would sell you on it anyway). What it comes down to is that Flash 9.0, which is the latest plug-in required to drive Flex 2.0, is at the beginning of its adoption, making this argument somewhat ligitimate. However, typical adoption patterns are a STEEP yield curve... you get to around 80%-85% within a year, get the next 10%-15% shortly thereafter (4-6 months), and pin down the final %5 over the next 5 years. Flickr has a good graphic to illustrate this.
http://www.flickr.com/photos/mannu/148867953/
The Flash 9.0 plug-in came out a couple months ago. What this means is that if you were to start developing an application now you'd likely launch with 80% adoption. So is it REALLY an issue right now? No, not unless you're developing a very targeted application on a very short timline. Additionally its worth noting that the generally plug-in updating architecture has improved dramatically after 6.0, so most users are now able to seamlessly update their players when prompted.
Basically I would say this is a legitimate concern if you're audience profile/segmentation indicates very old hardware/software with virtually no technically ability (and I mean NONE here, even more than a web neophyte) then you may need to reconsider your approach.
Application Accessibility
This subject is left only partially discussed, and its the real 800lb gorilla in the room. Last week a US court handed down a decision against Target.com (it was on Slashdot). The gist is that Target was found to be inviolation of the ADA for their use of non-accessible content formats in their web site. This was the first t
AJAX is seriously overhyped. It's been possible to do these kinds of things since the late nineties. The reason people weren't massively doing it back then is the same reason they shouldn't now: it's just not the right way. Just look at the code it generates: it's terrible.
If what we want is truly interactive, desktop-like apps on the web, then let's make something that does that, not kludge together something that approximates that, using today's fast (really fast) hardware and enormous memories to give it the semblance of actually working.
Java came much closer to this, being a real programming language with a real GUI library, platform independent, etc. I think the reason it failed is partially that Sun didn't get it right soon enough (in the beginning, performance really did suck), and that Microsoft managed to break compatibility enough that Java applets wouldn't work reliably. Also, the Java runtime is too large to comfortably download.
Flash does better: the plugin is small, it has OK performance, and Microsoft didn't kill it. However, it doesn't give programs that native feel (right?), and I don't know if there's a real programming language behind it.
XUL is interesting, too: a proper GUI framework, cross platform, open standards, open source implementations, support for all major browsers either existing or on the way. My only doubts are about the programming language: is JavaScript really going to cut it?
There are numerous others out there that I won't mention because the list would get too long; one of these is my own (abandoned) project that mixes XML GUI descriptions with Ruby programs.
I think, the way things stand now, we should rally behind XUL. It comes closest to what we need, and it's open, which is very important: it won't do to get locked into a proprietary technology that would only be available...I think that mistake has been made often enough.
The surge of AJAX means that the world is ready for the revolution: the demand for rich web apps is there. However, please don't make the mistake of thinking AJAX is the way to go: it's hitting the limits of what HTML and JavaScript can do even as it provides only little bits of interactivity here and there. That's not a good start. We want a technology that can grow.
Please correct me if I got my facts wrong.
DOM level 3 load and save
Because a browser is all you've got when you use a public terminal.
Because every user behind a firewall has resigned to coax his admin to open up another port in the corporate firewall.
Because a browser is what's already installed on your computer.
Because WWW has the biggest user base ever.
Oh, BTW, you're still using IPv4, don't you?
SVG is designed to fix that. It is an open standard, it looks promising but unfortunately browser support isn't quite there yet...
as long as they don't discriminate against the blind.
All of these platforms suffer from a common drawback: the lack of right click capabilities. I'd really like to find one that lets me use it to build a rich user interface.
Everybody has a purpose in life, maybe mine is to lurk in slashdot.
The model of the web was broken the instant people started using it as a front-end for remote applications.
The World Wide Web is (ostensibly) a network of hyperlinked documents. Dynamically-generated pages pulled as requests from a database is a bit of a stretch but still basically within that model, as a database record is not so different from a traditional stand-alone document: it's still just data.
But cramming fancy interactive applications (games, etc) into this model is already a bastardization of it, with or without requiring external plugins. The notion of remote applications is fine, and I make great use of a number of "applications" on the web, but they really shouldn't be outputting their interface to what is essentially a document markup language. Imagine using an application whose interface was a read-only Word file that it updated and force-refreshed every time something changed. Sound ridiculous? Web applications aren't much different.
-Forrest Cameranesi, Geek of all Trades
"I am Sam. Sam I am. I do not like trolls, flames, or spam."
At Radio Mixtape (disclaimer, this is one of my sites), we use both technologies. Our site is accessible in most modern browsers (even cell phones) for browsing, downloading, and sharing so a reliance on Ajax and Flash is out of the question. However for building a mixtape (why our site is useful to most of our users) we use a flash applet(is that the right word) to display the selected tracks (it's really cool, the tracks are drawn on a cassette jacket in a handwriting font) by an XML feed. This gives us font embedding, guaranteed placement, total control over the look and feel and even back button support. However when you want to reorder the tracks you selected you are taken to a page that uses a simple drag and drop Javascript library and makes XMLHTTPRequest calles to save the changes in track order every time you drop a song in a new position. For sites like Radio Mixtape is has to be a balance, not everything looks good or works right in JavaScript+CSS+HTML, and Flash can actually be overkill for simple things. -Jason
This was a good article up until this point, which is utterly and completely wrong.
Flash has supported XML parsing back to version 6, I think.
Flash 9 includes E4X support as part of ActionScript 3, which puts it far ahead of most other solutions.
One way to reduce the challenges of using Javascript and AJAX across browsers is to use a library that abstracts away many of the differences from one browser to another. One such library is MochiKit, which provides AJAX / remote scripting support, functional language tools, portable DOM manipulation, and event signalling. It's even got some cool flashy visual effects.
Anyway, I'm not affiliated with the MochiKit at all; I'm just a very satisfied user and even use it on my own site.
This is slightly off-topic, but what's the point of making a diagram if you're going to make it this complicated? That diagram provides basically no information, which is pretty typical of all the diagrams in Dion Hinchcliffe's articles that I've seen. It hurts.
This is why application level firewalls are developed. Until all sides finally realize that they are just repeating history and that constraints on certain types of SOAP queries are not really different to constraints on certain TCP ports. In the meantime, a lot of those 'internet security consultants' got a lot of money in salaries for implementing such firewalls and the web traffic volume (and therefore the ISP stocks) got larger by the additional header of some protocol stacked onto HTTP. Worth mentioning are all those 'specialist' articles filling up pages in otherwise interesting computer magazines.
Ok...
They usually run on a fully-fledged GUI toolkit and a capable operating system...
Yes, this is probably the main reason (- I think the other of your arguments are essentially variations on this).
But I do not think that it is a good idea to keep going this direction, just because there is a lot inertial.
Sadly, yes! I'd like to have all these IPv6 multicasting capabilities
Flex 2.0, with cairngorm micro-architecture, front-ends.
Java of your choice (hibernate, EJB 3.0, etc...) backend.
A truly sweet combination.
Opinion:=TMyOpinion.Create(Me);
Radio Mixtape uses a Flash 6 applet that pulls down a XML document parses it and displays it information. I'd call that XML support, now if you meant XSLT or XPath support I might agree with you, anyone have experience with that one?
-Jason
Nnnnooooooooooooo!!!!!
An entire world of Mystery Meat, I don't think my eyes could take that
First God made idiots. That was for practice. Then He made Jack Thompson.
"While WPF/E itself is a powerful Flash analogue, it doesn't have its own application development model like Flex or OpenLaszlo..." WTF !!!! What planet is this guy on ? Has he never heard of .NET.... and Visual Studio .NET ?
Just what the hell is an application development model if .NET and Visual Studio don't count as one ?
Is this guy completely clueless or what ?
Yeah, they could have. However, there are at least three big show-stoppers to that idea:
Lacking <sarcasm> tags,
I wrote a quantum computing 3D visualization program in Java3D. The user can just click on the link in the browser and Java3D native libraries will be automatically downloaded and installed on the users' machine (of course after asking the user for permissions to do it) after that my application can use the native OpenGL drivers for fast 3D graphics. So it is both an Internet application (although it presently doesn't talk to a server in real time but it would also be possible) and it takes advantage of the fast native OpenGL graphics and the rich Swing GUI.
What about Eclipse RCP applications? They are apps that can be launched and updated from a website and yet, don't require an internet connection to function.
I wish SVG would take off at once. But the browser support is still lacking. I tried creating a small website in SVG using Inkscape only, it worked pretty well with Firefox but IE needed a plugin. But even Firefox still doesn't support the full 1.1 specification...
At some point, these "rich application frameworks" will get to the point where we've got a complete re-implementation of the X protocol over HTML. What a day.
If you've used Anyterm (http://anyterm.org/) you'll have seen how this is possible without needing to add anything new to HTTP. Anyterm is a GPL terminal emulator on a web page, and there are demos on the site running tetris and adventure. It doesn't poll for updates; it sends an HTTP request and the server doesn't send a reply, keeping the connection opne, until there is data to send. (An eventual timeout is needed to keep the browser happy, but that can be ~30 seconds, compared to perhaps ~0.3 seconds that you would need to poll with for the same responsiveness). The performance is quite respectable (though perhaps the demos won't be if lots of slashdotters try them!).
I have also applied this technique in Decimail Webmail (http://decimail.org/webmail/) which gets asynchronous notifications from the server, without polling, when new mail arrives. I'm planning to make this the most responsive and full-featured webmail app available, though it is currently very new. Please check it out.
>There are cross-platform thin-client network solutions like VNC or Nomachine's NX.
It's a blessing and a curse that http connections are mostly ephemoral. Web 1.0 applications have built-in assumptions that the user at the other end can go away without so much as a by-your-leave. Just ask a terminal service or Citrix admin if s/he wants to see Web 2.0 implemented on persistent TCP connections. Yes, you can resume a disconnected session, but this raises the compentency requirement of the user. Also, it doesn't matter that VNC-like connections can run in small amounts of bandwidth, it's the consistent need for bandwidth that is the problem. When you introduce a certain amount of low bandwidth, low latency traffic (VOIP and terminal service traffic are similar in this regard) on the peaky Internets, you get a shaping and priority problem that requires some sort of end-to-end solution that we don't have today outside of institional will.
"All levels of the stack need fixing, not just server-side. We need more than just hacks."
XMPP on one side. We may need to either retrofix existing browsers, or modify the existing XMPP clients.
He missed ZOPE, with such add-ons as the Plone content management system, becomes very competitive in the RIA space. Zope uses the object database ZODB. Zope is written mostly in Python - and uses python as its development language of choice (although you can use others).
Been using it for years -- it is stable as a rock, and Version 3 is looking very cool. If you love Python, then Zope is the development framework to use imho.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
When you expose your appliction as a web 2.0 app, your backend includes the application's backend and the shared environment (web/database server, etc) it depends on.
When you expose your application via VNC/NX, you have to additionally provide the per-user user environment (windowing, at least). The client machine is already providing the window managaer etc to run the thin client in, so why duplicate that in the backend? The flipside of thin client is fatter backend.
Is a thin client that much thinner than a web browser anyway? Another thing to think about is when you go thin client you're marrying to the client. I guess it's like just coding your web 2.0 junk for compatibility with only one web browser. That might be a pro or con, depending on who you are and what you're doing. Is there a way to run thin clients without needing to install software on the host?
The few AJAX enabled web apps I've used, as well as any web page which relies heavily on javascribble, have been slow to the point of almost unusability. Take Yahoo's new web mail client - please! Looks slick and can do almost anything a fully compiled app with native code is capable of, is frustratingly slug-like. Add to that scripts which time out or just crap out for no reason, and my P4 machine regresses to a 80386. I didn't pay all this money for a P4 to end up with a 15-year old computer.
What TFA is saying is that perhaps plugins - applications compiled and running on native code - are the way forward. To which I can only say - what the heck took you so long to figure *that* out?
Oy.
Who is this delectable creature with an insatiable love of the dead?
where I wish someone would just drop a nuc on all the participants.
WTF does so many people crave web apps to begin with?
slashdot troll = you make a compelling argument I do not like the implications of.
Excellent reply! In the corporate environment these days, if it don't work in my browser over standard HTTP port 80 - it won't work period. Everything is locked down so tight, that even installing the "plugin of the day" is not an option.
(+1 Funny) only if I laugh out loud.
get out of your basement, this isint 1970.
Zope doesn't have anything relating to RIA at all. Its just normal old web development, no flash or ajax or any other gay nonsense.
There are cross-platform thin-client network solutions like VNC or Nomachine's NX. They do exactly what the web x.0 wants to do, they do it fast and they do it without all the bloat and packing/unpacking of (essentially very simple) data.
You've got it backwards. VNC and the like send bitmaps across the wire. Bitmaps, even with compression, are more bloated and take more packing and unpacking than simple data. Other reasons to prefer AJAX, Flex, Laszlo, Altio, Nexaweb or other similar frameworks rather than terminal server type products are:
Also, the article gets it wrong when it states that these frameworks have suddenly started appearing in the last year since AJAX became popular. Aside from Flex, the products I've named above date back to around 2000. They're becoming more visible now that people are starting to see the possibilities of RIAs, but the 6+ year history behind some of these products means they're already stable, quality frameworks with good developer support.
the next time i hear or see the words ' rich experience' im going to scream.
---- Booth was a patriot ----
Echo2 is a dream to develop with (forget html, form backing objects etc. Think swing api)
The cross browser compatibility is excellent, the performance impressive and writing your own custom components (not that you'll often need to) is not too bad either.
Give it a go and you'll see what I mean.
Have a look at the demo app to see what it can do: http://demo.nextapp.com/Demo/app
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
Mainada Comics Sketch is a fine example of this new RIA aproach. http://www.mainada.net/comicssketch is a place for artists and users to draw their own comic strips online. This site uses rails/ajax approach and implements Open Laszlo features on top of it. It's a great example of the new generation of RIA sites and portals. Here you can browse comic strips with the conviniency of ajax, take advantage of flash to view animations and real time drawing strip playback. And due to Laszlo great features, anyone can draw complete comic strips directly online and publish them on-the-fly. This kind of mixture is great, having the right portion of html and ajax, to have a fluid yet google-friendly site and flash/openlaszlo components to give more dynamic and richness to it's main contents. Try openlaszlo. It's easy to integrate with ruby or any other related framework (ruby or python). If you have any talent or curiosity, feel free to use the site.
Tiago Cardoso
t's a blessing and a curse that http connections are mostly ephemoral. Web 1.0 applications have built-in assumptions that the user at the other end can go away without so much as a by-your-leave. Just ask a terminal service or Citrix admin if s/he wants to see Web 2.0 implemented on persistent TCP connections.
I have to be honest here... I do not have any information about what current TCP as a transport for a terminal-like UI would mean for the infrastructure.
But (as you also mention), there is already VoIP (and IRC and online games!). And some popular Web 2.0 applications. And the net still works. And the web2 isn't stateless any longer.
This effect - if it exists at all on such a scale, which I doubt (any references?) - could be easily mitigated by longer delay between keepalive messages.
A laggy end user experience with a VNC-like remote UI... ok, that's a valid point. But of course, it does not need to be solely pixel based and it does not need to transfer every mouse click.
I just think that some simple, low bandwidth standard for 'fullscreen remote applications' would be a better idea than the extension of HTTP+HTML with a lot of heavy APIs and many layers of software.
I saw that too. I have no idea how he came to that conclusion, as any amount of research (such as a Google search for "Flash XML") will show many examples of using XML with Flash.
For the record, XML has been a part of the player since version 5, as well as the XMLSocket class. It was slow at the time (it was itself written with ActionScript), but version 6 and later rewrote the class to use C code instead. Version 7 provided data components that could call SOAP or REST based web services (which of course are XML based). As you mention, Flash 9 provides e4x, which I must say is really nice and dang fast.
Flash 9 provides e4x, which is basically an XPath like implementation. There are no XSLT tools available to the Flash plugin itself. If XSLT is used, the transformation is done before the data gets to the Flash app, where Flash is basically just another target for an XSLT template. We have used this to generate XML input for Flash and HTML alternate content for those who do not want to use the Flash version.
The web needs a MAJOR overhaul indeed. Even when there's talks about some new stuff (SVG? XForms? XUL? XHTML+Voice? ...) it never ends up being implemented or used. Stateless HTTP could use a good replacement indeed, and I wish there was something better than relying on tons of javascript to get anything done client side: dhtml widgets, callbacks, animations - almost everything... I'm starting to see some pages with a LOT of javascript bloat - javascripts for ads, javascript for counters (google analytics namely), large javascripts for AJAX toolkits, TONS of javascript for widgets like FCKEditor or FreeTextBox, etc. If things keep going that way, soon enough pages will have over a meg of javascript. But the most aggravating thing is HTML form elements - what a lame set of widgets! Heck, shitty old VB3 had better widgets than that! Hell, try to find a simple combobox that works in more than one browser (no such native control - because that could be useful)! So far, I've only found 2 such things and they're commercial (like 300$/server - ouch!). Yes, there's a bunch of others that don't look like a native combobox, or that only work with IE, or some that work with most browsers - using a HTC for IE and which are a nightmare to setup and use, etc (and none of those being components - you gotta make that happen yourself; they're just a javascript that's used with a bunch of ugly form elements with a bunch of events, which sometimes doesn't work quite right).
I'm not keen on the idea of a proprietary/closed Microsoft-only technology replacing "the web", but there's times whe I wish something like XAML just replaced it all - I'm sick of the old hacked-together sub-par technology that powers the web, and there's no hope of the W3C doing anything about it. They're just too damn slow.
I've been thinking about using something else instead... But the alternatives are hardly better. ActiveX? Hell no! Java Applets? Nobody wants that! Flash? Perhaps the least evil of the bunch? It's bad enough that I've been considering using it as a front-end to web apps (and that's coming from someone who despises flash)
When you expose your application via VNC/NX, you have to additionally provide the per-user user environment (windowing, at least). The client machine is already providing the window managaer etc to run the thin client in, so why duplicate that in the backend? The flipside of thin client is fatter backend.
True, but I still doubt that simple server-side windowing (it's about a web app, not a web desktop, isn't it?) will be more resource hungry than producing messages for a fat API to the client. This api does not even exists implicitely in the server case.
Form handling this, templating that... or, for example, managing sessions through complicated and fault-prone mechanisms which are as least as complicated as unix process management.
Consider also that there are (already) a lot of incompatibilities in the client API. A standard for a fat client (which also gets a fatter and fatter API with all the 'neccessary' extensions) is more complicated and therefore much harder to implement correctly.
Java is a bitch to program when you know better languages*, you feel trapped, limited and frustrated.
But compared to AJAX? Yes, it's better, if your application is complex enough. Java looks ugly though.
So may be he had very few programming skills. But it's entirely possible that he had superb programming skills** and still would though the same.
* by better languages I mean Lisp, not C#.
** try explaining closures or continuations to a Java-only programmer.
We are Turing O-Machines. The Oracle is out there.
You should check out the discussion going on at ReadWriteWeb. Ebrahim Ezzy's post is interesting, as are the comments. There's also more followup from industry as they bring Web 2.0 products to market. SharpCast, TeamDirection and x-port. Hopefully with such interesting ideas, Web 2.0 won't implode like Web 1.0 did.
Geeze, why don't you all just use Java Swing over Webstart! All problem solved!!!
SVG + ECMAscript, when fully implemented, has the same major problem that Flash has: no decent automatic layout for complex pages.
That's one of the real strengths of HTML. If you've ever written a GUI application in, say, Microsoft Windows.Forms or Gtk or whatever, and then redone it using HTML, you'll know that for many data-intensive applications, looks great in HTML with very little effort compared with the GUI toolkits.
That's due to the wide range of handy CSS effects, good browser implementations etc., but it's also due to the HTML typesetting-style layout model. SVG and Flash both suffer from that same problem as GUI toolkits: you have to calculate layouts yourself except in very simple cases.
Granted, the HTML model is also a problem for some types of layout. There's much potential for improvment there too.
A hybrid of XHTML and SVG, with the typesetting-style layout model and GUI toolkit style layout methods as well (e.g. vertical box with springs) has great potential in this department. Who knows, maybe the next version of Flash will do something like that.
One thing that should be discussed when talking about the "The coming RIA wars..." (That have been going on for almost 5 years) are the benefits and limitation of the underly "VM" that the technologies are built on. For any given application one VM technology made be best suited for the application requirements. A framework can make it easy to use the VM and smooth the rough edges, add features but the true benefits and limitation come from the VM itself.
Currently there are four different VM technologies people use to build RIA applications (in no particalur order).
The article http://ajax.sys-con.com/read/232046.htm provide a good breakdown of the VMs.
Thin client, smart client, whatever you want to call it, won't last. We'll all be back in cleint/server mode in a few years.
"22 astronauts were born in Ohio. What is it about your state that makes people want to flee the Earth?" Stephen Colbert
To give Microsoft 95% of the market.
Your Flash info is circa 2001. Now it has a real programming language behind it, and many of the most-used slownesses are optimized in the native player code so for many types of things you get surprisingly fast performance. (Obviously it's not native performance for real number crunching.. but the recent player versions take many things - like event management - and do them natively, so that part IS at native speed.)
With Flex there's a really nice programming interface for every single part of Flash - no GUI required to create in Flex.
Looking for freelance Actionscript (Flash/Flex) or ColdFusion work and/or freelance developers. Email me, put Slashdot
Speed:
Remote Desktop solutions are reasonably secure (for the client) because the client only draws stuff. However, they are incredibly slow if you have a lot of users - because the you're doing ALL the work for EVERY client on the serverside. A well written Flash/Flex application does the vast majority of the work on the client side and only talks to the server when it needs to share something. This problem is tied to the responsiveness problem - even if it works over a low bandwidth connection, it can't work well over a high LATENCY connection. That is, if all the thinking is done on the server, the user experience must wait for a whole round trip before anything changes, which blows if you have any kind of latency at all.
Sandbox:
So you have to move most of the UI stuff to the client side so that user feedback happens without waiting for one or more round trips, and you want to move some random execution there so you can give the programmer complex and rich control over this. Of course, if you're going to do this, you need a secure sandbox to keep the computer safe from the remote app.
Congratulations, we've just invented Flash, or Java applets.
Looking for freelance Actionscript (Flash/Flex) or ColdFusion work and/or freelance developers. Email me, put Slashdot
It's "X-Windows" with a dash, if you want to maximize your chances of making people who insist on calling it "The X Window System" go apoplectic.
And NeWS invented the BIG small BIG BIG capitalization style, long before NeXT copied it!
-Don
Take a look and feel free: http://www.PieMenu.com
Since X-Windows is so pixel oriented, a natural scripting language would be a two-dimensional cellular automata like John von Neuman's 29 State Cellular Automata, which can run "Universal Constructor" programs that reproduce theselves or any other program. Since it's Turing Complete, you could script an emulator for any other language!
-Don
Take a look and feel free: http://www.PieMenu.com
Why would anyone choose to tie themselves to proprietary Flash and FLEX, when you can have your cake and eat it too with OpenLaszlo, which supports both Flash and DHTML, and is completely Open Source?
So when will FLEX support DHTML or SVG? The answer is NEVER, because it's designed to lock you in and make you depend on Flash 9 -- it not designed to be platform independent, like OpenLaszlo.
FLEX is not Open Source, so you can't just add support for your favorite runtime or graphics model, the way Henry Minsky added SVG support to OpenLaszlo.
-Don
Take a look and feel free: http://www.PieMenu.com
-Don
Take a look and feel free: http://www.PieMenu.com
What is needed is a distributed application environment. I've been saying this in every chance I have:
6 101&cid=160713125 852&cid=16052135
http://developers.slashdot.org/comments.pl?sid=19
http://developers.slashdot.org/comments.pl?sid=19
Over and over will I repeat this, until someone that has the time and resources reads it and takes the right decision.
>This effect - if it exists at all on such a scale, which I doubt (any references?) - could be easily mitigated by longer delay between keepalive messages.
Empirically I would expect increased needs for neartime delivery of information to have an effect near the consumer end of the tubes, where oversubsription is the norm and so far, seemingly necessarilly so. When it becomes common that the customer expects 32 kbps - 64kbs lag-less (VOIP realtime and one or two other neartime apps) one could predict that it will present a problem on even lightly loaded pipes (analyzed from a bursty model). Yeah, there are ways to deal with it, but they are not perfect, and I would expect voice degradation and lagging apps. It's not clear to me that end-to-end solutions are going to work on public networks because priority queuing would be gamed.
Back in the day when I flew in a MMOG called Air Warrior, we called people with realtime packet delivery problems "warpers" because once packets caught up after a delay their plane would defy physics briefly (usually when you were just about to blow them out of the sky). Yes, this was in the age of modems, but the bandwidth requirements were miniscule (but the temporal needs were not).
>A laggy end user experience with a VNC-like remote UI... ok, that's a valid point. But of course, it does not need to be solely pixel based and it does not need to transfer every mouse click.
Yeah, that would be the extreme example. But is responsive apps with dynamic content updating from a distant host not a logical conclusion for where this is all headed? Maybe that's Web 2.5 or Web 3.0.
>I just think that some simple, low bandwidth standard for 'fullscreen remote applications' would be a better idea than the extension of HTTP+HTML with a lot of heavy APIs and many layers of software.
Makes sense. Twas just trying to point out that getting away from HTTP doesn't necessarily solve the neartime delivery issue.
Its about scale. Web-scale to be exact. RESTful architectures (like HTTP) are proven on that scale, and pretty much nothing else is. VNC and the like are nice and have their uses, but you don't want to build an application for the web in general with them. You shouldn't be thinking about bandwidth, but rather about things like maintaining state for thousands of simultanious users, naming of third party resources and how to make your application benefit from caches.
o n/top.htm) pretty readable and convincing.
The REST article on wikipedia is rather terse, but can be used as a starting point. I personally found Roy Fielding's dissertation (http://www.ics.uci.edu/~fielding/pubs/dissertati
Computers are useless. They can only give you answers - Pablo Picasso
I feel a bit silly replying myself, but ... Big part, possibly the biggest, of REST is that it allows the system (= web) to evolve incrementally over time.
Computers are useless. They can only give you answers - Pablo Picasso
To paraphrase Bill Gates: "'Beep!' should be enough sound for anybody!"
This space intentionally left (almost) blank.