Start.com vs Google Homepage
Monday, March 13, 2006
I have recently experimented with writing an "web 2.0" desktop gadgets, both for Google and live.com (Microsoft).
I've been developing software since the age of 9. Long stretches of that time I worked exclusively with MS based technologies. Today - I use non of MS technologies for development / deployment. The reason is not a "releigous" one. I am not, by any means a "anti-Microsoft" kind of guy. Not at all. Its just that somewhere along the line, Miscrosoft technologies have grown too complex to master and use, to cumbersome, while refreshing new alternative came along.
Writing components / gadgets for a web-based homepage is no different. While writing a Newzingo google homepage module was a breeze, I am still struggling developing one for Live.com. Reasons?
1. MS code base is complex.
2. There is no support for XMLHTTPRequest proxying of data, thus a component can not use the XMLHTTPReqeust object to call on a different domain using the Microsoft "Framework" (Google supplies a neat JS call to do just that)
3. oh my oh my. In order to debug your component, you need to.... You guessed it! close your browser and restart it every time you change the JS code. Back to the "Restart windows" days.
What's really sad about his whole experience, from engineering point of view, that there is no real reason why the Live.com component development should be such hell. (XML hell replaces DLL hell?). The answer, I guess, is that Microsoft's engineers are just not professional / good / smart enough.
technorati tags: live.com, start.com, google homepage, comparison, api
I have recently experimented with writing an "web 2.0" desktop gadgets, both for Google and live.com (Microsoft).
I've been developing software since the age of 9. Long stretches of that time I worked exclusively with MS based technologies. Today - I use non of MS technologies for development / deployment. The reason is not a "releigous" one. I am not, by any means a "anti-Microsoft" kind of guy. Not at all. Its just that somewhere along the line, Miscrosoft technologies have grown too complex to master and use, to cumbersome, while refreshing new alternative came along.
Writing components / gadgets for a web-based homepage is no different. While writing a Newzingo google homepage module was a breeze, I am still struggling developing one for Live.com. Reasons?
1. MS code base is complex.
2. There is no support for XMLHTTPRequest proxying of data, thus a component can not use the XMLHTTPReqeust object to call on a different domain using the Microsoft "Framework" (Google supplies a neat JS call to do just that)
3. oh my oh my. In order to debug your component, you need to.... You guessed it! close your browser and restart it every time you change the JS code. Back to the "Restart windows" days.
What's really sad about his whole experience, from engineering point of view, that there is no real reason why the Live.com component development should be such hell. (XML hell replaces DLL hell?). The answer, I guess, is that Microsoft's engineers are just not professional / good / smart enough.
technorati tags: live.com, start.com, google homepage, comparison, api
Hi;
Another ajax-based, web 2.0 search engine, very new, in its BETA now, AskAlexia.com, simple UI+ajax+speed ?. Now only available with web, image searches. More searches such as video, music, news, shopping will be added in soon :)
Posted by KetYung | 5:11 PM
Regarding point #2: Live.com provides Web.Network.createRequest() to proxy XmlHttpRequest data in order to prevent cross-domain scripting problems. Check out this post on MicrosoftGadgets.com, which includes a quick overview of how to use it.
Posted by Anonymous | 6:26 PM