×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Future of Rich Internet Applications

kdawson posted more than 7 years ago | from the does-ajax-tell-flex? dept.

187

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

187 comments

The future is in the Stack (3, Interesting)

RunFatBoy.net (960072) | more than 7 years ago | (#16090098)

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/ [runfatboy.net] - Fitness for web 2.0.

Re:The future is in the Stack (2, Insightful)

orb_fan (677056) | more than 7 years ago | (#16090264)

I have to concur.

While what can be done with Ajax is pretty amazing, the unfortunate truth is that the developer generally has to jump through hoops to get everything working. Simply the lack of stateful information is a major problem. What's needed is another protocol (Application Transfer Protocol?) that would provide state information to the server, true client-server event handling, etc.

Re:The future is in the Stack (5, Insightful)

Randolpho (628485) | more than 7 years ago | (#16090542)

Yes and no.

Rails, Cake, and Turbogears can't provide the sort of rich interaction that flash/activex/java can, no matter how great their frameworks may be. Why?

The problem is not the stateless nature of the web as much as it is the medium with which the web is presented. HTML was designed as a document language, for the static display of information. It was never designed for any sort of interactivity other than hyperlinking. Everything else that has come along is a hack on top of a simple static display medium. Even arguably solid frameworks like Rails are nothing more than a hack to provide dynamic interactivity to a system that was designed against another way of doing things.

If we really want remotely obtained rich interactivity, we need to rethink the medium. We need to drop HTML/Javascript and plugins like activex and flash. We need a new platform designed from the ground up to provide dynamic rich interactivity. That includes both the display medium *and* the means by which it is obtained. XUL was a baby step. The concepts behind XAML seem to go much further -- especially in the display department -- but still relies on stateless HTTP.

All levels of the stack need fixing, not just server-side. We need more than just hacks.

SVG (2, Insightful)

drgonzo59 (747139) | more than 7 years ago | (#16090598)

HTML was designed as a document language, for the static display of information. It was never designed for any sort of interactivity other than hyperlinking.

SVG is designed to fix that. It is an open standard, it looks promising but unfortunately browser support isn't quite there yet...

Re:SVG (2, Interesting)

TheUnknownCoder (895032) | more than 7 years ago | (#16091107)

It's not that it's not quite there yet. Native browser support for SVG is non-existing. However, you can download plug-ins to view SVG. And being a W3C Recommendation [w3.org] , Netscape and IE are promising future browser support for SVG, and with browser support, the plug-in will eventually be phased out. The main problem with SVG for the moment is that hardly anyone uses it.

One sweet duo is SVG + Ajax, that can vastly improve the interface with the end-user, without eating up a lot of bandwidth and most importantly, can be easily implemented so that the browser gracefully presents an downgraded version of the page if one is not supported...

Give it all to the ones that can handle it, but degrade gracefully if one cannot handle it all. That is (or should be) the future of the web.

Re:SVG (0)

Anonymous Coward | more than 7 years ago | (#16091218)

One sweet duo is SVG + Ajax, that can vastly improve the interface with the end-user, without eating up a lot of bandwidth and most importantly, can be easily implemented so that the browser gracefully presents an downgraded version of the page if one is not supported...

Go take another look at SVG. If it's implemented in its entirety, it'll make Ajax completely superfluous. The direction they're taking it, if somewhat contrary to its original intent, is interesting. In concert with Javascript it's becoming a full-blown client-side UI programming environment. It sort of blows the original idea of a way to have vector graphics in web pages out the window (although SVG Tiny might still be good for that), but it appears to be morphing into a way to develop client-side UIs which can be downloaded just like a web page yet have most of the flexibility of a desktop application... I'm not sure it's going to be a better solution than XUL or XAML or things of that ilk, but interesting nonetheless.

Re:SVG (1)

drgonzo59 (747139) | more than 7 years ago | (#16091306)

Firefox support is half-way there. I was able to create a small website in SVG with Inkscape. It worked alright in the latest Firefox...

Yeah SVG+Ajax would be a dream come true if SVG is supported _in_a_standard_ way in all the major browsers. Making users download plug-ins is a good way to not have very many users.

Re:SVG (2, Interesting)

Jerf (17166) | more than 7 years ago | (#16091329)

SVG is designed to fix that.
Not from what I can see. SVG is basically as designed for static display of information as HTML now is. The same "hack" for dynamism is used for both, a Javascript-exposed DOM (or DOM exposed to some other language), and the same basic set of events are available to both.

From what I can see, it really wouldn't take a hell of a lot of work to merge XHTML and SVG into one specification with a richer layout model than XHTML currently has.

SVG gets you no new interactivity, just the ability to better display vector graphics. Nothing to sneeze at, but current SVG-browser apps are still going to use AJAX or whatever the HTML portion of the website is using for interactivity.

I agree with the grandparent that the whole stack needs fixing, but the most broken part right now is the stateless HTTP. All we need is for a browser to step up and offer a true, full socket object. Once people have settled into that, we can figure out how to make it more convenient, if there's even an obvious consensus.

If I could go back in time and choose between the XMLHttpRequest object or a Socket object, I'd take the latter. It's what people really want, they just don't really realize it yet.

Yes, it causes some new security problems, but ultimately, not really new ones; just allowing XMLHttpRequest at all really covered most of the security problems. (You'd certainly want to block the socket just to the originating server, though.)

Re:The future is in the Stack (1)

oyenstikker (536040) | more than 7 years ago | (#16091000)

You mean X Windows?

Don't shoot!

Seriously, though. If X were replaced with something with the same goal, but without the same "mechanism, not policy" policy, and a lot of the good design elements of News and NeXT, wouldn't that be ideal? Add some auto-launch features and SSL encryption, and you're all set. Hell, you could even have an abstraction layer to use and XML schema to control the toolkit.

Eventually, we get X over HTML (1)

whyde (123448) | more than 7 years ago | (#16091229)

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.

The future is in XMPP. (0)

Anonymous Coward | more than 7 years ago | (#16091292)

"All levels of the stack need fixing, not just server-side. We need more than just hacks."

XMPP [jabber.org] on one side. We may need to either retrofix existing browsers, or modify the existing XMPP clients.

Re:The future is in the Stack (1)

Elbowgeek (633324) | more than 7 years ago | (#16091449)

I'll only add that I've thought along the same lines as yourself. I'm not web developer, and I know nothing about coding for the web, but it is true that the current client for web interaction is not at all optimised for a truly interactive application experience.

I will go so far as to predict that the not too distant future all these *MLs as we know them will be obsolete and perhaps the very concept of "browsing the web" will no longer be how we interact with the WWW. I wish I had the smarts and education to implement such a paradigm shift, but I can barely get my tiny brain around HTML as it 15 years ago...

Re:The future is in the Stack (3, Interesting)

cascadingstylesheet (140919) | more than 7 years ago | (#16090607)

I want a full unification of the front and backend. That is why Rails, Turbogears and Cake appear to be more exciting.

Sounds like you're talking about ASP.NET and Atlas with Visual Studio ...

Re:The future is in the Stack (1)

wildBoar (181352) | more than 7 years ago | (#16090643)

so you don't consider cold fusion server running flex clients as an integrated solution ?

How does Rails integrate the front and back end ?

Re:The future is in the Stack (0)

Anonymous Coward | more than 7 years ago | (#16090705)

I think people generally want a fully integrated, front to backend solution for developing these Rich applications


Just like ColdFusion, Flex & Flash [adobe.com] ?


CF's a very RAD language, for the most part it is OO, has native access to Java (ie, you can write java code in ColdFusion). Can call COM & Corba objects, etc ,etc. It fully supports Flash remoting.


I'm working on a very large ColdFusion project at the moment, and whilst the language makes me want to throw my computer out the window at times, on the whole, it's a great platfor.

Re:The future is in the Stack (1)

drgonzo59 (747139) | more than 7 years ago | (#16090948)

The frontend is HTML+DOM+JavaScript. Unless you know of any good database access driver from HTML or JavaScript, or know any browsers with an embeded Python/Ruby interpreter you won't have _full_ unification of the front and backend. The closest to _full_ unification that I can think of is using Java applications where both the applet/WebStart application and the backend both run Java.

Re:The future is in the Stack (1)

plague3106 (71849) | more than 7 years ago | (#16091491)

Personally I'm hoping the .Net framework takes off. ClickOnce gives you a rich client with the ease of web deployment. As the framework install base becomes larger (I think Vista will ship with it) developing and deploying rich applications becomes very easy.

I also really hope more people get involved in Mono. Then you can target any platform you like.

No future! (0)

Anonymous Coward | more than 7 years ago | (#16090168)

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.

Re:No future! (2, Insightful)

wildBoar (181352) | more than 7 years ago | (#16090703)

The web wasn't designed for applications. FULL STOP. The fact that apps run on the web at all is a testament to the sheer stubborness of developers.

Re:No future! (1)

xENoLocO (773565) | more than 7 years ago | (#16091199)

You could not be more on target. HTTP is used up. There needs to be a new protocol with binary deliverables. You're going to be hard pressed to generically index prioritized information (the "dark web".. all that info in databases somewhere that when put together makes up an application). If you're going to display information in a pretty, brochure format it must be indexable and searchable. Whatever the solution may be, it needs an automatic data output that is machine readable so that it can be pointed to the human readable version of the data. HTTP is only capable of this because HTML is human readable *and* machine readable. However, rich applications are such a pain to develop in XHTML/CSS/JS...

Re:No future! (0)

Anonymous Coward | more than 7 years ago | (#16091474)

There needs to be a new protocol with binary deliverables.

No thanks. I too think HTTP is being abused but that doesn't make me want to run potentially malicious code over the internet. You can suggest whatever security model you want, I don't trust Adobe, MS or verisign and I refuse to enable script so running compiled code is completely out.

Web 2.0 saved my life (0)

Anonymous Coward | more than 7 years ago | (#16090176)

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.

duh.... (0)

Anonymous Coward | more than 7 years ago | (#16090191)

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.

Flash failed (1, Interesting)

hsmith (818216) | more than 7 years ago | (#16090194)

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.

Re:Flash failed (4, Informative)

kylner (639495) | more than 7 years ago | (#16090257)

Try Flex Builder 2. It's a much better Flash IDE for application development than Flash 8 is.

Flash 8 strikes me as more for content and multimedia development. Flex, on the other hand, is geared towards web developers for web applications.

We've started using it here at work for some smaller scale applications and really enjoy working in it. It's consistent, stable, and you can put together some really kick ass apps with it.

Re:Flash failed (0)

Anonymous Coward | more than 7 years ago | (#16090310)

Hook me up with links to the following I may even run them:
  1. Source code for a flash player
  2. Source code for a flash compiler
  3. Source code for your app


Otherwise, I think I'll stick to the web.

Re:Flash failed (2, Interesting)

tcopeland (32225) | more than 7 years ago | (#16090723)

You can put together an open source development toolkit for Flash development using the MTASC [mtasc.org] compiler. We use it for ActionStep [actionstep.org] development and it works great; it cut our compile time dramatically and can easily be used inside TextMate. Great stuff.

And for the language aficionados among you, MTASC itself is written in Ocaml. News for nerds...

MOD Parent Up!! (1)

bjk002 (757977) | more than 7 years ago | (#16090962)

Flex 2.0, with cairngorm micro-architecture, front-ends.

Java of your choice (hibernate, EJB 3.0, etc...) backend.

A truly sweet combination.

Re:Flash failed (1)

kylner (639495) | more than 7 years ago | (#16091316)

Oh, and as a follow-up for an example of a real world, non-web type of application that was built using Flash and Actionscript 3, check out FlashVNC.

I'm not going to link it because I don't want to blow-up the poor guys web host, but if you are interested google it.

Re:Flash failed (1)

RAMMS+EIN (578166) | more than 7 years ago | (#16090426)

I can understand the claim that Java applets and ActiveX failed, but Flash didn't. Flash is supported in all browsers, given the right plugin, which is available and even pre-installed on the bulk of computers. Support is there. Popular sites are using it. See, for example, youtube and Google video. Usage is there. How did Flash fail?

Re:Flash failed (0)

Anonymous Coward | more than 7 years ago | (#16090629)

> Flash is supported in all browsers,

It is huh? I don't install binary software but what the hell. Point me to a 64bit PPC linux binary, just for shits and giggles. Remember, the web is for everyone.

Re:Flash failed (1)

rainman_bc (735332) | more than 7 years ago | (#16090792)

Flash is supported in all browsers, given the right plugin,

Hmm... I'm looking for flash support in Firefox on my Linux box and can't seem to get anything beyond 7.

Some cross platform support huh? Adobe has really screwed with flash IMO by doing that...

Re:Flash failed (1)

IAmTheDave (746256) | more than 7 years ago | (#16090487)

Flash failed? 98% browser penetration, full cross-platform support, millions of websites developed either with or entirely on it. Google Video and YouTube, not to mention a plethora of flash-based MP3 players - not to mention it's embeddable in Win32 apps.

When did Flash fail in your mind?

Re:Flash failed (1)

peterarm (95041) | more than 7 years ago | (#16090641)

That's exactly why you should look at Flex. It might just be what you're looking for if you're coming from a Java or C# background. (I spent years doing Java Swing development, having never made a Flash movie in my life, and Flex was simple to learn...)

[Disclaimer: I'm selling something related to this (see my sig), so take anything I say with the appropriate amount of salt...]

Re:Flash failed (1)

rainman_bc (735332) | more than 7 years ago | (#16090776)

f macromedia wanted flash to be a serious tool, they should have developed a better platform for their actionscript to be developed in,

AND they wouldn't alienate operating systems like Linux. I don't take flash seriously if they are two versions behind with a linux viewer. It was a good cross platform tool, now it's a pile of crap IMO that only supports Windows and Mac. /me still annoyed with that.

Re:Flash failed (1)

Goaway (82658) | more than 7 years ago | (#16091177)

I'm sure Adobe will be devastated to learn that they have earned the ire of people who use IRC commands in lieu of real words.

SVG? (1)

drgonzo59 (747139) | more than 7 years ago | (#16091226)

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

Re:Flash failed (2, Interesting)

draos (672972) | more than 7 years ago | (#16091209)

Take a look at content that's geared towards the Toddler to preTeen age group. Its full of flash and shockwave content. Flash is filling a niche to deliver tv/video game style content to the worlds young children. My kids even have a large number of game/applications that use flash on the desktop to deliver content.

As far as flash studio sucking, I couldn't agree more, but then again I'm a J2EE programmer. My artist friends think it rocks. Again its all about knowing your audience.

Well, at least he mentions (2, Insightful)

overshoot (39700) | more than 7 years ago | (#16090203)

the fact that AJAX (and XUL, actually, but never mind) are searchable. It's the first time in quite a while that an "RIA" author got past the gee-whiz eye candy to deal with usability issues.

Of course, none of them want to deal with the disabled-accessability part, despite a recent Court decision [slashdot.org] that's going to make this kind of stuff a very low priority for a long time.

Re:Well, at least he mentions (0)

Anonymous Coward | more than 7 years ago | (#16090460)

And the accessibility issues in Flex and Flash are very serious, despite Adobe's insistence that Flash accessibility issues are all in the past. They most assuredly are not. You'll find only certain controls can be made accessible. You'll find that only very specific versions of screen readers, etc. are supported. You'll have to install additional software ("JAWS Scripts for Flex") on the client side.

Accessibility is even turned off by default to save on the size of the SWF! (One way of enabling it is to go hunting through XML files to find the "accessible" tag and setting it to "true".)

With standard Ajax you have to be careful and think about accessibility from the beginning, but Flash in comparison is a whole world of hurt.

Well in my opinion, (4, Funny)

Anonymous Coward | more than 7 years ago | (#16090215)

the <blink> tag should be enough for anybody.

B.G.

Telcos have been doing this for years. (2, Interesting)

BrookHarty (9119) | more than 7 years ago | (#16090221)

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.

Re:Telcos have been doing this for years. (2, Informative)

siamesepurr771 (959086) | more than 7 years ago | (#16090504)

AJAX is free, easy to use, and people are using it now.

Flex is free (the compiler), ease of use is a subjective measure, and people are using Flex now too.

That Adobe flex uses coldfusion, we stopped using that and migrated to Tomcat.

Negative. Flex has no reliance on ColdFusion. There are numerous ways for Flex (front-end) to talk to the server (back-end), ColdFusion being ONE of the ways. It can also talk to Java via Tomcat. For that matter, I can run ColdFusion ON Tomcat.

Note that I've never written a Flex app - I state facts, not biases.

Re:Telcos have been doing this for years. (1)

$1uck (710826) | more than 7 years ago | (#16090913)

Well the company I work for is having a brief training tonight on the use of flex with J2EE. So I know it is definitely not reliant on Coldfusion. I got the feeling you didn't need to use any proprietary Flash development tools to use it either, but I did get the feeling it used the flash plugin someway from the brief overview I was given.

Re:Telcos have been doing this for years. (1)

peterarm (95041) | more than 7 years ago | (#16091063)

You can use Flex with anything: J2EE, ColdFusion, Ruby on Rails, etc--anything that you can send an HTTP POST request to. Obviously, Adobe want to sell their server-side stuff, but other stuff works too...

Re:Telcos have been doing this for years. (1)

MickDownUnder (627418) | more than 7 years ago | (#16091363)

"AJAX is free, easy to use, and people are using it now."

People ARE using it, but you aren't !

No one in their right mind who has ever delivered AJAX sites would describe AJAX as easy. For what it achieves it's ridicuoulously complicated.

Prediction.... (3, Interesting)

TheNetAvenger (624455) | more than 7 years ago | (#16090232)

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

Re:Prediction.... (1)

CompSci101 (706779) | more than 7 years ago | (#16090322)

That's what I don't get about XAML and such: it's really just the Microsoft alternative to XUL and SVG+SMIL. Both of which have an excellent implementation that by most current estimates is used by about 10% of the surfers out there (I mean, of course, Firefox).

Now, I'll concede that last I checked Firefox didn't have a working SMIL implementation in their SVG stuff, but my point is this: it's already here, it does what WPE is supposed to do (which I haven't seen in the wild at all), and it's an open standard.

Why does everybody -- worst of all, developers that should know better -- count out XUL + SVG from the gate? Haven't web developers learned from the pain that was the last Browser War?
C

Re:Prediction.... (2, Interesting)

TheNetAvenger (624455) | more than 7 years ago | (#16090667)

That's what I don't get about XAML and such: it's really just the Microsoft alternative to XUL and SVG+SMIL. Both of which have an excellent implementation that by most current estimates is used by about 10% of the surfers out there (I mean, of course, Firefox).

Well, a lot of people go this route in thinking, but if you take the time to look at XAML and its capabilities, you will easily find that 80% of things it is doing or can do are not supported with the technologies you mention.

XAML is not only presentation, but handles every thing from events and hit testing to virtually every type of media. It bridges what you see and and what you can do.

One simple example is some of the graphic abilities of XAML is that can display very complex vector based images that surpass GDI+ or OSX's Display Acrobat. In fact, some of the image presentation abilities built in are on par with something you would normally see in Adobe Illustrator or CorelDraw. (Blends, transparency, effects, etc.. - And they are all extensible as well, so they are not even a locked set.)

I know WPF/E in the first release is not going to target 3D, but in response to your view of the other technologies, WPF/XAML does some really impressive things again with its ability to simply display 3D scenes, that are not only nice looking, but fully interactive UI controls as well. (Imagine a RichTextBox on the side of a Cube Spinning with Buttons on each side of the cube that are clickable.)

Not only is this beyond the 'display' capabilities of the technologies you mention, but also surpasses anything out there short of writing an OpenGL or DirectX application. Yet, a begining programmer can write a 'few' lines of XAML that does all of this that is actually easier than making a VB 2.0 Form and throwing controls on it.

This ease of programming is where it is as easy as early VB, and yet will do things that are beyond what many developers are even seeing as possible ways to create applications.

I consider myself half-way versed in WPF stuff, but everytime I look at aspects of it, I find numerous new ways of thinking in creating applications that JUST ARE NOT possible on any other platform and it also reinforces why MS could not just take SVG or other standards and bastardize them in order to achieve what they are with XAML.

In early previews of XAML concepts I was a lot like you and thought, why not just use SVG, but after seeing how much MS would of had to chop up and turn SVG into what XAML does, I'm actually glad they left SVG alone.

Not needed (0)

Anonymous Coward | more than 7 years ago | (#16090243)

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.

Another clueless, buzzword spouting fuckstick (0)

Anonymous Coward | more than 7 years ago | (#16090272)

If I wanted to do this kind of unified development, I'd look at haXe [haxe.org] . 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.

Event Streaming to Browsers (1)

TheJavaGuy (725547) | more than 7 years ago | (#16090283)

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 [opera.com] on the official Opera blog by their Web Applications team.

Re:Event Streaming to Browsers (0)

Anonymous Coward | more than 7 years ago | (#16090372)

Sounds useful, but the article wasn't clear. Does it work without javascript or do I put it on ignore with the rest of the AJAX hype?

Re:Event Streaming to Browsers (0)

Anonymous Coward | more than 7 years ago | (#16090451)

Why the hell would someone who browses without Javascript be reading an article on AJAX? Your ignore filter must be flawed.

Comet vs. SSE (1)

Wesley Felter (138342) | more than 7 years ago | (#16090383)

Why do we need two, brand new, incompatible protocols to push data to browsers?

Re:Comet vs. SSE (0)

Anonymous Coward | more than 7 years ago | (#16090935)

Competition is good for us! It brings more innovation, better software, reduces costs, etc...

Re:Event Streaming to Browsers (0)

Anonymous Coward | more than 7 years ago | (#16090744)

HTTP supports persistent connections already..

Re:Event Streaming to Browsers (done in Anyterm) (0)

Anonymous Coward | more than 7 years ago | (#16091262)

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.

most underrated ajax framwork ever: echo2 (0)

Anonymous Coward | more than 7 years ago | (#16090315)

(and always forgotten in those roundups):
http://www.nextapp.com/platform/echo2/echo/ [nextapp.com]
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.

The best thing about AJAX (3, Interesting)

also-rr (980579) | more than 7 years ago | (#16090350)

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 [revis.co.uk] 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.

Dump Flash (2, Interesting)

Perp Atuitie (919967) | more than 7 years ago | (#16090375)

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.

What I REALLY do not understand about the web 2.0 (3, Insightful)

sploxx (622853) | more than 7 years ago | (#16090427)

... is why they are using the essentially useless HTML/HTTP stack with all the addtional layers (JS, AJAX, flash etc.) at all.

There are cross-platform thin-client network solutions like VNC [realvnc.com] or Nomachine's NX [nomachine.com] . 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. ... and you can use your favourite GUI toolkit to build applications.

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.

Re:What I REALLY do not understand about the web 2 (1)

SCY.tSCc. (514610) | more than 7 years ago | (#16090587)

... is why they are using the essentially useless HTML/HTTP stack with all the addtional layers (JS, AJAX, flash etc.) at all.
Because HTTP is one of the not-so-many-left protocols that go through firewalls, forced proxies and filters.

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? ;-)

Re:What I REALLY do not understand about the web 2 (1)

sploxx (622853) | more than 7 years ago | (#16090867)

Because HTTP is one of the not-so-many-left protocols that go through firewalls, forced proxies and filters.

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... :-) I'm exaggerating and simplifying a bit, but I think this is a very common pattern today.

Because a browser is all you've got when you use a public terminal.

They usually run on a fully-fledged GUI toolkit and a capable operating system...


Because WWW has the biggest user base ever.

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.

Oh, BTW, you're still using IPv4, don't you? ;-)

Sadly, yes! I'd like to have all these IPv6 multicasting capabilities :-)

Re:What I REALLY do not understand about the web 2 (1)

Bull SR (245263) | more than 7 years ago | (#16091267)

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

Re:What I REALLY do not understand about the web 2 (1)

RosenSama (836736) | more than 7 years ago | (#16091320)

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. ... and you can use your favourite GUI toolkit to build applications.
Am I thinking about this wrong? If you offer an application via VNC or NX the entire environment consists of more total resources, with the extra requirements falling on the backend.

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?

Save Applets (2, Interesting)

Doc Ruby (173196) | more than 7 years ago | (#16090499)

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.

Re:Save Applets (1)

l0b0 (803611) | more than 7 years ago | (#16091009)

There are several factors hindering this:

  • Provider control - It may be the only way for them to get advertising revenue, or they just don't want you to reverse engineer the system.
  • Data ownership - For sites like MySpace, giving you their data would be illegal.
  • Data amount - Why yes, I'd like to download the Google database. Now where did I put that USB stick?
  • Data changes - Sites like Digg, del.icio.us and your bank are no use offline.

Really, I can't see how most useful web pages today could be used "locally". The dynamic part is the real power of the web.

Re:Save Applets (1)

Doc Ruby (173196) | more than 7 years ago | (#16091358)

Huh? I just want to install their applet instead of caching it. I'm not talking about a local copy of their data, just a local copy of my data, that I use their applet to modify. Nor am I talking about going offline. I just want to be able to use their applets the same way I use my local applications. That doesn't exclude them embedding their own advertising, either.

Re:Save Applets (1)

l0b0 (803611) | more than 7 years ago | (#16091507)

For Flash, that's mostly just View Page Info -> Media -> Save As. Of course, some sites mess up even that. And Java applets are spawn of the devil anyway - I've only used a handful of them, but all of those would have been better of as static web pages (sic) or Flash. Dunno about those "online desktops" which have popped up lately, but don't they allow you to add any URL?

The answer is WebStart (3, Informative)

drgonzo59 (747139) | more than 7 years ago | (#16091083)

Java's WebStart solves this exact problem. We are not talking about Applets. These are more like full Java applications that the user can launch just by clicking on a link in the browser. The applications then load along with any necessary libraries and are cached on the users' computer. Optionally the user can even include it in the Start/Gnome/KDE menu.

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.

Stuff like that oftens break with complexity (2, Interesting)

cruachan (113813) | more than 7 years ago | (#16090510)

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/ [tinybutstrong.com] templates, AJAX using the xajax framework http://www.xajaxproject.org/ [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.

Re:Stuff like that oftens break with complexity (0)

Anonymous Coward | more than 7 years ago | (#16091543)

"if you do any coding with PHP"...

then you are an idiot. Seriously, PHP is a template language, how stupid do you have to be to want a template langauge written in a template language to do the job that PHP is already supposed to do. Go learn another language. ANY other language. You will thank me.

Some quick insights and clarifications (5, Informative)

rtilghman (736281) | more than 7 years ago | (#16090518)

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/ [flickr.com]

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 time that a court has actually stated that a web site must be ADA compliant, and the implications are pretty big for ALL RIA SOLUTIONS, but probably more so Flex, Lazlo, and others than for AJAX/DHTML. Its possible to make Flex/Flash more friendly, but its more expensive and more difficult, and there aren't any really good solutions out there at the moments.

Platform Reviews
To be honest I'm not really sure why .Net and Mozilla are included in this round-up... I'm not aware of anything anyone is doing with them at present, so I don't even consider them bit players in the space. How about Nexaweb? How about TIBCO? Yes, MS is bringing out their own proprietary format, which is actually kind of stupid since they could easily have embraced SVG in Adobe's absence, developed an architecture that leveraged it, and relied on the OSS community to feed the beast from a component/visualization perspective. But why talk about something that's just on the radar over platforms that are out there now? Also,I believe the comments on XML and Flex 2.0 are wholly inaccurate... I guess limited can be qualified, but afaik Flex supports XML.

Summary
In general not a bad overview. Limited, light, and fluffy, but useful for people who don't know much about the space.

-rt

Re:Some quick insights and clarifications (2, Insightful)

drgonzo59 (747139) | more than 7 years ago | (#16090863)

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.

That's what happens when you are not prepared for travel!

How good are you Java programming skills? What were your expectations? Have you tried WebStart?

I think Java still has a place for specialized rich clients. I have recently released a Java3D scientific visualization application that uses WebStart. It automatically downloads all the Java3D libraries it needs and caches them on the user's machine, then it is able to use native OpenGL drivers. All the user has to do is to click on the JNLP link in the browser. The application works on Windows, Linux and Mac with with all the popular browsers. I am not saying it was trivial to write it but it can be done, one just needs to know Java at more than the beginner level. Flash/JavaScript/SVG would not have worked for what I needed to do.

Will we see major web portals using Java applications as their interface? - Probably not. But that doesn't mean Java is dead and Ajax is a panacea for all the Internet problems.

MS vs. SVG (1)

overshoot (39700) | more than 7 years ago | (#16091056)

MS is bringing out their own proprietary format, which is actually kind of stupid since they could easily have embraced SVG in Adobe's absence, developed an architecture that leveraged it, and relied on the OSS community to feed the beast from a component/visualization perspective.

Yeah, they could have. However, there are at least three big show-stoppers to that idea:

  • Not Invented Here. MS simply doesn't do other people's standards unless they are playing catch-up.
  • No differentiation. Anyone can do SVG as well on non-MS platforms as MS can on their own. That keeps MS from relegating every non-MS platform to second- and third-rate status.
  • They can't shut off competing implementations. Their ability to kill off non-MS "WPF/E" clients is a key strategic asset and they're not about to give it up.

AJAX Sucks (1)

RAMMS+EIN (578166) | more than 7 years ago | (#16090524)

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.

Re:AJAX Sucks (1)

suggsjc (726146) | more than 7 years ago | (#16090896)

Javascript isn't an entirely horrible language. It isn't as full featured as Java, C/C++/C#, perl, etc. However, it is a decent OO language. Most people don't know/use half of its capabilities. So your question of whether or not javascript can cut it...is *probably* yes.

There are no one size fits all solutions, but XUL could be a decent platform for some projects.

AJAX might be ok... (0)

Anonymous Coward | more than 7 years ago | (#16090618)

as long as they don't discriminate against the blind [slashdot.org] .

Right click anyone? (1)

Space_Nerd (255762) | more than 7 years ago | (#16090624)

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.

Re:Right click anyone? (0)

Anonymous Coward | more than 7 years ago | (#16091168)

If you want right-click, don't use a web browser for your application.

Breaking the Model of the Web (1)

Pfhorrest (545131) | more than 7 years ago | (#16090674)

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.

Radio Mixtape uses both (1)

sryx (34524) | more than 7 years ago | (#16090679)

At Radio Mixtape [radiomixtape.com] (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

"Flash-player does not include XML capabilities" (1)

mad.frog (525085) | more than 7 years ago | (#16090688)

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 [wikipedia.org] support as part of ActionScript 3, which puts it far ahead of most other solutions.

Re:"Flash-player does not include XML capabilities (1)

sryx (34524) | more than 7 years ago | (#16090973)

<a href="http://www.radiomixtape.com">Radio Mixtape</a> 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

MochiKit makes AJAX suck less (1)

witten (5796) | more than 7 years ago | (#16090728)

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 [mochikit.com] , 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 [coderific.com] .

Diagrams (1)

natrius (642724) | more than 7 years ago | (#16090812)

This is slightly off-topic, but what's the point of making a diagram if you're going to make it this complicated? [zdnet.com] 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.

Coverage of WinFx was woeful.... (1)

MickDownUnder (627418) | more than 7 years ago | (#16091043)

"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 ?

Eclipse RCP Applications (1)

kdekorte (8768) | more than 7 years ago | (#16091178)

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.

ZOPE (1)

Lodragandraoidh (639696) | more than 7 years ago | (#16091312)

He missed ZOPE [zope.org] , with such add-ons as the Plone content management system [plone.org] , 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.

Bleedin' 'eck I hope AJAX gets some help... (1)

Elbowgeek (633324) | more than 7 years ago | (#16091349)

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.

This is one war ... (1)

Spiked_Three (626260) | more than 7 years ago | (#16091506)

where I wish someone would just drop a nuc on all the participants.

WTF does so many people crave web apps to begin with?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...