The Webmechs Press

I wrote a blog article a few months back, Microsoft’s 3-front war, Part 1 where I was going to explain each of the 3 fronts Microsoft is competing on in a separate blog article and conclude with the recommendation in this article.  But I’m going to skip all these and just jump straight more or less to the conclusion.

The first front is the desktop OS where Windows competes with Linux and OS X.

The second front if I recall correctly is the mobile devices / mobile OS front where Microsoft competes with iPhone OS X, Symbian, Android, etc… (and not doing a very good job of it by the way)

The third front which was I was going to lead into is the runtime front where .NET/Silverlight competes with the Flash/Flex platform and Java.  This, I believe is the most important and exciting front and the unnamed third competitor is, of course, Adobe.  And in fact, since then a fourth platform is slowly emerging as credible challenger going forward - JIT-compiled Javascript plus HTML 5’s Canvas and Canvas3D (WebGL).

( In this blog post, the author clearly spells out a future where browser-centric standards - and NOT RIA plugins - serve as both the delivery and execution platform for just about all applications. )

This is where I believe Microsoft should be setting their strategic sights on.   While .NET is an awesome environment, by going the RIA route with Silverlight, Microsoft has shown it still hasn’t gotten the Web yet.  It has to do a far far better job of embracing web standards if it wants to dominate the future rather than Google.

( In this other blog post, the author explains why RIAs, among other things, destroy some of what is good about the web - in particular, the REST principle. )

The browser platform, with JITing VMs for Javascript and the incorporation of Canvas/Canvas3D/WebGL will give us most of what RIAs have to offer (performance + rich graphics) but preserve the URL-based REST nature of the Web.  The only problem with this is that we are still limited to just one language - Javascript - for creating such applications. Flash, which is Actionscript (the statically typed Javascript which resembles Java more than browser Javascript ) only, has the same limitation.

With IE becoming more irrelevant and Google pumping up Chrome aggressively, we are going to see people increasingly have the option to use the above as a runtime platform instead of RIA-oriented  technologies like Flash or Silverlight.  However, Microsoft currently has the very important Ace up its sleeve which is the fact that neither Google nor Adobe have a CLR that can run multiple languages.

The solution seems clear.  Side-by-side with Silverlight, Microsoft should start offering a browser - (probably) not IE - with the CoreCLR as its JITting VM engine plus proper Canvas/Canvas 3D/HTML5/CSS support (heck, just dump Trident and use WebKit).  The browser DOM would then be programmable using any CLR language and in fact integration with Silverlight could potentially be even more seamless.  Most of the infrastructure for this is actually already in place since the browser DOM seems already fully (?) exposed  in the System.Windows.Browser API.  All that would be needed would be to ensure that the CoreCLR-based Javascript running in this browser emulates traditional Javascript perfectly (down to the DOM API) - and since it’s a new non-IE browser, you can also throw away all the old IE4 era DHTML stuff and ActiveX support (also increasingly irrelevant except the IE development team probably still doesn’t want to acknowledge this yet) and just concentrate on supporting true web standards.  The point here is that while Silverlight / XAML in particular enables some truly awesome capabilities that HTML tags, even with Canvas, are going to take a long time to match, the RIA model breaks REST and this is a huge liability in the eyes of many people.

If Microsoft wisely chooses such a move, it could potentially do an IE4 all over again.  IE4-6 dominated by partly embracing some web standards and extending it with its own rich DHTML object model (now dead in favor of W3C DOM).  This new CLR-based browser can embrace Javascript, JITing VMs and then extend it by allowing people to directly script DOM with IronPython, Boo, VB.NET etc…  <SCRIPT> tags already support specifying the language and presumably, you would want to extend it with attributes that specify loading of CLR assemblies, for example.

Because the CLR is an open standard, such enhancements to the <SCRIPT> tag to support assembly loading wouldn’t (shouldn’t) be considered proprietary and such extensions would (should) be embraced by the standards bodies.

If ever I find myself wishing for Embrace and Extend, THIS is it.

After studiously (yes - studiously - considering how often you get bugged by the OS) avoiding upgrading my IE6 installation to anything newer, I finally heeded the update call and upgraded to IE8.  I think Microsoft has finally done something right with IE8 because it supports web standards much better in its default state. (UPDATE: IE8 is the worst P.o.S. *ever*.  I have found that it hangs within 2-3 minutes of loading a couple of tabs over 90% of the time). UPDATE 2: I found the culprit. The Flashget add-on is what was causing the crash.The other side of this coin, however, is that many, many websites which explicitly detect for IE and emit code (whether HTML or CSS or Javascript) specifically for dealing IE bugs and idiosyncrasies are now going to break, sometimes very badly.  Thus, IE8 has a “Compatibility View” button that reverts IE8 to behaving like earlier, less standards-compliant versions of IE, complete with all the quirks.

I’ve already noticed one particularly important instance where IE8’s Compatibility View is essential:  the Plesk 8.x management console.  If you do not turn on IE8’s Compatibility View, Plesk won’t work.

If there is a moral lesson to learn here, it was to avoid browser specific code at [nearly] all costs.  In other words, make it a point to NEVER detect for different browsers and put the onus on the browser creators to render standards compliant pages correctly.

In practice, avoiding browser detection is not possible 100% of the time, but because we make it a point to reduce the amount of browser specific code as much as possible, we are able to avoid having to detect for the browser in 99.99% of cases.  One best practice we adopt is to just rely on CSS quirks to get a page to render the way we want on IE.  In this case, the page would (theoretically) work on IE8 correctly because IE8 would, like any other standards compliant browser, ignore the IE5/IE6/IE7 specific quirks.  Even for complex javascript-driven pages, we have been able to reduce browser specific DOM code to only a line or two in the past (with the advent of AJAX libraries like jQuery, this should no longer be something to worry about).  It is actually very tough work to figure out how to do this reduction, but it was worth it because the resulting code is much easier to maintain.

Those developers who thought they were doing the right thing by detecting for IE and having their websites behave, serve content and run JS code differently are now faced with the prospect of seeing their pages break on IE8.  Tsk, tsk, tsk.

The good news is that going forward, you should not have to worry about browser specific coding anymore (or at least worry much much less) which should have always been the case from the beginning anyway.

When using Globe 3G to view websites, I was disturbed to find that so many web pages had very low image quality.  Upon closer inspection, I was alarmed to see that the images were being loaded in from a numeric IP address (usually 62.0.5.135 62.0.5.133 or 62.0.5.134 ) rather than the website itself, and I thought that my computer had been infiltrated by spyware or or a trojan!! After further investigation, I realized that this was actually the ISP’s handiwork >:-( .

Apparently, Globe 3G passes all images (e.g. jpg, png or gif) through a compressing proxy first before serving it back to the visitor.  This is apparently done to greatly minimize bandwidth consumption by visitors.

On the surface, one might be able to understand Globe’s justifications for such a scheme.  The lower quality of images will not be that noticeable when browsing via tiny mobile phone screens and secondly, I have to say that Globe 3G is fairly consistently speedy whenever I use it so their bandwidth miserliness has at least some redeeming factors.

On the other hand, you should be aware that if you use Globe 3G as your primary internet connection on a notebook or desktop (as opposed to just using it for quick browsing on a mobile device) then this kind of proxying is non-transparent and will result in breakage of many sites.  For instance, I have discovered that it breaks image handling via AJAX.  An example would be when trying to upload images for your ad in Classifieds PH, which will not work for those who visit the site via Globe 3G.

If it were true that internet access quality via Globe 3G would be greatly slowed down if they did not use this image compression scheme, then this is a somewhat reasonable tradeoff for those who use Globe 3G as a backup form of internet access.

On the other hand, if Globe really intended for people to adopt their 3G service en masse, then this method of conserving bandwidth is terribly flawed both from a technical and end-user point of view.  I think Globe is shooting themselves in the foot with this one.

URL at http://www.google.com/googlebooks/chrome/big_00.html

Since today’s browser environment is rapidly becoming the equivalent of an OS, the innovations in Chrome seem to be ideas whose time has come.  One of the central ideas behind Chrome’s architecture is to assign a different process (not thread) to each tab and the strip explains why.  The section on how they test the browser is also great propaganda that pretty much portrays Google as omnipotent in terms of technical resources. ;-)  Even though it is in comics format, the pages on Chrome’s V8 Javascript engine can get technical (and thus fun to read…).

One interesting revelation found in http://www.google.com/googlebooks/chrome/big_28.html is how existing plugins have to be allowed to get around the sandbox security restrictions built into Chrome, and how Chrome’s architecture still tries to minimize the ill effects of such a requirement. All in all the comic strip has sold me to the idea of adopting Chrome (one day, when it gets out of beta I suppose). We just have to remember to watch out for the privacy issues,  as Google has far greater potential to own us in this regard than Microsoft ever could. See http://www.srware.net/en/software_srware_iron_chrome_vs_iron.php

UPDATE: I tried Chrome out using the portable build from SRware and I have to say I’m impressed.  It really does seem to be crash-proof!  The acid test in my case is to view dozens and dozens of Youtube videos in a single session.  Firefox v3 in fact was more crash prone than v2 in this case, although v2 would also crash eventually.  Chrome was completely stable all the way up to the end of my session.

This blog article by Dare Obasanjo purports to give an insider’s view of how Microsoft might be a more desirable workplace environment than Google, in contrast to all the media portrayals about how working at Google is like being in a playground. In my own blog essay here, I would like to offer the view from the customer/pundit’s side about how Google compares to Microsoft in terms of their technology, marketing and business directions.

While I still overwhelmingly use open source technologies (primarily LAMP), changes in the way Microsoft presents its technologies mean that I no longer find myself averse to integrating with or adopting them in the near future. Gone is most of the closed, proprietary mindset which used to characterize Microsoft technologies and make them wholly unattractive to hardcore developers. Perhaps changes of such nature in the way MS is driving forward their technologies also reflects changes in their corporate culture, hence the reason behind Dare’s observations.

The biggest obstacle Microsoft faces however, is that it is saddled with so much ill will and baggage accumulated over the years, that many technically savvy people just take it for granted that they cannot come up with anything worthy - technologically speaking. The reality on the ground today is pretty different from that old stereotype. Technologies like IronPython and the DLR (both open sourced, by the way), now make .NET a very interesting and capable environment to operate in, certainly superior to Java [grudgingly open sourced very late in the game as an act of near desperation, by the way...] in many ways. Mono, despite heavy initial pessimism, actually saw the light of day and is now a useful, working, somewhat mature platform.

Other Microsoft technologies like Powershell (formerly codenamed Monad) just do not reap the mindshare they deserve. Powershell is MS’ answer to criticisms that the Windows command line is anemic compared to Unix shells, which _was_ most certainly true. Now however, the Windows command line arguably leapfrogs over current Unix shells’ functionality. Moreover, it manages to do so by adopting the most common Unix shell-isms (a sign that the Microsoft engineers involved in this effort are not afflicted with the NIH syndrome), preserving the familiarity of tried and tested conventions but supercharging them with a pipe-based paradigm that operates on .NET objects/properties instead of just plain text.  This sort of innovation is on such a fundamental level that Powershell can be rightfully called a revolutionary advance for the command line interface / paradigm.

I have tried out Powershell and I have to say, that contrary to what one would usually expect from Microsoft and despite my own heavy bias against the OO paradigm, it is _not_ lame. We have heard talk of “[pervasively] Object Oriented OSes” ever since the 90s, back when Taligent and similar initiatives (both coporate and hobbyist) were being touted as the future. Now that .NET is increasingly being overlaid on top of Windows and other Microsoft technologies and having a tool like Powershell give immediate command line access to (more or less) uniformly inspect and manipulate a whole array of .NET objects in the environment, we are effectively there today.

On the hardware front, MS again suffers from lackluster marketing, Microsoft’s multi-touch vision is far more comprehensive than Apple’s and yet it is Apple’s piddling iPhone that reaps disproportionate media coverage. Sigh…

Google’s Android, a Frankenstein-ish stack made up of a deliberately incomplete, incompatible Java implementation running on top of the Linux kernel is the media darling of the moment (scaring Symbian into open sourcing their C++-based mobile device OS, hehe), while MS seems to be doing precious little to let people know of how Mobile Windows can leverage off of the now thriving .NET ecosystem.

Even as MS fails to score points on the marketing side despite what I would consider are far more enlightened efforts today compared to those of yesteryears (karmic retribution, perhaps?), I would say that they have definitely learned real lessons from their open source competition. Many of today’s MS initiatives have genuinely picked up the good traits of the OSS philosophy and should convince those with a more pragmatic bent (e.g. those who do not possess ideological or sentimental attachments to labels and ‘movements’) - to at least reconsider their alienation to MS-originated stuff, if not consider moving to it.

All the flak and lost market share Microsoft has had to [deservedly] endure over the years seems to have changed the company. What is ironic is that while many people still have the narrow-minded view that “MS is evil”, they fail to see that Google, due to its enormous success, is in fact starting to become like MS during the latter’s heydays. We justifiably loathe MS’ former business practices and the parade of lame-ass technologies they used to introduce by the score, but Google isn’t immune to this:

When it comes to online advertising, Google, like any business with a competent, capable CEO at the helm is clearly aiming to achieve as dominant a market share as it can (aka a “monopoly”), which, to lefties, would certainly count as “evil” behaviour.

Another similarity too is that Google, having a cash cow in the form of Adsense, as MS did in the form of MS-DOS, uses it to fund as many throw-it-on-the-wall-and-see-what-sticks projects as it can, and a lot of those projects are insipid indeed. [ Google Base?!? My god, could anything be more uninspired? Fire the guy who "conceptualized" it already! Gmail is ok, but you'd think with all the initial hype, it'd have at least come close to giving Yahoo Mail a run for its money, but up to now I don't think Gmail has even a tenth of the market share Yahoo Mail does. ]

Finally, there are significant numbers of people who blindly adopt and/or defend their technologies simply because of the brand name. Whereas you had “MS zombies” before, you’ve now got uncritical, raving, Google fanboys who think the “Google” name is a rubber-stamp for cool technology. MS was obviously unable to topple Google the way it did Netscape, and now when it comes to the new frontiers of cyberspace such as online advertising, MS is clearly the underdog, while Google, the 500-pound gorilla. Still, I don’t see MS going down that easily. In the face of truly stubborn competition like was the case with Linux, Microsoft has proven quite willing to redefine itself in major ways to stay relevant (but not necessarily dominate).

Finally, we have a book that vindicates the desirability of a REST interface over AJAX and SOAP.

http://radar.oreilly.com/archives/2008/01/a_year_in_oreilly_books.html,

I remember back when SOAP, UDDI and all the rest of the corporate web services stack was introduced, many people in the open source community saw it as an attempt to recapture the web, making it complex enough to be an enterprise software play. But those complex stacks never caught on.

gives us a whiff of the commercial motives behind the introduction of technologies that override REST.

The quote in http://www.oreilly.com/catalog/9780596529260/index.html,

RESTful Web Services … provides a practical roadmap for constructing services that embrace the Web, instead of trying to route around it.

is a very telling indictment of the philosophy behind these non-REST technologies. They piggyback on top of HTTP but then seek to subvert the core ideas of the web! In a mailing list post from a couple years back, I expressed similar sentiments.

Back when SOAP and Web services were all the craze and Google introduced a SOAP-based API to their Search Engine some years ago, I frankly could not understand what was going on inside their supposedly brilliant heads. A REST-style URL-based interface would have been immensely simpler to learn and would not really have lost any functionality compared to the SOAP-based API. What happened? Google swallowed the “Web Services” Kool-Aid is what. (Some might even say the blame goes all the way back to Dave Winer and wonder why the rather dubious invention that is XML-RPC ever got all the attention it did)

It is quite interesting to discover that even for more demanding applications such as payment gateways, a REST-based approach is still feasible. A Philippines payment gateway, payeasy.ph, eschews a SOAP-based interface in favor of the much simpler GET and this is apparently enough to get things done. Having suffered the hell of interfacing with SOAP-based payment gateways, I couldn’t agree more with their decision and am left wondering why more people have not realized that they can do away with all the Rube Goldberg-style machinery imposed by SOAP (worried about job security perhaps? )