Re: Attempt to de-mystify AJAX

"Tony Gravagno" <g6q3x9lu53001@xxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:6gj8n1lqup53gi2cb7faci1v7ea0e8j08e@xxxxxxxxxx
> Holy cripes, I need to stay away from this forum, I'm obviously not
> making sense to anyone anymore - well, except for Luke. :)
>
> "murthi" wrote:
>
>>Ah yes, Tony, thank you for weighing in again with your standard
>>mantra-right tool for the right job. I think I've got it.
>
> That wasn't the point at all though I guess that concept was
> reinforced by the example. My point was that we need to have more
> conviction when we know the client (or some decision maker) is leading
> with a technology that is good for immediate needs but not for the
> long run.
Agreed.
>
>>In fact, in a fit of inconsistency...
>
> I was pointing out irony among our colleagues, which means I'm
> observing inconsistency, not practicing it. You've appparently done
> what I've been recommending, just pick something and go with it rather
> than theorize (as some people do) for years about what tools to use or
> wonder if this web thing is just a fad.

I do tend to stick with what's comfortable. otoh, reaasonably sure the JS
decision was correct.

>>Seriously tho', what's with the constant putdowns of perfectly WORKABLE
>>solutions (emphasis mine)? "people insist on doing "heavy lifting" in
>>"thin" clients" and "You might be "amazed.. that users don't want RIA"
>
> Again, not directed at you Chandru, I wasn't even thinking about you.
> There are a million other developers out there doing exactly what
> you're doing, some better than others. Again there is an irony that
> people loath thick clients so much and yet they're putting so much
> code into the browser that it's now just as thick as anything people
> were trying to avoid before.

Point appreciated. Some of our multi-page screens may reach 75-100k. I guess
I think of thickness as related to how much you have to load a priori (ie
not part of the html load). But then, in another of your points I never
followed up on, apparently one can download anything via html, not just
script.
[snip]
>> So what? It works. What's "poor" about a browser interface?
>
> The container itself is ... As far as the interface itself, if
> you're using JS the browser controls need to have their events
> manually wired to handler code, there are few popular tools that
> manage this for the developer, we might as well use Notepad or vi, and
> some people do. The DOM for visual components (listbox, radio, grid,
> etc) is inconsistent within and among browsers, and not as versatile
> as thick components. Browser controls are not extensible, you can't
> (without a LOT of code) inherit from an abstract listbox or textarea
> class and then change the behaviors, or clone such new classes to
> other pages.
About the wiring, it's fully automatic on our development platform as I
suspect it would be for Visage or DesignBais. No editing html here. However,
one can add event JS code at the design level, so while a knowledge of JS is
not required, most of the programmers using it can do so.

> This all increases the cost of development and implementation way
> beyond the perceived benefits of the economy of "thin" clients.
> "Thin" sounds elegant but the thinner the client the more effort is
> required to support it.
Now here I'm not sure how. If (using your term) we accept the "dumbing", or
(my term) the limitations of the technology, you live with it as far as
possible. I assume you are talking about about hitting the inevitable
"walls" when using any devlopment product, and that breaking over them is
harder with a browser than if you went another route?

People talk about ease of deployment with a
> BUI but look at all the contortions people need to go through to get
> there. The more you want your solution to be universally acceptable
> the more you need to dumb it down to the lowest common denominator.
> If people knew 10 years ago that this is where we were headed, I
> seriously doubt so many people would be advocating the browser as a
> universal client for business applications.

> This is one long series of misunderstandings after another, we have no
> disagreements here. Let's take this a little more slowly:
> 1) IT used to think BUI development was easy.
> 2) Therefore IT people advocated thin client.
> 3) BUI development is no longer easy, in fact it's difficult and
> costly.
> 4) IT people are now stuck with the phenomenon that people expect rich
> BUI. Oh yeah, and because browsers are free end-users and management
> people expect development tools and deployment infrastructures to be
> free too, which means developers are expected to do more with less.
> 5) Irony: IT people still say it's easy and advocate thin client, and
> yet everyone complains about the issues I cited above.
> 6) Observation: People en-masse are more inclined to go with the flow
> and perpetuate the ideal, than to admit that the solutions they've
> been advocating may no longer be suitable, and either to take steps
> "backward" or to push for improvement.
> Examples:

+ current administration.
>
>>>When a user has committed to being in your application they should
>>>understand what the rules are
>>
>>No, when an application designer works with a client (and, implicitly, the
>>user) to determine what they want, the rules are thereby determined.
>
> We're going a little off here but my point was more that developers
> seem compelled to try to code for issues like "the user wants to jump
> away from the app in the middle of data entry and then come back
> later". I think we're being over-accommodating. Computers are
> capable of running more than one application simultaneously, and all
> graphical desktops support multiple windows. If a user is inclined to
> surf, they should open a new browser window - their one click on the
> desktop will save massive amounts of ongoing developer effort. I'm
> not advocating that we compel users to do something unusual just to
> save us some effort, just looking for a bit of reasonable equity - the
> end-user is not always right. Car manufacturers don't make it an
> option to put the steering wheel in the back seat in case someone back
> there really wants to drive - let the person in back get out and come
> up front. If you ask a car manufacturer for this feature they will
> refuse the request, no matter how many back seat drivers there are. :)

But I see our example as being trivial to implement (as opposed to moving
the wheel) so I would indulge the user even if I disagree. In fact, the
applications designers (as opposed to me) welcome the opportunities that the
browser gives them since they can do all sorts of things without having to
wait for development to add features. Not always the right path, mind you,
but it does increase product acceptance.
>
>>> Glen mentioned using Flash for applications. This was something I
>>> tried to encourage years ago. See the Shockwave/FlashCONNECT demo on
>>> the RD web site.
>>And a pretty poor one it is, too.
>
> That was an unnecessary and unexpectedly childish retort. Don't
> confuse glitz with functionality.
Sorry, guess I meant it did not show me all I wanted too,and it does look
dated.

>
> We agree on a great many things, Chandru, it just doesn't seem obvious
> - take for example that we both like the same little Indian restaurant
> in Chicago, maybe a couple of them... ;)
>
Or those along 6th st NYC?

Chandur Murthi


.

Relevant Pages

  • Re: access only to one external site
    ... Is the firewall client installed on the client? ... Is the browser configured to use a proxy or not? ... If you can send a zipped print screen of the Destination Set definition it ...
    (microsoft.public.isa.configuration)
  • Re: Pure client-side javscript database?
    ... the individual asking the question in their single context. ... in the current browser instance and a respondent assumes the question ... >>> that the client may download an application from a server ... >>> server, but the APPLICATION may or may not be. ...
    (comp.lang.javascript)
  • Re: Still Need desperate help to start with ASP NET - simplified problems - HELP!!
    ... Now you can process the entered arguments at startup. ... browser and program so that you can leave all the client server ... back to IIS to send to the client you are going to have to find out ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Still Need desperate help to start with ASP NET - simplified problems - HELP!!
    ... You write that there is no IIS involved. ... which client sent it. ... browser and viceversa, I want the browser to display what the win ... running on the server? ...
    (microsoft.public.dotnet.framework.aspnet)