Why learn Reach when you know X?

by Dr. Jay McCarthy, Reach CTO

If you have already learned an existing DApp development system, like Solidity, PyTEAL, or Rust, you may be wary of “starting from scratch” and using an environment like Reach.

If you have already built a demo, MVP, or product, you may be wary of throwing away that work and starting from scratch after you learn Reach. Perhaps you spent six months getting used to your current toolset, then spent the last six months building your MVP, and you don’t believe you have another year to do it again with Reach.

We believe that…

1. Learning Reach will be faster than you think;
2. Building and evolving your product with Reach will be faster than you think; and,
3. Your product will be better with Reach.

Learning Reach is Fast

We’ve cataloged about half-a-dozen teams that have learned Reach on Friday and won a hackathon on Sunday with real code that really ran. We’ve cataloged about half-a-dozen teams that have learned Reach in a few sprints and built their MVP right afterwards. We offer a training curriculum that will bring you and your team to this level in weeks, not months.

This is possible primarily because of the following three reasons:

First, Reach is syntactically identical to JavaScript and seamlessly fits into a JavaScript development environment. The computational part of Reach is literally JavaScript, and the blockchain part is a few “weird” libraries that are no more difficult to understand and use than the latest database tool. After you compile your Reach program, the Reach JavaScript standard library imposes no additional constraints on how your developers work.

Second, Reach abstracts the difficult things about the underlying blockchain, like method signatures, transaction types, state management, and atomicity. Instead, Reach presents a comprehensive abstraction about what a DApp is that is easy for all developers to grasp yet powerful enough to build anything from atomic swaps & auctions to AMMs & stablecoins.

Third, Reach has a wide variety of curriculum and resources for learners, from several self-paced tutorials, comprehensive reference materials, and cohort-based training, to a vibrant Discord and GitHub Discussions community of people working together to learn and improve.

Building with Reach is Fast and Agile

We’ve done a case study where we found that building a serious blockchain application — a stablecoin — took about 15% of the time and resources using Reach compared to building with Solidity. This same team drastically modified the structure of their application halfway through development and finished the transition in a single week.

These results are not just because Reach is easier to learn but also because Reach solves many of the main challenges of blockchain development as part of its structure and keeps them solved through changes to your product requirements, whether those changes happen during development or are planned for version 2.0.

We’ll use three concrete examples of this to illustrate this point:

First, imagine you initially design your program to handle fees in the network token (i.e. ETH or ALGO), but then change your mind so that you instead want to accept payment in a non-network token (like USDC). If you were using a low-level programming language, like Solidity or PyTEAL, you’d have to make large changes to your program. On Ethereum, you’d have to introduce client-side multi-step actions to have users give your contract an allowance, then have your contract check it by using safe external contract calls. On Algorand, you’d have to have your application opt-in to the ASA, then you’d have to change `pay` txns into `axfer` txns, and you’d have to remember to close out the ASA balance at the end of the program. Yet, in Reach, a change like this is changing `amount` into `[ amount, USDC ]`, and Reach handles the rest.

Second, imagine you initially designed your program so that each instance of the program was its own separate contract, but now you want to change it, so there’s just a single contract, and all uses are represented as data in that contract’s memory. On Ethereum, you’d introduce a `mapping` data structure and have to learn about how to detect if a mapping existed, how to destroy one, and how to separate out your protocol state from the instance state. On Algorand, you’d learn about “local storage,” deal with users opting in and out of that, and change your clients so that they correctly provided access to the right local storage keys. Then, in late 2022, when Algorand introduces “box storage,” you’ll have to rewrite it all to use the newer, more efficient, and user-friendly version of this functionality. Yet, in Reach, a change like this is as easy as `new Map( InstanceData )`, and Reach handles the rest.

Third, suppose you are building on Algorand, and your program will call another contract if a certain value exceeds 5 after a transaction, but otherwise won’t. If you don’t use Reach, you need to learn about ARC-4 ABI calling conventions and inner transactions, and then ensure that the inner transaction fees are adequately paid for… but only when the value is greater than 5, so you’ll have make your clients do a local simulation of the contract’s effects to be able to detect when the remote call will happen, or else you’ll have to always charge every client for the call that only some will make. Yet, in Reach, you implement this by rewriting `remote(contract, interface).method(args)`, and Reach handles the rest.

Reach-based Products are Better

When you build your product with Reach, your code will automatically follow the safest and best practices of blockchain development, and as those standards evolve and progress, your code base will automatically be pulled forward as well. Reach makes it so the “right way” is the “default way” and, in some cases, the “only way.”

Here are three examples of how Reach-based products are safer and better:

First, every Reach program is formally verified to obey some general safety properties that all blockchain programs should have. For example, Reach guarantees that array bounds are always respected and that all attempts to pay funds are valid given the balances of the contract’s account. These guarantees are part of the compilation process and hold for all program executions without the need to test because they are based on the program's logical structure.

Second, Reach uses translation validation-based compilation-output verification to ensure that the bytecode it produces does not have categories of errors that are common in hand-written programs. For example, Reach ensures that the state-flow diagram is respected by the actual code, that the type-based assumptions of the user program are enforced by the compiled program, and that high-risk transaction parameters (like `OnCompletion` on Algorand) are checked by all control flows.

Third, Reach’s client-side library builds in best practices to protect your end-users. For example, Reach frontends will always verify that external contracts they connect to are running (and were always running) the expected bytecode, that locally checkable exceptions are performed locally before paying the consensus network to check them, and to implement client-side rollback on non-atomic actions.

You Should Learn and Use Reach

We hope this article has given you a glimpse at what Reach has to offer your team, even if you’re already familiar with another blockchain development platform and have already built a first draft or version of your product. The examples we’ve highlighted are just the tip of the iceberg.

We invite you to come and see what we provide by visiting our site or attending one of our training programs. We invite you to come and let us help you improve your product for your developers and users. We are sure that you will come and stay and help us bring the vision of blockchain to the world.

Remember: The future of blockchain is in Reach!

For more information, follow us on Twitter.