Axel, I'm not very good at explaining things, many have told me this. But you really miss understood me.
On Sun, 2012-02-12 at 10:33 +0100, Axel Kittenberger wrote: > > Examples of the Server side could be something like the following: > > [....] > > This is all micromanaging the client from the server. It will work I > wont deny that, but it comes with a few drawbacks. Bandwidth Load, > Sending every single DOM setting and change from server to client > causes more bandwidth, response time, anything you change needs a > client<->server communcation, leaving the user a worse responseviness > feeling, development encapsulasion, having client/server be more Bandwidth, load, responsiveness, communication, are all derived from one drawback, "performance" And I must disagree with you on this. I'm talking about less than 2k per each send/recv, in most cases less then 100 bytes. Hardly a nanogram compared to something like a game or a movie. I'm talking about Enterprise business applications, where the data buffers are usually less than 2k. Additionally, I've done some testing, in an intra-net environment doing straight socket I/O it is extremely fast. Over an Internet connection it does very well. I estimate about 30 to 50 round-trip updates between the client and the server per second. Now thats not using Node, thats all ANSI C (not c++) and socket calls. My understand is that after the initial http handshake Node can do standard socket calls outside of the http protocol, so it shouldn't be much slower at all. > seperate things where the former cares about the updates is better in > seperating the tasks for development. Its like doing an online game, > and instead of the server sending the client proper changes of the > virtual world for it to render properly, it would instead in analogy > to setting each and every DOM paramter from server provide a 2D movie. I think you're saying that separating the GUI development from the application development is a bad thing. The way you ran all those mis-spelled words together, its not real clear what you're saying. But, if this separation is a bad thing too you, then again I strongly disagree! I think you totally misunderstood my point. But I have an analogy also, Data Base Management Systems. Lets roll the clock back about 40-50 years. Application developers at that time didn't have allot of Database systems to choose from. They simply rolled their own databases, handling their own indexes, wrote their own hash tables, and so on. Starting in the 1960's IBM developed the first Navigational database, then hierarchical databases, and network databases. It was almost 1980 when we saw the first SQL database. Still there were application programmers who continued to roll their own, because it was faster, maybe. More so because people don't like to make a change when what they have is working just fine. People generally don't get it, like whats the advantage, or thats not what I was taught. Today the average programmer reads/writes data from a database without much concern about how it all works, that is someone else's job. The programmer simply uses a small amount of information about the data (meta-data), and requests the data. Similar scenario can be said about data communications or Network programming. Node.js definitely proves that! If you don't understand what the database problem was back then, and you don't understand why they fixed it, then I am wasting my time. So the industry fixed the database issues, and fixed the Networking issues. The UI back then was simple, literally is was read and write, but today it is a problem, its chaotic, it not standardized, its allot of roll your own. Somehow this too must get fixed! Wouldn't it be nice if a programmer could converse with a GUI by simply writing something like: Select * on Inventory-Screen; If sort-by-partnum was clicked then do the sort logic. Or if Enter was clicked then do the logic to process the data buffer. Now Axel, come on. In your opinion it would be faster to rebuild the entire GUI or page? What I'm saying is, only send whats changed, in this case it is the data buffer, and no doubt less than 1k bytes. Why send and rebuild the entire GUI or page? Sending the entire thing is what I want to avoid. Also, on the server, I'd like to avoid creating and tare down a processes every time the user clicks on a button. If I had the server side Node functions working as I explained (or tried to explain) in my earlier post, then I could develop the glue between the app and Node so the App would only need that one line to interact with a full blow GUI in a Web environment. Developing GUI Business applications would be drastically less expensive, or maybe programmers could make more money in less time. > If you need to keep at this strict server controlled design, just > generate webpages all over, like in the old pre-ajax web, instead of > making micro calls to the DOM. > You really miss understood me! -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
