[Nimsical]

[Disclaimer: my company is using Superblocks and have been paying for it for about a year]

Been reading the comments and I think there are a bunch of questions about why companies would use a tool like this and that integrating your product / company into it is potentially risky. Here's why we decided to use it.

First thing you should know is that before we moved to Superblocks, we were using a combination of Retool, Google Cloud Scheduler, Mode Analytics, and a few small Google App Engine apps to solve our problems.

There is a whole ecosystem of apps and mini-products our engineering team has to build which require slow-paced maintenance, but are still mission critical to our business. Analytics dashboards, Slack reporters, revenue dashboards, customer service dashboards, Discord bots, etc.

There are plenty of different tools which solve some of those problems in silo, but the main problem (and beauty) of building internal apps is that you can fully solve for your unique business problem. We're a tech-enabled advertising agency (there are a handful of companies like ours in the world) and we both have our own external product as well as a series of internal apps that power our operations.

We decided to move all our internal apps to Superblocks effectively because we could merge a few different platform layer things (Google Cloud Scheduler, App Engine, Mode, Retool) and be able to build much faster within our team. The big thing for us was that we have engineers writing in Python (more data heavy stuff), and engineers writing Javascript. Previously, we had to have them offer APIs to each other and it wasn't as agile as it is today for simple things we had to build for our business stakeholders.

I remember seeing one of our first Workflows on Superblocks when our data scientist built a BigQuery step, a Python step, and then our Javascript engineers grabbing that to do some post-processing with it to display the data and thinking "this is probably how most tiny apps will get built in the future".

I don't want to have infrastructure for every tiny solution I built for our team. I just want things to work.

[verdverm]

As a developer, the other concerns that I always want to be addressed around RPA / UI based tools are (1) how do I solve my problem when it outgrows the bounds of the product, yeah, you kinda have custom code I can enter via the webpage, but... (2) why do I have to use & learn your UI, let me use my normal tools

[bradmenezes]

Are you looking for specifically to write code in say your own IDE like VSCode and we build a VScode extension?

[verdverm]

I use nvim, but yea, that is the point. Meet your users where they are, which is code for developers, not drag-n-drop, which is for non-developers. Pick your poison :]

Just to be clear, porting a drag-n-drop interface to VS Code is not meeting developers where they are.

[pbardea]

(Disclaimer: I’m an engineer at Superblocks)

Interesting point. Personal opinion here - I do not think that drag and drop is only for non-developers. A great example of this is the gaming industry in Unity/Unreal engine. These tools are effectively low-code but also incorporate drag and drop to allow developers to build whatever they can imagine but faster. Drag and drop should be an extension to the developer’s arsenal, not be the only way a developer can interact with the system.

[verdverm]

I agree 100%, I want a drag-n-drop* but every single one has not met the expectations.

* what I want now is a little more and a product I plan to move from prototype to production soon (tm)

As I said in a peer comment, I get the game engine analogy, it's close, but there are enough differences that it doesn't carry enough weight to make it a point of justification. They've also had over a decade plus to develop and get lots of complaints. But note, there are 2-4 options in the game dev space, because it is so hard to build a compelling experience. Low code. / drag-n-drop is littered with shitty products and race to the bottom competitors. Also, my statements can generalize to DnD based solutions for more than frontend, to things like node red, iffft, zapier et al

Since Excel is on the front of HN, I'm reminded that Excel is the OG and most successful low code product in history

[bradmenezes]

It's a great point, one interesting thing we've found is that backend developers are welcoming of using a drag and drop frontend builder, as long as it is extensible with code. For them using React, HTML, CSS is painful especially for an internal tool where the speed of getting their tool shipped is paramount.

[verdverm]

Do you have analytics that back that up, or just statements and surveys?

As a backend focused dev who's very interested in low code, I've tried them all and they fall short after the honeymoon. Most recently Plasmic.app, had (has) great promise once their product matures. They nailed the developer facing workflow. The problem is twofold, (1) that the UI is big, slow, and buggy (2) the code that comes out the other side is super heavy. A blank component added 50% to my bytes shipped.

The hard question to answer is what does that interaction point look like? Why is the backend dev even tasked with doing the frontend?

You'll face a point where you will have to decide who your paid product is for, and every drag-n-drop for developers has pivoted to non-developers, because getting something that most developers actually love has proved impossible to date.

[bradmenezes]

Not from statements and surveys, but from paying customers :)

We think our market area is wildly similar to the early days of gaming engines, echoing what pbardea commented earlier. We are providing the game-engine or the "tool-engine" if you will.

The reason backend developers are often tasked with building frontends on internal tools is because the frontend developers are often allocated fully to the core revenue-generating customer facing product.

As of today, we don't solve every use case pure code can. But over time we think there is a path to becoming the default and standard for this category of software, especially if we can nail the programmability aspect to win over developers.

[xyzzyrz]

Hi! Thanks for the feedback on Plasmic.

Re: "super heavy" output: A blank component should result in one corresponding div. Maybe you're weighing the API client library? You can codegen pure React modules if you don't want the loader library itself.

If you have any specific feedback on the UI, would love to listen. Thank you!