Which RIA Are You Dying to Use?

[brad jones]

Check out my newest blog entry for Codeguru (sister site of VBForums):

Which RIA Are You Dying to Use? (http://blog.codeguru.com/blog/2009/04/which-ria-are-you-dying-to-use.html)

Which RIA do you plan to use?

Brad!

[techgnome]

What the heck is "RIA" ??? I know what the RIAA is... but I doubt that applies here.

-tg

[Harsh Gupta]

What the heck is "RIA" ??? I know what the RIAA is... but I doubt that applies here.

-tg
RIA - Rich Internet Applications

They are web application, with hint of windows applications and usually used via some browser add-ons or plug-ins. e.g. Silverlight, Adobe AIR, Adobe Flex etc.

[brad jones]

RIAs are generally full of Web 2.0 Features as well.

Brad!
Shameless Plug: Web 2.0 Heroes (http://books.internet.com/books/0470241993)

[RhinoBull]

RIA - Rich Internet Applications
RIA - Rare Isotop Accelerator (http://www.orau.org/RIA/) :).

[techgnome]

Really Insane Acronym ... seriously though, do we really need another acronym for something that has been around for some time?

Or do I not get it? I don't do web development on a regular basis, and when I do it's been PHP/server side ... and I've only just now gotten around to picking up a book on Ajax to see what the fuss is all about.

-tg

[brad jones]

You guys are funny. You need to get out a bit more too. RIA (for Rich Internet Applications) has been around for a long time now. It is not a new acronym from a technology perspective. It has been in common use for a year or two at least.

RIA doesn't necessarily imply just client side. It really implies a richness in the application. It is really characterized as the ability to pull "desktop" features and functionality into Web applications. I mention Web 2.0 only because the Web 2.0 features are what has tended to pull in more RIA features. Or maybe it is that the RIA features have allowed for Web 2.0 to happen... :S :)

Brad!

[RhinoBull]

Really Insane Acronym ... seriously though, do we really need another acronym for something that has been around for some time?

Or do I not get it? I don't do web development on a regular basis, and when I do it's been PHP/server side ... and I've only just now gotten around to picking up a book on Ajax to see what the fuss is all about.

-tg
Same thoughts here... :ehh:
And if "experts" don't even know (or can't agree upon) what it means then what's left for us? Guessing? :rolleyes:
I think it will be more and more of those things popping out now and then - lots of guys out of work and they will try to do something. Unfortunately most of what will ever come out will be completely useless.
But boy, we will have plenty of acronyms...

[timeshifter]

Bah. I use jQuery. I can make web apps run as smooth as most desktop applications with some slick JS and AJAX. I don't need any plug-ins. In fact, I personally find that a drawback. I have quite a few extensions installed for Fx already, and I really don't want to have to deal with something big like Silverlight getting thrown in the mix. Flash and Java are pain enough as it is. If you have a browser made after about 2003, my websites will work in it, plain and simple. And that's how I like it.

[brad jones]

And if "experts" don't even know (or can't agree upon) what it means then what's left for us? Guessing? :rolleyes:


We write books about it...... aka, my Web 2.0 Heroes (http://books.internet.com/books/0470241993)book ;) :D

[brad jones]

I use jQuery. I can make web apps run as smooth as most desktop applications with some slick JS and AJAX.....

RIA can be done with anything. It is a concept like OO is a concept. It doesn't preclude you from using specific tool or language....

[NeedSomeAnswers]

Well i have used Flex in a previous Job and liked it a lot but there is not much of a market for Flex Developers in the UK even less so outside London.

i would love to use Flex again, although now i am back using .Net mainly c# so i guess i would be interested in using Silverlight to see how it stacks up from a development point of view.

[mendhak]

I'm surprised Silverlight's actually that high up.

[NeedSomeAnswers]

I'm surprised Silverlight's actually that high up.

I heard version 2.0 is a lot better, i wouldn't even touch version 1.0.

Although i have never used it myself, the one worrying thing i have heard is the it can be very gpu intensive. Most places i have worked all the machines have a fairly crappy graphics card spec.

Flex is great to program with, so i am interested to see if Silverlight is any good.

[FunkyDexter]

I haven't decided so I'm going to use a Provisional RIA... I want to gain some tangible benefit, though, so it will have to be a Real RIA... Also, I don't want it to have a short shelf life so I'll make sure it's a Continuity RIA... Too soon?

Being a little more serious, isn't the whole web 2.0 thing moving us back towards a dumb terminal model? Don't get me wrong, I get that making web pages etc more user freindly is a good thing but I'm coming across an increasing number of essentially desktop targetted apps that are written in browsers for little or no benefit that I can see.

And conversly, isn't all this extra stuff moving us away from a thin client model anyway. What we're moving towards is a fat, though consistent, client.

I'm not a web programmer so I'm probably missing the point here.

[NeedSomeAnswers]

I thought 1 of the main points as far as i see of RIA's is to provide Desktop like functionality on the Web.

[timeshifter]

The wonderful thing is, a skilled web coder can do that without any RIA's. I do it all the time. Like any technology, it's all about knowing what your capabilities are. And with web, pretty much anything you can imagine inside browser is possible, it just takes someone determined enough to figure out how. I wrote an extremely fast, AJAX-driven system for managing fleet installations about 8 months ago... designed to handle tens of thousands of vehicles for any given project, distributed across any number of locations, without so much as slowing down. Has a pretty detailed level of user customization, too, and in the past 8 months, I think my chat room is the only thing I've written that can compete with it in terms of desktop-like usability. I'm one of those who fails to see the need for Flash, Silverlight, or any of the others, since I can make JavaScript and AJAX do everything I need, and unlike the others, I don't require browser plug-ins and other large installs that none of us really want to deal with. All I ask is that you're using a decent browser (not IE6), and you're all set to run my software. Very high accessibility, platform-independent, and actually fun in some cases. But that's just me.

[mendhak]

While it's true that the new frameworks out and coming out give you a lot of capabilities, it's a little unsafe in the wrong hands. The temptation with these frameworks in web applications is to start putting everything, including business logic, right into the client. Not everything, but significant bits. That's a sin, obviously, as it does go against the concept of a thin client, which is what the web is supposed to be about. Or rather, proper web apps.

But you can't apply that to every web site or application; a serious web app, yes, I'd definitely expect it to be serious about my data and not have a cavalier attitude. Some apps though, it's alright to bring out a little richness.

Now, to think of an example... take GMail. If you've been reading the news properly over the past few years, their extensive use of AJAX is rather unnerving because they're not the best when it comes to security. Even a person like me was able to mess around and impersonate another user. Considering that, I decided that I didn't want my personal emails floating around there, so I've mostly abandoned it. Now I know that some of you out there are true die-hard Google brown-no... I mean Google lovers. Please bear in mind that just because a company appears wonderful and benevolent and large doesn't mean it is devoid of idiots. Idiots are everywhere.

More recently, one of my favorite pizza companies whose name sounds like Jaja Pohns made their payment section javascript based. I don't care if they think it's secure or not. I am not a Mactard, I have a brain, and therefore I do not think it's secure and I cannot trust that they've done the right thing - in fact, they've already broken a big rule and put some of the business logic right into the page. They've lost a valuable customer who used to order from them regularly. Regularly! :mad:

If you don't see anything wrong with any of the previous two 'scenarios' then only divine intervention can help you.

Now take an example from the other end of the spectrum. VBForums upgrade. A little javascript lets us expand the quick reply box, lets us edit inline and quote multiples. I think that's pretty good and it degrades gracefully too.


So my point is - it's good, but to add richness to the app. I don't want business logic in there, there's always a danger point.

[Pino]

Very interesting post Mendhak.

Can we dig a little deeper into what you have said, when you say the business logic is in the javascript I'm sure they wont have there credit card processing in there ;) So how is using AJAX to submit the credit card (for example) data any less secure than posting it to a seperate script?

Or have I missed the point completley.

Pino

[dilettante]

This "RIA" sounds like a result you produce, not the toolset.

The expansion of the acronym just makes me think "silk purse from a sow's ear." So far my experience with these has been terrible. Just look at those Ajax/Flash/etc. heavy sites like those for viewing TV and movies. You constantly end up clicking in the wrong places, the scroll wheel goes dead, etc. because the #@$%& Ajax steals focus away or jumps it all over the page.

Even Amazon's site is becoming unusable.

Clickity-click like a monkey on drugs.

We ditched a front-end for an in-house application of this style before it got halfway built. Can you say "usability zero?" I think you can.

I'm hoping this fad finally passes. We have easy deployment via ClickOnce and reg-free COM now. And rumors to the contrary, the Mac market does not matter - Linux even less.

[brad jones]

This "RIA" sounds like a result you produce, not the toolset.


Actually, it is. But many of us talk about the tools when we talk about RIA even though that is technically not accurate. That is like calling cows dairy products. They (cows) are dairy producers not dairy products ;) :)

Flex, Silverlight, Curl are RIA producers.

Brad!

[techgnome]

So the question is flawed, and should have read "What RIA-Producing Toolset can you not wait to get your grubby little hands on?" ;)

-tg

[NeedSomeAnswers]

The temptation with these frameworks in web applications is to start putting everything, including business logic, right into the client. Not everything, but significant bits. That's a sin, obviously, as it does go against the concept of a thin client, which is what the web is supposed to be about. Or rather, proper web apps.

Yeh but that's just bad design, you can create bad applications in most languages, admittedly some languages make it easier than others.


The expansion of the acronym just makes me think "silk purse from a sow's ear." So far my experience with these has been terrible. Just look at those Ajax/Flash/etc. heavy sites like those for viewing TV and movies. You constantly end up clicking in the wrong places, the scroll wheel goes dead, etc. because the #@$%& Ajax steals focus away or jumps it all over the page.

I think that is a bit of a one eyed opinion.

So you have been to a few sites that aren't built very well, i have used many a Windows App that are pretty rubbish, maybe we should stop developing them to !!!!

So do you think that Web Development should just be static web pages of information then ?

RIA - Your are right on that part, there are several toolsets that are all capable of making Web Apps with richer features. It does indeed refer to the type of Application you can create rather than what you build it with.

[timeshifter]

Part of the problem with having client-side logic is that it really does boil down to methods and conditionals. If one were to dig into the code behind say a login button, they might not be able to "properly" log in (say if a database record was added to store a log of the user's activity), but they could still follow the callback trail to see what happens *after* the page gets confirmation of the user's credentials. If the login is based on session data, as mine are, then it won't do them a lot of good, but that's beside the point. The point is that they could manually trigger the code that follows a successful login, which could feasibly put an application's database at risk.

[dilettante]

So you have been to a few sites that aren't built very well, i have used many a Windows App that are pretty rubbish, maybe we should stop developing them to !!!!
No, I don't think it's a few sites. Most Ajaxy sites suffer from the same problems, though the heavier ones are worse of course. Even this very site attempts such things, with annoyances and varying success.
So do you think that Web Development should just be static web pages of information then ?
Largely, yes. The Web is about information, not applications. But when you must build a Web application it works best to leave most logic at the server. I wouldn't cry in the least to see floppy dropdown effects and such disappear from the Web.


You can only make the server just so thin anyway for most applications. Even if you stick to a strict fat client model (ignoring browsers for the moment) you run into problems that either risk data corruption or limit you to applications that can live with asynchronous processing.

A classic "data corruption" risk is the old MS Access model, where allowing random updates of the MDB database could cause problems when clients failed or lost connectivity while holding dirty pages of the file in local buffers.

The async processing issue is a little harder to describe. An example might be something like order processing though. I wouldn't trust client logic to "sell" an item and remove it from the global inventory. More likely I'd want logic on the back end to perform global operations of that sort, and later send or make available "order results" info that may have to say (perhaps hours later) "sorry, item X is sold out."

This is actually quite common, and why so many order entry systems send back email responses with final, binding results. Often there is no choice: you can't have all of the information required to make a binding decision "online" and able to process an Ajaxy RPC-style request/response. Other times you could, but then you'd sacrifice scalability (and lose sales).

There is also the issue of reliable messaging, which Ajax JSON or SOAP calls ain't. Raw HTTP is notoriously unreliable. By definition a busy HTTP server is allowed to just drop a request or connection. Surely you've had broken pages arrive, requiring a "refresh" or two before you have everything needed to fully render the page?

[FunkyDexter]

Just watching the bells and whistle bit of the conversation and I think there's a definite difference in attitude between web and desktop developers. I'm about to make some heeeuuuge generalisations here and I hope I don't offend anyone (actually that's not true, I'm a developer so I live to offend people - there you go, generalisation no 1, right there).

Desktop developers (of which I'm one) worry about functionality. In our opinion presentation is for wimps. There are only three colours in our world, grey, blue and white - and technically white isn't a colour so there's only two. See, we've even reduced the complexity of the spectrum to a binary function. Buttons are square. There are two kinds of buttons: OK and Cancel. They have OK and Cancel written on them so you know which is which. Pictures? Pictures?! We don't want no steenking pictures.

Web developers are different and strange. They worry about what things look like. They delve into hues of orange and green and use bizarre techniques like 'shading'. Their buttons are funny shapes. Sometimes you can't tell they're buttons at all, let alone what they do. Hell, sometimes their buttons even move around the screen, fleeing from the cursor like a politician from the truth. It's bright, it's dazzling, it's flashy. It's also completely dissfunctional but that's beside the point... look... look... my buttons rotating... ROTATING!

Face it. We're never going to agree. We're just too different. Some people claim they're both both desktop and web developer. These people are clearly deluded.

[szlamany]

...Some people claim they're both both desktop and web developer. These people are clearly deluded.Some of us have this forced upon us!

I have to agree with you though that Winforms are all about functionality - and the reality with VS a Winform can really only be written one way to perform an operation in it's ultimate fashion.

If a tree-view with a tab'd control with 2 buttons works best - then that's really the best way - you don't spend a whole week thinking about the GUI's interaction with the user and the "backend".

But with a webform there are 15 ways to accomplish "xyz" - Javascript? Ajax? What's-new-today? And each of these will or won't work properly with each browser you might encounter (why do people still use IE6?).

Being a VB.Net winform developer, I prefer to have my shop code ASP.Net pages with VB in the code behind. My web coder preferred PHP when he walked into the shop 10 months ago and I've been dragging him through the ASP'y world kicking and screaming.

Winform developers are comfortable in their "single-minded" world. Accomplish a goal? Easy - they've done exactly that logic 100's of times.

Webform developers need to become experts in uncovering how x relates to y and why z don't work with abc. And everything you do is new - so those x, y and z's become i, j and k's every day (or 10 times a day).

[brad jones]

FunkyDexter helped write my newest blog post: http://blog.codeguru.com/blog/2009/04/are-you-a-deluded-developer.html

It is funny that I get more discussion in the forums about my blog posts, than I get on my actual blogs :)

Brad!

[timeshifter]

I'm sorry, but as a web dev, I have to...

I'm a developer so I live to offend people - there you go, generalisation no 1, right there).
Are you implying that developers live to offend people? Because I've found that the customer spends a LOT more time offending me than I do them. Most of the time, I'm trying to appease them. Angry customers means no cash flow, and that's bad.

Desktop developers (of which I'm one) worry about functionality. In our opinion presentation is for wimps. There are only three colours in our world, grey, blue and white - and technically white isn't a colour so there's only two. See, we've even reduced the complexity of the spectrum to a binary function. Buttons are square. There are two kinds of buttons: OK and Cancel. They have OK and Cancel written on them so you know which is which. Pictures? Pictures?! We don't want no steenking pictures.

Web developers are different and strange. They worry about what things look like. They delve into hues of orange and green and use bizarre techniques like 'shading'. Their buttons are funny shapes. Sometimes you can't tell they're buttons at all, let alone what they do. Hell, sometimes their buttons even move around the screen, fleeing from the cursor like a politician from the truth. It's bright, it's dazzling, it's flashy. It's also completely dissfunctional but that's beside the point... look... look... my buttons rotating... ROTATING!
I think you've got "developer" and "designer" mixed up. You should see the internal web app that I spend most of my work time building. It's got 1 gradient image, and that's the header bar. Everything else is very blocky, driven PURELY by CSS. No images in the design at all. It's a web-based data management application. It does the same thing an equivalent desktop application would do, and doesn't look any better, but the advantage is global accessibility.

Face it. We're never going to agree. We're just too different. Some people claim they're both both desktop and web developer. These people are clearly deluded.
Yeah, deluded probably is a good word for me... I write what is essentially a folder explorer that's retrieving information through a web service as a desktop app, then turn around and write an AJAX-based treeview that's completely dynamic and has no limit on depth, then go back to my bitmap pointers and real-time video manipulation in my desktop apps. Web and desktop apps (with .Net, anyway) are both based on the same framework. Granted, they use different pieces of it, but there's a fair bit that's quite similar. With the AJAX work I do, I come ever closer to truly replicating desktop-like functionality in a web browser. That's my goal: to prove that almost anything you can do with a desktop app, I can do in a browser. And I can make that goal because I understand how both work. I don't see any dividing line between the two. It takes a different style of coding to do either one of them, sure, but not so different that it creates a barrier between the two.

[NeedSomeAnswers]

What is it about Web Development that gets so many WinForms developers backs up ????

Development is Development is Development !!! i couldn't really care less what type of development i am working on.

I agree with TimeShifter on this one;

I think you've got "developer" and "designer" mixed up

Anyone who believes that Web Development is all about Design clearly has no idea about Web Development !!!

I mean i have done Web Development, and i am almost devoid of all Design skills whatsoever, i am about as artistic as whoever designed the London Olympics logo !, but i design applications not a web pages !!!

I couldn't design someone a website, well i probably could but it wouldn't be any good

Then again i might just be Deluded :0)

[NeedSomeAnswers]

Largely, yes. The Web is about information, not applications.

1 question, do you shop online ?

[timeshifter]

I'm starting to think desktop devs might actually be a little jealous of those who excel in the web field... the truth is, as was previously mentioned, our technology changes very quickly, and in order to be good, we have to adapt very quickly. Not to mention, we have multiple languages we need to be fluent in before we can even get started... HTML, VB/C#, and ASP.NET are all absolute must-know's, and if you plan on doing anything "web 2.0", you'd better be good with JavaScript as well. Dealing with data? T-SQL goes on the list. Trying to make really smooth AJAX-driven applications? You'll probably want to know jQuery. Our development field is very unstable, and the best of the best can cope with all of it and harness the power that it provides. Application devs get a major update what, every couple years with a new framework? And even then, old applications will still work. The same can be said for web apps, but if you build a site with intent to be cutting edge, you really do have to stay on top of it, because it'll be behind in a couple months. That, and web apps have some pretty big inherent security concerns that most desktop devs don't have to worry about...

[FunkyDexter]

Yay, I'm net famous at last! Thanks, Brad. I'm really touched by that.

Just to be clear I didn't really mean to deride either web or desktop developers or those poor deluded fools whe think they're doing both;). My post was a deliberate exageration of the worst excesses I come across from both sides of the fence. And of course there's a huge overlap between the two.

I actually do think there's a tendancy to aproach things with a different mindset, though. Desktop aplications do still tend to be Bauhasian monaliths that belong in some Kafkaesque office space where the employees shuffle between cubicles staring at the grey carpets. And Web Sites, even those that offer functionality, do occasionally stray in the kind of wierd pschyadelia my parents pursued in the 60s. Of course, there are also nice bright shiny desktop apps that make you feel warm and fuzzy when you fire them up, just as there are lean and efficient web apps that get the user to their goal with the minimum of fuss and fanfare. But if you were to plot a scatter graph of each type of app I'm willing to bet you would see definite groupings.

Also, I probably did muddle up Web Designers and Web Developers but isn't that part of the underlying difference. Desktop Developers don't have designers! Ask one of us who designed the application and we'll scratch our heads and mutter that "I printed the DB design out from sql server. Will that do?"

[timeshifter]

The company I work at has a web designer, but she doesn't really do much designing anymore. Our last designer made a few good designs that we all like, and we've just been using them. Our public sites (probably at least a dozen of them) do need to be spruced up, either to look like a client's site, or just to be pretty... but our internal application looks like junk. We need no designer for it. It's sole purpose is functionality, and as a result, it's getting more and more AJAX code all the time. Why? Because with AJAX, I can have a web page with 10,000 data entry fields and no update button. Make a change, and the database records it, instantly. When properly used, AJAX can be a massive gain in functionality and usability... but when someone goes all MySpace or Facebook with it, that's where it becomes a problem. Have half a brain about the application being built, and it shouldn't be hard to avoid overdoing it.

[mendhak]

Very interesting post Mendhak.

Can we dig a little deeper into what you have said, when you say the business logic is in the javascript I'm sure they wont have there credit card processing in there ;) So how is using AJAX to submit the credit card (for example) data any less secure than posting it to a seperate script?

Or have I missed the point completley.

Pino
It exposes the service endpoint or page to anyone who wants to look and perform their own submissions, bypassing all the other validation routines that the developer may have introduced in the page. When you create a credit card processing service, you don't want anyone fiddling with it at all. You want your client application to talk to it, not Joe Bloggs and his copy of Fiddler2.

Then there's the psychology factor. It exists for me, at least and I definitely believe in it. If a developer is placing bits of BL in the Javascript, then he inherently writes sloppy code. If a developer writes sloppy code, then he inherently introduces security holes. Again, I exclude Facebook from this (although they've had security exploits which have spread due to their use of Javascript, and I don't understand why they call it a virus).

[brad jones]

Desktop Developers don't have designers! Ask one of us who designed the application and we'll scratch our heads and mutter....


I feel another blog entry coming..... :D:D:D

Brad!

[dilettante]

Isn't this all a little passé now?

It's had its run, from ActiveX controls and Java applets to Flash applications. It has its place, but it isn't an answer to everything. I'm not sure ajaxy pages fit the description at all myself. Isn't the return to RIA an attempt to band-aid over the limitations and general clunkiness of ajax approaches?

In reaction to the limitations of RIA we're now seeing a budding trend toward "Cloud Computing." This looks more like an attempt to make the old client-server model work via the Internet without being strictly limited to the failed "Smart Client/Web Services" model that has also achieved only limited success.


In the end though isn't it all about having a larger toolkit? None of these is "the" answer. Maybe it makes more sense to start a thread listing different approaches and cataloging different strengths and weaknesses. I suppose the extreme ends of the spectrum are isolated purely desktop applications (Word?) and very-thin terminal to host applications (Telnet BBSs?).

[timeshifter]

The way I see it, AJAX is the most un-structured toolkit available, in that it's more of a concept than an actual piece of code. jQuery is simply an awesome framework, and combining the power it has with the concept of using AJAX, you can create damn near anything you can imagine. Your capabilities are really only limited by your willingness to keep trying. I've used AJAX to make entire pages run extremely smoothly (at the cost of at the worst, a bit of extra code to send through the pipe), and I've used it to take existing, slow applications and add important functionality with only a minimal increase in code size. I think ones' view of AJAX can be summed up by what they're capable of doing or willing to learn with it. The more I delve in and see what's possible, the more I pull off, and the more I like the whole idea of using jQuery and AJAX to enhance my applications.

[brad jones]

Real Developers Don’t Need No Designers (http://blog.codeguru.com/blog/2009/04/real-developers-dont-need-no-d.html)

Thanks to FunkyDexter, I've created yet another blog entry as a result of this thread... ;) :)

Brad!

[mendhak]

Ah but WPF is going to change all that, isn't it?

[brad jones]

Ah but WPF is going to change all that, isn't it?

Ah, you mean it will bring the gory-ness of Windows app layout to the web, or do you mean that it will bring web flexiblity to Windows?

If you mean the later, then it (windows apps not needing designers) is really about standards rather than a 'layout' technology.

[visualAd]

I can speak here from both sides of the fence and sit in the middle like some kind of quantum superposition as I no longer officially work as a developer. Generalising, desktop and web development share many attributes and exist to fulfil pretty much the same purpose'; to design a tool / library or application that solves a problem.

Concepts and methodologies of desktop programming can and have been ported to web programming and vice versa. It is my opinion that the increased prominence of the web will push these two fields close together and blur the distinction between the two until they mean one and the same thing.


Web programming has come on leaps and bounds since I first started in 2002. Back then a typical web based application consisted of a few static HTML pages, a bit of HTML produced on the fly by a Perl or CGI application and some hideous examples of DHTML. The design side of web development seemed to be focused wholly on competing to see how many tables you could fit onto a single page, a legacy that unfortunately exists to this day.

There is now a clear distinction between design and programming in web development. Unlike the desktop environment, the front end of a web application exists in an unpredictable and hostile environment - the users web browser. Web browsers come in many different shapes and flavours, they also sit on many different types of machines devices and operating systems, they have their own features, caveats, bugs and security flaws. Add into the mix Javascript, which makes AJAX applications possible and again differs across browsers, devices and OSes. Designing a functional UI in this environment is like trying to build a desktop app that looks, functions and feels identical on every version of Windows, Linux and MacOs that ever existed. So it is no surprise that their are experts in the field of web design and in the field of web development and experts who specialise in both areas.

Things are getting better though; ASP.NET makes the design of the Web Based UI somewhat easier but has a long way to go. There are now toolkits that are marrying Javascript with the back end by treating it as a compiled form of the back end programming language and browser / device vendors are coming around to the idea that following the standards set out by W3C is the only way to promote better the development of rich content web applications.

IMO, a web developer needs to have knowledge and command of both the languages that drive the back end and the languages that produce the front end as well as an understanding of the protocols that transport the content to the users browser. Coming initially from a desktop development background, I found that web development forced me into a different mindset. The application had to be seen at minimum in terms of its functionality and the UI, with the UI simply being the strings the control the functionality puppet. I was then able to transfer this ideology to the desktop programming language and reap the benefits. Conversely, I was also able to take across to web development many of the best practices surrounding OOP and desktop application design to benefit the web applications that I developed.

I think that referring to those who have or do do both web development and desktop development as deluded demonstrates a lack of understanding and a lack of communication between two communities of very talented individuals who like it or loath it will have to start working together in the future.

[DeanMc]

Here's my view on the whole situation,

I currently feel that we are not utilizing the web fully. Currently most web applications are ran via a web browser. I think this is counter intuitive as as an application the web browser was designed for displaying documents. I feel that this would be akin to run web applications through adobe reader.

Somewhere along the line we learned how to make simple applications that make our browsing experience more pleasant while viewing through a browser. But I think the fact that most technologies targeting the web are browser dependent.

I am currently working on a new style application that will work much like the NXE dashboard on the XBOX360. The NXE dashboard while quirky in its own right, it does show the different ways in which the web is utilized to display information.

To your original question brad, I think I am most looking forward to taking a look at web services and thick applications via WPF that is not browser limited. Check my blog post below for more information on my new application.

As an interesting side note: How many web developers think the browser is your most limiting factor?

[brad jones]

How many web developers think the browser is your most limiting factor?

Is it the browser or is it the standards used by the browser that are limiting?

The point of standards is to allow for your application to work across more systems seemlessly. Do you lose that when you step out of the browser space?

[DeanMc]

Is it the browser or is it the standards used by the browser that are limiting?

The point of standards is to allow for your application to work across more systems seemlessly. Do you lose that when you step out of the browser space?

Hmmm, good questions. I believe the standards to make things harder but on a whole I believe the browser as a piece of software is too limiting for rich web applications to truly take off. Its ambiguity I feel is its limiting factor.


I believe that stepping out of the browser space may not necessarily reduce the amount of people who can view your content if companies like Microsoft took things like the .NET framework further.