Hello, Web Technologies!

I’m a first-time entrepreneur and I’ll be recording my learnings and experiments over time. I am always eager to interact with interesting people and learn new things. Please say hi to me on twitter @k2_181.

I have a Ph.D. in large-scale data-intensive science (the academic precursor to big-data) and I’ve worked in a couple of big-data companies (Greenplum, EMC and Qubole) earlier and built some fairly complex software. I had pretty good depth in a couple of niche areas, but I was nowhere close to being a full-stack developer. I will admit that I was a little embarrassed by it.

When my co-founder and I started talking about the business idea, it became apparent that the product would be heavy on web technologies. I decided to take up the challenge. At first, it was a little daunting — there were so many options in languages, frameworks, libraries, hosting providers. Fortunately, I’d spent a long time navigating large problem and solution spaces — some of the grad school training came in handy. I finally ended up with the following choices — would love some feedback from experts.

  • AngularJS — I liked that it forced developers to think and code more systematically. It does have a bit of a learning curve, but as I worked through some examples, it all seemed to make sense. I looked at React.js briefly, but it seemed like it was a small piece of the puzzle. There are a lot of articles talking about moving from AngularjS to React — but I haven’t faced any of these issues, yet.
  • Charts.js — I had to show some nice charts and looked at a few options including AmCharts, Rickshaw and Google Charts. I went with Charts.js primarily because of Angular-chart.js that bridges AngularJS and Charts very nicely.
  • alasql.js — I wanted to be able to add new charts quickly. Many charts were simply applying filters and aggregates on small tables. I chanced upon alasql.js which allows you to run SQL inside the browser against in-memory structures! It allowed to create multiple charts from the same input data and avoid clumsy aggregations in javascript or server-side call per chart.
  • (See edit) MaterializeCSS — while reading some blogs, I stumbled upon Material Design principles by Google. It seemed to make sense, and more importantly, it was visually appealing. MaterializeCSS.com is a front-end framework built on these concepts and has good documentation. Edit: I’ve actually dropped using MaterializeCSS in favor of Angular Material which played well with my angular app.
  • Dropwizard — I’d dabbled with Ruby-on-Rails and Python-Django for web services backend earlier. I’d never liked them — there was simply too much magic and it was easy to build up technical debt with them. I was much more comfortable with Java, but the traditional servlet programming and deployment seemed very outdated. Dropwizard combined the best of both worlds for me — it was good ol’ Java, but it had features to speed up time-to-v1. I also considered Play Framework for a bit, but it seemed too new at this point and had too much magic.
  • Heroku — I looked at Google App Engine for a bit. However, I felt there was quite a bit of lock-in. If I wanted to use Dropwizard, I’d have to go for a managed VM — which seemed like too much work for now. Heroku worked out great — I could choose the language / framework of my choice. Their documentation was great. Furthermore, I could just live on free dynos for now.
  • RabbitMQ — I needed a queue to do background processing work. I’m planning to use RabbitMQ.

The app is coming along well so far and I haven’t regretted any of these choices, yet :) I’ll be sure to write a follow-up post when things are further along.

Siva Narayanan

Read more posts by this author.