Even though Unlock, at its core, is a protocol to build a better business model for the web, I believe it cannot succeed if it does not provide a stellar experience to both creators and consumers. The fact that Unlock is a blockchain based protocol means that there are a few extra challenges to handle, but our goal is to build the best “unlocking” experience anyway.

Because of that, we’re focusing our early hires on software engineers who can help us build both that amazing experience and the architecture which will support it. For this reason, we are particularly looking for front end engineers.

Unfortunately, as we made progress and looked at applications and feedback from the candidates, we started to witness that front end software still has a stigma for a lot of software engineers as not being real engineering. It is time to end that myth.

Many still think that front end is not real engineering. It is time to end that myth.
At this point, any modern web application has probably more happening on the client (web browser) than it does on the server. That was certainly different 20 years ago, when most web applications were serving “static” HTML documents, but 2 trends have since then taken us to a very different place:

1. Most of the backend “platforms” have gotten infinitely more powerful. For example, when I started my career (early 2000s), sharding a MySQL database was pretty much considered cutting edge. Today, Google’s cloud platform offers what a lot of people consider to be the Grail with Cloud Spanner. While you had to design your whole web application around a database limitation, you can now build application which can (almost) completely ignore how the data is stored. Platforms like AWS, Azure or GCP, brought us transparent infinite file storage, managed queue servers, email services or auto-magic scaling, and now, services likes on-demand AI… I will go as far as saying that, unless you’re building some of the largest systems/APIs out there (hundreds of millions of users and more), you can go very very far with “out of the box(cloud!)” solutions.
2. The front-end constraints, requirements and usages have seen a Cambrian explosion. It started with Ajax, which, despite being a hack, paved the way for much smoother user interfaces (remember when each click meant a full page reload?). The mobile revolution of course made everything orders of magnitude more difficult: when most websites had to consider a dozen different resolutions, we now have dozens of aspect ratios alone! Mobile devices also took us a couple years back when it comes to available resources (CPU, memory and bandwidth) and added a new one: energy consumption. The web stack itself became incredibly more complex with half a dozen in browser data storage mechanisms (we started with cookies… only!), multiple streaming protocols, and of course a whole set of new JavaScript APIs. It’s no wonder why we have dedicate javaScript libraries to manage state alone. This means that, at least for me, the biggest impact that most engineering teams can have is on the front end, not on the backend. I’d even go as far as saying that a great front end experience can still make up for slow API requests, eventual consistency (have you tried reloading your FB home page twice?) or badly designed backend services… while there is no way a modern web application can recover from a sub-par front end layer.

Of course, the concept of a full stack engineer still has a great future, but we should also consider that, like always, context switching has a cost. One can be a great front end engineer and a great back end engineer in their career (after all, these are 2 facets of software engineering…), but I’d start to challenge the idea that they can be both at the same time. In the same way that a great musician can be both a great pianist and great guitarist, the amount of work to master any of these 2 instruments means that it’s nearly impossible to master both at the same time.

(this was initially published here)