[OutsmartDan]

Developers hate these tools for a reason: they're the ones maintaining it after it's been deployed. The whole concept of "no-code website builder" ultimately goes back to "where is the code and how do we modify or integrate it with our current systems".

Maybe if it was marketed as a "fast prototyping" tool, I'd be more on board with the product.

[migueloller]

I'm not sure I understand what you mean. Why would developers have to maintain a website that's not hosted by them?

If the issue is maintainability once the website has been extended (i.e., with custom code and integrations), then it's all about _that__ experience. I think in those cases, the mistake is to come up with some sort of bespoke abstraction that the developer now has to learn and that is different from everything else they're used to.

With the way we've designed Makeswift, once we open up extensibility, you'll just use regular old code (e.g., React, Vue, Angular components, or plan HTML and JS), in a repository that's version-controlled, that lives with the rest of the code.

To make that a bit more concrete, today, Makeswift components are just React components. So Makeswift's API is just passing props to your component. That's what we plan to open up eventually.

[Timpy]

The SAAS I work for started out as the owner building pages on whatever dreamweaver was popular 15 years ago, and that templating engine still haunts us today. Our development cycle is painfully slow because of all of the copy-pasting that happened in the code base before a team with modern sensibilities got their hands on it. I have nightmares about nested tables for layout and inline CSS.

[marketingPro]

I made it a rule that all articles are html/css, no website builders. One website builder page broke and I had no idea for potentially years.

I had nursing students, high school grads, history majors, and a heroin addict make a html/css page.

Sure it was wrapped in my header/footer, but this means 1 front end developer, once.