Tag Archives: javascript

internet, javascript, software development, windows

Microsoft partners with Joyent to bring node.js server-side JavaScript to Windows

Microsoft will port node.js to Windows in partnership with Joyent. This will work on Windows Azure as well as other versions of Windows back to Server 2003.

But can you not already run node.js on Windows? This is possible using Cygwin and instructions are here. Cygwin makes Windows more like Linux by providing familiar Linux tools and a Linux API layer. Cygwin is a great tool, though it can be an awkward dependency, but a true Windows port should be higher performance and more robust, particularly as the intention is to use the IOCP API. See here for an explanation of IOCP:

With IOCP, you don’t need to supply a completion function, wait on an event handle to signal, or poll the status of the overlapped operation. Once you create the IOCP and add your overlapped socket handle to the IOCP, you can start the overlapped operation by using any of the I/O APIs mentioned above (except recv, recvfrom, send, or sendto). You will have your worker thread block on GetQueuedCompletionStatus API waiting for an I/O completion packet. When an overlapped I/O completes, an I/O completion packet arrives at the IOCP and GetQueuedCompletionStatus returns.

IOCP is the Windows NT Operating System support for writing a scalable, high throughput server using very simple threading and blocking code on overlapped I/O operations. Thus there can be a significant performance advantage of using overlapped socket I/O with Windows NT IOCPs.

I was impressed by node.js when I saw it presented by author Ryan Dahl at a pre-Dreamforce event last year. Since then it has become better known. This is an interesting move, particularly in the context of an greater focus on JavaScript in the forthcoming version of Windows known as Windows 8. End to end JavaScript for your next-generation real time networking applications?

.net, microsoft, professional, software development

Full circle at Microsoft: from the early days of .NET to the new Chakra JavaScript engine

11 Comments

A discussion with a friend about the origins of Microsoft’s .NET runtime prompted a little research. How did it come about?

A quick search does not throw up any detailed accounts. Part of the problem is that much of it is internal Microsoft history, confidential at the time.

One strand, mentioned here, is Colusa’s OmniVM:

OmniVM was based on research carried out by Steven Lucco at Carnegie Mellon University. Steven co-founded Colusa Software in February 1994 in Berkeley, California. Omniware was released in August 1995. Colusa started working with Microsoft in February 1996. Microsoft acquired Colusa Software on March 12, 1996. Steven is currently a senior researcher at the Microsoft Bay Area Research Center.

OmniVM was appealing to Microsoft because Colusa had already created Visual Basic and C/C++ development environments for the VM. The VM was also claimed to be capable of running Java.

Microsoft took to calling the VM by the name of CVM, presumably for Colusa Virtual Machine. Or perhaps this is where the code name Cool came into being. Other names used at Microsoft include Universal Virtual Machine (UVM), and Intermediate Language (IL).

Microsoft’s Jason Zander, commenting to a story on this blog, does not mention OmniVM:

The CLR was actually built out of the COM+ team as an incubation starting in late 1996. At first we called it the "Component Object Runtime" or COR. That’s why several of the unmanaged DLL methods and environment variables in the CLR start with the Cor prefix.

Still, the timing pretty much matches. If Lucco came to Microsoft in 1996, he could have been part of an incubation project starting later that year.

In June 1999 Microsoft previewed the Common Executable Format for Windows CE:

A demonstration on Common Executable Format (CEF), a new compiler target within the Visual C++® development system for Windows CE, was also presented. This compiler enables cross-processor portability within a category of devices, such as Palm-size PCs or Handheld PCs. A single program executable under CEF is translated to the native code on either the host PC or the device, as desired. This capability eliminates the need for developers to recompile an application for every possible processor on a given Windows CE-based appliance before bringing it to market, thus enabling them to support every version of a device (Palm-size or Handheld PC) quickly and easily.

In 2000 I interviewed Bob Powell, then at Stingray, who told me this in relation to .NET:

There was an early version of the system for Windows CE called the Common Executable Format (CEF). The Pocket PC, which uses around seven different processor types, and which has many different versions of the operating system, is a deployment nightmare. This problem was addressed by the CEF, which was a test case. What is now in the IL is a more refined version of that.

Hmm, now that Windows is coming to ARM alongside x86, this sounds like it could be useful technology … though despite obvious similarities, I don’t think CEF was really an early version of the CLR. Maybe the teams communicated to some extent.

Now this is interesting and brings the story up to date. Lucco is still at Microsoft and apparently his team built Chakra, the new JavaScript engine introduced in Internet Explorer 9:

image

Steven E. Lucco is currently the chief architect for the Microsoft Browser Programmability and Tools (BPT) team. BPT builds the Internet Explorer’s Chakra Javascript script engine, as well as the Visual Studio tools for creating scalable, efficient Web client applications.

Right now, these are dark days for .NET, because Microsoft now seems to be positioning HTML and JavaScript as the new universal runtime.

It seems that the man who perhaps began the .NET Runtime is also at the centre of the technology that might overtake it.

Update: this post has prompted some discussion and the consensus so far is that the OmniVM acquisition probably had little to do with the technology that ended up as .NET. The one thing that is beyond doubt is that the COM team created the .NET CLR as Zander reported. I actually spoke to Zander at TechEd recently and we touched on his early days at Microsoft working with Scott Guthrie:

I was actually one of the original CLR developers. When Scott and I first started working together, he invented ASP.NET and my team invented the CLR.

The history is interesting and if the relevant people at Microsoft are willing to talk about it in more detail it is something I would love to write up – so if that is you, please get in touch!

.net, apple, google, internet, javascript, microsoft, mobile, professional, silverlight, software development, visual studio, Web, windows

Considering Windows 8 as an HTML platform

4 Comments

Amongst all the fuss about whether Microsoft is deprecating Silverlight or even client-side .NET, it is easy to lose sight of the other angle on this. What are the implications of Microsoft embracing HTML and JavaScript as a new first-class Windows development platform? Here’s the quote again:

Today, we also talked a bit about how developers will build apps for the new system. Windows 8 apps use the power of HTML5, tapping into the native capabilities of Windows using standard JavaScript and HTML to deliver new kinds of experiences. These new Windows 8 apps are full-screen and touch-optimized, and they easily integrate with the capabilities of the new Windows user interface.

When Microsoft introduced IE9 with hardware-accelerated graphics, support for some key parts of HTML 5, and a new fast JavaScript engine, it was not only trying to recover ground in the browser wars. It also had in mind a new application runtime for Windows, for desktop as well as for web applications.

In order to achieve this, we can expect more hooks between the browser engine and the local operating system. There is potential security risk, but Microsoft of all companies will be sensitive to this and I would expect it to get the security right. The further implication is that some parts of a Windows HTML application will be Windows-specific. It is an “Embrace and extend” strategy, as I noted in this Register article back in September last year when former Silverlight product manager Scott Barnes broke the story of how the Windows team at Microsoft was favouring HTML and JavaScript above .NET.

The rationale for this is two-fold. First, I’m guessing that Microsoft thinks it will work better. Although .NET client apps are now commonplace, especially for custom business applications, problems like slow start-up and heavy memory requirements never really went away, though I would argue that in Silverlight they are almost eliminated.

Second, HTML and JavaScript is a universal programming platform. With the new model, any developer who can code a web page can also code a Windows app. Corporate VP Michael Angiulo said at Computex in Taipei:

Windows 8’s new application platform … is based on HTML 5, JavaScript and CSS, the most widely understood programming languages of all time. These languages form the backbone of the web, so that on day 1 when Windows 8 ships hundreds of millions of developers will already know how to build great apps for Windows 8.

These are both compelling arguments. Nevertheless, there are several reasons why making Windows an HTML platform might not be the instant hit that Microsoft will be hoping for. Here are a few:

  • Microsoft’s Visual Studio is .NET oriented. It does have a web design tool, Expression Web, which is OK but still falls short compared to Adobe Dreamweaver. Web designers tend to use Dreamweaver anyway, thanks to Mac compatibility and integration with other Adobe tools. Even Dreamweaver is not great as an application development tool, as opposed to a web design tool. Tooling is a problem, and it is fair to say that whatever goodies Microsoft comes up with in this area will likely be a step back compared to what it already has for C# or C++.
  • Standards are a mixed blessing if you are trying to sell an operating system. If Microsoft does such a good job of standards support that the same apps run with minor tweaks on an iPad and on Android, users may do just that. If Microsoft encumbers the standards with too many proprietary extensions, the universality of the platform is lost.
  • Windows plus HTML and JavaScript sounds a lot like Palm/HP WebOS, which has gained favourable reviews but has yet to take off in terms of sales. Otherwise, Palm would not have been taken over by HP.
  • The question of whether HTML and JavaScript will really take over app development is open. I certainly hear voices saying so. I interviewed Nitobi’s president André Charland, in charge of PhoneGap, and he makes a good case. On the other hand, App development today is still dominated by platform-specific development, Objective C for Apple iOS and Java on Dalvik, the Google Android virtual machine.
  • The standard in HTML/JavaScript app platforms is not Microsoft’s Internet Explorer, but WebKit, as used in iOS and in Google Android and Chrome. Microsoft did great work in standards support in IE9, but so far it has not stopped its browser share decline. Worldwide figures from StatCounter show Internet Explorer in continuing slow decline overall, and Chrome still growing and set to overtake Firefox in a year or so.

In other words, there is little evidence that embracing HTML and JavaScript as an app platform will ensure success for Windows 8.

That said, other factors count for more. Developers will go where their customers are, and if Microsoft turns out a version of Windows that wins substantial market share in the emerging tablet market as well as on traditional notebooks, the new platform will be a hit.

The risk though is that the market will continue to perceive Windows as an OS for desktop and laptop, and look to iOS or Android for mobile and touch devices. The dual personality of Windows 8 may count against it, if it means devices that are compromised by having to support both user interface models.

adobe, development, javascript, professional, software development, web authoring

Dreamweaver CS5.5 PhoneGap apps: performance issues on Android

1 Comment

This is a follow-on from my earlier post about building a simple PhoneGap app using Adobe Dreamweaver CS5.5. I built it on Windows targeting Android. I liked the development experience up to the point of trying the app: it looks great, but performance is terrible. That is, you tap a button and there is a perceptible pause before the app responds. It is worse in the emulator than on my HTC Desire, but still poor.

I had thought it was a configuration setting – though Dreamweaver makes it rather hard to access the build settings – but I am now wondering if jQuery mobile plus PhoneGap is just too demanding for most Android devices out there right now. Admittedly my Desire is a year or so old now. See this thread for example:

JQuery Mobile on Android is definitely slow. (Tested A2 and A3Pre on Samsung Galaxy S, HTC Desire, ZTE Blade (edit: 2.2 Froyo) – with PhoneGap, stock browser, Opera Mobile)

Something has to be done. The experience is low quality.

It is worth noting that PhoneGap is not yet a version 1.0 release – I was told it may be done by July. Further, you do not have to use jQuery Mobile with it in Dreamweaver; it just happens to provide a great set of user interface widgets. It may be better on Apple iOS; I have not tried that yet.

Nevertheless, this looks like a significant issue if you planning to dive in and deliver Android apps using the tools in the new Dreamweaver.

adobe, mobile, professional, software development, visual studio, Web, web authoring

Native apps better than web apps? That’s silly talk says PhoneGap president

1 Comment

When I attended Mobile World Congress in February one of my goals was to explore the merits of the various different approaches to writing cross-platform mobile apps. One of the key ones is PhoneGap, and I got in touch with Nitobi’s president and co-founder André Charland. As it turned out he was not at that particular event, but he kept in touch and I spoke to him last week.

PhoneGap works by using the installed HTML and JavaScript engine on the device as a runtime for apps. That is not as limiting as it may sound, since today’s devices have high performance JavaScript engines, and PhoneGap apps can be extended with native plug-ins if necessary. But aren’t there inconsistencies between all these different browser engines?

Sure, it’s kinda like doing web development today. Just a lot better because it’s just different flavours of WebKit, not WebKit, Gecko, whatever is in IE, and all sorts of other differentiation. So that’s definitely how it is, but that is being overcome rather quickly I’d say with modern mobile JavaScript libraries. There’s JQuery Mobile, there’s Sencha Touch, there’s DoJo Mobile just released, SproutCore, which is backed by Strobe, which is kinda the core of Apple’s MobileMe.

There’s tons of these things, Zepto.js which is from the scriptaculous guy, Jo which is a framework out of a Palm engineer, the list of JavaScript frameworks coming out is getting longer and longer and they’re getting refined and used quite a bit, and those really deal with these platform nuances.

At the same time, phone manufacturers, or iOS, Android, WebOS, and now RIM, they’re competing to have the best WebKit. That means you’re getting more HTML5 features implemented quicker, you’re getting better JavaScript performance, and PhoneGap developers get to take advantage of that.

says Charland. He goes further when I put to him the argument made by native code advocates – Apple CEO Steve Jobs among them – that PhoneGap apps can never achieve the level of integration, the level of performance that they get with native code. Will the gap narrow?

I think it will go away, and people will look back on what they’re saying today and think, that was a silly thing to say.

Today there are definitely performance benefits you can get with native code, and our answer to that is simply that PhoneGap is a bundle made of core libraries, so at any point in your application that you don’t want to use HTML and JavaScript you can write a native plugin, it’s a very flexible, extensible architecture … So you can do it. We don’t necessarily say that’s the best way to go. Really if you’re into good software development practices the web stack will get you 90%, 95% of the way there, so that apps are indistinguishable from native apps.

Some of the native features we see in iOS apps, they’re reminiscent of Flash home pages of ten years ago, sure you can’t do it in HTML and JavaScript but it doesn’t add any value to the end user, and it detracts from the actual purpose of the application.

The other thing is, a lot of these HTML and JavaScript things, are one step away from being as good in a web stack as they are in native. When hardware acceleration gets into WebKit and the browser, then performance is really just as good.

Charland is also enthusiastic about Adobe’s recent announcement, that PhoneGap is integrated into Dreamweaver 5.5:

Two things are exciting from our perspective. It gives us massive reach. Dreamweaver is a widely used product that ties in very nicely to the other parts of the creative suite toolchain, so you can get from a high-level graphic concept to code a lot quicker. Having PhoneGap and JQuery Mobile in there together is nice, JQuery Mobile is definitely one of the more popular frameworks that we see our community latching on to.

The other thing is that Dreamweaver targets a broader level of developer, it’s maybe not super hard core, either Vi or super-enterprise, Eclipse guys, you know, it’s people who are more focused on the UI side of things. Now it gives them access to quickly use PhoneGap and package their applications, test them, prove their concepts, send them out to the marketplace.

He says Adobe should embrace HTML and Flash equally.

I also asked about Windows Phone support, and given that Microsoft shows no sign of implementing WebKit, I was surprised to get a strongly positive response:

We have something like 80% of the APIs in PhoneGap running on Windows Phone already. That’s open and in the public repo. We are just waiting basically for the IE9 functionality to hit the phone. The sooner they get that out in public, the sooner we can support Windows Phone 7. We have customers knocking at our door begging for it, we’ve actually signed contracts to implement it, with some very large customers. Just can’t there soon enough, really. I think it’s an oversight on their part to not get IE9 onto the phone quicker.

PhoneGap is at version 0.94 at the moment; Charland says 0.95 will be out “in a few weeks” and he is hoping to get 1.0 completed by O’Reilly OSCON in July.

I’ve posted nearly the complete transcript of my interview, so if you are interested in Charland’s comments on building a business on open source, and how PhoneGap compares to Appcelerator’s Titanium, and what to do about different implementations of local SQL on devices, be sure to read the longer piece.

cloud computing, development, microsoft, professional, software development, visual studio

How Microsoft’s Office Web Apps were written in C# and compiled to JavaScript, maybe

3 Comments

While researching another product I came across this 2009 tweet from Microsoft’s Nikhil Kothari:

Office 2010 web apps – perhaps one of the most ambitious script# projects!

Script# is loosely equivalent to the Google Web Toolkit, but whereas GWT compiles Java to JavaScript, Script# compiles C# to JavaScript. According to the site:

Script# is used extensively by developers within Microsoft building Ajax experiences in Windows Live, Office to name just a couple, as well as by a external developers and companies including Facebook.

I had come across the project before, but was waiting to see if would evolve beyond what looks like a personal project for Kothari. It is hosted on http://projects.nikhilk.net rather than on an official Microsoft domain, and the latest release is 0.6.2. In other words, it does not have the look of a project that you would recommend for production work, interesting though it is. Nor is there much public activity around Script# that I can see, though there is a CodePlex site dedicated to improving its JQuery support.

Seeing Kothari’s tweet though raises several questions.

  • Did Microsoft really use it for Office Web Apps, a high profile project which is a key part of Microsoft’s cloud computing strategy?
  • Is there another, more up-to-date version of Script# that is used internally and which may one day burst into the public arena?
  • How might it impact the Silverlight vs HTML5 debate, if Microsoft comes up with a C# to JavaScript compiler in Visual Studio that lets developers code in .NET but deploy to cross-platform JavaScript?

I am sure there are readers of this blog who know more than I do, so by all means let me know.

apple, google, javascript, mobile, professional, software development

Appcelerator acquires Aptana

Appcelerator, a company whose main product is a cross-platform desktop and mobile toolkit called Titanium, has acquired Aptana, whose Aptana Studio 2 is probably the best IDE for JavaScript application development, and which also supports Ruby on Rails, PHP, Python, and Adobe AIR.

It makes sense, in that Titanium uses JavaScript as the primary language for the application logic and UI.

image

Appcelerator is already doing well from the current surge of interest in mobile apps, offering an obvious solution to developers endeavouring to support both Apple iOS and Google Android with a single code base. Aptana looks a good acquisition; but the news may not be so welcome to those who rely on Aptana Studio for Adobe AIR; I imagine Appcelerator may see this as a competing platform. Then again, most AIR developers use the Flash IDE or Flash Builder so it is unlikely to have a huge impact even if AIR support is dropped (I do not know what the plans are in this respect).

The server-side technologies like PHP and Ruby are a better fit, since many mobile apps have a server component.

Update: in the webcast about the acquisition, Appcelerator CEO Jeff Haynie said “There’s quite a few questions around Aptana as it relates to Adobe and ColdFusion; I don’t think we can say anything about that.”

The company is expecting to release a joint Aptana Studio/Appcelerator Titanium beta in March 2011. The initial release will not include a visual designer, though this is planned for some future release.

javascript, professional, software development

Don’t miss Ryan Dahl on Node.js

I’m just back from Dreamforce in San Francisco, where one of the sessions I enjoyed most was from Ryan Dahl in the Cloudstock pre-conference event.

He is the author of node.js, a binding for the V8 Javascript engine, not for running in the browser but for creating server apps. However, it is interesting even if you don’t want to use V8, because of the approach he takes to concurrency and I/O. I wrote up the session here, under the title Nginx the new Apache, node.js the new PHP?

What was Dahl doing at a Dreamforce conference? That was a question that puzzled me, until later in the week when it was announced that Salesforce.com is acquiring Heroku. Heroku has been experimenting with running node.js on its hosted infrastructure for Ruby applications, and may come up with a Ruby wrapper.

adobe, flash

Render SWF in JavaScript – a solution for Flash on iPhone/iPad?

1 Comment

Looking at the blazing-fast JavaScript in IE9 Preview 4 made me wonder if anyone had tried to write a SWF renderer in JavaScript. SWF is the Adobe Flash file format and a published specification.

Of course someone has. Tobias Schneider has been working on Gordon and built his first full release in June.

image

Gordon is a little behind in terms of version support:

In this build, Gordon can read and parse all valid SWF’s, even if they are compressed with ZLIB, but plays only SWF1 files completely, as well as the most of the SWF2 features.

The Adobe SWF specification is now up to version 10.

It is still an interesting exercise. Consider Google Web Toolkit, which compiles Java to JavaScript. What if Adobe did something similar for Flash? In fact, if you look at the Smart Paste “sneak peak” from Adobe Max 09 something like this was demonstrated.

The Flash player includes some proprietary codecs that could not easily be replicated in JavaScript. Still, given such limitations, “Export to HTML 5” would be a nice option to find on some future version of Flash Professional, and would help Adobe’s tools business even if it also dented its ambitions for Flash as the universal runtime.

blogging, internet, javascript, web authoring

Speeding page load with dynamic JavaScript

5 Comments

I’m delighted that ITWriting.com is sufficiently popular to sustain some advertising. I’m not pleased though with the impact on performance. The problem is that ads such as those from Google Adsense or Blogads are delivered by remote scripts. It usually looks something like this in the HTML:

<script type="text/javascript"
  src="http://some/remote/script.js">
</script>

When the browser encounters this script, it stops and waits until the script returns. This means that your site’s performance depends on the performance of the site serving the script. At times I’ve noticed significant slowdown – though to be fair, Google is normally faster than most others in my experience.

So how can this be fixed? I’ve spent some time on the problem, but with limited success. Ideally I’d like an Ajax-y solution where the ads flow in after the rest of the page had loaded and rendered, because the content is more important than the ads. The first step though is to place the scripts at the end of the page, so that the rest of the content is downloaded first. However, the ads have to appear towards the top of the page, otherwise the advertisers will not be happy. I tried inserting the script dynamically like so:

var addiv = document.getElementById("addiv"); //where the ad is  to appear
var theScript = document.createElement("script");
theScript.type="text/javascript";
theScript.src = "http://some/remote/script.js"; 
addiv.appendChild(theScript);

While this works after a fashion, it does not do the job. The problem is that the script typically calls document.write. If you are lucky, the ad will appear at the bottom of the page. If you are unlucky, the ad will replace the entire page.

What I needed to do is to capture the output sent to document.write and then insert the HTML dynamically. It turns out that JavaScript makes this easy. We can simply override document.write with our own function. Like so:

var addiv = document.getElementById("addiv"); //where the ad is  to appear
var adHtml = ”;
var oldWrite = document.write;
document.write = function(str)
{
    adHtml += str;
}
<script type="text/javascript"
  src="http://some/remote/script.js">
</script>
document.write = oldWrite;
addiv.innerHTML = adHtml;

This is brilliant, and in fact works perfectly for some of my ad scripts. Unfortunately it does not work for the slowest performer. The problem is that I have no control over the content of the remote script. In the non-working case, the remote script does not return HTML. It returns another script, which references another remote script. Now I have to figure out how to handle all the possible cases where scripts return scripts, which might or might not call document.write.

I’d be interested if anyone has a generic solution. There is a library here that looks like it might be helpful.

Another reflection is that it is in the interests both of advertisers and publishers to have scripts that execute fast and/or behave in a predictable manner that is friendly towards deferred loading techniques. It is no use writing convoluted code to deal with a particular script, when it might change at any time and break the site.