alekseykulikov

/**
 * Credit: https://github.com/csswizardry/ct
 *
 * Main changes:
 * - use as a bookmark (toggle on/off)
 * - work with any CSP (no extrnal scripts/styles)
 * - fix an issue with async scripts added using inline JS (impossible to detect with css)
 * - improved styles detection with [rel='stylesheet'][href]
 *
 * Add JS bookmark -> javascript:(<code below>)

alekseykulikov

Github Actions is a CI/CD platform that gained a lot of popularity recently. I participated in building ⭐️ Lighthouse CI Action and was curious how well it performs.

But Github Marketplace UI shows no ranking information. Essentially, It's a search with random results; at least, I don't understand the order. I couldn't find ⭐️ Lighthouse CI Action in Continuous integration category after browsing 50 available pages (Each page shows 20 results, so it's possible to see only 1000 results, but CI category has 1469 😐).

I decided to build a custom script that crawls all categories and use Github Search (example query) to estimate usa

alekseykulikov

{
  "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/85.0.4161.0 Safari/537.36",
  "environment": {
    "networkUserAgent": "Mozilla/5.0 (Linux; Android 6.0.1; Moto G (4)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3963.0 Mobile Safari/537.36 Chrome-Lighthouse",
    "hostUserAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/85.0.4161.0 Safari/537.36",
    "benchmarkIndex": 1206
  },
  "lighthouseVersion": "6.0.0",
  "fetchTime": "2020-05-31T13:08:20.759Z",
  "requestedUrl": "https://developers.google.com/",

alekseykulikov

In this article, I would like to share three features of PageSpeed Insights (PSI), that is not easy to find in the official documentation. I discovered them while hacking on the Lighthouse plugin and integrating PSI to Treo.sh.

For a context, PSI is a simple yet powerful API by Google, that audits your page using Lighthouse and provides real-world users' data from Chrome UX Report (CrUX).

1. Audit many categories with one request

By default, PSI API returns only performance category. It's possible to pass ?category argument multiple times and get a report with many Lighthouse categories using one request (available categories: performance, accessibility, best-practices, seo, pwa).

curl -i "https://www.googleapis.com/pagespe

alekseykulikov

Recently CSS has got a lot of negativity. But I would like to defend it and show, that with good naming convention CSS works pretty well.

My 3 developers team has just developed React.js application with 7668 lines of CSS (and just 2 !important). During one year of development we had 0 issues with CSS. No refactoring typos, no style leaks, no performance problems, possibly, it is the most stable part of our application.

Here are main principles we use to write CSS for modern (IE11+) browsers:

• SUIT CSS naming conventions + SUIT CSS design principles;
• PostCSS + CSSNext. Future CSS syntax like variables, nesting, and autoprefixer are good enough;
• Flexbox is awesome. No need for grid framework;
• Normalize.css, base styles and variables are solid foundation for all components;

alekseykulikov

$ npm i -g browserify uglify-js pretty-bytes
$ npm i react
$ browserify node_modules/react | uglifyjs -m | gzip | wc -c | pretty-bytes
> 51.58 kB
$ npm i backbone jquery
$ browserify node_modules/backbone | uglifyjs -m | gzip | wc -c | pretty-bytes
> 41.99 kB
$ npm i socket.io-client
$ browserify node_modules/socket.io-client | uglifyjs -m | gzip | wc -c | pretty-bytes
> 20.64 kB

alekseykulikov

var co = require('co')

/**
 * Wrap koa-like generators to express-like callbacks.
 *
 * @param {GeneratorFunction} fn
 * @return {Function}
 */

modules.exports = function wrap(fn) {

alekseykulikov

{
	"preset": "node-style-guide",
	"requireCamelCaseOrUpperCaseIdentifiers": "ignoreProperties", // for external APIs
	"requireCapitalizedComments": null, // why???
	"requireCurlyBraces": null, // allow one lines
	"requireTrailingComma": null, optional

	// personal style
	"maximumLineLength": { // 80 is a goal, but sometimes it's necessary
		"value": 120,

alekseykulikov

{
  // validate code
  "freeze": true, // prohibits overwriting prototypes
  "unused": true,
  "undef": true,

  // relaxing options
  "expr": true, // suppresses warnings about expressive expressions, like ?
  "laxbreak": true, // allow line breaking
  "lastsemic": true, // suppresses warnings about last missing semicolon

alekseykulikov

In reply to Jeremy's tweet, that underscore is 3x smaller (simpler?) than Lodash! https://twitter.com/jashkenas/status/568564455937839106

Apparently, it's only true if you use <script> tag, but if you use lodash's module feature and build your project with browserify(or webpack) you get different numbers. In simple cases underscore can be 4-6 times bigger.

15020 bundle-lodash-without.js
 4820 bundle-lodash-without.min.js
 1647 bundle-lodash-without.min.js.gz