When thinking about developing an iOS mobile application the key decision is deciding on either native or hybrid development. Both have their advantages and disadvantages and the correct choice comes down to doing some research and contrasting it with your goals. For hybrid development the tool of choice is Facebook’s React Native and for native you’d probably go with Apple’s dedicated language Swift. Obviously that’s only the basics and the choice isn't as simple as that.

## A Swift successor

Swift is meant to be a successor to Objective-C, the programming language Apple had been using for decades. It had become a little bit obsolete or to put it mildly lacking in modern functionalities, as it was created in the 1980s. Swift was introduced at the Worldwide Developers Conference in 2014 as the dedicated way for developing iOS applications and has received a lot of substantial updates since then. A number of very popular applications like Twitter, SlideShare and Airbnb have been developed using Swift, and it's more than likely a lot more will be in the near future.

## Hybrid app development = React Native

React Native is a JavaScript framework, created by Facebook for developing cross platform applications. It has also been used to develop a number of very popular apps like SoundCloud, Instagram and obviously Facebook’s application. The main idea was to let developers write code and create applications for both iOS and Android while the UI elements get rendered in the native version for each platform. This ensures the development process is significantly faster than having a separate dev team for each platform, while still providing the user with experience that feels native to the particular platform.

## Swift vs React Native for iOS

Obviously the big advantage with hybrid development is using one codebase for creating an app for both platforms. Android holds a large share of the market so even when going for only an iOS app it’s good to keep your options open for the future. That said, React Native holds a number of key advantages even when considering just iOS app development. In the broadest sense the choice should be focused on the aims of the particular project and prioritizing one aspect of it over another. Obviously the choice is much more complex than just focusing on speeding up development as much as possible and it’s worth it to do a deeper dive into the key differences:

* **UI**: With Swift devs can take advantage of SwiftUI and create interfaces tailored to iOS from scratch. React Native, on the other hand, uses JavaScript libraries to build user interfaces. That provides a lot of advantages like helpful third party tools, libraries and a number of reusable UI components, which makes creating a native-like UI for both platforms much easier.
* **Coding speed**: While Swift definitely has improved on Objective C and creating an iOS app with its help is much faster, React Native still has it beat. JavaScript has been the most popular programming language for a long while now, and for good reason. The community, number of tools and solutions is absolutely massive and will make creating a codebase a lot simpler even for new developers.
* **Learning**: Apple has done its due diligence with the documentation and has provided ample help as well as a playground environment. Still it is almost impossible to beat JavaScript in this regard as almost anything you want to know is just a google search away. With time this gap may become smaller with time, so far the more established language simply has so many more tools, tutorials and developers it’s hardly comparable.
* **Performance**: Obviously performance can be dependent on a variety of factors such as individual setup or the size and complexity of the application. That said, React Native takes advantage of native code optimizations and tools which can have a large impact regardless of the other factors.
* **Stability**: The one area where Swift has React Native beat is application stability. The fact that it is designed for a particular platform and uses type safety means errors are easier to spot and the performance and stability is optimized with iOS in mind. The hybrid approach and focusing on faster development has its drawbacks here when contrasted with one dedicated to a single platform. Although obviously we’re just talking out of the box here as various platform specific libraries and development tools can vastly help React Native in this regard.

## Why not both?

In general the JavaScript community is so much older and larger it is a tremendous asset. Whatever the project you can be pretty sure it will beat out Swift in terms of developer availability, cost, time, community support and available third party libraries. That said, the Swift environment is growing dynamically and if you’re looking to make an iOS app that’s tailored to the platform and uses all its functionalities without any issues, it might edge out React Native. For the usual cases where the biggest factors are time and cost React Native is still probably the best choice. One last point is that if you’re just starting out as a developer it would be good to learn both, as the learning curve is not that steep for either, and you’ll be available for jobs in both and that can be a major asset especially going forward.

A brief look at the advanatges of Swift and React Native

Swift or React Native; what's better for developing iOS apps

React 19 is not in the RC or Release Candidate Stage and while things might still change between now and release one particular new feature has generated a lot of buzz among developers and SEO experts - namely the `head` changes. While it is a feature aimed at making things easier there has been a lot of talk about potential issues it may cause. Is that warranted?

## The basics

If you're not that into SEO stuff the `<head>` is a html tag at the top of the page where you put most of the SEO stuff like page title, meta tags, links, canonical and scripts like schema.org and google tag or analytics. If you put any of that anywhere outside the `<head>` tag, like in the body of the page it wouldn't work. As such the usual application would be to have a helmet component which puts all the relevant SEO stuff in our pages.

## Where's your head at?

From my experience with React projects we usually used a custom helmet component that was then included in the layout component and had a few simple props you needed to input for each page (title, meta description and canonical) and all the other SEO stuff would be handled by the custom helmet component.

Other typical use cases were using the Next head component provided natively by Next and inputting the SEO stuff directly there per page:

```ts
import Head from "next/head";

function IndexPage() {
  return (
    <div>
      <Head>
        <title>My page title</title>
        <meta property="og:title" content="My page title" key="title" />
      </Head>
      <Head>
        <meta property="og:title" content="My new title" key="title" />
      </Head>
      <p>Hello world!</p>
    </div>
  );
}

export default IndexPage;
```

Next also had native support for metadata:

```ts
import type { Metadata } from "next";

export const metadata: Metadata = {
  title: "...",
  description: "...",
};

export default function Page() {}
```

For projects that didnt use Next there was the popular react helmet library (https://github.com/nfl/react-helmet) which basically did the same thing:

```ts
import React from "react";
import { Helmet } from "react-helmet";

class Application extends React.Component {
  render() {
    return (
      <div className="application">
        <Helmet>
          <meta charSet="utf-8" />
          <title>My Title</title>
          <link rel="canonical" href="http://mysite.com/example" />
        </Helmet>
        ...
      </div>
    );
  }
}
```

## React-helmet Custom approach

I never really used Next's native Head or Metada for a simple reason - it forced you to do it per page, which works for basic SEO like title and metadescription, but not much beyond that. For example for [graphqleditor.com](https://graphqleditor.com/) my customHelmet component which handles stuff like: truncating too long titles and metadescriptions, schema.org, link canonicals and alternates, og tags, google tag, posthog, fb pixel and whatever else has around 150 lines of code. Obviously sticking that code in every single page makes no sense, but splitting it up and using Next head or metadata for just titles and a customHelmet or react-helmet for the rest makes no sense either when instead I can keep all the SEO related stuff in once place. This way if anything goes wrong (which with SEO happens quite often) I'll need to look in just one component instead of in all the pages.

## What are they actually changing?

As laid out in their [blog post](https://react.dev/blog/2024/04/25/react-19#whats-new-in-react-19) React 19 will natively support meta tags wherever you'll put them so you can just do `<title>my title</title>` wherever in the page component or any child component and React will put that into the `<head>` tag automatically. As they hint in their post this is meant to replace outside sources like react-helmet and next-head with native built in support.

```ts
export const BlogPost = () => {
  return (
    <article>
      <h1>{title}</h1>
      <title>{title}</title>
      <meta name="description" content="a blogpost about bla blah blah..." />
      <p>Lorem ipsum...</p>
    </article>
  );
};
```

## Issues

So what's the big problem? While this is nice and makes sense for one-off usage I'm immediately sceptic about two things:

* inserting tags per page instead of doing it in one place via a helmet component
* possible tag duplication

As mentioned before keeping all the SEO related stuff in one place via a helmet component is easier and more clear to a dev or seo technician than spreading it out over each page component. Lets say I have an e-commerce shop with a custom helmet I can do something like this:

```ts
let title = shopData.pageTitle || fallbackTitle;
if (product && variant) {
  title = `${product.name} ${product.variant} | ${shopName}`;
}
if (collection) {
  title = `${collection.name} | ${shopName}`;
}
if (blogPost) {
  title = `${post.title} by ${post.author}`;
}
if (title.length > 60) {
  title = title.slice(0, -3) + "...";
}
```

This way I can handle titles for pages, blogs, product and collections - all in one place and have a fallback in case there is none provided as well as truncate them to fit googles 60 character limit. Using the native solution I would have to do that in each page component and as mentioned before I'm doing a bunch of other stuff in the helmet component I would also have to replicate.

## Duped tags

Additionally the automatic rendering of every `<title>` regardless of where it is can easily lead to tag duplications. Lets say some junior dev adds a new page with a `<title>` tag because he doesn't know that we're already using react-helmet in the page layout component. This will now result in two titles in the head, with no clear indication of which one will actually be rendered. I for one am looking forward to searching for some title tag nested in some small component somewhere in the page (and I really when using Styled Components a `<Title>` doesn't get treated the same way)

## Not for me

While the new approach makes sense for basic usecases and will be appreciated by those who don't want to bother with SEO too much and just want their page titles and meta-descriptions I will definitely stick to using a custom helmet component to keep all my SEO stuff in one place instead of scattering it across all the pages. The possible pitfall with title duplication has some people a lot more worried (especially in regards to streaming html) but that will probably get fixed with how much attention it got from people online. Aside from that I doubt React Helmet will become less popular since (as of now at least) it still is a more efficient and easy to use approach which provides a bunch of additional seo related stuff out of the box aside from the basics. But if React continues adding more and more native feature support who knows?

React 19 SEO issues - what exactly is changing, will it be a problem, and why has it caused quite a stir in the community.

React 19 SEO issues - a scare or worth looking into?

Once we’ve wrapped our heads around the psychological side of estimation and set up the right technical foundation, it’s time to move on to one of the key concepts in IT project estimation – **the difficulty scale**. This scale makes it much easier for developers, project managers, and clients to quickly gauge how complex a given task really is and get a rough idea of how long it might take. On top of that, difficulty scales let us track team velocity, which in turn helps make future estimates more accurate. In practice, there are plenty of abstract units used to measure task difficulty – and each team usually picks the one that works best for them.

*Why, then, do we use abstract units instead of hours?*

Estimating in hours creates the illusion that we know exactly how long a task will take. It’s a false sense of precision that ignores context, unexpected problems, or cross-platform differences. On top of that, every developer has a different pace — what takes one person 2 hours might take another 6. The real problem is that hourly estimates easily turn into promises to the business side. If we say something will take 3 to 5 hours, a client might expect results after just 2.5. That kind of mismatch quickly damages trust and strains the relationship between developers and stakeholders, since such estimates are often inaccurate. From a Project Manager’s perspective, hourly estimates also complicate sprint planning and roadmapping, because they fail to capture the relative difficulty of tasks.

*Along the way, you might also come across the terms absolute and relative task complexity.   Absolute complexity is simply a time-based estimate — “This will take 2 hours.”*
*Relative complexity, on the other hand, uses abstract units (like Story Points), which lets us say, “This task is roughly twice as difficult as that one.”
Research shows that teams reach consensus faster when comparing tasks relatively (“Is this more like a login, or more like implementing payments?”). As a result, the estimates become more stable and less affected by individual differences.*

With that explained, let’s move on to the most commonly used difficulty scale.

## 1. Story Points

**Story Points** are one of the key elements of the SCRUM methodology.
They are abstract units of measure used to estimate work, taking into account both the complexity and the effort required to complete a user story. Thanks to Story Points:

* We can compare the **relative difficulty of tasks** - for example, a 2 SP task is roughly twice as challenging as a 1 SP task.,
* We avoid estimating in hours, which allows us to focus on the **relative comparison of tasks** instead,
* The estimate covers not just time, but also **technical complexity, risk, and uncertainty.**

Another major advantage of using Story Points is the ability to measure **team velocity**, which makes sprint planning and forecasting delivered value much easier.

**Fibonacci numbers are most commonly used to assign Story Points** (1, 2, 3, 5, 8, 13…). This is because it’s easier for a team to decide whether a task deserves 8 SP or just 5 SP, rather than precisely comparing, say, 6 SP to 5 SP - a way to limit **the illusion of precision**. The increasing values in the Fibonacci sequence also reflect the fact that the larger a task is, the more uncertainty there is, making it harder to estimate its exact complexity. In small teams, using this approach also sparks useful discussions, such as: “Why did you assign 8 SP to this task? I think 3 SP would be enough.”

*How do Story Points reflect uncertainty?*

Small tasks, usually rated 1-3 SP, are relatively predictable, with low risk. Medium tasks, rated 5-8 SP, come with some unknowns - they might involve integrations, cross-platform differences, or require extra analysis. Large tasks, 13 SP and above, carry high uncertainty; they need deeper analysis and discussion, and sometimes must be broken down into smaller pieces to be estimated reliably.

## 2. Alternative Methods for Assessing Task Difficulty

### 2.1 Linear 1–6 Scale

In the beginning, teams often start with a **linear scale** to make it easier to get going, and later move on to Story Points and the Fibonacci sequence. In this method, the team uses simple values: 1, 2, 3, 4, 5, 6, where:

* 1 represents a very small and simple task,
* 6 represents a very large, difficult, and risky task.

The advantage of the linear scale is its low entry barrier for newcomers - it’s just easy to understand. Explaining it to a client is also straightforward: “6 is the hardest task, 1 is the easiest.” Additionally, for us - Poles - it feels natural because it resembles the school grading scale.

Unfortunately, the linear scale carries a strong **illusion of precision** and doesn’t highlight uncertainty for larger tasks as well. By contrast, the Fibonacci sequence shows a clear jump between a 3 SP task and a 13 SP task, naturally encouraging breaking down bigger tasks into smaller pieces. The linear scale also often leads to over-“mathematization” of estimates and disputes over details - developers find it easier to argue whether a task should be 5 SP or 8 SP than whether it should be 3 or 4 SP.

### 2.2 T-shirt sizes

Another easy-to-grasp scale is the **t-shirt size scale**: XS, S, M, L, XL (sometimes XXL). Each size corresponds to relative complexity and effort, without using numbers.

This scale is very intuitive, as everyone naturally understands the difference between an S and an XL, making it easy to introduce to both new and experienced teams. It avoids the **illusion of precision** because it doesn’t rely on numbers - but that’s also it’s biggest drawback. Without numbers, it’s harder to measure **team velocity**, and the sizes themselves are **less precise** for sprint planning.

It’s great for comparing and prioritizing tasks, but it’s harder to build a concrete sprint plan around it.

## 3. Story Points for React Native – Examples

### 1-2 SP: Simple changes

* changing text,
* changing text color,
* minor style tweaks (e.g., increasing `paddingHorizontal` on a screen),
* adding/replacing an icon on an existing button,
* swapping the endpoint in an existing API call.

### 3–5 SP: Standard features

* a new screen with a basic form and validation (e.g., your pet’s data)
* a screen with a list of available guests fetched from an API, including basic loading/error states
* adding local storage (AsyncStorage, MMKV) for basic data
* integrating with UI libraries
* creating simple navigation
* adding a splash screen

### 8–13 SP: Complex features

* multi-step or otherwise complex forms with validation and error handling
* offline-online data synchronization using TanStack Query + MMKV persistence
* integration with Google Maps, Stripe, Firebase, Push Notifications (device registration, token handling, click reactions)
* advanced navigation
* handling deep links
* complex animations requiring React Native Reanimated / React Native Gesture Handler

### 21+ SP: Huge tasks meant for decomposition

* an order system with cart, checkout, and payments
* migrating to a large new library (upgrade Apollo / React Navigation, etc.)
* full offline-first support with mutation queues and retry logic
* advanced QR/Barcode scanning system with API integration
* integrating multiple services at once (e.g., Google/Apple/Facebook login + backend)

## 4. 1–6 Scale for React Native – Examples

### 1: Simple UI/Text changes

* changing a button color
* changing text color
* replacing an icon
* fixing a typo
* adding margin in styles

### 2: Basic forms, simple components

* adding a simple login form with `TextInput` + `Button`
* login form validation
* creating a `UserAvatar` component with an image and username
* creating a simple static list using `FlatList`

### 3: API integration, navigation

* fetching data from an API using Axios/Fetch
* displaying a product list from the backend using `FlatList` with pagination
* setting up React Navigation and adding product details with parameters in navigation.navigate() to open the details screen

### 4: Complex logic, state management

* using TanStack Query/Apollo for caching and data synchronization
* offline-first handling with MMKV and NetInfo
* implementing optimistic updates
* nested forms with conditional validation
* integrating Redux/Zustand for global state
* custom hooks managing business logic

### 5: Native module integration, cross-platform problem-solving

* connecting SDKs for payments (e.g., Stripe, Adyen) that require native configuration
* creating custom native modules
* integrating push notifications using Firebase Cloud Messaging and APNs
* debugging differences between iOS and Android
* fixing platform-specific issues

### 6: Architectural changes, app performance improvements

* migrating to React Native New Architecture (Fabric + TurboModules)
* refactoring the entire state management
* implementing modular architecture
* list optimizations
* code splitting
* profiling and fixing memory leaks
* setting up CI/CD using Bitrise/EAS

## 5. Factors That Increase Complexity

Besides the task scales themselves (1-6, Story Points), there are factors that can significantly increase implementation complexity. You can think of them as **difficulty multipliers**. Some of these factors were already hinted at in the examples for the different scales.

One of the biggest factors increasing complexity in mobile app development with React Native (though a similar phenomenon occurs in Flutter) are **the differences between iOS and Android**. Both platforms have their own way of handling permissions, significant differences in appearance and behavior, and often completely different APIs. What works “out of the box” on Android may require extra configuration on iOS or, worse, might not be possible at all.

Another significant factor that increases complexity is **integration with external systems**. Many developers have lost sleep over integrating payment SDKs or implementing login via OAuth/SSO. This category also includes integrations with hardware or backends that lack a stable and well-documented API.

When developing a mobile app, we need to keep **scalability** in mind. That’s why **performance** is another key factor that can increase complexity. Why? Because there’s no single universal method for optimization. What feels smooth to the user often requires, on our side, things like: 
 * optimizing lists, ensuring animations run at 60 FPS, managing memory (e.g., image caching, avoiding memory leaks), 
 * handling offline-first functionality with optimistic updates and data synchronization, 
 * as well as implementing lazy loading and code splitting for heavy screens.

But that’s not all. It’s 2026, the age of AI, where data leaks and fraud are happening more frequently. That’s why **data security** is another factor that increases complexity. It requires special attention when storing tokens, encrypting data, securing communications, handling sensitive information, and safely storing tokens in `.env` files.

All of this means that a task that might initially seem like a 3 SP job could actually require 21 SP. For example, implementing a login feature can involve at least three of the complexity-increasing factors mentioned earlier.

## 6. How Decomposition Affects Estimation – The Same Task Across Different Scales

To show how decomposition affects scales and Story Points, let me give you one example - the “Order List” - approached in two different ways.

### Version 1 (without decomposition)

**Description: Create an order list screen with API integration, handle pagination, allow changing order status, offline-first mode, and push notifications.**

Based on the examples mentioned earlier in this article, we can estimate this task as:
* - **Scale: 5-6** (we have API integration, offline logic, native modules)
* - **Story Points: 13+** (high risk, many dependencies, one large module to deliver)

**What are the problems with this task?**
It’s hard to estimate. The scope is very broad and touches on complex, time-consuming issues. Additionally, there’s a high risk of delays due to, for example, API blocking or Firebase issues.

### Version 2 (after decomposition)

Let’s break the task into smaller subtasks.

#### Task 1 – Displaying the order list

***Scale: 2***  
***SP: 2***

**Result:** clickable UI, progress is visible

#### Task 2 – API integration + pagination

***Scale: 3***  
***SP: 5***

**Result:** access to real data and a working list

#### Task 3 – Changing order status (optimistic updates)

***Scale: 4***  
***SP: 5-8***

**Result:** interactivity, order management, initial offline-first handling

#### Task 4 - Offline first mode (persist + sync)

***Scale: 5***  
***SP: 8***

**Result:** The order list works without internet, remembers what the user had in the list.

#### Task 5 - Push notifications

***Scale: 5***  
***SP: 8***

**Result:**  Users receive updates about order changes

This example shows that decomposition **lowers the rating of individual elements** - instead of one large, high-risk task, we have several smaller tasks with lower risk. This makes sprint planning easier, allows developers to show progress faster (e.g., displaying the list fetched from the API), and reduces the risk of blockers, since the remaining tasks can be worked on in parallel, for example while waiting for the backend to be ready.

## 7. Summary

The goal of this article was to explain what difficulty scales are and how to use them, with real-world examples. The 1–6 scale, Story Points, and task decomposition are primarily tools for technically assessing tasks and planning team work. When communicating with business stakeholders or non-technical people, it’s not always necessary to dive into implementation details. What’s important is to emphasize that the scale used for estimation doesn’t translate directly into hours — time estimates are a separate matter. From a developer’s perspective, it doesn’t make sense to explain, for example: “This task is 8 SP because we need to use TanStack Query, implement offline-first, persistence, sync, and optimistic updates.”
It’s better to say: “This task is large because it requires integration with multiple systems and must work smoothly even without internet, so we treat it as a bigger task that will take more than one sprint.”
Task decomposition also improves communication - instead of one big “it will take two months” task, we can show progress in smaller milestones. All of this helps clearly convey to the business **what they will get, when, and with what level of risk**.

A guide on difficulty estimation in React Native using Story Points, 1–6 scale, and task decomposition for better planning and risk management.

Difficulty Scales – Story Points, 1–6 Rating, and Other Methods in the World of React Native

The foundation of human civilization is mistakes – it is thanks to them that we have learned valuable lessons and found ourselves where we are today. History is full of accidental discoveries, such as when Spencer Silver, a 3M scientist, was trying to develop a strong adhesive. Instead, he accidentally created a weak, reusable adhesive. This “mistake” ultimately led to the invention of Post-it Notes, a product that revolutionized note-taking and organization of many companies, inluding those from the IT industry (Kanban planning).

![Kanban planning](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/planning-board-in-office-2025-03-10-05-20-45-utc-1753860929432.webp)

But have you ever wondered why we operate with estimates? What lies behind this, and how do psychological factors influence our approach to estimation?

The fact that people prefer to estimate rather than give precise numbers has been known for a long time, especially in psychology. The human brain processes massive amounts of data at the same time , so it sorts out information and optimizes the way it’s processed. Estimating is the brain’s way of simplifying the task—it doesn’t need to calculate or remember exact figures. Thanks to this optimization, the brain doesn’t have to run at full throttle in everyday life, since our sense of time, distance, or quantity mostly works approximately—like “a lot,” “far,” or “about half an hour.”

A great way to observe this is to ask a child about the size of several balls. The child will struggle to state the sizes and will likely talk about differences between them. But if you ask the child to arrange the balls from smallest to largest, there should be no problem .

In the IT industry, the tendency to estimate is especially noticeable, and developers often avoid giving estimates in hours because:

* it involves the risk of being wrong (and humans estimate partly to avoid the stress of decision-making ),
* the environment constantly changes,
* it helps manage interpersonal risk between the team and the client,
* developers, subconsciously using the physiology of the ANS (Approximate Number System), can roughly assess complexity or size, e.g., in story points .
  It might seem that this is something to fight against. Quite the opposite—it turns out it’s better to leverage our physiology rather than battle it. Even though Agile (including SCRUM) wasn't directly based on cognitive psychology, in practice it addresses phenomena described by Janis and Mann, such as avoiding decision stress or using the ANS . Agile frameworks reduce the pressure for precision, promoting approximation and adaptive approaches.

## The Influence of Authority on Team Estimation

One of the most common problems in group estimation (the basis of SCRUM) is the unchallenged decision of the group’s authority or leader . This might be the best programmer, the person with the longest tenure, or someone with strong leadership or authoritarian traits. If that person says a task will take an hour—even if every other team member would spend two days on it—no one is likely to object in front of the group, as members suppress doubts in favor of conformity (groupthink). As a result, the SCRUM Master records “one hour,” which can be an obvious estimation error from the start. This is another interesting psychological phenomenon, rooted in the famous Milgram experiment .

This becomes especially visible when a supervisor, department head, or boss attends meetings. Team members automatically adjust their responses to match the authority’s opinion—even when it’s incorrect. The “authority bias” leads to a lack of honest discussion and pressure to conform to expectations . Additionally, team members may struggle to push back or say “this will be difficult” due to fear of negative evaluation or having their competence questioned .

The presence of a superior also increases cognitive stress, which worsens the quality of judgment and decisions and restricts working memory (sparking the reaction: “what should I say to please them?”). This results in lower psychological safety to express uncertainty, less room for questions and doubt , and, most crucially, downward-biased estimates out of fear of appearing slow or incompetent

This is exactly why Agile/SCRUM is one of the most popular team management models—it leverages psychological factors. SCRUM specifically encourages estimations made by the development team without decision-makers present. The PM can provide context, but shouldn’t suggest specific numbers.



## What Is the Planning Fallacy?

The planning fallacy is a systematic tendency to underestimate the time, cost, and resources needed to complete a task—even when past experience contradicts such optimistic estimates. This is particularly noticeable in mobile development due to dynamic environments, hard-to-predict dependencies (unknown unknowns), or the pressure to quickly deliver features/apps.

Some examples:

* “It works on my machine, so it will work everywhere”—only to hit issues with various Android/iOS versions, devices, and edge cases in the real world.
* “The library will handle it”—then come incompatibilities, runtime bugs.
* “It’s just a backend change”—but then hooks break, caching needs redesign, and offline mode acts up.
* “We did something similar last time, so this will go faster”—ignoring historical data; despite prior delays, the team believes this time will be different.

## **If we know about this bias, why does it still happen in IT?**

From a developer’s perspective, there are several reasons why the planning fallacy persists in IT. One key factor is excessive faith that everything will go perfectly, leading to disregard of hidden dependencies and historical data, creating an illusion of optimism and omitting safety buffers. I’ve built several commercial projects from scratch and maintained/evolved others—trust me, nothing ever goes perfectly, though we always strive for it.

Another reason I often see is the motivating but deceptive fog: developers (often juniors, but not only) assume that saying something is easy and won’t take long will show they're good developers and motivate them to work faster (since it “must” be done in this time). In reality, when the estimate isn’t met, morale drops, stress rises, and developers shift into an intuitive, rushed “just get it done” mode—which leads to untested solutions that end up needing rework, and if that influences the developer’s reputation, it’s usually in a negative way.

The Dunning-Kruger effect also has a significant impact on the planning fallacy, in my view.

> *Dunning-Kruger effect—a cognitive error in which unskilled people in a particular field tend to overestimate their abilities, whereas highly skilled people underestimate theirs .*

## How Deadlines Affect Estimate Quality

Although it’s psychologically and procedurally absurd, you might encounter an estimation deadline. By definition, an estimate should reflect uncertainty and require reflection, analysis, and team discussion. Time constraints introduce pressure that significantly lowers estimation quality, fuels effects mentioned above (planning fallacy, groupthink, authority bias, fear of evaluation), and undermines the core Agile concept.

From a developer or team’s perspective facing such an expectation, it’s simply guessing what the business wants to hear—usually just confirming their assumptions. This leads to: “give me a number that fits the narrative,” not “give me a realistic project risk.” In the end, everyone loses. Under pressure, developers switch to “quick and dirty” rather than “thorough and correct” . Stress rises, causing tunnel vision, weaker risk/dependency recognition, and cognitive simplifications . Teams fear overshooting estimates out of concern they'll seem slow or inefficient, as discussed earlier. The result is underestimating time, resources, and hidden risks—directly impacting the client and project. Instead, it’s worth agreeing on how you estimate (without pretending faster is more precise), do explorations, and work with ranges—not fixed dates and hours.



## Summary

Estimation in IT is not just about planning—it’s fundamentally about psychology. Our brains work with approximations, not precise values—and this is perfectly normal. The real problem is pressure for exactness in uncertain environments, under time and authority strains. Good estimation isn’t about giving an exact number—a range better accounts for variability, risk, and unpredictability. This isn’t a weakness, but realism.

Research shows that decision-makers’ influence can unconsciously lower estimates through authority effects, groupthink, or competence anxiety.

Creating space for exploration and honest conversation is the best thing we can do. Estimates should come from reflection and experience, not expectation. Only then do they hold real value for both the team and the project.





**References:**

* Miller, G. A. (1956). The magical number seven, plus or minus two: Some limits on our capacity for processing information. Psychological Review.
* Kaczor, Ł. (2020). Scrum i nie tylko. Teoria i praktyka w metodach Agile. Warszawa: PWN.
* Janis, I. L., & Mann, L. (1977). Decision Making: A Psychological Analysis of Conflict, Choice, and Commitment.
* Dehaene, S. (2011). The Number Sense: How the Mind Creates Mathematics (Rev. and Expanded ed.). Oxford University Press.
* Wikipedia. (2024, June 26). Milgram experiment. [https://en.wikipedia.org/wiki/Milgram\_experiment.](https://en.wikipedia.org/wiki/Milgram_experiment.) Accessed: July 28, 2026.
* Janis, I. L. (1972). Groupthink. Houghton Mifflin.
* Milgram, S. (1974). Obedience to Authority: An Experimental View. Harper & Row.
* Rosenberg, M. J. (1965). Cognitive structure and attitudinal affect.
* Edmondson, A. (1999). Psychological safety and learning behavior in work teams. Administrative Science Quarterly.
* Wikipedia. (2024, July 17). Dunning-Kruger effect.  [https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger\_effect.](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect.) Accessed: July 28, 2026.
* Kahneman, D. (2011). Thinking, Fast and Slow. New York: Farrar, Straus and Giroux.
* Hockey, A. (1993). Cognitive-energetical control under pressure. In A. Baddeley &
* L. Weiskrantz (Eds.), Attention: Selection, awareness, and control (pp. 328–345). Oxford: Clarendon Press.

The psychology of estimation in the IT industry

## 1. Introduction

In the ever-evolving realm of web development, accessibility stands as a cornerstone of inclusive design, offering pathways for all users to seamlessly engage with digital content. But what exactly is accessibility in this context, and why does it hold such paramount significance?

### 1.1 What is Accessibility?

At its essence, accessibility in web development embodies the principle of ensuring that **digital experiences** are **perceivable, operable, understandable**, and **robust** for **individuals of all abilities**. It's about crafting online environments that transcend physical and cognitive barriers, empowering users with disabilities to navigate, interact, and derive value from the vast expanse of the internet.
In practical terms, accessibility encompasses a myriad of considerations, ranging from the implementation of **alternative text for images** to the **optimization of keyboard navigation** and the **creation of adaptable interfaces**. It's about fostering an inclusive digital ecosystem where diversity is not only acknowledged but celebrated through thoughtful design and meticulous attention to detail.

### 1.2 Overlapping Areas of Webdev

Accessibility doesn't exist in isolation - rather, it intersects with a multitude of other facets of web development - each contributing to the overarching goal of delivering superior user experiences. From **search engine optimization (SEO)** to **performance optimization** and **security protocols**, the pursuit of accessibility dovetails with a host of complementary objectives.

![accessability and SEO](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/accessibility-seo-1731602335937.webp)

Consider, for instance, the correlation between **accessible design** and **SEO**. By prioritizing semantic HTML markup, descriptive link text, and structured data, developers not only enhance the accessibility of their websites but also improve their visibility and rankings on search engine results pages. Similarly, the **optimization of website performance** through techniques like image compression and code minification not only accelerates page load times but also enhances the browsing experience for users with limited bandwidth or slower internet connections.
**Accessibility** and **security** are also closely connected. Using accessible CAPTCHA alternatives and strong authentication methods increases both user trust and inclusivity.

### 1.3 Standards and Definitions

Established standards are essential for guiding developers in creating accessible websites. The **Web Content Accessibility Guidelines (WCAG)** by the **World Wide Web Consortium (W3C)** outline principles and success criteria for accessible web content. WCAG is based on four principles: perceivable, operable, understandable, and robust, with success criteria across three levels: A, AA, and AAA.

Other important standards include the **Accessible Rich Internet Applications (ARIA)** specification and the United States' **Section 508 standards**. Adhering to these guidelines helps developers create inclusive digital experiences.
In the following chapters, we'll explore key aspects of accessible web development, including screen readers, semantic HTML, and ARIA, to help you build websites that are usable by everyone.

## 2. Screen readers

In the realm of web accessibility, screen readers play a pivotal role in ensuring that individuals with visual impairments can navigate and interact with digital content. Understanding how screen readers work, the importance of alternative text, and the array of other assistive technologies available is crucial for creating inclusive web experiences.

### 2.1 What Are Screen Readers and How Do They Work?

Screen readers are software applications that enable individuals with visual impairments to access digital content by converting text and graphical elements into synthesized speech or Braille output. These tools interpret the structure and content of web pages, allowing users to perceive and interact with the information presented.
Screen readers work by parsing the HTML and other code behind a webpage, extracting meaningful content, and presenting it in a linear, auditory format. Users navigate through the content using keyboard shortcuts, allowing them to move between headings, links, form fields, and other elements. Popular screen readers include **JAWS (Job Access With Speech)**, **NVDA (NonVisual Desktop Access)**, and **VoiceOver for macOS and iOS devices**.

### 2.2 Alternative Text

Alternative text is a concise textual description provided for non-text content, such as images, graphics, and multimedia elements. Alt text is essential for accessibility as it conveys the purpose and content of these elements to users who cannot see them.
When a screen reader encounters an image, it reads the alt text aloud, allowing the user to understand the image's context and relevance.

Best practices for writing alt text include:

* Be Descriptive: Clearly describe the image's content and purpose. For example, "A group of people sitting around a conference table discussing a project",
* Be Concise: Keep descriptions brief and to the point, typically no longer than a sentence or two,
* Avoid Redundancy: Do not repeat information already conveyed in surrounding text or captions.

### 2.3 Other Assistive Technologies

Beyond screen readers, several other assistive technologies support individuals with disabilities in accessing and interacting with digital content:

* **Braille displays** are devices that convert on-screen text into Braille, providing tactile feedback for users who are blind or have severe visual impairments. These displays connect to computers or mobile devices and dynamically update to reflect the text being read by the screen reader. This allows users to read and navigate digital content through touch.
* **Speech recognition** software enables users to input text using voice commands. This technology is particularly beneficial for individuals with mobility impairments or conditions that make typing difficult. Popular speech recognition tools include **Dragon NaturallySpeaking** and built-in options like **Apple's Siri** and **Google Assistant**.
* **Voice control** systems allow users to navigate web pages and applications using spoken commands. These systems work in conjunction with screen readers and other accessibility tools, providing an additional layer of interaction for users with various disabilities. For example, users can issue commands like "click link," "scroll down," or "open menu" to interact with web elements without needing to use a mouse or keyboard.

## 3. Accessible HTML

Creating accessible HTML is fundamental to ensuring that web content is usable by everyone, including individuals with disabilities. This involves using semantic HTML to convey meaning and structure, setting the appropriate language for content, and fixing markup errors to maintain a robust and navigable web experience.

### 3.1 Semantic HTML

Semantic HTML involves using HTML elements that accurately describe their meaning and purpose. This practice not only improves accessibility but also enhances SEO and overall code readability. Semantic elements provide context to browsers and assistive technologies, enabling them to interpret and present content correctly.

In web development we can often encounter an occurrence commonly called “div hell”. It refers to the **overuse of `<div>` elements** to structure a webpage. While `<div>` elements are versatile, their excessive use can lead to unmanageable, cluttered code that is difficult to read and maintain.

More importantly, it significantly hampers accessibility because `<div>` elements provide no semantic meaning about the content they enclose. This lack of semantic information makes it harder for assistive technologies to interpret the page structure and content correctly. Here is an example of a badly structured HTML page:

```html
<div class="container">
  <div class="header">
    <div class="logo">My Website</div>
    <div class="nav">
      <div class="nav-item"><a href="#home">Home</a></div>
      <div class="nav-item"><a href="#about">About</a></div>
      <div class="nav-item"><a href="#contact">Contact</a></div>
    </div>
  </div>
  <div class="main-content">
    <div class="section">
      <div class="section-title">Our Services</div>
      <div class="section-content">
        <p>Details about services.</p>
      </div>
    </div>
  </div>
  <div class="footer">
    <div class="footer-content">
      (c) 2024 Your Company. All rights reserved.
    </div>
  </div>
</div>
```

In this example, even though the classes give us a mere understanding of the layout - the use of multiple nested `<div>` elements does not convey the purpose or structure of the content, making it difficult for assistive tech to navigate and interpret.
Semantic HTML provides a solution - elements that convey specific meanings, making the content more accessible and easier to understand for both humans and assistive technologies. [HTML5 brought even more semantic elements](https://www.freecodecamp.org/news/semantic-html5-elements/) that help structure web pages more meaningfully:

```html
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Accessible Web Page</title>
  </head>
  <body>
    <header>
      <h1>My Website</h1>
      <nav>
        <ul>
          <li><a href="#home">Home</a></li>
          <li><a href="#about">About</a></li>
          <li><a href="#contact">Contact</a></li>
        </ul>
      </nav>
    </header>
    <main>
      <section>
        <h2>Our Services</h2>
        <p>Details about services.</p>
      </section>
    </main>
    <footer>
      <p>&copy; 2024 Your Company. All rights reserved.</p>
    </footer>
  </body>
</html>
```

### 3.2 Setting Language

Defining the language of your web content is crucial for accessibility. Screen readers rely on this information to apply the correct pronunciation and reading rules. Set the primary language of the document using the lang attribute in the `<html>` tag.

```html
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Accessible Web Page</title>
</head>
<body>
  <header>
    <h1>My Website</h1>
    
  </header>
</body>
</html>
```

For multilingual content, we can set the lang attribute on individual elements as needed:

```html
<p lang="es">Este es un ejemplo de contenido en español.</p>
```

## 4. Accessible Rich Internet Applications (ARIA)

ARIA is a set of specifications developed by the **World Wide Web Consortium (W3C)** to enhance the accessibility of web applications, especially those that are dynamic and rich in interactivity. ARIA provides additional attributes that help bridge the gap between complex user interfaces and assistive technologies, ensuring that all users, including those with disabilities, can interact with web content effectively.

### 4.1 What is ARIA?

ARIA (Accessible Rich Internet Applications) is a set of attributes that can be added to HTML elements to make web content and applications more accessible to people with disabilities. ARIA attributes provide information, which assistive technologies use to interpret and present web content more accurately.

### 4.2 Roles, States, and Properties

ARIA attributes are categorized into three main types: **roles, states, and properties**.

#### Roles

ARIA roles define the type of user interface element. By assigning a role to an element, you inform about the element's purpose. This is crucial for dynamic content that might not have a clear semantic equivalent in HTML.
Role examples:

* role="button": Defines an element as a button.
* role="navigation": Indicates a navigation region.
* role="main": Signifies the main content area of a document.
  Code sample:

```html
<div role="button" tabindex="0">Click Me</div>
```

#### States

ARIA states represent the current condition of an element, such as whether it is disabled, expanded, or checked. States are dynamic and can change in response to user interactions.
State examples:

* aria-checked="true": Indicates that a checkbox or similar element is checked.
* aria-expanded="false": Indicates that an expandable element is currently collapsed.
* aria-disabled="true": Denotes that an element is disabled and not interactive.
  Code sample:

```html
<button aria-pressed="true">Toggle</button>
```

#### Properties

ARIA properties describe the characteristics of elements that are not typically expressed in HTML. Properties provide additional context that helps users understand the purpose and behavior of elements.
Property examples:

* aria-label="Search": Provides an accessible name for an element.
* aria-labelledby="elementID": Refers to another element that labels the current element.
* aria-describedby="elementID": Points to an element that provides a description.
  Code sample:

```html
<input type="text" aria-label="Search box" />
```

### 4.3 Accessible Names and Descriptions

ARIA introduces a foundational concept for all HTML markup: **accessible names and descriptions**. These attributes enhance the usability of web content by providing meaningful context to assistive technologies like screen readers.
The text content or value exposed from elements like buttons, links, form inputs, or headings is referred to as an **“accessible name.”** This name is what assistive technologies use to identify and describe these elements to users:

```html
<button>Submit</button>
<a href="#home">Home</a>
```

In contrast, text exposed on an element with a title attribute is called an **“accessible description.”** Descriptions are announced by screen readers after a slight delay and can be configured to be on or off. Therefore, don't rely solely on descriptions being announced. Descriptions can also act as accessible names if no other name is provided:

```html
<button title="Click to submit the form">Submit</button>
```

Both accessible names and descriptions are crucial for assistive technology users, providing clarity on the purpose of an element. An accessible name or description should give users enough information to understand the element’s function.

#### ARIA Attributes: aria-label, aria-labelledby, & aria-describedby

You can explicitly set both accessible names and descriptions using ARIA attributes like **aria-label, aria-labelledby,** and **aria-describedby**.
You can assign a string value to the aria-label attribute on an element with a qualifying role, such as a `<button>` or a landmark element.

```html
<button aria-label="Settings"></button>
```

Both aria-labelledby and aria-describedby attributes take an ID as a value that matches another element's ID, making it easy to reuse content already present on the page.

```html
<section aria-labelledby="section-heading-2">
  <h2 id="section-heading-2">All About Wombats</h2>
</section>
```

#### Determining the Accessible Name

When multiple pieces of content are associated with an element—text content, an aria-label, aria-labelledby, and aria-describedby—which one takes precedence? To avoid chaos in accessible naming, ARIA and related specifications define the order in which content should be exposed. This order does not rely on the source order (i.e., start-to-end in the markup). According to the standard algorithm, one attribute may override another, ensuring a predictable and coherent user experience across platforms.

## Conclusions

Building accessible web applications is not just about adhering to standards; it’s about creating inclusive experiences that respect and accommodate the diverse needs of all users. By incorporating accessibility best practices into your development process, you ensure that your web content is usable by individuals with disabilities, thereby broadening your audience and enhancing overall user satisfaction.
Throughout this article, we’ve explored the foundational principles of web accessibility, the importance of semantic HTML, the role of ARIA attributes, and the specific techniques for creating accessible names and descriptions. Here are some key takeaways:

* Understanding Accessibility: Recognize that web accessibility is integral to modern web development. It overlaps with areas like SEO, performance, and security, reinforcing the overall quality and robustness of your web applications.
* Using Semantic HTML: Employ semantic HTML elements to convey meaningful structure and context. This practice not only aids accessibility but also improves code maintainability and SEO.
* Leveraging ARIA: Use ARIA roles, states, and properties judiciously to enhance the accessibility of dynamic content. Ensure that accessible names and descriptions provide clear and useful information to assistive technologies.
* Adhering to Guidelines: Follow established guidelines such as the Web Content Accessibility Guidelines (WCAG) and the Accessible Rich Internet Applications (ARIA) specification. These standards offer comprehensive frameworks for creating accessible web content.
* Continuous Learning and Improvement: Accessibility is an ongoing commitment. Stay informed about new developments, tools, and techniques. Engage with the accessibility community and seek feedback to continuously improve your practices.

Incorporating accessibility into your web development workflow is a step towards a more inclusive internet. By prioritizing accessibility, you not only comply with legal requirements and industry standards but also demonstrate a commitment to social responsibility and user-centric design. Ultimately, accessible web development is about making the web a place where everyone can participate and benefit, regardless of their abilities.

### Additional Resources

To further enhance your understanding and implementation of web accessibility, consider exploring the following resources:

* **W3C Web Accessibility Initiative (WAI)**: Provides a wealth of information on web accessibility standards and guidelines.
* **WebAIM (Web Accessibility In Mind)**: Offers articles, tools, and training materials on web accessibility.
* **Mozilla Developer Network (MDN) Web Docs**: Comprehensive documentation on HTML, ARIA, and accessibility best practices.
* **A11Y Project**: A community-driven effort to make web accessibility easier.

By leveraging these resources and integrating accessibility into your web development practices, you contribute to a more inclusive digital world. Together, we can build web experiences that are not only functional and beautiful but also accessible to all.

A thorough look at all the different facets of web app accessibility - standards, guidelines and their implementation.

Comprehensive guide to web app accessibility

Imagine coding without stressing over syntax or boilerplate. Just describe what you want, and boom - the code writes itself. Sounds like magic? Welcome to the world of **vibe coding.**

In recent months, devs across Twitter and LinkedIn have been buzzing about this new way of building software - where you code more by **feel** than by hand, and AI handles most of the details.

In this post, we’ll unpack what vibe coding actually is, where it came from, how tools like ChatGPT and GitHub Copilot make it possible, and why developers are hyped (and a little scared). Expect memes, real-life stories, and a casual tone - so grab a drink, and let’s vibe in.

## **1. So... What *Is* Vibe Coding?**

At its core, **vibe coding is about letting AI handle the grunt work**, so you can focus on what you actually want to build.

Instead of writing everything from scratch, you describe your goals - in plain English - and the AI fills in the code. Think of it like:

*“I want a form with three inputs and a submit button. Also, make it look clean.”*

...and the code just appears.

One definition puts it like this:

*“A new approach to software development that uses AI tools to help people create applications without needing deep programming knowledge.”*

In other words: **you set the vision, the AI writes the code**.

Your role shifts from typing every line to guiding, curating, and tweaking what the AI delivers. Less battling syntax errors, more directing the show.

## **2. Where Did the "Vibes" Come From?**

The spark? A tweet from AI researcher **Andrej Karpathy** in early 2026.

He described a coding style where he just *"sees stuff, says stuff, runs stuff, copy-pastes stuff"* - and lets AI do all the work. He was using Cursor Composer and even coding by voice. No keyboard smashing. No reading diffs.

*“I just embrace the vibes and forget the code exists.”*

That tweet exploded. Memes followed. Devs started calling it “vibe coding.”

People even joked that legendary music producer **Rick Rubin** was the patron saint of vibe coding - the man known for having no technical skills but incredible taste.

And suddenly, everyone was sharing their own rules of vibe coding. Like:

*“Vibe coding is easy. Vibe debugging is hard.”*

Which... is kinda true.

## **3. The Rise of the AI Coding Sidekick**

What made all this possible? Simple: **AI coding tools got ridiculously good**.

Over the past couple of years, GitHub Copilot, ChatGPT, Replit Ghostwriter, Cursor, and more have gone from autocomplete helpers to full-on code co-pilots.

These tools can now:

* Turn plain English into fully working functions
* Generate whole components, pages, or APIs
* Debug errors
* Write tests
* Even run or lint your code

You can literally say:

*“Add error handling and turn this into a REST endpoint.”*

And watch it happen in real-time.

Some tools even support **voice commands**. Karpathy used voice-to-code with SuperWhisper and Cursor. He barely touched his keyboard - and still built a full app.

## **4. Why It *Feels* So Different**

Here’s why “vibe coding” caught on - it’s not just about using AI.

It’s about how **fluid** the process feels. Like jazz. Or jamming with a band.

Instead of planning every detail, you:

* Try something
* See the result
* Tweak it
* Repeat

You get instant feedback. The flow is fast and creative. You’re not stressing over syntax - you’re just vibing, iterating, and adjusting on instinct.

This “code by intuition” style is empowering. One non-tech founder built a beta of their app in a weekend using ChatGPT. They didn’t even know what stack it used until the AI explained it after the fact.

It’s about **speed, creativity, and momentum** - even if you don’t understand 100% of what’s under the hood.

## **5. Why Devs Love It**

Let’s look at why this has taken off:

* **🚀 Wild Speed**
  Building an MVP used to take weeks. Now it can take a weekend - or a day.


* **🎨 Creative Flow**
  No more getting stuck on syntax. You focus on ideas and design.


* **🤝 More Accessible**
  Even non-devs can build something functional. AI bridges the gap.


* **😎 It's Just Cool**
  There’s something fun about saying “I built this by vibing with ChatGPT.”

It’s a little chaotic, a little magical, and people are loving the ride.

## **6. But Wait – There's a Catch**

Of course, **there’s a downside**. The vibes aren’t always good.

Here’s what can go wrong:

* **🐞 Vibe Debugging is Brutal**
  When things break (and they will), figuring out *why* is tough. You didn’t write the code, so you’re stuck deciphering AI logic.


* **🧠 Losing Skills**
  Rely on AI too much and your coding muscles atrophy. You stop thinking about how stuff works.


* **⚠️ Risky for Production**
  The AI doesn’t always follow best practices. Sloppy patterns, missing tests, even insecure code can sneak in.


* **📦 Messy Codebases**
  If the project grows, AI-generated files can get chaotic fast. One change might introduce ten more.



Bottom line? Vibe coding is amazing for fast prototypes, but it’s not (yet) a replacement for solid engineering.

## **8. The Bottom Line**

**Vibe coding is real, and it’s here to stay.**

It makes coding faster, more creative, and more accessible than ever. You don’t need to know everything - you just need to know what you want.

But it’s not magic. It doesn’t replace good engineering. If you’re building something serious, you still need to test, refactor, and understand what’s going on.

So here’s the takeaway:
**Use vibe coding to explore, prototype, and jam - but don’t forget how to actually play your instrument.**

If you balance vibes with skill, you’ll not only build cool stuff faster - you’ll have a lot more fun doing it.

Now go forth. See stuff. Say stuff. Run stuff. And may the vibes be with you.

Imagine coding without stressing over syntax or boilerplate. Just describe what you want, and boom - the code writes itself. Sounds like magic? Welcome to the world of vibe coding

Welcome to the Era of "Vibe Coding"

Yesterday (25 Jan 2024) Apple announced some major changes to iOS, Safari, and the App Store operating model that would impact developers' apps in the European Union. The motivation for the changes is to comply with the Digital Markets Act (DMA) that came into force in Nov 2022. Let's have a look at the most interesting ones, or if you want to see the full list of changes go to [Apple's official announcement](https://www.apple.com/newsroom/2024/01/apple-announces-changes-to-ios-safari-and-the-app-store-in-the-european-union/).

## What's new for iOS

For iOS, Safari and App Store to become DMA compliant Apple has been forced to significantly loosen many of its previous restrictive operating rules which will result in:

* **New framework and APIs for browser engines** — which will allow developers to use browser engines, other than the default iOS WebKit, for browser apps and apps with in-app browsing, which is a huge impact on developers, as it should give them some more options when dealing with WebView.
* **Interoperability request form** — through which developers can apply to unlock additional iPhone, iOS hardware and software functionalities which should lead to some cool new products see daylight

A lot of you might say:

> "Hey, what about the alternative app marketplace deregulations?"

so it looks like we should indeed get some new APIs & tools for publishing, downloading & even updating apps from alternative marketplaces, but this comes with even more safeguards (regulations?) in the form of:

* Notarization for iOS apps
* App installation sheets
* Authorization for marketplace developers
* Additional malware protections

which is hardly surprising as this could pose a risk for iPhone end users. I honestly believe that the majority of users and app download traffic will remain in the App Store anyway. It's a tidy, familiar & trustworthy environment, so nothing should change until a high-trust alternative emerges.

## What's new for the App Store

Changes to the App Store terms cause, to put it mildly, mixed feelings. So we're getting a tool which lets us estimate fees, better understand metrics associated with Apple's **new business terms for apps in the EU** (which will be covered in a minute) & a bunch of new really nice deregulations like the ability to:

* **use 3rd party payment service providers** - we're finally getting a way to process payments for digital goods and services directly from our iOS app (no additional fee to Apple),
* **process payments via link-out** - users can finally complete a transaction for digital goods and services on developer's external website (no additional fee to Apple),

and there is one but. This leads us to...

### New Business Terms for Apps in the EU

Let's start with the fact that we can choose to accept these new business terms or stay on Apple's existing terms, but of course, the previously mentioned deregulations are **only** included in the new business terms.

Now let's see what's inside. It starts nicely with two eye-catchers in the form of:

* **Reduced commission** — iOS apps on the App Store will pay a reduced commission of either 10 percent (for the vast majority of developers, and subscriptions following their first year) or 17 percent on transactions for digital goods and services.
* **Payment processing fee** — iOS apps on the App Store can use the App Store's payment processing for an additional 3 percent fee. Developers can use a payment service provider within their app or link users to their website to process payments for **no additional fee to Apple**.

but then we're getting hit with:

* **Core Technology Fee** — iOS apps distributed from the App Store and/or an alternative app marketplace will pay €0.50 for each first annual install per year over a 1 million threshold,

since we're getting a cool new tool to "*estimate fees, better understand metrics associated with Apple*" let's do the math. As it was put nicely by Nikita Bier on his Twitter [@nikitabier](https://twitter.com/nikitabier) an app that would work & sell digital goods under new terms that generate 10 000 000 installs per year and is forecast to reach 10 000 000$ in sales can expect to pay a whooping 500 000$ in monthly fees. OK, the yearly APRU of 1$ is a bit higher (or a lot higher?) than the sector average, but as you can see in the breakdown below most of the fee is coming from the so-called "Technology Fee" which is tied to your install volume.

![new fee structure](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/bier-1730907775025.webp)

## Conclusion

Considering all the above are we really getting a batch of deregulations or just DMA-compliant illusion of an alternative solution which in comparison with the current one comes out so poorly that few will want to use it? Apple boldly estimates that the new business terms would reduce or maintain the current level of fees paid to Apple for 99% of developers and that less than 1% would need to pay a Core Technology Fee on their EU apps. Let's wait and see.

Apple has been forced to adapt to DMA compliancy in the EU, but are the changes they're making better or worse for app developers?

 Apple DMA changes - for better or for worse?

When Tailwind CSS burst onto the scene, it introduced a utility-first approach to styling that dramatically changed the way developers build applications. By allowing styles to be applied directly in the markup, it promised faster workflows and more consistent design systems. Yet, it also sparked debates. Critics argue that such convenience might come at a cost—discouraging developers from learning core CSS principles. So, does Tailwind make us lazy, or does it enable smarter development? Let’s explore this question through real-world perspectives and examples.

## **The Perceived Problem: Are We Forgetting Core CSS?**

For some, Tailwind represents a shortcut—a way to bypass the deeper nuances of CSS. Imagine a junior developer who’s never dealt with the cascade or specificity but can still build a fully responsive, visually appealing site with Tailwind. Is this a win for productivity, or a loss for foundational knowledge?

Take, for example, a scenario where a team builds a component with Tailwind:

```html
<div class="bg-gray-100 p-6 rounded-lg shadow-lg">
  <h1 class="text-2xl font-bold mb-4">Welcome</h1>
  <p class="text-gray-700">This is a simple card.</p>
</div>
```

It’s concise and clear—no separate CSS file needed. But does this approach risk turning CSS into a black box? Critics warn that such reliance on utility classes might lead to a generation of developers who are unfamiliar with how their tools work under the hood.

## **When Tailwind Shines: The Ultimate Time-Saver**

Despite the criticisms, Tailwind’s supporters point to its undeniable strengths. For projects where speed is crucial and reusability is not a priority, Tailwind excels like no other. By focusing on utilities, it eliminates the need for bloated CSS files filled with one-off rules. Developers can prototype quickly, refine designs directly in the markup, and enforce a consistent visual language across the app.

Consider a fast-paced freelance project where the client needs a fully functional MVP within days. Tailwind’s predefined utility classes allow you to get the job done without the overhead of creating reusable styles or separate CSS files.&#x20;

For instance:

```html
<div class="grid grid-cols-3 gap-6">
  <div class="bg-blue-500 p-4 text-white">Card 1</div>
  <div class="bg-blue-500 p-4 text-white">Card 2</div>
  <div class="bg-blue-500 p-4 text-white">Card 3</div>
</div>
```

With Tailwind, consistent spacing and styling are effortlessly achieved through its utility classes. This speed and simplicity can be a game-changer in scenarios where time-to-market is critical.

## **The Challenges of Scaling with Tailwind**

However, for larger projects where reusability and maintainability are key, Tailwind’s inline utility approach can pose challenges. As the codebase grows, HTML can become cluttered with class names, making it harder to identify and update shared styles. This can lead to headaches in large-scale applications where design consistency and clean architecture are paramount.

For example, consider a team working on a design system that will be used across multiple products. Extracting reusable styles into components or CSS files might be better in the long run. Using tools like @apply can help mitigate some of the issues:

```ts
.btn-primary {
  @apply bg-blue-500 text-white py-2 px-4 rounded hover:bg-blue-700;
}
```

This approach combines the speed of Tailwind with the organization of traditional CSS, offering a balanced middle ground.

## **Tailwind in Practice: Know Your Use Case**

The key to using Tailwind effectively lies in understanding its strengths and limitations. If you’re working on a project that demands rapid development and minimal architectural complexity, Tailwind can be your best friend. It’s ideal for prototypes, small-scale applications, and scenarios where reusability is not a primary concern.

However, if you’re building a large application with a focus on scalability and maintainability, you might need to complement Tailwind with other tools or techniques. Pairing Tailwind with component-based frameworks like React can help mitigate some of its downsides:

```ts
const Card = ({ children }) => (
  <div className="bg-blue-500 p-4 text-white rounded-md">
    {children}
  </div>
);
```

By encapsulating styles within reusable components, you can maintain clean and organized code while leveraging Tailwind’s utilities for rapid styling.

## **Why Tailwind CSS Is Worth It**

Tailwind CSS doesn’t make developers lazy; it makes them efficient. By reducing the friction between design and development, it enables faster iteration and more consistent styling. However, its utility-first paradigm does challenge traditional ways of thinking about CSS and that’s not necessarily a bad thing.

For developers who prioritize speed and simplicity, Tailwind is a no-brainer. It allows you to focus on building features and delivering value rather than getting bogged down in the details of CSS. While it may not be the perfect solution for every use case, understanding when and how to use it can unlock its full potential.

So, is Tailwind making us lazy? Not at all. It’s giving us the tools to work smarter and in the fast-paced world of modern web development, that’s a trade-off worth embracing.

Does Tailwind make us lazy, or does it enable smarter development? 

Is Tailwind CSS Making Developers Lazy?

# Full-Stack Type Safety with Axolotl, Zeus, and Vite

I've been building GraphQL APIs for years, and the biggest pain has always been keeping types in sync. You write your schema, manually create TypeScript types for resolvers, generate client types, and hope nothing drifts. One typo in a resolver return type and you're debugging runtime errors.

This example shows a different approach - true end-to-end type safety from schema to React components, running on a single server.

## The Setup

The `yoga-federated` example runs everything on one port:

* **Backend**: Express + GraphQL Yoga with Axolotl-generated types
* **Frontend**: React + Vite with Zeus-generated GraphQL client
* **Both**: Same server, same origin

http://localhost:4002/         -> React Frontend (SSR)

http://localhost:4002/graphql  -> GraphQL Playground

In development, Vite runs as Express middleware for HMR. In production, Express serves the built frontend. One deployment, zero CORS config.

## The @resolver Directive

Here's the schema:

```gql
type Todo {
  _id: String!
  content: String!
  done: Boolean
}

type AuthorizedUserMutation {
  createTodo(content: String!, secret: Secret): String! @resolver
  todoOps(_id: String!): TodoOps! @resolver
}

type Query {
  user: AuthorizedUserQuery @resolver
}
```

The `@resolver` directive marks which fields need implementation. Fields without it are auto-resolved from the parent object.

```gql
type Query {
  user: AuthorizedUserQuery @resolver # ← needs code
}

type User {
  _id: String! # ← resolved from parent
  username: String! # ← resolved from parent
}
```

This is what makes Axolotl work well with AI assistants. When Copilot or Cursor sees a schema, it knows exactly which fields need resolvers and which don't. No guessing.

Prompt an AI with "Implement all @resolver fields" and it generates the right code because the schema is explicit about what needs implementation.

Run `axolotl build` and you get typed models:

```ts
// Auto-generated src/models.ts
export interface Todo {
  _id: string;
  content: string;
  done?: boolean | undefined | null;
}

export type Models = {
  ['AuthorizedUserMutation']: {
    createTodo: {
      args: {
        content: string;
        secret?: Secret | undefined | null;
      };
    };
  };
};
```

Write resolvers with full type inference:

```ts
// src/todos/resolvers/AuthorizedUserMutation/createTodo.ts
import { createResolvers } from '../../axolotl.js';

export default createResolvers({
  AuthorizedUserMutation: {
    createTodo: async ([source], { content }) => {
      // TypeScript knows `content` is string
      // TypeScript knows this must return string
      const _id = Math.random().toString(8);
      db.todos.push({ owner: src._id, content, _id });
      return _id;
    },
  },
});
```

Return a number instead of a string and TypeScript complains immediately.

## Micro-Federation

The example splits schemas by domain:

```ts
src/
├── todos/
│   ├── schema.graphql
│   └── resolvers/
├── users/
│   ├── schema.graphql
│   └── resolvers/
└── resolvers.ts
```

Axolotl merges them:

```ts
// src/resolvers.ts
import { mergeAxolotls } from '@aexol/axolotl-core';
import todosResolvers from '@/src/todos/resolvers/resolvers.js';
import usersResolvers from '@/src/users/resolvers/resolvers.js';

export default mergeAxolotls(todosResolvers, usersResolvers);
```

Types flow through the merge.

## Frontend with Zeus

Zeus generates a typed GraphQL client from the schema:

```ts
// frontend/src/api.ts
import { Chain } from '../../src/zeus/index';

export const createGqlClient = (token?: string) => {
  const headers: Record<string, string> = {
    'Content-Type': 'application/json',
  };
  if (token) {
    headers['token'] = token;
  }
  return Chain('/graphql', { headers });
};
```

Queries are type-safe:

```ts
// frontend/src/hooks/useTodos.ts
const fetchTodos = async () => {
  const data = await gql()('query')({
    user: {
      todos: { _id: true, content: true, done: true },
    },
  });

  // TypeScript knows data.user?.todos is Todo[]
  if (data.user?.todos) {
    setTodos(data.user.todos);
  }
};
```

Mutations too:

```ts
const createTodo = async (content: string) => {
  await gql()('mutation')({
    user: {
      createTodo: [{ content }, true],
    },
  });
};
```

The `[{ content }, true]` syntax means: pass these arguments, return this field. TypeScript validates that `content` matches the schema.

## Express + Vite on One Server

The whole stack runs on one Express server:

```ts
// src/index.ts
async function startServer() {
  const app = express();

  // Mount GraphQL
  const { yoga } = adapter({ resolvers, directives });
  app.use('/graphql', yoga);

  // Development: Vite middleware for HMR
  if (!isProduction) {
    const vite = await createViteServer({
      server: { middlewareMode: true },
      appType: 'custom',
    });
    app.use(vite.middlewares);
  } else {
    // Production: serve built assets
    app.use(sirv(resolve(__dirname, '../dist/client')));
  }

  // SSR for all other routes
  app.use('*all', async (req, res) => {
    const { html } = await render(req.originalUrl);
    res.send(html);
  });
}
```

You get:

* HMR in development
* SSR for SEO
* One deployment artifact
* No proxy config

## The Type Flow

A todo travels through the system like this:

1. **Schema** defines `createTodo(content: String!): String!`
2. **Axolotl** generates `args: { content: string }` for resolvers
3. **Resolver** uses `{ content }` with TypeScript support
4. **Zeus** generates client types from the same schema
5. **React hook** calls `createTodo: [{ content }, true]` with type checking
6. **Response** comes back typed

Change the schema, run `axolotl build`, and TypeScript shows you what broke.

## Try It

```ts
cd examples/yoga-federated
npm install
npm run dev
```

Open http://localhost:4002:

![](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/screenshot-login-1765204379116.png)

Register and you're in and can create todos

![](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/screenshot-todo-created-1765204389217.png)

GraphQL Playground at http://localhost:4002/graphql:

![](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/screenshot-playground-1765204385463.png)

## What I Like About This

After using this pattern, a few things stand out:

1. **Schema changes propagate everywhere** - modify a field, run build, TypeScript tells you what broke on both backend and frontend
2. **AI assistants actually help** - the `@resolver` directive means Copilot knows what to implement without explaining the architecture
3. **One `npm run dev`** - no separate terminal for frontend, no proxy config, no CORS debugging
4. **SSR just works** - good for SEO if you need it

The tradeoff is coupling - frontend and backend deploy together. For most projects that's fine. If you need independent scaling, split them later.

## Links

* [Axolotl Documentation](https://axolotl.aexol.com)
* [GraphQL Zeus Documentation](https://zeus.aexol.com)
* [Example Source Code](https://github.com/aexol-studio/axolotl/tree/main/examples/yoga-federated)

***


*Built with Axolotl + GraphQL Yoga + Zeus by* [Aexol Studio](https://aexol.com)

I've been building GraphQL APIs for years, and the biggest pain has always been keeping types in sync. You write your schema, manually create TypeScript types for resolvers, generate client types, and hope nothing drifts. One typo in a resolver return type and you're debugging runtime errors.

Full-Stack Type Safety with Axolotl, Zeus, and Vite

## 1. Introduction

**“How long will that take?” - is a question every developer has heard hundreds of times. What comes to mind each time is “it depends…”**

I hold a bachelor’s degree in Mechatronic Engineering from Bialystok University of Technology. More than once, I’ve had the chance to design or make something using machining tools – both manual and CNC ones. To visualize how the manufacturing process looks in mechanical engineering, let’s imagine we’re making a flat timber connector with 10 holes in it.

First, a constructor designs the part. He chooses the material, sets the dimensions, and decides where the holes go and how big they are. Then, based on that documentation, a machine operator – whether on a CNC or an old-school manual mill – picks the right tools, feed rates, and all the other necessary stuff to get the job done. The machine cuts the shape out of a sheet of metal, drills the holes, and finishes the edges. Once it’s done, the operator takes out the finished piece and starts on the next one. What’s more, CNC machines can make several – or even a dozen – parts at once, and the whole process can be fully automated. Either way, we can be pretty sure, or at least reasonably expect, that the process will take roughly the same amount of time if we’re using the same setup: same material, same machine settings, same tools. On top of that, modern CNC machines will even tell you exactly how long it’ll take to produce a given part once you load up the program.

In software development that process looks nothing like what I just described and this is exactly why estimating time in IT projects is one of the hardest skills in the industry. There’s no such thing as two identical apps. Every project is unique – with a different design, different assumptions, and totally different business goals. Often, there aren’t any ready-made templates to use, and even the simplest feature can turn out to be a pain to implement in a specific environment.

On top of that, platform differences between Android and iOS tend to mess with our plans pretty often. And to make things even more “fun,” React Native lets you target web apps, Apple Watch apps, or even TV platforms – all from the same codebase.

So then, someone might say that estimations are pointless, or that it's basically just a lottery — but that’s not entirely true.

It doesn’t matter if you’re a developer who needs to estimate or price out a task, or a CEO trying to understand why a “simple” project is taking three months — I hope what you’ll find here will shed some new light on how this whole process actually works.

We’ll start by going over the basics and some key concepts. We’ll dig into what actually makes this so hard, and how to try bridging the gap between the tech world and the business world — which, in my opinion, is one of the most important parts of any IT project.

## 2. Basic definitions

*There’s gonna be a bit of dry theory here, but I’ll do my best to keep it clear and easy to follow* 🙂

### 2.1 Estimation

It’s the process of figuring out how much time, effort, and resources will be needed to complete a given task or project. It’s a key part of planning and project management — it helps set realistic goals and use resources effectively.

Estimation usually isn’t just a one-time thing. It tends to evolve as the project moves forward. It helps us build realistic timelines, set the right priorities, and keep track of progress. It’s also useful for spotting risks early and managing expectations on both sides.

Estimates are usually done by developers or the tech team, and most often expressed in story points, though sometimes you’ll still see hours being used.

***Did you know that:***

> Hofstadter’s Law -Any task always takes longer than you expect — even
> when you take Hofstadter’s Law into account.

### 2.2 Pricing

This is the process of turning an estimate into an actual price. It includes the: estimate + hourly rate + margin + risk and it’s an external, contract-related figure. It’s presented to the client and usually negotiated. If your estimate was done in hours, the math is pretty straightforward.

But if you estimated in story points, converting that into hours means you need to factor in the team’s velocity — or take the appropriate assumptions about it if it’s a new project or team and you don’t have that data yet.

### 2.3 Task

It’s a single unit of work that needs to be done as part of a bigger project. It’s specific and measurable — for example, “Make the login screen background white” is clear enough to understand what’s expected, and you can verify when it’s done.

Often, it’s assigned extra info like who’s responsible, its priority, or status. Tasks like this are used every day to break down big jobs into smaller chunks, and they’re common in tools like Jira, Asana, Trello, or Basecamp.

They’re basically the building blocks of work management.

* **Epic:** User login flow
* **User Story:** “As a user, I want to login to access my account”
* **Tasks:**
* **1.** Create a login form (frontend)
* **2.** Handle the request (backend)
* **3.** Add form validation
* **4.** Create unit tests
* **5.** Validate UX designs

### 2.4 Epic

It’s a big, high-level piece of work, usually too large to complete within a single sprint (but not impossible). It represents a business goal — for example, user login in an app. It’s broken down into smaller tasks and user stories.

### 2.5 Project

A project is a big piece of work with a clear start and finish, aimed at creating a specific solution — like a mobile app. It has a clear business goal, involves people with different roles, and is made up of multiple epics.

Projects can last from weeks to months or even years. These days, they’re often managed using Agile methods like Scrum or Kanban.

### 2.6 Complexity

This is the level of technical difficulty involved in completing a task, feature, or project. It doesn’t mean how long it will take, but it affects risk, raises costs, and increases the chances of mistakes or changes.

Common factors that add complexity include things like unusual architecture, complicated designs, edge cases, unclear business or tech requirements, new technologies, or just the overall scale of the work.

**Does complexity affect the work?**
*Definitely yes. Tasks that take the same amount of time can have very different levels of complexity. Having too many complex tasks in one sprint significantly increases the risk of delays, which in turn pushes up rates and safety buffers. Complexity is usually assessed using story points or other point-based methods like t-shirt sizing or just the Fibonacci sequence. Only after figuring out a task’s complexity can we start to predict how long it’ll take a specific person to complete it. That time depends on the developer’s skills and how well they know the project or technology. For example, a junior might take 5 days to finish a task that a senior can do in 2. From there, by calculating the cost — time \* rate + buffer + margin — we can set expectations and assign the right person to the job.*

* **Task:** "Add login via Google account"
* **Complexity:** 5/6 (requires OAuth, tokens handlers, integrations)
* **Time:** 3 days for senior developer, 6 days for junior developer
* **Cost:** 2400€ (senior) vs. 1800€ (junior) - but the senior gets it done twice as fast.

## 2.7 Storypoint

Story points are used to estimate the complexity, effort, and uncertainty of tasks or user stories. They are not hours, days, or any other unit of time.

They’re usually assigned using the Fibonacci sequence: 0.5, 1, 2, 3, 5, 8, 13, 20, and so on. That’s because in most cases, it’s hard to precisely tell the difference between, say, a 5 and a 6 — but it’s easier for the team to say whether something is a 5 or an 8.

Simply put, a task rated at 5 story points is roughly twice as hard as one rated at 2 points. After using this system for a while, teams can measure their velocity — how many story points they complete per sprint (e.g., 30 story points per sprint).

**Story points are a planning tool, not for micro-managing!**

Below I've described the basic differences between storypoints and hours.

*Tab. 1 Differences between storypoints and hours*

|                    | Storypoint                                                                                           | Hour                                                                                       |
| ------------------ | :--------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------- |
| **What is it?**    | Relative unit of complexity                                                                          | Unit of time                                                                               |
| **Who estimates?** | Developer team or just one developer (on planning for example)                                       | Developer team or just one developer with a manager                                        |
| **For what?**      | Sprint planning, measurement of velocity                                                             | Pricing, planning, roadmaps                                                                |
| **Why?**           | Comparing tasks, predicting performance, estimating task difficulty, and then planning them properly | Estimating the cost of completing a task, project, or feature. Allocating developers time. |
| **Accuracy**       | Approximate and resistant to differences in developers skills                                        | Seemingly precise — but can be misleading without data                                     |
| **When NOT?**      | Not used for pricing or contracts (e.g., fixed-price), because story points ≠ hours                  | Don’t estimate on your own without involving developers.                                   |

## 3. Why is IT so different from manufacturing?

The main difference between IT and traditional manufacturing is that every project is unique. In mass production, we’re used to repeating the same process to make a batch of products, and that process is strictly standardized.

In IT app development, however, there are big differences between clients, their expectations, and the specific requirements of each technology. Because of that, we can only standardize parts of the process — but it will never be a repeatable, assembly-line style production, since every app is different.

I don’t mention the client for nothing — they play one of the key roles in IT. The client isn’t just the end user, they’re an active part of the creation process. Their needs shape the app, and their decisions — often made during development — impact how the work progresses. Developers have to be ready to adapt to changing client requirements throughout the entire process.

Another important factor is the fast pace of technology. In IT — especially in mobile app development — new tools, libraries, and even entire architectures appear week after week. A perfect example is React Native, a technology that has really taken off in recent years, with practically every update bringing something new and innovative. Not long ago, I had to face updating the tech stack in one of the apps I was working on. It turned out that during that time, React Native switched to a new architecture ([https://reactnative.dev/architecture/landing-page](https://reactnative.dev/architecture/landing-page)).

Updating the environment and moving to the new architecture caused many libraries used in the project to lose backward compatibility. This forced me to find new solutions, quickly learn them, and implement them into an already developed environment. What usually takes a few hours ended up taking several days 🙂

Building cross-platform mobile apps comes with another big challenge: the differences between platforms. iOS and Android evolve independently, have different requirements, offer different solutions to the same problems, and can cause unpredictable issues. Seemingly simple tasks can end up delayed significantly due to platform-specific quirks, unexpected bugs, or the need to find alternative solutions. Take, for example, blocking screenshots in an app. On Android, it’s pretty simple — you just add FLAG\_SECURE in the MainActivity. On iOS, there’s no native way to do this, so you either use some GitHub solution or write a native method yourself that replaces any screenshot or screen recording with a black screen while the app is running. Sounds easy? But does it still sound that simple when you imagine getting this task as a Junior React Native Developer with only three months of experience and no context? :)

As a result, working in IT means constant learning, adaptation, and flexibility. It’s an industry where relying on fixed patterns and well-trodden paths is difficult. The ability to respond to change and solve problems before they become critical is one of the most important qualities for both developers and companies.

## 4. Common misconceptions

### 4.1 “2 developers = 2x faster”

Not necessarily. Breaking tasks down isn’t always possible because some things have to be done sequentially. A great example is building a mobile app from scratch. It’s hard to create a guest filter screen if the guest list doesn’t exist yet or is being worked on by another developer at the same time 🙂 On top of that, there are merge conflicts, code reviews, and synchronization issues. As you can see, that already adds up — and we haven’t even mentioned the most important part: communication, which grows exponentially: 2 people = 1 connection, 4 people = 6 connections.

### 4.2  “You’ve done it before, so you’ll do it quickly.”

In point 3, I explained the difference between an IT project and manufacturing with a flat timber connector. A similar argument applies here. Every project is different — it has its own architecture, unique requirements, changing technologies, and a different client and business goals.

For comparison, when I was a junior developer, I implemented authentication using Okta OAuth. In the next project, the requirement was to use Azure. I assumed the implementation would be very similar. Unfortunately, I was very wrong. Azure had its own client requirements (which at the time caused issues with React Native), so I had to write a custom solution. This in turn required learning the entire process of attaching and intercepting tokens so that Azure could handle it properly.

The time difference was significant — what used to take about a week with Okta, took up to a month with Azure.

### 4.3 “It's just frontend”

You can probably guess how often I’ve heard this one :) “It’s just frontend” often means dealing with responsiveness across devices, cross-platform or cross-browser differences, custom animations and components, and various APIs.

## 5. Summary

Keep these things in mind, and you’ll change your approach to estimation — and the whole industry — by 180 degrees.

#### - Estimation is an art

Let’s remember there’s no mathematical formula for a perfect estimate. The biggest factor affecting its accuracy is experience. As teams, developers, and managers, we have to accept that mistakes will happen. What matters is learning from them and not repeating them in the future.

#### - Uncertainty is normal

It’s natural not to be 100% sure about your estimate. That’s why, in my opinion, the best way to communicate is using ranges instead of exact numbers (like 1–2 weeks instead of 8 days). Unknown unknowns will always pop up, so having a buffer for unpredicted situations helps protect the team or developer from negative consequences.

#### - Communication between developers and business is a key

Developers are the technical experts, while the business side knows the context and priorities. Transparent communication about risks and assumptions, along with understanding business goals, leads to better estimates.

#### - Document your estimates.

It will help you in the future, and over time you’ll notice which mistakes you managed to eliminate.

#### - Don’t be afraid to be conservative

It’s better to deliver something earlier than later. Try to add buffers to your estimates. Remember, the client will always be happier if you deliver in 2 days when the estimate was 3 days, rather than delivering in 3 days when the estimate was 2 days :)

#### - Estimate as a whole team involved in the project (and if your team is just one person, seek advice from others).

#### Remember: "Under-promise, over-deliver"

A look at the estimation processes in IT through the eye of an experienced React Native developer.

Why are estimations so tough in software development?

In the past year, the term **AI agent** has gone from buzzword to battleground — not just for hype, but for real productivity. You may have seen headlines about “agentic coding” or “task-completing AI,” but here’s the truth:

> **AI agents aren’t just a trend. They’re redefining what it means to be an efficient, modern developer.**

Let’s break down what AI agents are — and why every dev should start using them.

## What Is an AI Agent?

In simple terms, an **AI agent** is a piece of software that can:

1. **Understand a task or goal**
2. **Plan out how to achieve it**
3. **Take actions independently** — like writing code, testing, running commands, or querying APIs
4. **React to outcomes** and adjust behavior

So while traditional AI (like GitHub Copilot or ChatGPT) might autocomplete your function or help debug a line, an AI agent can **fix the bug, write the test, run it, and open the PR** — all on its own.

Agents turn AI from a *smart tool* into a *semi-autonomous coworker*.

## Ok, so how do AI Agents work?

Under the hood, most agents are powered by a set of puzzles like:

* **Large Language Models (LLMs)** like GPT-4 or Claude
* **Memory/context** to track what they’re doing over time
* **Tool access** — such as shells, APIs, file systems, codebases
* **Planners** that decide what step to take next
* **Feedback loops** (sometimes even self-correcting behavior)

Frameworks like **OpenAI Assistants API**, **LangChain**, **AutoGPT**, and **Microsoft Copilot Agents** are leading this movement — letting devs create or integrate these agents into workflows with minimal setup.

## What AI agents are good at?

The answer is obvious, tedious generic task that most of the devlopers are alergic to. Here’s what this looks like in practice:

### 1. **Code Refactoring & Cleanup**

Agents can scan your repo, identify code smells, apply consistent formatting, and even modernize legacy code (e.g., converting class components to functional ones in React).

### 2. **Security & Dependency Updates**

Instead of just warning about vulnerabilities, an agent can:

* Update the dependency
* Check compatibility
* Run your test suite
* Open a PR
  All while you grab coffee.

### 3. **DevOps & Automation**

From provisioning infrastructure to restarting stuck services, AI DevOps agents are being deployed to **monitor, act, and fix problems** before you even see the alert.

## So… Do AI Agents Actually Make You More Efficient?

Yes — and here’s the evidence:

* **50–80% time savings** on routine tasks like linting, formatting, test generation, and dependency updates.
* **Fewer context switches**: You stay in the flow while the agent handles setup, docs, boilerplate, and cleanup.
* **Shorter lead times**: By automating repetitive coding or debugging steps, you move from idea to PR faster.
* **Better DX**: Developers report higher satisfaction when they’re solving problems — not chasing broken configs or repeating git commands.

> The result? You write less boilerplate and do more creative, high-leverage work.

Companies like **GitHub**, **Microsoft**, **Replit**, and **Sourcegraph** are already using agents in production — not just as proof-of-concept, but to **automate 20–40% of routine developer workloads**.

## Not Replacing Developers — Empowering Them

A common fear is: *"Are agents here to replace us?"*

But the truth is: **they’re here to elevate us**.

AI agents aren’t taking your job — they’re taking your Jira tickets!&#x20;

We're entering an era where understanding how to **orchestrate and collaborate with AI agents** will be as essential as knowing Git or Docker. The devs who adopt them early — and learn how to guide them effectively — will outpace their peers dramatically. If you want to be a more efficient developer, don’t just use AI for autocomplete -&#x20;
**start building with agents, start working with agents.**

AI Agents: The New Teammates Making Developers 10x Faster

Let's start with the basics. A URL (Uniform Resource Locator) is simply a unique address that allows you to find a particular page, file or resource on the web. By typing in a URL in your browser, you end up exactly where you want to go - whether it's to a shop homepage, a blog article or an image. Without URLs, the internet would be a pure chaos, because there would be no way to pinpoint where the content is.

**What is a URL and what does it consist of?**

If you're wondering: what is a URL and what does it look like, it's worth knowing that each URL is made up of several elements:

* a protocol (usually https or http)
* domain (e.g. twojastrona.pl)
* path (e.g. /blog/what-to-address-url)
* sometimes parameters (e.g. ?sort=desc)
* excerpt (e.g. #section1)

An example URL might look like this:
[https://yourpage.com/blog/adres-url?sort=desc#section1](https://aexol.com)

**URLs and SEO - why is it important?**

OK, but what is a URL in the context of SEO? It turns out that the URL is one of the first elements that both search engines and users look at. A well-constructed URL helps Google understand what the page is about, and helps the user decide more quickly whether to click on a search result.

A friendly URL, i.e. one that is short, readable and contains keywords, can improve a page's visibility in Google. An example? If you run a blog about travel, it's better to use url: *yourwebsite.co.uk/blog/japan-trip than yourwebsite.co.uk/blog/?id=1234*.

**Important rules for creating URLs for SEO**

Before going into the specific rules, it is worth emphasising that proper URL design is the basis for effective SEO optimisation. A friendly and well-thought-out URL not only makes it easier for search engine robots to index your site, but also improves the user experience, increasing your chances of ranking higher in search results. Below, you will find key tips to help you create URLs that follow SEO best practices.

* Use the https protocol - this builds trust and is a signal of quality to Google.
* Use short, concise and logical paths.
* Include keywords related to the content of the page, but don't overdo it.
* Separate words with hyphens (not underscores).
* Avoid Polish characters and special characters.
* Don't change URLs for no reason - it can hurt SEO.

**URL - what does it mean for the user?**

A well-designed URL is not only a nod to search engines, but also a convenience for visitors. A clear url is easier to remember, copy and share. This makes users more likely to return to the site and recommend it to others.

**Summary**

URL is an online address through which anyone can reach a specific page or file. In the context of SEO, the URL is one of the key elements influencing SEO and user perception of a website. It is worth ensuring that it is clear, unique and complies with SEO best practices. A well thought-out url can be your ally in the fight for better positions in Google.

URL - what is it?

Hexagonal architecture, or hexagonal architecture, is a design pattern that is gaining popularity in the programming world. Its goal is to create applications with loosely coupled components that can be easily exchanged and tested independently of external dependencies. In this article, we'll explain what exactly a hexagonal architecture is, what its key elements are, and why you should use it. Finally, we will provide practical examples to help you better understand how to implement this pattern in your daily work.

## What is hexagonal architecture?

Hexagonal architecture, also known as ports & adapters architecture, was proposed by Alistair Cockburn in 2005. Its main idea is to separate the business logic (domain) from any external dependencies, such as databases, user interfaces or external APIs. This makes the application more modular, easier to maintain and test.

Unlike traditional layered architecture, where dependencies run from higher layers to lower layers, in hexagonal architecture dependencies are directed from external components to the inside of the application, i.e. the domain. It is the domain that defines the ports - the interfaces of communication, and the adapters are their implementations on the external side.

## Key elements of hexagonal architecture

1. **Domain (Core)**
   This is the heart of the application, where the business logic and use cases reside. The domain does not know the implementation details of external systems and does not depend on them.
2. **Ports**
   These are the interfaces that define how the application communicates with the outside world. Ports can be input (e.g., accepting requests from the user) or output (e.g., sending data to a database).
3. **Adapters**
   Implement ports and are responsible for communicating with specific technologies, such as databases, user interfaces, APIs or external systems. Adapters can be easily replaced without affecting business logic.

## Advantages of using hexagonal architecture

* **Modularity and interchangeability of components**
  Thanks to the clear separation between ports and adapters, technologies can be easily swapped, such as changing the database or user interface without interfering with business logic.
* **Ease of testing**
  Business logic is completely decoupled, allowing you to test it in isolation without running external systems.
* **Independence on frameworks and technologies**
  Domain code does not depend on specific libraries or frameworks, making it more stable and easier to develop.
* **Support for Domain-Driven Design (DDD)**
  Hexagonal architecture works well with the DDD approach because it focuses on the domain and its use cases.

## Practical examples of using hexagonal architecture

To get a better understanding of how hexagonal architecture works, it's worth looking at some practical examples from different domains.

**E-commerce application**

Imagine an online sales application. At the center (domain) we have the logic for managing orders, products and payments. Ports define how the application communicates with the outside world:

* **Input port** - REST API accepting orders from customers.
* **Output port** - the interface to the payment system that processes transactions.

Adapters implement these ports:

* REST adapter handles HTTP requests and forwards them to the domain.
* The payment adapter integrates with an external service, such as PayU or Stripe.

With this approach, if we decide to change the payment system in a year's time, we only need to replace the payment adapter without modifying the business logic.

**Content management system (CMS)**

In a CMS, the domain is responsible for managing articles, users and permissions. Ports can include:

* **Input port** - a user interface (such as an admin panel) or API for publishing content.
* **Output port** - access to a database or file system for storing images.

Adapters are specific implementations:

* Web frontend as an input adapter.
* A database adapter, such as for PostgreSQL or MongoDB.
* A cloud adapter, if storing files on Amazon S3.

Thanks to the hexagonal architecture, we can easily replace the database or add new publishing channels without affecting the domain.

## How to start implementing hexagonal architecture?

1. **Define the domain and its boundaries**
   Focus on the business logic and use cases that are the heart of your application.
2. **Define the ports**
   Define interfaces for communication with the outside world - both input and output.
3. **Create adapters**
   Implement ports for specific technologies, such as databases, APIs, user interface.
4. **Test the domain independently**
   By isolating business logic, you can write unit tests without running external components.

## Summary

Hexagonal architecture is a pattern that helps create flexible, testable and maintainable applications. By clearly separating the domain from external dependencies, applications based on hexagonal architecture are more resistant to technological changes and easier to develop.

Practical examples show how this pattern can be applied to different types of applications - from e-commerce to CMS to mobile applications. If you want your projects to be more modular and easier to maintain, you should consider implementing hexagonal architecture.

Do you have questions about implementing hexagonal architecture or want to learn about tools that will make working with this pattern easier? Contact us!

Hexagonal Architecture - what is it and why is it worth knowing?

In recent years we have been hearing more and more about gamification, also known as gamification. These terms are often used interchangeably, but both refer to the same idea - the use of game elements in contexts not directly related to entertainment. In this article we will explain what exactly gamification is, what its key assumptions are and why it is gaining so much popularity in business, education and marketing.

## Gamification what is it? Definition and basics

Gamification is the process of implementing mechanisms known from games, such as points, rankings, progress bar, challenges or badges, into processes such as marketing, education, training or sales. The goal is to increase user involvement, motivate users to take specific actions and build positive habits through fun and competition.

In practice, gamification involves making everyday tasks that may seem boring or monotonous more attractive and rewarding. This makes users more willing to engage in educational, marketing or business processes.

## Key tenets of gamification

1. **Mechanisms known from games**
   Gamification uses elements such as points, levels, rankings, badges, progress bars, challenges and rewards. They are what create the structure of the game and encourage action.
2. **Motivation and engagement**
   Through competition, cooperation and a reward system, gamification increases users' motivation to perform specific tasks. This makes processes more engaging.
3. **Purposefulness and measurability**
   Gamification is not an end in itself - it has specific business or educational goals, such as increasing sales, improving learning efficiency or building customer loyalty. Effects can be measured by analyzing user performance and behavior.
4. **Adapting to the audience**
   For gamification to be effective, it must be properly tailored to the target audience. The game should be neither too easy nor too difficult so that users feel satisfaction and a desire to continue participating.

## Where does it work best?

Gamification is used in many areas, and its popularity is constantly growing. Here are the most important areas where it is used:

* **Marketing and sales**
  Points-based loyalty programs, contests, quizzes and challenges engage customers, increasing their loyalty and encouraging more frequent purchases from online stores.
* **Education and training**
  Gamification helps students and employees learn better through interactive tasks, quizzes and reward systems that motivate learning.
* **Recruitment and employee motivation**
  HR gamification supports recruitment processes, onboarding and competence development, increasing team engagement and effectiveness.
* **Social and health campaigns**
  Promoting healthy lifestyles, physical activity or environmental activities using challenges and rewards motivates positive change.

## Why does gamification work?

The secret of gamification's effectiveness lies in the natural human need to compete, achieve goals and receive rewards. Gamification elements make even difficult or boring tasks enjoyable and engaging. As a result, users are more willing to perform activities that they might find too challenging or unattractive in traditional settings.

In addition, gamification allows building positive habits and strengthening brand-customer relationships, which translates into long-term business benefits.

## Summary

Gamification, or gamification, is a modern tool that changes the way we engage in various activities - from learning to work to e-commerce shopping. By using mechanisms familiar from games, such as points, rankings and badges, daily tasks become more attractive and motivating. If you're wondering "gamification what is it?" or "gamification what is it?", now you have a fuller picture of how this technique works and why it's worth using.

If you want to introduce gamification in your company or project, it's a good idea to start by defining your goals and selecting the right mechanisms that will best motivate your target audience. This is an investment that can bring tangible benefits in both the business and educational spheres.

Gamification, what is it?

Near Field Communication (NFC) tags are transforming the way we interact with the world, enabling seamless, secure, and instant data exchange between devices. Whether you’re tapping your phone to pay for coffee or unlocking a hotel room with a smart key, NFC tags are the invisible force powering these everyday conveniences.

## What Are NFC Tags?

What are NFC tags? NFC tags are small, wireless data chips that communicate with compatible devices, like smartphones or an NFC reader, when brought within a few centimeters of each other. Unlike their predecessor, RFID, which only allows one-way communication, NFC enables both one-way and two-way data exchange, making it ideal for interactive applications such as mobile payments and secure access control.

## How Do NFC Tags Work?

How does NFC work? NFC tags operate over short distances (typically up to 4 inches), using radio waves to transfer data. They don’t require batteries; instead, they draw power from the device that reads them, such as your smartphone or an NFC reader. This makes them cost-effective and easy to deploy in a variety of environments. Each NFC interaction is a secure, encrypted process, minimizing the risk of data theft or accidental transactions.

## Types of NFC Tags

NFC tags come in several types, each suited for different use cases:

* Type 1: Basic, low-cost, ideal for simple tasks like sharing URLs.
* Type 2: Slightly more advanced, used for event tickets and low-value transactions.
* Type 3: Higher memory and speed, perfect for e-money and digital IDs.
* Type 4: Versatile, with large memory and fast speeds, commonly used for payments and e-ticketing.
* Type 5: Specialized for sectors like healthcare and inventory management.

## Key Components of NFC Tags

NFC tags are ingeniously simple yet powerful devices, built from three essential components that work together to enable seamless wireless communication:

* **NFC Microchip (IC):** The microchip is the brain of the NFC tag, responsible for storing data and managing communication protocols. It holds information such as URLs, contact details, or authentication codes. The chip is designed to be energy-efficient and is typically placed at the center of the tag to protect it from physical damage.
* **Antenna:** Wrapped around the microchip or embedded within the tag’s structure, the antenna is usually made of copper or aluminum. Its job is to transmit and receive radio waves, allowing the tag to communicate with NFC-enabled devices like an NFC reader. The design and size of the antenna influence the tag’s range and performance.
* **Substrate:** This is the physical base that supports both the microchip and the antenna. Substrates can be made from various materials like plastic, metal, or even paper, depending on the intended use. For example, flexible substrates are used for NFC stickers, while rigid ones are found in cards or key fobs. The choice of substrate determines the durability, flexibility, and application possibilities of the NFC tag.

Together, these components create a compact, battery-free device that can be embedded in everyday objects - from business cards and posters to luxury goods and office equipment.

## Why Are NFC Tags So Popular?

NFC tags have soared in popularity across industries due to their unique blend of convenience, versatility, and security. Here’s why they’ve become indispensable:

* **Effortless Interactions:** NFC tags enable instant, contactless data exchange. Users simply tap their smartphones or devices to interact via an NFC reader. No need for manual data entry or complex setups. This makes tasks like payments, ticketing, and information sharing incredibly fast and user-friendly.
* **Wide-Ranging Applications:** NFC tags are used in retail for contactless payments and interactive marketing, in transportation for ticketing, and in healthcare for patient tracking and medication management. They also power smart home automations and event check-ins, making them a flexible solution for countless scenarios.
* **Enhanced Security:** NFC technology uses encrypted communication and requires close physical proximity to operate, reducing the risk of interception or unauthorized access. This makes it a trusted choice for secure transactions and access control.
* **Sustainability:** By digitizing processes that traditionally relied on paper-like business cards, tickets, and brochures, NFC tags help reduce waste and support eco-friendly initiatives. They can also be integrated into supply chains to optimize resource use and minimize overproduction.
* **Customer Engagement:** Brands leverage NFC tags, including NFC stickers, to deliver personalized content, verify product authenticity, and build direct digital relationships with consumers. This boosts brand loyalty and enhances the overall customer experience.

The combination of these factors has made NFC tags a go-to technology for businesses and consumers seeking speed, security, and innovation in their daily interactions.

## Summary

NFC technology is quietly revolutionizing our digital interactions. As adoption grows, expect even more innovative uses in everyday life. You are using NFC technology when paying for goods using your phone or smartwatch, to unlock doors or check in at the gym, trigger smart home routines, or when you connect to your wireless printer with an NFC reader. Curious what are NFC tags and how they could benefit your business? Contact us and let's discuss it!

What Are NFC Tags? The Heart of Contactless Technology Explained

## Ready-made online stores: a great start, but won't they become a roadblock to growth?

**Why are ready-made stores a good choice to start with?**

At the start of an e-commerce business, ready-made store platforms (e.g. Shopify, Shoper, WooCommerce) seem to be an ideal solution. They allow you to quickly launch online sales without investing in costly implementations or hiring developers. Their advantages are:

* Quick setup and ease of use
* Low initial costs
* Ready-made templates and integrations with popular payments and couriers
* No technical knowledge required

For companies with a small number of products and a limited budget, this is often the best way to test a business idea and start getting their first customers.

**When does a ready-made store become a trap?**

As the company grows and the number of orders increases, new needs arise. Off-the-shelf platforms, which were an asset at the beginning, can begin to limit growth. The most common problems are:

* Limited ability to personalize the store and the purchasing process
* Lack of support for non-standard integrations (e.g. with ERP, warehouse systems, loyalty programs)
* Difficulties with optimizing performance when traffic is heavy
* Limitations in expanding functionality (e.g. non-standard promotions, specific product variants)
* High commission or subscription costs when sales are high

As a result, the store that was supposed to facilitate growth begins to block it. The company loses flexibility, and implementing new ideas requires costly workarounds or migration to a more advanced solution.

**Example: migration of magicznyrynek.pl store from Sky-Shop to Deenruv**

A good example illustrating the need to migrate from Sky-Shop to Deenruv is the magicznyrynek.pl store. For its owners, the key challenge turned out to be Sky-Shop's limitations in terms of integration with an external warehouse, where some inventory was stored. The inability to seamlessly synchronize inventory and automatically update product availability prevented further development of the store and effective order management.

Migration to the Deenruv platform made it possible to implement full integration with the external warehouse, ensuring automatic inventory updates and eliminating the risk of errors in order processing. As a result, [magicznyrynek.pl](https://magicznyrynek.pl "magicznyrynek.pl") was able to efficiently scale the business, offering customers up-to-date information on product availability and significantly improving the quality of service. For more details on this migration, see our case study: [magicznyrynek.pl - case study](https://aexol.com/pl/casestudies/magicznyrynek/).

**The importance of SEO and integration with Google Merchant Center**

With the migration to a more flexible platform like Deenruv, new opportunities opened up for effective store SEO and integration with Google tools. One of the key elements turned out to be the correct integration with Google Merchant Center via the Merchant API. Thanks to this solution, it is possible to automatically and continuously update product offerings, which translates into higher quality of presented data and better visibility of products in Google Shopping and other Google services.

The application of SEO best practices - such as optimization of product descriptions, implementation of structured data and regular indexing analysis - allowed the store to increase its visibility in search results and reach new customers. Integration with Merchant Center and consistent SEO efforts contributed to an increase in website traffic and higher conversions, confirming the importance of a comprehensive approach to e-commerce development on a dedicated platform.

### **Summary**

Off-the-shelf e-commerce stores are a great choice to start with - they allow you to get into the market quickly and test your business. However, as your business grows, it's worth regularly reviewing whether the platform is becoming a limitation. At some point, an investment in a more flexible, dedicated solution may be necessary to maintain your growth rate and competitive advantage.&#x20;

Planning to open an online store or need support in upgrading your old store to finally start selling? Learn more about our solutions, effective integration with Google Merchant and SEO best practices - contact us.

Off-the-shelf stores work well when you have few products or are just starting out, but they quickly become a growth blocker

Case Study: Switching from Sky Shop to a more flexible eCommerce engine

If you’ve been doing frontend development for more than a few minutes, you’ve probably felt it - that mix of **frustration, fatigue, and ironic humor** as you watch yet another tool change overnight. Recently, Brad Traversy (a prominent developer educator) vented on social media about how our beloved frontend ecosystem seems to evolve faster than a JavaScript function in an infinite loop.&#x20;

The post went viral, and for good reason: it struck a nerve with developers of **all experience levels**. In this blog post, I want to expand on that sentiment in a humorous yet honest way. Consider this an open letter (or rather, open rant) to the whirlwind world of frontend development, with love from a **tired** but **devoted** developer.

## **1. The Struggle to Stay Up-to-Date**

The JavaScript/Frontend world moves **ridiculously fast**. It’s like trying to ride a roller coaster and drink a cup of coffee at the same time – exciting but inevitably messy. Every week there’s a new framework, a new best practice, or a new build tool. Keeping up feels like a full-time job *on top of* your actual full-time job. Ironically, developers (even experienced ones) often feel guilty for not spending their weekends reading release notes. We’re told we should always be “up to date” with the latest and greatest. But in practice, staying up to date often feels **impossible unless all you do is read docs and Twitter threads 24/7**. The result? A lot of us end up in a state of constant FOMO and fatigue.

Here’s the kicker: this struggle doesn’t just plague **newbies**. Sure, beginners are confused when one tutorial says to use ComponentWillMount and the next tutorial (written 3 months later) says *“nah, hooks now!”*. But even seasoned devs who have been around since the jQuery days are feeling whiplash. One day you’re confidently using a library, and a few months later you return to it and everything’s different. It’s a universal developer experience at this point: **no one is safe from the churn**.

## **2. React Router: Who Moved My Routes?**

Let’s talk about one specific example that’s become a running joke: **React Router**. This is a great library for navigating React apps – or at least it *was* the last time I checked. Then I blinked, and suddenly the way you define routes changed. Then it changed *again*. If you’ve ever upgraded from one version of React Router to another, you know the feeling: “Wait, what happened to \<Switch>? Where did my beloved history.push go?”

The React Router maintainers are incredibly smart folks, but keeping up with the API changes has felt like chasing a moving target. It sometimes feels like they’re rearranging the highway while we’re driving on it. You update a package and suddenly your routing code is yelling at you with deprecation warnings or outright errors. Instead of building features, you're digging through changelogs and migration guides. Fun!

## **3. Tailwind CSS: Config Today, Gone Tomorrow**

Another recent pain point: **Tailwind CSS**. Historically, Tailwind projects came with a tailwind.config.js file. But with the newest versions, that's no longer automatically the case. Tailwind decided to take a CSS-first approach and stopped generating a default config file by default.

Neat for minimalism, sure. But now every tutorial, every starter project, and every developer who expected to find tailwind.config.js is left scratching their heads. Was it a failed install? Did something go wrong? Nope – the tools just changed the rules again. Cue the collective sigh.

## **4. Tutorials on Shifting Sands**

One of the biggest **pain points** in this rapid-change environment is for educators and content creators. Writing a tutorial or recording a course in frontend development sometimes feels like building on quicksand. You pour hours into crafting the perfect explanation of a technology, and by the time you hit publish, something in it is outdated.

Our frustrated friend joked about tutorials getting outdated in *18 days*. That might be only a slight exaggeration. I’ve personally had the experience of following a tutorial that was just a few weeks old and running into *different* results because the library version had moved on. It’s not just frustrating for learners - it’s exhausting for the people making the learning material.

Imagine being a school teacher and every few weeks the alphabet changes order. “Oops, sorry class, *A* is no longer the first letter, we decided to put *Z* in front for performance improvements.” It sounds absurd, but in the land of frontend development, that’s reality.

## **5. Real-World Consequences**

This isn’t just about inconvenience. Many developers work on real projects for real clients. In other domains, things are relatively stable. Backend frameworks tend to maintain backward compatibility for longer. But frontend? We feel like beta testers for someone else’s experiment.

The consequence: developers lock projects to older versions for stability, which creates a gap with the current ecosystem. Upgrading is **risky**. And trying to explain to a client why a fresh app already feels old is never fun.

## **6. Dear Framework Creators: Please Chill**

To the brilliant folks building these tools: we love you. We truly do. But we need to talk.

Here’s what would help:

* **Semantic Versioning and Fewer Surprise Breakages**: Don’t sneak major changes into minor updates. Let us trust version numbers again.
* **LTS Releases and Clear Upgrade Paths**: Let stable projects remain stable. Provide tools or clear guides to help with major transitions.
* **Better Communication**: Warn us. Loudly. Preferably with megaphones. Or changelogs that don’t read like puzzles.
* **Respect the Learning Curve**: Every change impacts thousands of people. Consider the cost. Sometimes stability is more valuable than cleverness.
* **Preserve Backward Compatibility**: If something’s deprecated, don’t yank it out right away. Let us adapt. Gracefully.

We’re not asking for stagnation. Just some balance. Let innovation meet stability halfway.

## **7. Rant Over (Until Next Update)**

We laugh because we love. We joke because it helps us cope. But we keep building. Despite the churn, despite the chaos, we still believe in the beauty of the web and the tools we use to shape it. We just wish those tools would stop breaking our code for fun.

So here’s to all the front-end developers out there: hang in there. You’re not alone. And here’s to the framework authors: thank you for everything – now please stop moving the goalposts every sprint.

Rant over. For now. Until the next version drops…

Consider this an open letter (or rather, open rant) to the whirlwind world of frontend development, with love from a tired but devoted develope

Stop Breaking My Code! 
Riding the Frontend Roller Coaster

State management is a crucial aspect of any React application, and while Redux has long been the go-to solution, many developers are looking for simpler and more lightweight alternatives. One of the most compelling options today is **Zustand**—a small but powerful state management library that offers a minimal API while maintaining scalability. In this post, we’ll dive into what makes Zustand special, how to use it, and why it might be the perfect fit for your next project.

## **1. Why Zustand?**

Zustand (German for "state") is a state management library created by Poimandres, the same team behind popular libraries like Jotai and React Three Fiber. It stands out because:

* **Minimal Boilerplate**: Unlike Redux, Zustand doesn’t require reducers, actions, or extra setup.
* **No Context API Overhead**: Zustand manages state outside of React’s component tree, leading to better performance.
* **Lightweight**: The library is only a few kilobytes in size, making it a great choice for performance-conscious apps.
* **Flexible**: Works with React Server Components, React Native, and even non-React applications.
* **Scalable**: Suitable for small applications as well as complex projects with multiple state slices.

## **2. Getting Started with Zustand**

### **2.1. Installation**

To start using Zustand, install it via npm or yarn:

```bash
npm install zustand
# or
yarn add zustand
```

### **2.2. Creating a Store**

Zustand stores are simple JavaScript functions that return state and actions. Here's an example of a basic counter store:

```ts
import create from 'zustand';

const useCounterStore = create((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 })),
  decrement: () => set((state) => ({ count: state.count - 1 }))
}));
```

### 2.3. Using the Store in Components

Once you have created your store, you can use it inside React components with a simple hook:

```ts
import React from 'react';
import { useCounterStore } from './store';

const Counter = () => {
  const { count, increment, decrement } = useCounterStore();

  return (
    <div>
      <h1>Count: {count}</h1>
      <button onClick={increment}>+</button>
      <button onClick={decrement}>-</button>
    </div>
  );
};

export default Counter;
```

## 3. Advanced Zustand Features

### 3.1. Middleware Support

Zustand supports middleware for logging, persistence, and other advanced features. For example, you can persist state using zustand/middleware:

```ts
import create from 'zustand';
import { persist } from 'zustand/middleware';

const useUserStore = create(persist(
  (set) => ({
    user: null,
    login: (user) => set({ user }),
    logout: () => set({ user: null })
  }),
  { name: 'user-storage' }
));
```

### 3.2. Selective Rerenders

Unlike **useContext**, which triggers re-renders on any state change, Zustand allows for selective state subscriptions, improving performance:
const count = useCounterStore((state) => state.count);
This ensures the component only re-renders when **count** changes, avoiding unnecessary updates.

### 3.3. Asynchronous State Updates

Zustand works well with asynchronous state updates, making it ideal for API calls and other async operations:

```ts
const useDataStore = create((set) => ({
  data: [],
  fetchData: async () => {
    const response = await fetch('https://jsonplaceholder.typicode.com/posts');
    const jsonData = await response.json();
    set({ data: jsonData });
  }
}));
```

### 3.4. Combining Multiple Stores

For larger applications, Zustand allows you to modularize state into separate stores:

```ts
const useAuthStore = create((set) => ({
  isAuthenticated: false,
  login: () => set({ isAuthenticated: true }),
  logout: () => set({ isAuthenticated: false })
}));

const useProfileStore = create((set) => ({
  name: '',
  setName: (newName) => set({ name: newName })
}));
```

These stores can then be used independently or combined as needed.

### 4. When to Use Zustand

Zustand is a great fit for applications that need simple yet powerful state management without the complexity of Redux. It’s especially useful when:

* You need global state without prop drilling.
* Performance is a concern, and you want to avoid unnecessary re-renders.
* You prefer a small, dependency-free state management solution.
* You want easy-to-maintain, modular state management.
* You need a state management solution that works with server-side rendering (SSR) and React Server Components.

|    **Feature**    | **Zustand** | **Redux** | **Recoil** | **Jotai** |
| :---------------: | :---------: | :-------: | :--------: | :-------: |
|  **Boilerplate**  |     Low     |    High   |   Medium   |    Low    |
|  **Performance**  |     High    |   Medium  |    High    |    High   |
|   **Middleware**  |     Yes     |    Yes    |   Limited  |     No    |
| **Async support** |     Yes     |    Yes    |     Yes    |    Yes    |
|  **Persistence**  |     Yes     |    Yes    |     No     |     No    |

## **6. Conclusion**

Zustand provides a compelling alternative to Redux by offering a minimal API, strong performance, and ease of use. Whether you're working on a small side project or a large-scale application, Zustand can help streamline your state management with less boilerplate and better efficiency.

Are you using Zustand in your projects? If not, maybe it's time to give it a try!

Zustand—a small but powerful state management library that offers a minimal API while maintaining scalability

Zustand: A Simple and Scalable State Management Solution for React

When accessing array data in TypeScript, or even JavaScript for that matter, the most commonly used method is the bracket notation: `[]`. While that obviously works, there is a better solution, especially when caring about type safety: the `.at()` method. It might be less known because it was introduced relatively recently in ECMAScript 2022, but it is actually safer and more intuitive. Let's dive into the details and check out what are its advantages.

## Type difference

The key difference is how each method handles types:

* bracket notation `[]`: Always returns type `string`
* array `.at()`: Always returns type `string | undefined`

Lets look at an example:

```ts
   const pkmn = ["Pikachu", "Charizard", "Mew"];
   const pika = pkmn[0]
   const pikaAt = pkmn.at(0)
```

Here you won't see any difference yet, as both methods will return "Pikachu". However things change when you use an out-of-bounds value or an empty array. Let's try to uppercase a value from an invalid index:

```ts
  const pkmn = ["Pikachu", "Charizard", "Mew"];
  const outsideArray = pkmn[4]
  const outsideArrayAt = pkmn.at(4)
  console.log("brackets test", outsideArray.toUpperCase()) // Throws TypeError
  console.log("array at test", outsideArrayAt?.toUpperCase()) // Safely returns undefined
```

While the `.at()` method safely returns undefined when an invalid index is accessed, the bracket method results in a TypeError: Cannot read properties of undefined (reading 'toUpperCase'). This can lead to runtime crashes or build failures, particularly in applications that rely on dynamic data.

The same principle applies to an empty array. For example:

```ts
const emptyArray: string[] = [];
const firstValue = emptyArray[0]; // TypeError
const firstValueAt = emptyArray.at(0); // undefined
```

## Cleaner negative indexing

Accessing elements from the end of an array is something you'll often see when dealing with things like pagination or logging. This is where `.at()` also comes in handy as it does negative indexing in a cleaner and more concise way:

```ts
   const pkmn = ["Pikachu", "Charizard", "Mew"];
   const lastTwo = [pkmn[pkmn.length - 1], pkmn[pkmn.length - 2]];
   const lastTwoAt = [pkmn.at(-1), pkmn.at(-2)];
```

## `.at()` is simply better

While it might seem like a small addition to JavaScript, `.at()` is simply a more intuitive way of accessing array elements. It improves type safety by returning undefined for invalid indices, reducing runtime errors and simplifies negative indexing. While the bracket notation `[]` still works, `.at()` is a modern alternative that aligns with best practices in TypeScript and lets you avoid common errors. While it's not a must-use it's simply a better option for cleaner and type-safe code.

TypeScript is all about type safety, lets look at that while accessing data in an array

Why .at() is Better than [] for Accessing Arrays in TypeScript

As applications grow in complexity, maintaining a responsive and efficient user experience becomes crucial. React, known for its declarative and component-based architecture, has empowered developers to build dynamic applications with ease. However, without attention to performance, these applications can become sluggish, leading to a less-than-ideal experience for users.
In this post, we’ll dive into the essentials of optimising React performance. By understanding how React’s rendering cycle works and utilising the right tools and techniques, we can make our applications run smoothly and respond instantly to user interactions. We’ll walk through tools like the React Dev Tools, strategies to minimise unnecessary re-renders, and advanced concepts like `useMemo`, `useCallback`, and the Suspense API.
Let’s explore how to take full advantage of React’s capabilities, ensuring every component is as efficient and responsive as possible. Whether you’re optimising a complex stateful application or fine-tuning interactivity, these strategies will help you enhance performance without compromising code readability or maintainability.

## 1. Understanding React Dev Tools

React Dev Tools provide powerful insights for identifying and addressing performance bottlenecks within your application. By analysing re-renders, measuring render time, and visualising where resources are being used, you can detect areas needing optimization. Let’s explore the key features of React Dev Tools that are essential for understanding and improving performance.

### 1.1 Components Tab

The Components tab gives a hierarchical view of your application’s component tree. Here, you can inspect the structure and props of each component, as well as observe the state updates that might trigger re-renders.

* **Identifying Rendered Components**: Use this view to see the relationships between parent and child components and spot components that re-render frequently.
* **Viewing Props and State**: Inspect the props and state of individual components to understand what causes a re-render. State and prop changes are common triggers, and this tab helps you pinpoint them.![Viewing Props and State](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/todo-1730914129840.webp)

### 1.2 Profiler Tab

The Profiler tab records and visualises the render time of each component, enabling you to see which parts of your application are slowing down and why.

* **Recording Performance**: Start a profiling session by clicking the “Record” button, then interact with your application. The Profiler records render durations and highlights components taking the most time.
* **Identifying Bottlenecks**: After recording, the Profiler’s flame graph shows where rendering resources are concentrated. Components that take longer to render than others may need optimizations like memoization or state management adjustments.![Identifying Bottlenecks](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/tab-1730914152413.webp)

## 2. React Rendering Cycle

Understanding the React rendering cycle is essential for effective performance optimization. React’s rendering process, designed to be efficient and predictable, still requires careful management to avoid costly re-renders and unnecessary updates across components. In this chapter, we’ll explore how React’s rendering cycle works, what triggers it, and the factors that can cause performance slowdowns.

### 2.1 Overview of the React Rendering Cycle

The rendering cycle in React is the sequence by which React processes changes to the application’s state and props to produce updates on the screen. At a high level, the rendering cycle has three main stages:

* **Reconciliation**: React first reconciles the current virtual DOM with the updated virtual DOM by comparing the two. During this phase, it determines which parts of the UI need to change.
* **Commit Phase**: React then applies the necessary updates to the actual DOM, only changing elements that differ from the last render to minimise expensive DOM manipulations.
* **Re-render Triggering**: A re-render can be triggered by state changes, prop updates, or context updates, which we’ll examine in detail below.

React’s rendering process is optimised by only updating what’s necessary, but when large components re-render frequently, they can cause slowdowns. Understanding what triggers these re-renders and how they propagate through the component tree is key to efficient performance.

## 2.2 Key Factors Impacting Re-Renders

In React, there are several primary triggers for re-renders, each of which affects how efficiently the application performs. Here’s a closer look at these factors:

* **State Changes**: When a component’s internal state updates, it triggers a re-render. React uses this re-render to check if the component’s output should change based on the new state.
* **Prop Updates**: When a parent component’s state changes, it passes the updated props to its child components, triggering re-renders throughout the tree. This can be efficient if managed carefully, but extensive prop-passing can lead to performance bottlenecks.
* **Context Updates**: Context provides a way to share data globally across components without prop drilling. However, when context values change, all components that consume the context re-render.

React’s rendering cycle is designed to maximise efficiency by updating only what’s necessary. However, understanding how state, props, and context influence this cycle empowers developers to target and optimise these updates. By minimising re-renders and managing state effectively, you can ensure a smoother, faster user experience across your application.

## 3. Techniques for Reducing Re-Renders

Reducing unnecessary re-renders is one of the most effective ways to improve React application performance. Every re-render consumes resources, and in large applications, excessive re-renders can cause noticeable slowdowns. This chapter covers essential techniques to manage state and props efficiently, minimise re-renders, and keep your app responsive.

### 3.1 Pushing State Down

Managing state in React often involves deciding where to place it within the component tree. By pushing state down, or lifting state up only as much as necessary, you can reduce re-renders higher up in the tree.

* **When to Push State Down**: If a state is only needed by a specific component or small part of the component tree, keep it local to avoid triggering re-renders in unrelated components.
  * **Example**: In a parent component with multiple children, avoid putting a child-specific state at the parent level if only one child needs it.

### 3.2 Pulling Content Up

On the other hand, some states benefit from being elevated, or “pulled up,” to ensure that updates happen only once at a higher level, instead of in each child.

* **When to Pull Content Up**: When data or functions are shared among multiple child components, it’s often more efficient to manage this state at a higher level and distribute it down through props.
  * **Example**: For a form with multiple inputs that share validation logic, keep validation logic at a common ancestor component to avoid re-rendering each input individually.

### 3.3 Memoization with `useMemo` & `useCallback`

React offers built-in hooks, `useMemo` and `useCallback`, to cache values and functions, preventing unnecessary recalculations or re-creations that trigger re-renders.

* **`useMemo`**: Use `useMemo` to cache expensive calculations, such as sorting or filtering large arrays, based on dependencies.
  * **Example**: Use `useMemo` to store a filtered list, recalculating only when the relevant dependencies change, rather than on every render.
* **`useCallback`**: Use `useCallback` to memoize functions and avoid re-creating them on every render.
  * **Example**: Memoize a callback for a button click handler to prevent passing a new function reference to child components each time.

### 3.4 State Management with `useReducer` and Dispatch

Using `useReducer` instead of `useState` for complex state management can offer more control and improve performance by reducing the frequency of state updates.

* **When to Use `useReducer`**: If state logic is complex, such as toggling multiple flags or updating nested values, `useReducer` provides a way to manage it with a single dispatch function.
* **Dispatch for Efficiency**: Instead of updating multiple states in sequence, `useReducer` lets you consolidate these changes in one dispatch action.
  * **Example**: In a settings panel where multiple options are toggled, `useReducer` can reduce re-renders by handling updates in a single dispatch call rather than separate state setters.
    Each of these techniques—pushing state down, pulling content up, memoization with `useMemo` and `useCallback`, and efficient state management with `useReducer`—offers ways to limit unnecessary re-renders. By implementing them thoughtfully, you can prevent re-renders that slow down your app, ensuring a seamless, efficient user experience.

## 4. Suspense and Fallback Content

Suspense in React offers a powerful way to manage loading states by allowing components to wait for asynchronous data before rendering. This approach is especially useful for creating responsive applications that gracefully handle loading delays and keep the user experience smooth. In this chapter, we’ll explore Suspense, fallback content, and strategies for maintaining interactivity with `useTransition` and `useDeferredValue`.

### 4.1 Using Suspense for Lazy Loading

React’s Suspense component allows you to “suspend” rendering until specific data is ready, simplifying the process of loading content and managing asynchronous operations.

* **How Suspense Works**: Suspense waits for a component to finish loading before rendering it. Until the component is ready, Suspense displays a fallback UI—such as a spinner, placeholder, or message—informing the user that content is on the way.
* **Implementing Suspense with Lazy Loading**: Combine Suspense with React.lazy to dynamically load components only when they’re needed, reducing the initial bundle size and improving load times.
  * **Example**: In a dashboard app, use React.lazy to load specific pages only when users navigate to them, showing a fallback loader in Suspense until the page is fully loaded.

```ts
const Dashboard = React.lazy(() => import('./Dashboard'));

function App() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <Dashboard />
    </Suspense>
  );
}
```

### 4.2 Managing Interactivity with Suspense and `useTransition`

For interactive applications, managing updates without freezing the UI is essential. `useTransition` is a React hook that helps prioritise urgent updates while deferring less critical ones, allowing you to maintain interactivity even with background loading tasks.

* **How `useTransition` Works**: `useTransition` allows you to specify which state updates are less urgent and should occur in the background. When triggered, React treats the transition as a lower priority, keeping the UI responsive and interactive.
  * **Example**: In a search app, `useTransition` can delay the rendering of search results so that user input remains responsive even if results take a moment to appear.

```ts
const [isPending, startTransition] = useTransition();

function handleSearch(input) {
  startTransition(() => {
    setSearchQuery(input);
  });
}
```

* Indicating Loading State: Use `isPending` to show a subtle loading indicator, informing users that background data is loading without interrupting their interaction.

### 4.3 Fine-Tuning with `useDeferredValue`

`useDeferredValue` is a hook that delays non-urgent updates, helping to prevent the UI from freezing when the app processes more intensive updates, like filtering large datasets or re-rendering complex UI elements.

* **How `useDeferredValue` Works**: `useDeferredValue` creates a deferred version of a value that can be updated in a non-blocking way. This allows more urgent updates, like user input, to take precedence over less immediate ones.
  * **Example**: In a product list with a large filter, use useDeferredValue to delay filtering until after the user stops typing, keeping the UI responsive as they type.

```ts
const deferredSearchQuery = useDeferredValue(searchQuery);

const filteredResults = useMemo(
  () => largeDataset.filter(item => item.includes(deferredSearchQuery)),
  [deferredSearchQuery, largeDataset]
);
```

Suspense, `useTransition`, and `useDeferredValue` work together to provide a seamless experience in loading and rendering asynchronous data without compromising responsiveness. By incorporating these tools, you can gracefully manage loading states and ensure your application remains fast and interactive, even under heavy data loads.

## Summary

Optimising performance in React applications is essential to deliver smooth, responsive, and efficient user experiences. Throughout this guide, we’ve covered the key tools and strategies that can make a real difference in how your app performs:

* **React Dev Tools**: Start by analysing your application with React Dev Tools to detect unnecessary re-renders and pinpoint bottlenecks in the Components and Profiler tabs. Visual indicators, like the green re-render borders, make it easy to spot components that need optimization.
* **Understanding the Rendering Cycle**: Familiarise yourself with React’s rendering cycle and the triggers behind re-renders. By managing state, props, and context efficiently, you can control which components re-render and minimise performance overhead.
* **Reducing Re-Renders**: Techniques like pushing state down, pulling content up, and using memoization hooks (`useMemo` and `useCallback`) help reduce re-renders across your application. When working with complex state logic, `useReducer` can provide a more efficient update model.
* **Suspense and Interactivity**: React’s Suspense, in combination with `useTransition` and `useDeferredValue`, allows you to load data gracefully without compromising interactivity. These tools help you balance loading states, prioritise updates, and maintain a smooth experience, especially in data-intensive applications.

By combining these strategies, you’ll be well-equipped to tackle performance challenges in your React applications, ensuring that they remain responsive and fast as they grow in complexity. Whether you’re handling asynchronous data with Suspense, reducing unnecessary re-renders, or leveraging React’s Dev Tools to track and analyse performance, each technique contributes to a faster and more efficient React app.

Learn how to improve app performance by understanding React's rendering cycle and utilizing hooks to their full potential.

 Key aspects of React Performance

Learn how to enhance the structure and maintainability of applications by using React's best practices for managing state and component logic.

React Design Patterns

Managing Node.js dependencies has long been a challenge for developers, as it often involves a trade-off between **ease of use**, **speed**, and **disk space**. Traditional package managers like **NPM** and **Yarn** have their strengths and weaknesses, but a "new" contender has emerged to offer a fresh approach to dependency management. In this article, we'll explore what **PNPM** is, how it works, and why it might be a valuable addition to your Node.js toolkit!

### What is this "new" contender?

"New" because even though PNPM is often referred to as a "new" package manager due to its innovative features and recent rise in popularity, it was officially released all the way back in 2016. It has only recently started to gain more attention and wider adoption within the Node.js community.

In general terms PNPM (which stands for "**Performant NPM**") is a package manager for Node.js applications, created to address some of the known shortcomings of traditional package managers. PNPM's primary goal is to simplify the dependency management process, reduce disk space usage, and improve the installation and update speeds of packages.

### Key Features

To highlight its strong points and advantages it has over other package managers, let's outline the key features provided by PNPM:

* **Linking Dependencies**: One of the key features of PNPM is its approach to dependency linking. Unlike NPM and Yarn, which create copies of packages for each project, PNPM uses a symbolic link approach. This means that multiple projects can share the same dependency if they require the same version - which significantly reduces disk space usage.
* **Parallel Installation**: PNPM is designed to install packages in parallel, taking advantage of multi-core processors. This approach can significantly speed up the installation process, making it a great choice for projects with many dependencies.
* **Local Package Store**: PNPM maintains a global storage for packages on your system, allowing it to re-use packages across different projects. This eliminates the need for downloading and storing the same packages multiple times.
* **Faster Updates**: PNPM optimizes the update process by only fetching and updating those packages that have changed. This leads to quicker updates and minimizes network and storage usage.
* **Support for NPM and Yarn**: PNPM is designed to be compatible with both NPM and Yarn. It uses a similar package.json format, so transitioning from another package manager to PNPM is relatively straightforward.

### PNPM disadvantages

While PNPM offers numerous benefits, it's important to acknowledge some potential drawbacks:

* **Compatibility Issues**: While PNPM aims for complete compatibility with existing Node.js projects, it may have some issues with certain packages or configurations, particularly in complex or niche projects.
* **Community Adoption/Limited Awareness**: While PNPM has been gaining traction, it does not yet have as extensive a community or ecosystem as more established package managers like NPM or Yarn. This may sometimes result in a lack of resources, tutorials, availability of third-party plugins or community support - especially compared to its widely adopted competitors.
* **Tooling Support**: Some development tools and integrations may not fully support PNPM out of the box. While efforts are ongoing to improve compatibility, developers may encounter limitations when using PNPM with certain tools or services.

While these downsides are worth considering, they are not necessarily prohibitive, and PNPM's unique features still make it a compelling choice for many Node.js projects. As with any tool, weighing the pros and cons based on your specific project requirements and preferences is **crucial**.

### How to Use PNPM

Using PNPM in your Node.js projects is quite simple - just follow this basic step by step guide:

* **Installation**:
  First, you need to install PNPM globally on your system. You can do this using NPM or Yarn with the following command:

```bash
npm install -g pnpm
yarn global add pnpm
```

* **Initialization**:
  Create a new Node.js project or navigate to an existing one and inside its main directory initialize PNPM by running:

```bash
pnpm init
```

This will generate a pnpm-lock.yaml file, similar to package-lock.json or yarn.lock in NPM and Yarn, respectively.

* **Install Dependencies**:
  To install dependencies, use the following command:

```bash
pnpm install
```

This will install packages using PNPM's unique approach, linking common dependencies and optimizing the process.

### Should you switch to PNPM?

PNPM does stand out as a promising tool in the realm of Node.js package managers - it boasts a distinctive array of features tailored to streamline dependency management, expedite installations, and minimize disk space usage.
Leveraging symbolic links, a shared package store, and parallel installation, it effectively tackles the typical issues encountered by developers in Node.js application development. Whether embarking on a new project or seeking to enhance existing ones, PNPM merits serious consideration as a means to refine your Node.js development workflow. Moreover, transitioning to PNPM from other package managers like NPM or Yarn is remarkably straightforward, thanks to its compatibility with existing projects and familiar package.json format. Give PNPM a try, and discover how it can seamlessly integrate into your toolkit, potentially becoming an indispensable asset in your development arsenal!

Is it time to switch over from NPM and Yarn to PNPM?

 Simplify Your Node.js Projects with PNPM

Last weekend I had a strange situation. It all started when I noticed on GitLab that one of my folders in the repository was actually a submodule. It was already late, so I went on Stack Overflow to find a thread about detaching a module from a repository :)

## Restoring git rm files with VSCode

After successfully copying a few commands, I looked at what I've done and thought, oh my god - I deleted the entire folder without committing any changes. What's worse, I found out that when detaching a submodule forcefully, Git uses the rm -rf command. So what now? Well, I tried looking for options in Git, but it dawned on me that no reset would help because these files simply didn't exist in my repo, they were just a submodule with locally uncommitted changes. I could go on about all the methods I tried, but let's cut to the chase - VS Code Local History saved me.

## VS Code Local History

Ok, so it turns out basically every file you ever edit, has its own local timeline saved in VSCode which tracks file saved events. Restoring a file is really simple, all you need to do is:

1. Click Ctrl/CMD + Shift + P
2. Select `Local History: Find Entry To Restore`
3. Filter results by something like folder name
4. Open file
5. Click Tick Icon to Restore It

Going file by file that's exactly how I managed to restore all of my deleted content!

P.S I didn't make this article too long because if you're in a similar situation you're probably looking for a solution asap and googling 'recover git rm files' or going through stack overflow. So no worries - VS Code has got you covered.

Have you ever deleted a few days of work accidentally? I did, but I was able to recover everything!

How to recover files deleted with git rm or how to recover uncommitted submodule with vscode

Over the past weekend, the Tauron Arena in Krakow was hosting the biggest hackathon in Europe - Hackyeah 2023. The competition brought together talented minds from Poland and all of Europe and served as a battleground for IT experts. Of course, participating in such an event isn't only about work and competition, it's also a chance to meet tons of different people from the IT sector and exchange ideas, thoughts and experiences. That said everyone was there to see the main event - tackling technology challenges within a 24-hour time-frame. The category the AEXOL team participated in required the creation of a solution to modernize the education sector using technology.

![Hackyeah](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/hackyeah2-1730907339244.webp)

Our team utilized artificial intelligence to create a complete MVP (Minimum Viable Product) for the GovTech task, combining various tools, skills and technologies. This earned them the third spot in the "Education in Innovation" category and their project caught the attention of both participants and competition judges due to its innovative approach to educational challenges. I'm proud to say that our team created one of the most recognizable projects to emerge from this exceptional event.

## The team

The award-winning team includes Aleksander Bondar (frontend developer), Arkadiusz Kuryło (backend developer), Adam Michałowski (frontend developer), Jakub Sowa (3D graphic designer - external to AEXOL), Adrianna Gregorczuk (leader), and Monika Szypurska (graphic designer - external to AEXOL). Their stack consisted of React, Next.js, TypeScript, GraphQL, Stucco.js, mongoDB, Figma and Blender. It served to combine the various skills of team members and was key in reaching the goal of the challenge. This achievement is the result of a combined effort that took many hours of hard work and dedication from the entire team.
![Hackyeah](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/hackyeah3-1730907356215.webp)
The project was all about the implementation of artificial intelligence to help students pick a university course to study. An effective tool to assist in making crucial life decisions can be a great help in today's world, especially when it comes to decisions as important as choosing the right educational institution or course of study. Our team took on the challenge by using our trained chatGPT model and designing an application around it - allowing users to easily and accurately find schools, educational institutions, or study programs that best suit their individual needs. Their solution could become part of the Education and Science Portal - edukacja.gov.pl!

## Research - Generations Z & Alpha

We know the issues addressed and the goals of the project, but we didn’t really talk about the first step. How did the team come up with the idea for the app, where did it come from, and what research on the topic did they do?

The demographic significance of Generation Z cannot be underestimated. Comprising a substantial 15.4% of Poland's population, this generation faces a slew of unique challenges. Research suggests that the dissatisfaction experienced by young individuals can have far-reaching consequences, making it imperative to address their concerns in a timely manner.
![Hackyeah](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/hackyeah4-1730907380398.webp)
Numerous psychological studies have delved into the impact of unrealized aspirations on mental well-being. The weight of unfulfilled dreams can lead to feelings of frustration and disillusionment, underscoring the importance of providing avenues for young people to pursue their ambitions. Social psychology research consistently highlights the significance of a robust support system. Young individuals who lack adequate support from their immediate surroundings may face hurdles in their personal and professional growth. Initiatives designed to offer mentorship and guidance during the transition to adulthood are vital for their development.

As we look toward Generation Alpha, often labeled as "Always on," early economic and socio-scientific projections indicate a preference for highly personalized experiences, empowerment, and innovations. Understanding these evolving preferences is essential for shaping the future landscape. Emerging as a potential remedy to the multifaceted challenges faced by both Generation Z and Generation Alpha, competent AI administration offers guidance and support in navigating complex life and career decisions. Harnessing the power of AI can be a game-changer in addressing the needs of these tech-savvy generations.
![Hackyeah](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/hackyeah5-1730907405673.webp)
In crafting their solution, the team drew inspiration from the immersive qualities observed in popular gaming platforms like Roblox and Minecraft. These virtual environments have been studied extensively in the context of user engagement and experience. By incorporating elements of immersion and CAVE, they aimed to create a product that not only captures attention but also evolves in multiple directions, all while preserving its original MVP concept.

## Fine-tuning

Now that we have learned about the issues our friends faced, we can move on to technical matters. As we know the team turned their minds and capacities towards so-called fine-tuning. In the ever-evolving landscape of artificial intelligence, fine-tuning has emerged as a crucial technique for enhancing the capabilities of pre-trained models. Fine-tuning is a process that allows us to adapt these models to perform specific tasks with greater accuracy and relevance.
![Hackyeah](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/hackyeah5-1730907405673.webp)
Before we dive into the intricacies of fine-tuning, it's essential to grasp the concept of pre-trained models. These models are AI systems that have been trained on vast amounts of data, typically from the internet, to learn the patterns and structures of natural language or images. A well-known example of a pre-trained model is OpenAI's GPT (Generative Pre-trained Transformer) series for natural language processing, which includes GPT-3.5, the foundation of this AI.

Pre-trained models are designed to perform a wide range of tasks, from text generation to language translation, sentiment analysis, and more. However, they might not be optimal for specific, domain-specific, or fine-grained tasks. This is where fine-tuning comes into play.

Fine-tuning is akin to the process of "specialization" for pre-trained models. It is the process of taking a general-purpose, pre-trained model and adapting it to excel in a specific task or domain. Think of it as giving a versatile tool a sharpened edge for a specific job. Instead of starting from scratch and training an entirely new model, fine-tuning leverages the existing knowledge of the pre-trained model, saving time, computation resources, and data. In the world of artificial intelligence, fine-tuning has emerged as a critical technique for enhancing the capabilities of pre-trained models. It bridges the gap between generic AI and task-specific AI, offering an efficient and effective way to adapt models to specific needs. As AI continues to play a pivotal role in various domains, the importance of fine-tuning cannot be overstated, as it enables us to unlock the full potential of these powerful AI systems.![Hackyeah](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/hackyeah6-1730907465865.webp)

## Congratulations

I want to extend my heartfelt congratulations to our team for winning a prestigious award and achieving widespread recognition for their efforts. Hopefully, their project will make a significant contribution to the Polish education sector through the use of the latest technologies, including artificial intelligence. The integration of AI into educational processes holds immense potential to greatly improve the quality and accessibility of education.

Thanks to your efforts, we saw how students can have the opportunity to use AI in an engaging and effective manner while preparing for a future where technology plays an increasingly vital role. Getting a well-deserved 3rd place in our first go at such a large event serves as a recognition of your hard work and commitment. It also serves as an encouragement to participate in similar events in the future for everyone at Aexol. So once again: congratulations!

Our team got 3rd place showcasing an AI powered app aimed at educational innovation and empowering future generations.

Aexol shines at Europe's biggest hackathon - HackYeah 2023!

Reducing boilerplate code and minimizing code repetition is something all developers pay close attention to in their projects. Same with the ease of use of all the various tools, as they are designed to save time and that’s exactly what I’ll try to show in this tutorial!

We’ll get to know how to properly install and handle fonts in iOS and Android, and create an easy and intuitive typography system that will save time and reduce the amount of code when developing both Single and Monorepo apps. It doesn't matter if your app has a lot of text or not - this solution will work great for either. Most importantly, the system we will create will be based on font type, size and weight. This will let us build fully editable custom components, which means we’ll have a lot more possibilities in the styling of our app.

```ts
<Text style={{...typographySystem.yourFont, other styles}}>Your text</Text>
```

1. Settings

I use `Yarn`. If you're using `NPM`, don't worry - it will be very similar.

1. `.ttf` files

Download the font files using for example: `google fonts`. For this article, I’ll be using a "Poppins" font.

1. Fonts directory

After downloading, create a `fonts` directory in your `assets` folder. Move all the font files into this fonts directory. The path to your font files should look like this:

* **Single app**
  `my-app/src/assets/fonts`
* **Monorepo apps**
  `mono-repository/packages/shared/src/assets/fonts`

#### **Create a `index.ts` file to create and export const your font files.**

In your `fonts` directory create a `index.ts` file. It should look like this:

```ts
export const PRIMARY_FONT_REGULAR = "Poppins-Regular";
export const PRIMARY_FONT_SEMI = "Poppins-SemiBold";
export const PRIMARY_FONT_BOLD = "Poppins-Bold";
export const PRIMARY_FONT_THIN = "Poppins-Thin";
export const PRIMARY_FONT_MEDIUM = "Poppins-Medium";
export const PRIMARY_FONT_LIGHT = "Poppins-Light";
export const PRIMARY_FONT_EXTRALIGHT = "Poppins-ExtraLight";
export const PRIMARY_FONT_EXTRABOLD = "Poppins-ExraBold";
export const PRIMARY_FONT_BLACK = "Poppins-Black";
```

> For prettier paths, you can create an index.ts file in your assets folder. The body of this file should be something like this: `export * from "./fonts";`

#### App configuration

Create a `react-native.config.js` file in the root directory of your project. If you are working with a monorepo, please do this for every app in it.

### Example folder structure:

**Single app**

```yaml
  my-app/
    src/
        assets/
         index.ts
            fonts/
                index.ts
                fontFile.ttf
    react-native.config.js
```

**Monorepo**

```yaml
  my-monorepo/
    packages/
        app1/
            react-native.config.js
        app2/
            react-native.config.js
        shared/
            src/
                assets/
                    index.ts
                    fonts/
                        index.ts
                        fontFile.ttf
```

Now edit your `react-native.config.js` file to add the assets path. It should be something like this:

**Single app**

```ts
module.exports = {
  project: {
    ios: {},
    android: {},
  },
  assets: ["./src/assets/fonts/"],
};
```

**Monorepo**

```ts
module.exports = {
  project: {
    ios: {},
    android: {},
  },
  assets: ["../../node_modules/@my-monorepo/shared/src/assets"],
};
```

#### **Creating the typography system**

Now, we can create a typography system. In your `src` directory, create a new folder named `styles`. Inside this folder create a `typographySystem.ts` file.

> For a monorepo do this in your `shared` package directory.

In this file, we can now import our exported consts of fonts, like so:

```ts
import {
  PRIMARY_FONT_BOLD,
  PRIMARY_FONT_SEMI,
  PRIMARY_FONT_REGULAR,
  PRIMARY_FONT_MEDIUM,
} from "@/assets/fonts";
```

> I have absolute imports in my project so bear in mind your 'from' path can be different!

I would also like to use a `StyleSheet` so, let's import it as well:

```ts
import { StyleSheet } from "react-native";
```

> Please, check your import path. Automatic import may be from 'react-native/types' and cause errors!

Now that we have imports, we can create our typographySystem StyleSheet which we will use in our projects! Here's my file as an example:

```ts
import {
  PRIMARY_FONT_BOLD,
  PRIMARY_FONT_SEMI,
  PRIMARY_FONT_REGULAR,
  PRIMARY_FONT_MEDIUM,
} from "@/assets/fonts";
import { StyleSheet } from "react-native";

export const typographySystem = StyleSheet.create({
  H3Bold: {
    fontFamily: PRIMARY_FONT_BOLD,
    fontSize: 24,
  },
  H3Semi: {
    fontFamily: PRIMARY_FONT_SEMI,
    fontSize: 24,
  },
  H3Medium: {
    fontFamily: PRIMARY_FONT_MEDIUM,
    fontSize: 24,
  },
  H2Bold: {
    fontFamily: PRIMARY_FONT_BOLD,
    fontSize: 22,
  },
  H2Semi: {
    fontFamily: PRIMARY_FONT_SEMI,
    fontSize: 22,
  },
  H2Medium: {
    fontFamily: PRIMARY_FONT_MEDIUM,
    fontSize: 22,
  },
  H1Bold: {
    fontFamily: PRIMARY_FONT_BOLD,
    fontSize: 20,
  },
  H1Semi: {
    fontFamily: PRIMARY_FONT_SEMI,
    fontSize: 20,
  },
  H1Medium: {
    fontFamily: PRIMARY_FONT_MEDIUM,
    fontSize: 20,
  },
  subtitle1Bold: {
    fontFamily: PRIMARY_FONT_BOLD,
    fontSize: 18,
  },
  subtitle1Semibold: {
    fontFamily: PRIMARY_FONT_SEMI,
    fontSize: 18,
  },
  subtitle1Medium: {
    fontFamily: PRIMARY_FONT_MEDIUM,
    fontSize: 18,
  },
  subtitle1Regular: {
    fontFamily: PRIMARY_FONT_REGULAR,
    fontSize: 18,
  },
  body1Semibold: {
    fontFamily: PRIMARY_FONT_SEMI,
    fontSize: 16,
  },
  body1Medium: {
    fontFamily: PRIMARY_FONT_MEDIUM,
    fontSize: 16,
  },
  body1Regular: {
    fontFamily: PRIMARY_FONT_REGULAR,
    fontSize: 16,
  },
  body2Semibold: {
    fontFamily: PRIMARY_FONT_SEMI,
    fontSize: 14,
  },
  body2Medium: {
    fontFamily: PRIMARY_FONT_MEDIUM,
    fontSize: 14,
  },
  body2Regular: {
    fontFamily: PRIMARY_FONT_REGULAR,
    fontSize: 14,
  },
  caption1Semibold: {
    fontFamily: PRIMARY_FONT_SEMI,
    fontSize: 12,
  },
  caption1Medium: {
    fontFamily: PRIMARY_FONT_MEDIUM,
    fontSize: 12,
  },
  caption1Regular: {
    fontFamily: PRIMARY_FONT_REGULAR,
    fontSize: 12,
  },
  caption2Semibold: {
    fontFamily: PRIMARY_FONT_SEMI,
    fontSize: 11,
  },
  caption2Medium: {
    fontFamily: PRIMARY_FONT_MEDIUM,
    fontSize: 11,
  },
  caption2Regular: {
    fontFamily: PRIMARY_FONT_REGULAR,
    fontSize: 11,
  },
  tooltipSemi: {
    fontFamily: PRIMARY_FONT_SEMI,
    fontSize: 10,
  },
  tooltipMedium: {
    fontFamily: PRIMARY_FONT_MEDIUM,
    fontSize: 10,
  },
  tooltipRegular: {
    fontFamily: PRIMARY_FONT_REGULAR,
    fontSize: 10,
  },
});
```

## Single app

#### Linking

Once we have all that configured, we can create links to our fonts for iOS and Android. If you have React Native ver. >= 0.69, you can use `npx react-native-asset`. For older versions, use `yarn react-native link`. Once that's done save everything and that's it!

#### Use

here's an example use of our typography system:

```ts
import { View, Text } from "react-native";
import { typographySystem, colors } from "@/styles";

export const Title: React.FC<{ content: string }> = ({ content }) => (
  <View>
    <Text style={{ ...typographySystem.H3Bold, color: colors.error.magneta01 }}>
      {content}
    </Text>
  </View>
);
```

## Monorepo

#### Building a shared folder

If you already have `typographySystem.ts` in your `styles` directory, you can then go to the root of the shared folder directory and edit the `index.ts` file there - adding the following at the end of that file:

```ts
export * from "./src/assets";
export * from "./src/styles/typographySystem";
```

Now, the `shared` directory should build correctly!

> To be 100% sure, remember to look at your `dist` folder after the `yarn` command.

#### Linking

Once we have everything else configured, we just have to create links to our fonts for iOS and Android. If you have React Native, ver. >= 0.69 you can use `npx react-native-asset`. For older versions, use `yarn react-native link`. Save everything and that's it! Just remember to do this for every app in your monorepo!

> If you are in the `shared` directory, the correct way to do that is using a script like this:

```bash
    cd ..
    cd app1
    npx react-native-asset (for RN >= 0.69) / yarn react-native-link (for RN < 0.69)
    cd ..
    cd app2
    ...
```

#### Use

If everything is correctly configured, you can now freely use your typography system in your applications.
Here's an example use of the typography system:

```ts
import { View, Text } from "react-native";
import { typographySystem, colors } from "@my-monorepo/shared";

export const Title: React.FC<{ content: string }> = ({ content }) => (
  <View>
    <Text style={{ ...typographySystem.H3Bold, color: colors.error.magneta01 }}>
      {content}
    </Text>
  </View>
);
```

> If you're having some trouble with a monorepo, try to remove your node\_modules and Pods, and reinstall one more time.

## Correct direction structure

### Single app

```yaml
  my-app/
    src/
        assets/
         index.ts
            fonts/
                index.ts
                fontFile.ttf
        styles/
            typographySystem.ts
            index.ts
    App.tsx
    react-native.config.js
```

**Monorepo**

```yaml
  my-monorepo/
    packages/
        app1/
            App.tsx
            react-native.config.js
        app2/
            App.tsx
            react-native.config.js
        shared/
            dist/ (created after building this package)
            src/
                assets/
                    index.ts
                    fonts/
                        index.ts
                        fontFile.ttf
                styles/
                    typographySystem.ts
            index.ts
```

## Conclusion

Creating a typography system, in addition to the aforementioned code reduction, speeds up the application development process (especially if combined with a styling system and color palette!). If you have any questions, go ahead and let me know. If you do not know how a monorepo works for React Native applications, go ahead and read an [article about that here.](https://blog.graphqleditor.com/react-native-monorepo-with-shared-components)

## Enjoy!

A guide on how to create a React Native typography system for use in all applications including a monorepo and those for Android and iOS.

How to create a React Native typography system

If you’re into Drum and Bass or UK Dance music there's a pretty good chance that you’ve heard of Dj Fresh or that you’ve heard some of his hits on youtube (where he has almost 240 million views and almost 400k subscribers) on the radio or in the clubs. If you're wondering why I'm writing about that here (as this isn't really a blog about music) you should check out what the author of the hit single Gold Dust has been working on lately.

2022 was a pretty big year for artificial intelligence with AI-generated images from MidJourney or Dall-E mini being all the craze for quite a while. With their simple text-to-image interface, it was easy enough to play around with for basically everyone. While it was admittedly fun to play around with generating images of the pope riding a dinosaur or whatever, the bigger implications are for using them professionally. For a simple use case as a copywriter I often need images either for blog posts or website content and usually, I simply have to wait for a graphic designer to create them. Well, I had to before to be exact as that’s where things like FastQL come in.

## FastQL

With FastQL you can quickly prototype and publish a GraphQL API around models like the AI-generated image models from Midjourney, Stable Diffusion or RunwayML (or something less controversial like Huggingface's Mitsua Diffusion which is trained only on public and copyright-free data). While this already sounds cool for a non-coder like myself the key focus here, as the name implies, is on being fast. That's why the key here is using strongly-typed languages to speed up performance:

* **GraphQL**: enables data fetching with a single API call, eliminates over-fetching and provides type-safety.
* **Rust**: is a performance-focused low-level programming language. That's why under the hood, FastQL uses the powerful and extremely fast ActiX Rust web server, enabling 20ms response time

## Usage example

The more impressive part is how it actually works, a single line of code describing your graphql schema leads to a powerful rust API being autogenerated where you can query it via the friendly GraphQL Playground API or with a straight GraphQL query without having to write any API code. Then all you have to do is call the API with a simple query containing the description of what you want to receive.

```gql
{
  Model(prompt: "blog post header image with a DJ") {
    images
  }
}
```

After that, you'll get a response with a link to the generated image, which you can use for (in this example a blogpost header) Obviously the code is secondary here as you could just as easily implement this API into a cms of your choice (like say a markdown editor) and enable its users to get AI-generated images on the fly.

## Fine-tuning

Random AI-generated images are fun in a lot of cases, but you can also personalize them with FastQL by using DreamBooth. This way you can get an image of yourself in front of the Taj Mahal, on top of Mount Everest or anything you can come up with really. While that sounds complicated the process is actually really simple. First, upload 10-12 images (of for example yourself) to a Google Drive folder. Set it to share content with everyone with the link and then prep the tool by giving it that link so that it can analyze the images by using a simple query:

```gql
{
  Model(
    fine_tune_photo_description: "photos of michal"
    gdrive_folder_of_images_link: "https://drive.google.com/drive/folders/example"
  ) {
    images
  }
}
```

After approximately five minutes the tool is ready to provide you personalized images using the same type of prompt description as before:

```gql
{
  Model(prompt: "michal on top of Mount Everest") {
    images
  }
}
```

As you can see FastQL is a great tool to make it easy to create APIs around AI models. It can be connected with some application or cms, letting you use them wherever you need, and in a fast and efficient way (without requiring any knowledge of programming). Going back to the author, it's safe to say DJ Fresh is still putting out hits in 2023, although of a different variety, so give him a follow on GitHub as well as on Youtube.

Check out the repo on [GitHub](https://github.com/happy-machine/FastQL) or read about it in Dan's [piece on medium](https://medium.com/@thisisdjfresh/introducing-fastql-the-python-package-for-rapid-prototyping-and-sharing-of-machine-learning-models-54863236dbaf).

Introducing a blazing-fast and incredibly simple to use API for getting AI-generated images.

DJ Fresh presents FastQL - prototype & publish a GraphQL API

Like many we have followed the State of JavaScript surveys quite closely over the years, as such we were excited to see the announcement of the very first [State of GraphQL](https://2022.stateofgraphql.com/en-US/) survey this year. While our devs are obviously very familiar with JS, GraphQL is our main focus and we were anxious to see what are the trends in its ecosystem. The results surprised us to say the least, we never expected to see our [GraphQL Editor](https://graphqleditor.com/) and [Zeus](https://github.com/graphql-editor/graphql-zeus) included!

## Peak retention

The overall libraries segment already showed some very promising data. GraphQL Editor was in the top 10 of all libraries for user retention and while the usage was lower, it did very well in the 1st quadrant which the authors described as low usage & high retention technologies worth keeping an eye on. While we obviously would’ve liked to see it included in the 2nd quadrant (high retention & high usage), that one was occupied by only Apollo, so we see this as a really good opportunity for growth.

![user retention graph](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/retention-all-1730916031561.png)

The section dedicated to API Builders brought even more optimism as GraphQL Editor ranked #1 overall for retention! We’re really grateful to our users and we hope we can use their feedback to solidify that position in future editions of the survey.

![retention builders](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/retention-builders-1730916050511.png)

## Really high interest

Interest was also really high with GraphQL Editor squarely in the top5 just behind Hasura. This means a lot to us as we ranked far lower in usage and awareness so we hope we can get all those interested users to try our tool (especially taking into account retention was so high)

![interest builders](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/interest-builders-1730916185741.png)

## Zeus got in as well!

GraphQL Zeus was a side project done after hours by our programmers so to see it included was a nice little surprise as well. It’s little wonder it was low in awareness and usage as we did not promote it at all yet. But we see the interest and the potential it has, so you can expect great things in store for it as well!

![interest GraphQL Zeus](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/interest-zeus-1730916203583.png)

## All thanks to you

Overall we can only thank the community for showing us appreciation and interest. All we can promise is that we will continue to work on both these tools to make them even better for our users and attract as many new ones as we can by generating justified interest. The survey’s results gave us a big boost in confidence 💪 and a a clear direction. We’re aiming to really amaze the GraphQL community in the next edition of the survey! 🚀

Read the full survey [here](https://2022.stateofgraphql.com/en-US/)

Both GraphQL Editor and GraphQL Zeus were received enthusiastic feedback in the State of GraphQl survey.

GraphQL Editor appreciated in the State of GraphQL survey

One thing most programmers dislike doing is writing documentation. It's generally seen as a mundane task that you’re forced to do, a sort of chore in software development. It often feels like a waste of time, that could be used coding something new for your web app or other project. Instead that time has to be used on explaining that code to others. Everyone still does do it though, as it is basically the gateway to your project for everyone else. So it is usually worth to sacrifice some time working on one to make things easier for those who might be interested in what you’re working on.

## Not a waste of time

A well written and detailed documentation can be quite a draw, that’s why tech giants like Google and Facebook do work on those for the projects they take under their wing. If you’re looking for inspiration you can check the documentation for Django to see an example of a particularly well done one. Even if you’re not too keen on writing it now it can save you some headaches down the road when you want to interest others in your web app, library, framework or whatever it is you're working on. While some think documentation is insignificant it actually does play a large role especially for things with a steep learning curve or a lot of complexity. For various tools it can even be make or break, as when it comes to application development, most devs prefer to start out with a clear picture instead of working out everything themselves. It's also best to start making documentation gradually so that it grows with your project. Otherwise you can end up with a ton of work somewhere down the line, needing to document everything from scratch for a project that has grown quite large.

## Magidoc

Fortunately there are some tools that can help you create documentation. Yes they wont do literally all the work for you (at least yet) but since the priority is to get it done as fast as possible, any tool that speeds that up should be a boon. One such tool is Magidoc, it's a static documentation auto-generator designed for GraphQL APIs and created using Svelte. Since we’re interested in getting done with documentation as quickly as possible let’s simply check out the features:

* **fast and simple**: Magidoc works out of the box and can generate documentation for each query, type, subscription and mutation in your GraphQL API, by simply using your schema or a live endpoint via an introspection query.
* **easily customizable**: Magidoc uses a simple JavaScript configuration file which lets you customize it to your heart's content.
* **markdown support**: Magidoc supports markdown so formatting your documentation is as easy as writing a forum post. It also supports advanced markdown features so if you need tables or inline HTML you can also work with that.
* **useful plugins**: Magidoc also has a Svelte PrismJS wrapper and a markdown parser that renders into Svelte components and supports [GitHub Flavored Markdown](https://github.github.com/gfm/) for those wanting to make their documentation a bit more fancy.

## Apprecieate the help

As you can see the approach is quick and to the point, you use the defaults and easily get basic documentation which outlines what your API is about and you can work on the configuration and markdown to add more things and make it look nicer. How much you want to spend on that is entirely up to you, some will be completely fine with the basic documentation and glad to have it over with and others will like to fiddle around a bit more. The key point after all is making writing documentation less of a chore, which it definitely does. Its also only a couple months old and being constantly worked on so you can look out for additional features down the line. If you're not interested in that, it does a bunch of things out of the box already, so if you just want to be done with writing documentation asap this will help you get a quick start with that.

No one likes writing documentation. Luckily Magidoc is here to help! It's a new tool for creating static documentation for your GraphQL API.

Magidoc: fast and easy docs generation for your GraphQL API


Software development has only become more and more popular over the last few years and if you’re looking for developers odds are sooner or later you’ll look outside your own country. This is particularly true for technologies like React, which are so widely adopted and finding devs isn't an issue. Before deciding to outsource your project thought, it's good to think about what region you would like that company to be from. While obvious factors like costs and time zones are usually taken into account, it's really worth it to do a bit of a deeper dive to know a bit more what market you’re getting into. One such market we can take a closer look at happens to be in central Europe, namely Poland.

## Cheaper devs means lower quality?

If you don't know anything about Poland or the software development here, fair enough. Odds are you’ve heard about CD Projekt or maybe 11 bit studios as well if you're into games, but probably not much aside from that. A common stereotype is that Polish software houses charge less because they’re less skilled than those elsewhere. If you do a bit more digging you’ll find out this isn't actually true. HackerRank checked the skills of developers from 50 countries and Poland came in strong at third place, excelling particularly at Java challenges. The Pentalog reports paint a similar picture as Poland came in 4th in 2019 and 7th this year, the only country to keep its place in the top 10 in both rankings. The reports additionally state any country ranked above 30 by HackerRank or 20 by Pentalog can be considered excellent. On the other hand, lets be honest, price is a big draw, and the fact that it will still be significantly lower than in Western Europe or the US is quite enticing.

## Late to the game?

This might sound surprising as Poland and other countries in central and eastern Europe were pretty late to the game when it comes to IT and programming. You would think countries in western Europe should be ranked above them. The Pentalog reports actually point to a couple good reasons as to why that isn't the case. Developers from old IT countries, like western Europe, often come from older technologies with older working methods. Devs from countries without much IT legacy have started with a clean slate, they were learning the ropes only with the newest tools, technologies and practices in mind. This is a big advantage, as anyone in IT knows devs aren't too fond of adapting to the newest trends and often prefer to stick with what has always worked for them. So it makes sense that those who started out using the newest tech have a bit of an edge over those who with time had to switch over from older tools and change their practices.

## Anybody know English?

Setting up meetings also shouldn't be an issue as Warsaw is in the same timezone as Paris, Madrid or Berlin, sure the 9 hour difference between west coast US and Europe might need some working around, but it's manageable. The bigger misconception has to do with language, as a lot of people equate Poland with poor or barely any knowledge of the English language. While this might’ve been true 20 years ago, the situation has changed drastically since then as English has been compulsory in schools since 1989. The EF English Proficiency Index has consistently ranked Poland around the top 15 countries by English skills, putting it in the ‘high proficiency’ group. Obviously it isn't some country of English language experts, but for business related communication you can be pretty sure everything will be fine.

## More bang for your buck

All in all Poland is currently rapidly advancing in the software development sector, dev earnings have already eclipsed most countries in the region aside from the Czech Republic and obviously Germany. The prices are still significantly lower than in the US or western Europe though, while the developers are just as skilled, if not in some cases better. So if you’re looking for the right mix of quality and cost-effectiveness it's in the sweet spot: not too expensive, but also not sacrificing quality to be cheaper. After all, price is just one of the factors and while you might want it to be as low as possible, ultimately it's far more important that you get exactly what you ordered.


A look at software development in Poland and some common misconceptions about it.

The ins and outs of software development in Poland

When looking for the right React devs for your project, sooner or later you’re going to arrive at the basic choice of either looking for a skilled freelancer or a complete team. This will for the most part be determined mainly by the size of the project and the amount of work needed to be done. The big issue is getting to know that, since what might seem like a simple idea can turn out to be a really complex project needing tons of work. You might think that the obvious response to that is just getting more freelancers, but let's just say it isn't exactly as simple as that.

## Freelancers

When looking for freelancers the first step is self explanatory, doing the research and checking the resume. Things to look for are experience and past projects, what they worked on, what their role was, was the work for a startup or a large company etc. If that information isn't readily available through a simple search it's always good to ask for those details during an interview. As for interviews, they’re a natural way of checking out soft skills like communication, motivation, teamwork or attitude. For hard skills you likely either need to know the ins and outs of React or have someone who does conduct the interview to know whether the interviewee has all the required skills or not. While that might sound easy it's good to keep in mind the overall pros and cons of going with a freelancer, even if you do find one who has all the required skills.

* **Cost**: While freelancers are usually not expensive a good rule of thumb to go by is: the cheaper the freelancer the worse their skills.
* **Flexibility**: There’s no commitment so upsizing or downsizing the team is no problem. Freelancers work either hourly or on fixed price projects, which means without a really detailed plan tracking their work will not be possible and a precise daily/hourly timesheet might prove too restrictive.
* **Maintenance**: Due to short term commitments being the nature of freelancing, expecting anything after the project is finished, aside from maybe ad hoc bugfixing, is pretty unrealistic.
* **Quality**: Freelancers are judged and hired based on the quality of their work and most are experts, so this usually should not be an issue (unless research was lacking) However due to the dispersed nature of freelancing, industry standards do not apply as everything is done according to personal preference. This can mean a lot of potential issues down the line especially if integrating or upscaling the project.
* **Control**: With a single person working on the project decisions will be made quickly and instinctively. A team of freelancers however can need a lot of supervision and may even require a person dedicated to exactly that as some form of a project manager.

## Outsorucing

The alternative to freelancers is outsourcing the project to a React development company. Those will simply assign a complete and experienced team to work on your project from start to finish. Yes it is a more hands-off approach, as those companies and teams have usually done a number of such projects before and will have their own internal process and practices. While this might seem like having less of an influence over the project the opposite is actually true as your input focuses on the result of the work and not the way it's being done. You can request an MVP (minimum viable product) and get a basic idea on the viability of the project quickly and you enjoy long term support so any issues shortcoming or updates to the projects just come down to communication. Basically instead of being forced to micromanage everything and do constant oversight you just oversee the end results and judge how it fits what you requested.

* **Cost-effectiveness**: With freelancers you’ll need to navigate and micromanage an entire patchwork of people working separately on various parts of the project in the way they see fit. Outsourcing the entire project means saving tons of time and effort, and in consequence money.
* **Quick turnaround**: The key reason to outsource is speed, you’ll see the project done quicker and without sacrificing quality either. A battle tested team which has handled a number of such projects works like a well oiled machine, a developmental crash course for a ragtag team of freelancers can hardly compete with that.
* **Hands-off approach**: The team will have everything the project requires, UI/UX designers, graphics designers, frontend developers, backend developers, mobile developers and a Project Manager to oversee all that. No need to monitor all the work, you just see if the results are satisfactory and fulfil your requirements.
* **Superior solutions**: An experienced company will have dealt with a large number of similar projects, their issues and any problems that might arise during development. It will also have a tried and tested stack and know all the kinks of React and its associated technologies to work as fast and efficiently as possible. This means that they will be able to provide the best, well-tested solutions during the development process. Maintenance, scaling, fixes and updates will also be easily handled and your project will enjoy long term professional support.

## Focus on the result not the process

In short, unless you’re really hell bent on micromanaging a group of freelancers along the entire way, outsourcing is simply more efficient. Sure if your project is really small or you need only a bit of help from one person on some particular thing, hiring a company would be overkill and in those cases by all means go with a freelancer. If you need a complete project though, it's way better to hire a company which will provide you with an expert team to take it from start to finish. Efficiency is not the only argument as by turning your attention from the intricacies of the development process to its actual result makes it much easier to control what comes out of it. Instead of compromising here and there because of developer shortcomings your focus is entirely on the finished product so that you ensure you get exactly what you wanted.

A look at the pros and cons of hiring freelancers vs outsourcing the entire project.

React development: Freelance vs Outsourcing

State management in React, despite being a key aspect of development and having a ton of useful tools and libraries, is still not solved, or even close to that. Most have stuck with Redux over the years, but the ever growing number of new state management libraries suggests there is a lot of space for improvement. Over the years React has dropped in a lot of help, like the Context API or Hooks. While this was initially seen by some as the end of Redux, that has not materialized to say the least, and Redux remains the most widely used state management tool.

## Everyone uses Redux

Redux has been the much maligned and yet still most widely used state management tool ever since it came out victorious from the so called flux wars, a period when various libraries based on Facebook’s Flux architecture vied for the title of the top state management solution in React. That turned out to be Redux as it overshadowed the other libraries. Over the years however, there have been a lot of complaints about it, mostly relating to boilerplate and performance issues as Redux is not meant to be quick or simple, its purpose is being predictable, i.e. making it easy to see state updates.

In fact a lot of the complaints are a product of its wide adaptation as it has led to overuse. Since Redux focuses on making it easy to read state updates not every app even needs it (or might be better off with a different state management library) On top of that because of the whole ‘single source of truth’ approach a lot of people tend to just stick everything in their app into Redux which isn't the best idea either. Additionally as Redux is the go to solution for state management it means you are somewhat forced to use it and it does have a learning curve and some issues that might not be to everyone's liking, especially those used to Object Oriented Programming.

## How is Unstated Next better?

On the other hand some newer libraries have chosen to make full use of the new tools provided by React. One of them is Unstated Next which was basically built on top of the React Context API. It's a spiritual successor to Unstated and its main focus is keeping everything as simple and small as possible. How? It relies on simply using React and the tools it provides like Hooks and Context to the fullest, while also providing the useful addition of Containers. These are just like components, but only for state. You simply put a piece of state into a Container, other components can subscribe to it and any change to the state in the Container triggers a rerender of the subscribed components. Let’s look at a simple comparison with Redux:

* **smaller and faster**: Unstated-Next pretty much boils down to built-in React functionalities and componentizing everything, which makes it a number of times smaller as well as significantly faster than Redux.
* **way simpler**: There's almost no learning curve, it will take you maybe 5 minutes if you know how to use `useState`, `useContext` and custom Hooks (which lets be real, you do if you’re using React) Additionally the containers also make it easier to get around everything.
* **written in Typescript**: Typescript support out of the box means type-checking and less need for testing
* **built around containers**: This means less boilerplate and simply relying on the Context API under the hood. It also makes integrating with any react library a simple process by doing it one component at a time.

## Overuse is not a good idea

Many saw the addition of Hooks as something that will make Redux obsolete (or maybe were eager for an opportunity to ditch it) The thought was that the `useContext` and `useReducer` hooks would be used for state management instead of using a global state container like Redux. This has not materialized and it remains the go to tool for state management. It even has its own Hooks API now making use of the new things React has provided. While Redux is much maligned for the above mentioned reasons it isn't bad, it's simply overused and relied on too heavily due to being so widely adopted for so long. Instead of complaining about having to use Redux with all its issues we should instead focus on figuring out when we can use alternatives like Unstated Next which will fit our project better. The React state management ecosystem is constantly changing so we don't have to ditch one tool for the other. We can simply keep on relying on Redux when/if needed and try to get on with some newer solutions which can be better in other cases. Additionally although Hooks have not made Redux obsolete some new thing always can, so its good to keep an eye out for that!

 A look at why always sticking with Redux might not be the best idea

Unstated Next vs Redux, which is better for state in React

React state management enjoys a rich ecosystem of libraries with a new one seemingly popping up every few months, if not even more often. While that might seem confusing from the outside, with so many options to choose from, the choice is actually quite simple. It boils down to either sticking with Redux despite its flaws or following the latest trends, looking for that one new library that works just like you want. One of the newest ones is the atomic state management library called Jotai.

## Three approaches to state management

The different types of state management solutions in React can be broken down into three categories. Well there is also a native solution that’s built-in, the React Context API. It lets you pass data through the tree via a `provider` and `consumer` without the need for passing it manually through each level of components. This does have some use cases, particularly if you have something that is rarely changed and just want to make it accessible to another part of your React component tree, without bothering with third party libraries. Though using it for anything more complex than that will leave you with a ton of nested context all over the tree, which isn’t optimal to say the least. So aside from some basic applications you’ll likely need to pick one of these:

* **Flux-based**: Based on Facebook’s Flux architecture, these libraries follow the centralized, global store approach. Data is made accessible to components by subscribing to a single source, the global data store and only updated by triggering actions. Examples include Redux, the oldest and most widely used library (which is bemoaned for lots of boilerplate) or something like Zustand which uses simplified Flux principles.
* **Proxy-store**: This approach wraps a state object in a proxy, so you deal with it and not the object itself and you can subscribe to a part of that state from anywhere in the tree. The proxy pattern does not require a specific action to be fired, like the flux approach does, and will automatically detect what part of the state is used in the component and subscribe to just updates to that part. The best known examples are Valtio and Mobx.
* **Atomic**: Unlike the others where state is stored outside the React tree in a top-down approach, here the state is stored internally inside the tree. Atoms are updatable and subscribable units of state. You can build state by combining them and renders are based on atom dependency. This saves you from unnecessary re-renders of the other approaches and results in a boilerplate-free API where shared state has the same basic functions as Hooks (ie. `useState` and `useAtom`) That makes it really easy to get a hang of for anyone with some experience with Hooks and since they have been with us for a while, I would guess that wouldn't be that rare. The two atomic libraries are Recoil and Jotai.

## Jotai vs Recoil

The atomic approach is fairly new in comparison to the good old Redux, but looks to be here to stay. Little wonder since the benefits it provides over the more tried and tested approaches are really substantial. Now as far as the atomic state management libraries go, the two main ones are Jotai and Recoil. The latter was released in 2020 by Facebook, which shows that even the originator of Flux has realized that a different approach to state management might be better. While Jotai is newer (released in June 2021) and does not have a tech behemoth behind it, it does have a few interesting advantages.

* **it's smaller**: Jotai has a smaller core API, it’s bundle size is just 3.3 kb compared to 14 for Recoil and for the most part it boils down to `provider`, `atom`, and `useAtom`. There are other additional features but this should provide the basic idea of the approach: as lean as possible.
* **it's simpler**: Jotai is less boilerplate as it is less opinionated, it has no string keys or selectors as atoms function as both selectors and basic atoms. While Recoil does have robust documentation, as you can expect from a Facebook backed library, Jotai is much easier to learn and quicker and simpler to write. It's also TypeScript focused, fully compatible with it and comes with Typings pre-installed.
* **handier**: While keeping everything as small and simple as possible Jotai does already have a pretty big chest of official integrations for managing pieces of state with some additional functionalities ([redux](https://jotai.org/docs/integrations/redux), zustand, valtio, xstate, immer, react-query etc.) A number of these were proposed in GitHub issues so even if it doesn't have the one you need yet, you can probably expect a bunch to be added fairly soon.

## Here to stay

While some might prefer to stick with Redux for the sake of continuity or familiarity it's clear that the dynamically growing field of state management libraries for React does offer a lot of interesting and beneficial solutions we can use. In any case atomic state management is a game changer and solves a lot of the issues that have become so painfully familiar over the years. Even if you don't want to jump ship yet, it's good to familiarize yourself with Jotai and Recoil as they’re likely here to stay and will become more popular as more and more people see the advantages they provide. As for choosing between them it does depend on preference and particular use case. Recoil does have some functionalities that Jotai does not have yet (Snapshots for an example) on the other hand Jotai is much smaller and easier to get into. So if you’re accustomed to something like Redux, one small glance at Jotai and how simple and transparent its code is should be pretty enticing and might be enough to bring you over.

 A look at the benefits of using an atomic React state management library like Jotai

Jotai: atomic React state management made easy

JavaScript has been around for a long while and has become somewhat of a controversial topic in the dev community, some love it, some hate it. Many of those highly critical of JavaScript are probably referring to its pre-2015 state as the language and its entire ecosystem is in a completely different and much better place now. Still, whether you’re a fan of JavaScript or not, it's good to have an idea about alternatives and new variations just in case they offer some key improvements. One of those is TypeScript, a superset of JavaScript which adds static typing.

The main gripe with JavaScript is that the early versions had a lot of traps for programmers and sadly, unlike say Python, those relics can not be discarded with a new version by ignoring backward compatibility and starting with a clean slate. That’s because of the fact that each browser, or rather the company behind it, is a vendor and as such JavaScript has to support everything. Now with all the different mobile platforms this has only compounded the issue. So any change that would do away with some old relic in the language would have to not only be done at the same time and with accordance with all the vendors, it would also probably cause a ton of issues for half the internet still basing some of their code on those old relics. This means that while not everyone might like JavaScript we’re probably stuck with it for the foreseeable future.

## Why TypeScript?

Various improvements to JavaScript made it faster and that led to the appearance of Node.js, a backend implementation. This in turn showed that when working on larger and more complex things, code maintenance keeps becoming a bigger and bigger issue. JavaScript being a dynamically typed language is quick to write and that is a big advantage that jumps out at anyone starting to work on a project. TypeScript being a strongly typed language requires a bit more effort, but makes it easier to read and understand code. This is an even bigger advantage, but one far more that’s noticeable down the road, either with maintenance or especially when it comes to inheriting code. The biggest advantage is that static typing means errors are detected at compilation and not on runtime. This saves a lot of time and effort, usually spent during testing and makes the platform do a bit of work for the programmers, by catching errors for them. As such while JavaScript is perfect for small things like a simple web page with barely any logic behind it, TypeScript is simply way better for anything bigger or more complex.

## For web, mobile and backend

Additionally as TypeScript is a superset of JavaScript all JavaScript code is valid TypeScript code, which means anything written in JavaScript that outgrows it, can be easily transferred to TypeScript. While these might seem like simple quality of life advantages for a developer, they’re actually vital when it comes to working in teams. Whether a team is inheriting some old JavaScript code, changing the scope of a project or getting reassigned to a different branch of it, Typescript will be a real help to make that process much easier and smoother (and most importantly actually possible!). To make that more apparent we can look at how Typescript is used for web, mobile and backend development:

* **web**: React is a tried and tested solution for JavaScript and so TypeScript as well. React Hooks with static typing and type transformations makes for a powerful combination that really streamlines the code. Alternatively you can use Next.js, a framework built on top of React and Node.js which comes with type definitions and has a bunch of features like simplified routing and image optimization to make things faster and easier.
* **mobile**: React Native provides you with a great out of the box solution for hybrid app development. Additionally the main gripe with it, the lack of built-in testing functions, is solved by TypeScript catching errors on compilation. Alternatively you can opt for native development for each platform where using TypeScript will still be a big help especially if you want one team work on implementations for both iOS and Android.
* **backend**: The most popular backend use case for Typescript is serverless functions, in which case Node.js really shines, as it is designed to run on a single thread and can run well even in those environments, when computing resources are limited. Similarly in case of microservices its event driven architecture makes it perfect for Nets.js a TypeScript based framework often called the 'Angular of backend'. GraphQL is also greatly useful here as it uses its type system to describe data fields, preventing over and under-fetching, which makes it a natural fit with TypeScript.

## Versatility, efficiency and interchangeability

Obviously there a numerous other libraries and frameworks available, but this should provide some insight into how versatile the language is. It also makes everything interchangeable: a mobile developer can fill in for a web developer and vice versa without much issue. Work and communication between developers is also much easier than when working with dynamically typed languages, where everyone comes up with individual solutions others have to be brought into. Perhaps most importantly one team can handle everything instead of needing separate teams for mobile, web and backend.

* **versatile**: almost all libraries are now written in TypeScript which makes integration much easier
* **interchangeable**: interdisciplinary developers which can help or even replace each other when needed
* **cost efficient**: one team can handle every aspect of the project. with no need for separate teams for web and mobile development the costs are significantly lower

## Teamwork

TypeScript obviously isn't universally loved and you can easily find those who do not like it for a number of reasons, they might find it too restrictive, think static typing is bothersome and unnecessary or they just might like loose typing. Others might find it too close to JavaScript which is disliked by a lot of developers, to put it mildly. However TypeScript does have clear advantages especially when dealing with big or complex projects and to be honest, personal preference should take a back seat to better teamwork in those cases anyway.

 A look at the advantages of using TypeScript for developing different types of apps

TypeScript: solution for web, mobile and backend development

State management is a bit of a boogeyman when it comes to React, if you ask those who don't want to get into it, that will probably be the reason they’ll give you. State management does become quite a bit of work as your app grows and you often need libraries to help with that. That’s what turns a lot of people off as most devs experienced with React have their top 5 state management libraries if not a top 10. Either that or they simply stuck with Redux and never bothered looking for some other option.

Redux is the most popular library for state management, but far from the only one and some of them are based on one another like Rematch is on Redux, which makes it hard to wonder why it all serves as a major turn off for people who are looking to get into React. The whole thing seems complicated with a lot of learning required to find the right solution and even then you might still have to deal with a lot of boilerplate or need to jump on some other more advanced library built on the one you were using. This creates the often seen view that state management in React is bothersome as you either have to stick with the most commonly used tool (which is widely criticized in the community) or need to engage in a never ending cycle of looking for the newest library with all the additional features and functions. If that sounds like a hassle, fortunately there is one much simpler library that might just be what you’re looking for.

![Unstated](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/unstated-logo-1730917901466.png)

## Unstated

In React state basically lives on components and that makes it predictable, transparent and easy to work with or test. Even if you’re not familiar with React, a brief look at those components will usually give you a pretty good idea of what they're supposed to do. Continuing with this approach everything, including state, is shared through Context, you pass some state into a Provider component and a Consumer component will receive it. This makes for a simple and efficient solution as it doesnt need to pass through the entire tree and ends up exactly where you want it. While this is great, what if you want to share state across multiple components? Well this is where Unstated comes in, it's all about combining Component State and Context while keeping things simple. It's a really small library comprised of three things:

* **Containers**: these are a class which is basically like components but used only for state. You simply paste a piece of your state into a Container and components can subscribe to the state in it.
* **Subscribers**: components which are used to deliver the state to the components that need it. Any change in the state in the container automatically triggers a re-render of the subscriber components.
* **Providers**: components which hold all of the instances of your containers and allow its children to subscribe to them. They are used at the top level around components that you want to subscribe to a container.

## Unstated-next

As you can see Unstated was a great tool and helped share logic and state in a quick and simple way, something that was sorely missing in React. That said, React later introduced Hooks which basically filled the niche Unstated was in and to be brutally honest kinda made it redundant. The creator of Unstated Jamie Kyle realised that, but also saw another niche for a library and that’s how he came up with the idea for Unstated-next. The niche was that a lot of devs didn't see how to use Hooks to share state and logic so the goal was a spiritual successor to Unstated which would help understand shared state and logic in React by using the same base concept.

* **keep it simple**: Unstated-next just wants you to use React Hooks and Context to their fullest using the same container system Unstated did
* **keep it small**: at around 200 bytes and needing only a few minutes to get a hang on the library is really miniature
* **componentize everything**: having everything in components does wonders for performance and especially testing, integrating with any other React library will also be smooth since you can do it one component at a time

## it's all about React

The key thing about Unstated is that it encourages you to simply use React and just throws in a clever solution like Containers for you to use when needed. When used correctly with Hooks and Context, which are powerful tools by themselves, it will make state management much easier without the need for learning to use some more complicated state management libraries or dealing with lots of boilerplate code. While there are obviously cases where you might need a more complex tool and the minimalistic approach of Unstated-next simply wont be enough it is definitely the way to go if you’re just starting with React or if you just want to keep state management a simple and easy affair.

A look at how Unstated-next can help us with React state management

Unstated: a light & simple React state management library

According to the latest data, mobile device users spend almost 90% of their time on apps and only around 10% on browsing the internet. With the growing popularity of mobile devices in general and apps in particular, almost everyone wants to make one, and as quickly as possible. Due to this hybrid development has been growing in popularity, as its advantages are primarily related to cost efficiency and faster time-to-market. However getting your app out quickly is far from a guarantee that people will want to actually use it and that's where a different approach might prove to be more sensible ie. native app development.

## Native mobile apps - perks overview

Once you look past the basics native development does have quite a few advantages worth taking into account. Hybrid technologies have made great strides recently in the areas of optimization, security, and user experience, and are constantly working to definitively bridge the gap between native and hybrid approaches in these areas. A well-built React Native or Flutter application will not differ much from a native one, still native apps offer better benchmarks in some areas out of the box:

* **Performance** - native app performance is still significantly better as they are optimized for a specific platform
* **User Experience** - for the same reason they are more intuitive and interactive, resulting in an overall better user experience. Although the look and feel of UI components is more or less the same in native and hybrid applications, there are still some aspects where differences are noticeable such as visual interactions, gesture controls that are seamlessly integrated in native apps and match the style of the operating system to which a user is familiar
* **Learning curve** - once a user learns to use their device, they don't want to do it again with every new app they install, native app development results in an app that is more embedded in the feel of the particular platform
* **Security** - native apps offer the best in class security and that’s why they are still usually preferred by fintech apps

## Initial app launch - does your app need to be available on both Android and iOS right away?

There is a common belief in the business world that their company's app must be immediately available on both iOS and Android.

Of course, it is true that being present on both platforms has its advantages and if you absolutely need your app delivered in the shortest possible time on both platforms, you should consider using hybrid technologies such as React Native or Flutter instead of native ones.

However, if you think that native technologies offer what your product needs, ask yourself if you really need to have your app available on both platforms at once?

No one is perfect and software development is a process. Be sure that no matter how well prepared you are, your application will need constant adjustments, the features will change after being confronted with the needs and preferences of users, it will also need to be improved and adapted to the constantly changing technological environment. Starting with one platform lets you avoid duplicating mistakes in the fields of functionality, technology and business assumptions on a second platform.

## The platform question - which platform you should start with?

The first choice in regard to native development is obviously picking the platform you want to develop the app for: iOS or Android. iOS dominates the European and Asian markets with about 70-80% market share and the US market is split about 50-50. Obviously you don't have to pick one and can develop your app for both platforms, but this is where the costs and time constraints come in. While the overall product will have the above mentioned advantages due to being developed natively, it will take more time and effort and most likely will need separate devs or teams for iOS and Android. So if you’re targeting a market dominated by iOS it might be prudent to focus on that and leave getting out an Android version of your app for later.

## Native mobile platforms - the overview

## Apple ecosystem - iOS

If you’re picking iOS the first choice is picking the language, Objective-C or Swift. Good old Objective-C has been around since the 80s and Apple has been using it since the mid 90s, it still does have its uses and has been tried and tested over the years. The truth though is that everyone is moving on from it because Swift just has it beat. Apple developed it specifically as an improvement and it's faster (2.6 times faster according to Apple) safer, less complex and easier to maintain.

The choice obviously comes down to personal preference and if you want to stick with Objective-C because you or your team are familiar with it or you already have a project with a large Objective-C codebase you can do so, but Swift is simply better if you’re starting out. With the language picked you have a number of tools that will help you with development:

* **Swift Playgrounds**: a platform for learning to code with Swift in a fun way
* **Xcode**: the official integrated development environment (IDE) for iOS development, with extensive documentation, interface builder, simulator, graphical debugger and a bunch of other features
* **iOS SDK**: a package of tools which helps you with native app development by providing access to various functions and services of iOS devices, like hardware and software attributes
* **TestFlight**: an online testing service for iOS devs

## Google ecosystem - Android

For Android the choice of language is somewhat similar, its Java or Kotlin and once again one language is much older and the other has some new improvements. It's not as easy here though, as although Kotlin has been gaining traction and has recently been adopted by Google as the official language for Android, it is still far less popular than Java and will likely remain so for the foreseeable future. Java is well established for good reason as it is a great multi purpose language, Kotlin on the other hand does bring in quite a few new features. It combines object oriented and functional programming, requires less code and is faster to compile. Java on the other hand has a much larger community, is way more widespread and supports almost every server, device and operating system. Even Android itself was written in Java, so while Kotlin is the better language for Android app development, sticking with Java is perfectly understandable. Whichever language you choose Android also has a few useful tools which will help with development:

* **Android SDK**: a package of useful tools which includes various libraries, a debugger, tutorials, documentation, a handset emulator and code samples
* **Android Jetpack**: a suite of libraries to help developers follow best practices, reduce boilerplate code and write code that works consistently across Android versions and devices

## User experience vs time-to-market

If you’re looking to make a test or demo app hybrid is definitely the way to go. That said native does have many advantages especially considering user experience so if you know what you want and you’re looking for quality it will most likely deliver. Platforms and market dynamics are important factors to consider though, while many are scared off by the fact you usually need separate teams for Android and iOS you might not even need an Android version of your app if you’re targeting a market dominated by iOS devices. Additionally the tools are also getting constantly improved by two tech giants in Apple and Google, which will have a further impact on the time and ease of native development in the future. Plus with millions of apps already on the market it might be better to focus on how yours will compete with them, rather than simply looking at costs and development time.

A brief look at the native app development for iOS and Android

Native mobile development for iOS and Android

Modularity and reusability are among the principles of React. React components are independent and reusable pieces of code that are responsible for one specific thing. This approach helps to keep the code clean and elegant. **Rerousel** is the simplest and lightest infinite carousel component package created for React, with the goal of providing a way to show that your application follows these principles:

* **Simple** - Carousel setup is very easy, just install the package and import Rerousel and the component setup is effortless,
* **Lightweight** - Rerousel is the lightest working React JS infinite carousel available for download from NPM. It uses only the packages that are necessary, so you don't have to worry about thousands of excessive dependencies flooding your app,
* **Versatile** - It doesn't matter if you are building an eCommerce app for businesses and need to showcase your products or a personal project to display your vacation photos - Rerousel is for you. It supports all JSX element types, so you don't have to worry about compatibility.

## How to use it

Install the package using npm:

```bash
    npm install rerousel
```

Then import Rerousel into your React project:

```ts
import { Rerousel } from "rerousel";
```

Place it in your app and populate with the items you want to showcase, create a ref pointing at your outermost item and include it in the **Rerousel** as itemRef prop.

```ts
export const Component: React.FC<CustomersProps> = ({ customers }) => {
  const customerLogo = useRef(null);

  return (
    <Container>
      <Rerousel itemRef={customerLogo}>
        {customers.map((c) => {
          return <Img key={c.image} image={c.image} ref={customerLogo} />;
        })}
      </Rerousel>
    </Container>
  );
};
```

Et voila! Enjoy the simplest, the lightest & the most reliable infinite carousel package made for React. If you want to get more info on it make sure to visit [Rerousel's repo on GitHub](https://github.com/aexol-studio/rerousel).

 Carousels or image sliders have been always used for enhancing the visual appeal of websites, presenting products, customers or testimonials. Let's take a look at Rerousel, the simplest infinite carousel for React.

Check out Rerousel - the simplest carousel for React


In terms of key decisions to make when thinking about app development the first one is to decide on either hybrid or native app development. Both are very popular with some well known native apps like WhatsApp and Spotify and hybrid apps including the likes of Instagram and Uber. Both approaches also have their pros and cons and depending on the circumstances each can be the right one to pick. While that choice will probably require quite a bit of brainstorming and figuring out the goals and aims of the product, let's look at what lies ahead if you decide on hybrid development.

## Flutter vs React Native

While not the only frameworks you can choose from, Flutter and React Native are the two leading platforms, so the simple decision is to turn to one of them. Both are created by tech giants, Facebook released React Native in March of 2015 and Google released Flutter in April of 2018. React Native is more widely adopted as it was released earlier, but Flutter has been gaining popularity and has recently taken the top spot becoming the most popular framework. Similarly for the size of both communities whether you’re going by Stack Overflow, GitHub or dev.to Flutter is catching up despite React Native having a 3 year head start. For a while it was basically a choice between an established tool and a fresh solution that’s gaining popularity, but now they’re just two major frameworks each with its own advantages.

## The ins and outs

First let’s take a look at some technical aspects, not in some very detailed way but just to get an idea on what each of them aims to do best. Each framework differs quite a bit in how it is constructed and how it works and that in turn means either a bit of a learning curve or some digging for community made solutions:

* **language**: React Native uses widely known JavaScript, Flutter uses Dart which is a custom object oriented language made by Google. While this might seem like React Native is the easy pick here Dart might be preferable as it should be very intuitive for those familiar with object oriented programming.
* **libraries/components**: Flutter relies on built-in libraries, React Native relies on third party libraries. This again comes down to preference, one has more of a starter toolkit the other offers you a buffet of user provided solutions, which you’ll have to find and pick yourself.
* **architecture**: Flutter uses a layered architecture of widgets while React Native uses a bridge between the Native and JavaScript threads. In short this means that Flutter is geared towards gradual app building via small and simple components while React Native makes more use of native functions, but can increase the size of the app which in turn can create some performance issues.

Some key differences are already apparent, React Native is more of a customizable tool that you should fit to what you need and Flutter aims to be more of an out of the box tool which gets you everything you need right off the bat. To further drive that point let’s take a look at some details on ease of use.

* **testing**: React Native offers no built in testing functions, you’ll need third party apps like Appium or Jest. Flutter offers a number of features for testing units, widgets and integrations.
* **documentation**: React Native has extensive documentation, however it focuses on helping those already familiar with JavaScript and some app development practices. Flutter has robust documentation with detailed video tutorials and graphics which will help you start from scratch and features like debugger and Flutter inspector which offer additional help. Little wonder since JavaScript is way more widely adopted than Dart but still an advantage if you’re starting out.
* **performance**: though this is a hotly debated topic, the basic fact is Flutter is faster and consistently runs at 60 frames per second. React Native does experience some issues and can be a bit slower, the best evidence for that is the existence of popular performance improving third party apps like Proguard.
* **complex projects**: React Native can be used even for more complex apps, but you’ll likely need to implement at least some bits of native development in relation to some kinks of the particular platforms. Flutter and its Dart are still fairly new and focus on simpler and faster development so they might lack what is needed for more complex or niche projects and using it for those wouldn't make much sense.

## Community driven vs out-of-the-box

I think the differences in both approaches are now quite clear and as usual the decision comes down to circumstances and personal preference. React Native focuses on providing developers with a good base and a variety of (often third party) tools which you can pick and choose from to get exactly what you need for your app. Relying on dev experience and community provided solutions makes sense since JavaScript is so widely adopted and those who know it and start using the framework will know exactly where to look for what they need. Flutter on the other hand has some learning curve since Dart is pretty new and not nearly as widely adopted, but throws in a ton of help to make it easier to get a hang of everything. It also focuses on faster time-to-market, better performance and more of a one size fits all approach to development. Any dev either familiar with Dart or object oriented programming or with the time to learn it will definitely find it worthwhile even if only for working on simpler projects or MVP applications and it's in no means limited to just that.

React vs Flutter an up to date framework comparison

Hybrid development, React Native or Flutter?

Soon it'll be 7 years since Facebook released React Native in march of 2015, in that time it has become immensely popular on all platforms. Today it's still one of the most used frameworks and according to Statista has only recently lost 1st place to Flutter. So while it might not be the hottest thing at the moment, React Native is still growing and it's worth checking out what’s new in 2022 especially since I promised we’d do so in the previous blog post anyway.

## Execute order 0.66

In August the team behind React Native posted a blog post, which outlined a roadmap for the second half of 2021 and brought a lot of encouraging news. Not only was the team getting bigger but the updates would now be more stable and much more frequent with a change of approach to the development of React Native. Soon after in October we saw the release of the much anticipated major version 0.66. Aside from the usual fixes and a compatibility update for the latest versions of mobile operating systems (Android 12 and iOS 15 respectively) it brought quite a few interesting features. To sum them up in brief:

* **support for children rendered outside of parent view boundaries** - a much requested quality of life feature that brings React Native up to web dev standards,
* **support for the new Bluetooth permissions added in Android 12** - which among others enable your app to look for other Bluetooth devices, make the current device visible for others and communicate between paired devices,
* **better Support for Apple Silicon** - along with better Xcode 13, and iOS 15 with a focus on the new QuickTime and navigation bars in iOS and permission updates and overscroll effect in Android 12,
* **Hermes 0.9.0** - the open-source engine optimized for React Native which focuses on performance (improving start-up time, decreasing memory usage, and keeping the app size smaller). With around 400 commits this update focuses on closing the gap between the Hermes cut and the React Native 0.66 cut and making sure there are no issue with the two working together,
* **React 17 support** - even a glance at [the changelog](https://reactjs.org/blog/2020/10/20/react-v17.html#changelog) will tell you this is pretty big and could easily be a blogpost in its own right!

## Promises made

The releases have been coming more often with 0.66 being already the third update in 2021. To reinforce that point 0.67 dropped just as I was writing this. While its a smaller update it still had almost 400 commits and some big highlights: Lean-core removals and support updates for Kotlin 1.5.31 and Gradle 7.2 With that it's safe to say so far the team behind React Native has been delivering on their promises. 2022 should bring a few more updates with things like Native Modules and Facebook’s Fabric project already on the horizon.

## Some healthy competition

Things are getting pretty exciting for React Native. It seems the team behind it realized that other frameworks like Flutter were catching up and decided to pick up the pace. Obviously it's one of the biggest frameworks and it's likely to stay that way for a long time, but as evidenced by the update pace that change in development approach was long overdue. So while these updates might not be enough to make everyone instantly abandon all the other frameworks, they’re still definitely a great benefit for the React Native community and it's safe to say things are looking bright.

A look at the latest big updates from October and January

What's new in React Native - highlights of v. 0.66 & 0.67


## Intro

I am a full-stack TypeScript developer and I've been learning the Elm language a lot recently. Will I switch to Elm? Definitely not. However, the learning process helped me understand and demand more things in React.

Today I will show you a React anti-pattern that will allow you to **share state outside components**. Why would you do this? Why not use a hook? etc. etc. I will show you an example with a small form.

**Note:** This is not a "real-world" example. In production env I am using this hook to create a synchronized S3 File browser, but it might be too much for the sake of this article.

## The hook

So this combination of State and Callback is to connect the ref function later and listen when the ref changes:

```ts
import { useState, useCallback } from "react";

export const useImperativeRef = <T,>() => {
  const [refState, setRefState] = useState<T>();
  const ref = useCallback((n: T | null) => {
    if (n) {
      setRefState(n);
    }
  }, []);
  return [refState, ref] as const;
};
```

## The form

We don't need anything fancy for this example so we will use a simple form with 2 inputs:

```ts
import React, { useImperativeHandle, useState } from "react";

interface FormValues {
  username: string;
  password: string;
}

export interface MyFormHandle {
  values: FormValues;
}

export const MyForm = React.forwardRef(
  ({}, ref: React.ForwardedRef<MyFormHandle>) => {
    const [values, setValues] = useState<FormValues>({
      username: "",
      password: "",
    });
    useImperativeHandle(ref, () => ({
      values,
    }));
    return (
      <div>
        <input
          type="text"
          value={values.username}
          onChange={(e) =>
            setValues({
              ...values,
              username: e.target.value,
            })
          }
        />
        <input
          type="password"
          value={values.password}
          onChange={(e) =>
            setValues({
              ...values,
              password: e.target.value,
            })
          }
        />
      </div>
    );
  },
);
```

## Using the form

Et voila! We can listen to state changes of components underneath:

```ts
export default () => {
  const [values, setRef] = useImperativeRef<MyFormHandle>();
  useEffect(() => {
    console.log(`Values changed!, Values: ${JSON.stringify(values, null, 4)}`);
  }, [values]);
  return (
    <div>
      <MyForm ref={setRef} />
    </div>
  );
};
```

Of course, we can pass change functions and values, but let's be true - that's Yuck! In my opinion, this way is much more elegant and codeless in many cases.


How useImperativeHandle + useCallback + useState works together.

React `useImperativeHandle` Magic by a fullstack dev

In today’s digital landscape, user experience is more than just a pretty interface - it’s an engaging journey. Animations have evolved from simple CSS transitions to dynamic, complex interactions powered by advanced JavaScript libraries and even 3D technologies. This blogpost explores the evolution of web animations, highlights the core technologies behind them, and showcases practical examples to inspire your next project.

## **1. The Evolution of Web Animations**

Animations have long been the secret ingredient in creating immersive web experiences. Initially, simple CSS animations and transitions gave us smooth hover effects and subtle visual cues. Today, developers leverage a combination of CSS and powerful JavaScript libraries - such as GreenSock (GSAP), Anime.js, and Framer Motion - to craft animations that can tell stories, guide user interactions, and bring interfaces to life in ways that were once impossible.

## **2. CSS Animations: The Foundation of Fluid Interfaces**

CSS remains the go-to for simple animations. With properties like **transition** and **@keyframes**, CSS can handle everything from fades to slides with minimal code. For instance, consider this basic hover effect:

```css
.button {
  background-color: #3498db;
  color: #fff;
  padding: 1em 2em;
  border: none;
  border-radius: 4px;
  transition: background-color 0.3s ease;
}

.button:hover {
  background-color: #2980b9;
}
```

This example shows how a simple color transition can enhance the interactive feel of a button. CSS animations are not only lightweight but also optimized by browsers, making them ideal for many common effects.

## **3. Advanced Libraries: Unlocking Complex Animations**

For more sophisticated animations, CSS might not always be enough. This is where advanced libraries step in:

### **3.1. GreenSock (GSAP)**

GSAP is a powerhouse for creating high-performance animations. It allows you to control timing, sequence complex animations, and even synchronize them with scroll events. Here’s a snippet demonstrating a simple GSAP animation:

```ts
// Animate an element with the ID 'hero'
gsap.from("#hero", { 
  duration: 1.5, 
  y: -50, 
  opacity: 0, 
  ease: "power2.out" 
});

```

This code fades in the element from above, creating a dynamic entrance effect that can be part of a larger storytelling narrative on your landing page.

### **3.2. Anime.js and Framer Motion**

Both Anime.js and Framer Motion offer declarative ways to handle animations in web applications. Anime.js excels at animating multiple properties and complex SVG paths, while Framer Motion integrates seamlessly with React, making it a favorite for building interactive UIs.

*Example using Anime.js:*

```ts
anime({
  targets: '.box',
  translateX: 250,
  rotate: '1turn',
  duration: 2000
});
```

This snippet moves an element horizontally while rotating it, demonstrating how animations can transform static content into engaging experiences.

## **4. Real-World Applications: Animation in Action**

Modern web animations aren’t just for aesthetics—they solve real UX challenges:

* **Loading Indicators:** Animated loaders keep users informed while data is being fetched.
* **Microinteractions:** Subtle animations for actions like liking a post or adding an item to a cart enhance user feedback.
* **Storytelling:** Parallax scrolling and interactive timelines guide users through narratives on landing pages.
* **3D Visualizations:** Libraries like Three.js allow developers to create interactive 3D scenes, turning web pages into mini virtual worlds.

For instance, an interactive dashboard might use GSAP to animate data transitions, ensuring that users can visually follow changes in complex datasets.

## **5. Best Practices for Modern Web Animations**

* **Keep It Purposeful:** Ensure every animation enhances usability rather than distracting users.
* **Performance Matters:** Overuse of heavy animations can degrade performance; optimize by using hardware-accelerated CSS where possible.
* **Accessibility First:** Provide options to reduce motion for users who are sensitive to movement.
* **Test Across Devices:** Always verify that animations perform well on various screen sizes and devices.

## **6. Conclusion**

Modern web animations bridge the gap between design and interactivity, making web interfaces not just functional but truly delightful. Whether you’re using simple CSS transitions or integrating advanced libraries like GSAP and Anime.js, the key is to experiment and find the right balance that enhances your user experience without compromising performance. Embrace the power of animation, and let your creativity transform your next web project into an engaging digital experience.

A look at how web animations are evolving and what are some currently popular animation libraries.

Modern Web Animations: CSS and Beyond

Articles

GraphQL Best Practices: Gain hands-on experience with schema design, security, and error handling

Ebooks

Open Source

Axolotl is a framework overlord/wrapper thats lets you forget about type-casting and looking into schemas. When there is no drama, only efficiency remains

Axolotl

Translate i18 JSON files automatically with best translating engine in the world without losing format.

DevTranslate

Tree is a simple, yet highly efficient tool for visualizing node-based systems, with only one dependency.

Tree

Based on your graphql schema Zeus generates TypeScript types and strongly-typed clients, maximizing the power, efficiency, productivity, and safety of TypeScript in your GraphQL requests.

Insight, developer tools and more

Services

AEXOL™ Stack

Industries

Resources