I am a co-founder of a competing OSS product called Appsmith. I discovered Superblocks early this year and my first reaction was that the UI builder looks similar to Appsmith. Examined the DOM, and it was Appsmith code under the hood.
I’m new to the FOSS world and it was quite interesting to see someone use our project to compete with us.
Yes, we do use some Appsmith code (Apache 2.0) in Superblocks specifically related to our frontend drag and drop canvas and components, as part of our UI builder in Superblocks. We’ve evolved our architecture significantly over the past 18 months to support our unique API execution model.
We do not use it in our API builder, workflow builder, scheduled job builder, agent platform, permissions, audit logs, observability, integrations, version control and more, all of which have been built on a different architecture to provide different value to our customers.
What Appsmith has built is impressive and is a good option for customers who may prefer to fork and customize their UI builder or prefer to manage a full on-prem platform themselves. The customers who choose Superblocks are a different group with different needs.
We use the Apache 2.0 license and we don’t intend to change it. AGPL would restrict adoption. We have a few large companies that maintain Appsmith forks customised for their needs. A couple of them have made the product better.
Only thing that I’d like is an acknowledgement at this point. An engineer from Superblocks spent hours of my team’s time asking questions about the project on our Discord community. We were too dim to realise that the engineer wasn’t interested in contributing but competing. It’s all perfectly legal, but definitely left a poor taste once we found the product.
[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.
I don't want to have infrastructure for every tiny solution I built for our team. I just want things to work.
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
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.
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
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.
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.
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.
There will be no default or standard in low code / drag n drop. It's a market that has been around a long time, very crowded, largely segmented, and a tough space to compete in.
I get the game engine analogy, used it myself, but it's a little apples and oranges. Very different personas, if you only have one persona for developers or even backend devs, you haven't narrowed down enough yet.
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!
Airplane.dev founder here - glad to hear you like our approach! Many low-code/no-code tools miss the mark, in my opinion, by creating a walled garden / silo where you build stuff, which makes it hard to version control, leads to vendor lock-in, etc. Our approach has always been to allow users to write normal code that they store in their own repository.
Excited to see where Superblocks goes and whether it embraces that approach in the future.
Hi, one of the creators of Superblocks here. We think airplane is a great product and want to enable developers to choose their favorite development flow. We're working on a gitops feature that will allow you to export Superblocks app definitions into project files and manage it just like any git repo.
Super cool. It's likely in the works but it would be cool to have more recipes / mini templates to start with on the application builder. E.g. a list of most active users or something similarly generic to help me get to something real faster. Also the ability to add an integration / connect postgres from the 'new api' prompt rather than having to go back to the dashboard first
This is a really good idea and something that is on our roadmap to add templates to accelerate tooling development. We're learning about the most common use cases and going to build templates to shortcut getting started. The other thing we've discussed is upon connecting an integration (ex. Postgres) automatically giving you a postgres admin app, similar to what you get with a Django admin for example.
Is that what what you're referring to?
good usability feedback on the New API part of the UI, we will address this!
Yeah pretty much, help me get to a data connected state as fast as possible so I have an app / view to share with someone. It's likely an app has a user's table with created ts, help me generate a chart of signups over last 30 days or something rather than having me manually create an app, drag in a chart, nav about to connect pg and then write the basic SQL. Then once I have a working base I can explore from there
There are some very good features of Django Admin we can learn from like their onboarding - the major reason some users have replaced Django Admin with Superblocks is that Superblocks works with your db but also internal/external APIS pretty easily, plus there's a Workflow and Cron Job aspect to the platform.
The reason others have chosen to stay with Django admin and not move to Superblocks is they spent a ton of time investing in it (and it works quite well), the switching cost ends up being high.
Great question, having been an engineer all my life, this is one of the question I would ask myself as well. Developers are at the forefront of our target audience and we want to give all developers the peace of mind that any code or configuration you create in Superblocks is completed owned by you and can keep working without Superblocks. Here's how:
1. Our agent is open-source, this means you can inspect, modify, build and host it however you like
2. We're soon launching a feature where you can export the entire definition of Superblocks apps/workflow/jobs/permissions as project files and manage it in your own git repo
3. We're brainstorming the idea of exporting your app as native React and NodeJS applications so your app continues to work outside of Superblocks
Obviously our goal is to keep providing the best features, performance and stability so you can save time and let us accelerate your development process :)
Would this give you the confidence to use a platform like this? If not, what can we do better?
Congrats! Seems like a Retool competitor but focused more on developers? I'm not sure if that's the direction I would go since developers already have pretty good tooling for their level of expertise, IMO.
Although, I could see how building an app that uses data across the various SaaS tools a company uses without requiring that data to be dumped into another database could be useful. Maybe I'm missing the point.
As an aside, I'd love to see Retool but for less technical people. Specifically, a way to make Google Sheets available for multiple people in a company to use. We have multiple quick and dirty "calculators" (think pricing for sales, comp for recruiting) that we roll out across our company. Eventually they get operationalized and converted into proper applications (or we buy a SaaS product for it) but would be nice to have an interim solution. Some requirements:
- Ability to create a very simple CRUD web UI
- Authz/n with ability for IT to integrate into their SSO.
- Google Sheets backend and integration so financial analysts can update and manage.
Because Superblocks is quite broad in nature we end up being compared to a wide variety of tools but we at the same time integrate with them.
For example you mentioned Retool which has a UI builder, but also Zapier and more recently BI tools. We have a customer who's moving off Tableau which was a surprise at first because Tableau is well designed for fast analysis for SQL-only users and that's not our core audience.
I guess we don't really deliver on what you're looking for wrt an offering for less technical users than developers, because to really be proficient in Superblocks you'll need to understand SQL, calling APIs, Python or JS to get the full value.
regarding Google Sheets integration that is our most popular integration alongside Postgres, the end users can easily user it like a database.
Looks like it has tons of potential, but from watching your demo, developing steps using a bunch of form fields is going to be very tedious, especially when you're trying to test/debug things and have to flip between screens constantly.
Hi, one of the creators of Superblocks here. Most building blocks in Superblocks are fully extensible with code, and we're building much better debugging capabilities in the platform. The form based configuration is easier to work with for simple use cases, for more complex use case, you can extend Superblocks with your own business logic in code. We're also building a gitops feature where we allow users to manage Superblocks apps and workflows in source files just like any git project.
Congrats on the launch Brad and Ran and team! We've been an early customer of Superblocks for a long time and have been thoroughly impressed with the team and product.
We evaluated all of the low-code builders in the market (including both paid and open source) and eventually decided to use Superblocks for some of our core operational tools and workflows due to the power & flexibility of the tool, the focus on access & security, the team's unparalleled support and the pricing model.
It's been great working with the team and they've been nothing short of fantastic. We can't wait to build more with Superblocks and see what they release next.
One of the developers that built Superblocks here:
> Is this open source
Although the app builder you see on the cloud is not open source, we offer a hybrid deployment option - the on-premise agent (OPA) is our execution engine that runs all of the code that you write in Superblocks. It is source available https://github.com/superblocksteam/agent and you can self-host it to ensure your data stays within your network. Feel free to check out the github repo or our docs (https://docs.superblocks.com/on-premise-agent/overview) for more details!
How does this compare to Retool (https://retool.com)? We use Retool at my company and like it; this seems like it is similar, but targets non-developers and is less mature (e.g. in the quality of the components)?
Interesting. This is kind of like Camunda without the BPMN baggage and a full blown IDE that integrates all the frontend/UI aspects with the backend workflow stuff. With Camunda, you have to build your own frontend past the auto-generated task forms. It’d also be interesting to see what a rule engine would look like in Superblocks.
You say source-available, but I do wonder what happens with all your apps/workflows if Superblocks goes belly up. It doesn't seem like there’d be an easy way to migrate off it. With Camunda, their modeler and engine is open source and all the code you write is like any other code—it exists in your own git repo.
(PS: Not a Camunda shill, but have built proofs-of-concept with it in the past, and am evaluating it again.)
Our approach is somewhat akin to say Datadog where they have an agent that you run, but the UI is hosted.
The approach we took was to give customers a) ability to keep data in their VPC, b) security teams can audit anything running in their network, c) anything non-sensitive doesn't need to be hosted by the customer to make it simpler to run/manage.
Would be curious what you think of this hybrid approach and if there are further design decisions we could make that could be useful for us to incorporate?
This matches exactly how we saw the market before we built Superblocks - which is why we never refer to Superblocks as low-code/no-code solution, but rather a programmable developer tool.
When we speak to customers, the thing that resonates most is the speed of higher-order primitives, with the flexibility of code. The best of both worlds. This has guided our product philosophy entirely and even custom components are in beta which you can sign up for here:
We're a broader approach to building different types of internal tools (UI, workflows, Cron).
We get compared to stuff like Retool, Zapier, BI tools and other low-code tools quite often, but the main differences are in the breadth of the product and most importantly how focused on developers and code (Python and JS for now, other language in the future) the product is to make things extensible. Basically we wanted to replace all the internal tooling we've built and used at previous companies we've worked at. A lot of it is too complex for the popular low code tools of today.
We are a ways away from achieving that mission, but think there is an approach that can work if focused entirely on developers.
Hi, creator of Superblocks here. We are 100% focused on developers and our goal is to make the onboarding experience seamless. We've seen many of our customers consolidate different tools so they can manage dashboards, workflows (APIs), cron jobs, all in one place. We also have a different architecture than Retool where there is significantly lower overhead for the customer because we offer a lightweight agent rather than a fully on-prem installation. Happy to dive into more details with you!
I think the python functioning is super useful for my application on superblock.
but it only provides basic functionalities.
are you guys going to make it more powerful like importing project from my own codebase/github repo. So I can use a lot of my own code components, and the abilities to install additional packages.
We are another of Superblocks' early customers, and we've found it really useful for creating internal tools quickly. We still prefer to write some of our more heavyweight tools in React to leverage component reuse, etc, but we like this for lightweight tools that don't have a lot of complex frontend logic.
Component reuse is something we are tackling on our end. We are working on a custom components feature so that you can bring your own components to Superblocks and reuse them across applications. Would that help replace some of the heavyweight tools you currently prefer to build in React?
We've seen a mix of small startups building their first admin tool, for example to replace a Django Admin. We've also seen larger enterprises with 1000+ operations people building financial services tooling to support credit card management or a large salesforce doing on the fly pricing of their product based on data from Snowflake. So it ranges, what we do see if most medium and large companies want to use our source available agent to keep their customer data in their VPC
We aren't yet HIPAA compliant (yet), we recently got SOC2 compliance working with a compliance vendor to do more certifications. One thing is that with our on-prem agent your customer data never leaves your VPC.
Since we focused on developers we had to do both those things early as users didn't want to adopt without it. In terms of version control, we have a native version control that allows you to mark a deploy comment rollback to any prior version of an app, workflow or job.
We got some feedback recently that customers wanted to manage this all using their own CI/CD pipeline so we're working toward enabling this very soon. A GitOps feature would allow you to manage everything via your typical process in Github/Gitlab etc including code reviews and team hierarchies on who can deploy code.
In terms of role based access control, we have a set of permissions you can set at the job, workflow and app level for access to Own, Edit, or Use. Also Permissions groups can be accessed via code to do business logic around the groups for more fine-grained controls. There are also permissions at the integration level because you may want developer A to access postgres, but not developer B from another team.
We've seen the most pull from more operations-heavy businesses like Fintech (building KYC, AML, Fraud, Credit Card Admin tools), Insurance (claims management and support admins), E-commerce (Order Management, Supply chain). Which industry are you in?
Seems like a cottage recipe market/consultancy for small non-tech business could be a professional services like option (or for others to have a small consultancy coming into non-tech businesses and selling setting this up, templating, recipes, whatever for companies.
interesting markets in this could be tying to legal, real-estate, construction, hospitality, etc - obv a stretch goal or at least something to just consider how to accommodate.
Given the comments I'm used to seeing in general in HN, the over excited tone of the comments in this post makes me wonder how truthful all the praising is, or if they are related to the company in any way. Maybe HN is actually full of people who build internal tools and find this honestly awesome and a game changer.
To be fair, you are right, now, because when I first opened the discussion there was only 1 critic comment and the rest was overly enthusiastic praise. It really stood out from the usual tone of the discussions.
Please don't post insinuations about astroturfing, shilling, bots, brigading, foreign agents and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email firstname.lastname@example.org and we'll look at the data.
I have been actively following this space. I think there is a huge fallacy in a tool like this. At surface most of the developers love the idea, you often get feedback that people would use it but time comes people just not integrate their service with a platform like this. You have to build huge amount of trust either by raising from popular VC, Angel's, blogpost by reputed dev advocates, socialproofing. For a general purpose framework it is generally an uphill battle. Having said that, there has been outcomes in past like rundeck's acquisition by pagerduty. One thing I noticed that platform who have built some features that bound them to certain usecases done really well. Platform with a horizontal is a very long road than a platform with certain purpose, it also makes it easy to sell. Just some thoughts.
Cool product, nice features, too important to rely on such a young company.
Sorry to be that guy, but I would never rely the business core on a company like that.
That's why I like Tooljet: https://www.tooljet.com (no affiliation) - they are open source. That mitigates the risk to a level that I'd personally accept.
Gamechanging. Built an internal admin tool with Superblocks in just a few minutes - definitely saved me hours of time and let me focus on building my core product. Congrats on building an awesome product already.