JScript .NET PDC 2001 Demos available on GotDotNet
Peter Torr (MS)
I finally had time to add some minimal documentation to these samples (and a
few more features ;-) ) and they're available on the web right now --
http://www.gotdotnet.com/userfiles/torrboy/PDC2001.zip
These demos include:
* Using JScript .NET from C# and VB
* Using Managed Extensions to C++ from JScript .NET
* Writing a simple arcade game in JScript .NET and using VSA to customise it
* Using JScript .NET inside Internet Explorer to build cool web pages
* Good old VsaDemo app for hacking on scripts
The code has been tested on the Release Candidate of the .NET Frameworks
(the build handed out at the PDC). You should be able to hack it to get most
of it working on Beta 2 if that is what you are still using, although there
may be some bugs in Beta 2 that prevent code from running.
Enjoy!
Peter
--
Peter Torr -- pt...@microsoft.com -- JScript .NET / VSA Runtime
Waiting for the Vengabus? http://www.microsoft.com/info/cpyright.htm
Please post all questions to the group. Thanks.
djaubert
Hi,
Is there a chance, a day, to use js7 as client scripting
in IE ?
Regards
>.
>
Peter Torr (MS)
news:b65801c1719f$80c27190$b1e62ecf@tkmsftngxa04...
> Is there a chance, a day, to use js7 as client scripting
> in IE ?
Hi,
Although this is not supported in this release of .NET, it is one of the
things we would like feedback on. Do you think it is a compelling feature to
have, considering it will require the CLR on the client machine?
Christoph Kreß
Yes, definitely! Especially in environments with a controlled range of user
agents like large corporations this makes perfect sense. If I had three
wishes free, one of them would be: JScript.NET for IE 5+. (The others I
won't tell :) .)
Christoph
"Peter Torr (MS)" <pt...@microsoft.com> wrote in message
news:OMJ0nFecBHA.1440@tkmsftngp04...
Manfred Braun
and thanks for the offer. I think:Yes!! But to go into more details, I think
a rewritten IE, based on dot:net would finally be, that what I need. More an
admin then a programmer, I moved over the must stuff to HTA's (starting at
last year). I'll not start dealing with interop (and embed the IE control
into winforms), and the most times, I think, a winforms app would solve most
of my needs (especially, because of inheritence!!!!), but it is too much
work to start with currently (I am at overview-level). On the other hand,
the is no control, which offers to create HTML output directly (and I use
much DHTML), but I am not at details level currently. Winforms and
inheritence could possibly let us build simplified (re-usable) apps, so that
I could go completely to C# (that would be my preference instead of
scripting). If not, scripting, with the possibility to use win32 api and the
dot.net framework would be the best. In an intranet-environment,
distributing the runtime at the next rollout, is not a too big problem (like
many updates would be).
Best regards,
Manfred Braun
(Private)
Lange Roetterstrasse 7
D68167 Mannheim
Germany
mailto:_mbr...@manfred.mannheim-netz.de
(Remove the anti-spam-underscore to mail me!)
"Peter Torr (MS)" <pt...@microsoft.com> schrieb im Newsbeitrag
news:OMJ0nFecBHA.1440@tkmsftngp04...
wa
>
Scott Dinwiddie
Thanks for the demos. I downloaded and worked with them some. I'm curious
to hear opinions on how using compiled script (in a web page) on the client
compares to using Windows Forms Controls (in web pages). I've prototyped
both now and for a Java developer moving to C# it (at least initially) seems
a lot easier to develop the Windows Forms Controls. Can you tell me if
there are clear advantages to using the compiled script? Also, your
disclaimer indicates that this is not a supported feature yet and it seems
like the Windows Forms Controls are.
Thanks
Scott Dinwiddie
"Peter Torr (MS)" <pt...@microsoft.com> wrote in message
news:uBdoXJUcBHA.1960@tkmsftngp03...
Peter Torr (MS)
news:uRmxohQfBHA.996@tkmsftngp03...
> Peter,
>
> Thanks for the demos. I downloaded and worked with them some. I'm
curious
> to hear opinions on how using compiled script (in a web page) on the
client
> compares to using Windows Forms Controls (in web pages).
Hi Scott,
There are several reasons why you might want to use compiled script on a web
page; some of them are alternatives to Windows Forms, and some of them work
in conjunction with Windows Forms.
One of the most compelling scenarios for non-JScript developers is the
ability to interact with Windows Forms controls within the web page. In .NET
v1.0, in order for a Windows Forms control to interact with the browser (eg,
to fire events) the control author must do two things:
1) Do a lot of extra work defining COM interfaces, implementing them, and so
on.
2) Require FullTrust for COM interop
The VSA control eliminates the first item above: you can natively interact
with .NET events without going through all the COM interop hoops. The VSA
control doesn't eliminate the second item -- it still requires FullTrust --
but this is one of the reasons why it's not really a supported scenario. In
the future, if we were to fully implement this technology, you would be able
to interact with the web page without any COM goo and without FullTrust.
Another scenario that works hand-in-hand with Windows Forms controls is when
you actually create the UI dynamically inside the script code, rather than
as a pre-compiled DLL that downloads with the page. This basically gives you
the RAD experience of writing web pages with all the features of Windows
Forms controls. The last demo on the "Internet Explorer" page shows how you
can dynamically build a TreeView control using only script in the page.
One of the places where script would be an alternative to Windows Forms is,
for example, when you want to display a table of data on a web page. If you
use the Windows Forms controls, you get some nice designer support and so
on, but HTML is a much richer, more flexible way to present data than a data
grid, so you could write some JScript .NET code to talk to your back-end Web
Service, pull in the data, and very richly render it on the client. All
sorts of other UI can be done in HTML that is difficult to do in Windows
Forms (any kind of Flow Layout, for example) and it's another case of RAD
development. I can just change a couple of lines in my page, refresh the
browser, and hey presto! the change is applied. Versus making the change,
rebuilding the project, restarting IE, and then seeing the change. This is
particularly annoying if the page you want to view is not your start page...
Then there are a bunch of scenarios that don't really involve UI at all, but
make existing web pages or scenarios better:
* Replacing Remote Scripting with Web Services
* Speeding up complex processing
* Running processing in a separate thread, so that the UI doesn't lock up
* Full access to the .NET platform (assuming the code is trusted)
* etc
> Also, your
> disclaimer indicates that this is not a supported feature yet and it seems
> like the Windows Forms Controls are.
Correct; Windows Forms controls are supported, and the VSA control is not.
It is just a "demo" to see if customers think compiled script code in a web
page is a useful feature to add in the future.
Scott Dinwiddie
Thanks for the feedback. Some interesting stuff to digest. I don't suppose
you guys have a target date set for making a decision on supporting the
compiled script code in a web page functionality?
Thanks
Scott Dinwiddie
"Peter Torr (MS)" <pt...@microsoft.com> wrote in message
news:uEQv3#bfBHA.2364@tkmsftngp03...
Joost Devos
> things we would like feedback on. Do you think it is a compelling feature
to
> have, considering it will require the CLR on the client machine?
I think this will boost the distribution of the .NET technology !
Considering a web-application, in fact you always have 2 3-tier
applications.
- one on the client side browser: with its own visual presentation layer,
its own business-logic and its own disconnected data-layer. This application
acts as a consumer for web-services...
- one on the server: with its invisible web-interface (presentation), its
own business-logic and its own data layer. This application acts as a
provider for web-services...
As I see it now, the current (ASP).NET developments are mainly focused on
server-side developments to provide standardized output for all kind of
browsers and devices...(which is great !).
However we want users to have a great user-experience, not with flashy stuff
but with clever rich controls that respond to events on the client side
(without the need for server loopback). At the time being, it is not
possible to serve all devices through the same "one identical rich client
side application" especially when it comes to the "CLR" and "base class
library" functional possibilities. The nature of each device type (WAP <>
handheld <> desktop) doesn't allow this so far.
So if the CLR is available at the client side...
- wouldn't it be nice to have a pre-compiled script that builds up the IE
document >100 times faster (strong typing, no compiling, no unneccessary
web-traffic) ?
- wouldn't it be nice to have a pre-compiled script that checks the business
logic of the builded IE document >5 times faster (more hidden for prying
eyes) ?
- wouldn't it be nice to have a pre-compiled script that handles the data
layer of the builded IE document >5 times faster ?
It will also free the load on the server a lot. The document only has to
call a web-services to exchange (xml) data...
Overriding or re-writing the 'rendering' in .NET still delivers uncompiled
script to the browser that has to be rendered on a page per page basis and
that's something standard I don't like to touch...
Providing us that compelling feature will enable to see the web-server as
1° a source for assemblies (the latest version is always available and
automaticaly updatable at the client)
2° a web-services server
I can agree that the vision of MS is to have
- "web-forms" on the one hand
and
- "windows-forms" on the other hand
but I don't see any reason why IE may not be a serious candidate the host
compiled (scripting) applications with a rich HTML presentation interface ?
So if IE can do both, traditional (D)HTML and compiled scripting, it's again
far ahead its competitors !
It's part of MS vision today !
"Empower people through great software any time, any place, and on any
device..."
What are you waiting for ??????
Peter Torr (MS)
news:uKa9So#fBHA.2052@tkmsftngp03...
> I think this will boost the distribution of the .NET technology !
Thanks for the reply Joost -- it's great to hear what customers want to do
with our technology!
You scenarios are all valid and are the kinds of things we expect people to
be doing, but I just wanted to address one thing: Performance.
> So if the CLR is available at the client side...
> - wouldn't it be nice to have a pre-compiled script that builds up the IE
> document >100 times faster (strong typing, no compiling, no unneccessary
> web-traffic) ?
Unfortunately, this is not a realistic expectation. For a start, .NET code
is not 100x faster than script code. If you downloaded the sample from
gotdotnet, you can check some very simple (and meaningless!) benchmarks at
http://localhost/pdc2001/InternetExplorer/perftest.html but you will see
that even numeric processing is only about 20 times faster in .NET than in
script. DOM interactions are actually slower than in script because IE is
still a COM component, and there are significant perf costs for COM interop
in .NET.
Of course if you build a hybrid HTML / Windows Forms application, it could
be a lot faster, and by minimizing your interactions with the DOM you can
avoid this performance hit, but the actually rendering of content will not
be any faster, and will likely be slower.
> - wouldn't it be nice to have a pre-compiled script that checks the
business
> logic of the builded IE document >5 times faster (more hidden for prying
> eyes) ?
> - wouldn't it be nice to have a pre-compiled script that handles the data
> layer of the builded IE document >5 times faster ?
This is where you will should see performance wins: computationally
expensive operations, or code that currently relies on COM objects that can
be replaced with .NET objects should get faster.
Nevertheless, we don't see performance as the #1 reason for doing this (and
indeed anyone who ported their client-side code to .NET purely for
performance reasons would probably be disapppointed). Enabling better web
service integration, richer client interactions, and the ability to
communicate with Windows Forms controls are three of the bigger reasons why
we think this would be a useful technology.
> What are you waiting for ??????
Customer feedback, among other things!
Joost Devos
> is not 100x faster than script code. If you downloaded the sample from
> gotdotnet, you can check some very simple (and meaningless!) benchmarks
at
> http://localhost/pdc2001/InternetExplorer/perftest.html but you will see
> that even numeric processing is only about 20 times faster in .NET than in
> script. DOM interactions are actually slower than in script because IE is
> still a COM component, and there are significant perf costs for COM
interop
> in .NET.
Sorry, 100 was a big typo, I meant 10x here. I also was not only addressing
the .NET "code" here. I was also focusing the fact that the code didn't have
to come over the wire but was locally available, and this would be the
biggest performance gain I guess.
We build document controls up from scratch (using createElement(),
appendChild(), etc...). Do I read between the lines that using pre-compiled
script will not be faster in that specific case because of the COM interop
between .NET en the IE DOMDocument ? At least we'll gain the traffic time
over the wire (for the client) and the freed bandwith and CPU usage (for the
server).
Although I have no access to your http://localhost it interests me to have a
look at these IE benchmarks :-)
Thanks
Joost
Peter Torr (MS)
> Although I have no access to your http://localhost it interests me to have
a
> look at these IE benchmarks :-)
If you download and install the PDC demos referenced in the original mail,
and set up a vroot for the PDC2001 directory, you will be able to access the
page from your very own localhost ;-)