Tilo Mitra

Front-end Engineering | UI Development

May 9, 2013

Waterloo’s Message

waterloo-space

A great post from my friend, Rajesh Kumar, on what makes Waterloo unique:

Waterloo’s message, at least within the confines of the University’s walls, is this: Learn to deal with shit thrown at you from all directions. And be able to do it all at the same time with minimal resources. Get a whole bunch of random crap thrown at you, and then learn to deal with it by figuring it all out one thing at a time. In fact, if Waterloo had but only one skill to teach its engineers, it would be the art and skill of “figuring things out” as quickly as possible.

A lot of my friends in engineering did this everyday: they skipped all lectures, and then figured out strange, complex concepts as efficiently as possible the night before the exam. We live in an age of information overload, when the time to “figure things out” or “deal with the unknown” is shrinking down to zero — fast. The people who can figure things out the quickest are therefore the most admired.

Read the entire post.

May 9, 2013

Developing a web app vs. a native app

iphone5
There’s a lot of back-and-forth between developers on whether one should focus on developing web apps, or native apps when it comes to mobile platforms. I’ve done a bunch of thinking on this, and having developed both types of apps, I wanted to share my point-of-view. I’m mostly going to be referring to iOS and Android here. Other environments, like Windows 8 or BB10 let you make native apps using web technologies. I’d also like to note that this guide is aimed more at indie developers, and not for large organizations. Ok, let’s jump in.

Defining Terms

First, let’s define what these terms mean. A web app is an app that built using HTML, CSS, and JavaScript for the most part. I’m going to include hybrid apps (web apps within a Webview container, so that they can be packaged natively) as a web app, because most of your application code is still using the web stack. In contrast, a native app is an app that is built using the native stack (iOS/Android SDK with Objective-C or Java). A native app may still have webviews, with some code that is rendered in HTML. It just means that the bulk of the app is made using native technologies.

Pros

Web apps have the following pros:

  • Faster to prototype in HTML/CSS/JS, than code an entire app in Objective-C.
  • No need to send updates through the app store – you can publish updates anytime
  • Your app runs in multiple environments. Gets close to the “write once, run everywhere” dream.

Native apps have the following pros:

  • More performant than a web app since you’re closer to the metal.
  • UI/UX looks and feels more natural.
  • Less time spent styling elements to make them feel native.

Cons

Web apps have the following cons:

  • Your app will never be as performant as it’s native counterpart. You’re always executing code in a browser-context, which is slower than the native context.
  • It’s a pain (near impossible) to get your app to look and feel native. This is especially true in iOS.
  • For hybrid apps, communicating between the web and native layer is a pain, and not elegant.
  • Webviews will always reload when you re-launch the app, causing an unpleasant user experience.

Native apps have the following cons:

  • Write once, for a single platform. Very far from the “write once, run anywhere” dream.
  • Your app updates have to be explicitly downloaded by the users, meaning you will have a fragmented user-base.
  • At the mercy of the app store.

My thoughts

Make (responsive) web apps if you want to reach a large audience; make native apps if you want your small audience to have the best experience possible.

My thoughts on this subject have changed over the last few months. Initially, I really believed that web apps were the way to go. I tried everything – Phonegap, Titanium, hybrid apps, and regular web apps added to the home screen. At the end of the day, I realized a web app cannot stand up to its native counterpart. It is too damn hard to make a web app feel native. By this, I mean that the styling, transitions and DOM structure necessary to make a web app feel usable on iOS is very difficult. Attempting to do this takes up more time than it would take me make a native app, in my opinion. The Android browser is even worse, especially since a good chunk of Android users are stuck on v2.3.x.

Now, even if you aren’t worried about getting your application to look and feel native, you still run into issues. For instance, for any app that requires a slightly complicated DOM structure, suddenly you have to worry a lot about memory management, webview scrolling jankiness, and more. LinkedIn is on of the few companies that have a successful hybrid app in the App Store, but most hybrid apps fail due to bad user experience. LinkedIn did some great work with NodeJS, and were able to keep their DOM and HTML structure extremely simple by removing DOM elements on the fly – not a trivial task, and one that is automatically handled for you when using native views.

You see, when it comes to making a web app, I face two challenges.

  1. Writing my application logic.
  2. Making sure my application’s UI/UX was not crappy on mobile devices.

When it comes to writing native apps, I only worry about (#1), which is the only thing that I want to think about. So, these days, I adopt to this principle: Make (responsive) web apps if you want to reach a large audience; make native apps if you want your small audience to have the best experience possible.

Concluding Remarks

Web apps and native apps serve different purposes. I think it makes sense to start off with a web app (faster to prototype, larger user base, etc.), and then make a mobile app if the idea sticks. Of course, the opposite works as well (Instagram went mobile-first, for example).

As a front-end engineer, and someone who loves to improve user experience, I think it’s a great idea to get some experience making mobile and web apps. They both have their own challenges, and I find them both to be equally fun to develop.

May 3, 2013

Cricket Time

cricket-time
A quick little NodeJS app that makes it easy for me to check cricket game timings, and watch live games. Check it out.

Rationale

Going on popular cricket sites like Cricinfo just to check what time the next game was starting to get annoying. Game times on those sites are hidden away and require multiple clicks to access. Just take a look at the picture below.

cricinfo-game-time

The times are provided in specific timezones, and I had to do some mental math to figure out exactly  how many hours from now is the next game starting. In contrast, Cricket Time pulls down the next 10 upcoming games, and humanizes the times. It’s:

  • always in sync
  • works in whatever time zone you are in
  • Updates in real-time
  • Works great on mobile too (I added the website to my home screen)

Live Games

I’ve also added a feed so you can view live games. This is my personal go-to stop when I am away from my TV and I want to see what’s happening.

live feed

May 3, 2013

node-boilerplate

A starting point for every new NodeJS app that I make.

I’ve been creating a bunch of websites running on NodeJS lately, and have become more opinionated in my stack. Generally, I use the following:

  • Express 3.x
  • Handlebars as my view engine (via express3-handlebars)
  • YUI on the client (and on the server, if I need Models on the server interacting with a DB)
  • MongoDB (with Mongoose), or MySQL (with Sequelize)
  • SocketIO (optional)

Instead of starting from scratch, I decided to fork the popular node-boilerplate repo, and make some modifications so that it represents the stack above. This is the result. It’s my starting point whenever I’m creating a new Express app on NodeJS. I just do the following:


> git clone git@github.com:tilomitra/node-boilerplate.git myprojectname
> cd myprojectname
> npm install
> npm start
Older Posts