All Articles

Micro Progress

You can only learn so much, this is some Micro Progress

This is not a revised essay, it is mainly notes, with thoughts

So, I realised that the Frontend Developers Handbook was out there, after not thinking about it since last year. I read and read.

Their 2018 recap

I have a lot more to learn about React.

JAMStack is sweet. This site is using the this stack… it’s on Gatsby. Any static site I make in the future likely will be as well. Creation to deployment in days. Separation of concerns. Tons of awesome plugins that literally make the site “blazingly fast”. I can’t see why I would stop using it.

More reasons:

  1. No need for a server. Just use microservices.
  2. Security is locked, everything is in the browser.
  3. Cheap hosting, literally free on Netlify, etc.
  4. Loose coupling
  5. And again… performance! This site has a 99 on Lightouse last time I checked. 99!

Again, You can only learn so much, no such thing as true fullstack developer, unless you are very experienced in the industry. Maybe then, that is possible. There is only so much a mind can know. And, honestly, to be one with the mind that grasps everything is not a goal. Happiness is as important as work. They are connected, though, perpetually.

no such thing as a fullstack developer

I wrote this down in relation:

  1. Do the research
  2. Look at the big picture
  3. Create some structure
  4. Take the decision out of the moment
  5. Stop chasing trends
  6. Prioritise happiness

And truly, what is a front end dev, i’m part of the new generation, so one that learns all the things at once. But before me, there were clearer job titles. You do CSS and HTML, and maybe design, maybe a little JS. Now, you have to know React, JS, HTML, CSS, Node, be good with the command line, maybe some AWS, on and on.

Start using CSS grid all the time, browser support is there

SO much is there! The ever changing world of front end development.

  1. CSS variables
  2. Webp will soon be compatible in SAFARI, of all places.
  3. What an awesome site: this one right here

And i do agree in the distrust of CSS in JS

I mean, can’t I enjoy the comforting confines of CSS file from time to time?

const Title = styled.h1`
  font-size: 1.5em;
  text-align: center;
  color: palevioletred;
`;

// stuff...

<Title>I am title</Title>;
<style>
  h1 {
    font-size: 1.5em;
    text-align: center;
    color: palevioletred;
  }
</style>
<h1>I am just an h1, like you expect</h2>

I like this better.

I loved this article about performance

Why?

Mainly as if you get anyone to read it, they’ll be convinced, that yes, that bundle needs to get smaller.

And images like this:

you need a perf budget diagram

And things like this:

Budgets define measurable constraints to allow a team to meet their performance goals. As you have to live within the constraints of budgets, performance is a consideration at each step, as opposed to an after-thought.

Metrics:

  • Milestone timings — timings based on the user-experience loading a page (e.g Time-to-Interactive). You’ll often want to pair several milestone timings to accurately represent the complete story during page load.
  • Quality-based metrics — based on raw values (e.g. weight of JavaScript, number of HTTP requests). These are focused on the browser experience.
  • Rule-based metrics — scores generated by tools such as Lighthouse or WebPageTest. Often, a single number or series to grade your site.

This quote as well:

Field data (or RUM — Real User Monitoring) is performance data collected from real page loads your users are experiencing in the wild. Sites with heavy JavaScript payloads would benefit from measuring main-thread of this work through Long Tasks and First Input Delay.

  • Utilise browser API JS to see things in a new light.

I mean, what made Google Google? Likely this guy:

Larry page

And what was his passion as a young un doing his Google stuff?

Performance based on this quote from Wikipedia:

Page also believed that the faster Google’s search engine returned answers, the more it would be used. He fretted over milliseconds and pushed his engineers—from those who developed algorithms to those who built data centers—to think about lag times. He also pushed for keeping Google’s home page famously sparse in its design because it would help the search results load faster.[28]

Babel 7 release

I read an article about it written by Henry Zhu. Which led to internet wandering, which led to this:

Hope in Source Podcast

Which is something I’ve been dwelling on recently, faith/religions. I read this quote:

We talk about our backgrounds and motivation for doing this podcast, and why the practice of faith seems so prevalent among open source developers.

The last part touched me. As I’ve been wondering recently if faith, religion, the like lead to more thoughtful, hard working individuals. My guess is yes, it takes away quite a bit of the clutter.

A react pattern I should utilise more often

something.filter(doFilter(this.state.query));

function doFilter(query) {
  return function(user) {
    return query === user.name;
  };
}

Use higher order functions more often.

On the topic of React, really, what is the virtual DOM

My notes state this:

• Recursively nested objects that reference DOM elements. And the references are, if I’m remembering correctly, a linked list of elements, with algorithms and data structures behind to properly handle the list. There is also other little optimisations that I don’t understand well enough. lot’s of recursion.

  • It is basically a bunch of calls to new whateverElementIsReferencedInObject, element.addEventListener, element.className = ..., etc.

Which is…?

And Refs?

• A special identifier that can be referenced at specific instances of time. Useful to do vanilla JS released to styling, or adding classnames, etc. to an element in the confines of React

Some dudes useful way to handle a React project already in existence, he does this:

My 3 Steps for any project:

  1. Load page on Chrome, use Coverage Tool (DevTools => Ctrl+Shift+P => type “Coverage” => press Drawer: Coverage),
  2. Press reload icon and see how much unused code you are shipping init. page load.
  3. Find those modules and lazy load with import()

Sounds about right, keep that bundle small.

He goes deeper:

PRPL (Push, Render, Precache and Lazy-Load) is a pattern for aggressively splitting code for every single route, then taking advantage of a service worker to pre-cache the JavaScript and logic needed for future routes, and lazy load it as needed.

Learn JS, then React

This quote:

In conclusion, there is lots of JavaScript which can be harnessed in React. Whereas React has only a slim API surface area, developers have to get used to all the functionalities JavaScript has to offer. The saying is not without any reason: “being a React developer makes you a better JavaScript developer”.

  • I personally, do agree that learning the right things about JS will greatly assist you, like in the article you should definitely keep up with being able to write quality JS code with Objects, Arrays, etc. All the new and cool stuff.

    • BUT, that only touches a surface level. A hard level to get to but there are deeper elements of JS such as lower level data structures or Browser API’s that one should also put time into learning.
    • Though, still, React’s new features are often simultaneously integral to understand. Hooks, Context, Suspense, etc. Understanding these tools are vital for a React Developer.

Something from a Triple Byte article

Engineers who use Go are also especially strong. If you know why, please let me know.

This is in relation to Triple Byte’s programming tests (mainly in relation to data structures/algorithm stuff). And people who take the tests in Go tend to pass regularly:

chart showing what programming languages people pass triplebyte exams with

Some stuff about JavaScipt, things to think about JavaScript

Next few things are thanks to this awesome article: Preparing for a Front-End Web Development Interview at Top Tech Companies

  • Mainly, it initialised the following learning, but i still have more to parse in the article.

JS

// Traversal up and down the tree
const el = document.querySelector('.some-el');
const parent = el.parentNode;
const firstChild = el.firstChild;
const lastChild = el.lastChild;
const children = el.childNodes;

// Traversal left and right
const previousSibling = el.previousSibling;
const nextSibling = el.nextSibling;

From MDN, I think, about DocumentFragment

A common use for DocumentFragment is to create one, assemble a DOM subtree within it, then append or insert the fragment into the DOM using Node interface methods such as appendChild() or insertBefore(). Doing this moves the fragment’s nodes into the DOM, leaving behind an empty DocumentFragment. Because all of the nodes are inserted into the document at once, only one reflow and render is triggered instead of potentially one for each node inserted if they were inserted separately.

<ul id="list"></ul>

<script>
  var list = document.querySelector('#list');
  var fruits = ['Apple', 'Orange', 'Banana', 'Melon'];

  var fragment = document.createDocumentFragment();

  fruits.forEach(function(fruit) {
    var li = document.createElement('li');
    li.innerHTML = fruit;
    fragment.appendChild(li);
  });

  list.appendChild(fragment);
</script>
  • So, if you ever need to create a bunch of elements on the fly, use DocumentFragment to prevent the DOM from updating more than once.

And these two things I wrote:

  • Cache created DOM nodes, and use them as a pool of pre-assembled elements you can put back in the page as needed.

    • So if for whatever reason you need to create lots of elements for common use cases, cache these elements, be prepared in a way? I wonder what React does
  • Look for excessive repaints and reflows or massive waves of DOM manipulation.

    • In other words, learn how to use Performance dev tools better. And record page load, things like that. Likely, when you have time take those Google Performance free courses on Udacity again. Was a long time ago.

CSS

/* descendant selector */
ul li {
  margin: 0 0 5px 0;
}
/* child selector */
ul > li {
  margin: 0 0 5px 0;
}

ID’s vs Classes

I tend to use classes too much and rarely ID’s but I should use ID’s more often, I know this.

Someone on Stack Overflow states this:

A good way to remember this is a class is a type of item and the id is the unique name of an item on the page.

  • So use ID’s for a page, that’s the main gist. classes for reuseable stuff.

BEM

Basically, .some-class__thing-in-class

HTML5 - Ya, I have a lot to learn…

<header> header for document or individual section

  • Same with footer, but opposite

<main> main content of a document

<article> self contained composition in a document. Intended to be distributable or reusable.

<aside> portion of document only indirectly related to main content

<section> standalone section in document, generally with a header

<details> and <summary>

  • This will create an accordion, summary is the title, text is what is seen when clicked
<details>
  <summary> Details </summary>
  Something small enough to escape casual notice.
</details>

<dialog> similar to a notification

<dialog open>this is seen</dialog>
<dialog>this is not seen</dialog>

<figure> and <figcaption>

  • Used for an image that has a description. The description is right below the image.
<figure>
  <img ... />
  <figcaption>...</figcaption>
</figure>

<mark> Highlights text

<nav> For a section of a page that provides navigation links

<meter> creates a battery looking thing

  • It even changes colors based on the low/high/optimum values
<label for="fuel"> Fuel level: </label>
<meter
  id="fuel"
  name="fuel"
  min="0"
  max="100"
  low="33"
  high="66"
  optimum="80"
  value="50"
>
  this is like the alt
</meter>

<progress> shows indicator for the completion progress of a task

<label for="file"> File progress: </label>
<progress id="“file”" max="“100”" value="“30”">
  alt for it
</progress>

<summary> for a summary, caption, or legend for <details>

<time> represents a specific period in time.

<!-- date time can represent three forms of time -->
<!-- Precise date -->
<time datetime="2018-07-07"> July 7 </time>
<!-- Time on a 24 hour clock -->
<time datetime="20:00"> 20:00 </time>
<!-- A valid time duration -->
<time datetime="PT2H30M"> 2h 30m </time>

<dl> - for a row of definitions

  • <dt> - is the word
  • <dd> - is the definition

Write way to do a form:

<form>
  <fieldset>
    <legend>...</legend>
    <!-- inputs and other stuff -->
  </fieldset>
</form>

And now for something completely different:

he's the most dangerous of animals, a clever sheep