选择html还是脚手架作为demo？

你想培养客户的什么信心，让他以为你明天就能完成任务的信心么？

正因为他不停地催问你界面的事情，才让你有足够的资本可以跟他讨价还价。

Joel曾经说过：不要先去完成界面，因为在很多用户看来，完成了界面，就等于功能也快完成了。而要让功能和界面的开发保持同步最好。

按书上说的，用铅笔和纸

我也是html+js做demo，够用了，页面也出来了，我们还能有空想想怎么建库表

应该根据项目性质况以及客户情况决定，不可一概而论！

是这样的，这个就是看自身水平和时间的权衡了， 或许能做出来完美的demo给客户演示， 但不得不考虑花费的时间。
而且一般情况下，html+js, 客户都能接受的。

在国内不能这么干的，首先用户不会签署任何需求层面的确认文件。

所以要想不把项目做砸，界面必须给用户看。

在国内这么做还有个重要原因是，国内信息化程度低，甲方和乙方的业务分析师往往都是在探索新领域，因为具有中国特色的需求嘛，所以双方都有可能碰到需求陷阱而对各自的上级交不了差。所以确认界面是非常重要的一个确认需求合理性，和系统可操作性的过程。

支持Html方式，demo就应该当作售前项目来做，从成本上考虑不要加入后台代码，因为刚才说了当项目来做，界面的需求也会一改再改，甚至于推翻，一旦牵涉到后台代码，效率肯定低下。html打包后可以邮件发给客户看，客户也能很方便的用这个demo作其他用途（100%对他有用），每次都要去部署的话，效率太低了。

题外话，这也是应该选择JS客户段框架的理由，前期demo就可以介入，后期拿来就能用，非常非常节省人力，服务端生成JS代码的方式就很难做到这样高效的操作流程。

你用脚手架做demo要花时间啊。在小公司，可能这些时间就是正式开发的时间。

做过很多对日项目
他们demo基本都是html+css+js

我觉得，两者都有优势。
如果客户是内行，更关注与业务逻辑，和执行效率，那用脚手架更好。
但如果客户是外行，更关注页面设计，对业务逻辑更集中在流程方面。那还是用html比较好。
或者说，同一个项目可以用两个。比如业务流程，可以用html。
涉及到具体的复杂部分，可以用脚手架来做。

这东西完全不必要争论，各有所长，没有最好的，只有针对某具体问题最适合的。

软件开发原则,在分析设计阶段，就算是用html+css+js，可只需要显示到业务原型部分就行了，美观的事情应该是之后具体实施的时候来做的。
如果客户在分析阶段就要对页面有要求的话，那页面也已经作为初级需求的一部分了，自然你在交付需求分析或者详细设计的时候，页面这部分也要给他了