10x Performance Increases: Optimizing a Static Site

Use case by JonLuca De Caro in which he optimised the page load speed of a static site. Before optimisation the site weighed 1MB (at 20 requests) with DOMContentLoaded at 3.74s. After optimisation the site weighed only 267kB (at 9 requests) with DOMContentLoaded at 197ms.

10x Performance Increases: Optimizing a Static Site →

Elsewhere , , Leave a comment

JavaScript asyncawait: Resolving Promises in parallel

Recently I saw a colleague implement some functionality in which he required two results from an API using asyncawait. The piece of code looked something like this:

The code looks fine, is syntactically correct, and works … but there’s one big problem with it: the calls are made sequentially.

To run these calls – which are promises – in parallel, one can reside to using Promise.all. Combine that with destructuring and the code becomes this:

Easy, right?

💻 The example embedded in this post is part of a talk on ESNext named “What’s next
 for JavaScript?”, which I recently gave at a Fronteers België meetup and Frontend United 2018 (Utrecht). You can check out the slides / a recording of that talk right here. I’m available for bringing this talk at your meetup/conference.

Elsewhere , , Leave a comment

Resilient, Declarative, Contextual

I enjoyed reading this piece by Keith J. Grant on three key characteristics of CSS that set it apart from conventional programming languages.

I want to look at three key characteristics of CSS that set it apart from conventional programming languages: it’s resilient; it’s declarative; and it’s contextual. Understanding these aspects of the language, I think, is key to becoming proficient in CSS.

Resilient, Declarative, Contextual →

Elsewhere , Leave a comment

A JavaScript Typing Carousel

I like this JS typewriter effect:

The HTML that goes along with that is really simple:

<h1>This pen is
  <span
     class="txt-rotate"
     data-period="2000"
     data-rotate='[ "nerdy.", "simple.", "pure JS.", "pretty.", "fun!" ]'></span>
</h1>

Simple Typing Carousel →

Elsewhere , , , Leave a comment

Harry Roberts: FaCSSt – CSS and Performance

A Frontend United I was lucky to see Harry Roberts give this talk on CSS and Performance. You can watch it to, as the recording has been published to YouTube

Ahh… CSS and performance. Two of my favourite things! But how well do they play together? It depends…

In this very matter-of-fact talk, we’ll be looking at all of the different ways CSS can make our websites faster or slower. From the common and perhaps more obvious, to the unusual and obscure ways in which CSS can impact performance for better or worse.

Great content. And great to see that I’m not the only one mentioning the answer to life, the universe, web development and usability from time to time.

Sidenote: A recording of my talk “What’s next for JavaScript” at Frontend United is also available. Always confronting to see yourself speak … learnt a lot from watching that.

Elsewhere , , Leave a comment

How CSS works: Parsing and painting CSS in the critical rendering path

Insightful post by the folks over at LogRocket on the rendering pipeline:

If your site takes forever to load, chances are your users aren’t gonna wait for it to finish, even if there’s valuable content to be found there. Some studies have shown that up to 50% of users leave a page after 3 seconds of waiting.

With users expecting those types of load times, it’s our responsibility as web developers to not bloat the amount of stuff we’re sending to the user. Sadly, CSS is often the culprit of increased load times, so having a nuanced understanding of how the CSS you send is transformed into beautiful pixels will help you optimize that crucial seconds where users are most likely to bounce.

How CSS works: Parsing & painting CSS in the critical rendering path →

Elsewhere , , , Leave a comment

Implementing Web Push Notifications

Alexander Zlatkov from SessionStack on how to implement Web Push Notifications:

There are three general steps to implementing a push:

  1. The UI — adding the necessary client-side logic to subscribe a user to a push. This is the JavaScript logic that your web app UI needs in order to enable the user to register himself to push messages.
  2. Sending the push message — implementing the API call on your server that triggers a push message to the user’s device.
  3. Receiving the push message — handling the push message once it arrives in the browser.

How JavaScript works: the mechanics of Web Push Notifications →

Elsewhere , , , Leave a comment

yett – A small webpage library to control the execution of (third party) scripts like analytics

In order to provide GDPR compliant consent-first-analytics (and other stuff), you can use yett:

Blocking execution of analytics script (until consent is given) can be done manually, but the problem is that analytics providers often provide minified code embeds that you have to include in your html as they are. If you want to exercise control over their execution, then you have to tamper with this minified JS yourself, which is complex and does not scale well if you load server 3rd party scripts.

Thus we invented yett. Just drop in the script and define a domain blacklist – yett will take care of the rest ✨.

Uses MutationObserver under the hood, thus is compatible with even IE11.

Beware though, as this might conflict with applications that rely heavily on document.createElement (like React):

This library monkey patches document.createElement. No way around this.

yett – Control the execution of (third party) scripts like analytics →

Elsewhere , , , Leave a comment

Tips for improving performance of React Native apps

Whilst researching a performance issue in a React Native app by doing a deep dive into the bridge, I stumbled upon this nice list of tips by jamsch.

The list – which touches react-navigation, the types of lists one can use, etc. – was originally posted as a comment on a Github Issue, but deserves way more attention, as it’s great for developers new to RN, who haven’t had to learn this stuff the hard way (yet).

  1. Try to use React Native’s FlatList/SectionList/VirtualizedList where you can and not array.map() as it allows for asynchronous rendering of components in your viewport which is important for mobile devices.
  2. With the nature of React, any component that has updates to it’s state/props will re-render all of it’s child components, and likely the children of those components as well. It’s up to you to make sure that your components should update or not by using shouldComponentUpdate or changing the components to a PureComponent. There’s often times where you don’t even know that components are re-rendering when they shouldn’t be. Start by checking the app root component and going down from there.
  3. React Navigation will typically have any screen you have in your navigation state rendered. State-heavy screens may suffer in performance especially when there’s background state updates. It’s also easy to add more routes to your navigation state and more difficult to take them off.
  4. Make sure that the screen you’re trying to navigate to isn’t heavy on it’s initial render. Your components should preferably be light on the first render and accumulate with data later from interaction and server responses. react-navigation will only transition to the screen once it’s typically fully rendered. One thing that could help is configuring initialNumToRender on your FlatList/SectionList component. Otherwise this may take seconds to render new screens using react-navigation.
  5. The renderItem function should render stateless list item components. If it needs state context (e.g. whether the list item is expanded or selected), it should be using the parent’s state as seen in the documentation.
  6. Unusual things may start happening if you render more than one FlatList/SectionList/VirtualizedList in one component (e.g. rendering only the current render batch and no more).
  7. Avoid wrapping your FlatList inside a ScrollView, as it will render all child components. FlatLists implement on top of ScrollViews so you can use most ScrollView props on FlatLists.
  8. Develop Android-first. iOS performance is guaranteed and you will notice performance issues sooner before having to rebuild much of your code base. React-Native was built first with iOS-only support.
  9. Using remote debugging will execute JavaScript on the host computer and not on the phone, and instead use the RN bridge to send native calls to the phone. This will likely be very slow in some situations and very fast in others. Try building the app with the release variant — react-native run android --variant=release so you can get a more accurate feel of the app’s performance.
  10. Remove any console.log() statements from your app when releasing it to production with babel-plugin-transform-remove-console.
  11. Generally as a guideline, the less JavaScript and more native code, the better performance you’ll get. React Native allows us to build user interfaces with great productivity and a shared code base but there may be times that you’ll need to go native on both platforms to get better performance.

react-navigation is a not very performant library especially for Android. It solely uses React Native’s library as a basis for all it’s navigation logic which means any additional screens/views are all loaded on to the one activity/viewcontroller which gives ‘native-like’ navigation but not true navigation. If you went to inspect the app on iOS while the app was running you’d see that the screens in your navigation state are essentially rendered and layered on top of each other. react-native-navigation (v1) is a suitable alternative if you’d rather want to use the native navigation controllers.

/me nods along

Elsewhere , Leave a comment

RE: The React is “just” JavaScript Myth

🗣 This was originally posted as a reply over at Dave’s blog. Unfortunately Disqus – the commenting system Dave uses – thinks it’s spam, so I’m posting it here as a full post instead.

In his blogpost The React is “just” JavaScript Myth, Dave Rupert said this:

React shows up on the scene with Babel, Webpack, and JSX (which each have their own learning curve) then quickly branches out into technologies like Redux, React-Router, Immutable.js, Axios, Jest, Next.js, Create-React-App, GraphQL, and whatever weird plugin you need for your app.

As a JavaScript developer (who happens to be writing mostly React (Native) these days) I’d like to counter that though …

Babel + Webpack + JSX: Yes, those are the basics. To run a train you need a locomotive, tracks, and a power source.

Although … thanks to things like create-react-app (CRA) you can start coding out-of-the-box as it has a babel-webpack thing set up for you. Even though highly interesting you don’t really need to know the inner workings of Babel nor Webpack when starting out with React.

As for JSX: JSX syntax essentially compiles down to functions. You don’t really need JSX, but if you wouldn’t use it your code would grow exponentially (<b> vs. React.createElement('b', { children, … })). If you know HTML, JSX can be learnt quite easily.

As for the rest of the things Dave mentions: these are not mandatory. Don’t let this list of fast- and ever-changing technologies overwhelm you, as you can easily create a React app without ‘m:

  • Redux — Even the author of Redux himself says you might not need it. (It is nice to work with though ;-))
  • React-Router — You can perfectly use different pages if you want. Additionally you don’t need a router when refactoring one or two components from your site to React implementations.
  • Immutable.js — I’ve written quite a lot of React apps by now and have used it only once so far.
  • Axios — You can use ES’ built-in fetch instead. No need to learn another library 🙂
  • Jest — Only if you want to write tests
  • Next.js – Never used it
  • CRA – Never used it.
  • GraphQL – Never used it (but I am really interested in it).

Of course, as your code and knowledge evolves, you most likely will start using one / a few / all of those 😉

~

The one thing Dave hasn’t mentioned (by name) in his post is ES2015. To me that was the biggest hurdle to take when starting out with React.

Reading Dave’s post I think his – and many others’ – gripe with React comes from exactly this. It’s easy to confuse React-specifics with ES2015-specifics since React uses a lot of the new ES language features.

Take Array.prototype.map for example (which Dave mentions): that’s an ES feature and has nothing to do with React itself. There’s even an article dedicated to this distinction: “Learning React: Is This ES6 or React?”

Once one embraces these new ES features – which I have a full presentation about – and uses ‘m more often one will start loving them … I know I have 🙂

To start with React, learning ES2015 is essential. Sprinkle some JSX on top and you’re good to go. It’s ES2015 that’s the hardest part to learn. React itself builds on top of these language features. So yes, React indeed is “just JavaScript”.

👋 This post also got published on Medium. If you like it, please give it some love a clap over there.

Original Content , , Leave a comment