I'm a software developer who writes about Laravel, JavaScript, Rails, Linux, Docker, WordPress and the tech industry. Follow me on Twitter @tylerlwsmith
I'm not a fan of "no code" tools because I think their implementation is too dogmatic: they see code as something dirty and to be avoided. Sometimes, a few lines of code are much more powerful than what its no-code counter part can accomplish elegantly. Regular expressions are a great example of this.
That said, I'm a big fan of "low code" tools that provide opportunities to drop down into code when you need the extra power.
I love using WordPress page builders like Elementor for this reason: I can drag-and-drop a page together extremely fast, then I have escape hatches for custom HTML/CSS/JS/PHP if needed. Sure, if I wrote it all by hand it would handle responsive breakpoints a little better and it might be a bit faster. But it would take me three times as long for something that is only marginally better.
The real challenge is understanding the boundaries of what no-code/low-code tools can reasonably accomplish, and making sure you stay within its capabilities. I've seen a project manager commit to using a low-code tool without understanding its capabilities, and the whole project ended up way behind schedule and WAY over budget.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm not a fan of "no code" tools because I think their implementation is too dogmatic: they see code as something dirty and to be avoided. Sometimes, a few lines of code are much more powerful than what its no-code counter part can accomplish elegantly. Regular expressions are a great example of this.
That said, I'm a big fan of "low code" tools that provide opportunities to drop down into code when you need the extra power.
I love using WordPress page builders like Elementor for this reason: I can drag-and-drop a page together extremely fast, then I have escape hatches for custom HTML/CSS/JS/PHP if needed. Sure, if I wrote it all by hand it would handle responsive breakpoints a little better and it might be a bit faster. But it would take me three times as long for something that is only marginally better.
The real challenge is understanding the boundaries of what no-code/low-code tools can reasonably accomplish, and making sure you stay within its capabilities. I've seen a project manager commit to using a low-code tool without understanding its capabilities, and the whole project ended up way behind schedule and WAY over budget.