Modernize frontend UI stack

[Grsmto]

Hey guys, Here are some notes about the current frontend stack (purely UI-wise). This is for me and also to discuss and see what you think.

Currently the UI is based on Carbon Design System. Very similar to Bootstrap or Material UI, this had the advantage of making the UI development very quick. Also it's a design system so it proposes useful classes to have a consistent UI (spacing, font-sizes etc.) that we are not using at the moment and the website hasn't been build with them unfortunately.

But it comes with cons:

• UI look is tighten to Carbon look: another app could look very similar to Polymath if they use the same framework.
• It's not just a component library: it comes with global styles as well that need to be overridden if unneeded.
• It's hard to maintain, as if you update to fix a bug in one component, you might end up with breaking changes on other parts that you don't want (it happened to us).
• Sass + BEM: these are great but there are easier and more powerful solutions.
• No code-split: if you use 1 component or 10, they will all come bundled in your app anyway (I think this is fixed in latest version).

For applications like ours, a more modern CSS architecture would bring the following improvements:

• Design system: predefined spacing, font-size, colors, ... according to the design to warranty UI consistency. Carbon provides this already.
• Themeable: you can change the design system easily so it fits your design. Carbon provides this via Sass variables.
• Theme can be accessed by React components: you often have to hardcode media queries or size of components in the JS because you can't access Sass variables from the JS.
• Atomic CSS: you compose a component from other predefined classes. You shouldn't have to write CSS but just "compose" your UI from predefined components/classes. No magic numbers, no inconsistencies, cleaner UI.
• Primitive components: define a few core components and build the others by composition. Ideally you should be able to build a basic layout/page component without writing CSS and just by using primitives.
• Performances: CSS can be split in chunks for performances. Initial landing page loads only the necessary CSS.

Solution 1: stay with Sass + BEM

pros:

• variables, nesting, mixins
• scoping via BEM
• we keep a single technology

cons:

• Variables not shared in JS (so values like media queries etc. have to be hardcoded)
• BEM can be tedious/messy
• Can't be code-split
• Starts to get old

Solution 2: CSS-in-JS

pros:

• All the power of JS (variables available everywhere)
• Auto scoping
• Code-split
• Hype

cons:

• New stack, so we will deal with both Sass code and CSS-in-JS at the same time until we deprecated the Sass entirely
• Slower than raw CSS: as the CSS is in the JS and is processed at render time, it's slower than static precompiled CSS.

Patterns

• Constraint design: we encourage the user to follow the design system. Spacing, font-size, from the theme are easy to use and there is no need for magic numbers.
• Single element: our React components should be easy to reuse and extend. We don't stack the custom props as this doesn't scale well (we can end up with loads of business logic if/else in components that try to handle every scenarios).

Some resources to achieve this:

• Styled Components or Emotion
• Rebass a UI framework based on primitives and on Styled-System
• Reakit UI framework similar to Rebass

[RafaelVidaurre]

First of all: Great work, thanks for putting together this document, this is something that has been worrying me for a while. I agree with what you wrote down about how the architecture should be like.

I'd definitely go for solution 2. About what library to use I've used StyledComponents many times before and I like it a lot, but I know Emotion is pretty popular nowadays, so maybe it is worth considering the differences before making a decision (we probably won't be able to look back once we pick one).

About performance, I don't think this is really an issue, we can also precompile most of the styles to css in build time I believe, right?

[RafaelVidaurre]

What I'd suggest, is to do the refactor without any ties to the legacy code, and slowly start moving our deprecated components to the new ones. That way we are not limited to previous architectural decisions, this will heavily influence how the dApp will end up looking like in the future, so lets treat this as a definitive change

[RafaelVidaurre]

@monitz87 comments?

[Grsmto]

Update

tooling

I have been experimenting with both Reakit, Styled-System and I recently discovered Smooth UI to see what fits best. All 3 are "primitives based" React UI frameworks. It means that you don't actually need to use the built in components. You just use the primitives and build your own custom components on top. Great thing with this pattern is that every components are based on a single root Box component. So the frameworks are not leaving a huge footprint on the codebase (pretty much just the Box.js component). I think this is primordial for maintenance as it would let us swap/upgrade easily to another framework more easily if needed.

Styled-Components vs Emotion

The main difference between the two is performances: Emotion was faster. The APIs are really similar. But apparently since SC v4, the performances are now pretty much the same and everybody seems to go back to SC now.

Background experience

For the record, I have been using a similar pattern on a previous project. It was fully custom code (using Tailwind CSS + custom props mapping to class names functions). It was quite complex and not well documented, so not best for maintenance. However the pattern itself was awesome and extremely powerful. We ended up to a point where building new pages was just importing primitive components, no css to write at all, and everything was consistent and nicely layout-ed.