Web Clients, the role of ASP.NET and the Future of Web Development and Web Standards

[Guadala Harry]

This inquiry has to do with the client capabilities and Web client
experience:

I've been developing rich client apps (Windows desktop client exes in n-tier
architecture) for over 10 years and am relatively new to Web client
development. The other day, Kevin Spencer told someone that Web development
is arguably the most difficult type of programming to do. I couldn't agree
more. In many ways it seems to me that in order to develop non trivial
functionality into a Web application, we have to spend a relatively long
amount of time/effort (relative to achieving similar result in a Windows
client) - and we have to think very hard about the tradeoffs between
functionality and performance... e.g., if you want something approaching the
functionality provided in a Windows client app you suddenly have the
likelihood of a gigantic ViewState with associated performance issues... and
that's if you can assume an uplevel browser or even IE in particular. I
understand that ASP.NET - at the end of the day - simply provides us with
powerful tools and methodologies with which we can more easily work with the
existing Web standards (http/html, etc) on the server side. Powerful as
ASP.NET is, it is tied to the basic request/response model of http as we now
know it - and that is where the client experience is limited.

Three Questions:
1. Is my above assessment of ASP.NET and the role it currently plays
basically correct?

2. What are the next major changes we can expect in Internet programming
during the next 10 years? Do you think we'll still be programming against a
basic request/response model in which we pretty much send text around the
Internet? I'm trying to get a grip on where we are in the current paradigm,
and when it is likely to shift.

Please note I do understand Web Services and the SOA in general - but that's
all beyond the client; what I'm primarily interested in is the client
experience and client capabilities. At the end of the day it doesn't matter
if your HTML/XHTML/CSS etc comes from Web Service or Web Application - there
are still huge limitations in the clients as we currently know them.

Thanks!

-GH

 

[darrel]

Three Questions:
1. Is my above assessment of ASP.NET and the role it currently plays
basically correct?

Sure, but that's really true of any web-centric programming/scripting
language, is it not?

2. What are the next major changes we can expect in Internet programming
during the next 10 years?

Web development or internet programming?

10 years? That's really impossible to day.

Short term? Microsoft will wake up, see Firefox kicking it's ass, and get
IE7 out the door sooner than later...giving us developers a set of browsers
that are actually more alike than different for once. ;o)

Mid-term, companies will begin to see the absolute crap that most commercial
vendors of web-based software product. This is more of a hope than a
prediction, though. ;o)

Do you think we'll still be programming against a
basic request/response model in which we pretty much send text around the
Internet?

If you're talking Web, ie HTTP, then yes. If you don't like that, there are
other protocols that you can use right now if you'd like.

Please note I do understand Web Services and the SOA in general - but that's
all beyond the client; what I'm primarily interested in is the client
experience and client capabilities. At the end of the day it doesn't matter
if your HTML/XHTML/CSS etc comes from Web Service or Web Application - there
are still huge limitations in the clients as we currently know them.

What some call limitations, others call the nature of the medium. Yes, there
are things you can't do with web pages. But the benefits is that it's a more
universal protocol. A trade off? Sure. But I don't like to think of it as a
limitation.

*Note I am not an expert on any of this. All the above IMHO. ;o)

Good topic, BTW...would love to see other's thoughts on it.

-Darrel

 

[Marina]

As far as I know, MS is really trying to push winforms, particularly
deplying winforms over the web, instead of traditional asp.net programming.
They are working on better one click downloading, having the program check
for updates of itself every time it is launched, etc.

As far as I know though, they haven't provided any solutions to the
configuration/security issues that come along with this - i.e. having to
have each user go through configuring .net security on their machine in
order for the program to be able to do anything useful.

The other issue is that it requries the user have the .net framework
installed, though I think that will become less of an issue as .net will be
preinstalled everywhere, etc. Although it will definitely be a problem for
places trying to support people on non Windows machines - so that will be a
stopping block for many.

I am not sure how easy it will be to switch to this new approach. I think
you can do very powerful stuff with the web, and make the interface very
usable and responsive with the help of client side script. ASP.NET's
controls are all heavily server side based, and have very little client
script to make the controls do more work on the client.

I think only time will tell how willing people are to switching to
programming their web based apps in winforms, and how willing their clients
are with dealing with it.

 

[Scott Allen]

Hi GMan:

2. What are the next major changes we can expect in Internet programming
during the next 10 years? Do you think we'll still be programming against a
basic request/response model in which we pretty much send text around the
Internet? I'm trying to get a grip on where we are in the current paradigm,
and when it is likely to shift.

Hopefully in 10 years we will have a client that does more than just
parse HTML. Saying the browser "just parses HTML" is a bit of an
exaggeration of course, but relatively speaking, what we have is not
too far from that behavior. We should be able to push smarter code to
execute on the client. Smarter than the code that adds a javascript
alert ('Are you sure you want to delete this record?'); that shows up
again if the user goes to another page and hits the back button.

I think the basic request/response model will be around for a long
time, longer than 10 years. I think having the ability to respond and
interact with the user in a rich way in between those request/response
pairs is what we have to get to. A couple technologies will move the
MS platform in that direction (click once deployment in VS2005,
Indigo, Longhorn), but I don't know how everyone else gets there, and
I don't know how those technologies will pan out as yet, either.

So there is my 1 cent

 

[Guadala Harry]

<< What some call limitations, others call the nature of the medium.>>

I like your benevolent attitude - but in the end if you can't do something,
you're limited (by definition). Please understand I'm talking about real
basic things here - like if I want a box that has rounded corners - rather
than square corners. The "nature of the medium" is that you can't set
properties on some UI widget and get the arc - rather you have to create a
graphic image with lines that have the desired curvature (in Photoshop or
Fireworks, etc), chop up the image into lotsa little images ("gifs") and
then create links to those images which are in turn embedded into a table or
placed with CSS etc. You have to copy all of those little images to a very
specific place on your Web Server and make sure that location makes sense
relative to all possible pages throughout your app that might re-use those
images - and then in each place that uses the images make sure that you
specify the path correctly. That's a lot of work just to get a simple box
with rounded corners! Oh, and don't move anything later! It'll all break
unless you go with absolute URLs everywhere which isn't really what you want
to be doing anyway - or drive the path from a database - but then you have
performance issues... and on and on it goes.

This is what I mean by limitations - and the sort of thing that makes me
think there's gotta be a better way - and that it hopefully won't be too far
away... thus my OP inquiry to people who may know what's next for Web Client
application development.

When I saw the Internet go mainstream in the mid 1990s I decided to avoid it
as standards were constantly shifting... and that was before the browser
wars. Then I was glad to be on the sidelines working blissfully in my rich
Windows environment while the browser wars raged. Now I can't avoid the
Internet any longer and the good news is that things have stabilized
considerably since all the rapid changes in the late '90s. But appears to me
that the Web development community has "stabilized" on on some quite
limiting technologies and methodologies. Talk about feeling like I'm
developing in slow motion... The scenario I presented above in a Windows GUI
app would take a couple of minutes (most of which are spent trying to find
the dialog box into which to specify the property values); but in a Web app
it could easily take over an hour to create and fully integrate all the
required pieces.

FWIW: I'm NOT being critical or complaining (okay, maybe just a little)....
just trying to gain some perspective to where we are with the whole Web
client thing.

Thanks for your opinion!

-GH

 

[Kevin Spencer]

Hi Harry,

1. Is my above assessment of ASP.NET and the role it currently plays
basically correct?

I would say yes.

2. What are the next major changes we can expect in Internet programming
during the next 10 years? Do you think we'll still be programming against a
basic request/response model in which we pretty much send text around the
Internet? I'm trying to get a grip on where we are in the current paradigm,
and when it is likely to shift.

According to Microsoft, it is "Service Oriented Programming," which is the
centerpiece of codename "Indigo," which is the distributed application
architecture being developed for Longhorn, as well as Windows XP and Windows
Server 2003 (it will be available as an add-on to the .Net platform). It is
..Net, but much like C++ is a superset of C, it is a superset of .Net. I
can't really say much more about it at this point (NDA), but you might want
to search microsoft.com for whatever information they are making public
about it.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Neither a follower
nor a lender be.

 

[darrel]

I like your benevolent attitude - but in the end if you can't do
something,

you're limited (by definition).

True. At the point, you pick a different medium.

Please understand I'm talking about real
basic things here - like if I want a box that has rounded corners - rather
than square corners. The "nature of the medium" is that you can't set
properties on some UI widget and get the arc - rather you have to create a
graphic image with lines that have the desired curvature (in Photoshop or
Fireworks, etc), chop up the image into lotsa little images ("gifs") and
then create links to those images which are in turn embedded into a table or
placed with CSS etc.

Sure. But you want rounded corners, this person wants drop shadows, this
person wants animated text, this person wants embedded fonts, this person
wants gamma correction, this person wants sounds, etc.

Anyways, CSS-3, when it comes along and is actually supported, will get us
heading in that direction for you.

But appears to me
that the Web development community has "stabilized" on on some quite
limiting technologies and methodologies.

We had too. MS and the rest weren't really getting along in terms of
agreeing to work with the same set of standards.

Talk about feeling like I'm
developing in slow motion... The scenario I presented above in a Windows GUI
app would take a couple of minutes (most of which are spent trying to find
the dialog box into which to specify the property values); but in a Web app
it could easily take over an hour to create and fully integrate all the
required pieces.

Well, if you're working on a web app, the functionality should be what you
do first .Then it isn't too much work to add a layer of visual elements. You
can't 'draw' right on the screen. In some ways, this is the benefit. There
is a clear separation between the content/functinality and the visual
rendering. This allows your functionality to be modular in relation to the
interface elements.

FWIW: I'm NOT being critical or complaining (okay, maybe just a little)....
just trying to gain some perspective to where we are with the whole Web
client thing.

Well, the web client is the browser. The great thing about the web is that
it's universal. It works on a variety of operating systems, a variety of
devices, etc. That benefit means the end-user has much more control over
their environment than you've been able to dictate in the past.

The big issue that you're facing is that HTML was always meant to be a
content markup language. It was never designed for visual layout and
interface design.

So, we made do, and spent the late 90's and early 00's bastardizing HTML to
make it do what we wanted as a CLIENT, rather than simply as an information
markup language.

Then, we wised up, started looking at CSS, and have slowly built upon that.

HTML support is finally fairly consistent, but it's the CSS support that is
lacking. I think you will see things improve once IE7 comes out and Firefox
starts being a real competitor to MS. It'll mean that the major browsers
will have to start compteting on how well they support the newer standards,
vs. how well they support proprietary standards.

-Darrel

 

[Kevin Spencer]

Hi Harry,

Are you aware of the hoops you have to jump through to create a Windows
Forms Control with rounded corners? You literally have to write code that
paints the entire Control.

As the old saying goes, "Argue for your limitations and they are yours."
What some people tend to forget is that all the magic of .Net is simply
programming code written by Microsoft developers, which you could, if you
had the time, and the know-how, write for yourself. We developers must not
be imprisoned by convenience (ready-made code). Anything is possible, given
the right amount of time and resources.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Neither a follower
nor a lender be.

 

[bruce barker]

1) yes.

2) there are two trends.

the Microsoft approach is to use winform apps downloaded from the internet.
this follows the java applet model, so it may become successful. the biggest
holdup is clients having the .net vm installed. no current os ships with it,
a new release is due in 6-8 months. also some proxies block this method.
also its a windows only solution.

the w3c group is expanding browser capabilities. xforms is being added,
along with soap calls from the browser. unfortunately Microsoft's IE appears
to be a dead product, and none of these features are being added.

fast networks favor the second model, slow network favor the first.


-- bruce (sqlwork.com)

| This inquiry has to do with the client capabilities and Web client
| experience:
|
| I've been developing rich client apps (Windows desktop client exes in
n-tier
| architecture) for over 10 years and am relatively new to Web client
| development. The other day, Kevin Spencer told someone that Web
development
| is arguably the most difficult type of programming to do. I couldn't agree
| more. In many ways it seems to me that in order to develop non trivial
| functionality into a Web application, we have to spend a relatively long
| amount of time/effort (relative to achieving similar result in a Windows
| client) - and we have to think very hard about the tradeoffs between
| functionality and performance... e.g., if you want something approaching
the
| functionality provided in a Windows client app you suddenly have the
| likelihood of a gigantic ViewState with associated performance issues...
and
| that's if you can assume an uplevel browser or even IE in particular. I
| understand that ASP.NET - at the end of the day - simply provides us with
| powerful tools and methodologies with which we can more easily work with
the
| existing Web standards (http/html, etc) on the server side. Powerful as
| ASP.NET is, it is tied to the basic request/response model of http as we
now
| know it - and that is where the client experience is limited.
|
| Three Questions:
| 1. Is my above assessment of ASP.NET and the role it currently plays
| basically correct?
|
| 2. What are the next major changes we can expect in Internet programming
| during the next 10 years? Do you think we'll still be programming against
a
| basic request/response model in which we pretty much send text around the
| Internet? I'm trying to get a grip on where we are in the current
paradigm,
| and when it is likely to shift.
|
| Please note I do understand Web Services and the SOA in general - but
that's
| all beyond the client; what I'm primarily interested in is the client
| experience and client capabilities. At the end of the day it doesn't
matter
| if your HTML/XHTML/CSS etc comes from Web Service or Web Application -
there
| are still huge limitations in the clients as we currently know them.
|
| Thanks!
|
| -GH
|
|

 

[Guadala Harry]

Thank you everyone for your perspective.

-GH

1) yes.

2) there are two trends.

the Microsoft approach is to use winform apps downloaded from the internet.
this follows the java applet model, so it may become successful. the biggest
holdup is clients having the .net vm installed. no current os ships with it,
a new release is due in 6-8 months. also some proxies block this method.
also its a windows only solution.

the w3c group is expanding browser capabilities. xforms is being added,
along with soap calls from the browser. unfortunately Microsoft's IE appears
to be a dead product, and none of these features are being added.

fast networks favor the second model, slow network favor the first.


-- bruce (sqlwork.com)

| This inquiry has to do with the client capabilities and Web client
| experience:
|
| I've been developing rich client apps (Windows desktop client exes in
n-tier
| architecture) for over 10 years and am relatively new to Web client
| development. The other day, Kevin Spencer told someone that Web
development
| is arguably the most difficult type of programming to do. I couldn't agree
| more. In many ways it seems to me that in order to develop non trivial
| functionality into a Web application, we have to spend a relatively long
| amount of time/effort (relative to achieving similar result in a Windows
| client) - and we have to think very hard about the tradeoffs between
| functionality and performance... e.g., if you want something approaching
the
| functionality provided in a Windows client app you suddenly have the
| likelihood of a gigantic ViewState with associated performance issues...
and
| that's if you can assume an uplevel browser or even IE in particular. I