

Ask HN: If JavaScript could talk to databases - photon137

If JavaScript (or a JS framework) could talk to databases, would we need server-side languages/frameworks at all?
======
redredraider
So you want to give clients direct access to your database?

------
dotborg
Yes, for offline processing.

~~~
photon137
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?

~~~
dotborg
"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.

------
geuis
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.

------
batista
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).

~~~
photon137
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?)

~~~
bartonfink
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.

