## 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](/industries/ecommerce/) 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](/industries/ecommerce/) 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

## Gotowe sklepy internetowe: świetny start, ale czy nie staną się blokadą rozwoju?

**Dlaczego gotowe sklepy są dobrym wyborem na początek?**

Na starcie działalności [e-commerce](/industries/ecommerce/) gotowe platformy sklepowe (np. Shopify, Shoper, WooCommerce) wydają się idealnym rozwiązaniem. Pozwalają szybko uruchomić sprzedaż online bez konieczności inwestowania w kosztowne wdrożenia czy zatrudniania programistów. Ich zalety to:

* Szybka konfiguracja i prostota obsługi
* Niskie koszty początkowe
* Gotowe szablony i integracje z popularnymi płatnościami oraz kurierami
* Brak konieczności posiadania wiedzy technicznej

Dla firm z niewielką liczbą produktów i ograniczonym budżetem to często najlepszy sposób, by przetestować pomysł na biznes i zacząć zdobywać pierwszych klientów.

**Kiedy gotowy sklep staje się pułapką?**

Wraz z rozwojem firmy i wzrostem liczby zamówień pojawiają się nowe potrzeby. Gotowe platformy, które na początku były atutem, mogą zacząć ograniczać rozwój. Najczęstsze problemy to:

* Ograniczona możliwość personalizacji sklepu i procesu zakupowego
* Brak wsparcia dla niestandardowych integracji (np. z systemami ERP, magazynowymi, programami lojalnościowymi)
* Trudności z optymalizacją wydajności przy dużym ruchu
* Ograniczenia w rozbudowie funkcjonalności (np. nietypowe promocje, specyficzne warianty produktów)
* Wysokie koszty prowizji lub abonamentu przy dużej sprzedaży

W efekcie sklep, który miał ułatwiać rozwój, zaczyna go blokować. Firma traci elastyczność, a wdrożenie nowych pomysłów wymaga kosztownych obejść lub migracji na bardziej zaawansowane rozwiązanie.

**Przykład: Migracja sklepu magicznyrynek.pl ze Sky-Shop na Deenruv**

Dobrym przykładem ilustrującym potrzebę migracji ze Sky-Shop na Deenruv jest sklep magicznyrynek.pl. Dla jego właścicieli kluczowym wyzwaniem okazały się ograniczenia Sky-Shop w zakresie integracji z zewnętrznym magazynem, gdzie przechowywana była część zapasów. Brak możliwości płynnej synchronizacji stanów magazynowych oraz automatycznej aktualizacji dostępności produktów uniemożliwiał dalszy rozwój sklepu i skuteczne zarządzanie zamówieniami.

Migracja na platformę Deenruv pozwoliła wdrożyć pełną integrację z zewnętrznym magazynem, zapewniając automatyczną aktualizację stanów magazynowych i eliminując ryzyko błędów przy realizacji zamówień. Dzięki temu [magicznyrynek.pl](https://magicznyrynek.pl "magicznyrynek.pl") mógł sprawnie skalować działalność, oferując klientom aktualne informacje o dostępności produktów i znacząco podnosząc jakość obsługi. Więcej szczegółów dotyczących tej migracji znajdziesz w naszym case study: [magicznyrynek.pl – case study](https://aexol.com/pl/casestudies/magicznyrynek/).

**Znaczenie SEO i integracji z Google Merchant Center**

Wraz z migracją na bardziej elastyczną platformę, jak Deenruv, otworzyły się nowe możliwości w zakresie skutecznego pozycjonowania sklepu oraz integracji z narzędziami Google. Jednym z kluczowych elementów okazała się poprawna integracja z Google Merchant Center za pomocą Merchant API. Dzięki temu rozwiązaniu możliwa jest automatyczna i bieżąca aktualizacja oferty produktowej, co przekłada się na wyższą jakość prezentowanych danych oraz lepszą widoczność produktów w Zakupach Google i innych usługach Google.

Zastosowanie najlepszych praktyk SEO – takich jak optymalizacja opisów produktów, wdrożenie danych strukturalnych czy regularna analiza indeksacji – pozwoliło zwiększyć widoczność sklepu w wynikach wyszukiwania oraz dotrzeć do nowych klientów. Integracja z Merchant Center i konsekwentne działania SEO przyczyniły się do wzrostu ruchu na stronie oraz wyższej konwersji, co potwierdza, jak ważne jest kompleksowe podejście do rozwoju [e-commerce](/industries/ecommerce/) na dedykowanej platformie.

### **Podsumowanie**

Gotowe sklepy internetowe to świetny wybór na początek – pozwalają szybko wejść na rynek i przetestować biznes. Jednak wraz z rozwojem firmy warto regularnie analizować, czy platforma nie staje się ograniczeniem. W pewnym momencie inwestycja w bardziej elastyczne, dedykowane rozwiązanie może okazać się niezbędna, by utrzymać tempo wzrostu i przewagę konkurencyjną.&#x20;

Planujesz otowrzyć sklep online lub potrzbujesz wsparcia w modernizacji starego sklepu, aby w końcu zaczął sprzedawac? Dowiedzieć się więcej o naszych rozwiązaniach, skutecznej integracji z Google Merchant oraz najlepszych praktykach SEO -  [skontaktuj się z nami](mailto:office@aexol.com).

Gotowe sklepy sprawdzają się, gdy masz mało produktów lub dopiero zaczynasz, ale szybko stają sie blokerem wzrostu

Case Study: Przejście ze Sky Shop na bardziej elastyczny silnik e-Commerce

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

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 2025.

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"

Aplikacje mobilne stały się nieodłącznym elementem codziennego życia Polaków. W 2024 roku aż 82,86% internautów korzystało z aplikacji Google, a takie platformy jak Facebook, Messenger, YouTube, Instagram czy TikTok regularnie przyciągają miliony użytkowników miesięcznie. Coraz większą popularnością cieszą się także aplikacje zakupowe (Allegro, OLX, Temu) oraz lojalnościowe (Żappka, Lidl Plus, Biedronka), co pokazuje, jak bardzo zmieniają się potrzeby konsumentów i jak istotne jest posiadanie własnej aplikacji mobilnej w strategii rozwoju firmy.

## Dlaczego warto zainwestować w aplikację mobilną?

* **Zwiększenie zasięgu i lojalności klientów** – aplikacje mobilne pozwalają na stały kontakt z użytkownikiem, wysyłanie powiadomień push, personalizację oferty i budowanie trwałych relacji.
* **Nowoczesny kanał sprzedaży** – aplikacje [e-commerce](/industries/ecommerce/) umożliwiają szybkie zakupy online, dostęp do promocji i programów lojalnościowych, co przekłada się na wzrost sprzedaży.
* **Budowanie wizerunku innowacyjnej marki** – własna aplikacja mobilna to sygnał, że firma jest nowoczesna i dba o wygodę swoich klientów.

## Jak powstaje skuteczna aplikacja mobilna? – Rozbudowany proces krok po kroku

**1. Analiza potrzeb biznesowych i użytkowników**

Proces tworzenia aplikacji mobilnej rozpoczyna się od dogłębnej analizy biznesowej oraz zrozumienia, kim są docelowi użytkownicy i jakie mają potrzeby. Kluczowe jest, aby już na tym etapie precyzyjnie określić cele biznesowe aplikacji, zidentyfikować wyzwania, które ma rozwiązać, oraz ustalić, jak wpisuje się ona w strategię rozwoju firmy. W praktyce oznacza to:

* Prowadzenie warsztatów z klientem, podczas których omawiane są założenia projektu i oczekiwania wobec aplikacji
* Badania rynku oraz analiza konkurencji, by lepiej zrozumieć trendy i preferencje użytkowników
* Tworzenie person użytkowników – wyobrażonych profili reprezentujących różne grupy odbiorców aplikacji
* Wykorzystywanie wywiadów, ankiet i testów prototypów, by zebrać bezpośrednie opinie potencjalnych użytkowników i zidentyfikować ich rzeczywiste potrzeby

Na tej podstawie powstają mapy procesów oraz diagramy przepływu informacji, które pomagają określić kluczowe funkcjonalności aplikacji i jej rolę w realizacji celów biznesowych

**2. Projektowanie UX/UI – intuicyjna nawigacja, estetyczny wygląd, responsywność**

Projektowanie aplikacji mobilnej to nie tylko tworzenie ładnego interfejsu, ale przede wszystkim zadbanie o pozytywne doświadczenia użytkownika (UX) oraz atrakcyjny i spójny wygląd (UI). Kluczowe elementy tego etapu to:

* Tworzenie makiet (wireframes) i prototypów, które pozwalają przetestować różne koncepcje funkcjonalne i układy ekranów
* Projektowanie intuicyjnej nawigacji – użytkownik powinien łatwo odnaleźć się w aplikacji, a wszystkie funkcje muszą być dostępne w logiczny sposób
* Dbałość o przejrzystość, spójność wizualną oraz odpowiednie dopasowanie do wytycznych platform iOS i Android
* Uwzględnienie responsywności – aplikacja powinna działać płynnie i wyglądać dobrze na różnych urządzeniach i rozdzielczościach ekranów
* Testowanie prototypów na użytkownikach, by szybko wykryć i wyeliminować potencjalne problemy z użytecznością

Warto pamiętać, że zarówno funkcjonalność, jak i estetyka są kluczowe dla przyciągnięcia i utrzymania użytkowników.

**3. Wybór technologii – natywne, multiplatformowe, no-code/low-code**

Dobór odpowiedniej technologii ma ogromny wpływ na wydajność, możliwości rozwoju oraz koszty utrzymania aplikacji. Najczęściej stosowane rozwiązania to:

* **Aplikacje natywne** – tworzone osobno dla systemów iOS (Swift) i Android (Kotlin, Java). Zapewniają najwyższą wydajność, dostęp do wszystkich funkcji urządzenia i najlepsze dopasowanie do wytycznych platform
* **Aplikacje multiplatformowe (cross-platform)** – budowane przy użyciu frameworków takich jak Flutter czy [React Native](/technologies/reactnative/), pozwalają na jednoczesne tworzenie wersji na Android i iOS, co skraca czas i obniża koszty wdrożenia
* **No-code/low-code** – narzędzia takie jak Adalo czy Bubble umożliwiają szybkie prototypowanie i wdrażanie prostych aplikacji bez konieczności zaawansowanego programowania, co jest idealne dla MVP lub mniej złożonych projektów

Wybór technologii powinien być zawsze dostosowany do specyfiki projektu, oczekiwań klienta oraz planów rozwoju aplikacji.

**4. Testowanie i optymalizacja – gwarancja jakości i satysfakcji użytkowników**

Ostatni, ale nie mniej ważny etap to wieloetapowe testowanie i optymalizacja aplikacji. Obejmuje on:

* Testy funkcjonalne – sprawdzanie, czy wszystkie funkcje działają zgodnie z założeniami.
* Testy użyteczności – weryfikacja, czy aplikacja jest intuicyjna i wygodna w obsłudze dla użytkowników docelowych
* Testy wydajnościowe i bezpieczeństwa – ocena szybkości działania oraz odporności na potencjalne zagrożenia.
* Testy na różnych urządzeniach i systemach operacyjnych – zapewnienie pełnej responsywności i kompatybilności
* Iteracyjne poprawki na podstawie zebranych danych i opinii użytkowników – proces optymalizacji nie kończy się po wdrożeniu, aplikacja powinna być stale rozwijana i dostosowywana do zmieniających się potrzeb rynku

Dzięki takiemu podejściu powstaje aplikacja mobilna, która nie tylko realizuje cele biznesowe, ale przede wszystkim odpowiada na rzeczywiste potrzeby użytkowników i zapewnia im pozytywne doświadczenia na każdym etapie korzystania z produktu.

## Pozycjonowanie aplikacji mobilnych (ASO) – jak zdobyć więcej pobrań?

Aby Twoja aplikacja mobilna była widoczna w Google Play i App Store, niezbędna jest optymalizacja pod kątem słów kluczowych (ASO – App Store Optimization). Najważniejsze elementy skutecznego pozycjonowania aplikacji to:

* **Analiza słów kluczowych** – wybór fraz, które najczęściej wpisują użytkownicy (np. „aplikacja mobilna dla firm”, „aplikacja zakupowa”, „tworzenie aplikacji mobilnych”, „aplikacje na Android i iOS”).
* **Umieszczanie fraz w tytule i opisie aplikacji** – tytuł powinien zawierać najważniejsze słowa kluczowe, a opis szczegółowo przedstawiać funkcje i korzyści aplikacji.
* **Stosowanie fraz long tail** – mniej konkurencyjne, ale precyzyjne frazy zwiększają szansę na dotarcie do konkretnej grupy odbiorców.
* **Monitorowanie pozycji i analiza konkurencji** – regularne sprawdzanie skuteczności wybranych słów kluczowych i reagowanie na zmiany trendów.

## Najczęściej wyszukiwane frazy związane z aplikacjami mobilnymi

* aplikacje mobilne dla firm
* tworzenie aplikacji mobilnych
* aplikacje na Android i iOS
* aplikacje zakupowe
* aplikacje lojalnościowe
* projektowanie aplikacji mobilnych
* aplikacje webowe
* aplikacje [e-commerce](/industries/ecommerce/)
* aplikacje dla sklepów internetowych
* aplikacje dla przedsiębiorstw

## Podsumowanie

Aplikacje mobilne to dziś nie tylko narzędzie komunikacji, ale także platforma sprzedażowa, rozrywkowa i organizacyjna. Ich rosnąca popularność wśród polskich użytkowników sprawia, że inwestycja w nowoczesną aplikację mobilną i webową to kluczowy krok w rozwoju każdej firmy. Jeśli chcesz dowiedzieć się, jak zaprojektować skuteczną aplikację mobilną dla swojego biznesu lub potrzebujesz wsparcia w zakresie pozycjonowania aplikacji, skontaktuj się z naszym zespołem – pomożemy Ci osiągnąć sukces w świecie mobilnych technologii.

Aplikacje mobilne – klucz do sukcesu Twojego biznesu online

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](/technologies/reactnative/), 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 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?

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.![](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.![](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


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](/industries/ecommerce/) 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?

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

Dokładne spojrzenie na wszystkie aspekty dostępności aplikacji internetowych - standardy, wytyczne i ich wdrażanie.

Kompleksowy przewodnik po dostępności aplikacji internetowych

## 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

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

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.

![](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?


Looking at the world of [e-commerce](/industries/ecommerce/) one thing that jumps at you is how quickly things change and how difficult it is to stay ahead of the curve. Keeping pace with the latest technological advancements isn't easy but it's essential for businesses which want to stay competitive and attract new customers. The most important choice is the platform and the one you pick can either be of immense help or a complete stumbling block, which will only waste your time and effort.

## Platforms galore

There's a number of shop platforms to choose from: [Shopify](https://www.shopify.com/), [Shoper](https://www.shoper.pl/), [WooCommerce](https://woo.com/), [IdoSell](https://www.idosell.com/), [OpenCart](https://www.opencart.com/), [Volusion](https://www.volusion.com/) and many, many others. Choosing the right one isn't easy and usually requires a lot of research and a bit of trial and error. It definitely did in our case - we've been through them all! Recently to our surprise, we found a fresh [e-commerce](/industries/ecommerce/) solution that finally had what we were looking for. [E-commerce](/industries/ecommerce/) platforms provide good out of the box services, but most (if not all) have a lot of problems when it comes to customization. They usually handle this via some clunky workaround or band-aid solution that works so-so and often creates more problems than it solves like Shopify's liquid syntax (which almost everyone wraps with JS anyway). This often leads to numerous problems with customization, performance and SEO.

Setting up a shop quickly using some Wordpress-like platform isn't a problem. The real issues will keep popping up down the line since you're forced into the Wordpress ecosystem with all its benefits and all its many many flaws. It's quick and easy by design and it is meant as a one-size-fits-all solution, and when that 'one size' stops fitting you're going to be in trouble. From SEO, through mobile responsiveness and performance, everything will work so-so and improvements will be nigh impossible due to the underlying issues of the platform and the way it's built. That's why [Vendure](https://www.vendure.io/) has attracted our interest - it offers far more flexibility than any other platform we've come across. Its developer-friendly approach allows for nearly limitless customization and creating a store that works just like you want it to without worrying about platform limitations or workarounds.

## Developer friendly

Developer-friendly in the case of Vendure means relying on [Node.js](https://nodejs.org/en), [TypeScript](https://www.typescriptlang.org/), and [GraphQL](https://graphql.org/) while being fully open source. Node.js and TypeScript are industry standards when it comes to web development - they ensure high performance, scalability and better code quality. GraphQL is a backend technology that focuses on fostering better collaboration between frontend and backend developers while also greatly improving efficiency by eliminating the problems with over and under-fetching. With that combo working with Vendure as a dev is a breeze, especially in comparison with clunky cms-like tools known from other [e-commerce](/industries/ecommerce/) platforms. Vendure's modular and extensible architecture allows businesses to tailor the platform to their needs, applying whatever customization features and functionalities they need and integrating with third-party services. If you want to check out an idea of what you can do with Vendure just check out our demo shop at [shop.aexol.com](https://shop.aexol.com/)

## Vendure forth!

Even a quick look at the demo should give you a good idea of the lightning-fast performance of the store. That can serve as a glimpse of what you can achieve when developers are aided by the tools of the platform instead of being hampered by them and that's where Vendure really shines. Sure we could set up a demo shop using any other platform but it wouldn't be as fast or as easy to do and most importantly wouldn't be anywhere near as enjoyable to work on. So the simple question is why settle for a bland WordPress shop that will look just like everyone else's when you can set up something that will set you apart from the competition both in terms of look and customer experience?

## We've got you covered

We're an official partner of Vendure and as you can see we quickly got a hang of its possibilities. We can also easily guide you through the entire process, setting up your store to be lightning-fast and easily scalable right from the start! Vendure's flexibility lets us adopt your design or create a unique one from scratch and integrate your store with whichever payment platforms or other third-party services you require. Whether you are embarking on a new venture or seeking to revitalize your existing store, Vendure's feature-rich platform, backed by real-life examples, is the solution to take your online business to the next level. Check out [their official website](https://www.vendure.io/) to explore the possibilities and embark on the Vendure ecommerce journey - just remember to tell them you came from us :)


What can Vendure ecommerce do for your business? Read this short blogpost or go ahead and check out our demo store!

How to scale your eshop with Vendure ecommerce!


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

W miniony weekend w krakowskiej Tauron Arenie odbył się największy hackathon w Europie - Hackyeah 2023. Zawody zgromadziły utalentowane umysły z Polski i całej Europy i posłużyły jako pole bitwy dla ekspertów IT. Oczywiście udział w takim wydarzeniu to nie tylko praca i rywalizacja, ale także szansa na poznanie wielu różnych ludzi z branży IT oraz wymianę pomysłów, myśli i doświadczeń. Niemniej jednak wszyscy byli tam, aby zobaczyć główne wydarzenie - stawianie czoła wyzwaniom technologicznym w ciągu 24 godzin. Kategoria, w której brał udział zespół AEXOL, wymagała stworzenia rozwiązania modernizującego sektor edukacji przy użyciu technologii.

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

Nasz zespół wykorzystał sztuczną inteligencję do stworzenia kompletnego MVP (Minimum Viable Product) dla zadania GovTech, łącząc różne narzędzia, umiejętności i technologie. Dzięki temu zajęli trzecie miejsce w kategorii "Edukacja w innowacjach", a ich projekt przyciągnął uwagę zarówno uczestników, jak i sędziów konkursu ze względu na innowacyjne podejście do wyzwań edukacyjnych. Z dumą mogę powiedzieć, że nasz zespół stworzył jeden z najbardziej rozpoznawalnych projektów, które pojawiły się na tym wyjątkowym wydarzeniu.

## Zespół

Nagrodzony zespół składa się z Aleksandra Bondara (frontend developer), Arkadiusza Kuryło (backend developer), Adama Michałowskiego (frontend developer), Jakuba Sowy (grafik 3D - zewnętrzny dla AEXOL), Adrianny Gregorczuk (lider) i Moniki Szypurskiej (grafik - zewnętrzny dla AEXOL). Ich stack składał się z React, Next.js, TypeScript, GraphQL, Stucco.js, mongoDB, Figma i Blender. Służył on połączeniu różnych umiejętności członków zespołu i był kluczem do osiągnięcia celu wyzwania. Osiągnięcie to jest wynikiem połączonego wysiłku, który wymagał wielu godzin ciężkiej pracy i poświęcenia całego zespołu.
![](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/hackyeah3-1730907356215.webp)
Projekt polegał na wdrożeniu sztucznej inteligencji, aby pomóc studentom w wyborze kierunku studiów. Skuteczne narzędzie pomagające w podejmowaniu kluczowych decyzji życiowych może być bardzo pomocne w dzisiejszym świecie, zwłaszcza jeśli chodzi o decyzje tak ważne, jak wybór odpowiedniej instytucji edukacyjnej lub kierunku studiów. Nasz zespół podjął wyzwanie, wykorzystując nasz przeszkolony model chatGPT i projektując aplikację wokół niego - umożliwiając użytkownikom łatwe i dokładne wyszukiwanie szkół, instytucji edukacyjnych lub programów studiów, które najlepiej odpowiadają ich indywidualnym potrzebom. Ich rozwiązanie może stać się częścią Portalu Edukacji i Nauki - edukacja.gov.pl!

## Badania - Pokolenia Z i Alpha

Znamy poruszane kwestie i cele projektu, ale tak naprawdę nie rozmawialiśmy o pierwszym kroku. Jak zespół wpadł na pomysł aplikacji, skąd się wziął i jakie badania na ten temat przeprowadził?

Znaczenie demograficzne pokolenia Z jest nie do przecenienia. Pokolenie to, stanowiące 15,4% populacji Polski, stoi przed wieloma wyjątkowymi wyzwaniami. Badania sugerują, że niezadowolenie doświadczane przez młode osoby może mieć daleko idące konsekwencje, co sprawia, że konieczne jest zajęcie się ich obawami w odpowiednim czasie.
![](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/hackyeah4-1730907380398.webp)
Liczne badania psychologiczne dotyczyły wpływu niezrealizowanych aspiracji na samopoczucie psychiczne. Ciężar niespełnionych marzeń może prowadzić do poczucia frustracji i rozczarowania, podkreślając znaczenie zapewnienia młodym ludziom możliwości realizacji ich ambicji. Badania z zakresu psychologii społecznej konsekwentnie podkreślają znaczenie solidnego systemu wsparcia. Młode osoby, którym brakuje odpowiedniego wsparcia ze strony najbliższego otoczenia, mogą napotykać przeszkody w rozwoju osobistym i zawodowym. Inicjatywy mające na celu oferowanie mentoringu i wskazówek podczas przejścia do dorosłości są niezbędne dla ich rozwoju.

Patrząc na pokolenie Alpha, często określane jako "Always on", wczesne prognozy ekonomiczne i społeczno-naukowe wskazują na preferowanie wysoce spersonalizowanych doświadczeń, wzmocnienia pozycji i innowacji. Zrozumienie tych zmieniających się preferencji jest niezbędne do kształtowania przyszłego krajobrazu. Pojawiająca się jako potencjalne remedium na wieloaspektowe wyzwania stojące zarówno przed Pokoleniem Z, jak i Pokoleniem Alpha, kompetentna administracja AI oferuje wskazówki i wsparcie w podejmowaniu złożonych decyzji życiowych i zawodowych. Wykorzystanie mocy sztucznej inteligencji może być przełomem w zaspokajaniu potrzeb tych zaawansowanych technologicznie pokoleń.
![](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/hackyeah5-1730907405673.webp)
Tworząc swoje rozwiązanie, zespół czerpał inspirację z wciągających cech obserwowanych na popularnych platformach do gier, takich jak Roblox i Minecraft. Te wirtualne środowiska były szeroko badane w kontekście zaangażowania i doświadczenia użytkowników. Łącząc elementy immersji i CAVE, starali się stworzyć produkt, który nie tylko przyciąga uwagę, ale także ewoluuje w wielu kierunkach, zachowując przy tym oryginalną koncepcję MVP.

## Dopracowanie

Teraz, gdy dowiedzieliśmy się o problemach, z którymi borykali się nasi przyjaciele, możemy przejść do kwestii technicznych. Jak wiemy, zespół zwrócił swoje umysły i możliwości w kierunku tak zwanego dostrajania. W stale ewoluującym krajobrazie sztucznej inteligencji, dostrajanie pojawiło się jako kluczowa technika zwiększania możliwości wstępnie wytrenowanych modeli. Dostrajanie to proces, który pozwala nam dostosować te modele do wykonywania określonych zadań z większą dokładnością i trafnością.
![](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/hackyeah5-1730907405673.webp)
Zanim zagłębimy się w zawiłości dostrajania, konieczne jest zrozumienie koncepcji wstępnie wytrenowanych modeli. Modele te to systemy sztucznej inteligencji, które zostały przeszkolone na ogromnych ilościach danych, zazwyczaj z Internetu, w celu poznania wzorców i struktur języka naturalnego lub obrazów. Dobrze znanym przykładem wstępnie wytrenowanego modelu jest seria GPT (Generative Pre-trained Transformer) firmy OpenAI do przetwarzania języka naturalnego, która obejmuje GPT-3.5, podstawę tej sztucznej inteligencji.

Wstępnie wytrenowane modele są przeznaczone do wykonywania szerokiego zakresu zadań, od generowania tekstu po tłumaczenie językowe, analizę nastrojów i nie tylko. Mogą one jednak nie być optymalne dla konkretnych, specyficznych dla domeny lub drobnoziarnistych zadań. W tym miejscu do gry wkracza dostrajanie.

Dostrajanie jest podobne do procesu "specjalizacji" wstępnie wytrenowanych modeli. Jest to proces przyjmowania ogólnego przeznaczenia, wstępnie wytrenowanego modelu i dostosowywania go tak, aby wyróżniał się w określonym zadaniu lub domenie. Można to porównać do nadania uniwersalnemu narzędziu zaostrzonej krawędzi do konkretnego zadania. Zamiast zaczynać od zera i trenować zupełnie nowy model, dostrajanie wykorzystuje istniejącą wiedzę wstępnie wytrenowanego modelu, oszczędzając czas, zasoby obliczeniowe i dane. W świecie sztucznej inteligencji dostrajanie stało się krytyczną techniką zwiększania możliwości wstępnie wytrenowanych modeli. Wypełnia ona lukę między ogólną sztuczną inteligencją a sztuczną inteligencją specyficzną dla zadania, oferując wydajny i skuteczny sposób dostosowywania modeli do konkretnych potrzeb. Ponieważ sztuczna inteligencja nadal odgrywa kluczową rolę w różnych dziedzinach, nie można przecenić znaczenia dostrajania, ponieważ pozwala nam uwolnić pełny potencjał tych potężnych systemów sztucznej inteligencji.![](https://aexol-cms.fra1.cdn.digitaloceanspaces.com/aexolcom/media/hackyeah6-1730907465865.webp)

## Gratulacje

Chciałbym serdecznie pogratulować naszemu zespołowi zdobycia prestiżowej nagrody i osiągnięcia powszechnego uznania dla ich wysiłków. Mam nadzieję, że ich projekt wniesie znaczący wkład w polski sektor edukacji poprzez wykorzystanie najnowszych technologii, w tym sztucznej inteligencji. Integracja sztucznej inteligencji z procesami edukacyjnymi ma ogromny potencjał, aby znacznie poprawić jakość i dostępność edukacji.

Dzięki waszym wysiłkom zobaczyliśmy, jak uczniowie mogą mieć możliwość korzystania ze sztucznej inteligencji w angażujący i skuteczny sposób, przygotowując się na przyszłość, w której technologia odgrywa coraz ważniejszą rolę. Zdobycie zasłużonego 3. miejsca w naszym pierwszym starcie w tak dużym wydarzeniu jest wyrazem uznania dla ciężkiej pracy i zaangażowania. Stanowi również zachętę do udziału w podobnych wydarzeniach w przyszłości dla wszystkich w Aexol. Więc jeszcze raz: gratulacje!

Nasz zespół zajął 3. miejsce, prezentując aplikację opartą na sztucznej inteligencji, której celem są innowacje edukacyjne i wzmocnienie pozycji przyszłych pokoleń.

Aexol błyszczy na największym hackathonie w Europie - HackYeah 2023!

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.

![](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.
![](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.
![](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.
![](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.
![](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.![](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](/technologies/reactnative/) 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](/technologies/reactnative/), 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](/technologies/reactnative/) 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


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](/technologies/reactnative/) 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](/technologies/reactnative/)

[React Native](/technologies/reactnative/) 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](/technologies/reactnative/) 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](/technologies/reactnative/) 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](/technologies/reactnative/), 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](/technologies/reactnative/) 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](/technologies/reactnative/) 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](/technologies/reactnative/) 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](/technologies/reactnative/) 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](/technologies/reactnative/). For the usual cases where the biggest factors are time and cost [React Native](/technologies/reactnative/) 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

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](/technologies/reactnative/) 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.

![](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](/technologies/reactnative/) 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](/technologies/reactnative/) 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](/technologies/reactnative/)

While not the only frameworks you can choose from, Flutter and [React Native](/technologies/reactnative/) 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](/technologies/reactnative/) in March of 2015 and Google released Flutter in April of 2018. [React Native](/technologies/reactnative/) 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](/technologies/reactnative/) 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](/technologies/reactnative/) uses widely known JavaScript, Flutter uses Dart which is a custom object oriented language made by Google. While this might seem like [React Native](/technologies/reactnative/) 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](/technologies/reactnative/) 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](/technologies/reactnative/) 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](/technologies/reactnative/) 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](/technologies/reactnative/) 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](/technologies/reactnative/) 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](/technologies/reactnative/) 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](/technologies/reactnative/) 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](/technologies/reactnative/) 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](/technologies/reactnative/) 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](/technologies/reactnative/) 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](/technologies/reactnative/) 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](/technologies/reactnative/) 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](/technologies/reactnative/). 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](/technologies/reactnative/) 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](/technologies/reactnative/) 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](/technologies/reactnative/) 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](/technologies/reactnative/) 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](/technologies/reactnative/). 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](/technologies/reactnative/) 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

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

Axolotl

DevTranslate

Tree

GraphQL Zeus

Aexol Sp. z o.o.

Contact

Services

Technologies

Industries

Resources