Building AMP website with Parcel

I have recently updated my personal website to use AMP framework. After I finished the transformation and started optimizing it, one of the main warnings I was getting from the audit tool in Chrome was about my assets not being minified.

I didn’t want to use popular tools like Webpack or Gulp since it would be a waste of time to configure them for such a small project. That is why I decided to use Parcel which works out of the box without any configuration.

However, Parcel runs a lot of tools under the hood that do not only remove whitespace characters but also change the actual code. This is not really desirable since an AMP website is not valid unless AMP CSS boilerplate is present without any modifications (except for whitespace characters). And invalid AMP websites are not cached in Google search results so you lose the main benefit of AMP.

Parcel uses htmlnano to minify HTML files. To prevent unwanted changes in HTML attributes, you need to create .htmlnanorc file in the root folder of your project with the following content:

{
  "collapseBooleanAttributes": {
      "amphtml": true
  }
}

And since htmlnano uses cssnano to minify the content of <style> tags, some CSS rules are also modified. In order to avoid this, create cssnano.config.js file with the following content:

module.exports = {
  preset: [
    'default',
    {
      minifySelectors: false,
      normalizeTimingFunctions: false
    }
  ]
};

If you now build your website with Parcel and run the AMP Validator, there will no longer be an error saying that AMP CSS boilerplate is missing.

Managing complexity of Angular applications

Let’s say you are a newcomer to modern front-end development and you need to implement a single page application. You already know HTML, CSS, and some JavaScript. You have heard that Angular is a solid framework and you like the fact that it is based on OOP principles you are familiar with. So you start learning it by taking an online course teaching its basics while at the same time reading the official documentation in order to explore various building blocks in more detail.

After a while, you feel quite comfortable using the framework and you decide to start building your application. Since you are a newbie in this area, you try to follow Angular Style Guide to avoid bad architectural decisions right at the beginning. You build small reusable components and fetch data from the API in singleton services as you have been taught. You are making a good progress, creating a lot of components and seeing the first results on a few screens of a really nice user interface you have already built.

But you feel that something is fundamentally wrong with your application. It is still quite small but there is already a huge complexity when it comes to interactions between components and data management. You have figured out how to avoid redundant API calls by remembering the data needed by multiple components but your adhoc solution seems to be a little bit messy and error-prone. You need to be very careful not to introduce a bug when extending some functionality. It is already such a pain developing this application and you cannot image how it will look like if it grows ten times or more.

The problem is that neither the online course nor the official documentation has taught you how to manage the application state. They have only introduced various Angular concepts such as services which they recommend for data sharing between components. But once your application starts growing, using services to manage its state is a way to hell.

Fortunately, there is a whole set of state management libraries that try to solve this problem. The most popular is Redux which is mostly used by React developers although it can be used with Angular as well. There are also some libraries designed especially for Angular such as NgRxNGXS, or Akita which are based on RxJS so you can keep using observables that you are already familiar with. I would recommend using NgRx as it is the most popular one among Angular developers. But feel free to try out more of them and choose the one that best fits your use cases.

I am not going to explain the concepts of FLUX architecture these libraries are based on as many others have already covered this topic quite well. What I wanted you to know is that you have encountered a common problem in front-end development that have already been solved by people much smarter than you (no offense). So there is no need to implement your own solution or hack your application until it becomes unmaintainable. Using a robust state management solution is the only way forward if your application is going to grow significantly.