Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ReactEurope Conf 参会感想 #1

Open
dfguo opened this issue Jul 14, 2015 · 67 comments
Open

ReactEurope Conf 参会感想 #1

dfguo opened this issue Jul 14, 2015 · 67 comments

Comments

@dfguo
Copy link
Owner

dfguo commented Jul 14, 2015

ReactEurope Conf 参会感想

React 带来的革命性创新是前端世界过去几年最激动人心的变化。自从接触 React 以来,我深信 React 会改变客户端开发者(包括前端、iOS 和 Android)的开发体验。这次在巴黎举办的 ReactEurope Conf 大会是继第一次在 Facebook 总部举办后最大的 React 活动。超过10位来自React、GraphQL、Relay 团队的核心技术成员也出席大会进行分享。这次代表 Strikingly(似乎也是国内唯一家公司)去参加,想写下一些参会感想。

Keynote [1] 讲师是来自 Facebook 的 Christopher Chedeau (vjeux)。他分享了 React 生态系统四大方面 (Data, Targets, Language, Packager)的变化。这次大会所有的内容我觉得也都是这四方面的延伸。我印象最深的是 Data 和 Targets,也是这篇文章主要想分享的内容。

Data

React 定义自己为 MVC 中的 View。这让前端开发者从 V 开始去思考 UI 设计。但现在针对数据操作和获取方式,社区里还没有一种公认的方法。这也是任何写 React 应用时最难处理的地方。

Flux

对于 M 和 V,Facebook 提出了 Flux 的概念。之后,几乎每个月出现一新的 Flux 库,他们都有各自的特色,有的对服务器渲染支持比较好,有的运用了更多函数式编程的概念。很多 Flux 库更像是实验,这有助于 React 生态的生长,但不可否认的是,未来会有大量 Flux 库慢慢死去,而只有少数会存留下来或进行合并。。大会上 React Hot Reload 的作者 Dan Abramov 也介绍了自己新的 Flux 库 - Redux。这也是大会上最受瞩目的演讲之一。Redux 认为 Flux Store 就像函数式编程里的 reducer

f(init_state, action) => state

通过这种方式,我们只要存下所有 action 就可以像时光穿梭一样去到任何时间点上的状态。

Redux 应该是现在最函数式的 Flux 库。私下和 Dan Abramov 的交流中,他告诉我,他正在和其他几位 Flux 库作者接触并有意进行合并,也许 Redux 会是少数存留下的 Flux 库之一。

相关演讲:

[1] Christopher Chedeau - Keynote

GraphQL / Relay

GraphQL 和 Relay 是我这次参加大会最关心的技术。在构建大型前端应用时,前端和后端工程师通过 API 的方式进行合作。API 也是双方的协议。现在主流的方式是 RESTful API,然而在实践中,我们发现 RESTful 在一些真实生产环境的需求下不是很适用。往往我们需要构建自定义 endpoint,违背了 Restful 的设计理念。GraphQL 是我认为目前最完美的解决方法。这次大会也没有让人失望,推出了 GraphQL 的规范 并 开源了 JavaScript GraphQL 库。

然而要让 GraphQL 成为主流,Facebook 需要打造一个像 React 这样的生态系统。目前只推出了规范 和 GraphQL JavaScript 库(适应于 Node.js 应用)。要想在你自己的应用上用 GraphQL 还必须要有后端语言提供 GraphQL 库的支持。比如 Strikingly 需要 GraphQL Ruby 库。这不仅仅需要前端工程师。我认为这将会比 React 生态系统更难建立。Facebook 需要整个社区的参与才能达到。


(图片来自《Creating a GraphQL Server》[5] 演讲)

Relay

Relay 是 Facebook 提出的在 React 上应用 GraphQL 的方案。React 的基础单位是组件(component),构建大型应用就是组合和嵌套组件。以组件为单位的设计模式是目前社区里最认可的,这也是前端世界的趋势之一。每个组件需要的数据也应该在组件内部定义。Relay 让组件可以自定义其所需要 GraphQL 数据格式,在组件实例化的时候再去 GraphQL 服务器获取数据。Relay 也会自动构建嵌套组件的 GraphQL 查询,这样多个嵌套的组件只需要发一次请求。这次大会也公布了 Relay 将会在8月份开源。

Immutability

React 社区接收了很多函数式编程的想法,其中受 clojure 影响很深。immutable 数据的使用就是来自 clojure 社区。当年 Om,这个用 ClojureScript 写的 React wrapper 在速度上居然完虐原生 Javascript 版本的 React。这让整个社区都震惊了。其中一个原因就是 ClojureScript 使用了 immutable 数据。React 社区里也冒出了 immutable.js,这让 javascript 里也能用起 immutable 数据,完美弥补了javascript 做负责数据对象比较的先天性不足。immutable.js 的出现也成为了构建大型 React 应用的必备。本次大会甚至有在讨论是否把 immutable.js 直接纳入 javascript 语言中。我个人认为小型应用不会遇到 virtual DOM 渲染瓶颈,引入 immutable.js 只会让数据操作很累赘。

相关演讲:

[2] Dan Abramov - Live React: Hot Reloading with Time Travel
[3] Lee Byron - Exploring GraphQL
[4] Joseph Savona - Relay: An Application Framework For React
[5] Nick Schrock & Dan Schafer - Creating a GraphQL Server

Targets

对于 Virtual DOM 的讨论,很多人会说速度快过于真正的 DOM。这样的讨论可以让人快速入门理解 React,但是真正写过 React 应用的人会明白速度并不是 Virtual DOM 的精髓。我认为 Virtual DOM 的存在帮助我们做到了两件事。第一是声明式 UI。通过 Virtual DOM,UI 不再是一个不断被更变的 DOM,你只要声明 UI 是怎么生成的,React 会自动帮你把 UI 的改变渲染到真正的 DOM 上。这种新的思维方式让你可以不用手动操作真正的 DOM。第二是多 target。我们一直在讲 web,但 React 让我们做到 web 以外的 target。Virtual DOM 更像是 UI Virual Machine,自动帮你映射到真正的实现上。可以是 浏览器 DOM 、iOS UI、Android UI。在大会上,甚至有人做了 React 映射到 Terminal Text UI [7]。

多 Targets 是这次讨论的主要话题之一。多 targets 的根本是 提高开发者体验。这是本次大会上屡次被提起的概念。我们如何在保持一样的用户体验下,提高开发者体验。

任何一家有多客户端的公司都面临同一个问题:在各种客户端语言里重新造轮子。开发者需要学习新的语言、写和维护类似的功能。提升客户端开发者体验就是减少学习成本和维护成本。这就是 React 提倡的 learn once, write everywhere。

本次大会上也有一些鼓舞人心的消息。Facebook 内部 Ads Manager iOS 版本由 7 位工程师用 React Native 花了 5 个月完成。而 Android 版本,是同一班人,3个月内完成。代码重用率达到了 87%。而且在 React Native 中,大家比较关心的动画效果和速度的问题,也在这次大会上通过 Facebook 工程师 Spencer Ahrens 演讲中的流畅演示得到了令人满意的答案。

多 targets 也可以是在单个平台更深度的结合。这次大会最让我目瞪口呆的是 Sebastian Markbåge 的演讲《DOM as a Second-class Citizen》。演讲中他畅想 React 直接输出到浏览器架构的底层。


这是浏览器的渲染架构


这是 Sebastian Markbåge 认为 React 可以做的事情。

我当时听完后凌乱了。姑且不谈该不该这么做,我觉得 React 通过 Virtual DOM 能让我们有机会做到就已经让我兴奋不已了。也说明了 Facebook 在设计 React 时已经考虑到超越 DOM。真 TM 的 NB。。。

相关演讲:

[6] Spencer Ahrens - React Native: Building Fluid User Experiences
[7] Mikhail Davydov - Back to Text UI
[8] Sebastian Markbåge - DOM as a Second-class Citizen

其他演讲

篇幅原因,我不详细讨论 Language 和 Packager。但对有几个演讲也留下了深刻印象:

Sebastian McKenzie - Improving Your Workflow With Code Transformation

演讲者是 Babel 的作者 Sebastian McKenzie。Babel 是目前社区里最受欢迎的代码编译工具。Facebook 团队甚至已经决定转用 Babel 而不再维护之前内部使用的 jstranform。

使用 webpack 或 browserify 这类工具编译代码已经渐渐成为前端工程师工作流程的一部分。Sebastian 这次分享了编译代码所带来的好处。他也刚在 Twitter 上宣布加入 Facebook,全心做 Babel。期待未来 Babel 能够带来更多的可能性。

Cheng Lou - The State of Animation in React

最早关注 Cheng Lou 是因为他写的 react-tween-state 动画库。一直一来大家都对动画应该在 React 里怎么表达(示)为状态感到困惑。react-tween-state 是我认为最符合 React 思维的做法。把位移存在 state 里,然后通过 javascript 动态渲染新的位置。不过大家对该做法是否能达到满意的速度一直持有保留态度。这次在他的演讲中也展现出了非常出色的效果和速度,非常值得一看。

总结

这次赫门在 JSConf 2015 上提出了前端的摩尔定理:前端每18月会难一倍。虽然他是故意搞笑的,但也确实说明了前端变化的迅速。我觉得前端之所以变化这么快,是因为我们现在面临着前所未有的工程化挑战。今天的前端复杂度跟几年前完全不是一个等级。这也促使着社区要找到在这种复杂度下能保持开发效率和开发体验的工具和设计模式。React 社区从其他领域(游戏渲染、ClojureScript、函数式编程)偷师学艺,结合前端面临的独特问题,提出了一系列解决方案。我觉得 React 社区在各方面都推动着前端社区往前进。这对整个社区都是好事。我也希望前端各个框架,就像 Christopher Chedeau 在 keynote 上说的,停止攻击,互相学习,共同推动整个社区的发展。

It's an exciting time to be a front-end developer.

郭达峰
CTO of Strikingly.com

感谢 题叶、寸志、沈瑜杰、冯哲锐、王徐阳、徐欣 协助修订校对稿件

(这也是 Strikingly 团队做的首次技术分享,之后我们也会继续分享更多的前端技术及相关资讯,请关注我的微博GitHub

@island205
Copy link

火钳刘明

@hussion
Copy link

hussion commented Jul 14, 2015

@rachardking
Copy link

@leoli-dev
Copy link

赞!
“前端每18月会难一倍”,感觉前途一片黑暗。。。说笑哈,前段越来越难同时也越来越强大,这是网页开发者的福音,回想08年的时候搞个页面需要用各种hack,加动画效果只想到flash,那才是真正的Dark ages。

@liyaodong
Copy link

感谢达峰的分享,中文社区非常需要最前沿的技术

@airyland
Copy link

@caiyongmin
Copy link

go big!

@zwhu
Copy link

zwhu commented Jul 14, 2015

感谢分享,赞达峰

@hufeng
Copy link

hufeng commented Jul 14, 2015

@dfguo 太赞。

@Zkuns
Copy link

Zkuns commented Jul 14, 2015

hoho,赞一个

@cedcn
Copy link

cedcn commented Jul 14, 2015

很棒的文章,感谢分享

@ZpCooper
Copy link

很好的文章, 正准备学

@hupili
Copy link

hupili commented Jul 14, 2015

“前端每18月会难一倍” -- 確是亮點。前端複雜度增加,逼着大家不斷學習新的工具。

@jialezhang
Copy link

大赞!

@zhanglun
Copy link

前端已不只前端

@hongbinzuo
Copy link

酷,学习了!

@Huxpro
Copy link

Huxpro commented Jul 14, 2015

赞~

@fakefish
Copy link

It's an exciting time to be a front-end developer.

越来越有意思了呢

@bencrox
Copy link

bencrox commented Jul 14, 2015

分享下去就對了。也許日後可以把章節分篇寫,主題集中一點,會更方便討論。

@lishengzxc
Copy link

留名,前端摩尔定律促使我不断学习。

@udonmai
Copy link

udonmai commented Jul 14, 2015

弱弱地留名。

@FrendEr
Copy link

FrendEr commented Jul 14, 2015

赞!👍,留名支持一个😁

@geekplux
Copy link

也就是说要在18个月内把现有的知识全消化掉,以便迎接新的知识

@Keystion
Copy link

赞一个,马克一下

@dfguo
Copy link
Owner Author

dfguo commented Jul 14, 2015

文章重点不是。。。

前端每18月会难一倍

那是赫门这次在 jsconf 说得段子。。别太当真。。

@L42y
Copy link

L42y commented Jul 14, 2015

当年 Om,这个用 ClojureScript 写的 React 在速度上居然完虐原生 Javascript 版本的 React

依我的理解,Om 是构建于 React 之上,而不是 React 的 ClojureScript 实现

Om 的介绍里也说了:

A ClojureScript interface to Facebook's React.

@pynixwang
Copy link

一楼太那啥了。。。

@wptad
Copy link

wptad commented Jul 14, 2015

赞,mark

@KeithZhang
Copy link

太赞了

@execution7
Copy link

👍

@vagusX
Copy link

vagusX commented Jul 15, 2015

太赞了

@ChenQiuge
Copy link

谢谢达峰分享,文章已分享到CSDN极客头条:http://geek.csdn.net/news/detail/35713。
注:极客头条是分享优质技术文章、深度交流技术话题的社区,聚集了众多热爱钻研技术、愿意分享技术的人。http://geek.csdn.net/news/detail/33304

@hheedat
Copy link

hheedat commented Jul 15, 2015

赞👍

@luqin
Copy link

luqin commented Jul 15, 2015

感谢达峰的分享 👍

@tangrui
Copy link

tangrui commented Jul 15, 2015

@ChenQiuge 手好快呀!

@examango
Copy link

华丽丽

@luqin
Copy link

luqin commented Jul 15, 2015

@dfguo @island205 感觉到了前端在驱动后端、浏览器等各个方向的发展...

@damoqiongqiu
Copy link

虽然看不懂,但是还是赞一下吧。

@yczf1836
Copy link

赞一个

@shanelau
Copy link

一直在关注 react

@1ternal
Copy link

1ternal commented Jul 15, 2015

感谢分享!

@zhex
Copy link

zhex commented Jul 15, 2015

前端能真正把android,ios的开发归并进来就会是react带来的最大创举。nodejs也许未来会是所有大型项目的前置层。所以不一定要graphSQL for ruby,加一层node也许以后的想象空间更大

@rayston92
Copy link

赞一个 !

@fanhc019
Copy link

火后刘明

@kuailingmin
Copy link

随时刘明

@steelli
Copy link

steelli commented Jul 19, 2015

感谢分享

@sun-sheng
Copy link

👍感谢分享

@yofine
Copy link

yofine commented Jul 21, 2015

@dantetwc
Copy link

(y)

@dfguo
Copy link
Owner Author

dfguo commented Jul 27, 2015

@zhex 嗯,也可以那么做的

@dfguo
Copy link
Owner Author

dfguo commented Jul 27, 2015

@luqin 这也是激动人心的地方 :)

@dfguo
Copy link
Owner Author

dfguo commented Jul 27, 2015

@offbye 完全同意。

@dfguo
Copy link
Owner Author

dfguo commented Jul 27, 2015

@L42y 已更正,谢谢提醒!

@creeperyang
Copy link

感谢分享前沿动态 👍

@icharlie
Copy link

👍

@wangxiao
Copy link

当一个事情全是赞扬的时候,应该就说明还是有些地方出问题了吧,要不我就评论下。

FaceBook 也是有一帮技术大牛,需要一些新的 OKR(KPI),各位还是要保持着一颗冷静的心来看待这些新概念和新东西。

React 本身并没有特别多让我激动的点,当然 React Native 还有点意思,可以再研究研究。

React 本身只是一个 View,之前也有很多能够实现组件化封装的库,远的很多名字我记不清楚了,近的有 Angular 的 directive、Polymer、甚至是直接写 Web Component 等。Virtual Dom 的概念,其实就是编程中的 cache,以前写模板引擎的时候也都会生成一个类似的东西(编译后的 JS 函数),如果要生成 Dom ,有的也会放到 Fragment 中,不会直接在页面上生成。当然 React 不是这样实现的,但 Virtual Dom 也是类似的思路。感觉 React 最大的创新点应该是 JSX 编译上面,而且能够推动一帮人做了 iOS 和 Android 版本。这玩意用在 Web 上面本身其实没有什么真的特殊的优势,但是如果结合 iOS 和 Android 确实是解决了开发效率的问题。

Flux 这个概念说的那么高大上,还说了很多 MVC 的问题,但是。。。这些问题也都是随着项目不断复杂累积上去的。Flux 的 Store 给人感觉就是一个大大的状态机(翻译下,就是一个大 Object),然后管理着不同模块的数据,居然通过 Dispatcher 一个大大的事件中心来处理和分发所有操作及数据。好吧,有很多人居然说这个简洁,高手其实用什么工具写都是很简洁的,问题是很多人使用单一事件中心就会很容易出现时序问题、事件爆炸。。。项目大了如何维护?一个事件一个事件的找对应,关键是事件一个很分散的东西,很可能多个位置会被一个事件所触发。不过,也可能我没有深入使用,不知道 Flux 是否增加了强约束,但这样又太不灵活,模块间无法通信。

目前来看,如果在纯 Web 上面使用 React 并没有在开发上面有什么优势,但是支持 IE8 和服务器渲染首屏还是可以尝试的,大项目如果要用要三思,因为没有一个整体的方案。而且 React 去掉了双向绑定之类的东西,个人开发体验上觉得没有 Angular 好用,成体系。

感谢作者记录,文章是好文章,感谢分享。

@dfguo
Copy link
Owner Author

dfguo commented Aug 11, 2015

@wangxiao 我喜欢 contrarian 的态度。

VD 我就不大说了,同意你的看法,所以文章里我写了

对于 Virtual DOM 的讨论,很多人会说速度快过于真正的 DOM。这样的讨论可以让人快速入门理解 React,但是真正写过 React 应用的人会明白速度并不是 Virtual DOM 的精髓。我认为 Virtual DOM 的存在帮助我们做到了两件事。第一是声明式 UI。通过 Virtual DOM,UI 不再是一个不断被更变的 DOM,你只要声明 UI 是怎么生成的,React 会自动帮你把 UI 的改变渲染到真正的 DOM 上。这种新的思维方式让你可以不用手动操作真正的 DOM。第二是多 target。我们一直在讲 web,但 React 让我们做到 web 以外的 target。Virtual DOM 更像是 UI Virual Machine,自动帮你映射到真正的实现上。可以是 浏览器 DOM 、iOS UI、Android UI。在大会上,甚至有人做了 React 映射到 Terminal Text UI [7]。

当有很多事件的时候,维护 Flux 的问题确实是存在的。不过我认为你说的很可能多个位置会被一个事件所触发对于大型前端界面来说是一个正常的需求。这也是 Flux 出现的原因之一。最后,我不是很能理解你指的时序问题是什么样的。

个人认为在 web 上使用 React 还是有很多优势:服务器渲染首屏、SEO、组件化 UI 设计。这些对于一些应用场景来说(比如 Strikingly)是非常重要的。我们从 Angular 和 Knockout 迁移到 React 后总体感觉开发体验和效率比以前好。

另外,我和同事写了一篇覆盖范畴更广和深的文章,在最后也讨论了目前 React 的一些挑战和问题。

@wangxiao
Copy link

好的,我有空再看下。

@hcy2367
Copy link

hcy2367 commented Aug 28, 2015

support

@yozol
Copy link

yozol commented Sep 29, 2015

干货,赞

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests