3 ms·
Having worked with Mendix and Apex (both low-code tools) for over a year: I wasn't convinced. Anytime you're trying to color outside the tool's predefined line
by atsjie 5y ago
Having worked with Mendix and Apex (both low-code tools) for over a year: I wasn't convinced.
Anytime you're trying to color outside the tool's predefined lines you'll be hurting and spending ridiculous amounts of time.
But stay within their lines and you'll be fine.
Because of this I don't see any real use-case for it in the B2C market. That in itself makes the 80% mentioned in the article hard to achieve.
In B2B there are more opportunities for low-code tools, but there too I don't see it working everywhere. Simply put; if you build something from scratch it's going to be a lot better than anything built with a low-code tool and you can easily grab market share by providing a better offering than your competitors. Low-code tools are not the means to out-compete the market.
If you do succeed in the B2B market with a low-code tool offering; likely you'll be building some very customized setup that required a huge investment to get to that point. I'd not be surprised it'll be just as unwieldy and difficult to change as most other software is. And for fixing big issues with your app (performance, complex bugs) you'll be requiring devs who worked and understand all those abstraction layers. Those devs will be extremely rare and hard to come by. I was one; but I am not anymore. It's just not fun to develop in them compared to normal coding; you feel constrained and fixing issues all the time that shouldn't exist in the first place.
However if you consider the huge set of internal tools lots of companies develop and use; yes there indeed is a big market for low-code. Basically use cases that were run in excel are generally great candidates for these tools. And that's a lot of use cases. Not the big money-makers though.
There's a reason Frontpage and Dreamweaver never made it; this won't happen to low-code tools. They have their place, but know their limitations.
- staticassertion 5y ago> Anytime you're trying to color outside the tool's predefined lines you'll be hurting and spending ridiculous amounts of time. This is exactly my experience. This comes up a lot when someone tries to take a 'DSL' approach to solve a general problem. "Look what you can do in just one simple line!", and it's true, one line and you've got something working. Then you ask questions that weren't anticipated. How do I reuse the 5 lines I wrote here in another place? How do I write a test for those 5 lines? Can I log outputs in-between lines? Those aren't exactly scary questions for any programming language - the answer is trivial, and what those languages solve for. But in these fancy no-code systems the answer is "you can't", more often than not. I care way more about how a system is going to evolve and how it will be maintained than solving trivial problems in one line. They end up being completely unmaintainable and you lose more time than you save. Frankly, coding isn't that hard. You don't need to be an expert to be effective, and there's a massive amount of tooling, knowledge-sharing, and investment already there. All of this no-code shit is such a waste of time.