最近,Qwintry开发团队把很多项目都迁移至vue.js,包括所有遗留的项目和新开始的项目:遗留的Drupal系统(qwintry.com)新的qwintry.com分支,该分支是对旧有项目的彻底重写基于Yii 2的B2B系统(logistics.qwintry.com)其它大大小小的内部和外部项目(大部分使用PHP和Node.js作为后端)Qwintry在全球有差不多五十万用户,我们在美国和德国各有一个仓库,而且我们是美国最大的货物转运公司,业务主要面向东欧和中东地区。简单地说,我们帮助上述地区的人们购买美国网上商店的商品,并帮他们节省跨国运费。我们使用自己的IT系统和物流系统为他们提供高质量的转运服务,而且费用是非常实惠的。我们的系统有很多代码,大部分是PHP和JS代码。我们分别使用React、vue.js和Angular 2构建了一个用户计算器作为对比实验,经过比较之后,我们最终决定采用Vue.js。React.js之我见React的出现震惊了JS世界,几乎成为JS开发的首选框架。我使用React构建了一些单页应用和动态控件,我也玩过React Native(iOS)和Redux。我认为,对于面向状态的应用来说,React再合适不过了,而且React为我们提供了真正的面向函数编程。React Native在很大程度上改变了原生应用的开发。对我来说,React的不足之处在于:纯净、不可变性和解决问题的意识形态不要误解,我其实很感激React所带给我们的纯净的函数编码方式和简洁的渲染手法,在实际应用中,这些都算得上好东西。我想说的是其它方面的东西。如果你的公司里有千人开发团队,而刚好你决定要为PHP里的静态类型开发自己的语法,又或者你正从Haskell转向JS,那么一定程度的严格和纯净是非常有用的。不过大部分公司不会有那么大规模的开发团队,也不会有Facebook那样的宏大目标。下面我会更详细地解释这一点。JSX糟糕透了我知道,它 不过是具有特殊语法的javascript罢了 。我们的前端设计人员为了做出漂亮的表单,把表单元素放置在div里面,他们根本不关心什么纯净或ES6。设计React组件仍然需要耗费大量的时间,因为JSX的可读性太差。还有一个不好的地方,就是你无法在html代码里使用普通的IF语句。React的忠实用户会告诉你说,有了三元运算,就不需要再使用条件判断了。不过我向你们保证,当你再次阅读或编辑这些代码时,你会发现它们仍然是HTML和JS的混合体,尽管它们可以被编译成纯粹的JS。 ul {items.map(item = li key={item.id} {item.name} /li )} /ul 很多开发者认为这种严格的限制可以帮助我们写出更加模块化的代码,因为我们必须把代码块放到工具函数里,并在render()方法里调用,就像这个人建议的那样:http://stackoverflow.com/a/38231866/1132016。JSX甚至让我们不得不把15行的HTML代码分成3个组件,每个组件里包含5行代码。不要认为这种做法会让你成为更好的开发人员,你只是不得不这么做而已。而事实其实是这样的:如果你正在开发一个相对复杂的组件,而你并不打算明天就把它发布到GitHub上,那么上述的方式只会拖你的后腿,特别是在你要解决真实的业务问题时。不过不要误会,我并不是说拆分成小组件就一定不好。你当然清楚通过拆分可以提升代码的可管理性和可重用性。但前提是,只有当业务逻辑实体可以被放到一个单独的组件里时才要这么做,而不是每写一个三元操作代码就要进行拆分!每次在创建新组件时都会让你和你的意识流付出一定的代价,因为你需要从业务思维(在你记住当前组件状态时,需要增加一些HTML代码让它运行起来)转换到 管理思维 你需要为这个组件创建单独的文件,考虑如何给新组件添加属性,并把它们跟组件状态映射起来,还要考虑如何把回调函数传递进去,等等。你被迫使用这种过度且不成熟的组件模块化方式来编写代码,从而降低了编码速度,而从中得到的模块化可能并非你所需要的。在我看来,不成熟的模块化跟不成熟的优化没有什么两样。对于我和我的团队来说,代码的可读性是非常重要的,不过是否能够从编码中获得乐趣也很重要。为了实现一个简单的计算器控件而去创建六个组件,这样的事情一点也不有趣。大多数情况下,这样做也不利于维护、修改或控件检修,因为你要在很多文件和函数间跳来跳去,逐个检查每一个HTML小代码块。再次强调,我并不是在建议使用单体,我只是建议在日常开发当中使用组件来替代微组件。这是常识性问题。在React里使用表单和Redux会让你忙得停不下来还记得吗,React的设计在于它的纯净以及干净的单向数据流。这就是为什么LinkedStateMixin不受待见,你需要为10个输入创建10个函数,而80%这样的函数只包含了一行this.setState()代码,或者一次redux调用(或许你还需要为每个输入创建一个常量)。如果只要在脑子里想想就能自动生成这些代码的话,或许还是可以接受的,但现在还没有哪个IDE可以提供这样的功能。为什么要敲这么多的代码呢?因为双向绑定被认为是不安全的,特别是在大型应用里。我可以肯定地说,双向数据流的代码可读性确实不是很好,而Angular 1的双向绑定更是糟糕透顶。不过,这些还算不上大问题。
网站建设
来源: