Pairs web library selection history

This is 11th entry in Eureka Advent Calendar 2020.

Actually we renew our code base of Pairs for web browser since two year ago.
Then we made notes for the result and its reason of library and technology selection.

In this entry I want to review those notes by self and let you know what we like.

A quoted markdown is the notes, and I put current comment after that.

PRPL

Push

Not picked.

- http2 is 180 degrees opposite to assets separation.
— want to study

This note is in 2018, and then we didn’t have enough time to study and consider it.
So we considered css sprite based on the premise of using http/1.1, nonetheless, in the result we don’t use css sprite.

Render(SSR)

- To getting on performance
- Preparing architecture got complicated

Actually SSR implementation is complicated but architecture didn’t get complicated in whole.

Precache

- :white_check_mark: Workbox
— work offline
— looks difficult to use it with akamai because cache wasn’t hit if url has query
— we convert image size dinamically with using ‘with’ param of query
— Detail of cache storategy is not dicided
— Modify workbox setting because default setting blocked loading resources to render landing page

Because we already used Workbox at that time, we didn’t consider others.

Lazyload

- :white_check_mark: js
— Webpack4 chunk splitting (dynamic import)
— didn’t investigate others
— component dynamic loading
— :white_check_mark: [loadable-components](https://github.com/gregberge/loadable-components)
— moved from react-loadable because it looks not to be maintained
— believing hiroppy’s [this entry](https://blog.hiroppy.me/entry/loadable-components)
— it is little tricky that it support only default export
— [react-loadable](https://github.com/jamiebuilds/react-loadable)
— picked -> not picked
— found at 1st
— it declare timing and position to write dynamic import
— in the result Reducers will be loaded at the same time
— [react-universal-component](https://github.com/faceyspacey/react-universal-component)
— not picked
— found later

It can be read to do lazy loading of Reducer. Finally, we don’t do that because the reason why its system was quite complicated and we employed the budget for each bundle size.

- css
— :white_check_mark: css in js = load css as javascript bundle
— moved from css modules
— css modules (css-loader)
— picked -> not
— using css-loader with webpack

We used css-loader at first.
Details are in css library section.

linter/formatter

- prettier
— :white_check_mark: based on the default
- javascript linter
— :white_check_mark: eslint
— moved from tslint
— tslint is no more supported
— tslint
— picked -> not
— stop support
— tslint-microsoft-contrib
- stylelint
— :white_check_mark: stylelint-config-sass-guidelines
— not required after moving to emotion perfectly

We are using eslint based on presets and sometimes adjust rules with comment of the reason why we must make it loose or adjust it.

Language

js

- :white_check_mark: typescript
— we have been using it
— don’t consider es and flow
— ~ interact badly with some of babel plugins~ tslint got parsable by babel

Do you need other comments? Typescript won.
It was very very very good news that ts can be parsed by Babel.

css

- :white_check_mark: [emotion](https://github.com/emotion-js/emotion)
— moved from css-loader
- styled-components
— not picked
— many stars
— https://risingstars.js.org/2017/ja/#section-css-in-js
— it’s very good not to consider class names
— it looks work
— is this considered collectlly?
- css modules
— picked -> not
— css-loader will stop supporting
- sass
— not picked
— nest syntax is not so important
— other good features could be used by postcss plugins
- postcss + plugin

We should have used css-in-js from the beginning.
Using many webpack loaders makes module updating delay for example in the case of storybook we should wait for updating dependencies to use same webpack config.
To treat as javascript is very useful for many cases.

View library

- :white_check_mark: React
— we have experiencer
— want to use
— html with logic is good
— `onClick={this.handleClick}`
— hooks was implemented
— so nice
- vue.js
— not picked
— pairs global uses it
— feel limit of the way to separate html and logic
— no more…

Lol, it looks heavy bias by lovers of React.
Did Single File Component exists in Vue2 at that time? Pairs Engage, its admin tool and Pairs admin tool use Vue, right?

If we choose now, was decision changed?

¯\_(ヅ)_/¯

I love react.

Miscellaneous

There are many notes for others that I can’t compile in thi entry.

Totally

There are some libraries which was changed many times. Storybook is one of them. Because we stopped using css-loader, finally we can use it stably.
Jest, puppeteer and cypress also are the same. We were trying them to find good cost performance.
Unfortunately we don’t often decide them with clear logic but keep considering and trying libraries to improve maintainability, sustainability and DX.