First, let’s take a look at what our stack actually looks like.
The backend API is pretty straightforward – a Node/Express server, connecting to a Mongo database mostly through mongoose.
On to the feels
You can find a lot of hate online for the browser’s
The toolchain is also equal parts awesome and bizarre. Node, which is necessary for doing anything server-side, is fast, easy to use, and occasionally face-palmingly obtuse. Domains, for instance – which are deprecated, without having a replacement – and kinda mostly work, except when they don’t. Or the file system commands, which require you to use a try-catch to detect file existence. Or npm, which can easily fail due to network congestion, creates cascading, ballooning dependencies, and encourages an easy dependence on external, mutable code (<cough>left-pad<cough>) – but is also the gateway to an incredible ecosystem of critically important tools and libraries.
When I first agreed to join Scratch, the codebase was in Angular. By the time I joined three weeks later, the team had started rewriting the app in React. Although some of their reasons weren’t great (one engineer joked that they were afraid I’d nix the plan if they waited till after I joined), in retrospect, it turned out to have been a good decision.
It wasn’t immediately apparent. There weren’t a lot of accepted best practices at the time, the Flux/Redux/etc. wars were still playing out, and we made a lot of mistakes along the way. Over time, though, we’ve learned effective idioms, aggressively retired technical debt based on bad early decisions, switched out plain vanilla Flux for alt.js, and are generally pretty happy with where things are (though, of course, there’s still plenty of room for improvement).
React can feel a bit odd at first, or atavistic – a throwback to JSP scriptlets sprinkled through html, or the horror of Java files
System.out.println‘ing frontend code directly into the response stream. But use it a little and not only does it start to make sense, it starts to feel natural.
Our first mobile app used Cordova – a bundled version of our single page app, with some fairly trivial native components. We were interested in switching to a new architecture which would enable a snappier, more native experience, and ultimately decided on Swift for our iOS app.
I managed the mobile team at TripAdvisor for three years. I’ve coded my own hybrid, and fully native iOS apps in Objective C. And I picked up Swift when trying to teach my niece mobile development a while back. I wanted to build a Swift app. I thought it was the right approach. But the team was interested in using React Native, and I didn’t want to railroad the process. So sure, I said, let’s do two time-boxed proofs of concept – one in Swift, one in React Native – and make a decision based on what we learn.
Both projects made progress quickly, setting up environments, getting a critical UI element in place, and then… things stalled. Other priorities came up, and our time-boxed tasks got put on hold. I worked on it nights, and was repeatedly frustrated when trying to set up things that should have been straightforward. I eventually picked up Bonnie Eisenman‘s Learning React Native, blew through it in a couple hours, and was sold.
If I’d had a team of iOS experts, going with Swift likely would have been the right choice. But I didn’t. Don’t. I have a strong team, and I don’t doubt their ability to come up to speed on any required technology – but the choice was ultimately between a language that two of us knew to varying degrees, and all would have had to spend precious time learning… vs. a variant of the language and framework we were already using daily. Once I was able to set aside my personal desire to use Swift (which was quite independent of any fact-based decision-making process), the answer immediately became clear.
Let us imagine that there are, in fact, good use cases for Mongo. And, perhaps, even people who like its particular syntax (though not, I would bet good money, a single user who hasn’t wiped out important data by forgetting to use
$set in an update call). While I’m tentatively willing to accept both of these hypotheses, after a year of working with Mongo, I would trade it in a heartbeat for a database that can do joins.