同样的功能,你是倾向于框架 API,还是自己重写代码?

如果框架本身官方接受Pull Request的话
可以考虑重构目标API提交Pull Request
（但是如果这样做的话 需要考虑通用性问题

@Septembers 框架接受Pull Request,但是我的问题不在于是否修改框架,而是这两点之间的抉择问题.

@Septembers 如果框架本身能够很轻松的解决问题,那么一定选择框架提供的API,但是在框架不确定的情况下,是否可以先出一个版本,后期再进行迭代?
而且还是这种使用框架API与自己重构的成本基本上相同的情况下,如果选择框架,能很好的踩完需要踩的坑,但是浪费了时间.

@w88975 麻烦透露下编程语言

我只是好奇为啥要用一个beta不久的框架。。。

@Septembers polymer

@kongkongyzt 搞错了 是release

@w88975 既然接受pull request的话，你写得又比框架的好，那么你去发个pull request将你的版本合并进去，然后不久光明正大地使用了吗？

@w88975 = = 这个框架好像很熟悉的样子……
我看 Polymer 做出来的网页效果很好，虽然没有学过，但我倾向于根据自己的需求读官方文档，如果官方文档里没有，或者自己的需求超出了框架能做的，我会考虑再使用一些更加底层的方式写代码。
本人对前端的美观比较在意，所以肯定不会选择自己写，那么就先用 Polymer 做，实在没法用 jQuery 获取 Polymer 创建的 DOM 对象，然后进行操作……
= = Google Material Design 有一个 Bootstrap 主题…… https://github.com/FezVrasta/bootstrap-material-design , 如果是为了做出 Material Design 的界面效果而使用 Polymer，不如寻找其他可以显示 Material Design 的代码。

先修改自用，觉得可以就和官方讨论，不然就自己维护一套。
或者用这个为一个base class 然后extend你自己的API。
以前JQM不支持的tablet的时候就这么搞过。

@iskyzh 并不是UI方面,而是在JS框架方面,基本上没有用到polymer提供的控件,控件都是自己重新基于polymer做的.


@neoblackcap 首先是不至于为了一个很少见的需求去提pr,我最大的问题在于,如果框架提供的API仅仅能满足一点点需求,并且开发周期大于自己重新造轮子,这种情况下,是继续踩坑还是自己造轮子解决.

工期紧、框架完成度高并稳定，则用框架。

开源项目注重的是持续

@dallaslu 工期确实紧,但用框架需要踩很多坑,需要花时间去了解,反而比较浪费时间.

@88250 持续是肯定的,我想的是初期版本可以暂时自己实现,后期迭代的时候,如果能用框架则用框架.

@w88975
1.
你可以考虑自己做个 组件库，打包成一个project，单独维护
然后在项目中引入该 组件库
2.
目标API不满足又不希望提交poll request/issue
可以通过monkey patching的方法解决
（代价是API与文档描述行为不符合既定预期，
（从而造成维护困难
3.
开始你说公司不允许不使用API也就意味着，你没有对基础框架的调整权限。

选择一个可以充分扩展的框架……开源社区维护的可以贡献代码的就更好了

在可能的情况下尽量使用现有的框架,当然框架要符合成熟,开源, 社区好的条件,这样能享受很多人的智慧, 如果什么都是自己实现, 最后结局通常是重写, 特别是换人的时候

Polymer 感觉确实有坑... 特别是推开官方组件库从头重做的...