Seeking the One True Framework. Part 1

Featuring: the Actual Truth About Frameworks (because of course)

This post will go live on the Fadroma Frontlines blog over at Medium tomorrow morning. But readers of our blog get early access 😉

Hello again! This is our second post about Fadroma, our open source toolkit for smart contract development on CosmWasm-based blockchains. (If you’ve missed the first one, you can find it here; it contains an overview of the topics that these posts will discuss.)

As we speak, our fleet of magical Cosmic flying bulldozers is happily bulldozing through a pile of transitive dependencies that turned out to be incompatible with the improved ECMAScript Modules standard. (That’s standard, folks!)

If the above sentence means anything to you, expect the upcoming Issue 1 of our news bulletin for more news on how all the bulldozing is going. Over there, we’ll report our progress on the tactical level, in the sort of excruciating detail that it inevitably takes to identify the true way forward for the decentralized ecosystem.

Over here, the subject matter is going to be more high-level, the tone more casual, and the illustrations perhaps a bit more calming. So how about we leave the bulldozing to the bulldozers — let’s get to talking about them frameworks.

---

Frameworks… well they’re a funny thing, aren’t they.

Proponents consider application frameworks to be indispensable scaffolding for structuring the backbone of applications. A tried and tested architecture, plus a nice starter project that resolves the “fear of the blank page” and provides the quickest path to building features… what’s not to like?

Detractors find frameworks a burden that gets in the way of learning the underlying platform, and obfuscates the most direct solution to any given problem; thus turning away developers from their role as creative knowledge workers — and stunting the growth of entire tech ecosystems by preventing builders from seeing what truly could be.

These competing perspectives create grounds for what among us devs passes as politics. Something that we’d all like to put in the past, and resolve disagreements fairly through code and protocols. But that’s the future that we strive towards — in the present, things are slightly more nuanced.

The actual truth about frameworks, in our view, is quite simple:

When a language is deficient in expressivity, or an API becomes too complex and unruly, frameworks step in to bridge the resulting gap.

---

Frameworks do their thing at the cost of placing further layers of middleware between the mind of the programmer and the machine that runs the code.

Some would say that the layers are already too many, and this has been the case for way too long already. But hey, whatever gets the job done, right?

No matter where you stand on the framework debate, implementing business logic in terms of a framework’s enhanced primitives (rather than purely in terms of the underlying programming language and core platform APIs) inevitably introduces its own complexities.

Frameworks serve as a bridge over the existing gap between developer expectations and platform reality — but they also expand that gap ever so slightly by implicitly imposing their “one size fits all” approach.

Not even a paradox. Just a tradeoff

At times, framework-centric development can be at odds with the approach of using minimal tooling that solves particular problems and otherwise stays out of your way: as exemplified by the Unix philosophy that generations of battle-hardened developers swear by — and which the blockchain space, in our opinion, sorely lacks  (although CosmWasm itself has a delightfully minimal API that we find to mirror the Unix philosophy in subtle ways.)

New possibilities come hand in hand with new constraints, assumptions, and overhead. Maybe just little bits here and there — or, as is more often the case, a whole lot all at once. Either way, it adds up. It’s up to you and your team to decide whether any particular framework is worth it. If you jump on the first passing bandwagon, you might find yourself in the following painful situation…

Does any of the following sound familiar?

Your project, based on the shiny new framework that everyone is praising, is working great, looking all snazzy — until you hit a snag, and now nothing works. You find yourself stuck doing one or more of the following:

• trawling the Web for people with similar issues;
• waiting for responses on GitHub and StackOverflow;
• trying to figure out how to formulate your issue without having to walk people through your entire codebase;
• trying to figure out how to highlight the importance without getting shot down for sounding like you care a bit too much;

Eventually, you find yourself digging through the framework’s code to track down what exactly is the baroque edge case you just hit; maybe even realizing you would’ve been objectively better off writing some of the stuff yourself, rather than using a framework.

What do we do about it, then?

How to make sure the elegant CosmWasm platform doesn’t become a breeding ground for mutually incompatible frameworks and SDKs that thrive on false abstraction, bandwagon effect and lock-in? How to maintain a smooth development experience in accordance with that good ol’ principle of least surprise?

Well, how about a little more buildup, just to make sure we’re all on the same page here. We are getting to it 😉

Subscribe and stay tuned!

• In the meantime, we welcome your inquiries at hello@fadroma.tech.
• You can read more about our toolkit at https://fadroma.tech/ …
• …and, of course, you can try it out with npx @hackbg/fadroma@1.4.12 create, or by cloning the Fadroma Workshop repo (thanks to Lorenzo Giovenali for catching an issue there!) Should you encounter any problems, just ping us on GitHub — we’ll happily drop everything else and investigate 🙂