December 22, 2006

Microsoft betting on .NET... or JavaScript?

Microsoft keeps pushing .NET to developers... but they are investing in a different technology (namely JavaScript) for some of their own new products.

Windows Vista includes the .NET Framework runtime but doesn't seem to use it for most of its applications, which is what I was expecting, but is still quite odd. As many Microsoft critics keep saying, "if they are not using .NET for their own applications, why should we?"

What is more surprising in Vista, though, is that the Desktop Gadgets (like the big clock you get by default) are not based on the .NET technology, as I was told a couple of years ago, if I remember well. Instead, they are HTML-based and use JavaScript for programming the gadget object model. The desktop use IE7 to display the gadgets. This is the same model used by Google for its own Gadgets.

Even more, Microsoft recently released the first community technology preview (CTP) of WPF/E, Windows Presentation Foundation for Everywhere. The technology is meant to take XAML and WPF to any browser or any operating system, and not only IE7 on Vista. However, at least for now, you program the object model in JavaScript (with a native .NET version expected next year, but originally promised from the start). Certainly, JavaScript is currently more portable than IL (the .NET Intermediate Language), but I'm not sure I get the point... unless AJAX is really taking over so much that Microsoft is shifting its priorities for developers.

Finally (on a different .NET-related topic), Nick Hodges (no I didn't know your 5 things) has reopened the debate of why the Delphi IDE needs .NET. Steve Trefethen discussed it 2 years ago, suggesting the only reason the Delphi Win32 IDE needs it is for the .NET CodeDOM that the refactoring technology uses. Even Allen Bauer, in the following discussion, partially disagrees. I think Borland should have enough code parsing technology to avoid this dependency, that makes little sense for Turbo Delphi for Win32. If you look at the BDS ToolsAPI you'll notice that most of the internal code sits exclusively on the Win32 side of the IDE.



Microsoft betting on .NET... or JavaScript? 

.net is slow and slow and slow.

Thank you!
Comment by Peter on December 22, 01:25

Microsoft betting on .NET... or JavaScript? 

Coming from D6/D7, my VS 2005 VB.NET experience this
year was like Chinese water torcher.  SLOW IDE. SLOW
EXE.  SLOW... slow... slow.  Had to change jobs, as I
just couldn't take it.

IMHO, .NET apps have a tendency to be slow and bloated.

I understand that BDS 2005 is probably worse than VS
2005.  I think CodeGear should offer BDS 2005
purchasers a free upgrade to BDS 2006 if they buy
software assurance.  That would be like 10-15% of the
actual cost.  Basically, offer retroactive software
Comment by Tom Wilk on December 22, 06:34

Microsoft betting on .NET... or JavaScript? 

Interesting post but I don't exactly see the point.  
You seem to be trying to set .NET and JavaScript 
against each other when they are two different 
things.  In other words it seems like you're trying 
to stir up a fight where there isn't one.

.NET and it's languages are used for completely 
different purposes than JavaScript.  JavaScript is a 
great glue language, you can just write a few lines, 
string bits together and tada! a gadget.  With .NET 
you'd have to make sure you create the right project 
type, set the right options, include the correct 
namespace, etc. etc.

Basically JavaScript is great for when you have a 
loose structure while .NET is exactly for when you 
want multiple layers and levels to your applications, 
when you need an actual framework.

On the IDE using the .NET framework I'm one of those 
that really don't care.  I only do native Win32 
development in BDS 2006 (I use VS'05 for ASP.NET) but 
I still don't mind the IDE using .NET.  I have enough 
other applications on my system that already use .NET 
that I don't even notice it and frankly don't 
understand why so many people care.  I hear a lot of 
people worry about "cluttering up" their system but 
what else are they using all the extra disk space and 
memory for?
Comment by Shawn Oster [] on December 22, 07:31

Microsoft betting on .NET... or JavaScript? 


  I know .NET and JavaScript have different roles...
but  if Microsoft spends its time drumming ".NET will
let you do this and that" and ends up implementing
those new relevant features using JavaScript, I think
something is wrong...
Comment by Marco Cantù [] on December 22, 10:40

Microsoft betting on .NET... or C++? 

For windowsmobile development you get the choice 
between native xor managed development.

So if you want to use their GPS intermediate driver 
you must use native code:

If you want to start a phonecall, you need managed 

Do they know themselves what they want us to use? 

Comment by TDaniel [] on December 22, 15:06

Microsoft betting on .NET... or JavaScript? 

There is little point IMHO to write desktop .NET apps 
unless perhaps you need to easily share assemblies 
between your desktop and some ASP.NET stuff you did.

Perhaps we are seeing so much Java is because of 
AJAX?  MS is somewhat afraid to be left behind on 
Comment by steve [] on December 23, 01:31

Microsoft betting on .NET... or JavaScript? 

 It's another case of do as I say, not as I do....
Comment by Delphite on December 23, 11:50

Microsoft betting on .NET... or JavaScript? 

I think Marco has a point. I was an early .NET 
believer and i already have a 6 years expertise on 
it. But the last 2 months i have done a tremendous 
effort to learn Python and i really like it.
The main reasons are that i am sick of Microsoft's 
policy to change things every now an then, sick of 
buying "new" books every now and then and sick of 
presenting us a technology that not even themselves 
are using.

I think MS has lost it's way somehow...
Comment by Kikapu on December 29, 12:02

Microsoft betting on .NET... or JavaScript? 

 how use java script in 2005)
Comment by periasamy T [] on December 30, 07:36

Post Your Comment

Click here for posting your feedback to this blog.

There are currently 0 pending (unapproved) messages.