现在前端流行的开源免费框架靠什么来盈利？

1、象大名鼎鼎的华人前端巨著vue框架的作者每年会获得不少捐赠，这些捐赠者中还包含巨头阿里，这些捐赠可以让vue作者全职潜心allinone地迭代vue、发展vue生态。

2、谷歌的跨平台框架flutter出来之后在业界里面引起了广泛的反响，凝聚了一大批的拥趸，对这些不大缺钱的巨头来说这种品牌的影响力、感召力就是价值啊，几乎所有的互联网巨头都或多或少会去开源，你看看BAT、京东美团哪个没有？他们都是这样考虑的。

3、开源社区版让大家了解使用框架的基础功能，但是把盈利点设置在增值服务上，社区版本可以引流，增值服务可以变现。这是开源非常常见的玩法。最近国产有个做物联网数据库的T某某数据库开源，他们开源了单机版本的，但是分布式版本是收费的。

4、开源非常繁荣，建议题主多去github上去多感受下浓烈的开源氛围。

我是全栈工程师，从前端通到后端到数据库，从企业级通到云通到移动端

有问题可以私信我沟通！

新版 uni-app 框架主要做了三大改进：
重写框架内核：基于vue3 + ts重写内置组件和API，实现更彻底、更高效的tree-shaking；
新增支持 Vite 构建工具，在H5平台实现秒开预览；
新增支持 Vue3x，实现更灵活的开发方式，及更高的运行性能；
基于这三大改进，uni-app项目获得了多快好省四大收益：
更多的语法支持，支持组合式API，业务聚焦，开发效率更高；
更快的编译速度，H5平台十倍加速，小程序、App加速30%以上；
更好的运行性能，用户端响应更快，体验更好；
更小的代码体积，瘦身30%以上，更省体积、更省流量
更多的语法支持
新版uni-app支持Vue 3x框架，支持组合式API，可实现更聚焦的业务开发。
Vue 3x的一些新增特性，uni-app也已经完全支持，如：
支持<script setup>
支持<style scoped>、<style module>、State-Driven Dynamic CSS(v-bind)
支持jsx、tsx（h5,app 平台支持，小程序不支持）
另外，在小程序平台，新版uni-app也扩展了更多的语法，如：
更完善的模板语法支持（如 class、style 支持函数、变量等，不再局限数组、对象类型）
更完整的 props 支持（如传递函数）
更完善的 slot 支持（如作用域插槽）
更快的编译速度
开发者日常工作中，最无聊的就是等待编译构建。
某乎上还有一个”程序员在等待编译的时候都做什么？“的讨论帖，可见编译时间对开发者而言，是一个多么尴尬无聊的碎片时间。
uni-app本次升级vue3 & Vite后，在编译时间上有多少改进？带给开发者多少福利？我们安排真实测试，以数据说话。
测试环境说明：
硬件：RedmiBook 14 二代
处理器：Intel(R) Core(TM) i7-1065G7 CPU @ 130GHz
内存：160 GB
*** 作系统：Windows 11 专业版 64 位 *** 作系统
关于编译速度，我们做了两个维度的对比：
纵向对比：挑选uni-app常用项目模板，在H5、小程序、App平台，分别测试vue 26和vue 3x的编译时间
横向对比：使用业内优秀的其它跨端框架，创建默认项目模板，记录其编译时间，和uni-app的vue 3x版本进行对比
uni-app 历史版本纵向对比
我们选择uni-app默认模板、uni-starter、hello-uniapp三个项目模板，分别测试vue 26和vue 3x的编译时间。
uni-app项目编译时间的采集方式：
vue 26版本编译时间 = webpack 的 statsendTime - statsstartTime
vue 3x版本编译时间 = 构建工具入口处记录 globalvite_start_time = performancenow()，构建工具编译完成时：performancenow() - globalvite_start_time
H5平台
对uni-app的三个项目模板分别运行到H5平台，进行多次编译测试，并求其均值后，获得如下数据：

由此，我们可以观察到：
在vue 26环境下，随着项目复杂度的提升，H5首页预览所需编译时间会直线增加；这是因为在vue 26版本下，虽然仅预览首页，但依然会使用 webpack 编译整个项目资源；故项目越复杂，编译时间越长；
在vue 3x环境下，H5首页预览的编译时间跟项目复杂度也有关系，但增幅不大；这是因为在vue 3x版本下，使用 Vite 进行构建，预览首页时仅编译首页及首页所依赖资源，不会编译其它页面资源。
通过图表对比，我们可以直观得出结论：vue 3x环境下的首页编译时间，平均不到vue 26环境下的十分之一。
换言之，vue 3x版本下的首页编译速度，相比vue 26版本，有十倍效率提升。
这个十倍效率提升，主要得益于新版采用Vite作为构建工具，由此带来了两大好处：
使用原生 ESM 文件，无需打包，实现极速的服务启动；
预览（运行）使用esbuild作为打包工具，相比vue 26环境下的webpack，构建速度快 10-100 倍（这不是我们夸大，详见esbuild）
本着这个十倍效率提升，小伙伴们还不赶紧上手试试？
小程序平台
对uni-app的三个模板项目运行到小程序平台，多次编译测试，并求其均值后，获得如下数据：

从上图对比数据来看，我们可以得出结论：小程序平台，vue 3x版本下的运行编译，相比vue 26版本，编译性能至少提升30%；且项目越复杂，编译性能提升越明显，可以达到40% ~ 50%。
App平台
对uni-app的三个项目模板继续运行到App平台，多次编译测试，并求其均值后，获得如下数据：

从上图对比数据来看，我们可以得出结论：App平台，vue 3x版本下的运行编译，相比vue 26版本，编译性能提升将近50%。
虽没有H5平台的十倍效率提升那么刺激，但将近50%的速度提升，经常开发小程序/App的小伙伴，还不心动？
业内优秀框架横向对比
除了采用不同版本的uni-app进行纵向对比外，我们还使用业内优秀的跨端框架Taro，创建空的项目模板，进行横向对比测试。
具体测试方案：
安装Taro的最新cli，本文测试时使用的版本为"@Tarojs/Taro": "3316"
使用Taro init命令，分别选择react、vue、vue3框架，创建三个默认项目模板，三个项目名称分别为taro3-react、taro3-vue、taro3-vue3，如下图：

使用npm run dev:h5，运行到H5平台进行预览，记录每次预览编译时间，重复执行，求其均值
关于Taro编译时间的计算方案：
开发一个Taro扩展插件，插件规范参考Taro官网 - 插件功能
在ctxonBuildStart中记录开始编译时间
在ctxonBuildFinish中记录编译结束时间
两者的时间差，即为编译过程消耗时间
然后使用uni-app的cli命令行，创建基于vue3x的空项目模板，项目命名为uni-app-vue3。
我们使用各自框架的命令行，将如上创建的5个项目分别编译到H5平台和小程序平台，多次测试，并求其均值。
同框架版本在H5平台上的编译时间，结果如下：

从图中可以看出，uni-app的vue3版本，在H5平台上的首页编译预览性能是遥遥领先的。这个遥遥有多远呢？这么讲吧，你都编译20次了，友商第一次还没完呢。
继续编译到小程序平台，多次测试，求其均值，结果如下：

从图中可以看出，uni-app的vue3版本，在小程序平台上的编译性能也是遥遥领先的，这个遥遥也不近。
更好的运行速度
开发环节编译快了，那面向最终用户的软件，运行性能怎么样？
我们进入性能测试章节。
测试方案：
开发内容：开发一个仿微博小程序首页的复杂长列表，支持下拉刷新、上拉翻页、点赞。
界面如下：

测试机型：小米 Mi 10 pro、MIUI 125 (21113 开发版) 、微信版本 8016
准备工作：每次开始测试前，杀掉各App进程、清空内存，保证测试机环境基本一致；每次从本地读取静态数据，屏蔽网络差异。
评测点：长列表中的某个组件，比如点赞组件，点击时是否能及时的修改未赞和已赞状态？
测试计时方式：
选中某微博，点击“点赞”按钮，实现点赞状态状态切换（已赞高亮、未赞灰色），
点赞按钮 onclick函数开头开始计时，setData回调函数开头结束计时；
在小米手机上进行多次测试，求其平均值，结果如下：
记录条数 200 400 600 800 1000
vue2 30ms 43ms 56ms 72ms 90ms
vue3 8ms 9ms 9ms 8ms 9ms
从表格中可以看出：
随着页面记录的增加，vue 26版本的uni-app项目，点赞组件响应时间快速增加，响应越来越慢；
基于vue 3x的uni-app项目，点赞组件的响应时间跟页面条数无关，一直保持极高的响应灵敏度，性能体验远高于vue 26版本。
从这个常见的长列表组件响应实验来看，vue 3x的性能体验要远高于vue 26版本。
更小的代码体积
项目发行后的代码体积，是一个很重要的考量指标：
H5平台：更小的代码体积，可以帮助开发者节省服务端带宽及CDN流量，可实现更快的资源加载及页面渲染；
小程序平台：更小的代码体积，可加速小程序包的下载（甚至可能免了分包加载的繁琐），帮助用户更快进入小程序业务界面；
App平台：更小的代码体积，可实现更快的App启动，帮助用户更快进入App首页
为了测试vue 3x新版升级后，代码体积的变化，我们同样做了两个维度的测试：
纵向对比：选择uni-app常用项目模板，在H5、小程序、App平台，分别测试vue 26和vue 3x的编译包大小
横向对比：使用业内优秀的其它跨端框架，创建默认项目模板，记录其编译后的包体积大小，和uni-app版本进行对比
Tips：
开发阶段重在编译速度，对应npm run dev *** 作
发行阶段重在编译包大小，对应npm run build *** 作
uni-app 不同版本纵向对比
我们复用之前创建的uni-app默认模板、uni-starter、hello-uniapp三个项目模板，分别测试vue 26和vue 3x的编译包体积。
uni-app项目编译包体积的采集方式：编译到对应平台后，记录编译后文件夹的大小。
H5平台
H5平台编译后代码体积记录如下：

从统计结果来看，uni-app的vue3x版本，在H5平台上的编译包体积至少瘦身30%以上。
H5平台的瘦身优化，主要得益于uni-app框架的底层全面重构，实现了更彻底的摇树优化。
小程序平台
小程序平台编译后代码体积记录如下：

从统计结果来看，uni-app的vue3x版本，在小程序平台上也有大幅瘦身。

因为某个bug 以为 是 el-tabs 组件的问题，所以想直接仿造一个，结果发现 是其他问题，想想下次哪天会用到 就奉上这段样式

这是用VUE写的。看得懂的 用 JQ 写其实逻辑都一样 没区别！

HTML：

<div class="tabsMain">

                    <ul class="tabsList">

                        <li :class="activeName==itemcode'active':''" v-for="(item,index) of tabList" :key="index" @click="handleClick(item,index)">{{itemname}}</li>

                    </ul>

                    <div v-if="activeName == 'tab-1'"></div> //本来想直接用 index 判断的 结果还是直接 仿造el-tabs的方式做吧

                    <div v-if="activeName == 'tab-2'"></div>

                    <div v-if="activeName == 'tab-3'"></div>

</div>

CSS：

tabsMain{

    border: 1px solid #dcdfe6;

    box-shadow: 0 2px 4px 0 rgba(0,0,0,12), 0 0 6px 0 rgba(0,0,0,04);

    margin: 0;

}

tabsMain > div{

    padding: 10px;

}

tabsList{

    width: 100%;

    background: #f5f7fa;

    overflow: hidden;

}

tabsList li{

    float: left;

    padding: 0 20px;

    height: 40px;

    box-sizing: border-box;

    line-height: 40px;

    list-style: none;

    font-size: 14px;

    font-weight: 500;

    color: #303133;

    transition: all 3s cubic-bezier(645,045,355,1);

    border: 1px solid transparent;

    margin-bottom: -1px;

    cursor: pointer;

}

tabsList liactive{

    color: #409eff;

    background-color: #fff;

    border-right-color: #dcdfe6;

    border-left-color: #dcdfe6;

    white-space: nowrap;

    position: relative;

    transition: transform 3s;

    z-index: 2;

}

tabsList li:first-child{

    margin-left: -1px;

}

tabsList li:last-child{

    margin-right: -1px;

} 

data(){

return:{

activeName:'tab-1',

tabList:[

     {code:'tab-1',name:'标签-1'},

     {code:'tab- 2,name:'标签-2'},

     {code:'tab-3,name:'标签-3'}

]

}

},

methods:{

handleClick(item){

    thisactiveName = itemcode

}

}

最后结果：图

写仿豆瓣的时候经常会遇到一个点赞的按钮，点一下赞了 它的样式也改变了，然后再点一下还可以取消。于是打算封装一个点赞的组件
刚开始封装的时候将每次点赞和取消点赞的这个逻辑写到了组件内部，后来再看感觉很不合理，所以重新重构了一下。

template：

<div id="like" :class="like'active':''" @click="change">

<span class="img"></span><span>{{count}}</span>

</div>

img是显示的小心心的点赞图标，后面是点赞数量，因为想到有些点赞按钮可能没有数量，所以count设置为非必填项。

style：

#like{

width: 100px;

height: 30px;

line-height: 30px;

display: flex;

align-items:center;

justify-content:center;

font-size: 15px;

margin: 30px auto;

color: #42bd56;

border: 1px solid #42bd56;

}

#like img{

margin-right: 4px;

width: 20px;

height: 20px;

background:url(>