I've used WYSIWYG UI dialog editors (mostly the one MSVS used to bundle with C# in... I wanna say 2012?) that maintain their entire state as somewhat-editible two-way code (so if I modified the code, at least within a constrained envelope, it would be reflected in the editor and remain WYSIWYG editable).
Does that count?
If so, I think the lesson is you need to keep the no-code side way, way less ambitious than is theoretically possible in order to keep everyone sane and you might actually have a useful tool that doesn't dig you into a big hole.
Definitely agree with you in terms of limiting functionality built on top of WYSIWYG UIs. 2 years ago I developed a non-trivial app using Retool and it became an unmaintainable spaghetti monster "code" base. (Side note: Retool was pretty solid, my application was just way too complex for it)
The result was I wasted 6 weeks of time when I should've just spent 2-3 days prototyping and then throw out the tool once I had a good idea of what we actually wanted. In the end if didn't matter since the project died anyways :/
PM at Retool, agreed this is hard problem. Like you said, most projects fail so Retool can help you validate and get to success or failure faster. But yeah totally agree that performance, making diffs cleaner, and code search are some things we’re really working on.
Yeah, I had similar experience with https://eclipse.dev/windowbuilder/ in java swing. You can use the drag and drop for most of it, and if you need to hand edit some code, it mostly works and is reflected in the gui tool.
I thought it was pretty productive and honestly sort of miss that kind of development
Mendix does allow this. It runs on JVM containers so from their own "action blocks" you can just say "Call Java action" and execute your code there. There is a java api that you can access from there. Pretty neat and that's how most plugins are built.
On the client side you can do something similar with javascript.
I worked with some platforms that does. However, those usually position themselves as a code generator more than a full application builder.
- Amplication: Last I checked, they allow defining data structure & endpoints etc. before exporting to Nest.js Boilerplate with niceties. They sync to a separate branch on GitHub, so you can use it alongside writing actual logic into the boilerplate, and merge new changes from Amplication to the main branch.
- Draftbit (React Native based Mobile App builder). The builder is not very great, they lack a bunch of features. They make up for this by allowing the developer to add custom JS code very easily. You can write your own Custom React element inside the editor, and with a little massaging things can fall into place. I'm not saying this approach should be abused, though. The team told us once that some of their big clients are mobile dev agencies that mostly just use the platform to Storyboard & bootstrap some UI before doing the actual logic in their own code.
- FlutterFlow (Mobile App builder). I'm biased because I'm still in the progress of helping a client fixing their mess on FlutterFlow. FlutterFlow's code output is really spaghetti. The developer UX on the builder is horrible, so in the end I still opt to eject and deal with the spaghetti code.
If your workflows are exposed to their UI using an API, you can get your workflows out.
Whether it’s worth it vs rebuilding them bespoke is a different question. Or you have to have an ETL layer between your SaaS vendor and whatever open source workflow runner you’d eject to.
Does that count?
If so, I think the lesson is you need to keep the no-code side way, way less ambitious than is theoretically possible in order to keep everyone sane and you might actually have a useful tool that doesn't dig you into a big hole.