A Developer’s Blockchain

Progressive Cycles

The technology field has always operated in progressive cycles. Cyclical because it seems any new technology follows a pattern similar to previous technology, and “progressive” because each cycle informs the next, always moving forward. In this moment in history it seems that these cycles are happening faster each year.

If you’re not familiar, in this model there are “innovators” who start building things, “early adopters” who are excited before most people catch on, “early majority” who are getting involved right before peak adoption, “late majority” who are jumping on the bandwagon, and finally ”laggards” those who are begrudgingly forced to use the technology when it’s ubiquitous. Blockchain is no exception.

Currently, blockchain is in the hands of innovators. Right now, the innovators who decide whether technology takes over the world or fizzles into non-existence are programmers. Even as painful as it has been, there are programmers willing to build things anyways. This might be evidence that blockchain is at least important. It reminds me of the story of people willing to learn and write assembly code in order to program early computers, just because it was cool to them. Or even more like getting on the internet in the early days of web 1.0. Of course, there are those who believe it’s entirely hype!

The higher the barrier to entry, the more compelling (or hyped) the technology must be for people to give it a shot. Even so, for something to take off, that barrier eventually needs to come down. That’s what we’re doing at NEAR: lowering the barrier for developers to enter the blockchain space.

How to lower the barrier to entry

Every time it comes up in discussions, meetups or panels in the blockchain space, people are starkly aware that the current development experience is as unpleasant as the user experience. We’ll dig into each piece of the puzzle in more detail below. The most important first step is starting by removing unnecessary barriers.

The first interaction developing on blockchain should be pleasant, so we created a full feature online IDE. This allows people to run and deploy with one click and, importantly, it looks a lot like VS Code. Using just the online IDE, you can build an entire blockchain app from templates that give examples of the core functionality. A lot of the time, people end up spending more time on their frontends since the contracts are so simple to write.

Once someone is familiar with the general structure of the project, it makes sense if they can be quickly productive. That’s why our smart contracts are written in TypeScript. It’s approachable if someone comes from the ever growing JavaScript ecosystem or if they’re already familiar with another typed language.

Both the IDE and the choice to use TypeScript as the contract language removed the unnecessary barrier of unfamiliarity. There is no need to add complicated things to an already complicated concept. We want the cognitive load to be as small as possible when someone is starting out.

We’ve solved other problems as well and it started with a discussion of what problems we need to solve to keep lowering this barrier. It’s worth touring what it takes to build anything today.

The development lifecycle

There is one very necessary piece that needs to fall into place for the ecosystem to explode into the future where it takes over the world: the very basics of how apps are built should be available to developers who want to build on blockchain.

Currently the cycle of building a web 2.0 app looks something like this:

• Prototype
• User testing & verification
• Robust version
• Deployment
• Support & Maintenance
• Updating & Version management

How web 2.0 apps are built today in practice

Let’s start with a silly theoretical use case: Uber for dogs.

Say I’ve got a dog and I want to send them over to my friend’s house in a safe way. I suspect that other people feel the same, so I sit down at my favorite terminal, pull up my favorite IDE, and get cracking on the new industry standard serverless architecture with a completely separate frontend built in the server-side rendered frontend library of the day.

I’m feeling good, I’m hitting all the buzzwords in my npm packages. I have something ready to go in a day that allows a user to select a location on a map, and request a ride for their dog! I use one of the many quick-deploy options to get an obscure link to my running app. Great!

Now I’ve got the first round of validation. I need to build a more serious and stable version of the app. I take a couple weeks to figure out features, get some designs and flows down, and build my masterpiece: Ruff Riders, the premier app for dog sharing. Great!

In fact, each of the steps we’ve covered before have a robust solution and community support behind them. The point is, the process of creating and eventually maintaining any basic app that operates on entities in a database is extremely well explored now.

If you run into a problem in implementation, there is a Stack Overflow thread with copy and paste-able code. If you are trying to solve a problem with your deploy process, there is the whole field of DevOps to pull from and tons of resources and tools to help you. That’s the developer experience of building web 2.0.

How web 3.0 apps are built today

Round two in the developer experience (blockchain edition): Voting for dogs! Let’s imagine what it takes to get something up and running as a viable app.

I look at my auburn-haired Pomeranian, Teddy, and want to empower him to participate in the great utopian republic I envision. I suspect others feel the same way, so I sit down at my terminal and install… Wait. What package do I install for blockchain? I google search “how to program blockchain app.” The whole first page is taken up my paid results for “HyperLedger fabric” and Cornell’s online course… Okay… I click a blog post that looks legit. “How to build a distributed voting app” That’s exactly what I want to do! Great?

As I’m reading the blog post and it turns out I’ll need to learn a new programming language in order to start building. Hmmm. Not so great. I install some CLI tool that simulates a blockchain locally so that I can at least get started. I run it and it outputs a bunch of crazy looking strings to my terminal that all start with “0x.” Hmmm.

It takes a few days to figure all this out, but finally have a local version of the thing! I want to see if my Grandma’s dog Trinkles will participate in this beautiful future of empowered dogs. How do I do a quick deploy? I just have a prototype I want Trinkles to try.

I take a few hours to figure out how to deploy this to a “testnet” (by the way, what’s a testnet?) using new tools, like a browser extension based wallet. Wait, I was building an app. Why use a browser extension to choose configuration? I send the link to the frontend tying into my “smart contract” to my Grandma.

She calls.

“I think dogs should vote too! Trinkles wants to try the app you made,” she says.

“Great Grandma! I knew you would. It’s simple: first go to this website and install a browser-extension. That’s vital to the functioning of the app. Once you create an account, write down 12 words. Don’t lose these words Grandma. These are important words.” I say.

“Why are they..” she starts.

“I’m not done Grandma!” I interrupt, “then go to this thing called a faucet, where these things called tokens, are deposited into that thing you just installed in your browser called a wallet. That’s just for the testnet though, Grandma.”

“Now can I use your app?” she asks, timidly.

“No grandma. To use the fully functioning app, you should go on the main net and get an account on an exchange. All you have to do is sign up with an email and password, then verify your phone number, then attach your bank account, then wait a few days. While your waiting, you should verify your identity with a passport or driver’s license. Then you should pay real money to use the app. Buy some coins and HODL GRANDMA!” foam is dripping from my mouth as I finish.

“Why do I need to…” She starts.

“Bye Grandma, love you!” I hang up.

Grandma is having trouble using some of the basic parts of this thing to work. Not so great! I decide to fix some of the performance issues with the current best blockchain. I grow a beard and move to Hong Kong. All my money is now alt coins. Voting for dogs will have to wait.

(If you want to read more on our take on end-user blockchain useability, check this out)

We need to fix this for people to build real things

Exaggerations and joking aside, this is not too far off from my real experience building my first blockchain application. There were so many hurdles to overcome, the idea of a smooth ”code to deploy” process seemed ridiculous. Blockchain developers have learned all these tools and quirks and because of that, some of these crazy hiccups in getting real products shipped have become normalized. Mixed metaphors like ”a faucet” that flows “tokens” into a ”wallet” are unironically bandied as “the way it’s done.” What the hell are we even talking about?

I’m not advocating for changing terminology drastically, but it’s clear there are huge needs to be met for programmers who aren’t familiar with blockchain to be able to build any apps (let alone ones their grandma could use.) In the case of building tools, we don’t even need to get that creative. A good starting point is just emulating the great push for better developer tools in the web development ecosystem in the last ten years. When there is something like Ruby on Rails equivalent for Blockchain, there will be a huge influx of blockchain developers.

Remember, In a nutshell, these are the steps of developing Web 2.0 today.

• Prototype
• User testing & verification
• Robust version
• Deployment
• Support & Maintenance
• Updating & Version management

I’d add one more to this for blockchain specifically:

• Integration into existing systems

Each of the steps of developing an app needs to be addressed. You can almost think of addressing each one as a unit test. Once all tests pass, then we are green on developer experience!

It should be easy to prototype and test.

We’re developing both an IDE and a CLI tool that each allow people to very quickly onboard without needing to learn a new language. Our contracts are written using TypeScript and integrates with a front end library that you can pull in from npm.

It should be smooth to do a quick deploy to test with friends to validate. 

We’re trying to solve this by hosting deploys at unique links. You can deploy from the online IDE with one click, or use one command to deploy from the CLI. Imagine heroku for blockchain. Or any other platform as a service.

It should not require a bunch of tangential steps to get your first users. 

Having end users download a browser extension and then go to a third party site to fund it leads to huge drops in conversion rate. This is a huge missed opportunity since blockchain could lead to a complete single sign on experience for users who are already familiar to them. We have a hosted wallet as a proof of concept for this. Whether we make it or not, there will be a wallet app that most people will use when blockchain becomes ubiquitous. it makes sense for this to be the main way accounts are handled.

It should be possible to build a version that is more robust

This requirement is relatively straightforward to define: for more than 10k users the system will stay up and be able to meet performance requirements. This is accomplished with proof of stake and sharding. This seems to be the direction most blockchains are headed and our team has built sharding in a regular database context before. That being said, this problem is still unsolved.

It should be as easy to version and maintain as maintaining an API.

This is also a yet unsolved problem. As more developers enter the space, the applications they create will grow and become more complex. People will solve their own problems and this will fill in the foundation of maintenance and versioning. I’ve got ideas about how versioning and maintenance should look, but I’m more excited for what people come up with to create even more efficient pipelines and deploy processes. Configuration objects with meta-information you can pass on deploy are just the start.

It should be easy to integrate with existing products and workflows

It’s happening already: existing teams and even big companies are looking longingly towards the bleeding edge that is blockchain. There is some defensiveness towards this, probably because people are worried about stuffy institutions. Maybe deeper is a fear that the newcomers are going to take away our warm fuzzy secret that makes us feel cool. I think it’s time to let them in. The more people that enter the space right now, the better tools get, the better ideas get, and more interesting projects get started.

More programmers, more projects, more pleasant experiences!

Hitting each of these points listed above will be vital to the survival of the ecosystem. At the end of the day, a good developer experience allows programmers to create a good user experience. There is going to be a moment in the future when someone’s grandma sends birthday money through a crypto wallet; not because it’s crypto or because it’s cool. They will do it because a developer was able to build an experience that was better than anything else out there. That’s the kind of watershed moment that blockchain needs to succeed.

If you’re interested in building the future of usability on blockchain, you should check out our online IDE at https://near.dev and consider contributing to our Github. Everything we develop is completely open source, including the design process, you can participate in our discord at https://near.chat.

https://upscri.be/633436/