自我、价值、未来与LuLu UI

我经常会思考这样一个问题，宇宙之大，生命之少，我们每个人能够出现在这个世界上都是一个奇迹。如果每一天我们都是做些重复的事情，没有做有挑战的事情，没有做打破常规的事情，没有做引领方向的事情，赋予我们的奇迹岂不是一种莫大的浪费？二、一叶蔽目不见泰山人的认知和决策非常容易收到接触到的信息影响。世界是巨大的，行业是广阔的，但是在前端行业说话的那些人是只是其中的一小部分。这些有话语权的人多大厂背景，多人团队，上层框架，体系工程化。然而实际上在整个行业，大多数公司前端开发人员就1～2个人，大多数公司前端开发项目都非常都简单，还有很多公司给政府机构做项目，甚至需要兼容IE8浏览器。于是多少这样都公司在技术选型的时候被所谓的流行、热门所误导。留下一个又一个烂摊子。这些看似群体的思想其实仅仅是部分上层群体的思想。《乌合之众》这本书有言，个人一旦融入群体，他的个性变会被湮没，群体思考开始占据绝对统治地位。我们应该有着自己的个性，有着自己的坚持。但是，不幸的是，大多数的人缺乏坚定的自我而被群体淹没。其实呢，很多人的内心都是希望可以告别每天做重复的事情，去做有挑战的事情，去做打破常规的事情，去做引领方向的事情！但是，放到现实世界，却不知不觉将自己封闭在狭隘的日常工作中，为了认同与安全感追随群体意识，随波逐流。成为了乌合之众，平庸之辈。所以，最重要的是，如何在浮躁喧嚣环境中保持坚定的自我，保持自己的个性与特质，不要受群体影响而改变自己的行为与判断。我是如何保持自我的？对于我而言，是通过哲学思想的指引，来远离各种诱惑。下面这句话说得非常好！“如果一个哲学思想可以历经数千年不衰，那一定是千千万万人验证过的真理！”我们只需要借鉴古人千百年来流传下来的智慧知道我们的工作与生活，自然就能穿过起起伏伏的人生中，穿过复杂纷扰的世界中，达到自己想要的对岸。而我就是一个坚定的道家思想主义者。道家思想两个非常核心的点是：“追本溯源”和“无为而治”。无论是处事，无论是做人，无论是生活，还是工作，以及包括技术学习与认知，我都是遵循这样的思想进行实践的。例如：饮食：清淡，追逐食材原本的味道，而不是调味品的刺激；学习：思考技术的本质，学习底层的API，关注细节。技术：反对大而全，反对过度包装，追求，简单，原始，与灵活。React、Vue以及所谓工程化的问题回到主题本身，业界目前关注较多的React、Vue以及所谓工程化是有着自己的问题的。主要两方面：自己的认识认为是整个行业的认识不知道大家听过船夫和他的孩子的故事没有，故事是这样的：大寒天，船夫出外划船，他把自己的孩子也带去。船夫用力划了一程，觉得身体很热，便脱去了外衣，只穿一件单衣。他跑进船舱，对自己的孩子说：“太热了，让我替你把外衣脱掉！”他把孩子的外衣脱了，也只让他穿一件单衣。船夫又划了一程，浑身热得淌汗，他索性把自己仅穿的一件单衣也脱掉了。“呵，太热了！太热了！”他又走进船舱，把孩子的衣服也脱得精光。船夫划得多有劲呀，身上冒着热气，淌着汗。然而他可怜的孩子，在船舱里已经冻僵了。React、Vue以及所谓工程化也是同样的问题，上层那些人的需求被认为是整个行业的需求，殊不知下面的人早就被他们搞得瑟瑟发抖。无法穿越历史的长河，从业者本身也并没有本质提升纵观自然历史长河，那些复杂高等的顶级生物总是一波一波的淘汰，唯独简单的生命穿越亿万年历史长河而不衰。这样的世间真理对技术同样适用，越简单越基础的技术生命力越强，越能穿越历史长河。React、Vue这些上层事物，5年之后，衰落已是必然。另外一个问题就是“天赋陷阱”，美貌是一种天赋，同样也是一个陷阱，带来了很多便利，而忽视了对内在的关注与成长，未来幸福的概率反而没有美貌一般的高；身体素质很好也是一种天赋，往往可以带来很多优势，但也会造成忽视技术和意识的培养，最终成就也就那样；同样的，React、Vue确实给开发带来了便利，牺牲性能换来开发便利，但也造成忽视技术的基础和细节的学习，一旦时过境迁，这些框架不再流行，你会发现自己的竞争力已经没有了。这就是目前行业的问题，当然，有问题也就意味着机遇，可以做一些对行业有帮助有价值的事情。关键如何做呢？最好既满足自身成长诉求，也能给行业带来一点不一样的东西！不妨一起加入LuLu UI Pure主题的支持与建设！三、LuLu UI Pure主题LuLu UI Pure主题是LuLu UI组件库最新的开发的，传承LuLu UI组件体系一贯的设计理念，遵循“追本溯源”和“无为而治”的道家思想，基于Native原生JavaScript开发，柔软、灵活且自由的新主题。在展开介绍LuLu UI Pure主题之前，我们先来了解下LuLu UI的设计理念。四、LuLu UI的设计理念LuLu UI有两大设计理念，分别是：面向设计开发基于HTML开发设计理念：面向设计开发问大家一个问题，“设计师”，“前端设计”和“前端开发”这三个角色哪个角色开发UI组件更合适？答案是“前端设计”，因为既有UI敏感度，又懂代码开发。然而行业的现状却不是这样，中国的前端设计JS驾驭普遍较弱，虽然有设计敏感度，但是代码功力实在是弱，于是，最后UI组件都是前端开发这个角色实现的。然而前端开发这样的角色开发UI组件是有问题的，我总结了下面3个问题：HTML/CSS积累弱，实现啰嗦；扬JS对长，避HTML的短，挖巨大的坑；抽象与封装的意识侵入太深；我们一个一个来看下。首先HTML和CSS积累这块，我们看一个例子：某UI组件库的Autocomplete下拉组件的实现，在文本框外面包裹了一层

标签，设置position为relative，, 然后Autocomplete主列表容器就在这个包裹

里面，绝对定位于该

，通过left/top值与文本框尺寸关联。这是个糟糕的设计。小隐患是，由于改变了DOM层级深度，很有可能会导致相邻父子选择器会失效。超级大隐患是，外层overflow:hidden会截断下拉列表的显示，这个是非常容易出现的场景。实际上，有更好的实现，无需包裹一层

，直接跟随在输入框后面就可以了，自适应，不影响层级，也不会受外层overflow:hidden影响。但是前端开发肯定不知道有这样的实现，因为对CSS和HTML的积累弱。其次，由于HTML/CSS不太溜，JS比较溜，因此写的组件重JS，轻HTML，导致出现臭皮匠一样的组件代码，例如某组件框架的单选框模拟实现。可以看到，模板走JS API，所有的单选框状态全部走JS API，一切都是JS，然后这个这个名为iRadio的组件600多行JS代码，我勒个擦，600多行啊，恕我愚钝，这洋洋洒洒600+行的JS代码的价值在哪里？虽然这个组件也能用，功能也OK，但是……算了，平复下心情…………。最后一点，也是最重要的一点，那就是前端开发人员的抽象与封装的意识侵入太深。很多开发人员会不理解，组件难道不是抽象越好封装越好就代表质量越高吗？这是个错误的认知！如果我们是开发纯语言的JavaScript框架，那确实是需要高度抽象与封装。但是我们这里开发的是UI组件诶，UI组件，看好了，是UI组件，有UI两个字，不是纯语言的，是与视觉和体验打交道的组件。我们开看一看一些前辈的言论吧：UI逻辑很难抽象，一旦抽象就意味着死去这是玉伯的言论。并不难理解，如果有组件自信对UI层进行了完美地抽象与封装，这表明，这个组件已经对UI层的表现有了很大的限制。这是毋庸置疑的，有些事物本身就是对立的矛盾体，工程化就是要讲求一致性，但是，UI表现讲求个性化，两者本质就是矛盾，不可调和的。这就是很多前端开发人员的局限，没有意识到UI框架和逻辑框架的本质差异，仍在追求整站复用、封装良好、API丰富。一句话：UI框架妄图涵盖所有场景，想要大而全，那是死路一条。Steve Jobs有句名言：do not according to user bad habits to design， also do not according to programmers thinking design！中文意思是“不要按照用户的坏习惯去设计，也不要按照程序员的思维去设计！”因为程序员的思维是工程化，系统化，开发便捷，这样的思维适合开发内部产品，做内部产品，功能最重要，UI很次要，看得过去就可以。但是，对于to C的外部产品，程序员这种思维就很有问题了。问大家一个问题，对于to C的产品，产品的体验和品质和开发人员开发便捷哪个更重要？对吧，很显然，产品的体验和品质是更重要！此时，程序员思维就会影响产品品质，因为一个气质明显，高端大气上档次的产品，定制化的UI和设计是免不了的。当然，实际开发，开发也会尽量按照产品和设计的需求实现最终的效果，只不过这个实现的方式是在原来又大又笨的组件基础上二次封装。天呐，组件本来就很大的，还要再封装，最终组件就会变得很笨重，而且还不能覆盖所有的设计场景，最后反而是让设计师调整设计以便适应组件当前固定的功能。天哪，本末倒置，对外的产品开发，怎么能因为组件的设计糟糕而继续让产品设计再变得平庸呢！LuLu UI则不一样，立足于to C产品，贯彻面向设计的开发理念，于是最终的形态和传统的UI组件有很多不同之处，包括：去API，模块低耦合，层级扁平，适当冗余；没有版本的概念，一条核心持续往前迭代；根植于项目，任何UI变动修改组件本身，包括JS；1. 没有版本概念传统UI组件都有1.0，2.0版本之类概念，LuLu UI没有，LuLu UI就是一个核心，自顾自往前走，只有主题概念，没有版本。当某个项目需要使用的时候，直接拷贝到项目中，和整个项目融为一体，从此和LuLu UI没有任何关系，走小鸡孵化模式，一旦出壳就可以自力更生。图示如下：由于UI层是多变的，不可控的，因此，当我们UI需要根据项目实际设计进行调整的时候，请直接修改项目中LuLu UI的CSS和JS代码！2. 根植于项目UI组件的修改一定要根植于项目，而不是重置或者二次封装，这很重要，我们是UI框架，跟着项目走，设计驱动组件，而不是组件限制设计。由于我们直接修改LuLu UI中的源码，因此，什么样的设计都能够驾驭。修改原始组件？很多人觉得不可思议。大家一定要扭转意识，对外的产品，要想品质出众，定制化的处理是必不可少的，就像私人定制的礼服，一定一不开工匠的手工制作。这个和中后台项目开发不一样！用图示意就是下面这样（可以对比上面的二次封装图）：同样是定制，不同在于一个二次封装，一个是原始改造，既然走原始改造策略，那我们的UI组件就可以不用大而全，不会因为要应付各种场景变得日趋臃肿，一致保持简洁，这是LuLu UI优势以及长盛之道。很多人担心修改JS驾驭不来，根据我们几十个项目的实践经验，大多数场景下，是不需要对JS进行调整的，因此，不用担心。设计理念：基于HTML开发基于HTML开发的思想符合道家的追本溯源，无为而治。我们先看一个LuLu UI下的demo：基于原生的HTML UI组件体验demo一开始进去就是一个浏览器原生UI表单，如下作图所示，title提示，日期选择，表单验证等，都是粗糙的原生的UI。此时，我们点击下提交按钮，此时会加载LuLu UI的CSS和JS，结果神奇的事情发生了，UI全部变成了LuLu UI的模样，都变漂亮了。左边是原生HTML行为，右侧是LuLu UI实现的效果。更神奇的是，我们仅仅是引入了LULU UI组件的一点CSS和JS，没有动之前一点点一丝丝的业务JS. 但是，之前的各种交互功能，却完全不受影响。如下GIF：这就是基于HTML开发的理念，基于原生HTML，专注于UI表现，让UI组件回归了其本质或者说本职作用——UI！基于HTML开发更多优点语义化，可访问性，SEO等；学习成本低，API源自标准规范；前端分离——专注HTML控件本身，而不是组件；四、再次说说LuLu UI的Pure主题LuLu UI目前四大主题：modern：IE7+，依赖jQuery，生于2015年，停止维护peak：IE8+，依赖jQuery，PC，生于2016年，开源中pure：IE9+，原生JS，支持移动，生于2019年，开源中lead：Chrome+，原生JS，支持移动，内部开发中…其中Pure主题是当前LuLu UI组件库的主力，已经开源，相比之前主题进步在于：Native JS开发，性能升级；支持Vue和React项目组件引入，应用场景进一步扩大；支持属性检测，UI层自动更新，可以更加专注业务逻辑；全矢量资源，0资源外链，加载性能大幅提升；键盘和屏幕阅读无障碍访问有所提高；基于过往的经验，优化大量内部逻辑，使API更易用；API与语言风格完全统一，更加适合新人学习；文档升级，更加规范更加详细；Pure主题的当前阶段LuLu UI Pure主题目前已经开源：github.com/yued-fe/lul…官方地址：l-ui.comPure主题虽然开源，虽然站在了Peak主题的肩膀上，虽然内部经过了多轮系统的测试，但是一定还有很多不完美的地方，所谓实践方能出真知，希望可以有更多的人一起参与LuLu UI Pure主题的建设，这也是我写这篇文章的初衷。参与的方式有很多，可以Star一下表示你的爱，可以在项目中试用并反馈遇到的问题，可以直接参与代码建设优化内部的实现逻辑等。宇宙之大，生命之少，想想看人生的价值与意义，是巨大的奇迹还是巨大的浪费？我们是不是应该：做一件遵循内心，与众不同的事情；做一件对团队，对行业有意义的事情；和LuLU UI一起，穿越喧嚣浮躁，站在未来之路上；