3 ms·

If no-code is the future of programming, here are some pain points I have with existing no-code tools that they need to fix: - no automated testing - no deplo

If no-code is the future of programming, here are some pain points I have with existing no-code tools that they need to fix: - no automated testing - no deployments other than to production (to be fair Retool supports being deployed into two environments… but some teams where I work have three) - no history (e.g. git) - logging is a pain (imagine if the logs for each microservice you deployed had to be viewed/searched using a different tool… yeah…) I’m not saying they don’t have their advantages… but where I work we want to move away from Zapier and Airtable because of the pain they cause us.

raman162 5y ago
> no deployments other than to production Yah unfortunately where I work has 4 different deployments. 1. Sandbox for the devs to do whatever they please 2. Environment for the acceptance testing of features 3. Stable environment that mirrors production for sales and training 4. Production environment
deepsquirrelnet 5y ago
ETL tools are what came to mind for me. To some degree, we can already observe no-code examples like you mention in engineering fields. So far, the driving force behind no-code is the limitations of the overall workforce. Data engineering is a field that is desperately needed in many companies, but without a sufficient workforce to meet the demand. > no-code has the potential to massively improve the day-to-day lives of programmers In this, I don't agree at all. It is not an improvement to someone who can write code to do anything they want, and force them to learn the quirks and limitations of a no-code environment. How many engineers want to spend their days managing broken configurations rather than solving problems? Simple things are often simple, but hard things become impossible. What then? Going back to data engineering -- what I see is a large percentage of jobs that don't even require programming as a skill. How many people with more than 5 years of experience will apply to these specialized tools-based positions? What happens to the problem solving capabilities of your teams? You may achieve a fully replaceable workforce when you take this path, but you also accomplish a brain drain. Worse for engineers -- as these tools fail to meet the needs of business, they come and go like fads. Unless you want to learn a new set of tools and their limitations every 2-3 years, it is impossible to remain employable in certain fields. To me, no-code is exactly the wrong direction. Knowing how to solve problems in code is one of the most valuable skills for modern work. The problem lies in our education system, which has not embraced that it is as important as the "three R's". Efficiency of work would be greatly improved if more people knew how to write code (at least scripting) than if fewer people did.
Msw242 5y ago
These are all absolutely solvable. We're building a low-code internal tool builder with features meant to address these drawbacks that keep nocode from scaling. I'm sure others are too.
tchock23 5y ago
Zapier and Airtable != to a full no code platform like Bubble. While your critique of automated testing is valid, the others are largely solved. Even integration testing can be done with third party tools. Bubble is awesome if you have a fairly simple CRUD app that isn’t likely to have millions of concurrent users. Most of the best devs I know are bored to tears of building those kinds of apps anyway, so no code has a nice niche in that ‘in between.’
yaaang 5y ago
Not true for all such tools. Though like a sibling comment suggests, part of the issue is that no-code is defined too broadly to include everything under the sun. I work on a no-code tool that checks those specific boxes (shameless plug: https://www.plasmic.app https://www.plasmic.app), but the use case is very different from Bubble. The key is that it explicitly doesn't try to replace all code, and was designed from the ground up to integrate deeply with existing codebases. I don't think we need be the only one, other tools can also do the same. But this aspect is by far the most complex part of building this product. That, and the pressure to create vendor lock-in is real.

raman162 5y ago

> no deployments other than to production Yah unfortunately where I work has 4 different deployments. 1. Sandbox for the devs to do whatever they please 2. Environment for the acceptance testing of features 3. Stable environment that mirrors production for sales and training 4. Production environment

deepsquirrelnet 5y ago

ETL tools are what came to mind for me. To some degree, we can already observe no-code examples like you mention in engineering fields. So far, the driving force behind no-code is the limitations of the overall workforce. Data engineering is a field that is desperately needed in many companies, but without a sufficient workforce to meet the demand. > no-code has the potential to massively improve the day-to-day lives of programmers In this, I don't agree at all. It is not an improvement to someone who can write code to do anything they want, and force them to learn the quirks and limitations of a no-code environment. How many engineers want to spend their days managing broken configurations rather than solving problems? Simple things are often simple, but hard things become impossible. What then? Going back to data engineering -- what I see is a large percentage of jobs that don't even require programming as a skill. How many people with more than 5 years of experience will apply to these specialized tools-based positions? What happens to the problem solving capabilities of your teams? You may achieve a fully replaceable workforce when you take this path, but you also accomplish a brain drain. Worse for engineers -- as these tools fail to meet the needs of business, they come and go like fads. Unless you want to learn a new set of tools and their limitations every 2-3 years, it is impossible to remain employable in certain fields. To me, no-code is exactly the wrong direction. Knowing how to solve problems in code is one of the most valuable skills for modern work. The problem lies in our education system, which has not embraced that it is as important as the "three R's". Efficiency of work would be greatly improved if more people knew how to write code (at least scripting) than if fewer people did.

Msw242 5y ago

These are all absolutely solvable. We're building a low-code internal tool builder with features meant to address these drawbacks that keep nocode from scaling. I'm sure others are too.

tchock23 5y ago

Zapier and Airtable != to a full no code platform like Bubble. While your critique of automated testing is valid, the others are largely solved. Even integration testing can be done with third party tools. Bubble is awesome if you have a fairly simple CRUD app that isn’t likely to have millions of concurrent users. Most of the best devs I know are bored to tears of building those kinds of apps anyway, so no code has a nice niche in that ‘in between.’

yaaang 5y ago

Not true for all such tools. Though like a sibling comment suggests, part of the issue is that no-code is defined too broadly to include everything under the sun. I work on a no-code tool that checks those specific boxes (shameless plug: https://www.plasmic.app https://www.plasmic.app), but the use case is very different from Bubble. The key is that it explicitly doesn't try to replace all code, and was designed from the ground up to integrate deeply with existing codebases. I don't think we need be the only one, other tools can also do the same. But this aspect is by far the most complex part of building this product. That, and the pressure to create vendor lock-in is real.