NYCPHP Meetup

NYPHP.org

[nycphp-talk] Successor to the Web?

David Krings ramons at gmx.net
Wed Oct 18 10:40:38 EDT 2006


Hi,

         I do not know of any particularly good sources that cover this 
topic. I just wonder what is wrong with client/server? After all, a browser 
and an http server is nothing else than a client/server structure in the 
classical sense. And with JavaScript the browser is becoming more a fat 
client. I personally prever a fat client as it allows a far better 
distribution of processing power. The browsers come around and do a lot of 
that with the XML/XSLT deal that puts the presentation tasks entirely in 
the lap of the browsers (which may not be a good thing in case of broken 
browsers like IE).

         One of the biggest limitations that I see in regards to the 
web/internet is that it is still too slow for heavy duty applications (or 
speedy connections are too expensive for the casual consumer use), that it 
is still too different from the fat clients, and that it is just too much 
of client/server (stateless). I work and worked on both fat client/server 
projects as well as web based projects and they each have their place. And 
each of them are by far not at the end of what can be done, one good 
example is the rising of AJAX, which combines technologies that are around 
for years and years already. I personally don't see the need to replace fat 
clients and the page oriented web. The page limitations are a good thing 
and make the developers think more. Why do we need a Web 3.0 when the vast 
majority cannot even properly handle Web 0.0.1beta? That is the same reson 
why many big companies still runn their mainframes using COBOL. Sure, that 
it so 60s, but it is well understood and just plain works. Can't say that 
about the next big thing after that, the (Windows) client/server.

         Depending on the tasks to be accomplished, going back to what you 
call "client/server" is in my opinion a very good idea. Far too many 
applications are being browser based or web enabled these days that clearly 
are way to complex and heavy to be handled by a dinky browser and a handful 
of markup code regardless of the new avenues with Ruby, AJAX, or PHP. I 
really lost you on the demand for a "new web". If the browser based 
approach does not work for the complex applications, there are solutions 
available that do the trick and when done right they do it quite well.

         Just my 2 €.

                         David K.


At 08:54 AM 10/18/2006, you wrote:

>I am sorry if this question appears to be off-topic, but perhaps someone 
>can refer me to the correct forum.  I had programmed in approximately a 
>dozen languages previously before dabbling in PHP a couple years ago.  Now 
>that PHP 5 is truly object-oriented, I find it to be the most powerful of 
>the languages with which I am familiar.  As remarkable as the Web is, I am 
>coming to the conclusion that it has some severe limitations for the kinds 
>of complex applications that were the standard in the client/server 
>days.  I know that going back to client/server is not the answer and 
>suspect that somewhere someone is working on an Internet-based system that 
>could ultimately replace the page-oriented Web.  Can anybody point me in 
>that direction?
>
>My primary concern with the Web is that it seems to be a force-fit of 
>page-orientation and statelessness to structured programming/object 
>orientation, which I find to be inherently task-oriented.  Applications 
>that depend heavily upon related records require that users perform all 
>kinds of browses.  Under those circumstances, managing communication among 
>objects becomes a nightmare because it requires the application programmer 
>to predict communication paths to objects and manually handle session 
>variables that are not task-scoped (they are by definition, 
>session-scoped).  It appears to me that there is a role for session 
>variables, but it is not the task.
>
>The force-fit described above is particularly apparent when programming in 
>an MVC and validate/process/display workflow environment.  While many 
>programmers have reservations about the need for these disciplines, it has 
>been my experience that they become increasingly important as the size and 
>complexity of an application system increases.
>
>Any thoughts will be appreciated.
>
>Phil Duffy




More information about the talk mailing list