With PHP or Java, you let your business logic runs on the server, letting the client download most of the HTML already prepared. The user browser then just has to download and render that data. It also means that your server has to produce all that stuff, including pretty CPU- and memory-expensive HTML and XML.
Now what can you do with JavaScript? JavaScript (JS) will allow you to serve a very simple, naked HTML page, which will also reference the JS code (you can separate it in small modules that will get loaded dynamically to save bandwidth). The client JS code will then ask for the raw data almost directly to the backend database - with a small security and data transformation layer in the front. This data should be produced in JSON to reduce the CPU usage on both server and client sides. With that data, the JS code will then be able to build the user interface dynamically, either by building markup dynamically or basing on HTML templates.
What does that mean for the billing costs? Basically, you can save CPU usage on the host - thus having less billed, and also you can save bandwidth either with code lighter than the generated HTML, or code that makes your page application-like and not website-like. Let's picture that this way: with JS you can make your site load the code only once, and after that it will only exchange light JSON data with the server. With a Java or PHP implementation, you'll have many pages downloads. So the gain with JS is higher when you intend your user to stay longer on the site.
It may not be the silver bullet though - feel free to comment that and show cases where server- generated markup is better. I miss detailed numbers to present as case analysis. What I was just trying to show is that JavaScript should play a role when you do a cost or performance optimization of your website, especially if it's hosted on dynamic billing environment.
A little addition with a database like CoachDB which server JSON directly, doing this kind of development becomes even more attractive as well as convenient. Since the DB in this case is build to scale, you could server up a small page stub including the JS needed and from then on load pretty much directly from the DB, which implements the filter logic and serves JSON. I'm thinking about building a WebApp right now using NodeJS for Serving the basic functions, with CouchDB in the backend, and JS on the client doing most of the business logic. That's JS pretty much all the way.
ReplyDeleteThe only problem I see with JS as a developer is that the language do to it's prototype and functional nature is quite different to what I'm used to with Python and Ruby.
Good point. What you describes looks like a very elegant infrastructure entirely based on JS. Seems like a strong argument for this kind of software stack - also it's probably rather positive for you that it's a new territory. The single thing Node.js needs from my point of view is a performance proof. I'm not sure that it can react well for massive load and scale out. I may be wrong. Do you maybe have links on Node.js scalability/performance?
ReplyDeleteI've been working with NodeJS/ExpressJS for some weeks now, and it really is an impressive and quite stable framework, really nice to work with. About Performance there is a nice thread http://www.devcomments.com/NodeJS-scalability-and-performances-at223501.htm about that, also check out the Google Groups for NodeJS. There are a couple people discussing that, and from my understanding about I/O and OS I gotta say the idea of completly evented I/O seems like a great Idea.
ReplyDeleteWhen I release the project I'm working on right now, I will know a lot more. You are invited to check it out then.