Building Apps in a Document Centric World
During my SCUBA certification, I recall one of the instructors commenting that “we aren’t meant to be down there, doing this”. His point was, that, we rely heavily on technology to do things in an environment that was never intended to be hospitable to humans. The technology that allows us to survive and operate under water has evolved and gotten more advanced over the years, and will probably continue to do so as we find new and interesting ways to push the limits of what humans want to do under water. None of that changes the fact that when we’re under water, we’re operating in an environment that we’ve had to overcome with technology, not in a place we belong.
This is analogous to how I see the web. The web was built around the idea of sharing documents and creating links between them. HTML and the browsers that render it were built around the idea of text documents. While browsers have changed quite a bit over the years, we’re still building everything that goes on the web on top of the same, document centric foundation that was originally built to support documents.
Imagine if instead of building robust, native, desktop software, we were all forced to build applications as Word docs, adding interactivity and business logic with macros. With each new release of Word, we might get some new capabilities in our macros, but assume our docs have to continue to support old versions of word. We also can never break old docs, so imagine that problematic features could never be removed from Word. That’s a little bit like building applications on the web.
Now, before you get all defensive and attack me for shitting on the web, keep in mind that I have built a 20 year long career, building things for the web. It’s amazing how far we’ve come and how powerful the tools are today in comparison to the landscape that existed when I started. But, just because I’m excited about how far things have come, doesn’t mean I think it’s as good as it could be.
I can’t help but think back to my Flash days. I’m not advocating that we try to bring back Flash, but there was something special about building things with some guarantees about the runtime, and being in an environment that was not built with text-only documents in mind. To me, Flash was the right model for building applications for distribution on the web.
Again, I’m not trying to bring Flash back, or to relive my glory years (that’s not how I would label those years). Would a real application platform with the reach of the web be better? It sure as shit would! But that’s just not the reality we live in and for better or worse, we need to meet our customers where they are.
So what is the point of all this? Well, this all came out of a discussion where there seems to be an opinion in some places that “code is code” and developers can just be full stack, under any circumstances. It came out of my thoughts on how to properly challenge this view. It’s to illustrate the, sometimes bizarre, nature of frontend application development and to explain where the need for specialization comes from.
We’ve covered the whole “apps living in a document world” thing, but I wanted to also break down some of the unique challenges faced by frontend developers.
Uncontrolled Environment
I eluded to this a bit with my tangent on Flash, but one of the major challenges faced on the front end is that you have no control over where your code is executed. Various browsers and their versions can vary wildly in how (or if) they support specific language features. You have to contend with bugs that are specific to one vendor’s browser, at a specific version. This is getting better with “evergreen” browsers, but the issue of differences between vendors will likely always exist.
Beyond the implementation/support issue, we also have to contend with varied network speeds. Some customers will have slower networks in general based on geography and varying levels of investment in infrastructure for a region. It goes further than geography though, with the ubiquity of smart phone usage, even in places with solid infrastructure, a single customer can experience wildly different network speeds, including complete lack of connectivity, over time. Connectivity and the speed of that connection can even vary within the span of a single session with your app.
Speaking of mobile usage, this introduced some additional challenges. The first being device speed. There are a staggering number of devices out in the world. Many people may be using older devices or devices in a lower price point than those of most developers. This means code that runs just fine on a developer’s laptop, or the latest iPhone may be sluggish, janky, or even entirely unusable on a customer’s phone or tablet.
Couple a slow/unstable connection with an under powered device and your bloated bundle running a shitload of inefficient operations is going to create a horrible, frustrating experience, possibly chew up data, costing additional money for the customer, drain their battery, and just generally suck ass to use.
The last issue I’ll address (for now) related to the runtime host for your code is form factor. All the devices on the market mean you need to consider everything from ultra-wide monitors to small phones. Accounting for large phones and tablets, all in either landscape or portrait. This is all workable, but it requires a lot of consideration and coordination between product leadership, designers, and developers involved in implementing the application’s front end.
Unique Language Challenges
In addition to the challenges brought about by an uncontrollable runtime, browsers support HTML, CSS, and JavaScript.
For now, I’ll focus on JavaScript because I think this might be where ideas like “it’s all code” come from. I assume this because the JavaScript code is the easiest place for the uninitiated to squint and see major similarities to languages common on the server, like Java.
JavaScript is an interesting language. It has evolved over the years, but it certainly has its share of warts and since we “can’t break the web”, many of the oddities that may not be ideal, linger in the language so old websites that rely on the oddities will continue to work. It’s a weakly typed and a dynamically typed language. That combination can be quite powerful, but is also a source of confusion and errors. JavaScript is also multi-paradigm, it combines aspects of OOP and functional programming. It looks a lot like C, Java, and C# and it even has “Java” right in its name, but both the naming and syntax similarities were largely about marketing. JavaScript is an implementation of ECMAScript and has nothing to do with Java.
JavaScript is single threaded and runs in an event loop, meaning most significant code ends up having to run asynchronously via APIs provided by the runtime (browser, Node/V8, etc.). Async code can be confusing and make following the flow of code difficult for developers who aren’t used to a mostly async flow.
Ever evolving
The web is constantly changing. As browsers add features and languages evolve, new tools, techniques, and frameworks are introduced to keep up and solve the latest set of challenges. The move to robust, single-page-applications is fairly recent and there is rapid innovation happening across the ecosystem. This means there can be a great deal of churn, new information to absorb, decisions to be made about what to adopt, what to ignore, and what to monitor for future consideration. This rapid innovation is great for progress but it’s also something that requires work, diligence, and constant attention to keep up with.
This is not about using the latest, cutting edge technology just because it’s new and “shiny”. It’s about taking advantage of advances in the platform and surrounding ecosystem to deliver better experiences for customer. It’s about making products that meet the high expectations of today’s tech-savvy customers.
Understanding and being able to fold that understanding into the development of a product requires specialization.
Frontend development, like developing for other platforms, isn’t about typing code. It’s about solving problems. Once you understand what problem you are solving, then it’s about knowing the right tools and techniques needed to solve the problem in the most efficient and impactful way.
With all the factors to take into account, it’s hard to argue against the need for talented developers with the depth of knowledge and the desire to embrace the constraints presented by the web.
Today, more than ever, there is a need to specialize in the front end in order to compete in the world of web based applications.