场景 曾经吾辈以为 ES6 早已推广开来，然而事实上远比想象中更加复杂。传统后台的项目就是要兼容性，兼容 2 年前的浏览器，没有 babel，全程 jQuery 一把梭做到底。 之前的项目基本上都是前后端分离的模式，最近新公司的项目却是使用的传统的模板视图的模式。所以，一些东西发生了变化 thymeleaf 模板里面直接有 Java 的代码，在服务端直接编译 html 代码而非是纯粹的 API

场景长期以来，吾辈通过 RSS 阅读各种 blog，想要评论时却发现很麻烦，所以来推荐一下 blog 的评论系统。 评论系统大概有如下几种形式 基于第三方评论服务 输入名字邮箱即可发表评论 注入博客用户才可以发布评论（没怎么用过，不予置评） 优缺点对比基于第三方评论服务这里选择的是吾辈目前正在使用的 disqus，而评论选择是某位博主的评论系统。 两者截图如下 对比项 基于第三方评论服

前言在 基本项目搭建 中，我们已经能够启动一个 electron 应用程序了（开发环境），现在来看如何将之打包为二进制程序便于分发给最终用户。 依赖 electron-builder: 打包的主要工具库，负责这个 electron 的跨平台打包工作 事实上，还有一些其它的打包工具，但目前还没有比它更好的，参考: https://npmcompare.com/compare/electron-bui

环境 Windows 10 NodeJS 12 WebStorm VSCode（编写 markdown 文档） 创建 lerna 项目创建目录 electron_example，然后使用 yarn 初始化 12mkdir electron_example && cd electron_exampleyarn init -y 修改 package.json 123456789{

使用 react devtool 插件调试 前言 虽然绝大多数时候，我们都可以也应该在浏览器调试渲染层的功能，但确实也会有需要在 electron 程序中调试的需求，这里就说明一下 electron 如何安装 chrome 插件 react devtool 调试项目。 核心依赖: electron-devtools-installer 步骤 1、安装依赖 cd 到 apps/main 目录

场景在很多生产项目中，我们希望自定义 electron 窗口顶栏，因为它确实非常简陋。 步骤在渲染层实现自定义顶栏实际上，核心的代码就是添加一个为顶栏的元素添加 css 样式。在 electron 环境，有 -webkit-app-region: drag; 属性的元素可以拖动整个窗口。 123456.toolbar { -webkit-app-region: drag;}.toolbar &g

场景由于生产应用希望在有新版本时，自动为用户推送更新，所以此处便写一下如何让 electron 程序自动更新。 安装 npm 包1cd apps/main/ && yarn add electron-updater 配置 electron-builder 参考: https://www.electron.build/auto-update 其实本质上就是配置一个网络可以访问到的

前言 吾辈就是一个从 Java Web 后端转到前端的人。 吾辈今天又在看到人说 前端很简单，而且还比后端工资高，这里吾辈还是想做一些澄清的。 对话 后端 A: 我发现这两年前端的工作特别好找，而且工资很高 后端 A：后端内卷太严重了。 后端 B: #无语 后端 B: 前端要会啥啊到底才能称得上前端 后端 A: 我们这边。H5+小程序 就行了 后端 A: 主要是 CSS 要能处理好。。。 后端

简介前些时日，吾辈读完了 [浪潮之巅] 这本书。 它是 Google 开发者吴军所写的 IT 行业各个重要公司的兴衰历史，并进一步探讨了其中的原因。那些曾经无比耀眼的新星，压在每个公司头上的庞然大物，是如何一步步变成这样的。 起因最初是在一位朋友的推荐下了解到这本书的，当然，那位推荐了不少有趣的书籍: 黑客与画家、浪潮之巅、人月神话等。 感想 书中最有趣的一个观点是: 公司是由基因决定的，转基因

场景在生产中遇到的一个 css 问题，css 不正交的问题一直有人吐槽，吾辈今天总算也是遇到了，实在是不吐不快。 CSS 为什么这么难学？ 如下一个简单的二维横向图片列表 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455<style&g

xstate.js 官网, 中文（繁体）教程参考 场景 为什么要引入状态机？ 吾辈希望使用有限状态机管理程序中的状态及状态的流转，以避免使用各种 flag + if/else 控制程序的运行。 为什么吾辈会突然觉得 flag + if/else 这种方式不好呢？ 原因在于吾辈最近在看设计模式相关的书籍：JavaScript 设计模式与开发实践，其中涉及到了[状态模式]，里面就提到了[有限状态机

场景EventEmitter 很适合在不修改组件状态结构的情况下进行组件通信，然而它的生命周期不受 react 管理，需要手动添加/清理监听事件很麻烦。而且，如果一个 EventEmitter 没有使用就被初始化也会有点麻烦。 目的所以使用 react context 结合 event emitter 的目的便是 添加高阶组件，通过 react context 为所有子组件注入 em 对象 添加