In my experience, these tools have another - counter intuitive and often overlooked - strength. Their limitations.
You want to handle this very specific edge case? With code, there is certainly a way to do this. It may take days, it may add unreasonable complexity. Nevertheless, someone (yourself?) will ask that this kinda insignificant edge case is properly handled. And won’t take no for an answer.
With a (too) limited « no code » tool, maybe there really is no way to handle the edge case (or it would require code in a context that forbids it). Management (or yourself!) has no way to make someone fix this, and can just give up.
Soon enough, there is no problem. Finally, you can live with the unhandled edge case! Ok, you’ll just brief users. Ok they’ll learn by themselves that they shouldn’t do this.
So sometimes, « no code » tools can’t solve a problem. Then the problem simply disappear. It helps with finding a 80-20, something good enough. Everyone can be focused on more important stuff.
You may underestimate the ingenuity of non-developers hacking on no-code platforms. They end up thinking a lot more like developers than one might think.
Our operations organization has independently arrived at some things pretty darn adjacent to more advanced software patterns, like circuit breakers. (This being for workflow automation no-code tooling, vs website builders).
And a ton of real world work is getting done out there with Zapier, that's for sure.
I've seen a JSON parser written in a drag'n'drop visual no-code flowchart-like application that was very impressive and, if printed, would have caused the death of many trees. Utterly unmaintainable and horrifically stupid given any full-code solution would have involved using a pre-written library.
At Locomotive, we're building a SaaS solution to empower local businesses.
We're looking for a couple of full-stack developers to join a high-growth journey in its early days and be part of the core team. We can help with visa application.
For more informations or to apply, please reach me at guillaume@locomotive.eu
After years of wanderings, I've settled with Fork which is a a delightful GUI.
Polished, feature-rich, and still improving on a regular basis. Kudos to the authors!
Same, I spend about 50% of my time in git on the command line, the other 50% in Fork. I've used SourceTree -> Tower -> Fork and I'm very happy with where I'm at now.
If you’re interested in customizing a web-based (rich) text-editor, I can’t recommend enough the underlying library, SlateJS (http://slatejs.org).
I’ve been relying extensively on it for a quite big project, it’s been a pleasure to use. Especially if you need to change the editor’s content programmatically.
SlateJS is a really neat way to handle rich text editing. I worked shortly on a project to build a rich email client with SlateJS being the underlying library to power the editor. This introduced some interesting issues though around finding the correct way to serialize and deserialize the html due the way that slates core plugins normalize the slate state when working with the different node types (block, inline, mark, text).
The main issue is how to properly associated each html element to a node type, and fit within the core plugin normalization. This is difficult for having to deal with arbitrary html coming from all the different kinds of email client that choose to represent the html structure in their own unique way. However, this is also where SlateJS shines I believe, as you can just normalize all the different html formats into a single representation.
strong, b, font[style="font-weight:*"], etc => Mark Bold
The library has probably changed quite a bit (last I used it was v0.21), so I don't know if my issues are even there anymore, or have changed in some way since.
Overall though, SlateJS is a really neat project, and really fairly simple, and allows for some awesome things to happen in text editors that previous I would believe to be fairly complicated. This is all thanks to the fact that nodes in the slate state can be rendered as rich ReactJS components.
A simple example of this for our use cases was around using template variables in an html email template. I never got around to actually doing this bit, but a variable could be it's own unique node type in the slate state, and allow us to inject a special react component that would make working with the variables much nicer for our users. In the production editor at the time, these variables were just handle bars `{{ first_name }}`, which a lot of customers accidentally would mess up as they had to write out the syntax.
With SlateJS the vision was to simply render a Variable component that would serialize back down into handle bars, or later down the road take the json serialization of the slate state and render that into our own html for sending out.
I really like the patterns SlateJS uses, and I'm excited for any future projects that will allow me to work with it again.
https://stackshare.io/stacks gathers data about which frameworks are used by tech companies - though probably none of the startups from the article are listed here yet.
You want to handle this very specific edge case? With code, there is certainly a way to do this. It may take days, it may add unreasonable complexity. Nevertheless, someone (yourself?) will ask that this kinda insignificant edge case is properly handled. And won’t take no for an answer.
With a (too) limited « no code » tool, maybe there really is no way to handle the edge case (or it would require code in a context that forbids it). Management (or yourself!) has no way to make someone fix this, and can just give up. Soon enough, there is no problem. Finally, you can live with the unhandled edge case! Ok, you’ll just brief users. Ok they’ll learn by themselves that they shouldn’t do this.
So sometimes, « no code » tools can’t solve a problem. Then the problem simply disappear. It helps with finding a 80-20, something good enough. Everyone can be focused on more important stuff.