But that could be done without a web-specific framework right? Say I had JavaScript on the client side send me a computation request to do something massive, say on a grid - I will probably run that using C/C++/Java there and return the result to JavaScript.
My point is, do we really need something to generate HTML at all at what we usually call the "server"-side?
"Generating HTML" on server side is done in some predictable time, while you can't make any assumptions about your users computer/OS performance thus the user experience will be random. It means problems and many lines of javascript code to solve them.
You can accomplish this, after a sort, using databases like CouchDB and Mongodb.
While its entirely possible to write a pure client/database web application, you are going to run into security issues. You are inherently opening up your database to the outside world, and javascript clients are inherently un-trustworthy from a security angle.
If I were designing such a platform, I would segment actions into "safe" and "non-safe" areas. Safe areas would be client/database actions that are ok for the javascript client to access externally. Non-safe areas, such as account creation and editing, financial interactions, etc, would need a middle-tier server-side application layer. The middle-tier would need to act as a proxy that handles validation of database requests, etc.
Yes. For one, you don't let the intertubes (clients) all talk to your database.
Second, there are tons of other stuff that we do on the server side besides talking to databases. E.g image processing, task queues, etc.
And lastly, Javascript is not the most elegant of languages. No much benefit of using it in the server side, besides the mythical "so we can share code", as if server and client side do the same stuff (with the exception of input validation).
Direct client access to a database as being the most prominent concern raised here (which to me was the main concern as well) - I will need to think about it.
Say we magically got rid of the security problem (thus eliminating a middle tier - and I admit it'd be some pretty mean magic), then could your second point could be addressed by this: http://news.ycombinator.com/item?id=4518443 ?
Regarding your third point, I agree it's not the most elegant of languages - but if some language which is elegant could run on browsers and had database access capabilities, would one use that instead of having a middle tier to generate "pages"? (as things stand, much of the middleware these days generates and receives JSON/XML and data anyway - can we do away with generating that initial HTML totally?)
Your original point was that we might not need server-side languages or frameworks at all. "The grid" is still a server - it's just not one you control directly. I don't think we'll ever get away from servers because there are definite advantages available by having computation centralized - you can have more powerful hardware available, you don't need to worry about outdated versions of code running, etc.
More broadly, though - there's nothing specific to a language that allows or disallows communication with a database. That's really the realm of a library or a driver to interact with the database (an external service) through some established protocol. People have written databases with JS hooks before, but it's just not common, likely because of the security problem.
