Feed
As with all things in this world, choosing which adventure to take is a series of trade-offs. Low-code is a compromise on the disadvantages at the extremes, but it's not without its downsides.
Fundamentally, this is a discussion as to where on the scale you fall on Vendor / Dependency management. After all, unless you're fabricating your own silicon you will always have dependencies - it's just a question of scale.
It's all a question of trading speed and ease of development for control and maintainability.
(I very much disagree with your suggestion that low-code is automatically more maintainable for the following reasons):
You have significantly expanded your attack and maintenance surface. You may only use 5% of the framework / functionality that you've brought in - but you own the resource needs and maintenance of 100% of it. You now have to map dependency trees that may be incompatible between different libraries. You've traded complexity of code for complexity of dependencies (which is something you have less control over).
If you need to do something which your framework considers to be 'unorthodox', you may have to write your solution in a more complex way to fix into the existing framework's model (as opposed to the most efficient / maintainable way - introducing additional complexity).
If, God Forbid you tickle a bug that's located inside one of these frameworks and you've relied on the framework to hire less experienced people - you are stuck. You may end up with an application that's down that you don't have the skills in-house to fix.
Vendor lock-in. If you rely on a framework or a service and that relationship breaks down for any number of reasons - you potentially have to write your application from scratch.
Low-Code doesn't remove complexity, it hides it. The piper will always need to be paid - it's a question of when and by who.
These tradeoffs make sense in some cases and not others.
As the architect of a solution, only you can make the decision as to which approach is the right one for your use-case.
Great article! One of the philosophies we live by at appsmith is that visual elements and configs should be configured visually while logic and workflows should be expressed via code. Anything that cannot be a simple config should just never be forced into a complicated visual interface! This has always been one of my peeves with workflow builders. They're great to connect to the data sources but the minute you have to write logic on the data in between, it becomes a nightmare!
Well put. Embracing the change and using everything available to us to just build sh*t.
I'm a bit fan of laziness, give some plug and play that I can expand if I want to.
Great article 👌.
I agree that most platforms have struggled to find a balance between designers and developers. But I think platforms that focus on that gap are missing where most business value is actually created.
I think no-code is successful because marketers, salespeople, and customer success teams can use it just as well as anyone else. Putting this power in the hands of the people actually generating revenue for a business means they can start and run businesses without even talking to or hiring a coder — and start learning about their customers from day 1.
I hope to see more platforms blending everything together like you suggested and I agree they'll win in the longrun (can't wait to see what Webflow do in this space!). With a powerful platform like that, the marketing team can design a prototype, salespeople can sell it to customers, customer success teams can fill in the gaps in functionality with manual actions, while designers and developers are hired to rewrite one piece of the prototype at a time and make it more scalable and powerful.
A company I consult for actually started that way — doing everything with spreadsheets combined an amazing customer success team. Now we have a full tech team and a lot of happy customers!
That's my ultimate goal for an open-source framework I'm building called Remake (remaketheweb.com). Right now, it uses HTML as the underlying technology, but that's just to give it a strong foundation. We also have an online IDE and drag and drop builder in the works. I'm hoping non-technical people will be able to copy a template of an app, modify it, start a business — and developers can come in later and add extra functionality once they've already seen some traction with real users!
I also wrote up a blog post about the no-code/low-code ecosystem where I reviewed all of the latest and greatest tools. I'd love for you to check it out if you have time: blog.remaketheweb.com/no-code-and-low-code-tools-…
Great article, Ali. One of the best explanations of no code, low code and full code solutions. Have bookmarked Shawn‘s article.
And, welcome to Hashnode! 🙂
Sonu Sharma
Have you tried Nodezap , it can be used to create Admin Panels. It has variety of charts and widgets to choose from. You can write your own CRUD logic to manipulate data. It will also let you fetch data from the external resources using REST api.