Yesterday I posted my first Comique developer diary, which explained what Comiqueās highest priority is, and an idea for how to solve it without going completely mad. tl;dr: Comique needs to be available on all devices, but to make that work I need to bundle several different projects into just two manageable ones.
One of those projects is the existing iOS reader app, and the other is an all-new web app for making, browsing, buying and reading comics. This web app needs to be rock-solid, easy to maintain and develop new features for, and most importantly ā and maybe contrary to all the previous points ā it needs to happen fast. How the hell am I going to manage that?
Join me, traveler, as we take a trip to the figurativeĀ hardware store and work out which tools are going to get this job done.
Right now, the closest thing Comique has to a web app is artists.comique.co. This is the website comic makers currently use to upload and edit comics, view their sales, and manage their payment information. Itās also got some features just for me like making royalties easier to calculate, sending push notifications to the app, and sending mass emails to artists.
Itās got a lot of the functionality this new web app will need. But for various reasons, itās not a good project to expand into a full-blown reading app. It was built with a lightweight framework called Sinatra that makes it very easy to get something up and running with, but doesnāt scale well to big user-facing projects. It encourages you to do a lot yourself: itās really great if you want to learn about the challenges involved in making a good app.
But a lot of those problems are ones that have already been solved, like: āwhatās the best way to have user accounts in your app?ā, orĀ āwhatās the best way to serve images and stylesheets?ā, orĀ āhow do I get easy (and secured) access to information in a database?ā. Super fun stuff, I know.
What I was looking for was a framework that took care of a lot of these solved problems with respected, established solutions. And it would be great if it would use a programming language Iām already comfortable with, like Ruby ā then I could maybe even reuse some of the code from artists.comique.co!Ā
Fortunately there is such a framework, and itās called Ruby on Rails.
(note: I used to turn my nose up at Ruby on Rails because I didnāt like how muchĀ āmagicā there was involved with it ā it hides a lot of whatās happening under the hood. This is why I chose Sinatra for artists.comique.co. But now that Iāve got experience building my own web app, Iāve gotĀ an idea of what itās taking care of, and how little I care about doing that myself. Still, I think Iāve learned more by trying it out myself first).
This way a lot of problems are solved out of the box. Improved security, more efficient asset serving, user accounts ā all there without me having to do a whole lot.Ā
Continuing the carpenter analogy which makes me feel as if Iām an exciting outdoors person working with my hands, this is great: instead of me having to go the forest, chop down trees, transport the lumber back and cut it into planks myself, I have a whole truckload of planks, ready to go.
And thatās the system for the backend decided on. Thisāll do all the lifting on the server thatāll give users the comics theyāre looking for, upload comic pages to servers, and make sure no-one is looking at comics theyāre not allowed to see!
Now I can let Rails worry about the boring stuff, and think about the bit I love the most.
Even though I spend a lot of my time programming, for me itās a means to an end ā and that end is great interfaces. In Comique, I want reading comics to feel fantastic. And I want making those comics to feel fantastic too.
ItāsĀ hard work. Thereās a lot of moving parts: the information you have at hand, like text and images; how you present them; and how they behave when you interact with them.
And on the web, these three different domains all have their own systems. Information is provided in hypertext markup language, styled with cascading style sheets, and interaction dealt with by Javascript. In a big project, you have to keep these three systems working together, even though they donāt really know everything about each other.
When a project gets big enough, it can start to get really confusing. Which bit connects where? Whereās the markup for that widget again? Where does this bit get its title from, exactly?Ā
Without vigilance, a project becomes hard to maintain and eventually starts to be neglected. And who likes a neglected project? No-one, thatās who.
Iāve dealt with these problems before, and Iāve never been completely satisfied. Despite my best intentions and organisational efforts, things would slowly start to get out of whack. I donāt think this is just me, Iām now convinced that itās a problem borne out of the standard tools available to us (but thatās an argument for another post).
A few months ago, this tweet caught my eye:
Last year I watched a presentation titledĀ WWDC 2014: Advanced iOS Application Architecture and Patterns, featuring Andy Matuschak and Colin Barrett, and came away very impressed with their ideas about managing the flow of information in applications and their interfaces. Of course Iāve used UIKit a lot in making Comique for iOS, and while itās not perfect, thereās a lot to like. So when Andy Matuschak mentions this thing called React, Iām all ears.
To keep this short and simple, React is a framework that makes you bundle all of these concerns ā markup, presentation and behaviour ā into modular components that encapsulate everything about them. When you want to change something, you know exactly where to change it. When thereās a bug, you have a very good idea of where itās hiding.Ā When you want to reuse interfaces youāve built before, you can do so, like recombining Lego bricks.
Itās unusual and controversial. Not everyone likes it. There are a lot of people who think you shouldnāt mix markup, presentation and behaviour together, and a lot of people who donāt trust it because itās made by some rather brilliant engineers from Facebook.
But I love it, and itās what comique-webās UI is built with. Itās so wonderfully straightforward to build with, and it encourages you to build interfaces which are resilient and lightning fast. (Itās also allowed me to build an interface that is entirely indepedent of Ruby on Rails and could be transplanted onto a new backend very easily, should that ever need to happen).
It might also be what powers the interface of the iOS reader app in the future, and would definitely power the UI of a potential future Android app. Itās exciting stuff.
But thatās enough tooling around. Tomorrow Iāll get round to sharing what Iāve been making with these frameworks, and the features which will make up comique.co.Ā
The first thing I need to do is make this new app do at least what artists.comique.co can.
