解释一下 require-any

原创
2016/05/02 18:38
阅读数 132

几天前有个小伙伴向我了解reactjs的一些问题,事后有感而发,写了一个简单类库,require-any,并且register上了bower。然而当我兴冲冲去告诉他,我写了个这个东西,你可以随时去学习reactjs了,他却回答:工作中没机会去用reactjs了。我顿时一脸大写的懵逼……

html的前端,是一个既理想又很残忍的职位,因为每天你都能看到各种新技术、新规范如雨后春笋般冒出来,可是自己手头的工作却是那么的现实,能用到这些新东西的技术少之又少,如果没有适当的导入手段,这些东西对于一个在职的前端来说,就如看客般,无情的在你眼前飘过,自己只能无动于衷。久而久之,心态就很疲了,再多的新技术,于我何干?

可是时代在发展,技术再进步,不断重新拆散再组合,世界是无情的。从html4/css2到html5/css3,用了15年有余的时间(我个人从2000年开始到今天,见证了这15年),这中间衍生诞生了多少的辅助工具?以今天的开源模式而言,以一个SDK/语言为基石,以整个世界的互联网(google)为平台,以代码和代码注释为语言,形成一个巨大无比的开源社区,这之后发展的步伐只会更快,而带来的改变、冲击、代码量只会更加猛烈、剧烈。

任何新技术、新规范都会有适合不适合的属性问题(适合团队与否,适合项目与否),也会有他自己的坑,这些东西不是光靠学习理论、做一点实验能知道,必须将这个技术导入到你的实际工作环境,做一定范围的实践(以用为目的实际操作),才能得出结论的。

其实所有目前前端技术架构,都是可以随心所欲的导入到现实的项目中的。前端工作的主要内容有三块:

  1. js
  2. css
  3. html
  4. 其他静态资源,图片,字体等。

这里排除掉静态资源。

js目前可切换的语言,有如:coffee-script、es6、typescript等。一个公司环境肯定有自己开发好的js类库,有基础的js环境,这些并不影响你,你照常在页面上引用就好了。

这之后,就是你自己的问题,假定你现在某个一个用户注册的页面,你开始了一个html页面制作,接着要写用户行为的绑定,这时候,你就可以导入上述的各种js的近亲脚本语言,那么如何导入呢?

从结果上看,只要你确保将你做的代码转换为js文件,加入到公司的项目中即可,让别人可以调用你的代码,出现问题的时候,你可以随时修改即可。

于是乎,你可以马上用任意你喜欢的的某个脚本语言进行开发,完成后直接转译为js即可。对于团队层面而言,关心的问题无外乎以下的几样事情:

  1. 保证按时按量完成任务,这是必须的。
  2. 保证别人能用你的代码。
  3. 当你不在的时候,别人有能力能维护你的代码。

所以实际上当你导出了js文件到项目中的时候,上述问题已经全部完成了,至于转译出来的代码很奇葩,看起来不像人写的,你告诉他:噢,亲,那是最规范的转译程序转译出来的代码,花点时间去学习吧,渣渣。

前端论其本质,还是一个程序员,程序员必须掌握一项技能,即无论何时,都能在任何位置植入你的代码,并可以无缝的混入现有环境,且不会影响和破坏现有的系统和接口,而让你的代码产生价值。这个能力既是实际操作能力,也是一种思维方式,你的这个技能等级越高,你现实价值就越高——因为这个世界没有等着让你从零开始做的项目,程序员每天的战斗就是不断植入各种体系中。

所以,何时这个技能醒悟,就是你作为程序员的天赋真正觉醒的一天。

——事实上,今天开源协议、开源社区、开源模式,实际上就是对这种植入的技能的充分演绎,开源只是确保每项技术体系都有足够开放的植入接口而已。

同理,html也好,css也好,都可以转译为最终的目标格式。尤其是git今天如此好用的情况,你完全可以本地git初始化一个项目,用git本地提交的机制即可,不需要push上服务器,项目完成后,自动转译出所有目标内容,而后导入到你公司、团队项目中即可。

作为事后的转译,或者实时的转译,现在有太多的辅助工具了,grunt、gulp等等。

而require-any,并不是让你去研究这货是怎么写的,而是让你去用,让你可以在开发过程无须等待转译的过程,而可以在线上实时加载你的写的各种js近亲文件,进行线上实时的预览,提高开发的效率。实际上更进一步的说,require-any提供了一种机制,你还可以写自己的转换器,处理包括如less、scss、stylus等文件。

最后说一句,程序不是学出来的,尽情的玩耍吧,小伙伴们。

展开阅读全文
打赏
1
4 收藏
分享
加载中
更多评论
打赏
0 评论
4 收藏
1
分享
返回顶部
顶部