Posts with the tag: javascript

Lighthouse is the go-to tool for improving the quality of web pages. Lately, I have been using Lighthouse a lot at work to identify opportunities for performance optimizations. This post is part of a 6 part series that I have written about how to get the most out of Lighthouse.

Lighthouse has been part of my daily work for the last few months and I shared some snippets in my last few posts. For this particular post, it is time to share how I am using Lighthouse in a product used by millions of people and what I have discovered during this process.

Earlier this year, Google announced that “page experience” would impact its search ranking. A few weeks ago, they announced that the new page experience signals will roll out in May 2021. But what are these page experience signals?

Have you ever about thought tracking what is added to a page or web app? Did not know how your website became 15MB? Sounds like it is time to track this data!

Lighthouse captures the rendering timeline of a page in 10 images. Do you need to store them? If yes, keep reading in order to learn how to store these images.

HAR (HTTP Archive) is a JSON file containing all information about a browser’s interactions with a page. This file is often used for performance analysis. Earlier this year, I shared what kind of information we can get from and today we will automate the HAR creation.

A while ago I started an Apple Collection. After a few laptops and a few iDevices, I decided that I should start collecting info about my iThings. In the beginning, I created a gist containing model, serial number, how did I get the device, minimum/maximum OS, etc.

The list kept going bigger and bigger and the content started looking messy. The natural way to organize my data would be inside a SQL database, with the information distributed in columns. After organizing the information in tables, I would create a graphQL API (the one cool kids use these days) to give me the data needed to populate my UI – probably written in React, compiled with Babel and packed with webpack.

People and organizations often have preferences for a specific package manager. At work, we decided to use Yarn due to emoji support (jk) but how to keep everybody using Yarn? 

We can use the preinstall hook to check if the user run npm installor yarn install. Here is one example:

"scripts": {
  "preinstall": "node -e \"if(process.env.npm_execpath.indexOf('yarn') === -1) throw new Error('You must use Yarn to install, not NPM')\"",
}

Autofill in form elements is a very useful feature in browsers. Creating new accounts or shopping in an online store are examples of this feature saving us time.

However, the autofill feature can be a problem for SaaS products. Imagine that you want to edit the email address of one of your users. You hit edit in one screen and once you get a form with your user data Chrome will replace their email to your email. This is not a good user experience.

MDN has an article showing “How to turn off form autocompletion”. The solution is using the autocomplete attribute with an off value. This doesn't work in Chrome.

Digging in Stackoverflow and Google results, I found a bug issued in 2015 about the topic. Here is the TL,DR (from March 2016):

A few months ago we started using React at Thinkific. One of the challenges of using React is creating reusable components not only from a look and feel perspective but also shareable in different projects.

I didn't create this concept of elements (or components) library. To be honest, there are podcasts, courses, and examples everywhere about it but how to even start it? When you start creating a project from scratch you face several questions:

• How to style components? Sass? Stylus? styled-components?
• How to show the elements?
• How to build the library? Babel? Webpack?
• How to publish the library? To NPM or not NPM?
• How to use integrations and CI in your favour?

Lots of decisions and you may not know all the answers. Startup Life™ doesn't let you do whatever you want – everything has a cost and a trade-off. Why am I talking all this story? Because I wanted to share my thoughts about it and I created a repository to document what we are doing.

Criar efeitos visuais em Javascript era algo bem complexo. Muitos efeitos da lista que cito abaixo era algo somente imaginável para criar, para mim, no Flash. Entretanto, as coisas mudaram. O script.aculo.us é uma biblioteca que permite a criação de efeitos de forma super-simples, sem requerer conhecimentos jedi em JS. Vamos a lista então:

1. Image Gallery – Efeitos suaves e bem feitos
2. Reflector – Imagens com reflexos (muito usado no site da Apple)
3. Newsticker – Newsticker não-obstrusivo
4. Auto-Completer – Estilo Google Suggest
5. Auto-Completer – Demo do wiki do script.aculo.us