Opinions about new asp-tech

  • Thread starter Thread starter mikael
  • Start date Start date
M

mikael

I work for these people, http://www.naltabyte.com
and I wonder what you guys think about what they are trying to sell
there.
It's a kinda new approach to the whole server-client thing.
Quote
"Liquid 5 uses the wellknown dhtml/dom to access all elements in the
asp-file, like if it was a webpage.
- This makes it just as easy to create complext interfaces on the server
as it used to be on the client."

The resoning here is that with broadband, there might no longer be a
need for clientside apps at all.
I dont know if I support that notion or not, but I would like to hear
your thoughts on that.

Will broadband move it all over to the server, even when it comes to
dynamic interactivity, like drop-downs and so forth?


Live long and prosper(^-^)y

*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!
 
I think it will always be desirable to "off-load" any processes to the
client when possible. Since there is now strong support for standards on
the client (html/dom/css/xml), why would you want to add the processing of
these parts of the overall application to the server when the client can do
it without increasing overhead?
 
Basically, I dont want the 'javascript error' to appear.
Also, if I use xhtml, I support most devices, even those who dont even
support javascript at all.
Thirdly, if I still have to write the code, and it's the exact same
code, then I might as well run it on the server, where I know it's safe
and that it will run the same regardless.
And finally, I can keep the code 'secret' if it executes on the server,
which I cannot on the client.
- With broadband, the few kilobytes that needs to download each time is
hardly noticable, if at all.

Live long and prosper(^-^)y

*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!
 
But what about the user experience? It is greatly diminshed if things as
simple as even required field checks are done on the server. All that
flashing is annoying - and even with broadband you are still sitting there
waiting for the response.
 
Yes,that's a problem, but there's no perfect way to do anything online
as of yet, and I dont want to find myself in the same situation as
certain companies, like Convea, who basically had all their sourcecode
stolen recently.
Also, I can see browsers rendering improve in the future, and therefor
the flashing will disappear.
When that happens, the apps I do now, will automatically benefit from
this.
- But if browsers change in the future, or if I choose the wrong
approach, flash, java, or whatever, I'm toast, if I rely on the client.

Live long and prosper(^-^)y

*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!
 
mikael said:
Basically, I dont want the 'javascript error' to appear.

Then take the time to write it correctly.
Also, if I use xhtml, I support most devices, even those who dont even
support javascript at all.

XHTML and JavaScript are not directly comparable.
Thirdly, if I still have to write the code, and it's the exact same
code, then I might as well run it on the server, where I know it's safe
and that it will run the same regardless.

How do you write server side code to tell the client to produce a
message box?
How do you write server side code that validates user input BEFORE it is
sent to the server?
The fact is that client-side code and server-side code have different
API's available to them and are used for different reasons.
And finally, I can keep the code 'secret' if it executes on the server,
which I cannot on the client.

True. Code that I need to keep confidential I write a component for and
run from the server OR I make an ActiveX control.
- With broadband, the few kilobytes that needs to download each time is
hardly noticable, if at all.

We're not talking about the bandwith to download the client code, we're
talking about the processing of this code. ANY code you write for the the
server must be multiplied by the volume you expect for that server. If you
have code that contains 10 variables and 10 people call for that page
simultaneously, then your server must keep 100 values in memory, not 10. By
"off loading" some work to the client, you alieviate processing load from
the server.

Some tasks are best done at the server and some tasks MUST be done at the
server. Similarly, some tasks are best done at the client and some tasks
MUST be done at the client.
 
mikael said:
Yes,that's a problem, but there's no perfect way to do anything online
as of yet, and I dont want to find myself in the same situation as
certain companies, like Convea, who basically had all their sourcecode
stolen recently.
Also, I can see browsers rendering improve in the future, and therefor
the flashing will disappear.
When that happens, the apps I do now, will automatically benefit from
this.
- But if browsers change in the future, or if I choose the wrong
approach, flash, java, or whatever, I'm toast, if I rely on the client.

I think you are not seeing the "big picture", you seem to be putting all
your eggs in this "do it all on the server" basket and that day isn't going
to come anytime soon (if at all). The ability to code server-side has been
with us (in the main stream) for about 10 years now and client-side coding
hasn't gone away in all that time. With everything that .NET brings to the
party, client-side coding is still a vital part of the equation.

As I said in an earlier post, there are certain parts of an application that
MUST run client-side (any code that asks the browser itself to do
something - BOM) and code that really should be done client-side (form
validation). You seem to want to push it all to the server just for the
sake of saying it all runs from the server?
 
Back
Top