DEV Community: Maximiliano

When Do You Say A Website is Fast?

Maximiliano — Sun, 17 Jan 2021 11:28:57 +0000

15 years ago, I remember when I saw for the first time an image rendered on a screen from the Internet and I was amazed by it. At the time, my perception was different, the 640x480 image took around 6 seconds to be fully rendered and the render experience was jaggy and progressive in a way I could only get a sense of the image 4 seconds along the loading process.

Navigating through pages felt like a whole different experience. If you were aiming to click on a link and instead you clicked somewhere else, you even had time to click the "stop" button at the top of the browser and try again. Every click counted.

I didn't know best, it was already amazing that in a couple of seconds I had access to so much information and we were all thrilled by the mere fact the internet was so vast and available.

I remember I had to do an assignment for school and I used the internet to research. I spent an hour looking for specific information, I found what I needed it and I'd achieved what I had to.

Was it fast? Definitely. It was faster than going to the local library and it was available (at that specific moment the library was closed). I was really happy with how "fast" I managed to complete my task thanks to the web.

Yes, there were some pages that took a lot longer than others to load, especially when they had some images. I waited close to a minute to open a gallery of images and I waited because that type of content was only available there. My friends and I, we all waited... it was worth it.

The perception of speed

If you ask anyone today if they would wait almost a minute to open a media gallery their immediate reaction would be a solid "no!" and probably the reason behind this would be because it is "too slow".

Without much effort, we build a model to say if something is slow or fast. Intuition only relies on the samples that we encounter during our lifetime and we use that information to compare and make a judgment on whether things are according to our expectations.

Making objective a subjective term such as "fast", means that we have to define a set of numbers (metrics) to help us verify that intuition.

The amount of traffic served globally and the bandwidth that supports it have grown exponentially and next to that also our expectations.

What is a fast website today?

Right after you listen to that question you start thinking about examples that match the statement. It is also very hard to say why do we think X is faster than Y without pointing to the very specifics of those examples. Finding a common ground to compare them goes around getting rid of the specifics of a page and finding what are the elements we can use as links between all pages.

To simplify the process there is a constant debate on what we (as a community) should measure and which are the ranges that fall into the "fast" bucket. If you do a quick research on "web performance", "web optimization" or "improve website speed", to name a few, you'll find tons of posts pointing to some almost standardize the list of acceptable metrics.

Google is standardizing and promoting going toward that "performant"/"fast" web experience and they have defined this subset of metrics they call web core vitals. They've put a lot of thought and brainpower into the topic and I believe it is a great starting point.

To decide the metrics and the ranges they have, quite rightly, compare websites. I don't want to make it all about the web core vitals but, to give a more concrete example: One of the metrics is Largest contentful paint. Your website will have a good performance according to that metric if the largest element above the fold loads faster than 2.5 seconds.

Where is this number coming from and should I really aim for that? That came from comparing a lot of pages from the web plus investigation on cognition theory. To get to that number there is a complete explanation by the chrome team that I highly recommend reading[1] and they also made sure that the threshold is achievable.

If your website it's in the "good" range that basically means your website is as fast as the fastest 10% of all the websites.

Being in the green range obviously feels good but, if we think about what are all the pages that they are sampling to come to that number we can quickly realize that there is a basket full of different cookies. Which is good in some cases but really not suitable for others.

By mixing all these websites together they are assuming pages are all equal in a sense and that it is the same to serve an index.html page that has a couple of H2 tags without javascript to the apple iPhone landing page that has an incredible user experience.

We are literally comparing different kinds of "fruits" and I think it might be super unfair to compare them. I'm not saying that these metrics are bad. I'm very happy they exist and we have now amazing tooling and a lot more data to use.

Nevertheless, the more tailor-made your comparison the better the decisions you can make whether some new target might be worth aiming to or not. Takings samples closer to you, like your main competitors, would give you a better idea of what is "fast" for your industry and it might also be that you still provide more value with a slightly "slower" website.

Conclusion

The web is fast, a lot faster than 10 years ago. Maybe it's not as fast as your neighbors' web pages but you now have data to compare and if you want, you can act upon it. Don't take any metric for granted neither the process. If you want to make a good decision on if it's worth or not doing something today, have a critical view of the metrics and use them. The web core vitals is a good starting point but that's only the beginning, it might be enough.

Reference

[1]https://web.dev/defining-core-web-vitals-thresholds/

The Reason I Move Away From Disqus

Maximiliano — Wed, 06 Jan 2021 10:06:25 +0000

TLDR; Performance

Adding comments to your blog or web app is a fairly common task. You should know that the cost of including an external service like Disqus could be high.

While doing some investigation of the things that were affecting the performance of my blog, Disqus was one of the main reasons why my metrics were so inconsistent and lower than the "optimal" level suggested by the lighthouse score.

The Origin of the problem: Let's go 100.

Whenever I don't feel like writing an article for my blog I start wondering how I can improve the platform. Performance is something I enjoy optimizing and that day I decided to start the tweaking cycle. My default tool is the chrome lighthouse dev tool as a starting point and also WebPageTest. Lighthouse is an amazing tool that simplifies the process of diagnosis and sometimes the hints are really useful and WebPageTest it's also a great source of information.

The performance metric from the lighthouse audit was far from 100 and I was aiming for the perfect score. So, I ran the performance audits from WebPageTest and lighthouse to see what was going on.

In the waterfall view of all the resources being requested by the page, I saw that Disqus on average was taking ~500ms for TTFB and ~450ms extra to process. Blocking the main thread for that long affects your metrics related to interactivity. I found that very annoying so to verify the real impact I made a version of the site without the comment box and push it to production. The results were immediate, all the metrics went green. (I should have saved more screenshots). I was convinced now that this third party library was severely taxing my site.

Checking alternatives

Since I only had a few comments on a couple of articles I believed It was a good moment to check alternatives to Disqus. There was always the option to not have comments at all but I still wanted to have that feature. Furthermore, the migration of comments was not something I was really worried about. In the process, I found there is a nice guide for gatsby that includes many great alternatives.

One of the libraries I found most interested and suited my needs was Utterances. It saves comments as Github issues. That means it's public, aim for developers and performant (?).

It was very straightforward to include this library in my blog. After pushing these new changes to production I saw these new metrics for the utterance: ~200ms TTFB and ~20ms to process, with the addition that there's an extra call to the GitHub issues API that takes ~250ms.

The answer was conclusive: Utterance was significantly faster and I was happy with it.

Conclusion

Disqus it's an exhaustive solution for including comments to your site but sometimes it's maybe too much for what you need. There are a few lighter alternatives that you can use that won't hurt performance as much.

Snowpack: A promising bundler

Maximiliano — Sun, 03 Jan 2021 10:23:44 +0000

I remember some time ago I wrote a quickreview about a library called pikaweb. I was interested in its proposal yet didn't entirely understand what they were about. My initial thoughts were not that positive and although I believed it had some potential I failed to see why I would choose to use this library over a more mature one like webpack. Six months later, I checked a "new library" called Snowpack. It turned out to be a revamped version of pika.

Why changing names?

To my eyes, there is no other reason than bringing a new wave of attention to the library and I think the execution was done amazingly well. The library has evolved and with it, almost everything has changed. Only the core of the product has remained the same. The original intention of Snowpack was to leverage from the browser native module API and that is still something seen in Snowpack.

What changed from pika/web?

The last time I checked, pika's documentation was almost nonexistent with quite a few examples and overall hard to understand what it was trying to deliver.

Today, the naming similarity with webpack makes you immediately understand that we are now talking about another module bundler with a promise of being performant.

The resemblances with webpack are notorious. Having such a clear winner of the module bundler "market" brings two clear benefits:

We are familiar with configuration-based bundlers and we are likely to quickly pick up how to work with them.
Having a plugin system like webpack also helps the community ease the migration of some good packages to the Snowpack ecosystem.

Why would I choose to go for Snowpack instead of Webpack?

If you believe in following industry standards this is a valid reason to try Snowpack. Webpack has a significant learning curve and I see Snowpack as a valid bridge from a module-bundler-ruled world to a "no bundler at all" situation. Maybe at some point, we would get rid of all of the module bundlers (dreaming is free).

I was thinking why isn't this a feature of Webpack and I guess that with any new ideas it is easier to create something from scratch to prove it is worth it instead of including it in a big project widely used by the community. Opinions are always strong and the maturity of the project comes with some costs associated.

I believe Snowpack is showing the benefits of using web standards and like what happened with Parcel it can only improve the ecosystem showing that there are still many things to improve for the community.

Conclusion

Snowpack is delivering a new flavor of module bundler with a twist. Is it reinventing the wheel? Maybe. You can still decide to continue going with webpack, parcel, or whatever makes you happy. I'm trying Snowpack myself with a personal project and it's going great. Let's see what happens in six months. Maybe a new name? Who knows...

Check it here: Snowpack

How to improve the UX by optimizing your fonts

Maximiliano — Sun, 16 Aug 2020 19:15:17 +0000

Lately, I have been interested in improving the speed of my blog. The main reason why I wanted to do that was because I love seeing the content instantly. I was checking some performance audit tools and a common sign that every tool was giving was that the way I was requesting the fonts was hurting the speed of my site.

I found two main questions needed answers to come up with a better approach:

Where are your fonts hosted?
What's your font display strategy?

Source of your fonts assets

My fonts were coming from a CDN. This is a common approach and it's very easy to integrate to any webpage because you copy paste a couple of lines and you have it working.

Using your fonts from a CDN have some implications you should be aware of:

CDN could be slow or in the worst-case scenario down.
Performance penalty because of network negotiation: DNS, TCP, TLS.
1. The browser needs to create a new connection because the target resource is outside of your domain.
Prioritization of resources is not optimal.
1. HTTP2 is more efficient with resources from the same domain.
Caching policy is decided by the CDN.
Security could be compromised and you'll deliver malicious fonts.

The other approach is to host your fonts. - Serve your fonts assets from the same domain where your site is host -.

You don't have the disadvantages that I mentioned before and it's not a lot of work.

Font display strategy

Once you have included your fonts in your project you need to load it into your page. You can change the behaviour of how your fonts load with the property font-display . Depending on what you want I'll recommend you to take a look at these two options:

font-display: "optional"

The browser starts by showing nothing (no text).
The browser will start downloading the main font.
The browser will wait for a very short period of time to the main font to be downloaded (~100ms).
If the main font is available it will show that one otherwise it will show the fallback and stick to that.

font-display: "swap"

The browser starts by showing the fallback font (content is shown).
The browser will start downloading the main font.
The browser will wait for the main font to be downloaded (Any time).
After it is downloaded the browser will switch to the main font.

A couple of things worth mentioning. font-display: swap will make your content shift from the "web-safe" font to your main font meanwhile font-display: optional won't show any content at all.

I went for font-display: optional because this gave the user-experience I was aiming to. My blog is full text and the glitch of font-display: swap was really bad.

Check your fallback

With font-display: swap is critical to select the correct fallback. If you have a "serif" kind of font and your fallback is "Times new Roman" then it will look very funny.

Implementation for Gatsby with styled-components

Because I use gatsby with styled-components (emotion) for my blog I will show you how I self-hosted and configured my fonts:

Download your font.
Copy that to your project. e.g. static/fonts/Romoto.woff2
Create a js file where we import our fonts.

// fonts.js
import RomotoWoff from '../static/fonts/Romoto.woff'
import RomotoWoff2 from '../static/fonts/Romoto.woff2'

export { RomotoWoff, RomotoWoff2 }

Create a global styled-component where you will import your fonts.

// globalFonts.js
import React from 'react'
import { Global, css } from '@emotion/core'
import * as fonts from './fonts'

const GlobalFonts = () => (
  <Global
    styles={css`
      @font-face {
        font-family: 'Romoto';
        font-style: normal;
        font-weight: 400;
        font-display: optional;
        src: url("${fonts.RomotoWoff2}") format('woff2'),url("${fonts.RomotoWoff}") format('woff');
      }
    `}
  />
)

export default GlobalFonts

Inject your font into your layout.

// layout.js
import React from 'react'
import GlobalFonts from './globalFonts'

const Layout = ({ children }) => (
  <>
    <GlobalFonts />
    {children}
  </>
)

Layout.propTypes = {
  children: PropTypes.node.isRequired,
}

export default Layout

Use your self-hosted font

* {
  font-family: Romoto, sans-serif;
}

Conclusion

Self-host your fonts and think about your font-loading strategy. We should consider performance but if this means giving a non-optimal UX you should think this twice.

Reference

Docs: font-display

UI: explicit vs implicit actioners

Maximiliano — Sun, 19 Jul 2020 13:20:53 +0000

If you ever used JIRA. This very powerful tool is riddled with features. The tool is so powerful that the designers have an incredibly hard time trying to cram all the functionality on a page.

There are only so many buttons and messages that you can convey on a page before you go beyond the understanding threshold. I always complain about the number of features it has only to discover there's even more.

I was thinking about this and figured that there are two very immediate mechanisms we use when looking for elements and exploring a page.

Visual scan

Imagine that you are in a remote call and you have JIRA open. Someone might try to guide you and teach you how to use the tool, after 5 mins you are both tired of saying "there! / where?". At this point, you probably gave up and let someone else try to continue with the task.

You don't want any of your UIs to go this same path.

The feeling an app leaves you when you see more elements than what you can handle is Visual fatigue. A good UI design will do a great job at guiding you to what would be the optimal approach to the actions that are optimized for.

When a component is setting somewhere in your screen at plain sight I call this: Explicit actioners (CTA). This means that I only have to use my eyes and my interpretation of the elements to figure out what is it going to do after I interact with it.

You go to a page, you wait for all the elements to load, after that, you start scanning the page until you find the text or visual cue (icon/color/animation) that represents the action you want to perform on your page.

If you have a lot of elements this can be A LOT of work. If you combine this with the visual hierarchy given by Font / Color / Size / Spacing / Symbols you can imagine why this could be super confusing at times.

Motion scan

Another great tool we have at our disposal is the mouse.

In a device with a mouse, you can use the mouse to hover over elements and see when changes happen either to your cursor or the page. Sometimes there are even elements similar to drawers (hamburger icons/ dropdown menus/ inline pop-ups). After you interact with them you have even more elements that were once hidden to you.

All these elements that need an extra step to be accessible I'd like to call them: Implicit actioners (I-CTA).

In a mobile device, you can't hover over pages (yet) so you need to rely on your intuition and the correct communication of the elements to guide you in the navigation.

Visual vs Motion

Every app is a different world and I would be lying to you if I say I know exactly the perfect combination of explicit vs implicit actioners you should have on your page.

What I do know is that there's a limit and a relationship between the number of elements and the time users need to understand and later act over your pages.

What is too much? Is really hard to tell until you try it. If you have thousands of users you can rely on your data an A/B test every little decision you make but this is a time consuming and long process.

If you are on the early development process of a project you might want to see examples of what are the "big leagues" doing because they have already spent quite some money on testing what's more likely to succeed.

With a big disclaimer that what works for others might not work for you, I'd say it's good to at least be familiar with the current state of UI art. By this I mean, there's some collective knowledge that you should really use.

A great example of these are hamburger menus: If you see three bars somewhere on a page you expect that to open or show a list of more elements. If you use the same icon on your page to for example make a noise, that might be quite unexpected.

Some ending thoughts

I noticed that I tend to go for explicit-CTAs rather than implicit ones. I guess the trade-off of having too many explicit elements is that you can very quickly reach the visual fatigue for your app and that's when you have to be smart and consider rethinking your use cases to make it better for the vast majority.

Let me know what you think. I'm very interested in knowing what are your thoughts on the subject.

A few words on SEO for client-side rendered apps

Maximiliano — Thu, 16 Jul 2020 19:22:43 +0000

SEO and server-side rendering (SSR) work well together. Every search engine started by optimizing this technique.

In the beginning, JS was used to enhance our pages and improve the experience for the end-user but that changed.

We went full JS rockstar mode and we pushed it to the extreme. We went from adding a layer of dynamism to the HTML/CSS to using JS to create HTML/CSS in the browser in real-time while downloading the resources.

Browsers became monsters. 😋

We moved the rendering process from the server to the client. We did this because ... (I'm not gonna enter this area in this post). The result of that: A gazillion UI frameworks started to emerge.

What makes it so different from client-side rendering?

With frameworks like Angular, React, Vue. We serve an almost empty HTML with a few references to some 2MB JS files which do all the magic.

That turns the SEO process to looks as follow:

Browser: GET https://pugmark.io/dashboard
Server: Send 1Kb of HTML.
Browser: GET bundle.js(2MB)
Browser x100: GET endpoints A-Z / css / moar JS
Server x100: Send all the resources.

We can immediately see how much more work the browser needs to do. The server can go without any template renderer, serve a static file and you can have dynamic pages without many costs on the server-side.

But there are still costs, and those are being transferred to the browser, to the client. 😉

What's with SEO then? A search engine is mimicking a user, if it wants to crawl the content of the page it needs to wait, and sometimes a lot, to see the final content.

This bring some major implications for SEO. People at google are smart and the google-bot is good enough to do this.

But that is not free.

What's the impact?

To deal with this, Google introduced a rendering queue. If your page is SSR google can make a request to that page, crawl the HTML and eventually show on the web results page. This works and I read almost no-one has any problems with google understanding their pages.

If your page is client-side rendered then you are queued. Google needs a rendering engine that understand JS and execute the heavy lifting process of your framework before it can crawl the dynamically generated HTML.

This is very expensive for our fellow google-bot: Energy and, by that we mean, Money.

It can take from hours to weeks to be picked up from the queue. You need to compete with the same resources that are used by sites that probably have a lot more SEO authority than you and we don't really know when this is going to happen.

You also don't have guarantees that the crawler is gonna visit your site. There are many examples of client-side rendered apps that are dropped for some reason and never ended up in the search results.

Having a longer time to market is not something you should take lightly. It can change some business decisions and could be one of the key factors for your application.

Should I go fully SSR?

SSR/CSR it's like a knob. You might not need your site to be available in search engines. SEO is only one of the considerations when we choose frontend technologies.

Javascript SEO is still under development and I was very surprised google had this power already. (Not really working that well)

Going SSR is not the only solution if you have a fully client-side rendered app and you want to be part of the search results.

Pre-rendering

Taking a snapshot of your HTML and saving it as the initial-load for your user and google-bot is another technique that can be used to solve this problem. Again, it's not easy but it might be worth it if you need a middle ground.

Conclusion

Google-bot can crawl your Single-page application but it will have some implications:

Slower time-to-market
Crawling limited to google.
No guarantees your pages will be crawled.

References

Chaos as an exploration tool

Maximiliano — Sat, 13 Jun 2020 09:08:48 +0000

Originally published on blog.m4x.io

Have you ever been in this situation where you don't know what had happened to your day and it's already gone? You have this feeling of under achievement because either you've planned a lot and that was the end of it or you have done everything on your list but still you don't have the fulfillment you expected.

I've been there. I was there yesterday, I don't really know about today and I might be there tomorrow.

Chaos help me find joyment when I take decisions I find myself not commiting to.

I want to share some thoughts, random thoughts, you could even consider this chaotic... that's the whole point.

The negative connotation

When you hear that someone is a chaotic person, you might immediately think negatively. I also thought like this the vast majority of my life because since my childhood, structure and order was one of the main values my family and institutions taught me and Chaos is the opposite. (Isn't it?)

When we hear about chaos we tend to extrapolate to the extreme. That makes it very easy for us to get the concept but this doesn't necessarily need to be black and white.

Depending on the situation, extreme chaos can be something that adds value. If we take as an example a painting, there are many situations where we see a painter forget all the "rules" and go along with what we perceive as chaos...In the end, this could be a master piece.

If we go to the other side of the spectrum and we are extremely organized, you could end up in some behavior that could lead to be so off it can be considered O.C.D. A Harmful act instead of one that supports the situation trying to remediate.

But, for some reason now this side of the spectrum is sociable accepted with more ease because maybe of the misuse of the word and sometimes even brought to job interviews and other places you wouldn't have listened before.

The version of chaos I'm trying to convey here is closer to what we consider "Creativity".

Let me illustrate this with a small diagram where I show the "spectrum":

When everything we do, everything we decide, everything we say it's in line with what we plan we are on the "order" side of the range. If we plan, organize and act based on these premises outcomes are more deterministic and that helps on making future ideas a reality.

When going to the "negative" side of the order range you will find chaos, before reaching the extreme of self-destruction and total entropy you'll find many steps that can help you to be more creative, try new stuff, re-discover yourself. The key here is to know when to look for that side, when to expand your "chao-window" and how to do it. I'm going to tell you what works for me but I'm pretty sure it won't work for you... It can maybe serve you for inspiration.

I want you to remember that to keep this scoped, I want to focus and use as an example the following topic: Technology and Frontend Engineering, which are the things I spent some time thinking and doing last 5 years.

How chaos lead me to where I am now

When I was looking for my first job, I didn't know what I wanted to do (that doesn't mean I really know by now). My mindset at the time was:

I need a job, I don't care about the technology, don't really care that much about the salary, I want to enter the job market.

After a few interviews, I got a .NET developer position as first dev job. I learnt A LOT in the process and I can assure you, chaos was the main driver. I can add reasoning behind most of the things that I did but I would be lying to my self If I said I got everything planned and I knew exactly that 5 years on I will be where I am today.

There was some UI development required for the job and that wasn't planned, I was originally designated to do "backend" web services but literal chaos at work put me into the situation It needed to add some buttons to an old VB6 application, it was not easy, it was not hard, it was fun.

Another task came and it was in this case adding a button to one of the WebApps we were maintaining. Again, not planned from my side but I enjoyed it a lot.

There was some small part of the design that was not decided, I had the opportunity to design how to display it and then later implement . I'm a very visual person, and I found a lot more joy at doing this tasks than the SQL queries I was doing before.

A combination of many things, specially chaos put tasks and challenges on the way that help me discover a new field I didn't know I liked that much.

There is one thing I didn't tell you until now, I'm a person of hobbies, I like MANY things, I don't have time to do everything I want to do. At any specific time I think I know what I like but there are so many things I'm more than sure I have so much more to discover about myself.

When we do like something we tend to dedicate time to it. Maybe we discover how much we like about something and we start increasing our available time until there is not much budget for that. If we use ALL our budget we are limiting ourselves into this discovery process.

Trying to make sense of how I came from my first .NET job to my liking for UI I found chaos in the process, plenty of it. At that time I unintentionally use chaos and helped my way into the Frontend development. I continued with my chaotic behavior and learnt A LOT about how much little I know about everything.

If you are a developer, you can probably relate to the fact that the amount of jargon and libraries, frameworks, books, techniques, concepts that you need to get a grasp to be able to move in this world can be incredible overwhelming. Fortunately, many good people have created content that help you organize yourself into a plan that is less overwhelming. If you are in an early stage of your development career ORDER is a must and thank god we have so many awesome content creators covering this side.

On the other hand, If you passed through that phase (In any specific area), the plan you create for yourself has to pretty much be tailor made. YOU and only YOU know about yourself and the things that work for someone else might not work for you. When we learnt how to organize the next thing we want to learn, the book we want to read and to follow plans. You should start considering chaos is a powerful tool and can play on your favor if you know how to use it.

Deliberate chaos

There is Chaos we face on absolutely everything we do, chaos is not something like diamonds you need to dig a lot to find it. Right now, take a glance at your desk... do you see that cable that is off? that paper from last week that is due, that dust on top of the screen? Ok, you get the point.
This are physical examples, easy to acknowledge. The "non-physical" side of things can live in any form that you can imagine. E.g.Trying to think how to solve your folder structure but "random" quotes of Breaking bad pop on your mind, opening your phone calendar to check something and immediately switching to twitter without even doing what you intended to. I can continue but I'd be revealing way too much about myself. xD

These are example of chaos that we don't control, we don't necessarily ask for it. It just happen because it happens.

When you have worked for years to maintain order in this world full of chaos, you might have became way too good at organizing some specific stuff. In those areas that you are too experienced and room for error has been decreased to a minimum you might want to add CHAOS! :O

What the actual *functional-programming are you talking about? If you have been on the same field for years, you learnt your way into that field. You know how to learn "quickly" enough, what matters to you, what matters to the market, how you react to "new" libraries/ frameworks, new roles: From 'Webmaster' to 'Frontend Developer' to 'UI React Engineer' to 'UI React Native Engineer', to 'UI React Native Redux Engineer', etc.

*functional-programming = The F word

You are creating a mental model of how things are and how they should be. This is very hard to break unless you deliberately try to.

I'll say it : You might need chaos

But not the kind of chaos we already face daily, the chaos that will help you explore and learn more about yourself and the world we live in, but specially about yourself.

You might not need Redux Chaos

This is not for everyone, to everything at anytime. Like many things, there's a moment, a subject, where adding chaos makes sense. Nobody knows about your inner motivations more than yourself and probably a handful of other people (Could be). What I do notice is that everyone in one way or another is using chaos. When we feel unhappy, chaos help us. When we are bored, chaos strikes again. When we have to make an essay and we are playing League of legends, chaos is right there next to you.

How I use chaos

Because this is my story and to make justice a little bit to the title.

How chaos can be used as an exploration tool and how I create deliberate chaos in my life?

As a Frontend developer I like "knowing" or getting a sense of what's the new next thing. Is Svelte gonna conquer the world? Is Service worker really the future? Is JQuery dead? This questions came from chaos.

How I add chaos to my frontend mind?

- I follow on twitter to people that drive the faith of our frontend community. The big names, the ones that say: People jump and 100k frontenders do. (Including myself :P)
- I'm subscribed to many newsletters. Github, JavascriptWeekly, PonyFoo.
- I watch UI "opinions" in several youtube channels.
- I check what "tech stack" are people using on new startup projects.
- I experiment with new libraries and frameworks that I think are worth checking into.

I'm pretty sure you might do the same. It's very hard to talk to some other frontenders if you are not up to date with the new shiny Future proof framework.

Although, that doesn't really create the chaos and exploration level I meant by the title, it's one level of chaos. This creates exploration, not at the level it will really help you rediscover yourself.

What if I ask you?

- Do you like Animations?
- Do you like 3D design?
- Do you like DevOPS?
- Do you like Machine learning?
- Do you like AWS?
- Do you like VR?
- Do you like Mobile development?
- Do you like Management?
- Do you like IoT?

You can answer yes or no to each of this questions, I know. But have you really tried it?
The more away you are from the field you are in (your comfort zone) your discovery process enlarge it, the more chaos you bring to your life because each of these can change your career if you really like it.

If you find more happiness than what you have with what you are currently doing. You should probably do something about it and you probably will.

I don't want to encourage people to GO CHANGE, I want you to think, I'm constantly checking what do makes me happy today. In my spare time I also experiment and try to go out of my comfort zone as much as I can. I find fascinating people that come from other completely unrelated fields like Dancers, Doctors, Biologists. These people know how to explore and take big risks.

Ask yourself bigger questions, explore more, re-define yourself over and over again and be happy!

Conclusion

When we are learning how to learn we learn about chaos and how to control it. We should also learn about how to create it back and use it on our favor.

You probably already have enough chaos in your life, but consider that you could probably use this as your new power. Next time chaos is consuming your time and energy, think about how deliberately this happens. Maybe you discover what make you really happy. :D

I'm very interested if you deliberately use chaos, chaos management is not a thing yet but I think it should. What do you think?

How to equalize your rows in react

Maximiliano — Sat, 28 Mar 2020 19:24:14 +0000

Originally published on blog.m4x.io

How to equalize your rows in react.

As frontenders, sometimes when we are building grids we run into a very annoying but common issue, Unalignment. When the items of a grid are not aligned correctly it is time for trouble.

As human beings, we are very good at detecting these irregularities. An issue like this immediately jumps into our attention.

The problem is easier to grasp with an image so let me show you in a glance what we are talking about.

I hope that the problem is now more clear. I was looking into any library that would help me on my quest since I'm working in react but no luck.

In vanilla javascript, I have done this a bunch of times already but it was gonna be the first time I do this in React.

I've created a very small library to solve this and I hope you'll find it useful.

How it works?

First, you need to specify what's going to be the grid or element you want this component to act on.

This wrapper container will keep track of the position of the elements you want to equalize the height.

Secondly, with the Equalize component, you'll have to wrap the components you want to have on the same line.

Equalize will get the height of all the elements that are on the same line and will apply the correct height to it.

I found this solution worked out quite well at the beginning but then I realized there was one small issue.

If the elements of the lists changed it, the state of the heights needed to be reset. To do this, I added a prop to the container to which you can send an array that would trigger a re-render of the layout.

Problem solved!

Let me know what you think, maybe you also have a use case I can support. I'm more than happy to help!

You can check out the library here: React-equalize

Frontend Architecture: Installing vs Writing modules

Maximiliano — Sun, 01 Mar 2020 10:52:11 +0000

Originally published on blog.m4x.io

When working in an application we are constantly solving small problems to complete a task. Sometimes these issues are common among different use cases we run upon and with the experience we start noticing patterns.

If the problem is generic enough, probably someone else has also encountered it and solved it.

Whenever this happen we face a dilemma.

Should I write my own solution, or should I use this existing module that seems to solve it?

And the answer is YES

In some cases, the YES is more towards writing your own solution and in other cases to install an existing module. In the world of frontend, we have a gazillion of alternatives and options and one npm package/second is born as we speak. (xD)

If you work for a company that has strict rules about how to deal with this sort of decision, this was already sorted out. I haven't had an experience like that myself before so, I'll try to summarize my thoughts when deciding what is more adequate for each particular context:

Context-awareness

When taking this kind of decisions always gathering data about the context is very useful. So for that, we need to identify what it's in the scope of your app and what it is not.

We need to grab the magnifying glass and take a look at the dependencies of the project.

"Module decisions" are always context-dependant.

It's not the same trying to add a library to a repository where all the dependencies are only "very well known" and tested by the industry(express, react, jest, etc) than to a repository where there is not a clear pattern on what are all the considerations taken for the external modules currently being used.

This is the first step and what will eventually help you in defining the answer to the question "Should I write or should I install?🎵".

Keeping the scope in mind it's easier say than to do, but it's key we don't lose track of it because it changes the outcome of your decision and the importance you give to each point you have to juggle with.

A list of questions I ask myself and I find helpful are:

How important is this feature for the business?
Do we know if there is already a plan involving a high level of customization?
Was this issue already solved by other colleagues?
Are we ready to solve this specific issue on our own?

1. How important is this feature for the business?

It's very likely that if you are implementing a core feature for the business, this will change over time. Evolution of every part of your app is one of the constants in software development, there are going to be parts that grow more than others and the speed at which you can move on with the core features are probably going to have a direct impact to your business.

Asserting how important is what you are going to work on for the business is also going to be affected by the state of your company. When your company is at the phase of testing an idea and the resources are limited,the focus should be on making sure our implementation tests the idea and that's it.

You don't want to spend hundreds of hours on a prototype that might be discarded because of the lack of market or because you developed something the market didn't want. Believe me, been there done that.

2. High level of customization upcoming

Sometimes, we know that in the coming future we'll face some changes for the implementation we are today working on. Even in mature companies with mature products the roadmap is more of a guideline than a plan. The further in the roadmap you see a feature coming, the least you need to worry about how your current implementation is connected with that future. The likeliness of you working on a feature that is set on the roadmap is directly proportional to how close it is to the current date. Use this on your advantage and at the moment of taking a decision: Spend time on what is more important today.

If you see that something is inevitable don't look aside and wait for the chaos to come at you.Speak up and save time.

How is this related to modules? The decision to add a module today might be tempting, but if you look a little bit ahead you'll realize it doesn't make sense to add it because in a couple of months you'll have double the work.

3. Was this already solved by some other colleague?

If you work long enough for a company you'll start noticing there are requirements that are going to be similar to others.

At some point, either your team or someone external will start asking questions like, doesn't this look like that? When that happens, It's time to stop the wheel for a short moment and talk about the differences.

Similar problems might have similar solutions in their backbones and your more experienced colleagues are pretty likely to be really good at spotting the similarities and advantages of your problems and solutions.

If you are not sure, go ask, talk to them. This can only give you and your team an advantage because you will not only solve your problem with the best input, you'll also learn A LOT in the process.

Additionally to this, you'll get to know them better and start understanding how your solution will fit in the ecosystem.

At some point, you'll find someone that says yes. I have this module that does exactly that, or I have this module that can be extended and what you have to do fits there.

Then there it is! you are a lucky man.

Start from your team, and then keep on asking inside your company. Don't run directly to google and npm install the first result.

4. Are we ready to solve this specific issue on our own?

It could be that when you go ask in your company what's being used to solve X, the answer is that the solution was taken from the open-source community.

Its needed a lot of repetition to become a master on something, there are some very complex problems that you need years of experience to start feeling comfortable with.

When you are at a point that you feel really comfortable and ready to add extra value to your company, you should consider implementing your own modules.

You can even think about going beyond that if your company is open-source friendly and contribute to the community.

A module could go from a function that gives you a sum of two numbers to a web framework.

This decision generally happens when the use case you need to support is not really solved by any of the options available today plus you are an expert on a subject.

Disclaimer: If you are not an expert you might become one after solving it but, this comes at a cost.A LOT of time.

It's all about control

After we have identified the context in which we are taking this sometimes tough decision. We can now focus on the repo where this new module needs to exist.

When working with a repository, you'll start familiarizing yourself with the list of external dependencies used to solve specific issues. If you are new to the team, you can go to the list of dependencies and take a look at what it was "agreed" to use externally.

Don't take things for granted!

It's very important you question the decisions of your team to understand what were the thoughts that lead your team to decide on importing something externally when you feel that it should not have.

Whatever it is imported from an external package manager on our project it's not directly on our control so we bring all the decisions of that external dependency with us.

Luckily, there are people that have been working for YEARS in solving very specific issues and build amazing solutions.

The Gray area of dependencies

What problem do you really want to solve?

So, when the borders are not clear we are lost. In a repo, the flexibility we have to install whatever we want whenever we can could be nice at the beginning, but at some points you need to start adding constraints so it becomes super evident what is really the problem this project is solving.The code you want to maintain should be the core of the solution you are trying to solve. The "potential" your repo has at solving problems could be increased by including external libraries.

With this said, you should be careful and not go to the extreme, you don't want to kill a mosquito with a bazooka, that's not efficient. (It's fun though)

This gray area that I find incredibly hard to explain is something that we are constantly changing by introducing or removing dependencies from our repos.

To make myself a little bit clear I'll give a couple of examples of modules and how I do approach them:

Example case 1: isNull (lodash) - Utility Library

When you start to familiarize more with Javascript, you get to know its peculiarities and, you might say, lack of features. Operating with different types of variables (adding, subtracting, comparing) behaves differently as you would expect and there are tons of examples. Let's imagine you need to check if a variable is null. What do we do?

Case 1: Lodash is already a dependency. We import the function we need and we are done.
Case 2: We don't have any "utility" library that can help us so we have to decide.

Do we want to add lodash to only use isNull? Luckily today you can install lodash.isNull and you are settled again. But you could be in a situation that you need a banana and you install the jungle.

Code you write is code you have to maintain and if you are in a code base that has coverage you'll have to add a battery of tests as well, and the more underestimated feature: Documentation.

In the case of isNull I would say it seems even ridiculous since the function is extremely small: (const isNull => value => value === null).

The function can be written in seconds. Over analyzing this is already wasting time. The process of npm installing is maybe more work than creating a function.

Example case 2: Formatting dates - Utility Library

At some point, we have to show a date in our application and when we show it to our stakeholders they say it has to look prettier than Fri Feb 21 2020 08:27:13 GMT+0100. So we notice we have to do quite some work to make it work in a prettier, more custom made format.

Again, we could start with learning the Date API in javascript and at some point, we are going to realize how much of a hassle it is to do simple stuff.

There are multiple options for this and I'd say it is worth spending time reading what some libraries provide and how much it's the cost at the moment of importing them.

Dealing with dates is hard. If you have plenty of experience with this it might be good for you at the moment to build a custom made library for this, but this decision is not only going to affect you in the future, it will also your team.

Example case 3: React - UI Library

We are entering the level of complexity and kind of problem which is generic enough A LOT of developers encounter. When this happens the options tend to increase, the number of opinions as well. When A LOT of very capable people gather together and solve a complex problem the solution tends to be complex as well.

With this, I'm saying flavors are all over the place and today, as an example, one of the options you have to build your UI is React.

What does it do for you? A lot.

The problem of creating a performant, UI library that abstracts you from manipulating the dom is very complex.

It is so complex that you would need to spend a significant amount of time to build something relatively close to what React does.

Trust me, there are people that breathe this kind of problem day and night so you can focus on what matters to your business.

I agree with you it is cool to create a UI library but holy Santa molly it's a hell of a job. Giants of the industry have collaborated to create something that works pretty well. There is an entire team dedicated to this solo job.

In the end, you might not even need a UI library at all. You could do a lot of stuff with a couple of utilities.

I don't know your use case, you do.

When we are talking about this amount of complexity, I wouldn't even think about using modules vs creating my own. If there is something you could use, try it out.

Evaluate the options you have, maybe even extend one library, contribute to making it easier for someone else. You are not Facebook, you are not google… and If you are, don't let the challenge discourage you from building the next unicorn UI library.

Example case 4: Next JS - UI Framework

Modules are abstractions on top of abstraction, on top of abstractions. The more layers you have on your app the easier it is for you to focus on what really matters to your business. But, this doesn't come without costs. Decisions have been made and you have to live with those. Next.JS is a framework built on top of react that provides you with server-side rendering and a file routing mechanism, and a lot more. These guys and girls did an incredible job of making sure the framework is extensible enough to let you access the layers underneath and give the control back to the developers.

This was not done on a single night, the company ZEIT is putting significant energy and time on maintaining the framework. This is not their main business, but somehow they managed to change the state of the art in the terms of UI libraries and make it into their business..

They are a clear example that if you have the right people and all the conditions. You can contribute to the community and create a profitable business..

With all this said, I think you should not rush the idea of creating your own framework. You should definitely start involving more and more of the relevant participants and make sure you are all on the same page before you spend a minute writing a single line of code.

Decisions, decisions and more decisions (Snowball effect)

Install vs Writing modules is a decision kind of problem and although we take thousand of decisions every day without even thinking, we are bad at it. We struggle a lot with non-trivial decisions that have plenty of options to choose from. To improve your decision-making process you need to practice, you need to get involved and make calls yourself.

And why sometimes it's so scary to take these decisions because if we take the wrong ones it could and will bite us in the ass. And you know what? That's OK. It's a learning process and if you can't learn from more senior developers around maybe you are the senior that has to commit the mistakes to teach the rest.

I didn't want to conclude this article without mentioning something I always encounter. There is a snowball effect of modules from the very first decisions you made for a project. If today you install dependencies for absolutely everything and that's something that you breathe and take with you, the people that trust you and also take a look at the project start doing the same. This changes when a whole team is re-build again, especially if decisions are not well documented.

I know this is not only a frontend kind of problem but the rapidly growing ecosystem of npm packages in the frontend community it's a double-edged sword and we are constantly dealing with it.

Conclusion

The more complex the problem, the more effort we have to put on evaluating if you should include or not something to our project. Therefore, at some point, it's easier to just try out libraries instead of even think about solving a problem ourselves.

By being more conscious and spending extra time on this subject you will learn a lot.

When In doubt, maybe you can meditate a couple of seconds and ask yourself a few questions to determine the context for this issue. This will limit your options and help you with the outcome.

The difference between an experienced developer and a not that experienced one is that the more experienced one is more likely to make the right decisions at the right time and because of this, avoid extra costs.

The more experience you get, you'll maximize the amount of time spent on the right implementation.

Be aware of the gray area of your repo, be a positive factor in reducing uncertainty and help yourself and your team in the future. It's really fine to not know at the beginning, but if you want to move faster and get good at it, give a third thought before you npm install.

And what about you? How do you decide on what to spend time when it's about modules?

Add disqus to your react app in a glance

Maximiliano — Wed, 27 Nov 2019 22:02:29 +0000

Originally published on m4x.io

I recently started adding more content to my blog and in the process I decided having a communication channel with my audience, if there's any, would be quite useful.

Disqus it's a "comment as a service" platform that give you all the tools you need to have this feature on your application in literally 5 mins.

Let's get it on

Create a disqus account, if you don't have it yet.
Add the component that is going to load the disqus comment box to your app.

// Comments.js
import React, { useEffect } from 'react'

const Comments = ({ fullUrl, id }) => {
  useEffect(() => {
    const DISQUS_SCRIPT = 'disq_script'
    const sd = document.getElementById(DISQUS_SCRIPT)
    if (!sd) {
      var disqus_config = function() {
        this.page.url = fullUrl
        this.page.identifier = id
      }

      const d = document
      const s = d.createElement('script')
      s.src = 'https://MYDISQUS.disqus.com/embed.js' // REPLACE THIS LINE WITH YOUR DISQUS LINE
      s.id = DISQUS_SCRIPT
      s.async = true
      s.setAttribute('data-timestamp', +new Date())

      d.body.appendChild(s)
    } else {
      window.DISQUS.reset({
        reload: true,
        config: disqus_config,
      })
    }
  }, [])
  return <div id="disqus_thread"></div>
}

export default Comments

Use it in your app whenever you want to add comments:D

// Post.js
import React from 'react'
import Comments from './Comments'

const Post = ({ url, id }) => (
  <>
    <RestOfThePost />
    <Comments fullUrl={url} id={id} />
  </>
)

export default Post

Make sure you add the url of the page you are taking comments for and an id.
Wait for the awesome comments from your followers.

Is that all I need?

Yes! Incredible, that's all that you need to use disqus. Make sure to add comments yourself to be sure you are sending the right url and id. Stay longer if you want the rest of the story...

Extra: Juice of the story

While doing some research on how to add this I encounter a couple of options that I could try on:

First,I tried adding the snippet of code that it's in the disqus wizzard.

I turned into a component with the famous dangerouslySetInnerHTML and It looked like this

import React from 'react'

const Comments = ({ fullUrl, id }) => {
  const html = `
  <div id="disqus_thread"></div>
  <script>
  var disqus_config = function () {
  this.page.url = '${fullUrl}';
  this.page.identifier = '${id}';
  };
  (function() {
  var d = document, s = d.createElement('script');
  s.src = 'https://MYDISQUS.disqus.com/embed.js';
  s.setAttribute('data-timestamp', +new Date());
  (d.head || d.body).appendChild(s);
  })();
  </script>
  `

  return <div dangerouslySetInnerHTML={{ __html: html }} />
}

export default Comments

But, this didn't work out of the box. Every time the client side routing was switching components it was behaving quite awful. Also, I was adding a new script everytime the component was mounting.

Yes, I know it was waaay to mvp. But it worked, 2 out 10 times :P

Second tried was using the npm module disqus-react that disqus provides but I was skeptical of how would this be much different from the web approach and if you look at the code...

// file: https://github.com/disqus/disqus-react/blob/master/src/DiscussionEmbed.jsx

// ..lots of react code
 loadInstance() {
        const doc = window.document;
        if (window && window.DISQUS && doc.getElementById('dsq-embed-scr')) {
            window.DISQUS.reset({
                reload: true,
                config: this.getDisqusConfig(this.props.config),
            });
        } else {
            window.disqus_config = this.getDisqusConfig(this.props.config);
            window.disqus_shortname = this.props.shortname;
            insertScript(`https://${this.props.shortname}.disqus.com/embed.js`, 'dsq-embed-scr', doc.body);
        }
  }
// ..lots of react code

...and if you look at the code, It isn't.

I didn't install the npm module and tried it out because at this point I have learnt enough about what I need to do to make it work without another black box in my proyect.

So, a couple of tries more and I ended up with this small, in house component that does exactly that. - useDisqus

In this story of adding a "simple" component. I hope you can relate with the thought process to decide what to do at any given time when picking a new library.

If you read this far, thank you and give me a sign ( like, comment, email, etc) that you want to keep reading about my day to day struggles.

I have a tendency of over analyzing simple stuff which sometimes are good for stories but not that much for your productivity.

PS: it took me more than 50 mins to add disqus and I hope you can do it in 5 mins. (10x factor)?

What is react concurrent mode, really?

Maximiliano — Sat, 23 Nov 2019 20:29:47 +0000

Originally published on m4x.io

Concurrent mode is now with us and came to stay. The last feature was launched in an experimental mode and promise an improvement in the overall performance of your web apps.

This feature originally was not created to support suspense, but this mode, consequently allows suspense to be possible.

In my words,

Concurrent mode it's a flag that allows react's engine to decide when to commit to the DOM when in presence of several simultaneous changes

In essence, this mode makes react smarter.

Why there is so much hype around this feature?

When the core of react was re-written entirely in React fiber, one of the main benefits was the possibility to keep track of several "virtual threads" (fibers) which are tagged with a priority. In a very general way, react now can give top priority to components the user was interacting with and assign a lower priority to the rest.

React fiber sat down the foundations on which concurrent mode works. When multiple elements are changing at the same time, react can now smartly decide which elements of the virtual dom have priority to be rendered.

In a few words, react can handle multiple changes "at the same time".

How is this different from the "normal" mode of react?

In the let's say, dumb version (synchronous mode) of react, React render the screen taking as a premise that everything that is going to be rendered depends on synchronous content and have the same priority. After react's magic algorithm, the dom is efficiently mutated and we immediately see the representation of the new state.

In the case the screen or component depends on an asynchronous source of data, and also this source is incredible fast, react will be true to its behavior and will render every intermediate state our component transition, even for a split second. This will result in the user seeing a flash of "unloaded" state (?FOUS :D) on every component tide to this source.

The key difference is that in normal mode, once react has committed to render a fiber, it can not be interrupted anymore, with concurrent mode, it can.

Wait, wait, wait... Explain as if I were your old grandma (non-programmer)

Pre-concurrent mode react is not able to interrupt the rendering process of components. Additionally to this, it doesn't have any idea that there are a lot of dependencies to "external" services (mainly APIs) and then it cannot do anything to optimize the user experience.

Post-concurrent mode we let react's engine interrupt components and in combination with suspense know our dependencies with external services so it can smartly make use of this information and decide what it's more convenient to render at each time.

An example, very skewed to the suspense feature. We have a section on our screen that is going to show a spinner while fetching data from an API. This API only needs 20ms to return a value. In synchronous react we are going to see a spinner for a small fraction of time which turns out to be very "inefficient" because after the browser renders that It has to recalculate the new layout with the result of the endpoint.

It would be way more convenient to wait a couple of milliseconds more to make a efficient use of the resources and also present to the user a final state of the UI instead of the, sometimes very annoying, intermediate state.

This last strategy is possible thanks to React concurrent mode.