VK wrote:
>
IMHO all modern "box applications" are taking the web-application
approach: thus the program development life doesn't end at the moment
of being boxed. It remains alive (unless blocked) by connecting to the
producer sites for upgrades and new releases.
Same way any web-application can be stored on your disk (File Save >
Web Page, complete) but being automatically updated from the producer
site.
The moment you save a web application to your hard drive it can no
longer talk with all the same methods because of the JavaScript
security rules. So at this point many web applications will break.
We can load the browser with data in the browser's cache as a
JavaScript source file with JSON inside. If the data changes then we
can't locally update that cached data file. We have to download the
potentially large dataset from scratch the next time we visit the
website.
What I see really interesting is the possibilities of
distributed web-applications where say the interface comes from a US
site, script blocks from Germany and Finland and data processing RMI'ed
from a Japan database server.
I can see this really cutting down traffic on the web. If everyone
using Yahoo! UI downloaded it from the same URL then many sites could
take advantage of Yahoo! UI already being in the browsers cache. This
is possible isn't it?
Now the probability of a particular page working is decreased because
more than one server has to be up for success.
IMHO the bottleneck (but not a dead end) of all - even the most modern
- UA's is the rendering engine. They are still - like NCSA Mosaic -
slow and lazy tools to display text documents with some graphics. Some
day the niche can be closed: but for this C++ programmer has to step
aside and Assembly programmer take his place.
I can't imagine that a brower rendering engine needs to be hand written
in assembly to get fast rendering speed. Do they really write video
game rendering engines in assembly? That would be painful! I imagine
the problem in a web page is more of flowing the page which is not
something a video game needs to do. Can't a video game just place
everything by absolute pixel position?
-----
I suppose with faster client-server communication we could move in two
directions. One is make the browser smarter and have longer load times
but faster interaction times without server communication during the
page's life. The other is to move more in the direction of
mainframe-terminal design where the browser is capable of only
communicating and rendering.
Ruby on Rails is moving in the second direction. In a Rails app, all
form validation occurs server-side using Ajax if possible to make is
snappy. This makes sense if validation is considered application logic
and the browser is only part of the view layer in a
model-view-controller architecture.
One of Google's directive's is that page loads should be instant. I
think that implies that the page shouldn't contain any or much
application logic since the server can do this. Loading this logic is
not necessary to achieve the instant page load. I think Google would
rather spread out communication time over the life of a page than to
aggregate as much as possible to the initial page load.
Peter