Thinking Software

Read this first

Adaptive Design Systems

White Labeling, Rebranding, and re-UXing web applications

Changing requirements, fast deployments, large-scale applications, rapid changes… These words describe the modern web application’s / saas’ lifecycle.

TLDR;
Enterprise-size front-end. A tech giant buys our company and requires rebranding the application to be aligned with the rest of the corporates style guide.

TLDR.2;
Our product (or service) is purchased by one or more companies. They have requirements for changing the look and feel of the UI. We are now in a need to deploy the same application with different flavors.

Creating a design system that is both clear and flexible is not an easy task, but after a few successful implementations of such systems, I would like to share the knowledge and lessons learned from this experience.

The ingredients of an adaptive design system

Let’s define some terms first

Design system

A...

Continue reading →


Micro frontends, in practice

“Microfrontends” is a hot topic nowadays. Since front-end projects become big and feature-rich, as the codebase gets bigger, tooling and organization are essential for a successful project.

I would rather think of micro-frontends in terms of “polyglot front-ends”. Javascript ecosystem is growing fast, and every year or two we encounter new libraries, tools, and frameworks. Migrating or rewriting everything from the grounds up to the new stack seems impossible.

As our application grows, it becomes harder to keep up the pace.

Polyglot front-ends approach enables us to keep existing modules intact, written in their stack. The polyglot front-end approach let us run one application written in several technologies, every module has its build chain and tools, and even developed by different teams.

In the last year, I have managed to successfully implement a production-grade polyglot...

Continue reading →


Never BEM Again

During my career I have found BEM annoying.
You may ask why, as BEM is considered a good practice for handling styles and overrides.

For those who do not know what BEM is, the tldr description is BLOCK-ELEMENT-MODIFIER. For example, when using a CSS framework, your element would look like this

<button class="btn">This is a framework-designed button</button>
<button class="btn submit-btn">This would be a generic submit button modified by the design team of the product</button>
<button class="btn submit-btn large">This is our generic submit button, with modified size for a specific purpose</button>

Back to the reasons I dropped BEM.
Using classes for styling is somewhat easy and a good practice, but there is a better option with the result of less markup, more readable CSS files, making SASS/SCSS redundant and as a bonus it provides easy access for automated E2E tests.

I don’t have a...

Continue reading →


Being a “naked” web developer

Using modern web standards, we can add new features/powers into the browser in a snap. No React, No Angular, No Nothing. Is this too good to be true? Can it be that we are actually at the point where all the shiny component frameworks are disposable? Can we all be freed from the framework fatigue?

js_framework_timeline.png

Probably not (yet)

customElements.define('my-tag', MyCustomHTMLTag);

I was playing around with the idea that front-end developers can drop React or Vue.js in favour of new standard APIs implemented in all evergreen browsers (and soon even in that brownish-green one). I am a real web components fan, and a very lucky one, that actually works on a production web-application that is written completely with web components, zero bundlers, zero external tools whilst high performance is the top priority for all features. About 90% of the codebase is in-house built with javascript, relying...

Continue reading →


Software enginnering movie posters

the-legacy.png
environemnt-staging.png
the-code-conflict.png
the-ternrary-operator.pngcomponent-split.png
the-hook.png

View →