[habeyer]

Low/no-code tools as replacements for devs is never going to happen.

But as an "aid" to empower developers... absolutely.

The lowest hanging fruit for a low-code solution would be in the Front-End space since you're dealing with a visual medium anyway, and because Front-End work isn't "hard" as much as it's super tedious which is generally a good target for disruptive automation.

Of course one of the big challenges will be that devs are most comfortable coding in text-heavy non-GUI environments like the IDE or terminal, and any low-code tooling that leans on a visual interface is going to struggle.

This was actually a huge problem for me at https://rapidream.com (apologies for the shameless plug). I wanted a Figma-to-React dev-tool that I could actually use on my real "day-job" projects, but designing an interface and user flow for users who don't like low-codey tooling was almost a bigger challenge then the actual tech.

[schwartzworld]

> The lowest hanging fruit for a low-code solution would be in the Front-End space since you're dealing with a visual medium anyway, and because Front-End work isn't "hard" as much as it's super tedious.

I think the take that frontend isn't hard is extremely outdated. Responsiveness and a11y are nuanced problems with huge surface areas. As designs get more complex, keeping all these things in check requires tooling that needs to be learned. People on HN constantly bemoan the complexity of frontend development and how hard it has become. There's a reason drag and drop isn't the default way of creating a web page, despite tools for this being around for 30 years.

[habeyer]

I misspoke.

It's not Front-End dev as a whole, just the "pushing-pixels" stuff.

There's a ton of difficult FE work (esp. state). It's just that when it comes to a lot of the "basic" styling and responsiveness there's a lot of tedious work that should be automate-able (just like any framework or library, the goal is to reduce unnecessary work, not to suggest that the work is trivial).