In defense of the client (side)...
The Posting One
application. What did client-side javascript do for us that JScript .NET
cannot do for us?
1. Our application does about 14 million hits a day, generating over 20 GB
of traffic a day. We have 8 HTML servers, 8 business logic servers and 3
static content servers (for JS/CSS/etc...)
2. If JS goes away in favor of server-side JScript .NET, then what happens
to DHTML? It becomes useless. This means JS will not go away and that JS.NET
is a "big brother" technology.
3. Since our pages are all dynamic, embedding JS into the page itself (which
is what ASP.NET does) is a large waste. It does not get cached and is
constantly downloaded with the page itself. This increases server traffic, A
LOT!
4. External JS files are cached to the local PC and from that point on the
worst that happens is one small if-content-modified request per external JS
file about once a day. Compare that to downloading another 20k of ASP.NET
generated JS 14 million times in one day!
5. Out in our "field", there are tens of thousands computers with a raw
computing power of about 10,000 GHZ with memory stores of about 1,280 GB.
That's a lot of potential going to waste by ignoring the client.
6. With client-sode code you make everyone happy: Internal users get great
dynamic interfaces, developers work faster (though I concede that ASP.NET is
a fast development environment as well), administrators don't have any
distribution to worry about (in defense against distributed applications),
systems guys are happy that we have saved a lot of raw datacenter power by
utilizing the tens of thousands of PC’s out in the field.
It is critical that client-side JS have the same priority and justice as its
"big brother" JScript.NET, whether that means IE.NET and bringing JS.NET
down (preferable for an intranet) or JS growing up to be 6.0 or 7.0 with the
latest ECMA support (better for the internet as a whole)... I don't know, I
only know this:
Don't let them execute my client! He has lawyers fees to pay!
Thank you.
Code Ronin
> What did client-side javascript do for us that JScript .NET cannot do for us?
Work within the browser...? JScript.NET was designed to help
transition JScript code used in ASP pages to ASP.NET. It has no impact
on client-side JavaScript.
> 2. If JS goes away in favor of server-side JScript .NET,
Not anytime soon. That is like saying, "if JS goes away in favor of
server-side Java/Coldfusion/code...". There are a lot of advocates of
server-side code that will tell you not to "rely on" JavaScript as the
user may have it turned off, etc. I see the same argument with
cookies. I have been to numerous commercial websites that say "if you
do not have feature X turned on, I cannot help you". A good example is
Macromedia. Get very deep into it and you have to have the Flash 6
player loaded.
> then what happens to DHTML? It becomes useless.
No client-side (CS) JS and DHTML _is_ useless. But CS JS is not going
away anytime soon (if ever).
> This means JS will not go away and that JS.NET is a "big brother" technology.
What exactly did you read that caused you to freak out like this?
> 3. Since our pages are all dynamic, embedding JS into the page itself (which
> is what ASP.NET does) is a large waste. It does not get cached and is
> constantly downloaded with the page itself. This increases server traffic, A
> LOT!
ASP.NET increases bandwidth a lot for more than just not caching
script. All of those "RUNAT=server" commands get run on the server,
eventually causing a roundtrip to the server and back. And all of your
form data goes with it. But that is a whole other discussion.
> 5. Out in our "field", there are tens of thousands computers with a raw
> computing power of about 10,000 GHZ with memory stores of about 1,280 GB.
> That's a lot of potential going to waste by ignoring the client.
Ah! Another "do not treat web clients like dumb terminals" advocate.
Welcome, brother/sister!
> developers work faster (though I concede that ASP.NET is
> a fast development environment as well),
I think that ASP.NET is _much_ faster to crank out web apps in than
using client-side code. That is one of the problems (and major selling
points of ASP.NET): Microsoft attacked the development time issue and
largely succeeded. Compare it to server-side Java and VS smokes in
cranking out the code. The problem of course is that little
side-effect of increased bandwidth...
> It is critical that client-side JS have the same priority and justice as
> its "big brother" JScript.NET,
Ummm. JScript.NET does not have any real priority or justice. It is
definitely the "second-class citizen" if the .NET world. Maybe we
should shoot for a little higher?
Seriously, JScript will always get the short end of the stick as most
"serious" programmers consider it a "toy language" (which it is not).
But as long as more of them outnumber us, we will never get
first-class status in the MS world.
VB used to be "golden-haired boy" of MS, so anything VB was blessed.
That is why much of the ASP code is VBScript and not JScript. Now, the
reigning champion is C#, IMO.
I think "IE.NET" is somewhere on the horizon, but it is a long way
off. MS has not been able to sell .NET on the client (yet). Everywhere
I look it is .NET on the server. I hear about a few, bold enterprises
using .NET Windows apps, but they are few and largely not widely
distributed within the enterprise. .NET web apps, on the other hand...
> or JS growing up to be 6.0 or 7.0 with the latest ECMA support
Okay, you got me there. What is JScript missing that would indicate
that it does not have "the latest ECMA support"? Do you mean updating
IE so that it has the latest DOM support? (That would make more
sense.)
Unfortunately, MS has (supposedly) announced that IE 6 SP 1 will be
the last upgrade to IE as a standalone browser. In the future, in
order to get browser upgrades you will have to upgrade your Windows
OS. So do not expect too many enhancements in that department.
The Posting One
"Code Ronin" <code_...@yahoo.com> wrote in message
news:67120f77.03090...@posting.google.com...
> "The Posting One" <now...@somewhere.com> wrote in message
news:<OCV$3SZdDH...@tk2msftngp13.phx.gbl>...
>
> > What did client-side javascript do for us that JScript .NET cannot do
for us?
>
> Work within the browser...? JScript.NET was designed to help
> transition JScript code used in ASP pages to ASP.NET. It has no impact
> on client-side JavaScript.
Oddly enough the MS website advocates JS.NET as the end all for every JS
programmer. How many ASP pages were out there written with JScript? Very
few, almost all were written in VBScript. So where's the VBScript.NET?
Wouldn't that make more sense? I feel that JScript .NET was intended as a
client-side .NET script, but since .NET did not take off as fast as MS
envisioned, it got relegated to the server.
> > 2. If JS goes away in favor of server-side JScript .NET,
>
> Not anytime soon. That is like saying, "if JS goes away in favor of
> server-side Java/Coldfusion/code...". There are a lot of advocates of
> server-side code that will tell you not to "rely on" JavaScript as the
> user may have it turned off, etc. I see the same argument with
> cookies. I have been to numerous commercial websites that say "if you
> do not have feature X turned on, I cannot help you". A good example is
> Macromedia. Get very deep into it and you have to have the Flash 6
> player loaded.
Personally, I am speaking in defense of intranet applications. I think that
Internet sites should steer clear from depending on anything being installed
on the client...
> > then what happens to DHTML? It becomes useless.
>
> No client-side (CS) JS and DHTML _is_ useless. But CS JS is not going
> away anytime soon (if ever).
DHTML is nto useless, don't be silly. CS JS is going to stagnate under the
current IE, while it is flourishing in Mozilla. The whole point of MS's
arguments a long time ago was that their script engines are completely
separate from the browser can be plugged in at any time to ensure maximum
scripting support... well now they say that the browser and everything else
with it has to come along with the browser.
> > This means JS will not go away and that JS.NET is a "big brother"
technology.
>
> What exactly did you read that caused you to freak out like this?
It was a deduction.
> > 3. Since our pages are all dynamic, embedding JS into the page itself
(which
> > is what ASP.NET does) is a large waste. It does not get cached and is
> > constantly downloaded with the page itself. This increases server
traffic, A
> > LOT!
>
> ASP.NET increases bandwidth a lot for more than just not caching
> script. All of those "RUNAT=server" commands get run on the server,
> eventually causing a roundtrip to the server and back. And all of your
> form data goes with it. But that is a whole other discussion.
Fine.
> > 5. Out in our "field", there are tens of thousands computers with a raw
> > computing power of about 10,000 GHZ with memory stores of about 1,280
GB.
> > That's a lot of potential going to waste by ignoring the client.
>
> Ah! Another "do not treat web clients like dumb terminals" advocate.
> Welcome, brother/sister!
Not sure about the sarcasm here, maybe that is your gimmick?
> > developers work faster (though I concede that ASP.NET is
> > a fast development environment as well),
>
> I think that ASP.NET is _much_ faster to crank out web apps in than
> using client-side code. That is one of the problems (and major selling
> points of ASP.NET): Microsoft attacked the development time issue and
> largely succeeded. Compare it to server-side Java and VS smokes in
> cranking out the code. The problem of course is that little
> side-effect of increased bandwidth...
I doubt ASP.NET is _much_ faster (emphasis yours), it requires a compile
step, how can that be faster than any interpreted language? Maybe I am
wrong, but does ASP.NET support in-demand compiling? If so, then I can see
your statement being true. Otherwise, if you have to hit 'F5' or run a
command-line compile... then it's slower, though I can concede that at best,
it is as fast as client-side JS development.
> > It is critical that client-side JS have the same priority and justice as
> > its "big brother" JScript.NET,
>
> Ummm. JScript.NET does not have any real priority or justice. It is
> definitely the "second-class citizen" if the .NET world. Maybe we
> should shoot for a little higher?
No, if we wanted to shoot higher, then let's open up IE source code... I'm
being realistic and having a "bells & whistles" compiler like C# built into
the browser is asking too much. JScript.NET was DESIGNED for scripting!
> Seriously, JScript will always get the short end of the stick as most
> "serious" programmers consider it a "toy language" (which it is not).
> But as long as more of them outnumber us, we will never get
> first-class status in the MS world.
I'm not looking for first-class status, I'm looking for MS to support what
they build... They have enough programmers, there can't be 50,000 people
working on .NET...
> VB used to be "golden-haired boy" of MS, so anything VB was blessed.
> That is why much of the ASP code is VBScript and not JScript. Now, the
> reigning champion is C#, IMO.
Right, as I mention above, if JS.NET was meant as a bridge from ASP to
ASP.NET, that doesn't make much sense if the amount of VBScript ASP code
utterly dwarves the amount of JS ASP code out there (I don't have stats, but
I'd be willing to say it's about 9-1 VB to JS advantage). Makes little
sense, unless JS.NET was started as something else and wound up being quite
another.
> > whether that means IE.NET and bringing JS.NET down (preferable for an
> > intranet)
>
> I think "IE.NET" is somewhere on the horizon, but it is a long way
> off. MS has not been able to sell .NET on the client (yet). Everywhere
> I look it is .NET on the server. I hear about a few, bold enterprises
> using .NET Windows apps, but they are few and largely not widely
> distributed within the enterprise. .NET web apps, on the other hand...
I agree about IE.NET. It might be as long off as Longhorn. As for .NET
server-side, I agree that it is taking off. Does that preclude the fact that
MS spend a ton of time and money on the client-side features of .NET as
well? Should they not nuture it so that when all these enterprises learn
about the wonders of .NET, MS will have another avenue to generate revenue
from them? It's gotta start somewhere.
> > or JS growing up to be 6.0 or 7.0 with the latest ECMA support
>
> Okay, you got me there. What is JScript missing that would indicate
> that it does not have "the latest ECMA support"? Do you mean updating
> IE so that it has the latest DOM support? (That would make more
> sense.)
JS is currently floundering at around ECMA 1.2 support (much like they let
their Java runtime engine flounder at 1.1), while Mozilla supports 1.5 with
plans for 2.0 (admittedly, they came up with the 2.0 spec). I would like to
see ECMA take .NET and Mozilla's 2.0 and come up with a solid standard with
ideas from both camps (which from what I can tell overlap in quite a few
areas). Maybe that's what MS is waiting for. Maybe I'm delusional. Anyway,
perhaps MS is just averse to anything with the letter "J" in it?
> Unfortunately, MS has (supposedly) announced that IE 6 SP 1 will be
> the last upgrade to IE as a standalone browser. In the future, in
> order to get browser upgrades you will have to upgrade your Windows
> OS. So do not expect too many enhancements in that department.
I don't believe that statement. They also made a similar statement about OE
and both were retracted. But perhaps the truth leaks out and the lies flood
out. Perhaps MS should keep a tighter lip if those are in fact truths,
<mutter>because they would be breaching the antitrust agreement that they
have with many states.</mutter>
Code Ronin
> > > What did client-side javascript do for us that JScript .NET cannot do
> for us?
> >
> > Work within the browser...? JScript.NET was designed to help
> > transition JScript code used in ASP pages to ASP.NET. It has no impact
> > on client-side JavaScript.
>
> Oddly enough the MS website advocates JS.NET as the end all for every JS
> programmer.
That statement speaks nothing about whether JScript.NET works in the
browser.
> How many ASP pages were out there written with JScript? Very
> few, almost all were written in VBScript.
From the Framework SDK documentation: "The primary role of JScript
.NET is construction of Web sites with ASP.NET and customization of
applications with Script for the .NET Framework."
I do not know how many ASP pages were written in JScript. All I know
is that ALL of mine were.
> So where's the VBScript.NET? Wouldn't that make more sense?
It is called VB.NET.
> I feel that JScript .NET was intended as a client-side .NET script, but
> since .NET did not take off as fast as MS envisioned, it got relegated to
> the server.
Everyone is entitled to their own opinion. Read the JScript Language
Reference section of the Framework SDK Docs for more insight.
> Personally, I am speaking in defense of intranet applications. I think that
> Internet sites should steer clear from depending on anything being installed
> on the client...
Agreed. ASP.NET web application DO NOT require the .NET Framework on
the client-side, only on the server-side.
> > > then what happens to DHTML? It becomes useless.
> >
> > No client-side (CS) JS and DHTML _is_ useless. But CS JS is not going
> > away anytime soon (if ever).
>
> DHTML is nto useless, don't be silly.
I admit that what I wrote did not clearly convey what I was trying to
say. It was not "No, ...", but "Having no ...". I agree. No JS == no
DHTML.
> CS JS is going to stagnate under the
> current IE, while it is flourishing in Mozilla.
Define "flourishing". I see no evidence of _JavaScript_ flourishing in
Mozilla. Last time I looked, JS was still at 1.5 in Mozilla and JS 2.0
is still a dream. At least MS implemented their idea of JS 2.0 (even
if it was before the standard is finalized -- if ever).
> The whole point of MS's
> arguments a long time ago was that their script engines are completely
> separate from the browser can be plugged in at any time to ensure maximum
> scripting support... well now they say that the browser and everything else
> with it has to come along with the browser.
The same was true that the core rendering engine is a separate
component. The "browser" was really a security sandbox that glued
together the rendered and the script engine.
Yet, when I develop in .NET, I am still utilizing the same browser and
script engine components as those pieces have not all been converted.
(Hell, the complete Win32 API has not been converted to .NET, so do
not feel alone.)
Times change, like it or not. Personally, I prefer ASP, HTCs, and WSCs
because they are all founded upon using a prototype-based, dynamic
language rather than a class-based, static language.
> > > This means JS will not go away and that JS.NET is a "big brother"
> technology.
> >
> > What exactly did you read that caused you to freak out like this?
>
> It was a deduction.
You might recheck your premises. JScript.NET does not exist is any
usable fashion for the client-side. What MS did was provide a
migration route for ASP JScript code to ASP.NET. And that route is
simpler for the JScripters than the VBScripters, who have to go all
the way to VB.NET, which is a tough jump for some VB6ers.
> > form data goes with it. But that is a whole other discussion.
>
> Fine.
[gack] I sense some hostility. Sorry, but did you just want to vent to
the world or did you want to have a discussion? If I had known it was
the former, I would have simply moved on.
I feel like you are pissed at MS for leaving behind all you know and
love, but that is based upon a false premise: that JScript is being
replaced on the client-side by JScript.NET and that is simply not in
the cards at this time. MS has _NO_ significant penetration of placing
the .NET Framework on end-using clients. Without the CLR, JScript.NET
code will not work. Without the framework, no CLR. Period.
> > Ah! Another "do not treat web clients like dumb terminals" advocate.
> > Welcome, brother/sister!
>
> Not sure about the sarcasm here, maybe that is your gimmick?
The chip on your shoulder is so huge, it has blinded you to the fact
that I agreed with you on using more client-side code. The only thing
I do not agree with you on is where JScript is headed and what MS's
intentions were for JScript.NET. Chill out.
> > > developers work faster (though I concede that ASP.NET is
> > > a fast development environment as well),
> >
> > I think that ASP.NET is _much_ faster to crank out web apps in than
> > using client-side code. That is one of the problems (and major selling
> > points of ASP.NET): Microsoft attacked the development time issue and
> > largely succeeded. Compare it to server-side Java and VS smokes in
> > cranking out the code. The problem of course is that little
> > side-effect of increased bandwidth...
>
> I doubt ASP.NET is _much_ faster (emphasis yours), it requires a compile
> step, how can that be faster than any interpreted language?
[sigh] Do you really think that the major portion of time spent in
development is in the compiling step? I think the actual writing of
code takes longer. And MS focused on reducing the number of lines of
code that had to be written to accomplish the same goals. You should
look at the stats on how much code was reduced in the Java Pet
Shop/.NET Pet Store implementation. Too bad they did not implement in
ASP so we could see a comparison between old and new ASP tech.
> Maybe I am wrong, but does ASP.NET support in-demand compiling? If so, then
> I can see your statement being true. Otherwise, if you have to hit 'F5' or
> run a command-line compile... then it's slower,
You have not done ASP.NET development, have you? It does not sound
like you have even read the architectural overview on how ASP.NET has
changed. No, you do not need to do a command-line compile. [F5] starts
the web page so you can debug it. When you point your browser to the
.aspx page, if the appropriate code is not already compiled, it will
automatically compile.
> JScript.NET was DESIGNED for scripting!
To reiterate the JScript docs: "The primary role of JScript .NET is
construction of Web sites with ASP.NET and customization of
applications with Script for the .NET Framework." Look at that last
part. "Script for the .NET Framework." Not scripting for your web
page, but for the framework. Not client-side web scripting, but
"construction of Web sites with ASP.NET".
> I'm not looking for first-class status, I'm looking for MS to support what
> they build... They have enough programmers, there can't be 50,000 people
> working on .NET...
You need to take a look on Dice and Monster sometime and search for
.NET jobs (not that there are a whole lot of jobs out there anyway).
I agree that .NET has not taken off the way MS would have liked. Hell,
you can say the same thing for Windows 2003, Windows XP, and to a
lesser extent Windows 2000 and Office 2000.
Gartner Group estimated that slightly over 50% of Fortune 500
companies were going to continue to use NT 4 through the end of 2004.
When MS tried to pull the plug on providing patches for NT 4, the
industry "reacted unfavorably" and MS reversed and said NT 4 support
through 2004. Hmmm.
MS may have a ton of cash, but it still is not selling product as fast
as it is grinding it out.
> > > or JS growing up to be 6.0 or 7.0 with the latest ECMA support
> >
> > Okay, you got me there. What is JScript missing that would indicate
> > that it does not have "the latest ECMA support"? Do you mean updating
> > IE so that it has the latest DOM support? (That would make more
> > sense.)
>
> JS is currently floundering at around ECMA 1.2 support (much like they let
> their Java runtime engine flounder at 1.1),
Again, what specifically is in the ECMA-262 Version 3 specification
that is missing from JScript 5.6?
> while Mozilla supports 1.5 with plans for 2.0 (admittedly, they came up with
> the 2.0 spec).
Funny. Yet MS implemented their version of JS 2.0 first (it is called
JScript.NET).
> I would like to see ECMA take .NET and Mozilla's 2.0 and come up with a
> solid standard with ideas from both camps (which from what I can tell
> overlap in quite a few areas).
Which is, as far as I can tell, the dead ECMA-262 Version 4 spec. ECMA
seems in no hurry to morph JS to the 2.0 specs. And I, for one, cheer
that. I like JS as a prototype-base, weakly-typed, dynamic language.
When I want class-based, strongly-typed, static languages I do to C#
or Java, as my clients dictate.
> > Unfortunately, MS has (supposedly) announced that IE 6 SP 1 will be
> > the last upgrade to IE as a standalone browser. In the future, in
> > order to get browser upgrades you will have to upgrade your Windows
> > OS. So do not expect too many enhancements in that department.
>
>
> I don't believe that statement.
Okay.
I first heard about it when Opera shipped a new version and they
indicated that they would be the only (viable) commercial alternative
once MS went forward with their strategy. This was from a enewsletter
from developer.com. I Googled "internet explorer last standalone
release" and came up with over 20,000 hits. The top listing provided
the quote (but did not attribute it):
"As part of the OS, IE will continue to evolve, but there will be no
future standalone installations. IE6 SP1 is the final standalone
installation.... Legacy OSes have reached their zenith with the
addition of IE 6 SP1. Further improvements to IE will require
enhancements to the underlying OS."
Sorry if I came off as sarcastic and combatative. That was not my
intent. I agree whole-heartedly with client-side JSing. I do not want
to see JS morph from the language I love to the language I tolerate
(Java). I see no value in making JS "just like" all the other
languages.
Jim Ley
I've never seen that, or read that into the site - the web development docs
make little mention of it, the browser DOM always talks about Jscript 5.6
etc.
> How many ASP pages were out there written with JScript? Very
> few, almost all were written in VBScript.
Could you cite the study which states that, I know of a huge amount done in
JScript, and previous discussions on mailing lists have indicated lots.
> well now they say that the browser and everything else
> with it has to come along with the browser.
If you want a new script engine for IE6, you can get one over at
http://www.digitalmars.com/dscript/ they're telling the truth, the script
engine is seperate from the rest. JScript.NET is very different from just a
new script engine though, as it's got access to the .NET framework - the
ECMAScript Ed.4 improvements aren't particularly relevant in client-side
script, most people already over-engineer it leading to slow response.
Simpler authoring is the order of the day IMO (perhaps with better authoring
methods during the dev process to get those simpler scripts)
> JS is currently floundering at around ECMA 1.2 support (much like they let
> their Java runtime engine flounder at 1.1), while Mozilla supports 1.5
with
> plans for 2.0 (admittedly, they came up with the 2.0 spec).
JScript was ECMAScript Ed.3 compliant long before Mozilla - Netscape 6.0 was
released with a non-compliant engine at a time when IE was fully compliant.
You presumably don't understand what you're talking about - there is no ECMA
1.2 (well no ECMAScript 1.2, there may be some other - ethernet maybe?)
> Maybe that's what MS is waiting for. Maybe I'm delusional. Anyway,
> perhaps MS is just averse to anything with the letter "J" in it?
You do realise that Ed. 4 development is ongoing, and
http://www.ecma-international.org/memento/TC39-TG1.HTM notes the convenor
works for microsoft (this is actually interesting in that the convenor has
recently changed (well with ECMA quality of documentation the change
could've happened 12 months ago) the old one was also a Microsoft employee
though - he oven posts in jscript groups.
Client-side javascript isn't going anywhere, yes WEBforms are truly awful,
but don't worry, they're not getting much of a take up, they're inaccessible
garbage. JScript.NET though is still a powerful tool, and I don't imagine
the development costs of it are particularly high.
Jim.
Code Ronin
> (well with ECMA quality of documentation the change
> could've happened 12 months ago)
:) You are SO right.
> JScript.NET though is still a powerful tool, and I don't imagine
> the development costs of it are particularly high.
Have you been doing .NET development in JScript.NET? I have yet to try
Peter Torr's XForms, so I have been reluctant to try any Windows
Forms.
I have already worked around the lack of a true delegate, but
otherwise my only frustration with JScript.NET development is the lack
of support in Visual Studio.
Jim Ley
> Peter Torr's XForms, so I have been reluctant to try any Windows
> Forms.
No, not really, mostly just played, generally use C#, but then what I do is
collab with others, so, I actually do very little .NET, I don't run .NET
servers, I generally do either client-side js, or non-client WSH or C++
(not even using VS.NET as I get a lot of library compile trouble, so
sticking on VS6.0 or gcc). I've also been living out of backpack wandering
the world until recently, and only did a little real work and not much
hacking then, so my JScript.NET is rather limited, hence why I'm here
looking to learn!
Jim.
Peter Torr (MS)
but perhaps I can shed a little light on the situation...
"The Posting One" <now...@somewhere.com> wrote in message
news:%23%23EtIind...@TK2MSFTNGP09.phx.gbl...
> Oddly enough the MS website advocates JS.NET as the end all for every JS
> programmer.
Can you please point out the page that does that? I'll see if we can get it
fixed, because that's really not the message we want to give out, especially
since (as everyone has noted) there is currently no support in _any_
shipping browser for JScript .NET / ECMAScript Edition 4. It is certainly
the easiest way for JScript programmers writing server-side code to migrate
to the .NET platform though.
> How many ASP pages were out there written with JScript? Very
> few, almost all were written in VBScript.
As others have pointed out, this is not correct. For example, did you know
that the entire MSDN site was written in server-side JScript? You've
probably heard the phrase "there are lies, damned lies, and statistics".
Well, I've seen some statistics on JScript ASP usage that put it as much as
1/3 of all sites, but of course that could be high or it could be low. Who
really knows? Whatever the final number is, it's definitely true that many
people underestimate the popularity of JScript in non-browser environments
simply because VBScript got more press than JScript.
> I feel that JScript .NET was intended as a
> client-side .NET script, but since .NET did not take off as fast as MS
> envisioned, it got relegated to the server.
JScript .NET was primarily designed to facilitate ASP .NET migration and to
enable ISVs to embed script inside their .NET applications. The compiler /
runtime was designed to have at least some chance of being usable in a
dynamic environment such as a web browser at some point in the future (and
it does work, to some extent -- see my VsaControl sample), but it was never
a goal for v1 because neither the CLR nor IE nor VB had all the pieces in
place to enable "DHTML .NET". The security requirements alone make this
concept dead in the water for the current releases (.NET code requires
FullTrust to interact with COM, and there's no way anyone is going to give
random websites FullTrust just so they can enable some drop-down menus).
> The whole point of MS's
> arguments a long time ago was that their script engines are completely
> separate from the browser can be plugged in at any time to ensure maximum
> scripting support...
IActiveScript enables you to plug in Perl, or Ruby, or Python, or any other
language that has an IActiveScript-based engine into IE. One thing that may
be missing here is that JScript .NET does _not_ support IActiveScript, so
therefore it cannot be plugged into IE (or any other traditional script
host). It supports IVsa, which was the .NET scripting interfaces, but these
are a lot less dynamic than IActiveScript, and don't deal with things such
as expression evaluation, incremental download, etc.
We played around with an IActiveScript wrapper for VSA, but it was a mess.
Don't try this at home, kids. There were dreams of a VSA 2.0 that would be
more dynamic and support these kinds of things, but that has not happened
and is not likely to in the future, either.
That's not to say you'll never get DHTML-like behaviour with .NET code --
maybe one day you will -- but it won't be via IActiveScript or VSA.
> I doubt ASP.NET is _much_ faster (emphasis yours), it requires a compile
> step, how can that be faster than any interpreted language? Maybe I am
> wrong, but does ASP.NET support in-demand compiling? If so, then I can see
> your statement being true.
ASP .NET is a *lot* faster than ASP. It supports "on demand" batch
compilation of entire directories if you use notepad-style development, but
if you use VS .NET then all files are compiled in one go and published as a
DLL to the web site. There is no on-the-fly compilation per page request.
ASP .NET with unoptimised JScript and a lot of ActiveX controls may be
slower than ASP / JScript 5.x, but if you follow the simple guildelines at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/jstchASPPerfTips.asp
then JScript .NET on ASP .NET will be much faster than the ASP equivalent.
More info on porting is at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnclinic/html/scripting01222002.asp
> JS is currently floundering at around ECMA 1.2 support (much like they let
> their Java runtime engine flounder at 1.1), while Mozilla supports 1.5
with
> plans for 2.0 (admittedly, they came up with the 2.0 spec). I would like
to
> see ECMA take .NET and Mozilla's 2.0 and come up with a solid standard
with
> ideas from both camps (which from what I can tell overlap in quite a few
> areas).
As Jim points out, you have your version numbers mixed up. ECMAScript
Edition 3 is the most recent standard, and it has been supported since
JScript 5.5 (which I think shipped in 2000). Even JScript 5.0 had partial
support for Edition 3 (try-catch, for instance) but the standard was not
finalised at that stage.
Netscape's versioning system (1.1, 1.2, etc) has no bearing on either the
ECMA or the Microsoft version numbers. The JavaScript 2.0 spec (which is
still incomplete) was intended as a suggestion for the basis of ECMAScript
Edition 4, along with the work Microsoft did with JScript .NET. If you look
at the history of JavaScript Edition 2, you will notice that it has changed
a lot over the past few years due to the work of the ECMAScript committee,
and a large amount of complexity that was in the language has now gone --
given that many people think that classes are too complext for ECMAScript
programmers, they would have been completely baffled by all the namespacing
and versioning stuff in the original JavaScript 2 spec.
Peter (former JScript .NET Program Manager and ECMAScript Convenor)
--
Please post questions to the newsgroup - everyone benefits.
This post is provided "AS IS" with no warranties, and confers no rights
Sample code subject to http://www.microsoft.com/info/cpyright.htm
Bore yourself to tears -- http://blogs.gotdotnet.com/ptorr
Code Ronin
> OK so I don't want to get pulled into a long, drawn out bloodfest here :-),
Was it _that_ bad?
> really knows? Whatever the final number is, it's definitely true that many
> people underestimate the popularity of JScript in non-browser environments
> simply because VBScript got more press than JScript.
I was surprised to see all of the JScript files in the C# Wizard
folders. Do you have a link that documents what is going on in those
files?
> > I doubt ASP.NET is _much_ faster (emphasis yours), it requires a compile
> > step, how can that be faster than any interpreted language? Maybe I am
> > wrong, but does ASP.NET support in-demand compiling? If so, then I can see
> > your statement being true.
>
> ASP .NET is a *lot* faster than ASP. It supports "on demand" batch
> compilation of entire directories if you use notepad-style development, but
> if you use VS .NET then all files are compiled in one go and published as a
> DLL to the web site. There is no on-the-fly compilation per page request.
The original context of the discussion was on the speed of development
(i.e. cranking out code), not on the speed of an interpreted page
versus a compiled page. See below.
> > > developers work faster (though I concede that ASP.NET is
> > > a fast development environment as well),
> >
> > I think that ASP.NET is _much_ faster to crank out web apps in than
> > using client-side code. That is one of the problems (and major selling
> > points of ASP.NET): Microsoft attacked the development time issue and
> > largely succeeded. Compare it to server-side Java and VS smokes in
> > cranking out the code. The problem of course is that little
> > side-effect of increased bandwidth...
>
> I doubt ASP.NET is _much_ faster (emphasis yours), it requires a compile
> step, how can that be faster than any interpreted language?
I think the point, which I do not agree with, is that an interpreted
language is automatically faster to develop in than a compiled
language. If I were to make generalizations, it would be that I think
an interpreted language is easier to debug and correct than a compiled
language.
The most common problems with JScript code are runtime errors, which I
view as deferred compile errors. But some people feel that because the
code is up and running quicker (before it hits that fatal error),
interpreted language development _is_ faster. I think it just _feels_
faster.
> If you look
> at the history of JavaScript Edition 2, you will notice that it has changed
> a lot over the past few years due to the work of the ECMAScript committee,
> and a large amount of complexity that was in the language has now gone --
You mean "a large amount of complexity that was in _the 2.0
specification of_ the language has now gone", right?
> given that many people think that classes are too complext for ECMAScript
> programmers,
Not sure how to take that... Most of the programmers I know that do
heavy ECMAScript also do Java, C#, C++, etc. I would certainly agree
that the majority of people that "write" ECMAScript are not
programmers at all, but web page designers that cut-and-paste
snippets. (Then they get on comp.lang.javascript and ask "why does
this not work" when they change one line of code. ;-) )
> they would have been completely baffled by all the namespacing
> and versioning stuff in the original JavaScript 2 spec.
I am not sure I agree all around. The Snippets will continue to do
what they do: cut-and-paste other peoples work without caring how it
works. The ones that can code, but do not care about understanding
JavaScript, will continue to grind out code in a procedural style like
it was C code. The Java-wannabe's will embrace the changes until they
find out "it is not all there", and then complain. Finally, those that
have come to understand that JavaScript _is_ a totally different beast
and needs to be handled differently, will resent any dynamism lost in
order to make JavaScript more like Java.
I understand why you made JScript.NET the way you did -- if it wanted
to be a .NET player, it had to conform to the rules of the CLR. One of
the things I was shocked about when I read "Inside Microsoft .NET IL
Assembler" was that, in IL, a class could be reopened, so to speak,
and additional code added to it. That all source code for the class
did not need to reside in the same file. (I believe the next version
of C# is going to allow this.)
To me, this was a perfect example of what JScript.NET should have
allowed from the start. It fits in well with the Augmentation style of
coding that some JavaScripters use. Ah well. You know more about the
internals (code and politics) than I, and I am sure that the rigors of
the schedule probably prevented straying beyond. Just a thought.
I, for one, am glad client-side JavaScript is staying right where it
is for awhile. I still have customers that will continue to use ASP
over ASP.NET (for whatever reason), so this allows me to leverage
previous code for (probably) years to come.
Jim Ley
> "Peter Torr \(MS\)" <pt...@microsoft.com> wrote in message
news:<eU#d1B#dDHA...@tk2msftngp13.phx.gbl>...
ECMAScript
> > programmers,
>
> Not sure how to take that... Most of the programmers I know that do
> heavy ECMAScript also do Java, C#, C++, etc.
No, they don't do Java do they, please... comp.lang.javascript these
days is doing lots of talking about OOesque authoring. I'm of the opinion
that _client-side_ javascript doesn't need this, too many sites are now
becoming unusable because people insist on executing huge amount of slow
script on load, at which point the browser locks up (this is one reason I
never go near MSDN anymore, especially disappointing the jscript docs moved
into the same gobbledygook. client-side JS needs to be lean and mean, and
never lock the browser up - setTimeout to allow events to go in-between DOM
operations is handy (for example you're re-writing all DIV's in the document
to another class - do 10 at a time with 100ms in between.)
Of course if you're doing things in Zeepe or other javascript frameworks
where it's not the http client-server approach, then yes it makes sense, but
not in general webpages.
Defaulting to doing it on the server is even slower of course.
Jim.
Peter Torr (MS)
> > OK so I don't want to get pulled into a long, drawn out bloodfest here
:-),
>
> Was it _that_ bad?
No, but it could've become bad ;-)
> I was surprised to see all of the JScript files in the C# Wizard
> folders. Do you have a link that documents what is going on in those
> files?
You probably hace to license VSIP
(http://msdn.microsoft.com/vstudio/partners/default.aspx) to get the info.
Basically, all the New Project wizards are HTML pages with JScript code that
uses the VS DTE object (Development Tools Environment) -- think DOM -- to
create the files, etc.
> I think the point, which I do not agree with, is that an interpreted
> language is automatically faster to develop in than a compiled
> language. If I were to make generalizations, it would be that I think
> an interpreted language is easier to debug and correct than a compiled
> language.
I wrote so much here that I decided to commit it to my blog! Wow, some
actual content is up there now! :-)
http://blogs.gotdotnet.com/ptorr/PermaLink.aspx/eccc1d2e-fb94-43a0-bf43-5adadb5f579f
A lot of it doesn't pertain directly to this thread, but whatever.
> > If you look
> > at the history of JavaScript Edition 2, you will notice that it has
changed
> > a lot over the past few years due to the work of the ECMAScript
committee,
> > and a large amount of complexity that was in the language has now
gone --
>
> You mean "a large amount of complexity that was in _the 2.0
> specification of_ the language has now gone", right?
Yes, although from time to time there have been attempts to break
compatibility with Edition 3. There are many parts of E3 that are pretty bad
and most people want to be able to turn off for various reasons (prototype
munging, the 'arguments' object, 'with' blocks, octal numbers, etc), and
these deletions have been relegated to JScript's "fast" mode and Netscape's
"strict" mode in order to maintain compatibility.
> I understand why you made JScript.NET the way you did -- if it wanted
> to be a .NET player, it had to conform to the rules of the CLR.
Err, yes... by definition ;-)
> One of
> the things I was shocked about when I read "Inside Microsoft .NET IL
> Assembler" was that, in IL, a class could be reopened, so to speak,
> and additional code added to it. That all source code for the class
> did not need to reside in the same file. (I believe the next version
> of C# is going to allow this.)
To the best of my knowledge (which isn't much ;-) ) this is a source-level
feature; a class can be defined in one file, and then added to in another
source file, as long as they are both compiled together (much the same way
that almost any compiler these days can take an arbitrary number of source
files and output a single binary). But it may be at the binary (module)
level... I don't know.
> To me, this was a perfect example of what JScript.NET
You forgot the space. YOU FORGOT THE SPACE!!!! :-)
(Sorry... before release, there were large internal debates over whether it
was "JScript .NET" or "JScript.NET". In fact there were debates about
whether it could even be called ".NET", despite the fact that it was the
only compiler we shipped that was written entirely in managed code... but I
digress. Marketing has a lot to answer for! :-) )
> should have
> allowed from the start. It fits in well with the Augmentation style of
> coding that some JavaScripters use. Ah well. You know more about the
> internals (code and politics) than I, and I am sure that the rigors of
> the schedule probably prevented straying beyond. Just a thought.
In general, augmentation is done via inheritance. The prototype modification
scheme is still usable in "slow" mode, but this has real problems in a world
where people write components. If I modify the 'toString" method of an
object to do something random, then is that change scoped only to MY code,
or does it also affect any other code I call into? What about non-JScript
code? It's a hard problem.
Peter
--
Peter Torr - http://blogs.gotdotnet.com/ptorr/
This posting is provided "AS IS" with no warranties, and confers no rights
Samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm