问个问题，感觉大家都不看好javascript模板，为什么？

就算是JST好像也不热。
为什么？
不成熟？
UI库不够丰富？
路子偏了？
搜索引擎问题？
非主流？
不知道如何用，如何和你的应用结合起来？
不喜欢这种编程方式？
可笑的小玩具，不上档次？
............

你的
客户端模板语言-----我该如何驾驭你.
和
javascript 模板的思索
以及你在 leebai 写的
从JSF和Ext看WebUI开发－－给对JavaScript 有恐惧感的朋友
一文中的回复我也看了

但是一直没有发表看法, 因为你之前在给我的PM里说了这样一句话
"前提是您对jCT有认同感，要不如就成拍砖了，我喜欢有共识的讨论，不喜欢对立的争论"
弄得我比较忌惮.
其实我觉得你对 客户端模板语言的定位有点偏差
你对B/S解偶的理解似乎也和大家所讨论的不太一样

其实leebai对你的几个回复还是多少能说明一些问题的.


而且我一开始在给你的pm里也提到过
这类东西和 组件与框架相比,并不能做到更好的帮助开发者解决所面临的主要问题.
所以关注的人自然就少了.

你一方面承认 jct这类东西不是框架, 只是一个工具, 而另一方面,你又希望他可以发挥框架的作用,支撑起客户端的页面编程. 这个似乎有点矛盾吧? 当然 也可能我又会错了你的意思.

另外 既然你承认这类东西只是一个工具, 那么你可以想一想, 大家会很热烈的讨论 struts spring ext ,但是很少有人回去讨论这些框架里的 utils类的设计和使用吧?

谢谢了。
我明白了，是我的思想不能引起大家的共鸣.我关注的内容过于细微，小巧，独立，基础到了最小单元而不是全面的工具（框架），功能简单到独立什么也做不了必须和别的配合才行，愿意DIY的少，都想要整机。
其实我对整个web的开发有自己的一套看法和方案。
当然这个方案就不说了，因为从javascript模板不受欢迎就可以猜到我的想法也不会让大家认同的。
好在我有一个小团队，他们认可我的想法（目前包括我才3个人）。
我还是继续关注我的团队吧！
继续实践我的想法吧！
毕竟现在才刚刚正式投入第一次实战（以前有过一次不过不够系统）。
第一次的项目预计用1个月时间完成（5月8日完工,1个页面，1个整体策划和小偷，我来负责前后台搭建，代码几乎是从零开始写的）。
做完后发出来，希望大家能批批！虽可能仍然不被大家认同，但是我知道交流总是需要的。

js模板出现很多年了 为什么一直没有流行起来
你有没有想过呢?
另外 很多客户端的框架都有类似的模板机制,只是和你这种不太一样,没有那么多强大的语法,他们为什么没有做足够强大的模板,而是只是做到"点到为止"?

你对js模板的研究应该是比较深入的 能否谈谈你的看法?

我很尊重你的工作,也相信你的那个计划和项目应该能够比较成功的实现
但是如果你希望有更多的人认同你的观点 还有很长的路要走

我倒觉得lz可以看一下GWT，使用GWT操作html模板，那种感觉要比js好多了。

先回答这个。
所有后台操作模板的方案，我都不会去仔细研究的。因为那都是有平台限制的。
GWT是JAVA的，其他的语言的也有.
我本身是phper,在phper中有真正两年以上经验的程序员，自己搞个后台的模板，那就根玩一样。这个不是吹，到php社区转转就知道了，我自己也做过一个，是静态php模板（就是由源模板编译成php代码，以后就不用在解析模板了的那种）
只所以做前台javascript模板就是这原因。（现在做js模板仍然是可编译的）
因为事实是对于web应用，不管你后台用什么平台，前台目前就是javascript的天下。
对于我来说做前台模板还有一个目标就是：
后台最终用本地机器码执行，也就是c/c++/D来制作的exe程序是我最终的目标。
未来谁知道你的服务器是否是一个手机或者单片机呢？

==================
fix:此论点错误，偶不了解GWT
==================

发现你的思路总是很理性，很少有情绪化的东西，我就没有这么好的性格，偶还是那种
干吗？
不干！不干就算了。
干！那现在就干吧。

正题:
我觉得应该先说说我对WEB开发的看法。
WEB应用自身具有几个特征（随便说说，不是什么总结性的言论）：
1.广泛
应用的广泛性。这个不用解释了，企业级的应用都WEB化了（或者说是B/S化）
2.多变
客户总是变来变去，如果你做的是C/S，C是桌面程序的话，客户说变，你说你不能这样，估计客户就会妥协，
可是WEB不一样，几乎是客户说变，你就要实现，小到调整个颜色，字号，大到布局，内容。
3.团队
C/S开发很多都是一个人就搞定的。WEB开发不行，多数都要几个人（团队）配合，因为他涉及的内容多：
html,css,js,flash,全文搜索，后台代码，存储，服务器安全..........还要根应用相关的专业问题，比如流媒体服务,网络硬盘
4.平台
看看C/S结构，最常用的开发平台,c/c++,delphi,PB,java(这个其实不算完全),几乎都是window服务器平台
B/S的就不用举例了，多如牛毛。主流服务器平台就有两个,Xnix,windows
5.成本
WEB开发成本很高呀，服务器，存储，带宽，这是硬的，软的就不说了，就在上面4条中

如此混乱的一个局面，我们能做什么来避免再投入，减少整体成本？
我认为要从开发策略上下功夫，具体方法无外呼我们已经知道的2个基本原则：
1.一段代码（一个库，一个工具）只负责一个事情
2.工具要简单，学习成本要低，改造要容易，如果是在原有（应有知识）下学习更好。
另外就是
减少团队的沟通，沟通是必要的，但是因为配合的问题不停的沟通效率就不好了。

还有就是，如果你新成了了一个公司（或项目），你要招人，以下技能的人你是必须的。
html,css,js,falsh,美工
这是web开发共性的职位。
相反,对于后台程序员。
你是招java,php,c,ruby,asp,.net..............那一类呢？
你说当然是.........
呵呵，你需要5个这样的程序员，可你一下子招不到，你怎么办！
另外就是你真的需要招这么多么？他们都是在干后台应该干的活么？
不是，对于WEB开发，后台通常都在做前台的活，html这个职位几乎就是后台程序员的傀儡，让你干啥就干啥，让你等等，你就要等等。

看看这几年框架的发展和更迭，框架一直都在做什么工作，不是应用的业务逻辑，是前台表现。
你不让前台干前台干的活，后台干后台干的活，这个局面很难稳定，我认为他们现在做的才是路子错了。

在我说的2个基本原则上在加一条吧
3.分离,开发流程要分离，这一直都是MVC追求的东西，可惜，MVC搞砸了，因为他是MVC,而不是
一个M,一个V,一个C
MVC把流程分开了，却没有把自己分开。我要彻底的分离，任何一个都是独立的，可以拿出来和别的工具配合。

这样下去我们最终将获得的是

自由

平台，流程，团队，工具都自由了。

至于对js模板的研究，自吹一把，我的模板引擎是最容易改造的，一共就两个函数，所有的语法规则标记都清清楚楚的放在那里，如果谁喜欢把+--+换成{}或${}只需要改两处代码就搞定。

关键是我做js模板的目的是要"分离"这个目标。

你的这种想法我很认同. 我也是这类思想的倡导者
(可是很遗憾 由于个人能力和精力所限,没有机会去做一个类似的产品来证明这种思想的可行性与正确性)

只是我觉得js模板语言可能会帮助我们达到这种解藕的目的,但是它目前看来并不是最好的.性能 通用性 易用性 组件化这几个方面还不够.

类似EXT这种本身有着完善的组件模型和数据模型,代码通用性很强, 功能丰富的框架也可以实现这种前后分离的设计.

开发人员真也许真的更喜欢ext这类东西吧.

以前我也是研究过js模板的,当然没有你研究的深入,不过确实是"研究过",而不是简单的看一看.当时是从 springside的官方文档里看到了对一个jstemplate组件的介绍,于是下载 使用, 并研读了代码,还自己做了一些扩展和完善.
但是后来没有在正式项目中使用过.
原因就是我反复强调的: 1 性能不足, 2 组件化程度不高.

当然,也许我可以将js模板和ext之类的组件组合.但是结果也许是这个样子:

我编写模板语言, 让js来解析这些模板语言, 生成html+js ,这些js是ext的代码
在运行时生成组件.

但是这个过程显然有些冗余. 不如直接写ext的js代码了.

to fins:
你说的这个启发了我。
我要想想，模板语言难道只是做html表现转js对象，然后装配数据么？他不能干别的么？
估计有难度，先当作个遐想吧！

兄弟，先麻烦看看在说。
GWT的确是java的，但是他不是在后台执行的，他的最终代码是js，js是在前台执行的。