4 ms·

To hell! I'll throw myself to the lions. I make "Low Code" software and I think it's useful. It allows anyone who knows SQL to build real-time interactive HTML

To hell! I'll throw myself to the lions. I make "Low Code" software and I think it's useful. It allows anyone who knows SQL to build real-time interactive HTML tools: https://www.timestored.com/pulse/tutorial/pulse-interactive-table https://www.timestored.com/pulse/tutorial/pulse-interactive-... These people often only know SQL, so can't write javascript/html/react. The example video shows allowing them to create a live updating table that when clicked, draws a chart for that row. The best use-case is for prototyping many more apps than would be possible if they had to run every idea past a UI developer. Eventually some of those ideas get taken to full production based applications, many don't. I'm open to any and all feedback. If you think it's useless please say why and if you think there are better tools, well I would appreciate that feedback too.

k__ 3y ago
To me all software that requires minimal coding skills to use is low-code software. It's basically the job of a developer to move concepts that require coding through abstractions over to low code and then no code solutions. "Low code" or "no code" is just giving it another name, like when people started calling other people's servers "the cloud".
galaxyLogic 3y ago
Note that SQL is not no-code. You could say it is low code, but still it takes a "coder" to develop and debug it. It is a text-based format not GUI-based.
- rwalle 3y ago
  RyanHamilton did say it's "low code".
bob1029 3y ago
Fellow lion pit enjoyer here. We also use SQL for our product to deal with all the client customization needs. This has been our path for about 4 years now and we still haven't found a better option for our business. If you build a SQL schema and involve the business stakeholders in that process, you end up with something everyone can understand & work with. The difficulty of writing SQL scales in direct proportion with the complexity of the schema/domain. If the schema is something that is fundamentally familiar to your team, then you already have 80% of the "language" trained into your employees. At this point, showing them a few examples is all they usually need to "get it" and start doing things on their own. Inevitably, you will run into "how do I write a query that answers 13 questions at the same time and arrive at 1 final binary choice", and need to babysit with decomposition & CTEs. But even with some examples of those the team can begin to take matters into their own hands. In my experience, the joins are the hardest part. If you can, organize your problem such that even very inefficient nested queries can complete in a few milliseconds. We do things like run SQLite in-memory to achieve this outcome. Allow the team to do lazy crap and get shit done. You can always iterate the queries for quality later on - I think an LLM does this for us in our near future.
chrisweekly 3y ago
Prototyping -- and the code generated for that purpose -- needs to be distinguished from production-quality processes and deployment artifacts. This distinction (which is blindingly obvious to experienced engineers and product owners) is blurred or elided by most of the no-code / low-code sales and marketing materials I've seen. Your example of dynamic charting for data tables is useful; analyzing the performance characteristics and featuresets of enterprise-grade datagrid solutions (eg Ag-Grid, Bryntum) the chasm between a shallow one-off prototype and a properly-extensible and maintainable solution becomes more evident. Ignoring or attempting to bridge that gap with insufficient diligence leads to catastrophe. TLDR I think some of the hostility towards low/no-code tools is less "it's going to take my job" and more "it's going to make a royal mess of things in the hands of people who don't understand".

k__ 3y ago

To me all software that requires minimal coding skills to use is low-code software. It's basically the job of a developer to move concepts that require coding through abstractions over to low code and then no code solutions. "Low code" or "no code" is just giving it another name, like when people started calling other people's servers "the cloud".

galaxyLogic 3y ago

Note that SQL is not no-code. You could say it is low code, but still it takes a "coder" to develop and debug it. It is a text-based format not GUI-based.

rwalle 3y ago
RyanHamilton did say it's "low code".

bob1029 3y ago

Fellow lion pit enjoyer here. We also use SQL for our product to deal with all the client customization needs. This has been our path for about 4 years now and we still haven't found a better option for our business. If you build a SQL schema and involve the business stakeholders in that process, you end up with something everyone can understand & work with. The difficulty of writing SQL scales in direct proportion with the complexity of the schema/domain. If the schema is something that is fundamentally familiar to your team, then you already have 80% of the "language" trained into your employees. At this point, showing them a few examples is all they usually need to "get it" and start doing things on their own. Inevitably, you will run into "how do I write a query that answers 13 questions at the same time and arrive at 1 final binary choice", and need to babysit with decomposition & CTEs. But even with some examples of those the team can begin to take matters into their own hands. In my experience, the joins are the hardest part. If you can, organize your problem such that even very inefficient nested queries can complete in a few milliseconds. We do things like run SQLite in-memory to achieve this outcome. Allow the team to do lazy crap and get shit done. You can always iterate the queries for quality later on - I think an LLM does this for us in our near future.

chrisweekly 3y ago

Prototyping -- and the code generated for that purpose -- needs to be distinguished from production-quality processes and deployment artifacts. This distinction (which is blindingly obvious to experienced engineers and product owners) is blurred or elided by most of the no-code / low-code sales and marketing materials I've seen. Your example of dynamic charting for data tables is useful; analyzing the performance characteristics and featuresets of enterprise-grade datagrid solutions (eg Ag-Grid, Bryntum) the chasm between a shallow one-off prototype and a properly-extensible and maintainable solution becomes more evident. Ignoring or attempting to bridge that gap with insufficient diligence leads to catastrophe. TLDR I think some of the hostility towards low/no-code tools is less "it's going to take my job" and more "it's going to make a royal mess of things in the hands of people who don't understand".