Skip to main content

Making app development easier: Interview with Jerry Bowerman of sonarDesign

sonarDesign is an Austin-based company that builds an exciting app platform, in Dart. Jerry Bowerman, the company’s CEO, previously worked at Sierra Online, EA Sports and LucasArts. I asked him some questions about the company’s vision… and tech stack. — Filip Hráček

Why did you start sonarDesign?

We believe the app store model is broken. It's a nice refinement of a 40 year old paradigm of installing and updating software. It introduces friction between the app creator and end user. The app store model served a purpose in the early days. I haven’t found anyone that actually enjoys the app-cycle (discovery, install, daily updates, deleting photos or apps to make space, etc.).

The Sonar platform is a contrarian bet on the app store model. We believe for the majority of use cases, delivering apps instantly via open standards is the right model. The challenge for most app creators, however, is learning open standards, like HTML5, at the specification layer so you can deliver the performance required by modern users. Most app authors prefer to drag and drop components and create interactivity with no-code or low-code solutions. The Sonar platform gives you the performance low-level HTML5 with the ease of use of drag and drop design and no-code interactivity.

Is the vision you had when you started still valid in 2016? Is Creation as a Service a thing now?

I believe it is a thing now, but goes by several different names. Gartner, Forrester and other research companies call it Rapid Application Development. Famous Industries calls it micro-experiences, Facebook calls it React, etc. The mission of each is very similar: abstract all the tedious “guts” of app development so people can focus on creation.

Setting up web servers, databases, communication servers, DNS, load balancers, is a time consuming pain. Even after completing all that, developers still end up supporting multiple code bases to produce multiple binaries for iOS, Android, Windows, etc. It’s horribly inefficient. The worst part, however, is after it is all said and done people are going to use your app a few times and after a month won’t be using it at all.

Building non-native apps powered by web technologies is a controversial approach. Why do you think it’s viable, technology-wise?

I think most people have long forgotten there was no app store when the iPhone launched.

In fact, the app store didn’t arrive until a year later. A couple of weeks before the launch of the original iPhone Steve Jobs hastily arranged a meeting where he passionately implored developers to use “AJAX” to make web apps. He said HTML5 is the future. To underscore his point, he said several times that mobile Safari was a full featured browser on mobile, not a gutted “mobile friendly” browser prevalent on feature phones at the time.

Of course we all know the truth: Safari on the original iPhone was slow, buggy and didn’t support much of the HTML5 specification. Fast-forward nine years, however, and mobile browsers do support most of the HTML5 specification, processor speeds are comparable with two year old laptops, and download speeds are way faster. Our 400KB client downloads in a couple seconds and delivers a native look and feel.

What’s your current tech stack? How has it evolved over the years?

Our platform is hosted on AWS and so we take advantage of quite a few of their services for email, messaging, storage, data storage, CDN, DNS, load balancing, etc. We have an assortment of managed Linux/Nginx instances running PHP and Dart services. We use DynamoDB for unstructured data storage and Postgres/RDS for structured data storage.

Our stack has been pretty consistent from the beginning. The only big change was moving from Mongo to DynamoDB a couple years ago. DynamoDB wasn’t available when we started the company back in 2012.

Does Dart give you any value that other technologies can’t?

Being able to work in a strong, typed, object oriented language is a huge value versus hand-writing JavaScript. Building features on top of existing Dart libraries is quicker than writing everything from scratch. Dart also does a good job of optimizing JavaScript and minifying it for final delivery.

Was it hard for you to find (or train) developers who know Dart?

I thought that was going to be a big issue but it really was not much of an issue. We only hired experienced developers with a solid understanding of object-oriented programming, code design, etc. New hires are usually over the syntax issues and productively writing code in a few days.

What’s the next big thing for your platform?

We have many important features we want to add over the next year such as alignment, 9-slice, exposing our Expression system visually, bitmap caching and so on, but the big thing for our platform is Components. Components are self-contained objects that you can share with other people, who can then extend the functionality, and share with more people. We introduced v1.0 of Components in our platform earlier this year but we plan to really blow it out over the next few months and into 2017. Imagine being able to share and extend art, code, audio and video without fear of theft? The Sonar platform tracks, authenticates, and delivers all the bits, which makes our Component system much different than asset stores using DRM.

Popular posts from this blog

Dart in 2016: The fastest growing programming language at Google, 2nd fastest growing in TIOBE Index

Dart was the fastest growing programming language at Google in 2016 with millions of lines of code written. It also made it to TIOBE Index Top 20 this month (see TIOBE's methodology ). It takes time to build something as ambitious as Dart and, in some ways, Dart is still in its infancy. But we're glad the hard work is starting to pay off. Many thanks to our amazing community! We're going to celebrate by ... releasing 1.22 next week (as per our usual 6 week release schedule).

AngularDart is going all Dart

Until now, the multiple language flavors of Angular 2 were written as TypeScript source, and then automatically compiled to both JavaScript and Dart. We're happy to announce that we’re splitting the Angular 2 codebase into two flavors – a Dart version and a TypeScript/JavaScript version – and creating a dedicated AngularDart team. This is amazing news for Dart developers because: The framework will feel more like idiomatic Dart. It will make use of Dart features that couldn't work with the TypeScript flavor. It will be faster. This is equally great news for our TypeScript and JavaScript developers, by the way. Cleaner API, performance gains, easier contributions. Read more on the Angular blog. Angular 2 for Dart is used by many teams at Google. Most famously by the AdWords team, but many other Google teams build large, mobile-friendly web apps. Some of the top requests from these teams were: make the API feel like Dart, provide a faster edit-refresh cycle, and

The new AdWords UI uses Dart — we asked why

Google just announced a re-designed AdWords experience. In case you’re not familiar with AdWords: businesses use it to advertise on google.com and partner websites. Advertising makes up majority of Google’s revenue, so when Google decides to completely redo the customer-facing front end to it, it’s a big deal. The Dart team is proud to say that this new front end is built with Dart and Angular 2. Whenever you asked us whether Google is ‘even using Dart for anything,’ this is what we had in mind but couldn’t say aloud. Until now. We asked Joshy Joseph , the primary technical lead on the project, some questions. Joshy is focusing on things like infrastructure, application latency and development velocity, so he’s the right person to ask about Dart.   Q: What exactly did we launch on Monday? It’s a complete redesign of the AdWords customer experience that is rolling out slowly as a test to a small initial set of advertisers. The most noticeable thing is probably the Material