Re-drawing the entire page is a red herring - the issue here is speed of response, which is ruled by three factors: 1. processing speed, 2. available system resources, and 3. web connection speed. Their assumption is that server-side processing is inherently slower than client-side, but that isnt true nowadays by default because server-side processing actually is more efficient than client side on all these fronts.
It's not necessary slower, the response is "poorer". If I have users inserting items into a list, it's pretty damn stupid to refresh the entire page everytime I need to do that. The only time they really need to communicate with the server is when they "commit" something or when they need to receive some data. But no, every single minor operation requires a reload (there session has to be loaded, they have to validated, all the content on the page has to be re-read from the database or file). I hardly call that a red-herring.
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.
Oh my god.. do you think the average 400mhz machine (or hell 233mhz) machine - which aren't even being sold anymore is actually using even a fraction of its processing power most of the time that it's being used. Sheesh. Client-side processing should not be worse than using any other type of client-side application.
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?
I have a big fat pipe (well sorta).. cable modem. It still "stupid" that ever little operation on a web application requires a reload. No really because of performance, but because of user-friendiness.
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.
I agree that for page layout this thing offers pretty much nothing. CSS and HTML are pretty slick for that. CSS/HTML/Javascript suck for web applications which need to do anything meaningful.
For any real client side application requirements you would probably want stable Java anyway.
Java still sucks on the desktop. It's an OS in an OS. What we need is something like Java, but not so huge. Curl is not it. But there is room for this kind of technology.
should we drive on the left side of the streets too?
Have you forgotten that your nothern neighbours (Canada, you know, where the igloo's are) having been using the metric system and driving on the right for a long time.
2. Templated classes. It was mentioned above, C# lacks these, as do many other languages it seems. While the use of them could be cleaned up quite a bit, the idea of template classes is very sound. It allows for the easy set up of a container class that holds basically any other class you put into it. For example, a matrix in C++ is little more than an array of arrays, all of which can also be templated to hold int, float, char, etc. As a simple side project, I once made a 3D matrix by simple templating arrays into a 2d matrix. In C#, it appears doing this would not be nearly as easy or straight forward.
Java does not have template classes but it does have containers that can hold any other class you put in it. How do they do it? Simple, all objects derive from a single root object called Object. C# works the same way. This is by far cleaner than using templates.
Each time you instanciate a template class with a different "type" you create a whole new class. If you just creating simple containers, than you are wasting a lot of space. In Java and C#, the class is created only once.
Slashdot Mirror
Re-drawing the entire page is a red herring - the issue here is speed of response, which is ruled by three factors: 1. processing speed, 2. available system resources, and 3. web connection speed. Their assumption is that server-side processing is inherently slower than client-side, but that isnt true nowadays by default because server-side processing actually is more efficient than client side on all these fronts.
It's not necessary slower, the response is "poorer". If I have users inserting items into a list, it's pretty damn stupid to refresh the entire page everytime I need to do that. The only time they really need to communicate with the server is when they "commit" something or when they need to receive some data. But no, every single minor operation requires a reload (there session has to be loaded, they have to validated, all the content on the page has to be re-read from the database or file). I hardly call that a red-herring.
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.
Oh my god.. do you think the average 400mhz machine (or hell 233mhz) machine - which aren't even being sold anymore is actually using even a fraction of its processing power most of the time that it's being used. Sheesh. Client-side processing should not be worse than using any other type of client-side application.
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?
I have a big fat pipe (well sorta).. cable modem. It still "stupid" that ever little operation on a web application requires a reload. No really because of performance, but because of user-friendiness.
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.
I agree that for page layout this thing offers pretty much nothing. CSS and HTML are pretty slick for that. CSS/HTML/Javascript suck for web applications which need to do anything meaningful.
For any real client side application requirements you would probably want stable Java anyway.
Java still sucks on the desktop. It's an OS in an OS. What we need is something like Java, but not so huge. Curl is not it. But there is room for this kind of technology.
should we drive on the left side of the streets too?
Have you forgotten that your nothern neighbours (Canada, you know, where the igloo's are) having been using the metric system and driving on the right for a long time.
Java does not have template classes but it does have containers that can hold any other class you put in it. How do they do it? Simple, all objects derive from a single root object called Object. C# works the same way. This is by far cleaner than using templates.
Each time you instanciate a template class with a different "type" you create a whole new class. If you just creating simple containers, than you are wasting a lot of space. In Java and C#, the class is created only once.