前端工程化

在现代前端开发中，polyfill是确保代码在不同浏览器中兼容性的重要手段。传统的polyfill解决方案通常是在构建时解析JavaScript代码，通过检测特定方法调用来决定引入哪些polyfill

各位网友晚上好，相信大家都知道字体图标。字体图标虽然有轻量、矢量、易调整、兼容性好等优点，但有一个重大缺陷就是维护比较麻烦。在过去我们在维护图标库时，往往需要专业的字体制作人员，制作出字体图标库后再给

什么是 npm 仓库私有化？ npm 仓库私有化又叫 "npm 私服"、"npm 私有仓库"、"npm 内网仓库"、"npm 内网镜像"。其核心在于在内网环境搭建一个类似 https://regist

很多人会把Browserslist中的and、or、not理解为集合运算中的交集、并集、绝对补集，这是错误的。 Browserslist的语句分为查询语句和排除语句，not表示这是一个排除语句。 排除

各位网友晚上好，相信大家都对使用type="module"和nomodule这种技巧有所耳闻。今天我将为大家分享我把这种技巧应用到极致的经验：4 条件加载方案。 什么是分条件加载 在前端构建中，我们通

「不处理浏览器兼容性」不是逃避问题，而是通过架构设计将复杂度隐藏在幕后。毕竟，最好的兼容性处理方式，是让开发者忘记「兼容性」的存在。

当你在 Sass 中写下这样的代码时： 你以为这是标准语法？真相可能会让你惊讶——Sass 官方编译器从不支持波浪符 ~ 开头的路径解析！ 问题根源：~ 是社区约定而非官方标准 这个看似普遍的语法实质

一、当滤镜遇上浏览器战争：开发者之痛 在实现设计稿中的模糊效果时，我们兴奋地写下： 却在测试时发现： iOS 8.1 设备上效果消失 IE浏览器直接罢工 旧版Firefox显示异常 于是不得不改写成：

在 JavaScript 中，正则表达式是一种强大的工具，用于处理字符串匹配、搜索和替换等操作。然而，当涉及到匹配任意字符（包括换行符）时，开发者可能会遇到一些问题。本文将介绍两种常用的正则表达式模式

Vue3 怎么可能能兼容 IE 呢？我一开始也是这么想的，但是看到运行结果的那一刻，我震惊了。我们先从理论上分析一下兼容 IE 的可行性。很多人都认为 Vue3 兼容不了 IE 的原因在于 Proxy

各位网友大家好，构建性能优化是前端性能优化的常见手段。由于构建可以和业务脱离关系，可以在不改业务代码情况下进行优化，因此是性能优化第二考虑要素。按需打包是构建优化的手段之一，是实打实的减少体积，值得我

前阵子我看文章时看到一篇文章讨论 CSS 预处理器的替代方案。其中就是否用使用 CSS 嵌套语法在评论区产生了争论。有人说 有人评论 甚至有人评论  这里我说说我的看法供参考。 我认为架构层应当为业务

特性 阶段 Chrome Edge/IE Safari Firefox Opera 解决方案 可达到效果 postcss 版本 stylelint

前端开发在日常的项目中，面对的难题之一便是浏览器兼容性问题。不同浏览器依赖的渲染引擎、JavaScript 引擎等技术栈和规范有所差异，往往会导致同一个网页在各种浏览器上呈现效果不同。而针对这一问题，

什么是 module/nomodule 技术 我们在打包时，如果打包目标是中底版本的浏览器，就需要插入许多兼容函数和语法转化。 而用高版本浏览器访问，其实并不需要这些变换。如果用高版本浏览器访问，能够

babel 这东西真的很难用，需要配置的地方很多。比如 @babel/plugin-transform-runtime 要专门进行配置，babel 默认是用内联的辅助函数（inline Babel h

业界常用以下几种方式： 1、底层运行 webpack-runtime，基于 webpack-runtime 运行各个模块，包括 polyfill。这个是目前主流方式。这一方式的重大问题是 webpac