V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
推荐关注
Meteor
JSLint - a JavaScript code quality tool
jsFiddle
D3.js
WebStorm
推荐书目
JavaScript 权威指南第 5 版
Closure: The Definitive Guide
FrankFang128
V2EX  ›  JavaScript

Web 开发不应该这么复杂

  •  3
     
  •   FrankFang128 · 2016-08-17 03:18:42 +08:00 · 13855 次点击
    这是一个创建于 2780 天前的主题,其中的信息可能已经有所发展或是发生改变。
    除了 React / Vue ,你还应该看看其他开发模式

    原视频

    本文作者:方应杭(微信: frank_fang )

    本文很长,但请耐心看完,因为末尾有广告。。。

    这个视频来自 RailsConf 2016 ,演讲者是 Sam Stephenson ,他主要的开源作品有 rbenvPowTrix,曾是 Rails 的核心开发人员。目前在 Basecamp 工作。

    从这个视频,你可以明显地看出前后端开发者思考问题的差异。

    好了我们进入正题,看看他讲了什么。括号里面的话是我说的,其他都是演讲者说的。


    ⬆️ 我们一共 10 个开发者,其他 6 个 Rails 开发、 2 个 iOS 开发和 2 个安卓开发,在 18 月完成了共 200 个设计图、部署到五个平台的 Basecamp 3 。

    (你能想象不用纯前端开发者来开发一个 Web 应用吗?)


    ⬆️ 我们来回顾下从 2004 年开始, Web 开发经历了怎样的过程。


    ⬆️ J2EE ,典型的三层架构:数据层+业务逻辑层+表现层。(前端这个职业还没诞生吧)


    ⬆️ 然后是 PHP ( PHP 是招黑体质)


    ⬆️ 然后是以 Rails 为代表的 MVC 。那个时期是 Rails 的黄金时代,然而浏览器的性能令人沮丧。

    整个 request-response 的循环简单而优雅。


    ⬆️ 我们对服务器渲染 HTML 的性能不是很满意,同时浏览器的性能进一步提高了,所以我们觉得可以把渲染放到浏览器上来做。

    (可以看到简单的环状结构变得比较复杂了:浏览器从服务器获取 model ,同时自身维护着 router 、 view 和 controller 。)

    浏览器从服务器得到一个空的页面,然后用 JS 启动这个页面。 JS 发起很多 API 请求。服务器接收 JSON ,输出 JSON 。所有的 HTML 渲染,由浏览器完成。

    大家都觉得这主意不错,是吧?

    • 我们的应用总得需要 API 对吧。为啥不在应用内部也使用 API 对吧?
    • 而且还能让表现( presentatioin )与数据( data )解耦,解耦总是对的对吧?

    ⬆️ 但是,前端们还是觉得客户端 MVC 的性能不够好,所以又引入了虚拟 DOM 来最小化 DOM 操作。

    想法很不错。既然 DOM 操作慢,我们就尽量不要操作 DOM 。

    但是呢,有两个问题:

    1. 所以这些 JS 代码和 API 请求,让首页渲染,非常非常非常慢。
    2. 所有内容,都无法被搜索引擎检索到。

    (没事,再加功能)

    ⬆️ 所以我们决定不用浏览器来渲染首屏了,让服务器来(回到老路子)。但是由于渲染逻辑我们不想做两遍,所以我们需要在服务器添加一个 JS runtime 来执行 JS 才行,这样浏览器端的渲染逻辑在服务器上也能跑起来了。

    服务器也要支持虚拟 DOM ,因为客户端操作的就是虚拟 DOM 。

    那么上面这个图就是全貌了,把我们 2004 年的设计,重新改写了。

    但是复杂度,真的是爆炸性增长。

    一个 Web 应用的依赖,已经成千上百了。

    整个系统复杂到,一个人,不可能对其了然于胸。

    我们的队员需要分别去掌握其中某个子系统。


    ⬆️ 康威定律

    讲真,你们这些人知道康威定律吗?

    系统的设计团队受其生产系统的约束,而生产系统又是根据设计团队的沟通结构决定的。

    ⬆️ 康威定律说,软件产品的结构就是其创造团队的组织结构的镜像。

    我们正在使用的客户端渲染框架,来自于 Google 和 Facebook ,这两家公司有数千开发者,这些开发者隶属于数十个团队,组织结构就像这样:

    ⬆️ (是不是跟上面带有虚拟 DOM 的那种架构图很像?)

    ⬆️ (认清自己吧,少年)

    你的团队面临的问题,很可能跟 Google 和 Facebook 所面临的不一样。

    使用那些客户端框架时,我们是为了追逐性能,我们做的每个决定都是对的,但是放在一起看看结果,我们获得了微小的性能提升,却在工程方面花费了惨重的代价。

    如果继续深入这条路,这条路就会变得越窄。


    (还没完)

    ⬆️ 由于我们除了要支持 Web ,还要支持 iOS 和安卓,所以,我们要制造出三个类似的系统。

    (讲述者没有再说 React Native 了,因为这个思路是一样的:开发者选择客户端渲染,同时不想做三次,只能让 JS 运行在三个平台上。这就是「路越来越窄」,开发者把自己限定死了的意思)


    ⬆️ Fuck that.

    我们来重新审视一下吧。

    如果我们希望一个小团队能做大项目,那么就不应该把系统搞得这么复杂。

    ⬆️ (又出现这张图)


    ⬆️ 让 iOS 和安卓直接使用 View 。

    Web 的 View 可以作为 iOS 和安卓的基础,然后想办法优化使其体验起来像是本地应用。 Turbolinks 5 ,做的就是这件事情。


    ⬆️ 你的服务器依然渲染整个 HTML 。

    Turbolinks 异步请求页面,然后使用得到的 head 和 body 替换当前页面。 head 会做合并, body 则直接替换。

    (后面演讲者演示了 Turbolinks 的效果,有兴趣的人可以去看看视频。另外 Turbolinks 还提供了 iOS 和安卓的 SDK ,让移动端体验更顺滑)

    (演讲者也承认,这样的模式渲染一个页面大概 300ms ,没有很快,但是绝对够用。我看了下在 iOS 下的表现,切换页面时的 loading 时间确实有点长,但是能忍,也许再加点优化可以做到 1s 左右)


    相关观点:

    《为什么我不喜欢「前后端分离」》 - 18596 views

    《不依赖 Gulp 、 Babel 、 WebPack ,还能优雅地写代码吗》 - 6775 views

    广告:

    我现在在「彩程」(主要产品是「知人」和「 Tower 」),从事 Rails 开发,欢迎有志青年一起来「远程开发」,不用每天浪费三个小时在车上,而是用来学习新知识,真的很好。

    邮箱: frankfang1990atgmail

    第 1 条附言  ·  2016-08-17 11:08:16 +08:00
    注意演讲者针对的不是小网站。
    Basecamp 3 绝对不是小网站。
    有些人看了本文,依然人云亦云。
    现在用 React / Vue 的才是小网站。
    第 2 条附言  ·  2016-08-17 11:24:55 +08:00
    彩程的知人是用上面说的模式。
    Tower 用的是 Vue + API 模式。
    投简历时请写清楚。
    cc @kshift
    第 3 条附言  ·  2016-08-17 11:35:46 +08:00
    为什么有些前端觉得客户端渲染更「简单」?
    因为你负责的是子系统啊!
    子系统还能不简单啊。。。
    文章里已经说了,客户端渲染框架每一步决策都是当下看起来正确的、简单的,只是合起来,就复杂了。
    第 4 条附言  ·  2016-09-01 01:57:41 +08:00
    请收藏的人顶一下。。
    84 条回复    2016-09-10 11:47:42 +08:00
    dcoder
        1
    dcoder  
       2016-08-17 03:51:17 +08:00
    @FrankFang128
    "这样的模式渲染一个页面大概 300ms" "也许再加点优化可以做到 1s 左右"
    1s == 1000ms > 300ms 不是更慢吗?
    shoaly
        2
    shoaly  
       2016-08-17 04:01:03 +08:00
    写的很好, 楼主的表达能力 以及想要表达的内容我都觉得不错
    shoaly
        3
    shoaly  
       2016-08-17 04:02:40 +08:00
    @dcoder loading 我理解指的是 网速加载, 渲染我感觉是加载之后 webview 处理的时间? 期待楼主正解
    FrankFang128
        4
    FrankFang128  
    OP
       2016-08-17 04:06:14 +08:00 via Android
    @dcoder web 300ms , iOS 1s ,不一样的平台
    czheo
        5
    czheo  
       2016-08-17 04:10:37 +08:00
    前排观看 lz 又来挖大坑。
    czheo
        6
    czheo  
       2016-08-17 04:44:20 +08:00
    1. 其实我观察到的历史不是因为后端渲染不够快,而是因为前端需求开始复杂到需要写 modular js 才出现的前端框架。
    2. 无法被搜索引擎检索,在 virtual dom 出现以前,前端框架普及之初已成问题。
    3. Turbolinks 的作者当然支持 webview ,而现实是市场更愿意选择性能优秀效果酷炫的 native app 。
    peneazy
        7
    peneazy  
       2016-08-17 06:08:04 +08:00 via Android
    已经感觉到前端的复杂了,入职三个月,依然没有完全搞明白公司的整个前端框架,可能自己是前端新人的缘故吧。
    markx
        8
    markx  
       2016-08-17 06:09:06 +08:00
    我觉得这篇文章很有意思,图文并茂说得很清楚。
    但是我看到“讲真,你们这些人知道康威定律吗?” 的时候,我心里一惊,因为我真的不知道这个是什么。托楼主的福又学到了新东西 :)
    接着往下看,发现文中的翻译好奇怪啊。我想“这里 produce 不该是动词么?” 于是我去查了维基百科,发现维基是这么说的“ organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations ”.
    好吧,学习了。
    markx
        9
    markx  
       2016-08-17 06:21:27 +08:00
    看完全文了。
    我很喜欢文中那些结构图,很清楚。
    虽然是广告,但是我心里很赞同。如果用简单的工具能把事情搞定,就真的没必要搞复杂了。也许用各种高级工具各种抽象会更利于扩展,但现在的 web ,两三年工具就更新换代了,所以扩展说不定还不如重新写了。
    ecloud
        10
    ecloud  
       2016-08-17 07:00:10 +08:00 via iPhone
    在手机平台上用 HTML 假冒一个本地应用的做法不是这两年才有的
    之前那些基本都死得很惨
    剩下一俩没死的都改成本地应用了
    eriale
        11
    eriale  
       2016-08-17 07:03:48 +08:00
    赞!前后端细粒度分离,应该是产品 /部门大到一定程度的结果。
    楼主有没有考虑过产品 /用户规模大到什么程度时,才需要把前后端拆成这么细? 1000w 用户?或更多?
    loading
        12
    loading  
       2016-08-17 07:16:24 +08:00 via Android
    期待楼主很多的好文翻译。
    tomatoo
        13
    tomatoo  
       2016-08-17 07:30:44 +08:00   ❤️ 2
    说几点:

    - 并不是所有的网站都有 SEO 需求;
    - SAAS 应用的前端一般比较复杂,如果还是按照 jquery 的组织方式来搞的话维护起来太麻烦了;
    - 我并不觉得 Google 提出的 angular , Facebook 提出的 react 会让整个应用的结构变得复杂,相反的使用框架可以帮助我们写出更加低耦合,模块化,组件化的代码,同时数据与 DOM 的分离也让前端的单元测试更加方便。

    (之前是前端开发,现在做 rails 开发,一点感受)
    metrue
        14
    metrue  
       2016-08-17 08:20:05 +08:00
    其实 Rails 支持了 API 模式,在某种程度已经表明 Rails 社区也同样认为前后端分离是合理的。
    mdluo
        15
    mdluo  
       2016-08-17 08:27:25 +08:00
    @kshift 你们现在打广告都靠引战了吗 2333
    mdluo
        16
    mdluo  
       2016-08-17 08:28:09 +08:00
    简单点,招人的方式再简单点
    sfree2005
        17
    sfree2005  
       2016-08-17 08:36:12 +08:00
    同意 @tomatoo 我觉得原视频的主要思想还是说包装 web view 到移动端一种新的方式。 如果服务器渲染出来的页面没有很复杂的交互逻辑,这的确够用了。有的话还是要写复杂的 JavaScript ,这时候前后端分离,工程化和组件化就很有必要了。前端框架 Angular 之类是将复杂的交互逻辑变得更容易实现,所以最终还是需求决定工具。
    shyling
        18
    shyling  
       2016-08-17 08:37:27 +08:00 via iPad
    一直不觉得前后端分离和规模大小有关。。。而且和性质有关。
    想想当年, you are not google ,所以你不配像 gmail 那样使用 ajax 。是不是呢?

    另外为什么要执着于 virtualdom 了,那只是实现的途径而已。说起来既然用了 rails 还大谈性能问题....各种 coc 不管是在后端还是在前端都是为了更'无脑化'的写代码吧
    liudanning
        19
    liudanning  
       2016-08-17 08:38:21 +08:00   ❤️ 2
    唉,就是一句简单的具体问题具体分析
    cenxun
        20
    cenxun  
       2016-08-17 08:38:56 +08:00
    套路精髓 Max ,传统 jQuery 党就默默看着
    kikyous
        21
    kikyous  
       2016-08-17 08:43:43 +08:00
    rails 开发够简单
    zxb
        22
    zxb  
       2016-08-17 09:00:01 +08:00 via Android
    这些框图都太复杂了。搞什么 MVC ,搞什么 EJB ?

    想想 20 年前,是这样的:

    httpd --> xxx.cgi

    够简单了吧?不依赖 MVC ,我们还能优雅的写代码吗?
    9
        23
    9  
       2016-08-17 09:18:46 +08:00   ❤️ 1
    @liudanning 话虽如此,但是这个万金油回答说了等于没说哦,抛观点,引讨论还是好事
    FrankFang128
        24
    FrankFang128  
    OP
       2016-08-17 09:49:45 +08:00 via Android
    @ecloud 当时是时机不对。而且 Turbolonks 也有相应的优化
    FrankFang128
        25
    FrankFang128  
    OP
       2016-08-17 09:51:55 +08:00 via Android
    @tomatoo 单单前端那块不复杂,不就是个类 MVC 结构,但是前后加一起就复杂了。
    zhouzhe8013
        26
    zhouzhe8013  
       2016-08-17 10:02:24 +08:00
    写的挺好,大公司之所以采用复杂的结构,还是因为
    1 分工足够细致
    2 极致需求
    3 足够长的架构演进过程
    要是小公司或者小产品一开始就弄得很复杂,那肯定是个灾难.
    panlilu
        27
    panlilu  
       2016-08-17 10:10:29 +08:00
    所以全栈应该用 rails
    FrankFang128
        28
    FrankFang128  
    OP
       2016-08-17 10:14:31 +08:00 via Android
    @zhouzhe8013 大公司是因为分工细才使用这种框架,因果正好是反的,先分工,再找框架。
    FrankFang128
        29
    FrankFang128  
    OP
       2016-08-17 10:15:17 +08:00 via Android
    @panlilu Turbolinks 已经不只支持 Rails 了。用其它后端框架也可以。
    ichou
        30
    ichou  
       2016-08-17 10:19:15 +08:00 via iPhone
    Turbolinks 还是要赞的
    但是在非 rails 的圈子里,似乎还不太知名
    huybery
        31
    huybery  
       2016-08-17 10:19:27 +08:00
    招聘需求呢..
    scys
        32
    scys  
       2016-08-17 10:31:51 +08:00
    业务决定技术方向: D 。
    不过前端近几年突发的概念是多了,虽然到了最后还是 DOM DOM DOM
    YuJianrong
        33
    YuJianrong  
       2016-08-17 10:37:11 +08:00   ❤️ 1
    简而言之就是一句话:做个小网站架构不要太复杂。

    TM 简直废话。

    另一句话,做大系统必须要复杂但清晰、耦合度低的架构,就被标题“ Web 开发不应该这么复杂”吃掉了。

    拜托 Web 开发不仅仅是做个 2 , 3 个人日工作量的小网站好不好!
    est
        34
    est  
       2016-08-17 10:40:31 +08:00
    彩程强行广告啊。 tower 的移动段体验非常差。
    Ellen
        35
    Ellen  
       2016-08-17 10:42:11 +08:00
    哇, tower 的工程师,远程开发好向往。
    awanabe
        36
    awanabe  
       2016-08-17 10:57:51 +08:00
    楼主从阿里跳到 Tower 去了?
    Dreawer
        37
    Dreawer  
       2016-08-17 11:04:11 +08:00
    学习阶段,个人建站,前端领域问题可以一起交流讨论! http://www.dreawer.com/
    FrankFang128
        38
    FrankFang128  
    OP
       2016-08-17 11:04:13 +08:00
    @YuJianrong 本文说的是大网站, 200 个设计图,历时 18 个月,部署都五个平台。
    scott1743
        39
    scott1743  
       2016-08-17 11:10:05 +08:00
    原来是彩程大大,膜拜。早在几年前 Simditor 还没有图片上传的接口文档的时候,我还研究源码写了 Rails 的封装 gem ,结果下个版本就出了完整的接口和文档。

    另外说观点,和上篇一样,完全赞同。
    FrankFang128
        40
    FrankFang128  
    OP
       2016-08-17 11:11:01 +08:00
    @scott1743 那不是我写的,是带我的人写的。
    herozzm
        41
    herozzm  
       2016-08-17 11:16:23 +08:00
    我赞成, mvc 取得了很好的平衡
    FrankFang128
        42
    FrankFang128  
    OP
       2016-08-17 11:19:22 +08:00
    @tomatoo 你说的优点都对,但是缺点我受不了。利大于弊还是弊大于利,就看团队结构和产品结构了。一般情况,我倾向于不要使用客户端渲染。特殊情况可以用。
    kshift
        43
    kshift  
       2016-08-17 11:21:05 +08:00
    不怕,想前后端分离的来做 Tower ,我现在移动版是 Vue + Rails API
    bdbai
        44
    bdbai  
       2016-08-17 11:23:41 +08:00 via Android
    前端渲染你们团队不用就不用,还让全世界都不用?没摸清门道怪“复杂度暴涨”,那生产机器上的操作系统,你们全部掌握了?
    看到楼主就知道他要说什么了。简直就像传教士。
    FrankFang128
        45
    FrankFang128  
    OP
       2016-08-17 11:25:07 +08:00
    @kshift 我 append 了~
    FrankFang128
        46
    FrankFang128  
    OP
       2016-08-17 11:26:00 +08:00
    @bdbai React 能传教, Vue 能传教,我就不能传教? 呵呵
    kshift
        47
    kshift  
       2016-08-17 11:30:21 +08:00
    @FrankFang128 哈哈哈, Tower 之前的移动版我就用的是 Turbolinks ,主站是自己写的一套 pjax 框架。
    FrankFang128
        48
    FrankFang128  
    OP
       2016-08-17 11:30:34 +08:00
    @bdbai 有本事写文章说你自己的观点,而不是像这样避开观点谈我本人是不是传教士。
    tomatoo
        49
    tomatoo  
       2016-08-17 11:36:20 +08:00
    @FrankFang128 给你了模块化,组件化,爽的飞起的 ES6 , webpack 的各种好用的 loader 并且是傻瓜式配置,方便的前端测试,文件动静分离方便 CDN 加速,这些好用的东西还不够吗,那请问你说的缺点是什么缺点呢?

    Tower 我也关注过,你们的产品很赞。
    FrankFang128
        50
    FrankFang128  
    OP
       2016-08-17 11:38:39 +08:00
    @tomatoo 没有 SEO 支持,首页渲染很慢。
    而且动静分离、模块化、组件化、 ES6 、前端测试都可以单独做,并不是前端框架带来的特性。
    FrankFang128
        51
    FrankFang128  
    OP
       2016-08-17 11:41:14 +08:00
    @tomatoo 为什么前端在使用了前端框架后才开始模块化、组件化、 ES6 ?可以参考我之前对前后分离动机的腹黑推测:因为前端开发者对这些东西没有控制力和话语权。你让后端打包的时候加个 babel ,后端才不愿意承担风险呢!
    FrankFang128
        52
    FrankFang128  
    OP
       2016-08-17 11:42:35 +08:00
    @tomatoo 前端只好说,好吧,你们后端不帮忙,我就全用 JS 做。
    就是这样,起码我见到的一些大团队是这样的。
    tomatoo
        53
    tomatoo  
       2016-08-17 11:42:43 +08:00
    @FrankFang128 你当然可以自己做啊,自己写一套东西给团队使用,我也这么干过,但是这不还是一个框架吗?我主要说的点不是前端框架,而是前后端分离的开发思路(不是人员分工,而是技术上的分离)。
    bdbai
        54
    bdbai  
       2016-08-17 11:42:51 +08:00 via Android
    @FrankFang128 现在似乎很少见 React 跟 Vue 传教的。
    我的观点?具体问题具体分析。两种方案都有利弊,看需求咯。目前看来抛弃哪一种都是不可取的。
    lcc4376
        55
    lcc4376  
       2016-08-17 11:55:57 +08:00
    前端奇技淫巧太多,我是覺得所有後端都應該朝全棧發展
    zztt168
        56
    zztt168  
       2016-08-17 12:03:46 +08:00 via iPhone
    认真看完了,很好的反思。康维定律很深刻,我觉得可以用到很多管理领域。感谢楼主。
    quiz
        57
    quiz  
       2016-08-17 12:20:58 +08:00   ❤️ 3
    真正想做前端的同学来我们公司吧,数据可视化驱动,抽象高智商业务超复杂交互,真正前后端分离!
    后端渲染的同学就不要想了。。。还是去那些就简单做做 CRUD 的“用世界上最好语言和框架”的公司吧 = =
    http://www.lagou.com/jobs/1741791.html?source=pl&i=pl-2
    职位描述:

    1 、负责前端效果的实现,将设计师提供的设计图转换成静态页面,并实现各类页面动态效果;

    2 、与设计师、开发人员配合,根据需求调整、修改、优化页面;

    3 、解决网站页面浏览器的兼容问题;

    4 、其他上级分派的工作。


    岗位要求:

    1 、 2 年以上相关经验,计算机科学与技术相关专业专科以上学历;

    2 、熟悉 JQuery 、 Bootstrap 或类似开发框架;

    3 、精通 HTML5+CSS3 ,熟悉 DIV+CSS 页面布局,能手写样式代码;

    4 、能使用 JavaScript 开发产品及制作交互原型优先;

    5 、熟悉 AngularJS 、 ElasticSearch 优先;

    6 、了解 Linux 系统;

    7 、有团队合作意识。
    kamikat
        58
    kamikat  
       2016-08-17 12:43:14 +08:00
    对对对,你说的很对。某一天产品经理说我们要写原生 Android 客户端和 iOS 客户端…
    pepsin
        59
    pepsin  
       2016-08-17 13:14:39 +08:00
    @quiz 连个熟悉 D3 都不要求讲啥数据可视化啊
    tflz514
        60
    tflz514  
       2016-08-17 13:17:52 +08:00
    @FrankFang128 请问流程图是用什么工具画的?
    quiz
        61
    quiz  
       2016-08-17 13:33:17 +08:00
    @pepsin D3 可以过来学习,没关系,只要对浏览器 前端技术比较熟悉,学习起来还是很快的。有些可视化我们都是自己写的不一定非要依赖 D3 , D3 依赖 SVG 渲染,在大规模数据场景下会有性能瓶颈。
    ecloud
        62
    ecloud  
       2016-08-17 14:00:15 +08:00
    @zxb 我做的某天文工控系统就差不多是这样的, web 界面的 php 就是个幌子,直接 passthru 调 C (你没看错就是 ANSI C )写的实际控制程序。
    只有两段 JS ,一个用来显示动态曲线图,一个用来显示图片缩放。
    因为这个系统要求的基本上是实时响应,去你娘的 web 渲染,哪有那闲情逸致。
    不过说实话这样写的代码真的非常简洁清晰,很容易看懂,维护起来很方便,加个新功能也就半个小时(算上测试)的事情完事儿了。
    ecloud
        63
    ecloud  
       2016-08-17 14:12:47 +08:00
    @YuJianrong 跟大小无关,关键看需求
    IBM 以前的 CM 就是很低耦合的系统,也算是很复杂的东西了,但是 web 前端基本等于没有
    然后一些客户就抱怨说你们的 web 太烂了,能不能给我们一个好看的界面
    然后 IBM 收购了 FileNet ,用 FileNet 那套花哨的前端架在自己的后端 CM 上
    结果是花了很多很多钱,人力物力。然后那帮客户后来又发现,在这个前端上他们要做二次开发可就迷糊了,又想退回去了
    其实很多时候那些用户们并不知道他们究竟想要什么东西,这就是为什么 Jobs 能成功的秘诀
    FrankFang128
        64
    FrankFang128  
    OP
       2016-08-17 14:24:46 +08:00 via Android
    @tflz514 他手画的
    akira
        65
    akira  
       2016-08-17 15:03:10 +08:00
    看了下视频,其实就是在宣传 turbolink 的炫酷叼炸天
    YuJianrong
        66
    YuJianrong  
       2016-08-17 21:01:46 +08:00
    @ecloud 这是产品要背锅的。如果有大量二次开发的需求,那么在第一时间就要考虑到二次开发怎么做,甚至把自己团队降低到第三方一样的高度来先搞好二次开发框架(其实也没有二次开发框架了,就是一样的开发)。
    但这难度太大了,以 KPI 论的大商务软件公司真的很难搞(比如我司)。
    Geeker
        67
    Geeker  
       2016-08-17 21:17:24 +08:00
    @quiz 什么叫数据可视化驱动。。 2333
    ecloud
        68
    ecloud  
       2016-08-17 21:18:58 +08:00 via iPhone
    @YuJianrong 产品背锅?收购 FileNet 这么大的事情产品哪背得起这锅!大公司有些行为并不完全是简单的跟软件开发那套逻辑相关,还有很多七七八八匪夷所思的逻辑。所以小公司跟着学样会死得很惨。
    比如,刚收购 FileNet 的时候,我发现他们的人工作态度比 IBM 的自己人好太多,然后唠叨给美国的架构师,结果那厮说, This is just what we wanted to pay for.
    quiz
        69
    quiz  
       2016-08-17 21:52:50 +08:00 via iPad
    @Geeker 就是产品设计,技术选型,还有架构设计都是围绕数据可视化来做的,以把有价值的数据以最直观的方式展现给用户为目标驱动研发。语言是写的太精简了,主要怕影响大家灌水。本以为做过成熟商业软件开发的 v 友们都能 get 到 point ,实在不能理解的估计是经验还有看问题的思维比较不一样,不过可以一起探讨。跟檀木网站上比可能用语方式是不太一样可 v 站是专业技术社区,想必说的缩略点大多数专业极客 v 友们还是可以理解的,如果实在理解不能可以到漫展上约我当面切磋- -!
    YuJianrong
        70
    YuJianrong  
       2016-08-17 22:16:06 +08:00   ❤️ 1
    @ecloud 我说产品背锅不是说背收购前端技术公司这种锅,而是对自己产品定义上的锅。不管收购了什么前端技术公司,只要能清晰定义出以扩展性为第一优先,所有技术都围绕如何方便和安全地扩展来开发,也能达到满足第三方扩展的需求。

    只是这对于大公司来说太难了。

    比如我司,也和 IBM 差不多,部门结构庞杂,部门做事主要要 show 给老板看,老板做事主要要 show 给更大的老板看,结果最容易受重视的就是看起来好看的东西(不仅仅是指视觉上),至于扩展性啦什么的,总以为以后慢慢加……但架构都定死了加什么加……

    这么说来也不是产品这个职务的锅,主要还是回到产品原始定义上去,本来就定义成好看但不易扩展的产品,那自然就很难做出方便二次开发的产品。然而不幸的是,一般原始定义产品的时候,大佬们都只想着花三分钱办五分事,尽快把东西弄出来(毕竟人家的 KPI 是这个),而不是为以后真的推向市场的时候的扩展性来花十分功夫打基础。
    shooter
        71
    shooter  
       2016-08-17 22:23:35 +08:00
    @panlilu 这没必要吧
    jadecoder
        72
    jadecoder  
       2016-08-18 01:18:39 +08:00
    很好,第一次听说康威定律,值得深思
    genffy
        73
    genffy  
       2016-08-18 01:21:25 +08:00
    哎,天天扯这些没用的。
    loser
        74
    loser  
       2016-08-18 02:37:53 +08:00
    tower / 知人 用户路过帮顶
    选择适合自己的即可,没必要争论
    over
    tomatoo
        75
    tomatoo  
       2016-08-18 08:25:02 +08:00
    Tower 用的是 Vue + API 模式吗?
    为啥打开控制台没看到 vue ,是我打开的姿势不对吗?
    seaify
        76
    seaify  
       2016-08-18 09:53:12 +08:00
    @kshift

    rails + vue, web 端我是这样弄,但是移动端这样弄,是指原生+webview ?求解惑
    daysv
        77
    daysv  
       2016-08-18 10:28:14 +08:00
    虽然我是前端(写 exe 的前端 XD ),其实我也觉得前端炒作过热了, 感觉市场真正需求的还是全栈。
    但是全栈技术栈比较杂,很难互相匹配。
    tomatoo
        78
    tomatoo  
       2016-08-18 13:20:02 +08:00
    @daysv @FrankFang128 这样比较难招人吧 你让一个写后端的去做前端的事情,做出来的用户体验一般比较差的(前端不只是完成逻辑,更要重视用户体验),或者开发周期长,同样你让一个前端熟手去写后端,也会遇到各种性能问题,尤其是数据量大的情况下,这些都是我真实遇到过的。这个问题怎么解决呢?毕竟称得上 web 全栈的还是太少了。
    ihuguowei
        79
    ihuguowei  
       2016-08-18 16:56:00 +08:00 via Android
    @kshift 你们的编辑器还维护吗,发邮件没人理,提 PR 也没人理……
    FrankFang128
        80
    FrankFang128  
    OP
       2016-08-18 17:09:01 +08:00
    @ihuguowei simditor 吗? 不是有人理吗
    ihuguowei
        81
    ihuguowei  
       2016-08-18 17:17:35 +08:00
    @FrankFang128 https://github.com/mycolorway/simditor/tree/master 最后提交已经很久了啊 一个月前 master 分支。
    unlitechc
        82
    unlitechc  
       2016-08-24 09:00:20 +08:00
    这里是从后端到前端的破厂码农,该文说的一些问题当然是存在的。
    看了您的几篇文章,觉得您说的很有道理,只是语气冲了点,而且标题似乎应该改成“我不是针对谁,盲目套用大厂架构的都是辣鸡” 23333333333333
    ljbha007
        83
    ljbha007  
       2016-09-01 02:12:01 +08:00
    但是如果把前端做得简单 导航、控制器这些逻辑都会移动到后端 逻辑是一样复杂 只是架构变简单了
    xuzicn
        84
    xuzicn  
       2016-09-10 11:47:42 +08:00
    看完了回复,楼主是想说“框架过于复杂”还是什么呢?事实上前端工程依赖的复杂度,主要不是由框架引入的,主要还是一堆 shim 、 babel 之类的,这可都是浏览器的锅啊。“无 JS 也能使用”的应用,体验肯定是个问题,这种由市场决定的选择,也是无可奈何的
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2731 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 36ms · UTC 15:30 · PVG 23:30 · LAX 08:30 · JFK 11:30
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.