So I recently decided to give Ruby on Rails another chance. For many of the same reasons I gave jQuery a chance. I'll use this decision as an example, so bear with me for a second.
I was a huge fan of MooTools (and still am), but I decided to give jQuery a chance. I liked MooTools better. I thought it was superior to jQuery in its organization and many other things. You have to admit that MooTools's animations look way better.
All of that said, two things made me switch: the amount of code I didn't have to write and the huge community around it.
With jQuery you write a lot less code than you do with MooTools. I sometimes feel that its a lot less elegant, but less code equals quicker development time.
My biggest frustration with MooTools was that they changed major stuff in every release (at least when I was using it about a year ago). This means that if you needed a lightbox, you could find a few, but none of them would work with the current version. If you searched for jQuery ones, you could find tons of them.
On to Rails
I took the same approach when I was giving Ruby on Rails another chance. I knew the community was huge. It seems Rails is growing in popularity every day. All of the PHP programmers I knew were either dabbling in WordPress or writing really ugly, non-MVC code. It just seems that it's hard to find a PHP programmer doing cool stuff these days. I know a few don't get me wrong, the number just seems less and less.
I watched Creating a weblog in 15 minutes from the Ruby on Rails website. It blew me away. It was amazing how much code you didn't have to write, which is the entire purpose of a framework. A framework is designed to solve common problems so everyone doesn't have to solve them again and again. Rails seemed to solve more of these problems than any other framework I've used, and it did it very well.
I downloaded Rails and gave it a shot. I just followed along with that video to create a simple weblog in an hour or so. I was really impressed with myself on how quickly I could code it.
But, Rails isn't as good as PHP is it?
Well that depends on how you define "good". To me a good web development environment is one that lets me develop the quickest. Before Ruby on Rails it was KohanaPHP (which I totally recommend if you're using PHP). If Rails lets me developer faster and write less code (which generally equals less bugs), then to me that makes it a win. I believe it does. There is way less code in my Rails version of my blog than my Kohana one.
It has been proven many times that Ruby is slower than PHP. That doesn't bother me at all. If I'm writing a large web app, I'm going to be caching as much as possible anyway, so what's the point. If I can roll out features quicker at a tiny performance hit for when the cache misses, that is a win in my book.
This is the age old question for app developers. To state my bias, I make a living creating mostly native app and the occasional web app, but I greatly prefer working on native apps. I'll be referring to iOS devices for all of this, but it applies to the Mac (sorta, see the end), Android, and almost any other platform.
We Can All Agree
We can all agree that native apps have a much better experience than web apps, especially on slower devices (like the iPhone). Pull up your contacts in your iPhone and flick through them really fast. See how smooth that was. Now pull up any website and do the same. Not so smooth. Checkout Cover Flow in the iPod app. Amazing, right? Show me a website that does that that smooth. You can't.
The reason that native apps greatly out perform web apps is that there is a lot more processing power used to render website than it is to render native apps because they are... well, native. Websites need to run through some sort of engine, in this case WebKit, to convert them to something that can be used by the device.
You don't see games like Angry Birds or apps like Twitter for iPhone in your browser, because they simply can't make something that elegant and preformant. Partly due to some of the technologies not being available to web developers and partly due to browsers not being able to handle that much stuff efficiently.
So let's all agree that native apps are ideal over web apps. I could go on and on about this, but I think you get the idea. (If you don't agree, I think you're wrong and would wonder why would would ever use or want to make native apps. You should probably stop reading this and point your beloved browser elsewhere. Just kidding, but seriously.)
Why?
The main question I have for anyone asking this question is "Why do you want to make a web app over a native app?" There are usually two answers that people give me:
If we make a web app, we won't have to make it for each platform.
If we make a web app, we will be able to develop it faster.
Notice that it is never "If we make a web app, it will be a better user experience for the user." because that is never the case. You are trading user experience for quicker development time and platform flexibility. For some, this is ideal. In that case, make a web app.
In my experience, 90% of the time you want the best user experience possible. I want to make my users happy. I think providing them with the best user experience is the best way to do that. (If you are trying to make money of your app, more happiness = more dollars.)
Conclusion
I would rather trade development time and platform flexibility for a better user experience because I am passionate about making the best apps possible for my users.
Disclaimer
I wrote this in the context of mobile development. I think this still applies to the desktop, but it is a very different space. Most users don't buy apps or even understand that concept on the desktop. Web apps are great for most cases. Obviously you can't edit music or video (effectively) in a browser. Stuff like that will probably always be a "native app."
Also, there are lots of other pros and cons for both that I could have went into, but I decided to keep this short. With any other pros added to web apps, my conclusion still stands.
So I recent improved how my blog looks and works on iPhone in just a few lines of code. The iPhone web browser is awesome, but for large websites, it is really hard to read something without panning around vertically and then scrolling horizontally. Solving these issues will make your site way more useable on Mobile Safari.
Add an iPhone specific stylesheet. Something you will probably want to do is make your site narrower. The wider your layout is, the smaller everything has to be. It is much easier to scroll just vertically than vertically and horizontally. Something else to watch out for is mixing font sizes between px and em. You'll probally get some weird scalling issues if you mix units. You might also watch out for positioning issues due to Mobile Safari's scaling.
You might also want to adjust your font sizes a bit. I know I had to make my footer a tad smaller. In your case, you might want to make important things like navigation larger and easier to tap. Feel free to check out my iPhone specific stylesheet at http://samsoffes.com/css/iphone.css.
Add a viewport meta tag. This will tell Mobile Safari how to intelligently scale to fit your page. It's super easy to do and it will help a lot. My iPhone stylesheet makes my site 320px wide so I set my viewport to 320 to give a new bit of padding around my main content area. Here's the code:
Remember if you have something that is wider than your viewport, it will automatically expand, so be sure to resize it in your iPhone specific stylesheet.
Add a homescreen icon. When a user adds your website to their homescreen, you want it have a facny icon. You can easily do this by putting a 57px x 57px png named apple-touch-icon.png at the root of your website. For example mine is at http://samsoffes.com/apple-touch-icon.png. You can also put it at a different location with this link tag:
Doing these three simple things will make your web app way more useable on the iPhone. You can do most of this in about 10 minutes like I did. If your layout is overlly complex and can't be made narrower and simplier easily, then you'll have a lot more work than 10 minutes of course. Have at it!
Oh, and don't forget a favicon.ico for your desktop users.
