> That event (or part of a store, or however it's implemented) already has to be defined in code (even if it's just a stub) by the time you're making the UI.

> That event (or part of a store, or however it's implemented) already has to be defined in code (even if it's just a stub) by the time you're making the UI. That's a good point. A visual tool for building components will need a testing feature that can keep all those stubs. But isn't that just like Test-Driven Development? > It's also starting to approach the difficulty of just learning to code in the first place. Not at all. In any design, you'll have to think about all the cases thoroughly and systematically; and any rational people can do that. But coding in a general purpose language has the additional requirement of having a mental model of the execution platform and conveying precise instructions; it's not enough to think in terms of the problem being solved. That makes all the difference to people without coding experience. The syntax of programming languages is particularly tricky and difficult to learn. The people working with Chris Granger, the designer of Light Table, found that users of visual development tools find it incredibly difficult to understand scope. And coding in any modern general PL is all about scope. You may think of this kind of visual environment as a particular Domain Specific Language. The users are coding in it, but the programming language is not general purpose, which makes it not "coding" as developers understand it. > I can imagine the tool exporting some kind of interface with a list of things it needs (project-wide, across different components), that the developers would then implement BTW, the mockup tools I'm talking about already offer that kind of interfaces to define the list of coding requirements generated by the user interface prototype. They cough up that list of requirements as a Word document or web page, though. Wouldn't it be best to generate those as placeholders in code?