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.

claim verification

HRNSQ9S49DRY

Sleep is a symptom of caffeine deprivation

And every developer proud of being should know.
Anyway, everyone should know too that some quality of sleep is important too. It will make you feel better and your code will be better too. But it's hard to get. There are many parameters which prevent us of getting a good sleep, from personal preferences (late nights of coding), social events (late night parties), family (those with children at least don't have to worry much about late night parties), etc.
Well, seems that most problems can be solved with some training and self discipline. I've just found a free ebook called "40 sleep hacks. The geek's guide to optimizing sleep". I already knew/had read about most of them, but having them toghether in the form of a book is always good. It's free, and was made by SleepWarrior.com (which is currently in maintenance mode).
Oh, f.lux is an interesting utility (free as in beer, for Mac OS, GNU/Linux and Windows) which changes the color temperature of your monitor relative to the sun position (sun lighting is much different from artificial light, and your monitor color temperature regulates to the type of light used). Interesting idea.

So, you need a good and simple editor?

Sometimes those big IDEs are great, but sometimes they are... too much.
I've been a happy user of aptana for a long time, and I like it very much, but sometimes it gets being painfully slow (due to its huge memory usage).
A popular editor for those using Mac OS is Textmate. I've tried it and I really like it. It's fast and thanks to its plugins system (called Bundles), extremely customisable. You can usually find a bundle for what you want, reduce your more common things to do to a single keypress, etc.
On the Windows side, the E Text Editor claims to have "The power of Textmate on Windows" (it's compatible with Textmate bundles).
But... what if you use GNU/Linux? well, you happen to have a great editor already there (if you use Gnome at least), Gedit. It has plugins too! I have some installed, and have just discovered the Gedit Developer Plugins. Now I'll have to try them. What, word and python symbol completion? word completion like Textmate? symbol completion only for Python? well, I already have symbol completion on my gedit via another plugin... and it works for almost all languages (thanks to exuberant ctags). At least, works wonderfully for javascript, which is what I need. Anyway, good idea to have some developer plugins all together.

Perfection kills

Well, that's a goog name for a Javascript blag (which I have discovered btw searching on Google for the title of the post).
If you are writing a framework, a library, or just any kind of abstraction, don't pretend it to be perfect, it won't be (by law). The closests you can get to perfection will be by means of finding and documenting its imperfections. That means that whenever someone using your framework must do something which it doesn't support, they'll know and they'll be able to work around it instead of spending time trying to use your framework for (or trying to adapt it to) something which isn't (good) handled by it.
Yes, when you find some of these cases you'll be often tempted to solve it in your framework. You can try, of course, but if it does add some complexity (whatever small it could be), please forget it and document it clearly. Everyone wins!