Server-side Javascript
-
"Dave
November 15, 2006
</p><span class="comment-author"></span><p>ActuallyPaul I don’t have a personal website, I develop and maintain an online
banking website and I won’t post a link to that site because these
comments are my own. We use javascript extensively both client- and
server-side and we work hard to ensure our pages look good, load fast,
work in all modern browsers, and validate against the W3 standards. I
came here via a link in a web dev mailing list I subscribe to that I
normally consider a useful resource."http://www.christianmontoya.com/2006/11/05/hatin-on-javascript/
-
It's possible to use Javascript on ASP as the scripting language (server-side), but reasons why people would even use ASP (especially regular ASP) are beoynd me.
Personally, I have used javascript exactly twice on 'serious' matter. One was to make a web interface to control winamp. I can't remember for what I used it back then, but had something to do playlist.
Another was recently a project where I had to make a small closed quizz system. I didn't know the real questions (and they said they would be static), so to make it easier for client, I just made a simple javascript that was passing the questions around (it wasn't possible to add any custom formatings for questions tho since I just striped all html tags. I didn't want to leave cross-site scripting possibility even when using it was highly unlikely) so that they could easily modify the questions themselfs just on the first page (questions -> confirmation -> edit -> confirmation -> send). I could have made it using template of course, but I found that as the best solution and client approved it.
-
[quote user="Buzer"]It's possible to use Javascript on ASP as the scripting language (server-side), but reasons why people would even use ASP (especially regular ASP) are beoynd me.[/quote]
Cool, thanks for clearing that up : )
So would ASP be to server-side languages, what VB is to other PLs around here I guess?Just out of curiosity, I always thought of Javascript as being a language that interacted with the client. How would it be used server-side?
-
[quote user="donazea"]
Cool, thanks for clearing that up : )
So would ASP be to server-side languages, what VB is to other PLs around here I guess?Just out of curiosity, I always thought of Javascript as being a language that interacted with the client. How would it be used server-side?
[/quote]
Not sure what do you mean with the first question, so I will skip it for now.
Some "javascript asp" lessons
Also, JScript.NET does exists and as far as I know, it's posible to use it with ASP.NET. In my opinion, ASP sucks. Yes, you can use it with various languages (vbscript being the most common, but also supports javascript directly as said before. It's also possible to use perlscript, but that requires additional software), but I hate coding on all 3 that I know of, VBscript (=the most common) being the most haten.
-
[quote user="donazea"]
Just out of curiosity, I always thought of Javascript as being a language that interacted with the client. How would it be used server-side?
[/quote]
Javascript is just a language, you can use it anywhere you have an interpreter for it. In the ASP example, the ASP plugin to IIS contains/comes with a Javascript interpreter. Javascript is certainly best known for being used in web browsers to do dynamic stuff on the client side, but that's by no means its only possible use.
-
[quote user="donazea"]
Just out of curiosity, I always thought of Javascript as being a language that interacted with the client. How would it be used server-side?
[/quote]Netscape was doing that a long time before the ASP stuff people are talking about here. I remember trying to find documentation on Javascript back in the IE5 days and discovering that Netscape had a server product which could use Javascript syntax (eek) on the server. It had read-write file access, for example. (In fact, that's how I discovered it -- I was hoping there was some way to output a file after the user did some tinkering with controls, which of course normal Javascript can't do for very good reasons, and the searching brought up some documentation. Try searching Google with "site:Netscape.com Javascript server-side"
-
Personally, I love the Javascript language... The way prototypes are set up, you can do OO metaprogramming just as in Ruby. You could do an ActiveRecord-style ORM easily with a good database API.
I haven't actually messed with JScript.NET. Everything is C# here, and messing with a useful language will only make me wistful.
-
Now client-side Fortran -- THAT would be a WTF.
-
[quote user="Buzer"]It's possible to use Javascript on ASP as the scripting language (server-side), but reasons why people would even use ASP (especially regular ASP) are beoynd me.
Personally, I have used javascript exactly twice on 'serious' matter. One was to make a web interface to control winamp. I can't remember for what I used it back then, but had something to do playlist.
Another was recently a project where I had to make a small closed quizz system. I didn't know the real questions (and they said they would be static), so to make it easier for client, I just made a simple javascript that was passing the questions around (it wasn't possible to add any custom formatings for questions tho since I just striped all html tags. I didn't want to leave cross-site scripting possibility even when using it was highly unlikely) so that they could easily modify the questions themselfs just on the first page (questions -> confirmation -> edit -> confirmation -> send). I could have made it using template of course, but I found that as the best solution and client approved it.
[/quote]I agree server side javascript on ASP is rather painful. But it's really horrible to see people using vbscript for both server side AND client side. When they try to adjust their client code to work with other browsers, it just gets ugly.
When I use ASP, I prefer to use vbscript for server side, and javascript for client side. It not only keeps it clear which set of code is for which, but it eliminates the need to load the server side javascript package.
Nothing wrong with ASP though. You might have a preference for another system, and that other system might even be far better than ASP, but ASP is moderately clean and easy to use and does the job.
I'm curious though. What would you use if a client wanted you to set up some web pages on a brand new web server running Windows? What about an existing web server already running some ASP pages?
-
[quote user="newfweiler"]Now client-side Fortran -- THAT would be a WTF.[/quote]
eep, server side COBOL?
-
[quote user="writejustify"]
I'm curious though. What would you use if a client wanted you to set up some web pages on a brand new web server running Windows? What about an existing web server already running some ASP pages?
[/quote]
First case, either PHP (due to my knowledge of it) or ASP.NET. Second case, most likely continuing using ASP just so the site doesn't become one big WTF (ASP here, PHP there, ASP.NEt over there etc.)
-
[quote user="writejustify"]When I use ASP, I prefer to use vbscript for server side, and javascript for client side. [/quote]
Before C#, I used VBScript for server side ASP, except when it came to string handling. VBScript was such a WTF performance-wise with regard to strings, whereas the JScript libraries apparently handled them far better.
I'm curious though. What would you use if a client wanted you to set up some web pages on a brand new web server running Windows? What about an existing web server already running some ASP pages?
On a Windows server, I'd definitely use ASP.NET. Even for an existing site, since ASP and ASP.NET live reasonably well next to each other, I'd probably go ahead and configure the framework and slowly transition the ASP pages to .NET, depending on the size of their site and budget.
-
[quote user="donazea"]
"Dave
November 15, 2006
</p><span class="comment-author"></span><p>ActuallyPaul I don’t have a personal website, I develop and maintain an online
banking website and I won’t post a link to that site because these
comments are my own. We use javascript extensively both client- and
server-side and we work hard to ensure our pages look good, load fast,
work in all modern browsers, and validate against the W3 standards. I
came here via a link in a web dev mailing list I subscribe to that I
normally consider a useful resource."http://www.christianmontoya.com/2006/11/05/hatin-on-javascript/
[/quote]
My name is Christian Montoya. You DoS'ed my server. Prepare to die!
-
[quote user="donazea"]
eep, server side COBOL?
[/quote]This already exists: it is called a mainframe.
-
[quote user="donazea"][quote user="newfweiler"]Now client-side Fortran -- THAT would be a WTF.[/quote]
eep, server side COBOL?
[/quote]Been there; done that. The year was 1976. CICS on an IBM 370.
PROCEDURE DIVISION.
0001.
MOVE 10 to A1.
MOVE DFHBMEOF TO F1A.
EXEC CICS SEND
MAP('FILEMAP')
MAPSET('MACSET')
FROM(FILEMAPO)
END-EXEC.
-
[quote user="rien"]
[quote user="donazea"]
eep, server side COBOL?
[/quote]This already exists: it is called a mainframe.
[/quote]
No it EXISTS!
-
Javascript is a great language for doing ASP. For starters
- It's much better at OO than VBScript, including being able to override and enhance the built-in classes
- It has structured error handling
- Its date objects have more useful properties and higher resolution (milliseconds)
- It has a sensible, consistent syntax and sane expression parsing rules
- Increment and decrement operators (yay!)
- It has proper variable scoping
- It has powerful Array and Object classes
- You can use function pointers
- It has much better regex support built in
- etc etc etc
If I ever had to do another ASP site (like if, say, I was held at gunpoint) I would definitely use Javascript rather than VBScript.
As for the "being able to tell which is client-side and server-side script by the different syntax" nonsense - this should never be a problem because they should always be in separate files so that the browser can cache the .js files.
- It's much better at OO than VBScript, including being able to override and enhance the built-in classes
-
[quote user="donazea"][quote user="newfweiler"]Now client-side Fortran -- THAT would be a WTF.[/quote]
eep, server side COBOL?
[/quote]Server-side INTERCAL.It's been done.
-
Re: Server-side COBOL
Actually server-side COBOL in CICS (late 1970's) worked more or less like Java Servlets, kinda sorta.
A stream of data came in from the terminal. This consisted of data from form fields, along with a function-key code and something in a hidden attribute which indicated which procedure to call. The procedure would take the data, make calls to the database and then format a response to send back to the terminal, including a hidden attribute that indicated the next procedure.
Thousands of terminals could be serviced by one process on one mainframe. There was no multi-threading (multi-programming, yes, batch programs could be running on the same machine at the same time, but "threads" (lightweight processes within a process) were still an exotic concept). For each request, a procedure came in, did its work quickly and ended. An infinite loop in the procedure would hold up the whole system.
There wasn't really any advantage in using COBOL instead of Assembler, if you knew your way around the instruction set.
