End-to-end JavaScript Web Applications

Web Servers and the Zen of Non-blocking I/O This post started as a short introduction to the first one in a mini-series of head-to-head comparisons of three non-blocking I/O web servers. And then things got out of control. Being as it is, I convinced myself that a bit more elaborate introduction is in order. Now comes the hard part, to convince everyone else. Web servers Web servers are complicated machines, both hardware and software-wise. The illustration below shows block diagram of a typical web server based on LAMP ( L inux A pache M ySQL/ M ariaDB) P erl/ P HP/ P ython) bundle (or stack as some prefer to say). LAMP bundle web server Told' ya it was complicated, didn't I? And this is just a block diagram. There are variants of this stack, such as WAMP ( W indows A pache M ySQL/ M ariaDB) P erl/ P HP/ P ython). By the way, these bundles are really easy to install. Companies like TurnKey Linux offer a number of software appliances based on Linux in n

Why !(!(node.js))   No one in his right mind would kill his main character in the third chapter of his suspense/thriller/drama blog about web apps, so the above title is not a mistake. There certainly is an extra set of parenthesis, but I wanted to add emphasis. In the first post I tried to make my personal case for node.js, and in this one I shall look into some of the most used counterarguments. JavaScript is slow Inherently, node.js which is based on it, is slow   Well, all web scripting languages are slow . That is because they are interpreted languages . Programs written in these languages need a runtime ( runtime interpreter to be precise) to work. And the runtime is just a program that reads your file and tries to interpret the commands. It is usually (read: always) written in some high speed compiled language (think C/C++). Anyone can create his or hers programming language. All you have to do is invent your own syntax, play around with Lex long enough to im