Live data from Hacker News

Ask HN: Experiences with low-code systems?

news.ycombinator.com

51–60 of 76 posts

Re: Ask HN: Experiences with low-code systems?

#51

I tested Retool a bit, which is great, but it is way too expensive for my projects, so I went with the open-source Appsmith instead. It has been successful, but I recently had to patch it to remove a new annoying «made with appsmith» ad on our applications that can only be disabled on the enterprise edition or if you edit the source code of the open source one and are willing to share your patch of course. Another im…

Creator of Appsmith here. First of all, thank you for trying the product and sharing your feedback. I appreciate it. While you can modify the source code to remove the watermark, you can also upgrade to the paid edition which helps keep the project sustainable. :) Additionally, you don't have to put in additional effort in keeping the fork up to date with our main repo. I understand that our choice of single Docker c…

I recently wasted a lot of time talking to salesmen who thought my (non profit research) company had bags of money to give away, and I decided to stop requesting quotes for SaaS because of that. I know that everyone needs to eat though, but it doesn’t soften the managers.

I wish you the best, you have a great product already.

Re: Ask HN: Experiences with low-code systems?

#52
post #16

Earlier quoted context omitted.

Curious if you tried Budibase? No annoying ad :-) https://docs.budibase.com/docs/kubernetes-k8s

Yes I did around December, from my notes I found it a bit more cumbersome to use for more than a few forms but I consider it a descent alternative.

Ahh. It's changed a lot. You should give it another try if you find a minute.

Re: Ask HN: Experiences with low-code systems?

#54
It's hard to think about because I feel like when they work I don't think about them at all. And when they don't work I think about and stew about them excessively. So the good cases I forget about completely and the bad ones are stuck in my memory.

SDLC is a frequent pain point. Often non-existent or hacky, e.g. export this giant XML doc and you can re-import it if needed. If any step requires clicking on buttons it generally leads to that kinda pain. Almost fundamentally, if I need to go copy paste or click on something for the product to work, I won't be able to automate it. Hence, it needs to be completely automatable. Similarly, if the config / set up / customization one does is obfuscated after it is specified it can be a headache to try to work around. Also maybe not the end of the world but many also decide to "handle" version control on your behalf, which can maybe be fine, but will also then almost by definition be divorced for your usual approach and processes.

On the last question, I think this boils down to how well can one operate at the surface level. It is not uncommon in these low code apps to have to understand in detail what is happening below the hood. So yeah, the top layer abstraction might be very simple in practice, but if working with it frequently necessitates me knowing how that abstraction will be executing it leads to an extra layer of complexity that has not abstracted anything. In a way they often function like a second language going through a translator: if I have to be considering the Spanish version the no-code cares about and also how and what it will be translated to in English under the hood, it's just extra confusing for perhaps little gain. What makes it extra pernicious is you can be operating entirely off intuition for what that under the hood English really is, rather than some open spec you can at least drill into.

Worst part here is I feel like this is really often something that will come with using the product. Often the use cases documented and sold really seem like all you'll need.

Re: Ask HN: Experiences with low-code systems?

#55

We evaluated trying to use appsmith for replacing our handmade admin panel but doing things like setting up pagination for databases was not particularly pleasant, basically writing raw sql with template strings. Yuck. Our app would’ve needed a bunch of new apis added to it to make it workable that we just weren’t willing to invest in at the time so we’re sticking with our plain html pages and smatteringgs of js for…

Disclaimer: I'm the creator of Appsmith. Thanks for evaluating the product. I appreciate it. The reason we allow users to write raw SQL within Appsmith is because it is geared to build dashboards and admin panels in scenarios where you don't have or don't want to write API layers on your database yet. Hence, this gives our users a balance of easy to start with & configurable to extend. You can always start with raw S…

Thanks for the response.

We considered starting with the raw queries and adding apis later, but unfortunately it just didn't make sense for us as it was ultimately less effort to just use our existing SSR rails views and we wouldn't have to dedicated more resources to augmenting internal tools even more, or managing the extra infrastructure needed for appsmith (hosted solution on other infrastructure was not an option unfortunately) - we don't use mongodb so adding it (for the appsmith datastore) to our infra was not something we really wanted to do either.

We did decide to revisit in the future as we are building some distributed services and appsmith might be a better fit then when we need to build a unified UI for all of our services.

Re: Ask HN: Experiences with low-code systems?

#56
I've been using Superblocks (https://superblockshq.com/) to do this.

I'm generally a fan of reducing complexity for building internal tools. We used to use Retool with a combination of Google's App Engine, Google Cloud Scheduler, and Mode Analytics to support our internal teams but we consolidated all of it under Superblocks.

They have charts, you can build backend functions (and call them on a schedule!), and you can build a UI just like you can with Retool (they have feature parity in most areas with Retool on the UI side).

The best part has been that they support Javascript and Python at the same time, which has let our data and engineering teams live in the same eco system and work together to build internal data tools for our team members.

Huge fan!

Re: Ask HN: Experiences with low-code systems?

#57

I've been using Superblocks ( https://superblockshq.com/ ) to do this. I'm generally a fan of reducing complexity for building internal tools. We used to use Retool with a combination of Google's App Engine, Google Cloud Scheduler, and Mode Analytics to support our internal teams but we consolidated all of it under Superblocks. They have charts, you can build backend functions (and call them on a schedule!), and you…

Thanks!

I'll take a look, I'm much happier in Python than JS so a big plus for me.

Re: Ask HN: Experiences with low-code systems?

#59

Disclaimer: I'm the creator of Appsmith. The primary reason for creating Appsmith was because, as a backend engineer, I didn't enjoy mucking around with HTML/CSS just to build admin panels. Hence, we created a way to build such apps really quickly. Appsmith also has a deep integration with Git. This allows you to create feature branches, raise pull requests and have different branches for your staging and prod enviro…

Great, thanks for responding! I'll be taking a serious look. I completely understand the motivation behind Appsmith, it's kind of exactly why I'm evaluating tools like these.

Out of interest, what proportion of your creators are engineers vs SMEs? Reason why I'm asking is that I'd be very nervous of letting non-engineers (without an understanding of just how much damage they could do) create write apps.

Re: Ask HN: Experiences with low-code systems?

#60

I tested Retool a bit, which is great, but it is way too expensive for my projects, so I went with the open-source Appsmith instead. It has been successful, but I recently had to patch it to remove a new annoying «made with appsmith» ad on our applications that can only be disabled on the enterprise edition or if you edit the source code of the open source one and are willing to share your patch of course. Another im…

Thanks for the detailed feedback! Yeah, I'm not a fan of the SSO tax (though I respect that they've got to eat).

Agreed on the all in one docker solution, it seems like a choice made to get things off the ground, not one predisposed to effective prod operations (storage being the major headache, though I assume there's not too much stored on disk).

Regarding the more complex application, do you think you could pinpoint what quality caused the low-code version to be too complex?

Post reply on HN