Beyond REPL? - On Design, Coding, No-Code, SwiftUI and Clojure

Recently, I have been thinking a lot about design, coding, no-code, SwiftUI, and what this all might mean for the Clojure/script community. TLDR - In particular, I wonder if there is any value to create a drag-and-drop no-code interface that creates lines of Clojure/script code.

What follows below is just my amateur two-cents: I’m just putting out my tentative-two-cents-thoughts on possible trends & directions. I would also like to caveat that I’m very much a #Clojurenoob and that I very much welcome critique, and pointers to alternative perspectives.

I also have no real agenda: this is really just some raw thoughts I’m throwing out for discussion, based on what I’m seeing from an amateur pov. If there’s prior work that I missed out, please do point me there! If you think this is nonsense, please feel free to say so, though I must also say that I’m not good enough with Clojure/script to do anything about my idea :sweat_smile: If anybody wants to run with this idea, that would be great!

Reflections on no-code

I had a few observations and thoughts on no-code, after a recent course I attended for work:

  1. No-code tools are now almost at parity with code, especially for simple web apps.
    Tools like allow the development and building of full-fledged web apps, with relatively intuitive interfaces. This allows almost anyone to create any app they have in mind. I think the craziest project I ever saw that demonstrates this, was this project which recreated Civilization VI on Webflow.

  2. No-code tools have overlapped greatly with design and prototyping tools, like Origami Studio, Figma, Framer etc.
    Like these tools, it’s relatively easy to create relatively high-fidelity prototypes and even interactions.

  3. … but one doesn’t just stop there! One can actually ship & test in market for product-market fit.
    An example of that is this startup that used Bubble to build their product, and get into Y Combinator.

But no-code has its problems, one of which is technical debt that grows very quickly, as described in this Hacker News post reply by mrspeaker:

…The rewrite would take some time.
Instead we launched with the Bubble app as it was. It targeted a niche market, and that market came flooding in - it really proved there was demand for the product and the feedback helped shape the end result - months ahead of where would have been if I re-wrote it.

But as the app grew we ended up with “spaghetti no-code”, slow loading times, crazy hacks, giant bundles (that we had no control over)… but again, it was good enough to launch with and validate the company, and it was fast to try out ideas.

We eventually did a full rewrite once we were happy with the overall structure of the app, but the process changed my perspective on the value of no-code tools in the right hands.

Two observations here:
a. no-code tools are great for testing designs, and getting products and features to test in-market quickly, but… performance is an issue at scale.

b. scaling by switching to code requires one to refactor rebuild the entire stack from scratch. It’s also noteworthy that Bubble covers the entire stack from database to front-end. This makes it harder to switch out from Bubble, as there is a much higher switching cost.

Using a stick-shift driving analogy, this is like going from gear 1, then having to stop completely and overhaul the engine before you switch to gear 2.

I would also add that no-code most directly overlaps with the most common web-stack languages: the no-code app that I built was (for all extents and purposes) very similar to the membership portal I created using HTML, CSS, JS and Node, hosted on Heroku…

Learn Clojure directly?

What about using Clojure directly? For most of the folks on Clojureverse, that is a no-brainer, because of your existing familiarity. Clojure and Clojurescript also offer tremendous power and leverage: I’m convinced that Clojure offers the technical leverage Paul Graham wrote about in Beating the Averages for most use-cases.

However, accessing this leverage is a lot for people outside Clojureverse: it’s going to be quite hard for a complete programming noob to grok Clojure sufficiently to make an app for testing the idea in the market. The learning curve is steep, and steeper than a comparative no-code tool.

I would also add that the difficulty is perhaps intrinsic: many of the challenges intrinsic in Clojure have to do with paradigm-shifts. Changing one’s view & perspective is both the simplest and hardest thing in the world. So it’s not trivial.

Alternative? Suggestions from Figma and SwiftUI

Right now, there seems to be a gap between no-code & Clojure: there’s nothing in -between. Maybe what is needed is something of a combination of two things:
a. no-code interface of components, which allows quick & easy product discovery & testing by designers or product managers or non-technical founders,
b. combined with a high-leverage code interface that allows easy refactoring and scaling up by developers. In my mind, it’s a no-brainer that this should be with Clojure/script, simply due to the leverage that the language gives.

This combination reminded me of a completely different tool: Figma.

Figma’s biggest impact isn’t the fact that it’s an interface/interaction design tool like Sketch: from a designer’s pov, the core functionality is very similar. The biggest impact is the fact that Figma allows for the seamless interaction between designers, product managers and developers, shortening the larger design process loop. This was best explained by Kevin Kwok in his blogpost:

Pic from Kevin Kwok’s blog

If you change “design” to “design & code”, that becomes even more interesting, because it offers the possibility of the smooth gear-shift from gear 1 to 2 & beyond, without needing to stop or overhaul. That’s what I think is an interesting possibility to explore.

REPL-driven-development already offers that partially, with the very fast iteration by the engineer. But imagine if designers and PMs can also provide input!

This is where I think SwiftUI offers an interesting illustrative possibility for Clojure/script’s future direction, beyond REPL-driven development.

SwiftUI seems quite similar to Clojure: there is a real-time view of the compiled code & hot reloading (though I’m not sure it allows for expression-level evaluation!) REPL-driven development already offers a lot of this.

For me, the most exciting part of SwiftUI is that it allows drag and drop of components and features into the Canvas, while updating the code base in real-time. This is like a REPL in the other direction: from the app/view into the codebase. It’s almost as though someone has a no-code tool attached to a code editor. That might allow the larger team to iterate more quickly.

So the prompt question I’m posing to the community is this: what if Clojure/script develops SwiftUI-like drag-and-drop of components & features into the app, like a no-code/low-code style “reverse REPL”? How could that help with Clojure/script’s adoption?


That civ4 mock is pretty serious.

No-Code/Visual-Design type tools are great for managing assets and game editors are probably the best example. For 3d stuff, It’s definitely possible to connect to a remote instance of Blender and script it via a repl.

The reverse repl thing (swift ui) is really cool and it’s very attractive for designers/beginning devs/people that want a more immersive experience but I dunno… I don’t feel like it’s that great a feature to have the cursor move to the line when you click on a box on the editor. What happens if you are generating a bunch of boxes by code instead of drawing each box out on the gui? Where does the cursor move to then?

RAD tools for databases are pretty cool too but It also depends on what you’re trying to do. What happens when you want to stream db events via a custom protocol to the ui? I’m not sure how the tool will help.

Visual-tools meeting 6: general monthly meeting may have people doing something similar to what you’re talking about - but with data visualisation as opposed to guis.


Fair points. I had two thoughts in response:

  1. When you’re generating a bunch of boxes using code instead of drawing it on the GUI, that’s probably not very different from the REPL?

  2. The reverse REPL would definitely benefit non-devs more than devs directly. But the gain is that it might allow for a faster design-process-loop of the larger team (including non-devs), in exchange. Kinda like Figma allowing non-designers to actively participate in the overall process.

I’m not sure what you mean by this. Are you saying the cursor would likely move to the same spot?.

can you give an example?

Mind you, this isn’t really a new thing. Visual Studio, Eclipse, Flash had similar features for it’s gui editor. It wasn’t that great an experience. You can do stuff like this in any decent game editor - linking code and visual elements. It’s good for fiddling around with things but I also don’t think visual tools solve the issue of software complexity. In my experience, it usually makes things more complicated - and that’s the tradeoff I guess.

1 Like

These type of tools existed in the past, such as Adobe Flash, Eclipse WindowBuilder (that’s a Java bidirectional one for Swing), etc.

I think maybe the newer batch with being made compatible for the web would become more popular, more people are using computers than ever before as well.

In my experience with the older stuff, it just ended up being used by devs and eventually abandoned because it was easier to do it with code.

There’s a kind of reverse pattern of all this as well, LaTex, Markdown, PlantUML, etc. People actually moving away from visual tools for writing and diagrams and to code based ones.

I still think these tools are great, but I think the market for them are people or companies that don’t have developers. Once they grow big enough to have a developer chances are it will get rewritten in code.

The problem I found is that it’s harder to be precise and to scale with visual tools. How do you have two or three or four people working on it at the same time? How do you reuse parts from one project in another easily? How are you sure all the alignments are handled properly?

And then there’s the issue that you’re working in 2 dimensions, once you start having multiple pages, animations, interactivity, there’s almost too much for the interface to handle.

I think an alternative to these are live-preview. The code is still the interface, but you get a live preview of the application.

Now it be cool to have a two-way interaction, but sometimes the visual view will just mess up your code haha, that’s the downside.

Still, there’s value in certain scenarios for some people. I know in games a lot of things are done through visual editors.

I used to do MaxMSP as well, and that’s not exactly the same thing, it’s more of a visual programming language, and it did work great for the use cases around it, though you’d be able to drop into the code for certain pieces as well when needed.


totally agree with that.

1 Like