Web 开发不应该这么复杂

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

推荐关注

› Meteor

› JSLint - a JavaScript code quality tool

› jsFiddle

› D3.js

› WebStorm

推荐书目

› JavaScript 权威指南第 5 版

› Closure: The Definitive Guide

这是一个创建于 3020 天前的主题，其中的信息可能已经有所发展或是发生改变。

除了 React / Vue ，你还应该看看其他开发模式

原视频

本文作者：方应杭（微信： frank_fang ）

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

这个视频来自 RailsConf 2016 ，演讲者是 Sam Stephenson ，他主要的开源作品有 rbenv、Pow 和 Trix，曾是 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 。

但是呢，有两个问题：

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

(没事，再加功能）

⬆️ 所以我们决定不用浏览器来渲染首屏了，让服务器来（回到老路子）。但是由于渲染逻辑我们不想做两遍，所以我们需要在服务器添加一个 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

请收藏的人顶一下。。

⬆️

DOM

渲染

服务器

84 条回复 • 2016-09-10 11:47:42 +08:00

dcoder

2016-08-17 03:51:17 +08:00

@FrankFang128
"这样的模式渲染一个页面大概 300ms" "也许再加点优化可以做到 1s 左右"
1s == 1000ms > 300ms 不是更慢吗?

shoaly

2016-08-17 04:01:03 +08:00

写的很好, 楼主的表达能力以及想要表达的内容我都觉得不错

shoaly

2016-08-17 04:02:40 +08:00

@dcoder loading 我理解指的是网速加载, 渲染我感觉是加载之后 webview 处理的时间? 期待楼主正解

FrankFang128

2016-08-17 04:06:14 +08:00 via Android

@dcoder web 300ms ， iOS 1s ，不一样的平台

czheo

2016-08-17 04:10:37 +08:00

前排观看 lz 又来挖大坑。

czheo

2016-08-17 04:44:20 +08:00

1. 其实我观察到的历史不是因为后端渲染不够快，而是因为前端需求开始复杂到需要写 modular js 才出现的前端框架。
2. 无法被搜索引擎检索，在 virtual dom 出现以前，前端框架普及之初已成问题。
3. Turbolinks 的作者当然支持 webview ，而现实是市场更愿意选择性能优秀效果酷炫的 native app 。

peneazy

2016-08-17 06:08:04 +08:00 via Android

已经感觉到前端的复杂了，入职三个月，依然没有完全搞明白公司的整个前端框架，可能自己是前端新人的缘故吧。

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

2016-08-17 06:21:27 +08:00

看完全文了。
我很喜欢文中那些结构图，很清楚。
虽然是广告，但是我心里很赞同。如果用简单的工具能把事情搞定，就真的没必要搞复杂了。也许用各种高级工具各种抽象会更利于扩展，但现在的 web ，两三年工具就更新换代了，所以扩展说不定还不如重新写了。

ecloud

2016-08-17 07:00:10 +08:00 via iPhone

在手机平台上用 HTML 假冒一个本地应用的做法不是这两年才有的
之前那些基本都死得很惨
剩下一俩没死的都改成本地应用了

eriale

2016-08-17 07:03:48 +08:00

赞！前后端细粒度分离，应该是产品 /部门大到一定程度的结果。
楼主有没有考虑过产品 /用户规模大到什么程度时，才需要把前后端拆成这么细？ 1000w 用户？或更多？

loading

2016-08-17 07:16:24 +08:00 via Android

期待楼主很多的好文翻译。

tomatoo

2016-08-17 07:30:44 +08:00

说几点：

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

（之前是前端开发，现在做 rails 开发，一点感受）

metrue

2016-08-17 08:20:05 +08:00

其实 Rails 支持了 API 模式，在某种程度已经表明 Rails 社区也同样认为前后端分离是合理的。

mdluo

2016-08-17 08:27:25 +08:00

@kshift 你们现在打广告都靠引战了吗 2333

mdluo

2016-08-17 08:28:09 +08:00

简单点，招人的方式再简单点

sfree2005

2016-08-17 08:36:12 +08:00

同意 @tomatoo 我觉得原视频的主要思想还是说包装 web view 到移动端一种新的方式。如果服务器渲染出来的页面没有很复杂的交互逻辑，这的确够用了。有的话还是要写复杂的 JavaScript ，这时候前后端分离，工程化和组件化就很有必要了。前端框架 Angular 之类是将复杂的交互逻辑变得更容易实现，所以最终还是需求决定工具。

shyling

2016-08-17 08:37:27 +08:00 via iPad

一直不觉得前后端分离和规模大小有关。。。而且和性质有关。
想想当年， you are not google ，所以你不配像 gmail 那样使用 ajax 。是不是呢？

另外为什么要执着于 virtualdom 了，那只是实现的途径而已。说起来既然用了 rails 还大谈性能问题....各种 coc 不管是在后端还是在前端都是为了更'无脑化'的写代码吧

liudanning

2016-08-17 08:38:21 +08:00

唉，就是一句简单的具体问题具体分析

cenxun

2016-08-17 08:38:56 +08:00

套路精髓 Max ，传统 jQuery 党就默默看着

kikyous

2016-08-17 08:43:43 +08:00

rails 开发够简单

zxb

2016-08-17 09:00:01 +08:00 via Android

这些框图都太复杂了。搞什么 MVC ，搞什么 EJB ？

想想 20 年前，是这样的：

httpd --> xxx.cgi

够简单了吧？不依赖 MVC ，我们还能优雅的写代码吗？

2016-08-17 09:18:46 +08:00

@liudanning 话虽如此，但是这个万金油回答说了等于没说哦，抛观点，引讨论还是好事

FrankFang128

2016-08-17 09:49:45 +08:00 via Android

@ecloud 当时是时机不对。而且 Turbolonks 也有相应的优化

FrankFang128

2016-08-17 09:51:55 +08:00 via Android

@tomatoo 单单前端那块不复杂，不就是个类 MVC 结构，但是前后加一起就复杂了。

zhouzhe8013

2016-08-17 10:02:24 +08:00

写的挺好,大公司之所以采用复杂的结构,还是因为
1 分工足够细致
2 极致需求
3 足够长的架构演进过程
要是小公司或者小产品一开始就弄得很复杂,那肯定是个灾难.

panlilu

2016-08-17 10:10:29 +08:00

所以全栈应该用 rails

FrankFang128

2016-08-17 10:14:31 +08:00 via Android

@zhouzhe8013 大公司是因为分工细才使用这种框架，因果正好是反的，先分工，再找框架。

FrankFang128

2016-08-17 10:15:17 +08:00 via Android

@panlilu Turbolinks 已经不只支持 Rails 了。用其它后端框架也可以。

ichou

2016-08-17 10:19:15 +08:00 via iPhone

Turbolinks 还是要赞的
但是在非 rails 的圈子里，似乎还不太知名

huybery

2016-08-17 10:19:27 +08:00

招聘需求呢..

scys

2016-08-17 10:31:51 +08:00

业务决定技术方向： D 。
不过前端近几年突发的概念是多了，虽然到了最后还是 DOM DOM DOM

YuJianrong

2016-08-17 10:37:11 +08:00

简而言之就是一句话：做个小网站架构不要太复杂。

TM 简直废话。

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

拜托 Web 开发不仅仅是做个 2 ， 3 个人日工作量的小网站好不好！

est

2016-08-17 10:40:31 +08:00

彩程强行广告啊。 tower 的移动段体验非常差。

Ellen

2016-08-17 10:42:11 +08:00

哇， tower 的工程师，远程开发好向往。

awanabe

2016-08-17 10:57:51 +08:00

楼主从阿里跳到 Tower 去了？

Dreawer

2016-08-17 11:04:11 +08:00

学习阶段，个人建站，前端领域问题可以一起交流讨论！ http://www.dreawer.com/

FrankFang128

2016-08-17 11:04:13 +08:00

@YuJianrong 本文说的是大网站， 200 个设计图，历时 18 个月，部署都五个平台。

scott1743

2016-08-17 11:10:05 +08:00

原来是彩程大大，膜拜。早在几年前 Simditor 还没有图片上传的接口文档的时候，我还研究源码写了 Rails 的封装 gem ，结果下个版本就出了完整的接口和文档。

另外说观点，和上篇一样，完全赞同。

FrankFang128

2016-08-17 11:11:01 +08:00

@scott1743 那不是我写的，是带我的人写的。

herozzm

2016-08-17 11:16:23 +08:00

我赞成， mvc 取得了很好的平衡

FrankFang128

2016-08-17 11:19:22 +08:00

@tomatoo 你说的优点都对，但是缺点我受不了。利大于弊还是弊大于利，就看团队结构和产品结构了。一般情况，我倾向于不要使用客户端渲染。特殊情况可以用。

kshift

2016-08-17 11:21:05 +08:00

不怕，想前后端分离的来做 Tower ，我现在移动版是 Vue + Rails API

bdbai

2016-08-17 11:23:41 +08:00 via Android

前端渲染你们团队不用就不用，还让全世界都不用？没摸清门道怪“复杂度暴涨”，那生产机器上的操作系统，你们全部掌握了？
看到楼主就知道他要说什么了。简直就像传教士。

FrankFang128

2016-08-17 11:25:07 +08:00

@kshift 我 append 了~

FrankFang128

2016-08-17 11:26:00 +08:00

@bdbai React 能传教， Vue 能传教，我就不能传教？呵呵

kshift

2016-08-17 11:30:21 +08:00

@FrankFang128 哈哈哈， Tower 之前的移动版我就用的是 Turbolinks ，主站是自己写的一套 pjax 框架。

FrankFang128

2016-08-17 11:30:34 +08:00

@bdbai 有本事写文章说你自己的观点，而不是像这样避开观点谈我本人是不是传教士。

tomatoo

2016-08-17 11:36:20 +08:00

@FrankFang128 给你了模块化，组件化，爽的飞起的 ES6 ， webpack 的各种好用的 loader 并且是傻瓜式配置，方便的前端测试，文件动静分离方便 CDN 加速，这些好用的东西还不够吗，那请问你说的缺点是什么缺点呢？

Tower 我也关注过，你们的产品很赞。

FrankFang128

2016-08-17 11:38:39 +08:00

@tomatoo 没有 SEO 支持，首页渲染很慢。
而且动静分离、模块化、组件化、 ES6 、前端测试都可以单独做，并不是前端框架带来的特性。

FrankFang128

2016-08-17 11:41:14 +08:00

@tomatoo 为什么前端在使用了前端框架后才开始模块化、组件化、 ES6 ？可以参考我之前对前后分离动机的腹黑推测：因为前端开发者对这些东西没有控制力和话语权。你让后端打包的时候加个 babel ，后端才不愿意承担风险呢！

FrankFang128

2016-08-17 11:42:35 +08:00

@tomatoo 前端只好说，好吧，你们后端不帮忙，我就全用 JS 做。
就是这样，起码我见到的一些大团队是这样的。

tomatoo

2016-08-17 11:42:43 +08:00

@FrankFang128 你当然可以自己做啊，自己写一套东西给团队使用，我也这么干过，但是这不还是一个框架吗？我主要说的点不是前端框架，而是前后端分离的开发思路(不是人员分工，而是技术上的分离)。

bdbai

2016-08-17 11:42:51 +08:00 via Android

@FrankFang128 现在似乎很少见 React 跟 Vue 传教的。
我的观点？具体问题具体分析。两种方案都有利弊，看需求咯。目前看来抛弃哪一种都是不可取的。

lcc4376

2016-08-17 11:55:57 +08:00

前端奇技淫巧太多,我是覺得所有後端都應該朝全棧發展

zztt168

2016-08-17 12:03:46 +08:00 via iPhone

认真看完了，很好的反思。康维定律很深刻，我觉得可以用到很多管理领域。感谢楼主。

quiz

2016-08-17 12:20:58 +08:00

真正想做前端的同学来我们公司吧，数据可视化驱动，抽象高智商业务超复杂交互，真正前后端分离！
后端渲染的同学就不要想了。。。还是去那些就简单做做 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

2016-08-17 12:43:14 +08:00

对对对，你说的很对。某一天产品经理说我们要写原生 Android 客户端和 iOS 客户端…

pepsin

2016-08-17 13:14:39 +08:00

@quiz 连个熟悉 D3 都不要求讲啥数据可视化啊

tflz514

2016-08-17 13:17:52 +08:00

@FrankFang128 请问流程图是用什么工具画的？

quiz

2016-08-17 13:33:17 +08:00

@pepsin D3 可以过来学习，没关系，只要对浏览器前端技术比较熟悉，学习起来还是很快的。有些可视化我们都是自己写的不一定非要依赖 D3 ， D3 依赖 SVG 渲染，在大规模数据场景下会有性能瓶颈。

ecloud

2016-08-17 14:00:15 +08:00

@zxb 我做的某天文工控系统就差不多是这样的， web 界面的 php 就是个幌子，直接 passthru 调 C （你没看错就是 ANSI C ）写的实际控制程序。
只有两段 JS ，一个用来显示动态曲线图，一个用来显示图片缩放。
因为这个系统要求的基本上是实时响应，去你娘的 web 渲染，哪有那闲情逸致。
不过说实话这样写的代码真的非常简洁清晰，很容易看懂，维护起来很方便，加个新功能也就半个小时（算上测试）的事情完事儿了。

ecloud

2016-08-17 14:12:47 +08:00

@YuJianrong 跟大小无关，关键看需求
IBM 以前的 CM 就是很低耦合的系统，也算是很复杂的东西了，但是 web 前端基本等于没有
然后一些客户就抱怨说你们的 web 太烂了，能不能给我们一个好看的界面
然后 IBM 收购了 FileNet ，用 FileNet 那套花哨的前端架在自己的后端 CM 上
结果是花了很多很多钱，人力物力。然后那帮客户后来又发现，在这个前端上他们要做二次开发可就迷糊了，又想退回去了
其实很多时候那些用户们并不知道他们究竟想要什么东西，这就是为什么 Jobs 能成功的秘诀

FrankFang128

2016-08-17 14:24:46 +08:00 via Android

@tflz514 他手画的

akira

2016-08-17 15:03:10 +08:00

看了下视频，其实就是在宣传 turbolink 的炫酷叼炸天

YuJianrong

2016-08-17 21:01:46 +08:00

@ecloud 这是产品要背锅的。如果有大量二次开发的需求，那么在第一时间就要考虑到二次开发怎么做，甚至把自己团队降低到第三方一样的高度来先搞好二次开发框架（其实也没有二次开发框架了，就是一样的开发）。
但这难度太大了，以 KPI 论的大商务软件公司真的很难搞（比如我司）。

Geeker

2016-08-17 21:17:24 +08:00

@quiz 什么叫数据可视化驱动。。 2333

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

2016-08-17 21:52:50 +08:00 via iPad

@Geeker 就是产品设计，技术选型，还有架构设计都是围绕数据可视化来做的，以把有价值的数据以最直观的方式展现给用户为目标驱动研发。语言是写的太精简了，主要怕影响大家灌水。本以为做过成熟商业软件开发的 v 友们都能 get 到 point ，实在不能理解的估计是经验还有看问题的思维比较不一样，不过可以一起探讨。跟檀木网站上比可能用语方式是不太一样可 v 站是专业技术社区，想必说的缩略点大多数专业极客 v 友们还是可以理解的，如果实在理解不能可以到漫展上约我当面切磋- -！

YuJianrong

2016-08-17 22:16:06 +08:00

@ecloud 我说产品背锅不是说背收购前端技术公司这种锅，而是对自己产品定义上的锅。不管收购了什么前端技术公司，只要能清晰定义出以扩展性为第一优先，所有技术都围绕如何方便和安全地扩展来开发，也能达到满足第三方扩展的需求。

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

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

这么说来也不是产品这个职务的锅，主要还是回到产品原始定义上去，本来就定义成好看但不易扩展的产品，那自然就很难做出方便二次开发的产品。然而不幸的是，一般原始定义产品的时候，大佬们都只想着花三分钱办五分事，尽快把东西弄出来（毕竟人家的 KPI 是这个），而不是为以后真的推向市场的时候的扩展性来花十分功夫打基础。

shooter

2016-08-17 22:23:35 +08:00

@panlilu 这没必要吧

jadecoder

2016-08-18 01:18:39 +08:00

很好，第一次听说康威定律，值得深思

genffy

2016-08-18 01:21:25 +08:00

哎，天天扯这些没用的。

loser

2016-08-18 02:37:53 +08:00

tower / 知人用户路过帮顶
选择适合自己的即可，没必要争论
over

tomatoo

2016-08-18 08:25:02 +08:00

Tower 用的是 Vue + API 模式吗？
为啥打开控制台没看到 vue ，是我打开的姿势不对吗？

seaify

2016-08-18 09:53:12 +08:00

@kshift

rails + vue, web 端我是这样弄，但是移动端这样弄，是指原生+webview ？求解惑

daysv

2016-08-18 10:28:14 +08:00

虽然我是前端（写 exe 的前端 XD ），其实我也觉得前端炒作过热了，感觉市场真正需求的还是全栈。
但是全栈技术栈比较杂，很难互相匹配。

tomatoo

2016-08-18 13:20:02 +08:00

@daysv @FrankFang128 这样比较难招人吧你让一个写后端的去做前端的事情，做出来的用户体验一般比较差的(前端不只是完成逻辑，更要重视用户体验)，或者开发周期长，同样你让一个前端熟手去写后端，也会遇到各种性能问题，尤其是数据量大的情况下，这些都是我真实遇到过的。这个问题怎么解决呢？毕竟称得上 web 全栈的还是太少了。