Node.js, YUI 3 & Dom Manipulation… Oh My(yuiblog.com)
yuiblog.com
Node.js, YUI 3 & Dom Manipulation… Oh My
http://www.yuiblog.com/blog/2010/04/09/node-js-yui-3-dom-manipulation-oh-my/
2 comments
He recreated the DOM, server-side, and can essentially call a ToString() to get the HTML to send to the client, but I didn't see anything about sending events and event handlers to the client. I assume that's the next step.
That is on my list ;)
You know, you could describe this project as GWT without Java and without the black box.
Is it that time already? I guess so, the server is the new client, which was the new server, which was the new client, which was the new server.....
It makes more sense than it sounds.
Client-side: Punch tape goes in, results come out. The idea of a server doesn't make sense because there isn't enough power for time sharing.
Server-side: We have powerful enough computers to timeshare, but computers are too expensive to have less powerful ones for everyone.
Client-side: a computer for each person doing more elaborate things is cheaper than a mainframe. Bandwidth is expensive, so it doesn't make sense to deliver all but the most basic GUIs remotely. (How many people were using remote X applications across the world in 1989?)
Server-side. Maintaining application executables (upgrades on all machines, security rights, telecommuting and mobile computing) is more expensive than putting it all on a web server. However, interpreted languages are just a bit too slow to run on their own. (Java was a viable option, but applets never caught on for many reasons, one of which was that Sun didn't put the work in to make the GUIs pleasant to use.)
Now, we have client side computers and javascript interpreters powerful enough to develop client side utilities that can be dynamically loaded, giving developers the best of both worlds. The balance switched again in favor of client-side applications. I expect this to hold for a while, until bandwidth and centralized processing power overtakes individual client machines to make server-side applications more valuable again.
Client-side: Punch tape goes in, results come out. The idea of a server doesn't make sense because there isn't enough power for time sharing.
Server-side: We have powerful enough computers to timeshare, but computers are too expensive to have less powerful ones for everyone.
Client-side: a computer for each person doing more elaborate things is cheaper than a mainframe. Bandwidth is expensive, so it doesn't make sense to deliver all but the most basic GUIs remotely. (How many people were using remote X applications across the world in 1989?)
Server-side. Maintaining application executables (upgrades on all machines, security rights, telecommuting and mobile computing) is more expensive than putting it all on a web server. However, interpreted languages are just a bit too slow to run on their own. (Java was a viable option, but applets never caught on for many reasons, one of which was that Sun didn't put the work in to make the GUIs pleasant to use.)
Now, we have client side computers and javascript interpreters powerful enough to develop client side utilities that can be dynamically loaded, giving developers the best of both worlds. The balance switched again in favor of client-side applications. I expect this to hold for a while, until bandwidth and centralized processing power overtakes individual client machines to make server-side applications more valuable again.
Idiocy is the new ingeniousness.