Friday, December 30, 2016

Mac OSX Web Developer Challenges

The point of this blog post is not to bash Mac OSX.  I like my new Macbook, my wife loves her Macbook even though it's getting quite old, I just bought one for my son, and OSX has many advantages over Windows.  However, since switching to OSX away from Windows for web development I have experienced some frustrating problems.

Most IT organizations doing web development use Windows for developers and Linux and/or Windows for their servers, although as I pointed out in a previous post Apple hardware is becoming more common.  Of course, Apple got out of the server business around 2010 and there's no sign of them jumping back in.  There are actually some hosting companies that will rent out OSX in the cloud, but that's not very common, and it's not an area that is making much money for Apple.  So, those of us doing web development on Apple computers are kind of an exclusive group.

The vast majority of Mac users are not going to run into the kind of problems I am having, because they are not web developers using development tools and languages not created or supported by Apple.  I do a lot of programming in Java and Javascript.  This is a programming blog, so I am assuming the audience is other programmers, but if you are an OSX and/or iOS developer doing ObjectiveC or Swift, maybe you are in the enviable position of having everything basically always work as you expect.  That's not the world I live in, at least not in my current job.

One of the first difficulties (I won't even call it a problem) that I ran into with my new Macbook is that there are so many ways to install software on OSX.  
  1. App Store (note that somebody also created a cli for the mac app store)
  2. DMG (disc image) files
  3. application files
  4. archives
  5. Windows-like installers
  6. Macports for installing ports of Linux and Unix software
  7. Fink, an alternative to Macports that provides a Mac implementation of Debian Linux tools like dpkg and apt-get, concentrating on pre-compiled binary packages to improve performance over Macports
  8. Homebrew, another alternative to Macports.  Homebrew does not like the other competing package managers, it takes over /usr/local and doesn't like other installers to put anything there, and, similar to Macports, installs can be excruciatingly slow when it has to compile from source.  However, even with the drawbacks Homebrew seems to be better than Macports or Fink and makes it much easier for a developer to install certain software.
  9. SDKMAN, for installing Java and Groovy SDK's
To be fair, there are multiple ways to install software on Windows and the various flavors of Linux as well.  However, I am just pointing out that using a Mac is generally expected to be simple and intuitive, but that is probably not going to be the case if you are a web developer.  Even if you don't want to run any software ported from Linux, there are at least 5 ways to install software on a Mac.

Some problems I have experienced as a web developer are particularly frustrating because they seem to be very specific to particular versions of OSX.  Therefore, other developers I work with may not see these issues even if they are also using a Mac.

Recently I have been working on a Node.js app that uses something called deasync.  Now, I don't want to digress into a conversation about Node.js, but suffice to say that deasync is a C hack that changes the way Node.js behaves at a low level and should probably not be in our project, but it is, and I have to deal with it.  Unfortunately, it turns out that deasync gets errors on my Macbook.

What is most frustrating about this Node.js problem that I am having is that it doesn't happen under Windows or Linux, and it doesn't seem to happen on all versions of OSX either, so basically I am the only person on my team having this problem.  And the only workaround I can find for this problem is to completely avoid it by running the Node.js app from inside an Ubuntu Linux VM.  The permanent fix should be to stop using deasync, but that would require a lot of re-writing on a project that is running out of budget.

Now, this deasync/Node.js bug is not Apple's fault, it's not even the fault of the Node.js developers.  The author of deasync doesn't want to take responsibility for it, because the error actually occurs in libuv, which is used by Node.js and deasync.  However, the libuv developers would probably say it is a problem with OSX.  I could try to fix libuv myself, it is open source, but I am a bit outside of my comfort zone with such low level C code.

Of course, these are just a couple of examples of the kind of difficulties one may run into.  I would really like to know how many web developers use Macs in their work compared to Windows and if they tend to run into similar issues or if I've just had a bit of bad luck this time around.  Also, I am hoping that with increased familiarity I will just know how to avoid problems in the future.


No comments:

Post a Comment