I'm not aware of anyone doing this, but wouldn't it be a great idea? You could share code between the server- and client-side, e.g., only write code to validate input once, as opposed to once in JavaScript and once in Perl/Ruby/whatever.
I've been thinking of the same thing. You could use the DOM model server-side to build pages, too. It seems such an obvious idea, you'd think somebody would have implemented it by now.
Have they?
You do know that there are different layers of security and each one is a point of attack
> The Plain Old Webserver uses Server-side Javascript (SJS) to run a server inside your browser. Use it to distribute files from your browser. It supports Server-side JS, GET, POST, uploads, Cookies, SQLite and AJAX.
That's just silly!
>>3
Dude, client-side input validation isn't a layer of security at all. It's only for the user's convenience.
Does Javascript have enough introspection to render closures into program code? I guess not. If you added that capability to the server-side Javascript implementation, you could have an extremely powerful tool.
Obviously, you don't want it to work the other way. But it's probably impossible anyway.
> Does Javascript have enough introspection to render closures into program code?
i have no idea what you mean by "render closures into program code", but it's probably possible. IME, just about anything is possible in javascript.
Apparently people have had the idea before:
http://en.wikipedia.org/wiki/Server-side_JavaScript
Most of these examples seem yucky for some reason (written in Java / closed-source / specific to Apache / etc.) to me, but they exist, FWIW.
it would be nice if someone would come up with some sort of cgi version of javascript...
If we for a second imagine that we have server-side javascript with a print() function:
var a=1,b=2;
var func=function() { alert(a+b); }print("<html><head><script>\n");
print("var func="+as_code(func)+"\n");
print("func();\n");
print("</script></head><body></body></html>");This would cause the browser to show an alert saying "3".
At first glance, jsext seems to be the way to go.
Although I would like one with the new open-source Flash execution engine, as that one seems to be blazingly fast.
var a=1,b=2;
var func=function() { alert(a+b); }
print("<html><head><script>\n");
print("var a='"+a.toString()+"',b='"+b.toString()+";\n");
print("var func="+func.toString()+"\n");
print("func();\n");
print("</script></head><body></body></html>");I'm pretty sure that doesn't work universally, though. Is it part of the specs? And does it correctly handle the closure?
How big a problem is being specific to Apache, anyway? I mean, back in the days of Apache 1.x, the module interface was pretty much just a C-level superset of CGI that required Apache's C utility library.
>>15, interesting to know that Apache modules can be easily converted to something else. I would find using a JavaScript interpreter as CGI more elegant though.
Also, if you are security-conscious, you prefer your web apps to run as separate processes instead of inside the webserver process.
Good point.
>>16
Well true, but JavaScript runtimes tend to be on the heavy side which might lead to an unacceptably high per-page interpreter startup cost. It's the same problem as with using Perl as an implementation language for plain old CGI scripts, i.e. without mod_perl or FastCGI.
>>16
And this is not to say that one couldn't write an Apache module that was really really heavily dependent on Apache's internals. But the basic module interface is kinda like "initialize, provide a set of callbacks, callbacks are called to produce results when requests come in" with some constraints on threading and such.
The more I think about this, the more I like it. I'd really love to be able to write code like this on the server side:
var document=new DOMDocument("template.html");
document.body.onload=function() {
alert("test");
};
document.sendToClient();Building DOM documents on the server, and then dumping them to HTML for the client to rebuild would be great, especially if function references and closures would be preserved.
>>21, you are a very newbie.
>>21
doesn't know anything about security
>Yes, I've only been programming for about fifteen years.
programming your calculator? lol.
You want to say something, say it. This is the grown-up internet, stop acting like a teenager.
just ignore those guys. the goal of anonymous discussion is so all comments are made without any fear; this will mean good and bad comments will be made. the result is that all anonymous comments are judged on the merits of the comment and not by the reputation of the poster.
Seriously OP do you know how the HTTP protocol works?
Way back in the mid 90s the company I worked for did a lot of server-side Javascript work using Netscape's Livewire server. While there was a set of Javascript objects available for string manipulation, object creation and such, it still came down to doing things like
client.write("<html><body><p>Some variable = " + serverobj.prop1 + "</p></body></html>\n");
I don't remember it being that speedy, either.
Well, back in the mid 90s, Javascript fucking sucked. It's progressed by leaps and bounds since with the addition of the DOM and such.
>>28
If you are serious, explain what part of HTTP you think renders this a bad idea and why.
This is the most retarded thread ever.
Why, other than the idiots who keep posting useless flames without understanding the topic?
>>31
They were probably referring to the way that HTTP can't send a response without getting a request.
Instead of server-side javascript, I hereby propose client-side perl built right into the web browser, because mozilla needs one more reason to take loads of RAM.
>>35
Nah, AJAX doesn't fix it. It still sends a request. But like I was saying, RJS is very convenient for generating JavaScript on the server which goes back to the client and runs there instead.
Certainly this causes problems, but none of them are specific to running JavaScript on the server. That's more an argument against using scripting in the client.
Actually HTML can already embed whatever scripting language you want, but for some reason only a couple are really taken seriously.
Being able to write the app in a single language from front to end would be much neater than what we have to do now.
I read someone argue that HTML should be based on Lisp.
While I'm not a proponent of a language obsessed with parens, moving from (X)HTML/CSS/Javascript to a single format is appealing. A meta-circular evaluator is more powerful and probably cleaner than a DOM.
http://ejohn.org/blog/bringing-the-browser-to-the-server/ You might be looking for something like this.
Rhino on rails!
I thought you could do this with CGI and the js shell