web development

Why I Use Mac OS X for Web Development

Comparing and contrasting the way that operating systems handle certain tasks can be touchy for some people. As such, I think I’d better make this point right from the get-go: I don’t want this to be a flamewar. I use Mac OS X, Windows, and various flavors of Linux and have likes and dislikes about all of them. I am not saying that Mac OS X is superior to Windows and Linux operating systems in every way, nor am I saying that every web developer should always develop on Mac OS X. I am simply offering some points for web developers to consider when deciding which operating system to do web development on.

Mac OS X Has Better Compatibility with Popular Web Development Tools Than Windows

Git can be awkward to use on Windows. For example, the last I checked, if a repository uses symlinks, a workaround must be put in place to get that repository to play nicely with Windows, as described in this Stack Overflow question. Also, at the company I work for, we use Vagrant and rely on NFS synced folders because, without them, our virtual machine’s performance is pretty awful. Here is a quote from Vagrant’s NFS documentation:

Windows users: NFS folders do not work on Windows hosts. Vagrant will ignore your request for NFS synced folders on Windows.

These are just two of the issues I have with using Windows for web development and both are not issues on Mac OS X.

Mac OS X Allows Testing Browsers in a More Common Environment Than Linux

It is a well-known fact that for most websites, the majority of the visitors using desktop computers or laptops are running Windows or Mac OS X. So unless you know that a significant number of people in your target audience are using Linux, it doesn’t make much sense to do most of your testing in Linux. Some web developers may say that Firefox or Chrome renders pretty much the same regardless of the operating system. However, there can actually be significant differences. For example, consider this HTML:

<!DOCTYPE html>
<html lang="en">
		<meta charset="utf-8">
		<title>Cross-Platform Test</title>
		<link href="//cdn.jsdelivr.net/normalize/2.1.2/normalize.css" rel="stylesheet">
			div {
				width: 300px;
				border: 1px solid #000;
				font-family: Georgia;
				font-size: 16px;
				line-height: 24px;
			When using Chrome 28.0.1500.95 and Firefox 23.0 on Windows
			7, Mac OS X 10.7.5, and Ubuntu 12.04.1, the number of lines
			this text takes up remains the same for both Mac and
			Windows (9 lines), but varies for Ubuntu (Firefox is 10 and
			Chrome is 8). Depending on what you are doing, this can
			cause noticeable design issues.

As stated within the above HTML, the way that the text in the above HTML gets rendered on Linux is significantly different than the way it gets rendered on Windows or Mac OS X. Here are some screen shots:

Chrome 28.0.1500.95 on Windows 7 Firefox 23.0 on Windows 7

Chrome 28.0.1500.95 on Mac OS X 10.7.5 Firefox 23.0 on Mac OS X 10.7.5

Chrome 28.0.1500.95 on Ubuntu 12.04.1 Firefox 23.0 on Ubuntu 12.04.1

So if you’re going to do your web development on Linux, you should probably not be too trusting in the way the browsers render your code. It would be safer to do all of your testing in a Windows virtual machine. There are free and legitimate virtual machines meant for testing websites in Internet Explorer available at modern.IE. You can use those same virtual machines for testing in Firefox and Chrome, of course.

With Mac OS X, you should still test your websites in Internet Explorer using a virtual machine, but I don’t think testing in the Windows versions of Firefox and Chrome needs to be done nearly as often as it does in Linux since those browsers render very similarly on both Mac OS X and Windows.

While I’m on the topic of testing browsers in virtual machines, I should note that based on what I’ve read in Apple’s software license agreement for Mac OS X 10.8.2, I believe that running Mac OS X in a virtual machine is only permitted if the host operating system is Mac OS X.

Mac OS X Has a High Level of Accuracy in Simulating iOS Devices, Unlike Windows and Linux

Xcode, which provides access to iOS Simulator, is available as a free download for Mac OS X. iOS Simulator provides a far more accurate iOS experience than any browser extension or web app I’ve seen. For more details, see my iPhone Website Testing: Windows Browsers vs. iOS Simulator┬ápost. I believe in this age of mobile devices ever rising in popularity, it’s important to test your websites on iOS devices, among other mobile devices. This may not be the case for every website you develop, but I would guess that it’s the case more often than not.

Go Daddy’s Database Creation Form: Horrible Password UX

A very poor decision was made by somebody at Go Daddy. That decision caused me hours of frustration and delayed the launching of a client’s website. Behold, the 14 characters that caused such grief:


When creating PHP websites, I, like many web developers, develop locally first. Once the client is happy with the website, I get things ready for production by uploading the code, creating a database, and importing the data. My troubles occurred with creating a database, specifically with the database password. Here are Go Daddy’s password criteria:

  1. be 8-14 characters long
  2. start with a letter
  3. include a lower case letter
  4. include an upper case letter
  5. include a number
  6. include a special character (!,@,#,%)
  7. not include these characters (^,\,$,`, )

Go Daddy has client-side password validation so that you can see which criteria your password meets and which it doesn’t. Now, given the popularity of phpMyAdmin and the fact that it generates 16-character passwords, I’d be willing to bet that there are a lot of MySQL database passwords out there that are 16 characters long. I also think it’s fair to assume that a significant number of web developers have their development database and production database share the same name, username, and password just to keep things simple. It’s not like it’s the root user, so why not?

Given these things, it’s only logical that it would be common for people to paste their database password into the password field on Go Daddy’s “Add a MySQL Database” form. And that’s a problem. Why? Because that password field has its maxlength attribute set to “14”. This means that if you paste anything more than 14 characters into it, whatever you pasted will be truncated without warning. So pretty much the only way you’ll notice that it got truncated is if you have a password significantly longer than 14 characters. Then, of course, you won’t be able to access your newly created database but, of course, Go Daddy’s tech support will be able to access it just fine. So I have some questions for Go Daddy:

Why limit the password length to such a small number? And if you’re going to do that, why not have that number be 16 since that’s the length of the passwords generated by phpMyAdmin? Next, why put the password’s maximum length in the HTML? The rest of the password criteria are checked client-side, so why not the maximum length as well? This way, if somebody pastes a password longer than the maximum length, “be 8-14 characters long” would get an “X” next to it and the person would realize that the password is too long.

Of course, the chances of Go Daddy reading this are slim to none. Even if they did read it, I highly doubt they would do anything about it. But maybe this blog post will help somebody else facing the dreaded “#1045 – Access denied for user ‘foo’@’’ (using password: YES)” message.

Lastly, I want to say that the only reason I was using Go Daddy is this particular client was already a Go Daddy customer. Otherwise, I most definitely would have went elsewhere.

iPhone Website Testing: Windows Browsers vs. iOS Simulator

I believe that in most cases, it’s important to test your website’s design on an iPhone and an iPad. This is easy to do if you own both of these devices or if you own a Mac (since Macs can use the free iOS Simulator, which can be downloaded through Xcode). But what if you do your web development on Windows and don’t own one or both of these devices or a Mac? People often suggest using Chrome or Safari because they both use the WebKit rendering engine, which is what Mobile Safari uses. It’s just a matter of overriding the browser’s user agent string and resizing the viewport. But is this method just as reliable as using the iOS Simulator? I did some tests to find out.

The Test Environment

I ran iOS Simulator 5.1 (272.21) on Mac OS 10.7.4 and I ran Chrome 20.0.1132.57 and Safari 5.1.7 (7534.57.2) on Windows 7. All three browsers used the following user agent string:

Mozilla/5.0 (iPhone Simulator; CPU iPhone OS 5_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B176 Safari/7534.48.3

The Results


Although Chrome and Safari on Windows can produce results quite similar to iOS Simulator, I don’t believe they should be considered as reliable as iOS Simulator. Of course, none of the three should be considered a true replacement for the actual iOS devices, but I’ve compared all three to my iPod Touch and iOS Simulator definitely does a great job. So should you shell out your hard-earned cash for one or more expensive Apple devices? That’s up to you. Just be aware of the potential risks in putting too much trust in Chrome or Safari on Windows. Lastly, if you have the means, I encourage you to do your own tests before making a decision.