发起了一个Javascript开源MVVM框架

woodheadz

上周打算在项目中引入MVVM框架，研究了下现在流行的几个框架，感觉要么过于复杂，要么实现方式让人不太舒服。
于是趁周末自己做了一个，结果感觉还不错，有潜力发展成一个很棒的MVVM框架。干脆就放到Github上，打算以MIT协议开源发布。
我把这个框架取名为knot.js. 因为MVVM框架的使用过程最重要的部分就是在数据和UI之间“打结”把它们绑成一堆  :-)

比较目前流行的几个javascript mvvm框架，knot.js的特征是：
1. 注入式，不要求对数据对象做任何改变。你甚至直接可以用来自服务器的JSON对象作为你的model，knot.js会自动建立监控，当数据改变时更新自动UI。而目前的javascript mvvm框架大多要求修改model，甚至要求从指定对象继承来产生model才能以支持双向绑定。

2.超级轻量。目前压缩后的代码核心+扩展不足12k，但已经能实现45k大小的knockout.js的大部分功能，实际上做得更多，比如knot.js提供了非常方便的数据验证支持。

3.简单。knot.js避免在html标记中加入太过于复杂的逻辑，转而提供很方便的javascript扩展模块引入机制。不把用户限制在一堆复杂而功能有限的语法内，让程序和标记做各自最擅长做的事。


下图是一个常见的增删改界面，包括数据录入，修改，删除，各项数据合法性，重复性验证, 以及界面上各个控件的状态控制（enable, visible， 选中状态...）等等。用knot.js不过一点简单的代码就能搞定。

登录/注册后可看大图

black_zerg

Very interesting!
Would you like to share your opinions on MVC, MVP and MVVM?  
Since this is a MVVM framework, would you like to draw a diagram to explain the implementation ?  

'注入式，不要求对数据对象做任何改变。你甚至直接可以用来自服务器的JSON对象作为你的model',
does that mean the view-model is always a dynamic one? how you do data-binding then?

woodheadz

black_zerg 发表于 30-9-2013 09:40

                               
登录/注册后可看大图

Very interesting!
Would you like to share your opinions on MVC, MVP and MVVM?  
Since this is a M ...

框架一般都有个特点，就是解决的问题越多，框架本身就会越复杂，学习成本越高，适用的情况越少。当然一旦用对了，威力也就越大。就knot.js的定位来说，和knockout.js的定位基本上是一样的，偏轻量，避免涉及太深层次的问题，仅仅关注于数据和UI之间的绑定和同步。

knot.js和其它mvvm理念上最大的一个不同点在于：目前的mvvm框架都有个特点或者说是趋势，就是越来越倾向于把逻辑放在标记中。一些大的框架比如angularjs，甚至还可以在标记里进行数学运算运算。 我认为这是明显的过渡设计。这种做法的确能进一步减少javascript代码量，但减少的其实部分以一种更难看的形式分散出现在标记里。html标记本来就够乱七八糟了，再摆一堆由各种奇葩符号包起来的逻辑进去还真是嫌世界不够乱！  
knot.js 的解决方案就是"converter".  举个例子，比如要显示利润，小于零的时候红色，大于则绿色。
在knockout.js里你要这么做：

1. <div data-bind="style: { color: currentProfit() < 0 ? 'red' : 'black' }">
   
2.    Profit Information
   
3. </div>
   
4. 
   
5. <script type="text/javascript">
   
6.     var viewModel = {
   
7.         currentProfit: ko.observable(150000) // Positive value, so initially black
   
8.     };
   
9.     viewModel.currentProfit(-50); // Causes the DIV's contents to go red
   
10. </script>

复制代码

在knot.js里你这么做：

1. 
   
2. <div knots="style: { color: *currentProfit =>profitValueToColor}">
   
3.    Profit Information
   
4. </div>
   
5. <script type="text/javascript">
   
6. var profitValueToColor={to: function(value):{return value<0?'red':'black‘;}}
   
7. </script>
   

复制代码

knot.js的做法的好处在于首先，你的转换逻辑可以重用，一旦需求发生变化，比如从红色变为绿色那么改一个地方就好。其次这个转换的逻辑复杂程度knot.js没有任何限制，用js代码啥都能做出来，knockout.js限制就很大了。所以knockout.js经常得根据显示的需求在model上创建些属性进行转换。


关于knot.js怎么完成数据双向绑定，说起来神秘，其实是个不值钱的小trick。 knot.js内建了个键=>值列表，每个绑定的数据对象在表中都有一个对应的附加信息，数据更新时的callback就存在这个附加信息上（此外还有数据的验证结果也在上面）。当值发生改变的时候取出callback函数call一遍就完了。现在还有个不大完美的地方就是如果在代码中修改值，需要用Knot.setValue来更改，不能自己直接用object.property的方式，否则界面不会更新。这本来也能解决，让knot在绑定的时候修改数据对象把原来的property替换成Knot监控下property即可。但我对于这点还有疑虑，主要是担心如果用户没有解除绑定就序列化数据到服务器或者worker线程里的话，数据会不会有问题。所以暂时没这么做。

black_zerg

"一些大的框架比如angularjs，甚至还可以在标记里进行数学运算运算。 我认为这是明显的过渡设计"
I totally agree with that. Actually I basically against the using of '标记'.

I see you have a lot of great ideas. Still I believe to make a good framework, a solid design on the data flow is essential (a diagram at least).

For example, since you called it a MVVM framework, you might want to explain how you implement these 3 parts, how they work together, what are the base class for each part(if you are using prototypical class) and how to extend them.

Actually I am biased as I am not fond of 2 way data-binding. I think it won't be flexible enough when things get complicated.

I fear some frameworks just make simple things easy and difficult things impossible

woodheadz

black_zerg 发表于 30-9-2013 12:37

                               
登录/注册后可看大图

"一些大的框架比如angularjs，甚至还可以在标记里进行数学运算运算。 我认为这是明显的过渡设计"
I total ...

不可极端化。
标记里面写太多逻辑不是好做法，但不用标记，以代码来完全控制UI也不是好办法。最好的做法必然是两者间的一个平衡点。我之所以重新设计一个mvvm框架，最重要的原因就是因为不认可其它框架所选取的平衡点。
knot.js里标记的作用被严格限定为“绑定”，也就是做一个代码和UI属性之间的关系定义。 这个定义很明显放在标记端比放在代码段优势大得多也灵活得多。
two-way-binding是必须的，只要有UI录入，你必然不可避免这个逻辑的存在。不用two-way-binding意味着你的代码量会有一堆event handler,那才是设计的灾难。

black_zerg

I don't agree. I would prefer HTML is HTML, CSS is CSS and JS takes care of dynamic logics.
The fact that Jquery is so popular has proved that we can create sophisticated apps without fancy data-binding or in-line tags. and in most really life cases, people are quite happy about that.

Let s look at the problem at a higher level, the view is supposed to be isolated from the 'domain logic' or 'binding logic'. I don't see why having ugly tags in html is a good thing. I was never a fan of struts, webwork or JSF, and so happy when I found AJAX makes life so easy. Now I see people are bringing these old clumsy designs to JS world, just makes me sad.

'two-way-binding是必须的，只要有UI录入，你必然不可避免这个逻辑的存在'. That is a good point. I would agree there must be some glue logic to fetch data from server (Model), then populate them to HTML DOM tree(view). In MVC, the logic is in controller; in mvp, it is in presenter; in MVVM, it is supposed in ViewModel. However I would suggest the 'GLUE' logic needs to be inside code as we can't guarantee the fancy background magic always fits the needs. because the 'glue' logic are not always the same.

Still, I am very interested in your project. Maybe you can explain your idea from a high level when you have time.

As I said before, my experience about 2 way data-binding is normally it makes simple things easy and difficult things impossible. And since it is a 'framework', during project development, you can't simple stop using it when the framework doesn't fit the need, doesn't improve productivity or becomes a burden. Then the team will have a long and painful fighting with the framework until everyone is exhausted.

black_zerg

Sorry forgot to explain my point, I think a 'lib'  is more useful than 'framework'. for example we can create a 'Form' widget which does 2 way binding to a json object, a 'List' widget works with 'Form' widget and bound to a json Array. something like that would be useful.
I am more interested in creating 'component' rather than 'framework' unless I am certain one way of 'data gluing' is always better than another.

woodheadz

black_zerg 发表于 30-9-2013 15:00

                               
登录/注册后可看大图

I don't agree. I would prefer HTML is HTML, CSS is CSS and JS takes care of dynamic logics.
The fa ...

其实high level的东西都很简单，我们都了解需要一个你说的glue logic存在，这其实不需要讨论。此外我们也明白系统逻辑之间要尽量降低依赖性，这也是不需要讨论的。

所以关键的问题上是这个逻辑该以什么方式存在。

现在的框架对于这个问题倾向于尽量用标记解决，你倾向于用代码解决，而knot.js，也就是我的观点是在你们二者的中间。

我认为这个glue放在标记里优势是极其明显的，无论是从降低工作量的角度说还是从增加可维护性的角度说都是如此。所以我不同意你的观点。

但其它MVVM框架的观点我也不同意。他们实际上是想完全通过标记来描述数据对象<=>UI 对象之间的关系。这听起来很酷，但实际上数据对象和UI对象之间的关系也是非常复杂的，可能有大量的业务逻辑在里面。而标记本身的纯逻辑描述能力就很弱，你非要用它来描述逻辑那不是吃饱了撑的么。

knot.js就是彻底只解决“glue”这个问题，可以把东西glue到UI组件上，但这个东西不一定直接就是数据。中间你可以粘converter和validator，再把converter，validator粘到数据上。

把knot.js的做法拔高务虚的来说，就是knot.js的世界里 不是只有m=>v, 而是还有 m=>vm=>v。 其它的mvvm框架试图通过标记来完成vm的部分，而knot.js把vm的部分完全放开用javascript实现，把自己的角色单纯化，只负责规划组织的部分 ，然后把自己变成一个好用的“glue”。

woodheadz

black_zerg 发表于 30-9-2013 15:27

                               
登录/注册后可看大图

Sorry forgot to explain my point, I think a 'lib'  is more useful than 'framework'. for example we c ...

component和framework直接我觉得也是有个平衡点，我不偏向任何一方。所以我不喜欢太过于复杂的框架，但我同时认为框架也有自己不可替代的重要作用。

woodheadz

woodheadz 发表于 30-9-2013 15:27

                               
登录/注册后可看大图

其实high level的东西都很简单，我们都了解需要一个你说的glue logic存在，这其实不需要讨论。此外我们也 ...

对了，忽然come up了一个knot.js的宣传口号：
Give to code what is code's, and to markup what is markup's.
怎么样？ 哈哈

black_zerg

Markup in html simply doesn't make sense to me.

A HTML Dom element IS a component it self, it has it's view and model API (same as VM in MVVM).
If required, developer creates a new new component(Class) to wrap a list of elements. So it will be reused in a similar scenario.

'Creating' the component and 'Using' the component are 2 different tasks. Mixing them only make the code looks very confusing.

woodheadz

black_zerg 发表于 30-9-2013 15:44

                               
登录/注册后可看大图

Markup in html simply doesn't make sense to me.

A HTML Dom element IS a component it self, it has ...

我发现你的想法和我想法的区别可以归结到你前面提出的“component”和framework的问题上。

我猜你可能在潜意识里有这么一个误区，认为component 和framework是两种相互对立的概念。其实不然，这两者之间根本没有任何冲突。
component解决的是具体的问题，framework提出更多是一个解决问题的思路，组织系统的办法，比component宏观。这两者描述的是两个不同层面上的问题。

一定程度上，你说framework是“using component”是正确的，但这里不存在“mix”的问题，因为framework不是component。你愿意自己为每个项目的每个ui组件编写代码当然没问题，但如果你觉得这些重复劳动是无价值的工作，那么为什么不把这些工作丢给framework来解决呢？

woodheadz

black_zerg 发表于 30-9-2013 15:44

                               
登录/注册后可看大图

Markup in html simply doesn't make sense to me.

A HTML Dom element IS a component it self, it has ...

纯粹从设计哲学上来说说这个问题：
component可以视为是对一个具体问题的具体解决办法的重用包装， 而framework是对一个解决问题的方法论的重用包装。
你为了using component而创建的“component”，一旦做到了重用，那么就是framework。因为你包装的对象不是某个具体的component,而是如何使用component的方法。

black_zerg

let me put is in this way:


A component is design to solve a certain problem. It doesn't make sense to create one component to solve all problems.
Because that means you API will be very complicated and become the 'Problem'.

Every time we create a component, we basically make the API simpler to better fit our needs. But at the same time, the system will become less 'powerful' or 'flexible' if you like.
Now the question is: Doesn't it make sense to create a component(Class) for the Whole application (which will be a Framework). My answer is no because I feel the current APIs (HTML, js, css, etc) are necessary because of the variety of my requirement. I am not convinced a subset of these APIs is good enough.
It is like in OOP programming, you need to decide when & when not to create a Class.

for example, what if the new app is not using JSON at all, what if the new app needs some UI component that your data-binding logic doesn't fit?

My suggestion will be, say if you are very interested in data-binding and view-model concept, you just create Widgets(component) to do certain things.

Those framework guys been working on their frameworks for years. I am interested in their presentations and feel they are very smart/passionate. but would not use their frameworks personal because I don't see much value except creating GDP.
Now you think your solution is better and more concise, but when new requirements comes you will have to add more and more logic. Your API will grow fat I am afraid.

black_zerg

woodheadz 发表于 30-9-2013 15:57

                               
登录/注册后可看大图

我发现你的想法和我想法的区别可以归结到你前面提出的“component”和framework的问题上。

我猜你可能 ...

The reason I said that was because I value the quality of a component(Class), once it is created it needs to stable, predictable and has very clear and well designed functions (API).

When working with those frameworks, you have to create a lot of half baked 'components', and you have to use some weird API which is more difficult to understand than the natural DOM.  

woodheadz

black_zerg 发表于 30-9-2013 16:57

                               
登录/注册后可看大图

let me put is in this way:

大哥，我前面讲了framework不是component。另外framework也不是solve all problems的。
这里面有个度的问题，过犹不及，不足也有不好。 我就是嫌其它的js mvvm framework解决问题的范围过度了，所以才自己又重新做一个出来。

具体到你说的例子，knot.js既然支持json对象，那么当然也能支持普通对象。 knot.js对UI component支持接口很简单，你自己创建一个对新UIcomponet的扩展也只是举手之劳。

就像你用面向对象去写hello world会增加很多不必要的复杂性一样，你用framework去解决简单的小问题也会增加复杂性。 但是随着你系统的的扩大和复杂程度的增加，使用framework带来的好处很容易就能盖过framework增加的复杂性。这就是为什么在中大型项目里或多或少都会采用一些framework的原因。 其实现在的小项目用framework的也很多。

framework应用起来自然是要比单纯使用component要求要高些，所以使用framework失败（带来的坏处比好处多）的例子的确不少。但这不是framework的问题。

技术一直在进步，从过程化到对象化再到组件化和框架化，每一个进步都在增加复杂度，因为每一个进步其实都是提出了新的方法而不是推翻了前面的方法。例如面向对象的程序内部一定也有很多过程化的逻辑，所以面向对象技术必然比过程化技术复杂。
你不能单纯的因为复杂度增加来拒绝一项技术，你要看承受这个增加的复杂度后收益是否值得。我建议你还是可以放开对framework的成见去尝试下吧。

woodheadz

black_zerg 发表于 30-9-2013 17:05

                               
登录/注册后可看大图

The reason I said that was because I value the quality of a component(Class), once it is created i ...

我理解你对使用framework后带来的这种“不安全”的感觉。 这不是错觉，事实上的确存在。如果系统的需求远远超出了framework的能力，那么会带来很严重的问题。
所以我一向不大喜欢太过于复杂的framework，那样风险会增加。另外在一些特别的场景下，贸然使用framework也是很危险的。
我们公司的产品在我进入公司的时候大量的使用了wpf内置的绑定framework来进行渲染，导致效率很低。我进入公司半年后提出来的重构方案第一个就是移除wpf绑定，自己来写viewmodel层。最后完成后极端情况下效率提高了90多倍。 但这是一个产品项目，另外这个项目里只有核心的渲染部分移自己建立了vm层，其它普通的ui全部还是用的wpf绑定，因为实在是很方便，很好用。

这里面就是一个度的问题。程序员最核心的经验和价值所在，也就在这个度的选择上。

black_zerg

Cool, keep up the good work then! I will be following your project. Later I may implement your demo in my way then we can compare. Quite happy to find someone interested in js and innovation

woodheadz

black_zerg 发表于 30-9-2013 19:15

                               
登录/注册后可看大图

Cool, keep up the good work then! I will be following your project. Later I may implement your demo  ...

  
的确可以用不同的方案实际做做，比较下

woodheadz

black_zerg 发表于 30-9-2013 19:15

                               
登录/注册后可看大图

Cool, keep up the good work then! I will be following your project. Later I may implement your demo  ...

我刚才很仔细的想了想为什么会有不少人觉得用了framework有点不够安全。
结论是很多framework都是个复杂的大黑盒子，一旦出问题，即便绝大多数时候都是使用的人自己的问题，但要找问题的话跟踪调试的时候到了framework里面就不行了。 framework和component又不一样，component一般只会在运行过程的一端，你只要确保进入component之前没问题或者处理component的事件响应没有问题就OK，而framework往往存在于一次代码运行过程的两端，有时候中间还要占上几段。这样要调试找出问题来就头疼了。

所以呢，我决定为Knot.js增加一个debug模块，让knot.js的内部运行状态白盒化！ 这个模块将作为附加模块存在，正式发布的时候可以排除，基本不会增加文件大小

black_zerg

just created a simple demo to mimic yours.
http://glue.atwebpages.com/

There is no validation logics yet but you can see the idea. I really don't like the in-line markup thing. That is messing with the view, and very intrusive.  

black_zerg

woodheadz 发表于 30-9-2013 20:51

                               
登录/注册后可看大图

我刚才很仔细的想了想为什么会有不少人觉得用了framework有点不够安全。
结论是很多framework都是个复杂 ...

主要的问题是，使用框架的风险是很大的。如果是库，我今天用了，明天发现不对头我还可以换，而且如果库有问题，一般很容易发现。但整个程序按照框架来建的话，项目做到一半发现这个框架问题很多，或者说文档不行，程序员没搞明白作者思路，代码混乱了，这时候就悲剧了。就像我上面说的，框架都是做简单的东西（或者说在看作者的例子）的时候，觉得狂容易。头疼的时候都是在后来，因为实际项目中什么千奇百怪的要求都有可能出现，而且团队的话，每个人思路和技术背景都不同，多数情况下还是用原生接口保险。就好象大家都说英文并不是说英文多优秀，只不过这玩意通用。
我为什么讨厌html写标记就是因为这玩意不伦不类，又不是规范语言，可能很简洁，但不见得好懂，更不要提调试。 其实代码最后并不是拼简洁，清晰易懂更重要。

用框架还有一个最可恨的地方就是代码逻辑跑动的很厉害，往往一个流程跳跃好几个文件，出了问题难查得很。 若干年前我用struts用得不亦乐乎，后来发现随便干点什么事都得有五六个文件参与。仔细一想早年用jsp的时候一个文件就解决了。开发的时候还没什么，维护系统帮别人改bug的时候就想跳楼了。

我很赞同你的这个加强logging的想法。不过真的要推广框架还是很难的。你做两个很好用的widget我还会更有兴趣。你想想那么多 MXX的框架，都是有团队在嗨哟嗨哟的折腾，实话说我看也就那么回事吧，增加GDP而已，不然大家没的事情干。

不过这个精神我还是很佩服的，这年头有点兴趣的人不多了，都是混日子。

woodheadz

black_zerg 发表于 30-9-2013 22:56

                               
登录/注册后可看大图

just created a simple demo to mimic yours.
http://glue.atwebpages.com/

嗯。 你这个demo不错。
刚好可以和用了框架的比较下。 你这个demo基本上没有去处理数据验证和控件的状态控制这些烦人的问题。但已经比使用框架的代码量多得多。这里还没包含你凭空写的东西的时候设计代码工作流程和组织代码的成本。这个例子比价简单也许很低，但如果是个更复杂的界面，这个成本也不小。

凭空写的demo的代码量和可阅读性可维护性是完全不能和使用了框架后的来比较的，还有团队里各个成员因为编码风格和喜好不同带来的隐性成本。

程序员都不会太喜欢markup，但如果你要和设计师合作，那就不同了。把你的这个demo放在一个设计师的面前让他去做设计处理，他一定会崩溃的。

woodheadz

black_zerg 发表于 30-9-2013 23:09

                               
登录/注册后可看大图

主要的问题是，使用框架的风险是很大的。如果是库，我今天用了，明天发现不对头我还可以换，而且如果库 ...

那么多的框架，刚好就说明框架本身很有用，是大家的兴趣热点。
你说的框架的问题我理解。用好框架本身也是个很有技术含量的活儿。但所有的问题最后都归结为你的投入是否值得产出。
其实面向对象技术也是一样的。用不好的人比用得好的人多得多，因此产生了大量的过度设计和丑陋代码。也有人因此认为面向对象不过是花式。 这和你对framwork的观点是一样的，太偏激了。

回到knot.js上来说，我之所以会强调knot.js的注入性，限制Knot.js的范围，就是为了让knot.js在任意时候都能方便的退出。 和java里面那些动不动就涵盖整个程序生命周期的大框架不同，knot.js 对系统的控制极小。你不信可以试试，在我的那个demo的基础上,把初始化用的knot.tie()注释掉，整个Knot.js就从你的系统里消失了。 你会发现你不用修改任何东西就可以直接用你喜欢的方式加入javascript来完成整个功能。 你退出knot.js的成本几乎为0.  
另外Knot.js也能和你的自定义代码共存。你完全可以在knot.js不能帮你解决问题的地方彻底使用自己的代码来完成工作嘛。

你对框架的印象看来还只停留在java里面那些控制欲超强的大框架上。这个世界上的框架可不都是这样的哦

black_zerg

我从来没说不可以造framework，我的观点是第一如果没有理论基础，我们很难折腾出比别人好的东西。所以我才再三问你你的基本思路架构是什么，怎么个MVVM法。
MVVM的话，最重要的部分就是ViewModel,因为基本上大部分的胶水逻辑都会在这里。
我的代码是随手刚写的，基本上基于MVC。 因为我很久不做crud了，也没怎么仔细想过这个事情。 但是我还是相信动态的页面逻辑，就用纯JS解决比较好。HTML和CSS去解决布局和静态的。

设计师对我的demo为什么崩溃，你看了源码了么？就是两个div而已。相反的如果都是mashup夹在html里，那才要崩溃。


‘你完全可以在knot.js不能帮你解决问题的地方彻底使用自己的代码来完成工作嘛’ 你看到这句话的问题没有，如果是类库，那么这话就是合理的, 代码也不会太难看也好跟。那如果你做框架，让一个团队以这个为核心开发，那这个就会变成一个很伤人心的事。我以前的一个项目就是所谓databinding,这东西你说他不管用吧，他也管点用，你说他管用他又不全管，总之就是他那套东西，我们也得巴巴的写，然后还有一大段手写代码或者workaround, 一个增删改就是一堆文件，模板还有手写代码，每个人的解决方案可能还各不相同。如果几个实体类有点关系，要在界面上显示这个层叠，就比登天还难。打电话找支持，他说你这个需求不对，不应该这么用。客户要求这样，那我们能说客户要求不对么？简直就是渣。他那个databinding当然更牛b一点，一直要绑到数据库表，改它的流程是极痛苦的。这时候我整天想的就是如果让我写jsp操一下表，我分分钟就解决了

当然了，一个项目大家修修改改做了几年，也不是坏事，要看你怎么看了。但是要说这玩意提高生产力，那就是笑话。

当然每个人看法都是主观的从自己经验出发，我只是觉得这玩意很难搞，也许你能做个更好的或者说起码很适用你的情况的，那还是很有可能的。

woodheadz

black_zerg 发表于 1-10-2013 00:08

                               
登录/注册后可看大图

我从来没说不可以造framework，我的观点是第一如果没有理论基础，我们很难折腾出比别人好的东西。所以我才再 ...

我当然是看了你的源码才这么说的。

就两个div， 设计师打开你的网页，什么都看不到。他怎么设计？
你的每个录入框在什么地方？ 如果他要往上加css怎么办？要调整位置大小怎么办？ 你列表中动态创建的的项目，如果他想往里面加一个图形背景该怎么办？
夹在html里的markup丝毫不影响html设计。所有的HTML设计软件都会自动忽略这些不认识的tag，并且原样保存。

我的理论基础前面也和你讲过了，就是把vm里面的胶水部分和业务逻辑分离，把业务逻辑回归代码。 比着现有的js框架，我自然是有突破。你可以拿和我这个框架最接近，同时也非常流行的Knockout.js来比，knot.js的优势是非常明显的。我相信我能折腾出比knockout.js好的东西，实际上我这个用一个周末折腾出来的东西就已经在很多地方比knockout.js好了。

我觉得咱们这个讨论有点往于口舌之争的方向发展了。我们还是不要去讨论什么framework和component， markup和code比较好。这些问题太虚，讨论不出什么结果的。

还是讨论具体的技术问题比较好。

black_zerg

其实我们证明各自的观点很简单的，等你的东西做得差不多了，我们来找一个复杂的例子，然后去实现，这样就好比较了。最好是有点用的东西，比如content management system 之类的，我们可以一起做一个开源的来玩玩。

woodheadz

black_zerg 发表于 1-10-2013 00:30

                               
登录/注册后可看大图

其实我们证明各自的观点很简单的，等你的东西做得差不多了，我们来找一个复杂的例子，然后去实现，这样就好 ...

这个问题不大。我现在在做我们公司的online版本。里面的UI交互会全部采用这个框架，到时候上线了你去看吧。

black_zerg

你说的很有道理，回头我来修改我的代码，让流程做到方便设计师。

woodheadz

black_zerg 发表于 1-10-2013 00:08

                               
登录/注册后可看大图

我从来没说不可以造framework，我的观点是第一如果没有理论基础，我们很难折腾出比别人好的东西。所以我才再 ...

你还是很牛，业界流行了这么多年的框架理念在提高生产力方面可以被你批成笑话。

我没你那个高度的认识，我一向对框架兴趣都不小，我自己负责设计任务的几个大项目里都有各种框架的使用，我觉得效果大多不错。当然也许我做那些项目不过也是笑话而已