the trend of most content-heavy websites is towards heavy duty server hardware with efficient server-side engines like PhP or mod_perl. Compare that hardware and software environment to a typical client-side desktop which suffers from M$ bloat, multi-tasking, and limited hardware. Unless you have server-grade hardware and don't use any other programs while surfing, you're probably not going to be able to execute code a.out in less time than it would take the server to execute it AND deliver it to you.
I'll take a thousand clients running at 50% of theoretical maximum rather than a dedicated server rendering and serving GIFs for each of those thousand, please.:)
speaking of delivery, consider that the trend is towards cable modems, ISDN, and DSL and away plain old dialup. True not everyone has fat pipes (I don't, myself) but why design a technlogy for the past?
Be that as it may, there will always be an advantage in using the minimum amount of bandwidth necessary to do the job. Any pipe can be filled with cruft, no matter how large the pipe. I predict that someone will always find a way to fill whatever is available -- streaming 3D with video textures, or something awful (or useful!) like that. If you only really asked for 30 Kb worth of info, then that's what the server should send, if at all possible.
granted, server-side processing sends the Whole Enchilada. Your 5-line PHP file expands to 100 lines of HTML and jscript. so what? if your connection is fast you won't notice, and if your hardware isn't state of the art you will wait for local compile time anyway. Just like you do now for Java (which is why IMHO Java sucks for web but rules for everything else).
The way around this is to provide an applet that queries the server without reloading itself, then updates the GUI state as required. Curl language applets can open connections back to the server. No recompilation required until the user shuts down and restarts the next day, or you rewrite the applet, etc.
Also -- I have a broadband connection, and I still wait on large pages. Not just for graphics, but textual data and for very complicated layouts. It happens today.
well, actually if you follow CSS you can separate content and layout without installing Yet Another Plugin and also minimize complex nested tabling. Assuming you use Opera or IE anyway:) To be fair they should compare CURL vs HTML + CSS, not CURL vs HTML alone, if they want to talk about layout affecting code design.
Having used/tried to use CSS, I can safely say that the Curl language's GUI options are much saner to use. CSS gets really complicated really fast, even without all the current differences in implementation between browsers.
Disclaimer: My employer, Curl Corporation, does not necessarily share the views expressed in this message.
Slashdot Mirror
I'll take a thousand clients running at 50% of theoretical maximum rather than a dedicated server rendering and serving GIFs for each of those thousand, please. :)
Be that as it may, there will always be an advantage in using the minimum amount of bandwidth necessary to do the job. Any pipe can be filled with cruft, no matter how large the pipe. I predict that someone will always find a way to fill whatever is available -- streaming 3D with video textures, or something awful (or useful!) like that. If you only really asked for 30 Kb worth of info, then that's what the server should send, if at all possible.
The way around this is to provide an applet that queries the server without reloading itself, then updates the GUI state as required. Curl language applets can open connections back to the server. No recompilation required until the user shuts down and restarts the next day, or you rewrite the applet, etc.
Also -- I have a broadband connection, and I still wait on large pages. Not just for graphics, but textual data and for very complicated layouts. It happens today.
Having used/tried to use CSS, I can safely say that the Curl language's GUI options are much saner to use. CSS gets really complicated really fast, even without all the current differences in implementation between browsers.
Disclaimer: My employer, Curl Corporation, does not necessarily share the views expressed in this message.