The problem with all these no-code/low-code tools is that they are not Turing complete. Wherever you need to do something custom, you have to write code.
Show HN: Superblocks – IDE for Internal Apps, APIs and Cron Jobs
81–90 of 102 posts
Re: Show HN: Superblocks – IDE for Internal Apps, APIs and Cron Jobs
#82I 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.
(Creator of Superblocks here)
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.
Re: Show HN: Superblocks – IDE for Internal Apps, APIs and Cron Jobs
#83Earlier quoted context omitted.
Are you looking for specifically to write code in say your own IDE like VSCode and we build a VScode extension?
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.
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.
Re: Show HN: Superblocks – IDE for Internal Apps, APIs and Cron Jobs
#84Earlier quoted context omitted.
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.
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.
Re: Show HN: Superblocks – IDE for Internal Apps, APIs and Cron Jobs
#85The problem with all these no-code/low-code tools is that they are not Turing complete. Wherever you need to do something custom, you have to write code.
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:
Re: Show HN: Superblocks – IDE for Internal Apps, APIs and Cron Jobs
#86Earlier quoted context omitted.
Are you looking for specifically to write code in say your own IDE like VSCode and we build a VScode extension?
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.
(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.
Re: Show HN: Superblocks – IDE for Internal Apps, APIs and Cron Jobs
#87Earlier quoted context omitted.
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 si…
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.
Re: Show HN: Superblocks – IDE for Internal Apps, APIs and Cron Jobs
#88Earlier quoted context omitted.
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 si…
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!
Re: Show HN: Superblocks – IDE for Internal Apps, APIs and Cron Jobs
#89Earlier quoted context omitted.
What is the license you are using? If your intention is not to allow this, you could switch to AGPL.
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 to…
No post body was provided.
Re: Show HN: Superblocks – IDE for Internal Apps, APIs and Cron Jobs
#90I 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.
(Creator of Superblocks here) 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, permis…
Thanks for confirming.