• 标签流 VS 脚本流


    搞过点前端,玩过几个框架之后,基本都会发现框架在设计上的一些套路和流派,今天给大家扒一扒其中的两个书写流派标签流脚本流

    我们以一个button按钮为例:

    这样裸写HTML标签的方式基本没法儿复用,功能和样式都太弱鸡了。搞项目基本没人会这样干了

    最常用的Bootstrap框架的写法:

     

    仍然是HTML标签为主体,结构一目了然,按需配置样式,事件得靠自己加。它的结构、样式、行为完全分离,有一定有复用价值。但是用过Bootstrap的都知道,基本就是对着官网例子复制’‘粘贴,真干起重活来还是很低效。

    然后有了封装度高一点的jQueryUI,写法大概是这样的:

     

    jQueryUI是比较尴尬的,看着像标签流的写法,有声明式的标签,但属性绑定都在js中依赖options的配置,这又是命令式脚本流的干法,既要写HTML,又要写js,复用性也不是那么方便。

    再看看封装度最高的ExtJS,标准写法长这样:

     

     

    这是标准的命令式写法,完全不用写一行HTML,框架已经全封装好了,需要用的时候随时new 一个button实例就好了,所有的方法人已经替你准备好了,只需要你按需求写完配置就可以了。其实在这种封装度下,你基本上已经不需要懂HTMLcss,甚至javascript了,认得已经单词就能学个七八成了。看起来很美好是吧。但是!!!这时候老板突然说,你把这个按钮上给我加一道光吧,blingbling的那种。怎么办?你把文档从头翻到尾,我能怎么办?我也很绝望啊。

    这里就很容易看出来了,标签流的写法以HTML为核心,脚本流的写法以js为核心,脚本流的东西用起来爽,改起来烦,标签流的写法正相反。早期做网站 美工负责出界面,后端程序员负责套模板,php里甚至可以直接写HTML不要太爽,至于js特效什么的在网上随便扒一个就是干,所以大家基本都是标签流的写法。后来web应用火起来了,页面全走前端渲染,脚本流靠js包打天下的写法又火了。

    有什么办法能结合标签流可读性和脚本流复用性这两方面的优点呢??拿目前最火的前端三大框架为例,最早的AngularJS1.3版本)是这样写的:

     

    HTML中使用自定义标签<my-btn>提供了一个挂载点创建元素,自定义属性看起来直观用起来方便,复用性相当好。不过这种写法在js中定义组件是比较有难度的,写法比较恶心。后来就出来了React,用ES6的写法是这样的:

     

    React的理念非常简单又特立独行,你又想要标签又想要脚本?简单啊,我把HTMLjs合在一起做一门新语言,叫JSX,所以React的代码里看起来既有标签又有脚本。这种组件化的搞法应该说还是目前最强悍的思路了。当然有人不喜欢JSX那种all in js的拧巴的写法,又有了大家喜闻乐见的Vue,写法是这样子的:

     

    标签用法和Angular基本一样,脚本写法则更像React。果然是前端界的一股清流啊。

    目前来说,我感觉标签流的写法在组织架构和易读性通用性上会好一些,web pageweb app基本都能干,只是组件搞复杂了之后满屏的bindmodel实在太烦了。React功能强大,不过jsx+babel编译玩得有点过火,调试和可读性比较麻烦,有时想干点猥琐的事情很难下手。

    所以要怎么选呢?如果你是设计转前端,标签流上手容易,如果你是后端搞前端,毫无疑问脚本流更方便!

  • 相关阅读:
    winfrom 中datagridview中checkbox的使用方法
    转 webservice中参数类型为datatable,报错“生成 XML 文档时出错”
    Oracle将表空间改为自动扩展
    Oracle 动态建立分区表
    运用ASMIOSTAT脚本监控asm disk磁盘性能
    ASMCMD命令
    select * from salgrade for update和select * from salgrade for update nowait区别
    Oracle 10g Block Change Tracking特性
    分佈式事務故障處理暨ORA-24756: transaction does not exist處理
    shell test 數值 字符串 文件比較
  • 原文地址:https://www.cnblogs.com/xuange306/p/6742058.html
Copyright © 2020-2023  润新知