“没有框架就是最好的框架”是否适用于前端样式？

本人全干攻城狮，不追求优雅只追求快速实现目的（再不优雅也比写原生微信小程序优雅得多），我现在起新项目一律 uniapp ，基本没有楼主的烦恼，但是有另外的烦恼就是在 V2 会被某些人鄙视，这事儿见仁见智了。

@uqf0663 难道就没有 uniapp 实现起来很麻烦，或者 uniapp 根本不支持的吗？

你是否在寻找 tailwindcss ？

@kk2syc tailwindcss 与直接手撸的优势是？

@craftx 在其他 V2ER 看来坑非常多，但是我确实用了好几年了，写了几十个项目了，V2ER 们说的 uniapp 的坑确实一个都没碰到。主要还是得看熟悉程度吧，例如 weui 就没有 uniapp 的版本，如果你非要用 weui 的话得自己移植，如果你不熟的话，这个过程会非常痛苦，我第一个小程序也是原生的也是用的 weui ，当时就很执着移植这个事情，后来第二个项目开始我就换了有 uniapp 版本的其它 ui 就没啥问题了。

看需求和技术水平，选顺手的就行。
后端全手写 SQL 也没人拦着不是？

我的建议是少碰小程序，带上框架更是少碰，不管是 taro ，uniapp ，mpvue ，remax,mpx 我都用过，小程序更新框架就得跟上更新，只要不维护了就只能赌运气，如果实在要碰会写 react 就用 taro ，会写 vue 就写 mpx ，京东和滴滴的小程序看起来还是要一直维护的，但是也有前车之鉴的美团的 mpvue

tailwindcss 与直接手撸的优势

1. 写起来顺畅，样式直接写 class 里面。不用我滚到代码底部的 style 里面定义一个样式，又返回来继续写组件。相比于写 style 又简短很多

2. 有很多定义好的基本样式，例如边框、颜色。通过配置，我也可以定义喜欢的主题色

主要是这两个点

1. 用框架和库的目的是增效，如果你不需要增效那么就没必要用框架。你后面提到的 DOM 操作、数据映射、渲染更新这些操作就是在给你增效。

至于是否用 `uni-app` 之类的**跨平台框架**，就看你是否有跨平台的需求。如果没有，原生开发就可以了，会避免很多麻烦事。
比如说目标平台更新了，但是跨平台框架没有及时更新，但是这个期间你又要上新版本，那么你就得自己写一堆 `#ifdef` 去做判断。等到框架适配之后再改回来。
或者是一些小的编译导致的样式问题，Web 版本样式 OK ，但是小程序样式有问题。你调整之后小程序样式 OK 了，但因为一些 hack 写法，Web 端又有其他的问题了。


使用框架实现起来几乎不会有坑，只是一些非常细枝末节你用一份代码不做调整，想要一次性跑通的会比较折磨。

如果要考虑这种跨平台框架了，就直接看使用人数，而不是技术栈是不是“优雅”。
很多技术栈看起来非常好，但是用户群不大，叫好不叫座是非常常见的。更新慢或者 bug 修的满，等你想自己修复搜都搜不到相关的结果就懂了。
用的人越多等你踩到坑的时候，社区肯定已经有先行者淌过了，起码有一个思路指引。


2. 样式和 UI 库，也是一样的，如果你已经有一个自己的样式风格了。那么可以不用 UI 库，就自己实现。
远古时期每一个前端开发大多都有一个自己维护的 common.css ，然后自己手写项目样式。
对样式需求并不怎么高，那么就不需要考虑那么多，找一个组件清单能覆盖自己需求的 UI 组件库就好了。一般来说 UI 库都会提供一个定制化主题的指引，自己按照需求改一份出来就够用了。
对样式需求比较高，会有很多特立独行的定制化需求，可以找一个 headless 组件库。组件库只负责功能实现，样式靠自己来实现。但是小程序端我还没了解到过是否有类似的库。


-----
#4 ，使用 tailwindcss 比直接手撸的优势就是可以少写很多东西，可以不用自己定义类，快速实现栅格化布局等等的功能。
很多时候我们只是想使用 `flex` 布局，还得起一个 CSS 类名，然后到 `style` 块中去声明。使用 `tailwindcss` 就可以直接 `class="flex ..."` 这样了。
然后一些样式规范也可以一次声明，全局都可以使用到（可以理解成全局变量和样式继承）。

框架还是要的，反正我是不想写那么多 document.querySelector/addEventListener ，即便有 snippets ，看着也闹心。UI 倒是可以视情况，毕竟设计稿大概率不会跟框架来。

@uqf0663 要不试下来点刚需 DOM 操作的，例如画个图表，或者弄个虚拟 emoji 键盘？

@marcong95 这就 ETC 了，小程序本来就没有 DOM ，这个跟 uniapp 没有关系，同样的需求有的是变通的实现办法，例如你说的图表或者 emoji 键盘，抛开自己能手撸的不说，至少 uniapp 的插件市场随手一搜都能看到一大堆现成的实践。

你举这个 DOM 的例子就相当于你去到一个没有人说中文的地方，你既不学习当地语言也不愿意借助翻译 APP ，就一味的指责这个地方没人能交流一样。

@uqf0663 小程序没有 DOM ，但是也有 wx.createSelectorQuery()，而且你开什么项目一言不合直接拉一个 uniapp ，你连不需要小程序的项目也失去了直接操作 DOM 的能力。在我在做 uniapp 的那个时代，只要我想去碰 DOM 的时候，都会有大概率会掉入 uniapp 的无底深坑，社区搜索无有效结果，群上提问无人回复。我当年的需求也并不需要小程序，就想找个框架把 web 网页打包成 app ，视情况还需要手撸两段 Java 。

所以我得出了一个结论，只要需求超出小程序能力的，碰 uniapp 只会变得不幸。按你这个例子，uniapp 这个翻译，是到了当地把你嘴堵上，然后给你塞一个猫狗语音按钮，只能让它来说人话，即便你自己会那么两句当地语言。

至于商城插件，我刚才重新上去随便找了一个 emoji 虚拟键盘，反正搜索结果的第一个是不能用的。

vue+unocss + 一套 ui 库搞定, 前端路过

@marcong95 因为 ETC ，你存在两个误区
第一、楼主的需求就是原来有小程序版现在需要增加一个 H5 的版本，如果他一开始就是用 uniapp 那么就不用发这个贴子，直接打包 H5 版本就行。
第二、uniapp 本就是以 vue 为基础的，既是基于 vue ，vue 本身也是不鼓励直接操作 dom 的，你非要纠结 dom 是你的问题，菜就多学习，实在不行就跟我一样多变通，而不是一直 ETC 。

@uqf0663
1. 如果他一开始用 uniapp ，楼主发的可能就是 uniapp 如何实现某某功能的帖子了吗？古人云：软件工程没有银弹。
2. 这年头正常人都不会鼓励你直接操作 DOM ，需求复杂了之后总归是躲不开的。菜就多学习我同意，所以我选择学习各种乱七八糟的原生实现，而不是守着 uniapp 这一亩三分地内变出花来。

各位写前端样式真的不用框架吗？那些配色啊，效果之间的搭配纯手写很难的吧。

关于 1 、js 是逃不掉一个框架或者 js 库的，
同样一个工件，可以根据传统车床编制一套加工流程，也可以根据数控机床编写一个加工程序，我选后者，毕竟后者可以把程序拷到别的机床上面分享，或者改一改可以适应新的工件加工，效率更高，复用更方便不是吗

关于 2 、样式框架和 ui 组件库，
如果有美工出图就照出图做，有视觉规范就照视觉规范做，都没有就用好用对 ui 组件库吧，最起码别人有一个统一合格的视觉规范（比方说，OP 你的小程序里面有个别字体太小啦）