Develop for the next billion users

The next Billion users

The next billion users will be on low-end devices, in regions where there is barely internet or even electricity. But even today there are people in your neighbourhood that have old computers, low-end notebooks, low-end smartphones. Another issue is data, mobile data is expensive. In Africa there are regions where people come together at antennas and generators to connect and charge. People don’t need your new shiny update if it only tweaks the UI and adds a lame feature, it’s too expensive.

In that same population are a lot of people that would benefit from having an identity on a blockchain. But we don’t reach them because our apps are too fat, too many files, too much JavaScript, too many network calls, too much online.

In the beginning there was HTML5 & Friends

I started during the HTML5 period and have been a fan since the first hour. I got even better HTML/CSS/JS super powers with all the new Web API's. I was very against apps as they keep you confined to the same walled garden as Yahoo or MSN at the time, and I believe in a free and open Web. So for me Apps are Evil and I shout it from my soapbox to everybody.

Getting the opportunity at a customer to study HML5/CSS3/Web APIs for 9 months, writing POCs, docs, migrations, presentations, tutorials, best practices, I became the HTML5 dude from the company.

Around the same time a few interesting Methodologies came up:

• Mobile First
• Progressive enhancement

Luke Wroblewski already mentioned the upcoming markets of mobile and low-end devices.

Some of my experience

A few years later I became a lead and tech lead at a bank with a major digital transformation. The team grew to 27 people, remote, near-shore(europe), off-shore(india). I learned to manage large teams and on-boarding, coaching and all that. By the time our new banking app was running smooth we already were looking at Web Components but due to the Angular.js investment we were stuck at the time and forced to continue with Angular.

A few years later I joined another bank to do the same setup. Only, they were even worse and stuck with YUI & Angular.js. So we started experimenting with Vanilla Web Components, making them work in IE11, which worked. But using them in the apps was a disaster because they made an Angular.Js patch with some custom created language which was a major overhead and the apps were not so fast. We started a side project with Vue to see how far we got there but were not able to build and integrate with the bank and had to run it in AWS. Anyway a big rewrite was needed to enter this new era.

• In the opinionated way(angular) you can have an easy on-boarding. The docs are written, everybody can just follow but with a steep curve to learn. And that’s all good for simple apps that you can off-shore. The moment you want/need to leave the path or have a very heavy application with other integrations you are going down the rabbit hole.
• Un-opinionated way(react) you can do what you want, you can use what you want. But it will cost you time in every sprint to maintain dependencies, to figure out what libs to use. Writing down everything in docs so your on-boarding goes smooth. On-boarding is also another issue because of the many choices, you have a lot of docs and because of the high pace of change those docs go out of sync

Present

Today I lead a smaller team of 4-7, and we have users I never worked for before. Our customers are farmers, and not only in Europe but also in Africa, Asia, South-America. Our users have low level devices and small mobile data plans. We had customers in Germany that had a lot of animals but when they opened the app twice to get all their data their data plan was done for the month.

Not only do they have low-end devices but also a crappy network. In most farms the connection drops when inside a stable. There are still a lot of rural areas here in Europe and the US where connections are still bad. There are users that can’t update their mobile apps because the data plan can’t handle that, the downloads are too big.

We started making a design system with React and Storybook in an Atomic Design way of work, and I can recommend Atomic Design. It does take some thinking up front but later on you can build faster. Later, we did remove Storybook due to the overhead and updates. We try to keep our Atoms as functional as possible. We ditched Typescript too, after our Angular-NGXS/Ionic experience, we had issues with all the libs we use the types we have to manage and more.

Last summer I started looking into the design patterns again and also found out about the Actor Model. This lead me to the great work of Dasurma, Dasurma and Paul Lewis have a presentation about this pattern. But more importantly, I learned about “Off the Thread”.
The idea is that you use the single thread there is in JavaScript as a mediator which will only be used for the UI. All other things should be shipped to web workers.

Meeting Blockstack

A DApp is an application that is built with at least 1 or more decentralized parts. In this case W3bCollections is build with a decentralized Authentication and Storage system.

Since last summer I re-discovered Blockstack during JSCamp in Barcelona (a must been JavaScript conference imo). I built my first DApp, published it into their store without any cost and even earned some BTC & STX. W3bCollections.com, a decentralized application with authentication and encrypted data storage where the user wants. Developing with Blockstack was a breeze, it has encrypted storage, you as a user are in control of your account, your data and your privacy. You can host a Gaia storage hub in you Google Drive or Dropbox and no more data breaches.

Before the Blockstack experience I always had choice issues, which framework, which test library, which code style, promises, streams, state manager, CSS, CSS in JS, you probably know what I mean. During the Blockstack hackathon I threw it all aside and just took the basic create-react-app and only cared about writing features and wrote some very dirty code. In 10 nights I wrote the app with the basic features I wanted and was in time to qualify for the contest. I have to admit that although the code was a mess it did what I wanted and I really had fun and spent nights coding again.

Recently I bought a yellow Nokia Banana to be able to test and experience what some of our customers experience. And with the web worker story, I needed a device to test that as well.
But I also tested my Animal-Kingdom DApp and it didn’t load on my Nokia and timed out. Encryption can be the possible cause, but “We don’t reach those people” was my first thought.
And full disclosure: I’m a Blockstack evangelist.

The goal

After all these experiences I started to look into rewriting W3bCollections and started to think about what the real goal is that we have to achieve.

• Does it have to be so complicated? We want to get stored data and present it in a browser, it should react to interaction of the user and we want to manage some state.
• By what are we constrained? CPU, RAM, Storage, Network.
• Do we really need to rewrite our apps every 3-5 years?
• Do I really want to invest in a walled garden, and pick a framework again?
• When we have less JS can’t we just directly load everything with script tags again, instead of relying on build processes?
• Do I really want/need to manage/track each state change in the UI or only the one I care for?
• Can’t I just use Node scripts if I need something to be done, instead of managing Webpack?
• Can’t I use IDE snippets instead of scaffolding or cloning or forking?
• Do I really need Types, Or can I rely on unit tests as “Uncle Bob” said?
• Do I need all the packages? Would I spend more or less time with managing my own code vs updating packages?

The almost perfect web app

For example a bank app, when I want to look at my account on my nokia with WAP. I should get a green screen with black numbers. But when our web app detects that the browser supports better, we could show off all our HTML5/CSS3 tricks to make it a pleasant experience. But even better we could detect that the browser supports WebXR so now we could generate a virtual bank where you could walk around.

• To accomplish this we should write our code layered this will make our app Gracefully Enhance.
  • HTML4
  • then CSS
  • then ES5,
  • then HTML5
  • then CSS3
  • then ES6++
  • ...
• The app must be designed Mobile First
• The app must be designed Offline First
• The app must be designed with Atomic Design in mind
• That app should be built with an Authentication system on a blockchain owned by the users.
• Data should be end-to-end encrypted and stored in a by the user provided location.
• WebAuthn support for credential creation and assertion using a U2F Token, like those provided by Yubico and Feitian,
• Web apps should be PWA’s and be offline capable and provide basic service. If I’m offline I still want to manage and view my account, and do transactions which will be processed when back online.
• The use of Web Components should make portability and integration a lot better, now and in the future.
• Use Web Workers to create an unblocked UI thread
• Use design patterns, Singleton, Pub/Sub, Observer, Mediator they are not that hard to write yourself.
• When choosing between 2 options take the one that makes it possible to extend later
• Reduce the bytes over the wire, loose all the libraries and frameworks.
• Accessibility is non-optional, WCAG, WAI, ARIA are needed to deliver an inclusive web, where the impaired and elders can access all content.
• Avoid Battery drain

We have the tools to kill mobile apps, reduce JS and be inclusive. I know it’s a lot but I started with an index.html some good old script tags and started with Web Components. I use the Singleton and Observer pattern for State management you can login with Blockstack. I have views and a landing page and it’s responsive. You can find this first attempt at https://github.com/webwizart/w3bApp. Any feedback is welcome and we will see where we get with this.

Future Web 3.0

Web 2.0 was a time of discovery for the rich and famous to post food dishes and duck faces.

Web 3.0 is for the people to learn and be educated, for those who want to start a business. For the people that have no identity, are blind, can’t read, can’t hear, can’t speak, that are suppressed.

To be available everywhere on earth on any device for everybody.
Let’s talk about it

This was a more detailed follow up on my previous post at Blockstack
https://forum.blockstack.org/t/develop-for-the-next-billion-users/9837