3 ms·

The problem with something like this is that it's a moving target. People in 2000 were saying visual editors couldn't match hand-written code, and were right a

The problem with something like this is that it's a moving target. People in 2000 were saying visual editors couldn't match hand-written code, and were right at the time. But I would happily use today's visual editors instead of hand-writing 2000s websites, using only the tools available in 2000, if all I wanted was a 2000-level website. But so far, every time we've made things more powerful - even if it makes it easier to have a good visual editor - it's also pushed the frontier of what a bespoke experience can give you.

kiawe_fire 5y ago
And this is true in many sub-domains as well. Even things like CSS frameworks. If you’re doing something trivial, or solving a couple of specific use cases, then a framework full of CSS classes that give you Twitter-looking cards or a no code solution that helps you send an email every time a user clicks a “subscribe” button IS helpful. But the problem is, once you’ve used the tool for that initial problem, you’re stuck with it. And inevitably, if your thing is successful at all, you will outgrow that tool quickly and need to start making bespoke things to keep up. I say this not out of gate keeping either - I say this as an overworked full stack software developer who would LOVE to be able to provide a CSS framework or a visual editor to my co-workers and have them produce long term solutions. But as soon as they find some tool and ask me to help adopt it, it works for them for a couple use cases, and then guess who’s stuck trying to make it work with all the fancy new things we need that then requires extending the tool or working around it entirely?