How Typescript Inspired Ilograph
Ilograph is written in Typescript because of the productivity and safety benefits it provides over standard Javascript. Over time, however, it has proven valuable in an unexpected, and big, way. Typescript has gone beyond being just the language Ilograph is written in; here are four ways it has actually influenced Ilograph’s very design.
Influence #1: At-Home Good (or, The Problem With “Easy”)
In REWORK, the founders of 37Signals (now called Basecamp) describe products that are “at-home good”. Such products, they say, are not merely easy to pick up and use; they go beyond “quick wins” and provide the kind of long-term benefits sought out by professionals.
Typescript is at-home good. As a superset of Javascript, it is, by definition, harder to learn than Javascript. There is also an up-front configuration cost, and annotating types in code requires keystrokes that Javascript does not. However, once developers get it “home” and really begin using it, the long-term payoffs are enormous. Professional developers seek out these kinds of trade-offs. They do not (or at least should not) want “easy”, because “easy” doesn’t scale.
Using this as inspiration, Ilograph’s primary goal is to be “at-home good”. It is geared towards pros and designed to scale. For example, it does not use drag-and-drop; instead, users define diagrams using code. Drag-and-drop is easy to learn, but it doesn’t scale as well as code (rearranging boxes and fiddling with arrows and font sizes gradually becomes a nightmare).
Other features, like multi-perspective diagrams and resource inheritance allow advanced users to express things that simpler drag-and-drop tools do not. This is one of Ilograph’s “big bets”; it caters to a smaller pool of advanced users, but it is better tailored to their needs.
Influence #2: Starting with a Model
The eponymous feature of Typescript is that it allows developers to declare their data types in code. Using interfaces and types, developers define what their data types look like, typically before writing the functional code that uses those types. The data types and functional code then usually evolve together over the course of development. Javascript, by contrast, does not support this and data types are implicit (or, at best, checked only at runtime).
Together, all of the explicitly-declared types in a Typescript program form a model. This model is the foundation of the codebase; the functional code depends on this model, but not vice-versa.
Ilograph diagrams aren’t type-checked per se, but they are checked against a shared model
Using this as inspiration, Ilograph diagrams also start with a model1. Users declare what resources are before declaring how they are related (in Relational perspectives) and their behaviors (in Sequence perspectives). Like in Typescript, users give resources both a name and a type (in the form of a subtitle and/or icon) since both are important. This explicitness not only improves developer and viewer understanding, but also improves developer tooling.
Influence #3: The Developer Experience
Typescript may be harder to learn than Javascript (see above), but its design enables tooling that makes it easier to work with. The most prominent example is autocomplete, which offers more precise suggestions and catches more errors when using Typescript compared to Javascript. This instant feedback gives the developer “micro wins” and helps keep them in a flow state.
For the same reasons, Ilograph has an integrated editor with auto-complete that leverages the diagram model. More critically, Ilograph diagrams are laid out automatically, freeing the designer from having to manually place elements, arrows and so on.
In all of these cases, the cognitive load on the developer/designer is reduced. Whether programming or diagramming, the more the computer helps with the small things (syntax errors, diagram layout), the more the user can focus on the high-level goals they are trying to achieve.
Influence #4: Built-To-Change and Built-To-Last, a Paradox
Ilograph currently has about 15,000 lines of Typescript code. I’d estimate that at least that many lines of code have been deleted or rewritten over its lifespan (4 years). Almost everything about the original app, including its appearance, editing experience, and even nomenclature are drastically different today.
That may sound like waste, but it’s actually a sign of a healthy app that is adapting to feedback and shifting priorities. The world changes, after all, and we must change along with it.
I can say with 100% confidence that Ilograph would not exist without Typescript; it has made making so many changes possible. Without these changes, Ilograph would have been abandoned long ago. That is the paradox: things that are built-to-change last. Things that aren’t die out.
This might be the biggest influence Typescript has had on Ilograph. Like Typescript applications, Ilograph diagrams are easy to change. Making diagrams easy to change means that they are more likely to be kept up-to-date and relevant, and are more likely to provide long-term value.
Comments or thoughts? Please reach out to me @ilographs on Twitter or by email at billy@ilograph.com.
Share this article on Facebook
Share this article on LinkedIn