“Peak Framework” and the runtime barrier: why libraries and frameworks are exhausted

The software industry has reached “Peak Framework”. Buildtime is where the action is today. But do we have the right abstractions?

Do you know the “Hubbert peak”? Originally applied to oil production, it is an observation that the production of a natural resource tends to follow a bell-shaped curve. There is an initial phase of exponential growth when the easily accessible resources are discovered and exploited, but then the rate of discovery inevitably falls and a peak is reached.

Well, the software development industry has its own Hubbert-like curves. Around 2009, we had “Peak Dynamic Language”. With the rise of the web, new dynamic programming languages like Ruby and PHP had seen explosive growth. There was widespread enthusiasm surrounding the rapid development practices enabled by flexible typing and the ability to “monkey-patch” everything at runtime. This enthusiasm peaked when web applications grew larger and the runtime unpredictability of dynamic languages became more of a problem. After the peak, static languages have enjoyed a strong resurgence.

Now in 2017, we are facing “Peak Framework”. The past ten years have seen an amazing explosion of libraries and frameworks for the web platform. This trend originally got started by clever approaches to patch over painful discrepancies and incompatibilities between browsers, but soon turned towards complete application frameworks like Angular that aim to provide a runtime solution to everything that’s wrong with the web.

This approach is peaking because developers are starting to realize that there is a fundamental limit to what can be done by adding new software layers into the runtime environment. Frameworks come with two high costs. The first is technical. Each dependency adds to your application’s startup time and footprint. A typical web app developed with one of these “kitchen sink” frameworks will load several megabytes before it loads a single line of code that is actually about your app. This is bearable today (if you’re on a computer and a fast Internet connection), but the frameworks can’t grow any bigger — nobody is going to wait for a 50 MB framework to load into a browser.

The second cost is mental. Web frameworks are complex, yet there is tremendous churn. Developers had barely familiarized themselves with Angular when Google announced that Angular 2.0 would take a different approach and would not be code-compatible. How much time are web developers spending on researching and learning new frameworks versus working on their actual projects? Sometimes it seems the balance has tilted towards the former, and that’s not healthy. Carpenters don’t spend most of their time reading about drills and lathes.

That analogy brings us to another important point, namely that software development today still largely operates like a mom-and-pop woodwork shop, even inside large corporations. Someone brings you a design on a napkin (a PSD, a Sketch file, a Zeplin styleguide, whatever — it’s still a napkin!)… And then you get to work, tinkering with your manually operated tools and artisanally feeling your way while sometimes glancing at the napkin to remind you what you’re supposed to be making.

It goes without saying that this is not how most physical products get made in the real world. Hand-crafted objects are an expensive luxury. Ordinary mass-market products are made using CAD tools and rigorous industrial methods. Yet we have none of that in the software world. Every app gets built like a Swiss watch or a Hermès leather bag, but not every software developer is a master watchmaker… And so we have an industry that faces both serious quality issues and demand that greatly exceeds supply. Maybe it’s time to do something about it?

The runtime barrier

The essence of the “runtime barrier” is that adding more layers of software into the runtime environment is like adding more tools into the woodworker’s shack. There is a limit of decreasing utility to new and increasingly complex tools at that level of operation. You could give the carpenter a million-dollar 3D printer, but it won’t improve his work because his method of working can’t accommodate it.

That’s why the focus of interest in software development is switching from runtime to buildtime. It’s the same kind of transition as the one that happened after “Peak Dynamic Language”: runtime complexity has become too unpredictable, and we want to catch more errors earlier while also reducing memory footprint. In the web world, this has converged around tools like Webpack and Babel. Ten years ago, web front-ends typically did not have build chains worth mentioning. Today, a modern web app’s build setup takes hundreds of megabytes (e.g. an empty project brought up using Facebook’s “create-react-app”), and this often includes a compiler for an entire programming language (Babel’s latest JS, TypeScript, etc.)

So, buildtime is where the action is today. To continue the previous analogy, we are in the process of switching from woodwork shops to factories… There is one curious thing about these new factories, however. Their output is configured and controlled using the same kind of tools as in the previous “shop” phase: command-line tools, plain-text source code files, text editors.

Is this the right level of abstraction to control a factory? Would Foxconn be able to operate if their manufacturing processes were managed by the same tools as “Jimmy’s Wood Shop”?

Maybe the modern build tools could be different, something beyond text files and terminal commands. We could learn a few tricks from those real world factories and their tool chains. What if your software development process had the equivalent of CAD design tools and their ability to directly interface with physical manufacturing (CAM)? What if you could encapsulate custom functionality in a way that follows factory-style modular thinking (rather than the hazardous “edit any text file” approach of code shops)? What if you could replace core libraries of your app without touching every source code file, similar to how car manufacturers can swap out engines and other components for different models while still using a single cost-effective base?

With React Studio, we want to bring those benefits into modern web app development. It’s the CAD tool to let you build your software factory, and it’s launching today as version 1.0.

Read more about our approach here: Meet the Design Compiler

The modern web is a complex platform, and innovating in build tools is really hard. So we fully realize that we’re not fully there yet, even though large parts of the vision are implemented and working today. If you are interested in the direction we’re taking, why not sign up [link] and engage in our Slack channel or private conversations! With your feedback, we can hope to build something that makes your work easier and better in the future.

By the way, we did not start from nothing with React Studio. We’ve been successfully piloting the “design compiler” build tool approach for two years with Neonto Native Studio, a product that uses the same core to construct truly native (“frameworkless”) projects for iOS and Android. It’s being used to produce hundreds of native apps already. If your interests are more in the native mobile space, check it out!