Developers, developers, developers

Anyone should remember the stellar actuation of Steve Ballmer reciting these words.
Developers were important for microsoft. Having developers tied to their platform meant software being written for it.
Well, now Microsoft is losing developers, while Apple is always winning more of them (I won't talk about GNU/Linux which is king supreme on the server side, but not yet on desktop).
Why is that? Well, many thing must be taken into account. The iDevices for example. There are many developers writing iPhhone, iPod touch and iPad applications. You only can do that from a mac, and once you have learned that (as officially most software must be written in objective-c using xcode) you are ready to easily write mac applications too.
Switching to intel architecture was a very very clever thing for Apple to do, because people have the possibility to run Windows on their macs too, either native via BootCamp or on a virtual machine. Many people were afraid of switching to a mac because they were relying on some windows software, which now they can use without problems.
But, the best... any developer who now uses a mac has their development environment ready, and free of cost. And when start to use it and step the learning curve of a new language, because objective-c isn't used much outside of the mac world, they start to appreciate the beauties of Cocoa, the heir of Next.
Let's be clear, Microsoft has done some wonderful things too, but when you have to deal with the absurd complexities of a system which was, in theory, designed to hide them... you find that something isn't working as it should.
If microsoft is losing developers which are going to other platforms, there's noone to blame more than the own Microsoft. They are doing things difficult for their own developers, while others have been trying sine years to make averything easier, more clear and more confortable for them.
Microsoft, you are slowly but steadily loosing points there. If you want to rise again, you know what you need: Developers, developers, developers...

Tips: Adjusting your webApp to iPhone screen size.

On mobile webApps, we should care a lot about screen space, because it's very limited.
My test app consisted on a fixed positioned header, an optional fixed positioned footer, and a scrollable content. I wanted it to fill the whole screen space, of course, both in portrait and landscape mode.
As anyone knows, it's possible to hide the navigation bar on iPhones's safari, and that gives us 60 extra pixels. That's a lot. But there's one thing... the navigation bar can only be hidden (it's really scrolled up) when the content is larger than the available screen space.
I thought... on orientationchange event I must only read window.innerHeight to get the total window height, adjust my div sizes, and hide the navigation bar. Fail
window.innerHeight reported the available window height considering the navigation bar was there...
Easy then, first I hide the navigation bar, and then read window.innerHeight. Results?
When switching from portrait to landscape mode everything was right. But when switching from landscape to portrait it wasn't.
Of course, when switching, the content height was the total height in landscape mode, 300px (the always present top status bar is 20 pixels height), and of course it wasn't enough to scroll the navigation bar up. What to do?
Easy. First, set the content height to screen.height (which is always 480 in the iphone) so it is high enough. Then, hide the address bar, and once hidden, set the right height depending on the window.innerHeight (which will be 460 in portrait mode when the navigation bar is hidden, the whole screen.size minus the 20 pixels of the status bar which is always visible).

Don't fear reinventing the wheel.

It's considered one of the most popular mistakes between programmers. Reinvent the wheel. Again and again programmers are constantly reinventing things. It's a big waste of time, and usually the resulting code is of a much lower quality than "wheels" which have existed for a long time, which had most of their bugs solved, which have been used and abused for all kinds of things...
But there are exceptions. Some times, reinventing the wheel is useful. Sometimes we don't need an overengineered wheel. We don't need the fast wheel for a formel-1 car, we don't need the strong wheel of a  big transport device, we need a simple, small wheel which just can carry our luggage. In that case, simplicity over all, our own wheel, although technically worse in many aspects, can be good for our project.
And of course, there is a time where reinventing the wheel has a clear advantage: learning. There is no better way to ler how a wheel works than reinventing it (even though after doing that we can see that existing wheels are better than our, but then we can use them with knowledge of doing the right thing).

More experiences on mobile(r) webApp development

Any mobile webApp should be simple, and if it is mobiler, it should be simpler.
I really like iScroll, it provides native app like scrolling, it's really easy to use, and customizable enough, so after (well, while) using it for the iPad framework, I've decided to go mobiler. What's mobiler than the iPad? iPhone (and iPod), of course. Using it on a real device is always much better than on the simulator (as I don't have a real iPad).
I like it so much that I'll probably start writing my own real iDevices framework (with the experience obtained with the iPad one). If everything is well deigned, minimal code changes will be needed to support the diferent optimal layouts for iPad and iPhone (which includes iPod and android devices too).
If added to the home screen (on iPhone at least, don't know about iPad or android) and given the good performance of iScroll (which is no so good on android due to the lack of hardware acceleration) any webApp designed to take advantage of offline operation and local databases can be made indistinguishable from a native application.

Experiences on mobile webApp development

So, I've started with the development of a webApp for the iPad. Well, it's more like a framework fora split-view like webApp.
Of course, I'm using the great iScroll library. It's very easy to use, and although it has a big ammount of complexity inside, successfully succeeds in removing it from the developer by providing a very easy interface.
Of course, every abstraction leaks, and iScroll is no exception, but if you stick to what it's designed for, it's great!. For anything else, if it doesn't work right, consider it a leak and attach the problem from a different angle. You can either read the sources from iScroll (it's clean and easy to read and understand) to see where your problem comes from, and either fix your concrete case or think of some useful modification for everyone (which doesn't add complexity, of course) and submit it, or you can attack your problem in a different way (that's what I did, making it do something a bit different from what I had in mind at the beginning).
This framework I'm doing leaks like mad too, but if you restrict yourselve to the "documented" behaviours, everything should be ok (it's done so that eveyrone can write an iPad split-view like informational app completely in html. All javascript code will be self-contained, inside its limits, of course).

What about mobile webApp development?

Well, of course we must talk about Apple here. The iPhone revolucionized the mobile phone world, and was the firstsmartphone with a real browser which everyone could use. The iPad was the first succesfull tablet device, and their additions to safari, even when they could be considered the "browser wars" of the XXI century, are really useful and powerful for web developers.
When the first iPhone came, there was no SDK for it. WebApps would be the iPhone apps, but at that moment it was not enough. Even forgetting the limitations of the original iPhone, there were many thing that couln't be done in a web browser... or could they?
When the SDK came, everyone started developing for it and forgot the webApps, but safari has continued improving. Now, webApps can be stored and used offline, with the hardware acceleration for the CSS transforms you can attach fast and interesting visual effects. WebApps can store data locally, access the GPS device, the accelerometers, etc. WebApp developing for mobile devices is getting more interesting every day, again.

And... which other big benefit does it have? in my opinion, two big ones:

• Availability. Everyone can use your webApp now, you don't have to submit it to an AppStore, it doesn't have to be approved, people don't have to download and install it. When they find it, it's already there, ready to use. This includes automatic updates too :-)
• Availability. Yes, it's the same as the first one. Your app will be availabe for everyone, independent of the device they have. They have an iPhone? the app will be there. They have an iPad? the app will be there. They have an Android phone? the app will be there. They don't have any smartphone or tablet but have a computer with a web browser? you already know the answer.

Of course, always keep in mind your possibilities and limitations. an FPS shooter would be too slow (today) as a webApp, but many other things implemented as a webApp can be just like native apps, or even better (you can access always the same data from every device or computer you like).

Which javascript framework should I use?

The answer, of course, is: It depends.
It depends on many many things. From the complexity of your application to the deployment platform. Will it be an iPhone or iPad only webapp? will it have to support IE6? Which other constraints do you have?
If your app is simple enough, the best framework will probably be... none. Using standard javascript, standard DOM methods, etc, will be probably faster and smaller. Even if you must take into account all possible weirdness (different event model in IE and the rest of the world for example). If you are constrained to a sane subset (no IE < IE9, only safari because it's for iPad, etc) then it becomes even easier to program without any framework or library.
For a medium size app which needs to run on a variety of different browsers, a framework which supports all needed browsers will help a lot, as we won't have to reinvent the wheel for solving many browser inconsistencies. In this case the developer should be consistent on using always the framework methods when existing, and not mixing them with native javascript or DOM methods, as that could led us to difficult to find, subtle bugs.
For a big thing, the use of a framework can always help, as many needed things will be already implemented and tested, and it will provide a lot of higher level functionality missing on the javascript core language.

About which one to use... I would say it depends on what you have to do as well as your personal taste. All frameworks have their own pros and cons, and some of them are better adapted to some kind of work than others.
Personally, I really like the Google Closure Library as it's the one which more closely resembles my style of work, and what I would like a good javascript framework to provide. For different styles of working, different frameworks can be better, of course.
If you want to try the closure library (which works better in its own environment, specially regarding the Closure Compiler), I really recomend reading closure the definitive guide from Michael Bolin. It really gives a ton of good information about the Closure Tools.