如何评价 React Native？
write native apps with React.js？
先说结论：必有作为，但绝不会是一家独大，甚至很难成为主流。用过 React 会知道，React 的核心概念是「DOM Representation」，在开发者和 DOM 中间构建一个中间件，然后通过高效的算法来 diff 两次 Virtual DOM 渲染的差异，然后在最小范围内更新 DOM，在大部分情况下——注意是大部分不是所有——这种做法都是足够高效的，但是对于精细的需求、动画控制等——比如在移动设备上做一个跟随 touchmove 的元素，还要各种 transition 等等——场景 React 会显得力不从心，或者很笨拙。但是抛开这些太过复杂的需求，React 是有能力满足大部分的业务场景的。再说 React Native，这几天不停看见媒体用「Web 开发要 XXX」一类的题目来发稿，真是吐槽无力。React Native 根本都不算 Web 开发好不好——Webview 都没了还 Web 个 bird 啊...React Native 继承了 React 在 JavaScript 的扩展语法 JSX 中直接以声明式的方式来描述 UI 结构的机制，并实现了一个 CSS 的子集，这把「DOM Representation」的概念外扩成了「UI Representation」，由于不是操作真实 UI，就可以放到非 UI 线程来进行 render——所有做客户端 UI 开发的都应该知道 UI 线程是永远的痛，无论你怎么 render，render 的多低效，这些 render 都不会直接影响 UI，而要借由 React Native 来将改变更新回 UI 线程。由于目前没有任何示例代码，也看不到更细节的实现机制介绍，所以以下部分为猜测。如果 React Native 沿袭 React 的机制，就会同样是把两次 render 的 diff 结果算出来，然后把 diff 结果传递回主线程，在最小范围内更新 UI。所以，核心是以下三点：1. 在非 UI 线程渲染 UI Representation2. 高效的 diff 算法保证 UI update 的高效3. 没错，由于中间件的机制，React 很有可能成为一个跨平台的统一 UI 解决方案，可以理解为 UI 开发的虚拟机？声明式 UI 开发，简单快捷，必然大有作为。精细控制无力，复杂应用场景无法很好满足，必然受限。最后再说一句...不是能写 JavaScript 就叫 Web 开发...============================================看了 的答案后来补充。这个答案作为补充或扩展来回答「React + Flux 模型」是非常好的，但问题是「React Native」。React Native 的亮点是解决了在 Native 中使用声明式来开发 UI 的渲染效率问题，而不是软件架构和工程模型的问题，无论是 iOS 还是 Android 固有的模型也是非常好的。为啥 FE 会在乎这个？因为 FE 最习惯用声明式来开发 UI，而这么多年想参与到 Native 开发中的目标都没能达成，就是受制于最终的运行效率。React 作为一个 View Component 封装解决方案来讲，同 Polymer 以及 AngularJS 中 Directive 并没有本质区别，只是用不同的思路来封装 View 而已，用 React 也不一定非得用 Flux 模型，React 替换 Backbone.View 组件，用纯朴的 MVC 模型来描述也是 okay 的。但是当 component 很多且互相嵌套时，就需要有一个合理的模型来描述通信机制，优雅且高效，那就是 Flux 模型了。前年 React 刚发布，还没有提出 Flux 时，我们在终端产品中开始小范围尝试 React 就遇到了 component 之间通信麻烦或者不合理的问题，当时的解决方案是全局实例化了一个继承 Backbone Event 的对象作为 event hub，所有的 component 都在其上来 reg 和 trigger 事件。现在看来，就是简化版的 Flux 模型。不过我确实有一点遗漏的内容，React 的 DOM Representation 或者 React Native 的 UI Representation 的每个 component 都有一个 state 用来描述状态，而 component 某种意义上来说就是一个状态机，因此渲染结果是幂等的。近些年 Web 前端的开发越来越多的受到工程复杂度上升导致整体性能下降的困扰，所以最近几年的新型框架大多有一些独特的机制来提升性能，而这些机制大多是从 Native UI 或者游戏开发中借鉴来的，比如 AngularJS 中的数据 dirty check 机制，比如 React.js 中 Virtual DOM 的 diff 机制，这些特点同以前的前端框架或库相比，真的是非常特殊且先进的改进，往往也会成为这个框架或库的亮点之一，对 FE 来讲当然就是新鲜玩意啦。最后，Facebook 在 PHP 中直接写 HTML Tag 那东西叫 XHP，对应是 JSX 扩展语法，和 React 关系也不大...
哈哈，大家都不看好它，我倒是觉得它非常不错。先说一下传统的 hybrid app 的一些优劣势：优势：js 可以直接被 native 端执行，也可以和 native code 进行通讯，进而可以调用一些 native 提供的接口。 能直接被执行的好处在于可以直接从服务器上载入并执行 js 代码，这点在 iOS 上是 native code 和其他 to objc 的语言都难以做到的。这使我们有了一些更灵活的方法，来完成诸如应用内更新或者开发应用内插件之类的工作。同时，iOS 和 Android 可以共享一些前端部分的代码，使得代码能够更好地重用。劣势：界面渲染效率低，多线程支持差，GC 问题。在 WebView 中绘制界面、实现动画的效率都比较低，开销也比较大。WebWorker 提供的多线程在 native 端有很大的局限，js 在 GC 时也有可能卡 UI。React Native 的做法非常激进，完全抛弃了 HTML（抛弃了 HTML 不代表抛弃了声明式），抛弃了 WebView，在 background thread 里运行 js 并直接使用原生控件进行渲染。这从根本上解决了渲染问题，使得 js 不再只能做 hybrid app，而能做出具有 native behavior 的流畅靠谱的 native app。从这一点上来说 React Native 已经做得相当不错了，尽管它只实现了 CSS 的子集，但是考虑到 CSS 如此复杂而它又抛弃了使用 webview 渲染，这是可以接受的。===========但是，React 的意义绝不在于解决了一些 hybrid app 的痛点。React 是一个很有野心的项目，它的目标不仅仅是简单地使前端能用 js 写 native app，而是希望推广一个通用的前端构建方案，不论是 Web 前端，还是客户端前端。FB 在演讲里说，React 的目标不是 “Write once, run anywhere"，因为不同平台的差异是客观存在的，设计风格也各有不同。它要做的，是 “Learn once, write anywhere”。React 里的 view 不仅可以是 DOM，也可以是 iOS 控件或者 Android 控件，不论是什么平台，都能 “build in React”。就我看来，前端不只是需要写网页，更重要的是要解决属于前端领域的各种问题。Web 前端和客户端前端在本质上是一致的，探索前端领域的最佳实践是一件很有意义的事。近些年前端比较火，相比于自成体系较为封闭的客户端前端， Web 前端在前端实践上的探索或许更多一些。不管是阿里的 Midway 那样侵入到后端的 UI layer，还是像 React Native 这样侵入到客户端前端，我认为都是非常值得称赞的探索。至于到底怎么评价 React Native，我觉得它和 React 一样赞。===========最后附个 FB 关于 React Native 的演讲：
看了所有的答案，都没有讲清楚React的实质作用在哪。我上周用纯React完成了一个CMS发布系统的界面框架，数据层仅仅用了Parse的JS库，但是功能还算完备。中间读了不少这方面的资料，对Flux + React有了一个较为系统的了解。这里大致总结一下给还没开始动手写React的人一点启发。要讲React的实质作用那一定不能脱离Flux模型。一说到Flux，很多人的第一反应就是那个经常见到的、看起来很复杂的Loop流程图。我不想一开始就贴那张图，因为我默认你们都没真正用过React，那张图只能让你们更加不明觉厉。其实了解Flux + React最好的方法就是看看官网给的，我就把重点摘出来讲讲吧。首先，Flux是为了解决MVC模型中数据流向不一致的问题的。视频中给出了一个非常典型的案例，可以说我以前也被类似的问题折腾了好久。比方说你从服务端拉下来的数据要改变两个View的内容，比如给未读消息的数字提醒+1，然后把消息放到Chat View中，如果用户正在看当前的Chat View就把未读消息数字-1。这一连串的操作在没有用React的时候要怎么写？她给出的代码也是我以前处理类似状况的方法：我以前也不是没想过写一个MessageManager之类的，类似Flux的Dispatcher一样的东西去控制这些逻辑然后分别对不同的View进行改动，但是好好想想这不过是一个简单的信息接收而已啊，为啥要复杂到专门给一个数字写一个Dispatcher去做这种事情？所以最后想想还是算了，代码丑点就丑点，能用就行，最后我也写成上面那样了。但是你要知道，这样的代码写在异步程序里是非常危险的！如果用户同时在操作，那你的代码很可能就会被中断报错的。还有，如果后期需要加功能，比如在屏幕侧边再搞个信息框，那你怎么知道在哪去加代码？你程序的数据交换会像这样混乱：怎么样？写异步MVC的童鞋有没有感同身受？脸书以前的Chat就是经常因为异步数据的问题被人黑。比如经常是右上角一个红色的1，点进去一看啥都没有，强迫症的怒火你可晓得？那么问题来了：如何让异步数据像同步数据一样正确地显示出来？脸书的攻城狮想到一个绝妙的招式：咱别一个DOM一个DOM的去更新内容了，来一次数据俺们就“刷新”页面！是的，就是回到了90年代的那种模式：你想看新邮件？请刷新页面！然后服务端把你当前的邮件全部读一遍，排好序，生成好HTML，然后给你寄过来，你就能看到新邮件啦。Flux就是这么干的，只不过现在已经是21世纪了，渲染HTML这种工作不需要服务端也能做，我们也不用真的去刷新整个网页，虽说Chat的那个问题的确可以靠刷新页面解决掉lol。Flux的（大致）做法是：来新的数据了，好，我把它Merge到客户端的旧数据中，然后把客户端存着的所有数据交给一个Render，然后把整个HTML从头到尾渲染一边，最后把新的HTML替换掉现有的HTML就好啦！那么之前那个Chat的代码咱就可以这样写（我YY的，视频没有，也不是React代码）function newMassageHandler(newMessage) {
this.messages.push(newMessage);
this.renderTheWholePage(); // In practice it should be an Action Creator
看到没有？管你有多少个View，你们自个儿去算怎么渲染吧，handler只管存数据跟提醒渲染。如果哪个View计算完了说，不对，那个Unread Message Number要-1，好，你跟Action Creator说一声，他会在下一轮渲染前把这个项目加到数据中的。如此一来就不会出现把改动View的代码写到某个Controller中，然后一个Controller又要同时关联好几个View的情况，这样一来整个程序的结构就变得非常清晰了。这时候再看这张图就容易理解多了：数据的流向变得非常统一，如果View要对数据做些改动也得等整个View渲染完了在下一轮渲染的时候再改，从而形成一个非常完整的Loop，这对异步数据的处理是非常有帮助的。Flux是一个取代MVC的设计模式，而React就是脸书写的给Flux用的专门做Viewer的框架。由于Flux要将原有的HTML从头到尾渲染一边，那么就不得不考虑一个平滑过渡的问题，因为毕竟我们要讲究用户体验，不能每次收到数据就真的把原网页给删了然后重新给用户画一个，那用户还不崩溃啊？React解决这个问题的办法就是用Virtual DOM，这才是React真正的核心价值。其原理是写看起来像是DOM的JS代码，然后生成ReactDOMElement的对象，而不是真正的DOM，然后把新的Virtual DOM Tree跟用户正在看的DOM Tree做个Diff，然后用最小的改动量Update整个网页。对比一下jQuery大概就是这样：// jQuery
$('&button&').text('Submit').on('click', submitHandler);
// &button&Submit&/button&
// React without JSX
React.creatElement('button', {onClick: submitHandler}, 'Submit');
// &ReactDOMButton&Submit&/ReactDOMButton&
// React with JSX
&button onClick={submitHandler}&Submit&/button&
可以看到，其实JSX只是React的一个语法糖，这只不过是一门DSL。有些人一看到JSX就说把HTML写JS里了，我真是不知道该怎么评价这种人。ReactDOMButton并不是真的DOM，在运行时只是一个普通的JS Object，我写成XML形式只是易读。不用真的DOM当然是因为效率问题，这也是一种优化手段，但是Virtual DOM的好处当然不止这样，后面会讲。你要是不喜欢JavaScript也没事，我就不喜欢。知道GitHub的Atom吗？就是用CoffeeScript + React写的。它并不是用改过语法的那个看起来就很恶心的coffee-react项目，而是自己写了一个很简单的helper来做简单的Transform。大致的原理是这样的：{div, button} = require('react').DOM
className: 'message'
onClick: @messageHandler
'some messages'
我觉得这样的写法真的很简洁很优雅，而且一想到这写的根本就不是HTML也没碰一行JavaScript就觉得很开心啊。不过我是LiveScript党，有更加简洁的语法，把Atom的helper改了改现在用在别的项目中用得很方便。看到这样的写法观众就应该很清楚地明白了React的原理了吧，它实际上就是把DOM元素全部变成了JS的类，可以直接用JS等价的代码调用new出来。（实际上是要用一个factory包着才能用的，0.12后把createFactory整合到createElement里面了所以现在用法上更加简洁）但是千万不要以为React就只是JS世界中的东西，其实它也是受到别的领域的启发呢。上面那个视频中后半段详细介绍了React，其实React这种idea受启发于游戏的渲染。有很多游戏都是数据来了，跟现在的数据Merge一下，然后update数据结构，diff一下老的结构，然后再部分渲染。所以说React其实最重要的还是一种使用Virtual Element描述界面的方式，而因为这种方式容易进行二次计算，所以能够保证最小幅度的影响用户体验，最大幅度地保证数据跟界面的一致。因此React才能够很轻易地使用在后端，做给Spider渲染HTML的工作。要知道Angular在之前是做不到这一点的，对搜索引擎的优化竟然要用到PhantomJS！而且这种方式竟然还演变成了收费的服务！简直让人咋舌。但是React却能做到，因为它并不受限于JavaScript，脸书最先用React做后端的时候是PHP的，后来整合Instagram的时候才分离出来写了开源的JS库。所以我觉得React Native的最终形式并不仅仅是把Web做到移动端上，因为那样根本没法跟Native的比。而是要把React这种Viewer的架构在Native上实现，把原有的模板式UI重构成Virtual Elements，然后以更加动态的方式渲染。不过就目前的开发进度来看，这个目标还是遥遥无期。以上。
一直在跟进 React.js , 中文论坛()也主要是我在维护, 吐个槽本人前端, Macbook 用户, Android 用户, 但是不会移动端的开发首先如果 Facebook 发布 React Native, 那么移动端开发的门槛瞬间降低, 非常好的消息当然这个也将促使更多人选择 React 这样一套方案, 社区当中的资源也会更丰富结果就是会有很多人来参与研究用 React 的范式怎样来编程, 这是我们非常希望看到的React 有一个观点很明白, 就是以往的编程太多过程式的写法, 他们想要变成声明式的,因为声明式的写法能讲底层逻辑交给可靠的代码, 那么开发者的门槛极大地降低发布会演讲提到的就是随着应用变大, 逻辑变复杂, 用 React 的话后来的开发者很好上手相信这也是很多人选择 Angular 的原因.. 虽然两者实现声明式编程的语法和方式差别还是不小那么 React 现在靠着它摆脱了 DOM 的高度的抽象, 想要把同样的开发方式复制到本地应用!顺带地, React 把前端的事件系统, Flexbox 布局, 打算复制到移动开发上这个对于前端开发者来说会是很好的消息, 特别是已经用 React 写了很多前端代码的对于移动端我希望是在 React Native 稳定版发布以后, 能被移动端开发者认可...就我个人来说, 我倾向于认为 Functional Reactive Programming 一路的图形开发前途更好比如 Elm, 比如 React, 对界面还有数据及逻辑都做了比较理论化的考虑..那我很期待各种图形开发当中能引入这个我认为非常高效的方案另外, Web 开发当中灵活的布局系统我也希望在我学习开发其他平台时能继续使用.
我先来答吧。从很久以前就警告了用HTML5来做App有多不靠谱，不过各种Cloud还是不断出现。说到底，HTML5做App的优势和劣势都是HTML本身，或者说是DOM，成也萧何败也萧何。归功于CSS这个神器，UI制作变得非常简单而强大。但是却因为DOM这个东西，每次操作都比Native View慢很多，内存开销也很大。========分割线========1. ReactJS在JS圈子里的口碑在不断爬升(虽然我没用过)，组件模式的开发体验对Native App来说非常适合。2. React Native宣称抛弃了DOM，而是纯净的JS Binding。但我还在怀疑他们是打算先用HTML做一次转换，还是直接修改React的体验，适配Native View。如果是后者，相信会非常棒。3. 还需要看看他们用的JS引擎，还有针对Mobile App的优化，比如GC。4. 从我个人角度看，FB把JS Binding和View Binding这套东西开源出来，比React自身更有意义。-----------------------看了 的回答，继续说下。现在确实各方神仙都想用自己的玩具来做本来不属于他们的领域，比如iOS。作为一个长期从事JavaScript开发的人，现在因为需求，要做iOS的开发。可能会有很多人想，有很好的前端能力，用HTML5来做会适合。但我没有这样做，而是买了一本Swift的书，重新学习一门语言。PS: 个人不太喜欢OC的语法，Swift对我来说基本可以跳过语法学习。就如上面说的，我了解完全用HTML5做App的危险性：维护成本，可用性，性能等等。有时候，学习相关的东西比用不相关的东西更来的快，更何况Swift很友好。我想说的是，跟风、傍大款是阻碍程序员进步的品质。还有，别把糖果当成银弹了。
其实最应该期待的是ui以及编译环境的整合，这些已经有ionic做榜样，js to native也有Ti趟了几年雷。工程结构上比ionic的angular讨巧。看起来会牛的，但这些优势目前我串不起来，没法预期会是个什么东西。我多说一点，以我的观察，没ide火起来难。
现在趋势都是声明式UI，React却“反其道而行之”，把UI深绑定到JS中去。然后又嫌编程创建控件的方式，对于UI的树状结构太麻烦了，于是搞出了个JSX。我就纳了闷了，他们团队究竟是对JS有多执念？诚然，以现在的前端生态来看，JS的群众基础的确是好。但是用React以后，要尽量保证与传统DOM的绝缘（下文例1）。从ReactJS的Virtual DOM，到React Native的“No DOM”（引号是因为这词不是官方的）。对JS群众而言是个新的挑战。（而且JSX真的是不怎么不好用啊）因为还没有看到第二天的视频，具体的一些实例代码和技术细节都看不到，但从现在的理解看，它仅仅是用了JS而已，跟前端技术已经没什么关系了，东西都要重新学。这方面我会继续关注后面的视频。然后另一方面，因为我不会做Native开发，不知道各种控件样式一般而言是用什么来定义的，但是如果React Native要搞一套“Native CSS”，这又是个学习成本，同时也是个无底天坑了。定义样式这方面，昨天的视频里没有看到，今天的视频发出来了之后我会再关注一下。小结：React Native除了JSX以外，已经和JS的发源地——WEB前端技术没太大关系了，东西都要重新学。它并不能提供一个用Web的技术和经验来开发NativeApp的方式，这一点与Ionic有本质区别。前端开发者想因此快速做出Native开发，也许做做小样还行，做出严肃的产品，我认为还有距离。结论：我不认为这是一条给前端转Native的出路。----------------------上文例1一些UI控件，比如模态框，很常见的实现方式是把模态框从定义的节点里摘出来，塞进BODY里面，这样定位什么的非常好搞。氮素，这样做会破坏真实DOM与Virtual DOM之间的关联关系，ReactJS会罢工。例如SemanticUI中的modal组件，需要指定`detachable`才能让它不把元素剥离进BODY里去，SemanticUI的文档中说这样做会造成渲染获得更少硬件加速的优化。这还是人UI组件库设计的比较周到，如果是要捡着自己的组件库用，还不知道要踩多少坑。相比之下，Angular要友好一些，我们写的UI组件自己接管状态维护之后，只需要修改$scope，然后调用$apply，把状态维护交还给它的digest循环就行了。具体就不展开讨论了。
当你手中只有一把锤子的时候，任何东西在你眼里都是钉子
瞎说两句：1. 为什么所有语言都想用来写ios？现在还有不能写ios的语言么？2. 看了新闻，感觉还是ionic的思路，可能会更向native渗入一步？用native渲染UI？不过感觉不太可能。3. ionic这种框架并非无用武之地，面向B端的大型移动端CRM管理系统，多人协作，N多操作业务集合，和后台数据极重的业务耦合，这种场景下，考察来考察去，ionic是最适合的，目前感觉没有其他非常成熟的能够应用到生产中的框架。性能方面也不是非常不堪，性能方面ionic做的优化还是不错的，虽然并非完美。4. React和angularjs，没有特别深入，不过我作为一个开发者，并不关心他们的实现有多取巧，性能有多棒，模式有多新颖。我最关心的一点，开发方不方便？是否足够简单？团队开发快速上手？目前没看到React的优势，可能是了解不够多，但是感觉angularjs足够了，也不想了解更多。
Titanium () 就是和 React Native 一样的逻辑，用 js 调用原生控件。这样很好，解决了界面体验问题。不过也有没解决的问题。他们无法代替原生的 API，很多效果，开源的控件，都要用原生的代码来实现。简单的 app 没什么问题。遇到复杂的 app，还是原生代码来的靠谱。
react native做了两件事，一件是react，一件是native。react的核心是组件化，组件化的优势是复用和可视化开发。这样就很容易形成类似visual studio这样强大的界面开发工具。其实，react走组件化的路线更多是为了提供抽象的界面层。有了抽象的界面层就为后续实现大一统的开发环境迈出了第一步。native可以称其为小型虚拟机，或是实时解释器。它的出现就是对底层native的屏蔽。因为没有类似于java的编译步骤，所以就是write once， run anywhere，本质上和java虚拟机是一样/类似的。就此看来react team的目标肯定是做一个大一统的开发平台，对不同的操作系统，web和native兼容并包，那么react native是其中的第二步。
无非是4-5年前的悲剧轮回 典型的好了伤疤忘了疼要知道2012年 fb宣称用h5写iOS客户端 是他们犯的大错Facebook: “Betting on HTML5 Was a Mistake” – Technical Reasons and Reactions
看了那个keynote，我看到的是脸书说他们的js跑到了一个单独的线程里面，所以很流畅。从这个思路来说，应该是直接用native ui的程序员不会注意写多线程，而用了react native 天生并发加成？
HHVM有什么意义？
我现在就在用apicloud写app
前端和非前端看待这个问题有非常大的区别，大多数前端开发人员习惯于html css js的开发方式，看着react的jsx会觉得别扭即使vdom和vdiff还有h性能很高，而非前端看待react就像当年的extjs一样所有逻辑都在js里一目了然、“清晰优雅”，说跑偏了，关于native的问题我觉得fb做了很好的尝试，但是效果怎么样还是得等到我辈开发人员尝试过大规模高复杂度的应用才能有结论，话说最近又有了NativeScript出现，看来js的民间基础确实蛮高的～对了，fb特别喜欢搞一套自己的标签之类的东西，它的开放平台接入应用的界面都是用fbml写的，我当年就很反感这种做法，现在也一样
还好没花200块去凑热闹Front | 动漫驿站
Posts Categorized: Front
是基于开发的内容发布系统，主要用来搭建BBS。遵守GPLV3协议。
系统的后端是简单的发布主题/回复/评论的功能，目前是基于Django(Python)的。使用Python3.2 + Django1.7的架构，Python2.7测试通过。
在界面上模仿NodeBB，前端使用SemanticUI，支持自适应，编辑器使用，同样也是支持自适应的：
因为是面向国内中文用户，所以没有Google的JS/字体API等容易被墙掉的性能，用户头像是使用Gravatar的，因为目前Gravatar可以正常访问。
下载解压或是直接clone，用pip3安装Django1.7。建议使用Python3运行。
git clone /perchouli/erya.git
pip3 install -r requirements.txt
执行migration相关命令，添加管理账号。如果使用默认的sqlite可以跳过这一步，默认的管理账号/密码是： root/root
python3 manage.py migrate
python3 manage.py createsuperuser
进入，添加分类，分类icon请参看：　
回到首页，可以开始使用了。
演示地址：
本来是想介绍的，但如果只介绍这个框架，没什么内容，框架相关feature站点上有不需要说，HTML/CSS这种标记语言/样式表在使用层面也没什么好讨论的，所以干脆列出自己常用的几个前端框架，算是做个阶段性总结。
本文的核心是侧重于HTML/CSS的框架，JS框架或以JS为核心的框架不讨论(比如YUI)；多屏已是既定事实，虽然不是所有开发都要考虑自适应，但有自适应功能至少说明了这框架短期内不会被淘汰，所以不带自适应功能的框架不讨论(比如flaminwork)；非开源、不可商用，或是需要付费的框架不讨论(比如easyframework)。
先说，这两年都在用它，如今Bootstrap有点烂大街了，难免有些审美疲劳。但想想在Bootstrap这种框架出现之前，程序员做的界面实在是惨不忍睹，如今至少升级成“还能看”的级别了，所以“泛滥”这个问题是瑕不掩瑜的。平时开发个小工具用它来做界面，写个底层脚本用它来做文档界面，工作环境中也可以用来做原型或是布局，谁都看得懂没什么学习成本。总体来说，这个框架对于互联网的美化实在是功不可没。
WP Cumulus Flash tag cloud by
9 or better.你的头 500 名用户怎么来？（转） - 简书
您还可以通过以下方式直接登录
你的头 500 名用户怎么来？（转）
比起其他忽悠文，我更喜欢这样实打实，每个步骤都明确的经验文。转自：V2EX卤主的网站刚刚要到500了，自我背景介绍：我们想为程序员兄弟做点事，先从程序员私活，远程自由工作做起---程序员客栈/。这接近500个用户怎么来的，卤主先自我剖析一下 ，因为马上500以上的用户增长就没有任何经验了，500之前还可以用笨办法，所以在这里抛砖引玉，真诚的求指导，希望大神分享一下:D首先前100个用户当然是非常痛苦了，邀请了一些朋友（十几个），他们基本不完善履历，确实难得填，我自己也不愿意填。楼主是v2ex 老用户，做的又是和程序员又关的事情，自然就想到了v2ex。所以在v2ex的求职，找到相关用户扒到邮箱地址，一个个给他们发邮件邀请（如下）。得到同意后帮他们注册好账号，完善履历。再把账号给他们。哈哈 就是这样笨办法，用户慢慢到了100 ，有没有你? XD
有个插曲，在用户快到100的时候，我在v2ex上面发了一篇帖子。“新开发了个程序员的社区 还差 7 个用户就破百了”/t/160039#reply53然后用户涨到了150人 嘿嘿突然意识到这个方法好啊，要写软文，于是我又发了2篇文章，里面适当提到了程序员客栈“Semanticui 确实是最好的前端框架。。。”/t/160712#reply49大概用户数就到200了“v2ex 用户增长历史轨迹，你是第几号会员”/t/161411#reply136这篇文章发过之后，卤主赚足了铜板，用户就蹭蹭蹭的到了300。当然仅仅这样就能涨几百用户就把事情想简单了。我还有相关的配合宣传做法。应该用户涨了100个。1. 邀请，邀请自己的朋友，一个个给他们说2. 把发v2ex帖子相同内容的，发到其他社区。3. 百度贴吧。“程序员吧”先发这样的帖子“ [福利] php全套经典视频教程 视频 + pdf书(英语) + 项目案例/p/”这样就保证不沉贴了。然后再给他们发邮件分享资料，里面就可以提到你的网站啦，这样。这个确实非常有效啊，孩子们是感激涕零“楼主好人 一生平安（听起来好奇怪，像发种子）”，我还发到了比较火的php吧 java吧，结果那边的管理员不允许，发了他们就删（没有公关），但还是收到了好多的邮箱回复。
通过以上的做法基本用户到了350再后来，通过v2ex我找到了我的运营合伙人 @greatdk。他把程序员客栈发到了36kr next，*创派，建立一些群之类的工作。用户就接近450 了。后面就看他的了 嘿嘿我确实非常想知道，v2ex的用户是怎么宣传的。通过一些挖坟，知道@Livid在06年都开始了v2ex的前身，07年在豆瓣推广，后面v2ex影响了一代程序员。如果能得到@Livid指导，那就太兴奋了。当然，知道v2ex大神很多，也希望你们能给指导。500以后的用户怎么增长，真的还是个大问题。。。求分享
打开微信“扫一扫”，打开网页后点击屏幕右上角分享按钮
作者的其他热门文章：
你可能会感兴趣：