Reactive Conference is bringing you an interview with one of our speakers Sean Grove.

What’s your personal elevator pitch?

I’m a developer living in San Francisco, where I run the local ClojureScript meetup with my sister. I tend to really enjoy taking technology that’s almost-ready and seeing what it enables, and what its costs are — unikernels, functional WebGL, abstract interpretation, etc. Sometimes it’s a clear win — our company at the time deployed the first production app in Om and saved so much time (and happiness) that would have been spent wrestling with the frontend. Other times, it’s a clear dead-end for the time being. But in each case, the act of exploring — feeding your subconscious with a new point of view — and seeing the consequences, is incredibly gratifying. Often that means a lot of throw-away demos and code, but that’s alright — I’m careful these days not to put my experiments in a place where others can rely directly on them, so I feel free to iterate, chase promising leads, and throw away dead ends. It sometimes feels like cheating — I’m often standing on the shoulder of giants, using their code, and just wrapping it up in a slightly different way, but I’ve come to feel OK with that. There’s a sort of process that happens with big, starkly new ideas, and it’s rare that the people who invent it are the ones who popularize it (just look at all of the CS research between ~1972–1976 that’s becoming popular now), and without that final step forward progress is severely inhibited. And in any case, it makes me happy to build cutting-edge apps and demos that are significantly simpler, faster, more clear, and more capable than they would be in some other expression.

How did you end up being a web developer?

Pre-mobile, the web was by far the most interesting distribution platform. If you wanted to easily share your projects and ideas with friends, it was easiest to do it via the web. That said, I spent most of my time on the backend — building APIs, munging data, etc. I actually assumed that building UI’s on the web was a solved problem — I mean, the web has been around for literally decades now, and has had every chance to learn from the desktop tooling, ideas, advantages, and pitfalls that came before it, so sure it should be better, right? Alas, that turned out to be wildly misguided. I nearly quit programming entirely when I built the front-end to our app in January 2014 and saw the state of things. Luckily I came across React, which embodied a lot of the core concepts I was looking for, and I was saved.

What was the journey to creating your JS library Dato like?

Dato’s been several years in the making now. Each app I’ve built has incorporated one new design or tech piece, in order to grow in understanding and ability while avoiding the fight that comes from picking up an entirely new tech stack. I often underestimate how much even a small design/tech change can open up new possibilities. For example, with Zensight, we separated our state transitions from effects (at the time we called it the controller/post-controller, in Dato the transition/effect model) to be able to reason about our code — but then we realized if we just kept track of the transition inputs, and disabled effects, we actually got code replay without much effort. Or for Precursor (not my app, but I worked on it a tiny bit in the beginning), the change that happens when instead of using a tree-like data structure to store your entire state, you use a flat databases in the client — sounds a bit crazy, but now you can have generalized tools that query for the state of anything in your app. The question is — are these benefits forever locked behind functional programming constructs/terminology, or can it be exposed to everyone such that it’s *easier* to write an app with these benefits than it would be to write a ‘standard’ web app? Dato’s emphatically set on making all this stuff easily accessible.

What is the most important project you’re currently working on?

Dato is the most important OS project by far — it represents the ideal experience/interface for building not only apps, but also for custom tooling around apps. I’m a huge fan of toolstrapping languages and applications, and I want that to be accessible to everyone. Confused about the interaction between two of your components? Write a quick GUI tool to query their state, record their interactions, and then slide back and forth examining exactly what happened — shouldn’t take more than 10–15 minutes, but it’ll save you hours over the long run. Same for layout, malformed data, styling, etc. The goal is to bring the in-app editing experience that Smalltalk had, with the functional programming benefits of e.g. Clojure/Elm, while avoiding the island-development syndrome that made image-based applications so difficult for devs using e.g. emacs/vim/sublime to work on.

Is there any issue in web development world that should be fixed asap?

A. Global CSS scope is a huge problem. Inline styles go some way towards alleviating this, but it’s still too easy to mess. Let’s say you’re building some dev tools, and you want to assure the styling is correct (you don’t want to be infected by the host page’s styles) and you don’t want to harm the host page’s styling — you’re in for some late nights. Sadly, the <style scoped> attribute isn’t widely supported. B. Shared immutable memory. There’s a proposal up which is great, but it’s incredibly low level and is going to be difficult to build on top of. The whole story of it blows my mind — we don’t have shared memory because devs might hurt themselves, so just serialize and send! — but wait — we realize it’s expensive to serialize/deserialize these objects when sending them between workers, so we have an experimental “transferrable” object that’ll remove the object from the sending side. Both of these options completely kill the advantages of persistent data structures (e.g. immutable.js or ClojureScript’s default data structures) in order to solve a problem they were guaranteed not to have in the first place!

What will you speak about at Reactive 2015 and what do you expect from the conference?