You’ve heard it said “Low-code / No-code app development is the future.”
But I say unto you: “A Developer-first approach to Low-code / No-code app development is the future.”
What do I mean?
Let me explain.
Do you know how many web page builders are out there that allow people to publish a landing page in a matter of minutes with a decent layout and design? A lot.
It seems like every month a new one launches with a new mechanism, promising you that you can build a landing page without code.
And you can.
And yet, the WordPress platform continues to persist, not in obscurity, but in overwhelming ubiquity even though it’s low-code capabilities are limited compared to the many new offers in the space. As of writing this, 43% of all websites on the planet run on WordPress and it has 63.1% of the CMS market, more than 10x greater than its closest competitor.
A number of reasons, but a big one is that WordPress strikes a balance.
The balance between giving non-developers the power to do things without hindering the power of developers to do all things custom.
You don’t have to know any code to achieve a lot with it, but it allows developers to customize, modify, and extend to achieve even more.
And that’s a hard balance to strike because as soon as you start to build any kind of software, especially low-code / no-code solutions, every decision has the potential to force the designer’s opinions of how things should be done—opinionation.
Opinions that aren’t necessarily shared by everyone, opinions that threaten the feasibility of the solution from functioning in the first place depending on the use-case, and/or opinions that hinder future flexibility.
Now, software opinionation may not matter a whole lot if the project is small, but as the scope increases, its impact is far-reaching.
Causes have effects.
When you’re faced with making a big software or a data management decision, you have to identify the opinions you’re willing to go along with, or in other words, what are the lock-in effects of choosing X vs Y?
So you can answer crucial questions about the longevity of the decision:
It’s natural to think “there’s a solution to my problem already in the market,” and then go look for it. Pay some money, solve the problem. Makes sense.
But as you get more answers to the questions above, you’ll often discover that even if the solution works, the trade-offs grow steep, leaving you feeling stuck if you were to buy it.
If you’ve been down this road, you may have thought to yourself “Maybe we should take the hit and build this from scratch.”
The classic Make vs. Buy dilemma.
Who are the people that will:
If you’re a developer, you know that eliminating as many tradeoffs as possible makes your work easier, gives you more flexibility as things change, reduces costs, and doesn’t leave you feeling trapped.
That’s why the Form.io platform is a developer-first approach to low-code application development.
“What does that look like practically?” you might ask.
It needs to solve common, repeatable, and predictable problems at scale to make the solution worthwhile in the first place.
These are the repeatable things that traditionally take the most time for developers, are the most tedious to build, and distract the most from building core requirements. Things like:
Which makes sense why there are many choices for form building and data integration and management:
Form.io sets itself apart as the only platform that can handle the most complex field types and the most complex data integrations, including legacy system integrations.
With it, developers can build in parallel while non-developers can build forms and their APIs in a drag and drop interface, even if they’re:
BUT, what are the tradeoffs?
Yes. Good question.
Form.io is as unopinionated as they come.
It’s the solution you can buy, but still gives you the benefits as if you made it yourself:
Imagine your next build is big. You get the enterprise docker container with everything already wired; the core developer portal, the form manager for non-devs, the JS form renderer (in your preferred framework, or none at all), the PDF servers, and built-in accessibility. You can stand it up in less than a day. No hassle.
You receive the requirements from 3 business managers in your organization. The requirements includes 375 different forms, each with their own rules. Okay, that’s a lot, but you’ll come back to that.
They have to integrate with your existing data. So you setup the resources in the Developer Portal where the data will be stored in. Ha! The resources are drag and drop forms themselves, with the APIs done for you as you built them.
You weren’t really thinking about the low-code / no-code benefits for yourself, but here you are.
You take those resource APIs, which are all JSON, and connect all your existing systems to the Form.io Developer portal. Now you’re brining in all your data—users, customers, products, etc. etc. Now it’s all in one place.
Time to build the app. In addition to all the forms, there’s a lot of front end work. You put your team on that.
But the forms. The business managers are intimately familiar with their requirements—they wrote them after all. You show them the Form Manager tool and they get to work, building the forms and their APIs for you.
Which lets you get back to your team, your responsibilities, and what you do best.