前文《浅谈移动端单屏解决方案》中，我介绍了移动端单屏场景下的一些常规解决方案。但是，这些方案主要针对的是竖屏的页面，对于一种特殊情况：横屏单屏页面，我们则需要进一步适配。

文中我强调了移动端适配是对屏幕宽度进行缩放：对于普通的流式布局(长屏幕页面)，页面内容是可以上下滚动的。屏幕小，一屏幕看到的东西虽然变少，但是用户可以通过手势滚动页面，继续浏览下一屏的内容。因此在常规情况下，对于屏幕宽度进行等比例缩放已经能解决大部分应用场景了

做移动端页面有一段时间了，总结下工作中常用的几种移动端适配方案。基础网上已经有非常多的基础知识总结，不再赘诉，详情可以见《关于移动端适配，你必须要知道的》《不要再问我移动适配的问题了》其中容易搞混的概念是视口 {代码...} meta标签中的viewport属性，就是视图的含义视口分为布局视口视觉视口理想视口布局视...

前言提到网页播放视频，大部分前端首先想到的肯定是: {代码...} 的确，一个简单的video标签就可以轻松实现视频播放功能但是，当视频的文件很大时，使用video的播放效果就不是很理想:播放不流畅(尤其在：首次初始化视频 场景时卡顿非常明显)浪费带宽，如果用户仅仅观看了一个视频的前几秒，可能已经被提前下载了几十兆流...

前不久接手过一个历史悠久的项(shi)目(shan)，技术栈之复杂(混乱)令我潸然泪下：你甚至可以在一个项目里使用前端三大框架(Angular1, Vue, React)。

前言由于在公司的交易支付部门搬砖，因此To C端的前端支付页面，基本由我这边负责一般来说，一次正常的交易流程，用户会经过几个阶段：浏览商品列表查看商品详情点击购买或加入购物车商品结算(确认购买)收银台(进行支付)支付成功其中收银台作为交易成功的最后一公里，其承担的职责之重可想而知我们先来看看市面上常见网...

A cookie associated with a cross-site resource at [链接] was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure.

jsbridge是随着Hybrid App的流行而产生的一种技术。那么Hybrid App是啥？Hybrid App又称混合App，即同时使用了前端web技术(js,css,html)和原生native技术(java,kotlin,swfit,object-c)进行开发的移动应用。

前后端分离开发已成为业界的共识，但分离的同时也带来了部署的问题。传统web模式下，前端和后端同属一个项目，模板的渲染理所当然由后端渲染。然而随着node的流行，以及webpack的模块化打包方案，让前端在开发阶段完全有能力脱离后端环境：通过本地node启动一个服务器，搭配Mock数据，马上就可以进行业务开发了。

前不久从零开始写了一个webpack多页面打包boilerplate(webpack4-boilerplate)，方便以后工作可以开箱即用，特此记录下开发过程中的要点。 注意：本文不会详细介绍webpack的基础知识，如果完全不会，建议看下我之前写过的基础文章 从零开始搭建一个简单的基于webpack的vue开发环境 从零开始搭建一个简单的基于webpack的re...

PixiJS是一个轻量级的2D渲染引擎，它能自动侦测使用WebGL还是Canvas来创建图形。这个库经常被用来制作HTML5游戏以及有复杂交互的H5活动页。

在上篇文章里，我们学习了Docker常用的命令和基本操作，现在可以开始实战了。 单页应用 前端工作中最常见的就是单页应用了。我们首先用create-react-app快速创建一个应用 {代码...} 可以看见正常启动的页面。 打包试一下 {代码...} 可以看到本地生成了一个build目录，这就是最后线上运行的代码。 <!-- more --> 我...

平时开发，我使用的是vscode编辑器，可以顺便安装docker插件。在插件商店搜索docker，安装完成后，我们可以很方便的管理Docker镜像和容器。

前段时间有个需求，需要前端导出excel。一般来说，对于导出大量数据的功能，最好还是交给后端来做，然而后端老哥并不想做(撕逼失败)，只能自力更生。

最近发现公司一个项目的目录组织挺奇怪的，所有的子项目都放在了packages目录里，还有这种骚操作？特意查了下资料，发现是一种比较流行的monorepo项目管理模式。近几年比较火的React,Vue,Babel都是用的这种模式:

非常简单的几行代码，就实现了一个服务器Server。createServer方法接收的callback回调函数，可以对每次请求的req res对象进行各种操作，最后返回结果。不过弊端也很明显，callback函数非常容易随着业务逻辑的复杂也变得臃肿，即使把callback函数拆分成各个小函数，也会在繁杂的异步回调中渐渐失去对整个流程的把控。

在前端，说到manifest，其实是有歧义的，就我了解的情况来说，manifest可以指代下列含义： html标签的manifest属性: 离线缓存（目前已被废弃） PWA: 将Web应用程序安装到设备的主屏幕 webpack中webpack-manifest-plugin插件打包出来的manifest.json文件，用来生成一份资源清单，为后端渲染服务 webpack中DLL打包时,输出...

React的核心机制之一就是可以创建虚拟的DOM元素，利用虚拟DOM来减少对实际DOM的操作从而提升性能，JSX正是为了虚拟DOM而存在的语法糖

IntersectionObserve这个API，可能知道的人并不多(我也是最近才知道...)，这个API可以很方便的监听元素是否进入了可视区域。

听起来高大上的“生命周期”，其实也就是一些普通的方法，只是在不同的时期传参调用它们而已。我们可以照着React的生命周期，自己模拟一个简单的类，并让这个类拥有一些生命周期钩子

事件的起因源于我大三时写过的一个chrome插件：老司机的工具箱，当时因为某XX御所开启了老司机模式，导致资源下载链接被隐藏，再加上那时无意间看了一篇教程Chrome扩展及应用开发，于是性致勃勃的花了几天时间，写出了这个插件：用来显示被隐藏的下载地址和自动填写百度网盘密码。之后插件也陆陆续续迭代了几个版本，不...

前端开发中经常会进行一些异步操作，常见的异步有： 网络请求：ajax IO操作： readFile 定时器：setTimeout 博客地址 回调 最基础的异步解决方案莫过于回调函数了 前端经常会在成功时和失败时分别注册回调函数 {代码...} node的异步api，则通常只注册一个回调函数，通过约定的参数来判断到底是成功还是失败： {代码...} ...

平时在前端开发中，好像也没啥用到递归的地方。不过这并不代表递归不重要，如果你看过一些框架的源码，就会经常见到它的影子：比如渲染虚拟DOM的render函数，webpack中require依赖分析，Koa2洋葱式的中间件模型，其实都运用到了递归算法。

之前也做过浏览器web端的SDK数据埋点上报，其实原理大同小异：通过劫持原始方法，获取需要上报的数据，最后再执行原始方法，这样就能实现无痕埋点。

小程序的模块化采用了Commonjs规范。也就是说，我需要提供一个monitor.js文件，并且该文件需要支持Commonjs，从而可以在小程序的入口文件app.js中导入：

工作也有一段时间了，平时忙于业务代码的编写中，发现身边的一些人以及自己，对一些基本概念理解有所偏差，可能闹出笑话，会问出下面这些常识性错误的奇怪问题：

1.Person这个函数被定义后，会自带一个prototype属性，这个属性指向一个对象，既原型对象，这个对象同时有一个constructor属性，指向Person

ReactiveX is a combination of the best ideas fromthe Observer pattern, the Iterator pattern, and functional programming

都8102年了，现在还来谈webpack的配置，额，是有点晚了。而且，基于vue-cli或者create-react-app生成的项目，也已经一键为我们配置好了webpack，看起来似乎并不需要我们深入了解。

Node本身已经支持部分ES6语法，但是import export，以及async await(Node 8 已经支持)等一些语法，我们还是无法使用。为了能使用这些新特性，我们就需要使用babel把ES6转成ES5语法