We have this e-prescription system in Estonia for over 2 years now, nation wide. The good - It's easier to get some recurring prescriptions that you have to take all the time, you just calle the doctor and say you are running low on the meds, he checks your previous prescriptions and can easily see that yes, you should have only a few left... (to detect you are not attempting to scam extra medicines for black market or something). Also another good thing is that combined with an electronic pharmacy database, you can check online exactly which pharmacies currently have this medicine in stock in the right quantity(My partner takes meds that come in 10, 20, 30, 50 and 100mg forms, She only wants the 100mg ones). The bad - Initially they had performance problems because they forgot one basic simple thing when calculating peak usage - All elderly / pension receiving people(They are also the ones who require a lot of prescription medicines.) get their pension on the same day in the beginning of the month. This gives them a reason to leave the house and go to the city, and most of them also buy their medicines within the 2 days period following it, causing a massive performance bottle-necks for that moment(This problem was later fixed by adding more servers + optimizing).

Please do send me an ad / job posting about what you are hiring as I'm looking for a job?

This is super! This means that a lot of companies will finally bother, or at least consider it, to pay the development companies(and consultants) to replace or patch their old web based intranets and business softwares. This my friends means pretty soon we'll have a lot more work, which means we can bill them adequately(because you can say that this time we built it on the latest and greatest HTML5 standards)! Unless of course some manager decides it's simpler to let their IT department just opt out of the upgrade and pretend they will be OK for the next 10 years using IE6.

This solution what the parent is suggesting is a rather good one actually and can be used in the PHP world also, although you still need some good library to help you handle the json objects but that is trivial. It does involve a rather big paradigm shift as you end up with coding a lot of your business logic in javascript on the client-side and using a lot of short ajax requests. But it does allow you do be more dynamic on the front-end in any way the customer sees fit. The down-side is actually that you are writing big parts of your code in javascript which can be a problem if you want to keep your code hidden from the prying eyes. Security as mentioned can be an issue if not properly handled by the backend. To sum up the parent commenters post: The best framework might just be a HTML5 and a powerful javascript library combo. ExtJS, JQuery and Dojo are all rather good.

Having a separate subdomain for images, video and content can actually improve speed when those subdomains are cookie-less and properly cached. Although having one subdomain like that would be preferred. Also, many developers are using Google(or others) CDN for javascript frameworks and popular API's to improve loading speed(You are very likely to already have the Google CDN JQuery in your browsers cache) and reduce bandwidth usage.

Depending on static/PHP/Python/WhatEverYouUse engines, i think 16GB is a bit overkill for 1000+ users per day, but it all depends on the application ofcourse.