4 ms·
That's only half the story. Bigger hurdles are the framework fatigue and the constant of having to keep things up to date even after you've got a "complete" pro
by spikej 4y ago
That's only half the story. Bigger hurdles are the framework fatigue and the constant of having to keep things up to date even after you've got a "complete" product. This is why you see shadow IT in the form of MS Access DBs and spreadsheets that (no matter how terribly implemented) won't die.
With no-code, those at least go away.
You're no longer having to deal with unnecessary complications of having to learn or deal with WebPack, etc, and you're no longer needing to stay in an endless cycle of dependency hell updates.
- sokoloff 4y ago> With no-code, those at least go away. Spreadsheets are no-code that works and has been for decades. No-code won’t kill spreadsheets.
- kcplate 4y agoHalf the time the feature requests I get for the product I manage can be summarized to “like…a spreadsheet”. I’m convinced that if the entire business world had its way, it would run entirely within an excel spreadsheet.
- mathgladiator 4y agoI've experienced this too, and it's a reason I'm building a reactive programming language. One way to think about it is a headless spreadsheet. https://www.adama-platform.com/ https://www.adama-platform.com/
- danielvaughn 4y agoI think this is there the real solution lies to this problem. We don't need another drag-and-drop, we need to change how we think about code. I'm building a "programming" language specifically for UI designers. I think high level DSLs are the future.
- spikej 4y agoI wasn't clear... I meant the hurdles go away. Spreadsheets from 90s versions of office still work just fine, whereas my nodejs app from last year is another story