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

一般的客户在刚开始往往不了解自己到底想要什么样的软件，随着项目的一步步进行，他们会根据实际完成的部分逐渐理清头绪，提出进一步的要求。
有一种说法就是，“真正的需求是在第一个版本完成的时候产生的。”用户在看到完整的成品后，才首次理顺了自己的思路，然后在成品的基础上对功能进行删减。
为了让客户更早明确自己的需求，还是应该根据最初的模糊需求制作出一个demo来，为客户提供一个实体做参考，来进一步细化需求，避免前期的返工。这个最初的demo是交付静态html页面还是由grail那种脚手架生成的crud程序呢？

我倾向于使用脚手架生成的动态程序。
第一，脚手架生成的代码，可以模拟基本的动态功能，也可以保证所有的链接都是完整的，添加测试数据可以直接在笔记本上给客户演示。而静态页面会有很多无效链接，对演示和客户体验造成障碍，影响客户输出更详细的需求。
第二，脚手架生成的代码，更贴近程序员，为数据库进行初步建模就可以生成所有的依赖关系，而静态页面更依赖于美工，这里也考虑一个付出的时间代价，同等量的页面，是自动生成快一些，还是由美工做快。对于crud部分的页面具有很大的雷同性，应该是自动生成更快，这种页面由美工来制作会产生很多无效链接。
第三，为demo生成代码的数据库建模，还可以为以后细化建模提供依据，而美工做的demo太粗糙，以后改动很大，感觉等于让美工做了无用功，之前demo的部分很少为以后的开发阶段服务。

但，使用生成代码也有缺点，如果使用html，可以直接交给客户，让他们在本机使用。要教客户在本机配置环境运行代码就太难了。只能采取需求人员带自己机器，陪客户一起操作（是否为客户和需求人员造成不便？）。或者发布到公网服务器上，让客户直接访问公网服务器上的demo进行试验操作。（是否有安全保密问题？）

以上想法，偏向于局域网内部程序，对美工排版没有很复杂的要求。应该不适合公网项目对页面要求很复杂排版的情况。

我倾向于用html，用这个沟通客户很好，修改非常方便。
客户可不愿意看到粗糙的界面，第一印象都不好，以后沟通就很难认可你的东西。

我们公司一直用html来做，编写方便，一直也在用。不过看了楼主说的grail，我准备试试了。看看到底哪个好。

LZ说的对业务复杂程度较大（及以上）的在我看来没有太大的作用。

demo应该是可快速实现的、易修改的、直观的。用grails是不是有些门槛，用html则实现起来太简单了，我只要关注业务逻辑和易用性就行了，就好像是橡皮泥似的，可供我随意蹂躏 呵呵

看用户的需求、水平了，如果用户不担心性能问题的话，html吧。

用脚手架最好先去搞一个好一点的模板.

举手赞成一个
如果你的客户很明白开发是怎么回事，也能理解第一阶段是确定功能需求而不是美化界面
那么用rails脚手架能事半功倍
如果你的客户就是很在意界面的布局，那么就老老实实用html吧

脚手架有个前提，你的数据库设计需要基本定型，但实际情况大多数是你在做demo的时候，数据库根本还没有开始做，要知道将客户需求转换到真正的数据库设计也是设计阶段一项重要的工作。
换个角度讲，大部分客户，肯定是注重界面多些，他才不会管你后台是什么东西。

我倾向用html，客户其实不理解demo的真实意义。所以他们一旦看到有一个界面粗糙的demo，当时就急了，才不管之前他签字确认的进度表呢，会不停催问你界面的事情。而且会严重打击客户的信心，以后我们就会很被动了