确信，fastm一定会作为一种模板开发标准流行起来。
当然，其间必定会遭遇习惯和成见的巨大阻力，毕竟，fastm的作者只是一个名不见经传的无名之辈。但fastm终会胜出，只是时间早晚而已。
一旦fastm的知名度超过某个阀值，fastm必将以星火燎原之势攻城掠地，争夺所有“复杂”模板技术的用户。
短期来看，fastm消灭了复杂，就等于消灭了大量的商机。fastm本身又如此简单，提供不了足够的新的商机；技术作家连写《fastm in Action》的机会都没有，因为fastm的定义和用法都太简单了；而且fastm极大地降低了Java Webapp的技术门槛，是否会令Java Web程序员贬值？fastm对 Java 开发阵营有什么好处？
长期来看，fastm能够帮助Java开发阵营夺回ASP.net在Web开发领域夺走的领地，改变两大阵营的力量对比。
fastm足以与Visual Studio.net（ASP）相较，甚至更胜一筹。
fastm模板不需要任何特殊的支持，就能够在普通浏览器中“所见即所得”；ASP模板必须在Visual Studio.net中才能正确显示（而且是以form的形式显示）。
fastm模板比ASP模板简单多了。从用法来说，甚至比其源头PHP模板还要简单。使用fastm，大量的PHP程序员可以直接转到Java Web开发阵营，而不用学习那些庞杂复杂的新模板技术。
JSR-223是一个Java与PHP等脚本语言（还有Perl，Python，Ruby，Tcl）等互操作的JSR。http://www.jcp.org/en/jsr/detail?id=223 目前正处于初稿审定阶段。
这从另一个方面说明，fastm生逢其时，直接为Java和PHP程序员提供Java Native的PHP改进模板。
至于fastm是否会令Java Web程序员贬值。我想，可能会让某些复杂技术的专精高手（比如JSP调试高手，各种TagLib使用高手）贬值。但fastm不会令解决真正问题的高手贬值，相反，fastm会帮助这些高手把精力更集中在解决真正的问题上。
关于目前如火如荼的JSF，我很高兴看到这个功能强大的开发框架的出现。
但说实话，我不认为，TagLib可视化拖放开发足以和Visual Studio.net（ASP）竞争。那等于以己之短，较人之长。
而且，一个潜在的危险是，Java Web开发框架将被引上一条微软倡导的“C/S结构、桌面客户端”的不归之路。
目前的一个趋势是，B/S开发框架尽量向C/S开发框架靠拢。
几乎所有的现代Web开发框架都在努力地追求着基于事件机制的处理方式——把前台页面组件和后台处理代码绑定在一起。
Visual Studio.net的ASP开发工具是一个典型的类C/S的B/S开发结构。JSF的Webapp开发工具部分也亦步亦趋，跟着走上了这条路。
不仅在服务端的开发框架存在这种趋势，在客户端这种趋势也愈演愈烈。继ActiveX，Applet之后， XMLHTTP，FLEX等新一代的“浏览器插件客户端技术”方兴未艾。
开源社区Mozilla提出并支持XUL技术。微软的LongHorn 64位操作系统提出“桌面即浏览器”（其实等于宣告浏览器的消亡），力推XAML。
HTML不被双方看好。HTML前景堪忧。
一种可能性：将来HTML很可能只作为一种历史资料的记录格式而存在，而不会作为应用程序的UI存在；而HTML浏览器也只将作为一种历史资料查看器而存在；HTML B/S Webapp时代结束。
可以说， B/S Webapp正是毁于自身越来越复杂的内需和开发结构。
B/S Webapp的界面的互操作性要求越来越强，浏览器需要支持的特性越来越多，附带的插件也越来越多（Java Script，ActiveX，Flash，XUL）。既然这样，为什么还用浏览器？Web Service协议比HTTP协议格式更完善，直接用Web Service客户端不是更直接，更彻底？
微软把握并引导这个趋势，Java世界也做好了两手准备。
无论是Visual Studio.net，还是JSF，其重头戏都是支持Web Service应用程序开发。毕竟，Web Service是属于未来两年的技术。
Web将变得越来越来越强大，无处不在。Semantic Web更有效地把整个Web资源组织为一个巨大的文档库、数据库、资料库和服务库。在这个大好形势下，主角将是各种Web Service Agent，而现在正当红的主角——HTML B/S Webapp却面临着将来（几年）出局的可能。（呵呵，先别急着说这是危言耸听，我只是假设这样的可能性）
倾巢之下，岂有完卵？
如果HTML B/S Webapp消亡了。大量的HTML TagLib就随之淘汰了。Tapestry，XMLC，Echo也随之淘汰了。
XML + XSLT的项目也许还能够幸存——比如，改造XSL，输出XUL或XAML。
fastm当然也会幸存——fastm也能够“所见即所得”地生成XUL和XAML。只要有动态生成可视化XML UI的需求，fastm就有用武之地。
如果B/S Webapp注定要退出历史舞台，fastm也无力挽救，但fastm至少可以拖延这个过程。fastm极低的技术门槛能够吸引大量的页面开发人员，留连在HTML B/S Webapp的领域里。
而且，fastm既属于现在，又属于未来。既可以用作构建现在的HTML、WML UI，也可以用于构建将来的XUL、XAML UI。
在这样的朝不保夕的严峻形势下，为什么不选择fastm呢？^_^
当然，其间必定会遭遇习惯和成见的巨大阻力，毕竟，fastm的作者只是一个名不见经传的无名之辈。但fastm终会胜出，只是时间早晚而已。
一旦fastm的知名度超过某个阀值，fastm必将以星火燎原之势攻城掠地，争夺所有“复杂”模板技术的用户。
短期来看，fastm消灭了复杂，就等于消灭了大量的商机。fastm本身又如此简单，提供不了足够的新的商机；技术作家连写《fastm in Action》的机会都没有，因为fastm的定义和用法都太简单了；而且fastm极大地降低了Java Webapp的技术门槛，是否会令Java Web程序员贬值？fastm对 Java 开发阵营有什么好处？
长期来看，fastm能够帮助Java开发阵营夺回ASP.net在Web开发领域夺走的领地，改变两大阵营的力量对比。
fastm足以与Visual Studio.net（ASP）相较，甚至更胜一筹。
fastm模板不需要任何特殊的支持，就能够在普通浏览器中“所见即所得”；ASP模板必须在Visual Studio.net中才能正确显示（而且是以form的形式显示）。
fastm模板比ASP模板简单多了。从用法来说，甚至比其源头PHP模板还要简单。使用fastm，大量的PHP程序员可以直接转到Java Web开发阵营，而不用学习那些庞杂复杂的新模板技术。
JSR-223是一个Java与PHP等脚本语言（还有Perl，Python，Ruby，Tcl）等互操作的JSR。http://www.jcp.org/en/jsr/detail?id=223 目前正处于初稿审定阶段。
这从另一个方面说明，fastm生逢其时，直接为Java和PHP程序员提供Java Native的PHP改进模板。
至于fastm是否会令Java Web程序员贬值。我想，可能会让某些复杂技术的专精高手（比如JSP调试高手，各种TagLib使用高手）贬值。但fastm不会令解决真正问题的高手贬值，相反，fastm会帮助这些高手把精力更集中在解决真正的问题上。
关于目前如火如荼的JSF，我很高兴看到这个功能强大的开发框架的出现。
但说实话，我不认为，TagLib可视化拖放开发足以和Visual Studio.net（ASP）竞争。那等于以己之短，较人之长。
而且，一个潜在的危险是，Java Web开发框架将被引上一条微软倡导的“C/S结构、桌面客户端”的不归之路。
目前的一个趋势是，B/S开发框架尽量向C/S开发框架靠拢。
几乎所有的现代Web开发框架都在努力地追求着基于事件机制的处理方式——把前台页面组件和后台处理代码绑定在一起。
Visual Studio.net的ASP开发工具是一个典型的类C/S的B/S开发结构。JSF的Webapp开发工具部分也亦步亦趋，跟着走上了这条路。
不仅在服务端的开发框架存在这种趋势，在客户端这种趋势也愈演愈烈。继ActiveX，Applet之后， XMLHTTP，FLEX等新一代的“浏览器插件客户端技术”方兴未艾。
开源社区Mozilla提出并支持XUL技术。微软的LongHorn 64位操作系统提出“桌面即浏览器”（其实等于宣告浏览器的消亡），力推XAML。
HTML不被双方看好。HTML前景堪忧。
一种可能性：将来HTML很可能只作为一种历史资料的记录格式而存在，而不会作为应用程序的UI存在；而HTML浏览器也只将作为一种历史资料查看器而存在；HTML B/S Webapp时代结束。
可以说， B/S Webapp正是毁于自身越来越复杂的内需和开发结构。
B/S Webapp的界面的互操作性要求越来越强，浏览器需要支持的特性越来越多，附带的插件也越来越多（Java Script，ActiveX，Flash，XUL）。既然这样，为什么还用浏览器？Web Service协议比HTTP协议格式更完善，直接用Web Service客户端不是更直接，更彻底？
微软把握并引导这个趋势，Java世界也做好了两手准备。
无论是Visual Studio.net，还是JSF，其重头戏都是支持Web Service应用程序开发。毕竟，Web Service是属于未来两年的技术。
Web将变得越来越来越强大，无处不在。Semantic Web更有效地把整个Web资源组织为一个巨大的文档库、数据库、资料库和服务库。在这个大好形势下，主角将是各种Web Service Agent，而现在正当红的主角——HTML B/S Webapp却面临着将来（几年）出局的可能。（呵呵，先别急着说这是危言耸听，我只是假设这样的可能性）
倾巢之下，岂有完卵？
如果HTML B/S Webapp消亡了。大量的HTML TagLib就随之淘汰了。Tapestry，XMLC，Echo也随之淘汰了。
XML + XSLT的项目也许还能够幸存——比如，改造XSL，输出XUL或XAML。
fastm当然也会幸存——fastm也能够“所见即所得”地生成XUL和XAML。只要有动态生成可视化XML UI的需求，fastm就有用武之地。
如果B/S Webapp注定要退出历史舞台，fastm也无力挽救，但fastm至少可以拖延这个过程。fastm极低的技术门槛能够吸引大量的页面开发人员，留连在HTML B/S Webapp的领域里。
而且，fastm既属于现在，又属于未来。既可以用作构建现在的HTML、WML UI，也可以用于构建将来的XUL、XAML UI。
在这样的朝不保夕的严峻形势下，为什么不选择fastm呢？^_^
扫一扫
481
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
