The software development paradigm for the 2020s

It's hard to see among all the new frameworks promising the world, but a new software development paradigm emerged in the last few months. And it makes building software better and cheaper.

Please follow me as I try to lay it out in a non-technical way, as well as its ramifications for businesses.

What do I mean by paradigm?

A paradigm is a way to see the world that creates distinct patterns from the ones that existed before. In software development, this usually means that a new generation of coders will see things in a different light and create technologies we couldn't anticipate.

Before frameworks like?Ruby on Rails?or?Laravel?existed, devs felt it was common sense to organize things in a way that looked chaotic after we got used to the new paradigm they introduced.

Before?React?popularized?reactive programming?and made it the norm for frontend work, we were all used to working 10x more to ensure a great user experience.

The current status quo

Since the 2010s, the most common paradigm has three main characteristics:

1. It relies on a separation between the backend and frontend, with each of them commonly having separate teams and tech stacks. That was not the norm in the 2000s when frontend and backend coexisted within the same codebase.
2. It expects rich user interfaces with real-time updates, no full-screen refreshes, and complex interactions. That was virtually impossible before the 2010s, but we got used to it fast.
3. Developers spend the bulk of their time on synchronization between what the client knows (e.g., a web browser, a mobile app, an IoT app) and what the server knows (i.e., our backend, typically in the form of a REST or GraphQL API). Whenever the client wants to make a change, it has to inform the server, show a loading indicator, and then update the whole app based on the response from the server.

A new paradigm emerges

I'll save the story about how we got to it to another article, but here are the characteristics of the new paradigm:

1. It expects even richer user interfaces than the current status quo.
2. It doesn't require separation between backend and frontend work but allows for it when necessary. Going one step further, it facilitates the integration of backend and frontend code in the same codebase, ideally the same files.
3. It automatically synchronizes what the client and the server know for most cases while still allowing for manual synchronization when needed. That is the disruptive innovation right there. Anyone who has tried to automate this while still maintaining rich UIs knows how big of a challenge this is. But we finally got there.

Remixing our stack

I'm sure someone will point out an obscure technology that implemented something similar before. But, for me, credit for this innovation goes to?Ryan Florence?and?Michael Jackson, creators of?Remix.

While React's?server-side rendering?capabilities and frameworks like?Next.js?had already solved the synchronization between client and server when loading information, Remix was the first to solve it when changing information. And when I said that devs spend the bulk of their time syncing client and server, most of the work happens when we need to change something rather than when loading data.

But, just like fish might not know what water is, it might take us a while to recognize the importance of this innovation. For most devs today, this synchronization doesn't feel like unnecessary work: it just feels like work.

But as people realize this is a paradigm shift, many other frameworks and libraries will introduce their version of this innovation. And a new generation of engineers will look at us in bewilderment when we tell them we used to have to do all this.

Opportunities for businesses

This new paradigm is not conceptual. It's already brilliantly implemented in Remix. Right now, companies who adopt Remix can expect:

• At least 3x in productivity while building better apps: we've measured this at Seasoned for six months and consistently delivered better software faster.
• Happier, more engaged developers: the unexpected relief from not having to do gruntwork they weren't even aware of is life-changing for devs.
• More flexible teams: all your devs can now work on the same tech stack without separating backend and frontend. Even if you have specialization in your team, it's not mandatory, and there's a lot of overlap between functions.
• A passionate untapped talent pool: more devs are dying to work with Remix than there are Remix positions. That will not last, but if you get onboard early, you'll have an unfair advantage for a while.

By Daniel Weinmann