明天早上关上github，发现尤大新开了个仓库叫 vue-lit，关上看了下，大略主体思维是用vue响应式外围去驱动lit-html的更新机制。

lit-html 是谷歌的一款 web-components的框架class base的api格调，不能说十分难用，实际上还是和当初支流的React hooks开发体验不可同日而语。在这里我要也吐槽下vue3的composition api，昨天我闲来无事看了下element-plus的源码，过后其实我是被雷到了的，咱们来看一段props的定义:

export default defineComponent({    name: 'ElDivider',    props: {        direction: {            type: String,            default: 'horizontal',            validator(val: string): boolean {            return ['horizontal', 'vertical'].indexOf(val) !== -1            },        },        contentPosition: {            type: String,            default: 'center',            validator(val: string): boolean {            return ['left', 'center', 'right'].indexOf(val) !== -1            },        },    },})

这。。。运行时的类型查看？typescript的动态类型查看他不香吗？几个单词就完事的货色要整下面这么一坨。。。而后就是各种 as看的我血压回升。好吧就算最初会用预编译把这些类型查看去掉，开发的时候写这些定义也不晓得会是什么感想，开发时的ts类型查看怎么办呢，代码提醒怎么办呢，我试了下最新版本的 vetur如同也全是 any提醒，如果有更新版当我没说，然而这相对不是一个很难受的写代码形式。

言归正传。

Web Components 是一个浏览器原生反对的组件化计划，，实际上它的组件就和原生的input之类的没啥区别，理论原生的包含 input的dom元素外部实现也是shadowdom，什么？你看不见，没事关上 f12，点击右上角的小齿轮，而后勾选 显示用户代理影子dom。(什么浏览器？当然是牛逼的edge`chrome`应该也在差不多的地位)

更多对于web-components的内容这里也不做过多赘述了，到处都有，总的来说，它能够让你写的组件真真正正是一个合乎web规范的运行时的组件，这很重要，有了规范什么事都好办。

再来谈谈Hooks。

其实大家当初都认可了React Hooks的开发体验，然而其实Hooks也有一些暗坑，也就是尤大始终说的心智累赘，然而总的来说这些累赘并不是 Hooks设计间接带来的，而是Immutable和闭包独特带来的。React 开发者都习惯了的闭包陷阱当初也是坑了我老半天。这个曾经被探讨烂了，就不多赘述了。而后社区就有两种人，一种说你们全副放redux啊，另一种说redux就是傻逼。然而其实都没有基本上解决问题。Immutable才是心智累赘最大的问题。

那么问题来了：为什么不把Hooks和Proxy一起用呢？一份高兴加上另一份高兴，而后再联合web-components去面向未来，那岂不是三份高兴？岂不美哉？

而后就有人通知我：行行行，这么高兴的事就交给你了。

实际上不必通知我，我早就开始实际了，文档都整的差不多了 Gallop。

废话不多说间接上代码。

// 这拉胯的网站怎么嵌入iframe...

Sandbox

import {    render,    html,    component,    useState,    useEffect,    useStyle,    css,    ReactiveElement} from "@gallop/gallop";component("sand-box", function (    this: ReactiveElement,    { color = "red" }: { color: string }) {    const [state] = useState({ tick: 0, text: "hello!" });    useEffect(() => {        console.log(`${this.localName}'s state tick was changed to ${state.tick}`);    }, [state.tick]);    useStyle(        () => css`        div {        color: ${state.tick % 2 ? "red" : "blue"};        }        `,        [state.tick, color]    );    return html`        <button @click="${() => state.tick++}">tick +1</button>        <div>${state.tick}</div>        <hr />        <input        @input="${(e: Event) => {        const { value } = e.target as HTMLInputElement;        state.text = value;        }}"        />        <div>${state.text}</div>    `;});render(html` <sand-box :color="blue"></sand-box> `);

那么这个叫Gallop玩意除了3份高兴之外，还有啥好玩的？

其实大部分在文档外面都曾经提及了，其实这个框架都不能算是一个框架，它只是从底层到顶层提供了一些api，让你本人去组合着玩，如果你只是写网页，那么你可能只会用到10来个，如果你想拓展它，那么你可能须要20来个，如果你想玩各种各样的骚操作，那么这些api也齐全能让你开发的难受又难受。另外，你其实就是在写原生的ts/Js，没有充斥魔法的预编译，没有那么多乌七八糟的调度机制，也没有太多诡异的模板语法，我置信根底扎实的你，只须要几小时就能搞定，如果你开发过React Hooks，那么我预计不须要10分钟。

目前Gallop曾经在笔者的公司外部开始解决一些业务组件上跨框架技术栈的问题，然而我还不能齐全保障bug free，然而开发效率是相对酸爽的，在这里也心愿有更多的bug 能在实际的磨难下可能浮现水面。

说了这么多，还是心愿web的将来会越来越不便，开发者们少掉点头发，少整点kpi，多干点有意思的事。

最初感激我的猫子们，陪本人写完这个"框架"。如果对Gallop感兴趣，也能够在 Github 上交换，欢送各种 Pr / Issue 或者对Gallop的扩大。