small_avatar_AdrianR3.png

thumbnail_avatar_AdrianR3.png

avatar_AdrianR3.png

Adrian

GET IN TOUCH

#### What is a design system?

Whenever we're talking about a group of components e.g buttons, inputs, icons that share similarities in the design e.g colors, fonts - we're talking about a **design system**.

Whenever we're talking about font families line-heights, or font sizes for given headings and paragraphs (a.k.a typography) - we're talking about a **design system**.

To summarize, a design system is a set of guidelines and components that together create a coherent application. 


#### Advantages of a design system

1. **Consistency:** By introducing visual and interactive elements with a similar color scheme and fonts, a design system ensures that a given application looks and behaves consistently across a whole app or even multiple apps.
 
2. **Implement once, reuse everywhere**: It streamlines the design and development process by providing reusable components and patterns, reducing the need to reinvent solutions for common design challenges.
    
3.  **Scalability:** As applications evolve and new features are added, a design system helps maintain coherence and adapt to changes without compromising the overall user experience.


#### What makes a good implementation of a design system component?

Now that we know what a design system is and its benefits, let's consider for a second what we, front-end developers, need to keep in mind when implementing a component from the design system.

**Ease of use** - every component should have a simple and intuitive API that builds on top of or extends native HTML element attributes. Here are a couple of examples:
- every prop that corresponds to an event handler should start with the `on` prefix `onClick` `onInputChange` `onSelect` since it fits react elements event handlers `onClick` `onMouseEnter` `onMouseLeave`;
- every prop that is a boolean should be in the past participle form, e.g., `disabled`, `focused`, `selected`, since it fits  native HTML attributes, e.g buttons or inputs;

_**These rules are not set in stone and may differ from project to project. However, it's important to decide on one way, before implementation and document it as a guideline for other developers to be aware and follow.**_

**Extensibility** - there can be places within the application where the same component e.g. inputs, has a fixed width of 200px, but should take a full container width in other places. So,  each component should have some form of flexibility to also cover some out of ordinary scenarios.


####  Tools to implement a design system

At Bitnoise, we've designed and implemented many unique and beautiful design systems in React-based applications. Thus, we have a selection of proven tools that help us implement quickly and painlessly.

_**Keep in mind that this tool selection is mostly based on our team’s preferences. Selected tools may differ based on your project demands and team preferences.**_

These are the tools we commonly use:
- **[clsx](https://github.com/lukeed/clsx)** - for managing components classes.
- **[tailwind-merge](https://github.com/dcastil/tailwind-merge)**—to ensure that tailwind classes do not contradict one another.
- **[class-variance-authority](https://cva.style/docs)**—for handling complex component styling that differs based on provided props. For example, a button can have a primary, secondary, or ghost variant.
- **[react-aria-components](https://react-spectrum.adobe.com/react-aria/getting-started.html)** - to ensure our components are accessible and meet WCAG requirements.
- **[storybook](https://storybook.js.org/)** - for having all components list out and documented. It helps to avoid duplicated components and to introduce a new developer into a project.


#### Implementing a component

In this section I will guide you through my process of implementing the components from design systems.

##### 1. Looking at a provided design system

First things first, we need to examine the beautiful design system provided by a UI designer (for simplicity, let's focus on a single part of the design system - typography). 

![blog-heading.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_heading_f729018df3.jpg)


Here are a couple of notes I took by looking at the design:
- we have 6 headings and 2 body texts,
- font sizes, font weights and line heights are as follows:
	- **Heading 1** - 92px, 700, 120%
	- **Heading 2** - 73px, 600, 120%
	- **Heading 3** - 59px, 600, 120%
	- **Heading 4** - 48px, 400, 120%
	- **Heading 5** - 38px, 400, 120% 
	- **Heading 6** - 30px, 400, 120%
	- **paragraph 1** - 24px, 400, 125%
	- **paragraph 2** - 16px, 400, 125%
	- **small text** - Manrope, 12px, 500, 125%


##### 2. Creating utils and utility types

Before implementing the component itself, we will add one utility function and one utility type that will help us in implementing this and other components. 

These utils help keep already long tailwind classes clean and noncontradictory to each other. 

_**If you're not using tailwind, you don't need to have this util... duh.**_

Similar to the built-in react utility type `PropsWithChildren` we're implementing a generic utility type `PropsWithClassName`  to ensure that our components will also accept the className prop and so that we don't need to add them manually in each and every component props.

##### 3. Implementing the component

Now it's time to get our hands dirty and actually start to implement the component itself.
-	Keeping in mind **ease of use** rule described above, we can map Heading 1, ..., Heading 6 to `h1` to `h6` html tags, which is convenient. Paragraphs 1 and 2 should be a `p` tag, and small text can be a `span`.


Now that the basis of the components were implemented, we should add styles for a given tag to match the design system. 


And then we can apply the styles to the component.

So far, so good, but what if we want to have a different color or we want to head 1 to be semibold instead of bold in some places in the application? The component should allow updating styles when needed.

Now overwriting basic styles is possible with new classes provided in the Parent component by using `className` prop. 

##### 4. Using the component in the application

Here's how it looks in the browser:

![blog-hello world.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_hello_world_a7d7835f53.jpg)

#### **Whole component code:**


####  Summary

In this blog post, we've created a very intuitive and simple-to-use component that will handle typography in the application. If the styling of any given tag needs to be updated, it will only require a change in one place instead of looking for specific tags across multiple files.

I hope that walking you through my work process, from looking at a design system to implementing a React component will help you think differently about building components, ensuring they are both intuitive and highly reusable.


large_blog-MICHAŁ GĄSIOREK_cover_high.jpg

medium_blog-MICHAŁ GĄSIOREK_cover_high.jpg

small_blog-MICHAŁ GĄSIOREK_cover_high.jpg

thumbnail_blog-MICHAŁ GĄSIOREK_cover_high.jpg

blog-MICHAŁ GĄSIOREK_cover_high.jpg

Implementing a design system in React

When we were tasked with building a website for Boom SuperSonic, we felt the gravity of the challenge. A groundbreaking aviation start-up, with hundreds of billions of dollars of funding and an aspiration to push the laws of physics to the limit, needed a website that would not disappoint. 

To match their ambition, BoomSupersonic hired a California-based studio, HOO KOO E KOO, to conceptualize and design a powerful web presence. We joined the process to develop a pixel perfect solution.

What is Boom SuperSonic?

From the very beginning Boom Supersonic's ambition has been to allow passengers to travel faster than sound. This dream was a reality in the past but was abruptly ended by Concorde's tragic accident in 2000. 

Boom's flagship airplane - the Overture - was designed to be significantly safer, more efficient and greener than its predecessor. In June 2021, a milestone was reached, as United Airlines announced it ordered the first batch of 15 planes from the manufacturer. 

![ ](\uploads\home-united_2x_3HNaY5HIdoNDhcRs4kYeEc.jpeg)
 Challenges in website development

The designs we received from HOO KOO E KOO stressed the innovative character and seriousness of the project. The site was not intended to be overly complex but had to work impeccably. Think of an airplane manufacturer who cannot engineer its own website...

To reach this goal, our developers used React and Next.js. We paid special attention to the specification we received from designers, spent a considerable amount of time on testing, and brought the website vision to life, just as our client is making their vision a reality. 



small_KHEK_pic01.jpg

thumbnail_KHEK_pic01.jpg

KHEK_pic01.jpg

Boom! How we built a pixel-perfect frontend for a SuperSonic company

PozTechTalks is a unique series of generally available meetings of practitioners from three leading Poznań technology companies - Apptension, Bitnoise and STX Next. Based on our experience and projects that we have managed, we talk about technologies, good and bad practices, tools we use, business issues and technical details of solutions that we have introduced in projects for our top clients.

🚀 Who creates PozTechTalks? 🚀

🐍 STX Next - the Largest Python House in Europe,

💡 Apptension - the best combination of design and technology,

💪 Bitnoise - the specialists for demanding projects.

Together we have:

🏆 36 years on the market

👩🏻‍💻 +496 employees

✅ + 70 projects per year


The topic of the first meeting is REACT. The interview was attended by: Robert Musił (JavaScript Expert / STX Next), Patryk Ziemkowski (Head of Development / Apptension) and Lukasz Roth (CTO / Bitnoise). The conversation was moderated by Krzysztof Kempiński, programmer and host of the podcast Porozmawiajmy o IT.

The premiere took place on Wednesday, August 4 at 11:00 am, on our YouTube channels and on our Facebook pages! 

We have summed up some “Golden Thoughts” for you, and you can download it here!



PozTechTalks: React

small_Blog_artykul_PozTechTalks_01.jpg

thumbnail_Blog_artykul_PozTechTalks_01.jpg

Blog_artykul_PozTechTalks_01.jpg

PozTechTalks #01: React 

Prettier is like your very experienced colleague who constantly whispers advice about your code consistency and readability. Who wouldn’t want one? 


Unfortunately, very experienced developers are often busy, and that’s why [Prettier](https://prettier.io/)
 was created. In essence, it’s a tool that helps developers implement best coding practices automatically. 

Here is a concise **Prettier guide** including key benefits, **React** and **Typescript** code examples, and comments from our developers. 

#### **Key benefits**
- **Opinionated Formatting:** Prettier has a set of default formatting rules based on community best practices, making it easy to format your code without spending time on style debates. 

- **Multiple Language Support:** Prettier supports various programming languages such as JavaScript, TypeScript, CSS, HTML, and more. 

- **Customizable Rules:** Prettier allows you to customize the formatting rules to fit your project's specific needs, giving you more control over your code formatting. 

- **Easy Integration:** Prettier can be integrated into your development workflow with ease, enabling you to automate your code formatting and improve your productivity. 

- **Improved Readability:** By formatting your code consistently and following best practices, Prettier can make your code more readable and easier to understand. 

- **Reduced Maintenance Time:** Prettier can save you time on code maintenance, as it can automatically format your code as you write it, reducing the need for manual formatting.

- **Reduced Human Error:** By automating the code formatting process, Prettier can reduce the chance of human error and ensure that your code is always formatted correctly.


![ ](\uploads\blog-prettier_Lukasz_post_cytat_01-1_3tfodtSBNooCMUZATR9yqN.jpg)
#### **How does Prettier work?**
Prettier parses your code into an abstract syntax tree (AST) using a parser specific to the programming language you are using. 

1. Applies a set of formatting rules to the AST, modifying it to conform to the formatting rules. These rules are based on community best practices and are designed to ensure consistency and readability in your code. 

2. Generates formatted code based on the modified AST, producing a new code file that conforms to the formatting rules. 


Prettier also provides options to customize the formatting rules, allowing you to tailor the formatting to your project's specific needs. Once configured, you can integrate Prettier into your development workflow using various tools such as code editors or build scripts. This way, **you can automate your code** formatting and maintain a consistent code style across your team.

#### **How to install Prettier?**
To configure Prettier, you can create a configuration file in your project's root directory. Here is the step-by-step guide:

1. **Install Prettier:** You can install Prettier either globally or locally to your project using a package manager like npm or yarn. For example, to install Prettier globally, you can run the following command in your terminal:


``npm install -g prettier``

2. Create a configuration file: Create a ``.prettierrc`` or ``prettier.config.js`` file in your project's root directory.

3. Specify formatting rules: In your configuration file, you can specify the formatting rules you want Prettier to apply. You can find a list of available options in the Prettier documentation. Here's an example ``.prettierrc`` file that sets the maximum line length to 80 characters and uses single quotes for string literals:

![ ](\uploads\blog-prettier_Lukasz_post_cytat_01_C7f9YCZX42n8FbuHij8i2.jpg)
#### **How does Prettier work with JavaScript and Typescript?**
Here are some examples of how Prettier works with JavaScript and TypeScript:

1. Formatting JSX  

Before:




3. Formatting TypeScript in a Functional Component

Before:



#### **What are alternative and complementary tools?**
1. [ESLint](https://eslint.org/)
: ESLint is a popular static analysis tool for identifying problematic patterns found in JavaScript code. It has built-in rules and plugins for code formatting and styling.


2. [JSHint](https://jshint.com/)
: JSHint is a community-driven tool that helps detect errors and potential problems in JavaScript code. It has built-in options for enforcing code style and formatting.


3. [StandardJS](https://standardjs.com/)
: StandardJS is a style guide and linter for JavaScript code. It has a built-in code formatter and can be integrated into various editors and IDEs.


4. [Beautify](https://marketplace.visualstudio.com/items?itemName=HookyQR.beautify)
: Beautify is a code formatter that can be used with various programming languages, including JavaScript. It has plugins for popular editors and IDEs like VS Code, Atom, and Sublime Text.


5. [CodeMirror](https://codemirror.net/)
: CodeMirror is a versatile text editor for the web that can be used for formatting and styling code. It has built-in features for code highlighting, indentation, and autocomplete.


6. [JS Beautifier](https://beautifier.io/)
: JS Beautifier is a simple tool that can be used for formatting and beautifying JavaScript code. It has options for configuring the code style and formatting rules.


7. [Black:](https://github.com/psf/black)
 Black is a Python-based code formatter that can be used for formatting code in various programming languages, including JavaScript. It has options for configuring the code style and formatting rules.


#### **Summary**
Prettier is a code formatting tool that automatically implements best coding practices, and improves code consistency, and readability. 

It has default formatting rules based on community best practices, supports multiple programming languages, is customizable, and can be easily integrated into a development workflow. Prettier works by parsing code into an AST, applying formatting rules, and generating new formatted code. Developers can install Prettier by creating a configuration file with specified formatting rules. Prettier works - among others - JavaScript and TypeScript. 

I encourage you to try out Prettier and other similar tools. 

If you have any questions or are interested in our services, do not hesitate to reach out to us.

small_blog-prettier_Lukasz_cover_high.png

thumbnail_blog-prettier_Lukasz_cover_high.png

blog-prettier_Lukasz_cover_high.png

How to make your code better with Prettier?

React has been around for a while, and it is currently the leading frontend framework (ok, library). It somehow manages to stay ahead of the pack despite tough competition. The React community is massive and that in itself is a good enough reason to expect a framework to stay popular as the adoption curve cycle slowly plays out. This sort of drift, however, is definitely not what’s happening with React. In fact, React stays popular because it keeps reinventing itself in the attempt to answer the changing needs of UI engineering (and, for the most part, does so gracefully, without compromising backwards compatibility).

This article looks at React's latest attempt to chart a new course, this time by laying out a bold vision around extending the component ecosystem into the server with **React Server Components**. The technology is not yet fully production ready, but you can already test early implementations offered by Next.js (and Remix might soon follow suit), and so it is probably mature enough that decision makers in companies using React (or considering using React) should start paying attention. 

First let’s understand the challenges the React team is trying to address and then look at potential adoption challenges and how the way we build and structure teams of React developers going forwards would change should the vision be brought to fruition.


#### **Why is React evolving towards the server side?**
It may come as a surprise if you’ve worked with react for years, but the React team now recommends to start new React projects through fullstack React metaframeworks:

![ ](\uploads\blog-serverReact_post_01_7EIWdEC0ow4M5qFf65l5pA.png)
*Source: react.dev*

The emphasis on using a framework is such that they felt it necessary to preempt the question of whether React is still its own thing.

![ ](\uploads\blog-serverReact_post_02_6XqaSpCjS2vNDLNmmc5Vy2.png)
*Source: react.dev*

This is quite a shift, considering that for the longest time the recommended solution was to use CreateReactApp - a tool built by the react team which spins up a React SPA (i.e. a client side only app). **What explains that change?** In short, React Server Components. Answering this question in a bit more detail is still rather challenging though, because – while the authors know the answer very well – they’re still figuring out the best way to communicate this to the outside world in a way that would capture people’s imagination. Luckily, **Dan Abramov from the React core team has lately given us a sneak peak** of their thinking by testing some pitch ideas for React Server Components on his private twitter account.

![ ](\uploads\blog-serverReact_post_03_7Ct4KhNuhk4eZXZDX0I28K.png)
*Source: Twitter*

You can read the whole thread here:

["i need to start collecting ways to pitch react server components.](https://twitter.com/dan_abramov/status/1631885118355718144?lang=en-GB)
"

But here’s my top 3.

#### **Best pitch for Server Side Components: 3rd place**
![ ](\uploads\blog-serverReact_post_04_jsP1HQs3YXsp6dBnnm21l.png)
*Source: Twitter*

This one, Dan readily agrees, is a little hyperbolic - but then most good sales pitches are. It gets third place because it’s rather inaccurate, but it does communicate the promise of having to think about getting data as part of architecting your UI much less often. 

Currently the data fetching pattern the react team has converged on is all about favoring collocation of components and data fetching, i.e. each component knows what data it needs and fetches it as required. There are many benefits of this approach, full composability being probably the largest. The drawback is that, since all that fetching happens on the client, each component triggers its fetching logic only once it gets rendered, which depends on the ancestors having been rendered and having fetched their data etc. - a waterfall of queries ensues, and the need to cache and dedupe requests on the client presents itself very quickly as the app grows. 

In Meta (React’s mother company) that is handled by the Relay framework, which facilitates stitching together a top level GraphQL query based on data dependencies declared locally by every component. It then takes care of optimizing a single top level query, which includes deduplication (the same data requested by multiple components gets requested once). Relay is a very powerful solution, check out this talk by Robert Balicki from the React Data Team to learn more: [https://www.youtube.com/watch?v=lhVGdErZuN4](https://www.youtube.com/watch?v=lhVGdErZuN4)


While RSC and Relay are very different things and might be used in conjunction, **they do have an overlap when it comes to solving request orchestration and deduplication**, i.e. in both cases developers worry less about optimizing data fetching. 

Here’s another tweet from Dan, which sadly didn’t make it to the top three: “**read data on the server, pass it down by props**”. This means developers would essentially be able to “think in components” also on the server. With React Server Component you can simply await a promise inside a (server) react component instead of fetching from the browser. 

The best part is that you’re not limited to treating your server components as “all knowing parents” responsible for getting all the data children need (which is what route level fetching in Multiple Page Applications is). Instead, you can be as granular as you want. You might choose to place a server component at the bottom of the React tree even if it has client rendered ancestors. Hopefully this illustrates why React developers in the future might worry less about using APIs and instead focus on the best ways to combine components, each of which would handle their own fetching concerns, with the actual fetching benefiting from some optimizations higher up.


#### **Best pitch for Server Side Components: 2st place**
![ ](\uploads\blog-serverReact_post_05_6oyCT94PSinGhUFajfUJ25.png)
*Source: Twitter*

This one is the key to understanding why building server first React components sits well specifically with React. The concept of facilitating the component based UI architecture paradigm both on the frontend and the backend is not limited to React but React’s unidirectional data flow is especially well suited to play well with such a setup. 

React treats the UI primitives like they are just values. You can keep them in variables, pass them around and compose them into larger groupings that behave predictably precisely because data flows through them only one way.

![ ](\uploads\blog-serverReact_post_06_4DCvJN1QEpawIimpDTpJpr.png)
*Source: Twitter*

Subsections of the component tree get selectively rerendered as required in order to reflect changes in data. It is therefore important to control at which level of the virtual dom tree the data changes are detected and reacted to. React developers know this problem as “lifting state up”, i.e. moving a piece of data as high up as necessary (closest common ancestor), but not higher (to avoid unnecessary rerenders). 

Now thanks to React Server Components developers can design their state architecture the same way but they can now decouple the problem of component structure from the challenges of sourcing the data in a streamlined fashion. 

With RSC, what arrives in the browser is a serialized json describing the react tree with the server side components already broken down into base html tags containing the results of any data crunching that happened on the server (it also contains elements acting as placeholders for client side rendering). There is no rerender triggered by the fetched data suddenly arriving somewhere higher up in the tree. In this sense, the server data orchestration serves as the top level of the unidirectional data flow, even if the components themselves are deeply nested in the react tree structure and have client rendered ancestors. Powerful stuff.

#### **Best pitch for Server Side Components: 1st place**
![ ](\uploads\blog-serverReact_post_07_5rVtbB7A2yPrv3agQ2Dp2r.png)
*Source: Twitter*

This pitch idea hits the nail on the head, I think. It’s all about still thinking in components but extending the composability. SRC is an entry point to the future where react components can be published on NPM and have their own data fetching concerns fully met out of the box rather than having to rely on app developers to understand what data is needed. 

This is the benefit that is much more interesting to CEOs than the details of how this is actually achieved. Imagine how much more streamlined the work of large react teams becomes if components can handle their own data in a way that allows you to put them together in more complex groups without footgunning yourself. 

That vision is definitely appealing. So, what are the drawbacks and challenges we might expect should it be realized?

#### **Fullstack React: added complexity vs metaframework lock-in**
The already mentioned emergence of react meta-frameworks, i.e. frameworks built on top of React, is not a problem in itself - on the contrary - next.js, remix and other frameworks have a lot to contribute. 

That said, React team deferring to these frameworks as a way to start an application tells you something about the fact that delivering on the vision outlined above no longer sits solely within the remit of React. The bits frameworks care about now become an integral part of delivering your UI to your users. What follows is that you might have to acknowledge that choosing React as your UI technology will now have potentially further reaching consequences and may come with added complexity. In other words, choosing React is no longer just choosing one of many flavors of V in MVC. 

This sounds like a lot of additional headache, doesn’t it? It doesn’t have to be! The whole point of the shift towards starting with a slightly more complex setup than just a SPA means that **you’re not locking yourself into a SPA** - and that’s a huge benefit as it saves you some serious grief in the future. Adding all the server-y bits to a bloated SPA is a complex endeavor. To avoid it, you may want to start with running RSC at build time (so react server components but – sort of – without a server) and then shift towards using whatever mode makes sense on route by route basis (and yes, there is a Dan Abramov tweet to back this up too). 

Does it mean that you should marry a metaframework? Maybe, and maybe not - either way, it’s now up to you to understand what such a framework does for you, and the answer is no longer simply based on whether you need SEO and hence need SSR. By the way, RSC is not the same as SSR. Server side rendering can be set up to play nicely with React Server Components though, and that’s partially also what metaframeworks do for you. 

One thing to consider is that server rendering runtimes are now a thing. As your UI app no longer lives solely in the browser, hosting becomes potentially more complex than just dropping a SPA bundle on a CDN. UI architecture considerations would now need to extend to deciding what your SRC server rendering environment requirements are. For example, Next.js now offers three different server rendering runtimes (node, node serverless, edge) - each with its own characteristics when it comes to security, latency, scalability and IO access and each with its own tradeoffs (e.g. code ran on the edge cannot exceed a certain size etc.). If you don’t want to be married to Vercel (the hosting company behind Next.js) - you need to roll your own. If you don’t mind tying yourself to a hosting provider, that has consequences too. 

Another thing to consider is that with SRC bundlers play an increasingly important role. Your bundler would now be tasked with generating serializable “module reference” objects, i.e. creating the server side placeholders for client rendered components, and then helping the client stitch the tree back together following the client rendering step. If you bootstrapped your project with a metaframework, this won’t be an issue. If you’ve got your own bundler setup, it might be something to look into. 

Yet another consideration is caching your rendered components (see static vs dynamic rendering in Next.js for an example of that). You might also be curious if your “backend for frontend” can rely on other technologies than javascript (not yet as far as I know, but that may soon change) and so on – there are potentially many more such technical challenges, which fall outside of the scope of this article. We’ll surely discover even more once the technology is mature enough to be production ready. 

What is obvious already, however, is that all of the above potentially impact the way you should source technical talent for react teams. Let’s look at why that is.



#### **What fullstack react means for sourcing React talent**
If the react community does embrace the metaframework first approach, one immediate consequence is that React skills will become less transferable. Familiarity with React via Next is not necessarily going to equate to familiarity with React via Remix - not to mention that we can expect to see meta-metaframeworks, i.e. more domain specific frameworks to be built on top of metaframeworks (e.g. Shopify hydrogen 2.0 is built on top of Remix). Each metaframework offers different abstractions and each is going to be incentivized to differentiate its offering. Competition is always great for end users, but bear in mind skill transferability may suffer. In your hiring you may therefore be well advised to pay more attention to the understanding of the underlying server related concepts, not framework trivia. 

Another consequence is that - metaframework or not - the mental model of react stretched across the network boundary becomes increasingly complex when it comes to debugging, optimization etc. Also, marrying the current client-heavy toolset with SRC may prove challenging. For starters, here is Jack Harrington building a toy Next.js 13 app using redux toolkit both on the client and the server and initializing the client store with values from the server store:

State Management for NextJS 13 Server and Client Components by Jack Herrington

This is to say that spreading React both on the client and the server may yield new challenges which you may want to test for or upskill towards. 

At this stage you may ask: is it worth all the hussle of revamping your HR practices just because one framework came up with a new feature? My answer in this particular case would be yes, if you believe this trend is wider than RSC - and I believe it is. 

Consider for example, that the same trend has been playing out in the C sharp world. .Net developers discovered the benefits of component based composability by going from MVC and razor pages to the Blazor framework, which came in two flavors. Blazor server, offering server rendered UI components, and Blazor Web Assembly, which works pretty much like every other SPA framework but relies on .net instead of javascript, crammed into the browser courtesy of webassembly. 

Now with .net eight on the horizon there is a new flavor of Blazor in town, called Blazor United, which promises to give developers the best of both worlds by allowing them to define which components should render on the server and which should be treated as client components. Sounds familiar? Here’s Jon Hilton explaining the details of how Blazor United came to be, and comparing it to Remix: [https://jonhilton.net/blazor-united/https://jonhilton.net/blazor-united/](https://jonhilton.net/blazor-united/)


This is not to say that server heavy UI frameworks are somehow a historical inevitability. The split between frontend and backend development is a valid one - at least for larger organizations. However, what seems to be more and more evident is that this split doesn’t align with the split between the server and the browser as neatly as we once thought. Instead the fault line seems to be between UI related concerns (spanning both server and frontend) and non UI related concerns. The talent sourcing consequences are pretty obvious if you look at it this way, and they go well beyond React. 

#### **Summary**
It’s still early days for RSC but it seems like it’s time to start looking at the details of what server-first React means for our organisations. 

#### **About the author**
[Jan Bełezina](https://www.linkedin.com/in/jan-belezina-7356055a/)
 is a software engineer and guest blogger for Bitnoise, based in Oxford. He specializes in React, Three.js, Next.js, and TypeScript. As a former product manager and business analyst, he has a wide overview of the development process and strategies.

small_blog-serverReact_cover_high.png

thumbnail_blog-serverReact_cover_high.png

blog-serverReact_cover_high.png

The server-first future of React – guide for CTOs

**AngularJS has no future. You know it, and I know it. There is no longer any support as of 2023, and developers try to stay as far away from it as possible. The problems of companies still using it are piling up.**

So if by any chance you are still using AngularJS, I don't think I need to convince you any further that it has to go. And it has to go now.

But let's dive deeper into the hard truth, explore alternative tech solutions, and see how you can prepare for the switch.

#### **AngularJS vs React - a quick overview**
Before exploring an overview of alternatives and discussing the pros and cons of switching to them, I want to highlight some compelling facts that demonstrate why it is time to make the switch now and, in many cases, why opting to adopt [React](https://react.dev/)
 is a wise decision.

1. Above all, the support for **AngularJS officially ended in January 2022**. Furthermore, it's worth highlighting that Angular versions v2 to v13 are no longer receiving official support.

2. The drop in interest in Angular and the surge in popularity of React among developers is evident in the latest [**Stack Overflow Annual Developer Survey 2023**](https://survey.stackoverflow.co/2023/)
. According to the survey data collected among professional developers, **React garnered a significant 42.87% share** in terms of web frameworks and technologies. In comparison, Angular lagged behind at 19.89%, while AngularJS only accounted for 7.96% of the responses. These statistics demonstrate the shifting preferences and increasing adoption of React among the developer community.

3. React stands out in terms of DX (**Developer Experience**) due to its remarkable attributes, such as user-friendliness, adaptability, quicker rendering through the use of virtual DOM, top-notch performance, and efficient testing capabilities.

4. **React has a thriving community and ecosystem**. While both React and Angular have strong communities, React's community is generally considered more dynamic. Moreover, React's ecosystem is lively, offering developers countless tools, libraries, and resources.

5. Last but not least, **React Native**. If you are also contemplating mobile app development, React might be a preferable choice due to React Native. This framework enables the creation of efficient native mobile apps using JavaScript while also granting access to native features. React Native is a descendant of React, not just in name but also in syntax and approach. For developers acquainted with React, implementing React Native is straightforward.


![ ](\uploads\Blog_AngularJS2React_2_18PLXBAKIQXgPnPyVt0gNw.png)
#### **Leaving AngularJS behind - React and other alternatives**

When you decide to move on, you might think that the simplest solution is to migrate to Angular if you have worked with AngularJS. Overengineering and overthinking the technology can be a detrimental factor when it comes to agility and fast implementations.

However, there is more to consider than meets the eye. **Migration entails a significant effort in terms of technology, budget, team engagement, project management, and more.** So, if you decide to proceed, take a moment to think outside the box and check other technologies.

Having said that, I will present three migration solutions and one temporary solution. I will discuss the advantages and disadvantages of Angular, Vue, React, and even staying with AngularJS (although I do not recommend it).

#### **Pros and cons of migrating to Angular**
Benefits after migrating:

1. **TypeScript integration:** Angular is built with TypeScript as its primary language, which brings static typing, better tooling, and enhanced code reliability. TypeScript allows for simpler refactoring, provides code navigation features, and catches errors during transpile-time, resulting in more robust and maintainable code.

2. **Improved performance**: Angular introduces various optimizations and enhancements in performance compared to AngularJS. It leverages a more efficient change detection mechanism, resulting in faster rendering and better overall application performance.

3. Angular provides a more **structured and component-based architecture**, making it easier to manage and maintain code. It offers improved tooling, TypeScript support, and better IDE integration, boosting developer productivity.


Cons of the migration process:

1. **Learning curve:** Angular and AngularJS have significant disparities in architecture and concepts. Migrating to Angular requires developers to learn new concepts, such as the component-based architecture, dependency injection, and reactive programming with RxJS. This initial learning curve may slow down development initially.

2. **Potential breakage:** AngularJS and Angular have different APIs and approaches, which can lead to possible breaking changes during the migration process. Some AngularJS features might not have direct equivalents in Angular, requiring developers to find alternative solutions or workarounds.

3. **Upgrading dependencies:** Angular often necessitates upgrading dependencies to their latest versions, including TypeScript, RxJS, and other libraries. This can introduce compatibility issues with existing code or third-party libraries that rely on older versions.


#### **Pros and cons of migrating to Vue**
Benefits after migrating:

1. **Improved performance**: Vue is recognized for its lightweight nature and efficient rendering mechanism. Migrating to Vue can result in faster load times and enhanced overall performance compared to AngularJS.

2. **Simplicity and ease of learning:** Vue has a straightforward and more intuitive syntax compared to AngularJS, making it easier for developers to understand and learn. This can result in faster development cycles and less steep learning curves for new team members.

3. **Component-based architecture:** Vue follows a component-based architecture similar to Angular, allowing for better code organization, reusability, and maintainability. Migrating to Vue can enable developers to harness the advantages of component-based development with a more streamlined and flexible approach.


Cons of the migration process:

1. **Compatibility issues:** Migrating from AngularJS to Vue involves rebuilding the existing codebase, which can be time-consuming and challenging. There may be compatibility problems with third-party libraries or custom directives that need to be addressed during the migration process.

2. **Tooling and ecosystem differences:** AngularJS has its own set of tools, libraries, and ecosystem built around it, which may not have direct counterparts in the Vue ecosystem. This can lead to the need for modifications in the development workflow and the adoption of new tools and libraries.

3. **Migration complexity:** Depending on the size and complexity of the existing AngularJS application, the migration process can be complex and require meticulous planning. It may be necessary to incrementally migrate components and features, leading to a mixed codebase during the transition phase.



#### **Pros and cons of migrating to React**
Benefits after migrating

1. **Performance and scalability:** React is renowned for its performance optimizations, such as the virtual DOM, which can lead to faster rendering and improved overall performance compared to AngularJS. React's component-based architecture also promotes scalability, allowing for effective handling of large and complex applications.

2. **Flexibility and modularity:** React provides a high degree of flexibility, allowing developers to choose libraries and tools according to their needs. The component-based nature of React enables enhanced code organization, reusability, and maintainability. React's unidirectional data flow and the use of pure functions for components also promote simplified testing and debugging.

3. **Larger community and ecosystem:** React has a vast and active community, which means a wealth of resources, libraries, and support available. This expansive ecosystem makes it easier to find solutions to common problems, integrate with other tools and frameworks, and stay up to date with best practices.

4. **Improved developer experience:** React has a moderate learning curve, especially for developers already familiar with JavaScript. The declarative nature of React simplifies the development process, and the availability of tools like React Developer Tools enhances productivity and eases debugging.



Cons of the migration process:

1. **Rewriting and time consumption:** Migrating from AngularJS to React typically involves a complete rewrite of the application. This process can be time-consuming and resource-intensive. Additionally, developers who are accustomed to AngularJS will need to learn React and its ecosystem, which may require extra training and adaptation time.

2. **Tooling and ecosystem differences:** AngularJS and React have different tooling and ecosystem support. This means that developers will need to adapt to distinct development workflows, build systems, and libraries specific to React.


And if you really need to stay with AngularJS, you can always rely on the helping hand of a third-party company, like XLTS, which currently plans to provide support for AngularJS through at least 2026. Remember that it is not a perfect solution, but when you have a stable application and no need for growth, it may suffice for a while.

**But let's face it, there is only one business-oriented solution on the table, and it is migration. The sooner, the better.**

I've shown that there are pros and cons to every technology you will use, but most of them sum up to the problem with the learning curve, tools, and ecosystem differences (even in the case of Angular).

The solution can be a hybrid migration, and I know from experience how it works because we did it for our clients with success.

#### **It really works! - A** [**case study**](https://www.bitnoise.pl/clients/circus_street)
 **on how Circus Street switched from AngularJS to React without losing momentum.**
To demonstrate how you can smoothly transition without losing momentum, I present to you a real-life example where we migrated an entire e-learning platform for our client, Circus Street. They are a provider of online training in digital skills, specifically designed for global enterprises.    

**Needs and problems** 

Circus Street approached us for help in maintaining their main web application, which was built on AngularJS. However, the imminent end of support for AngularJS in 2022 posed a problem for Circus Street, as they needed a solution that would allow them to introduce new features quickly without affecting the quality of service for their clients. We identified several pain points in Circus Street's application. The monolithic structure and outdated version of AngularJS made it challenging to implement changes efficiently. Additionally, the interconnectedness of the web and mobile applications meant that fixing one required addressing both simultaneously. The code structure also lacked flexibility, leading to longer implementation times for changes and fixes. 

**Solution and results** 

To address these issues, Bitnoise proposed using React, a technology Circus Street was already familiar with. **They considered two approaches: rewriting the entire application at once or using the Strangler Pattern to migrate gradually.** The latter approach was chosen, allowing Bitnoise to rewrite AngularJS components into React and progressively replace the old code. This process started with smaller components and culminated in replacing the AngularJS core, resulting in a seamlessly functioning final product. 

The achievements of the project included separating the mobile and desktop code for independent management, converting all AngularJS code to React and Redux, writing more flexible and maintainable code, implementing comprehensive tests and documentation, and facilitating onboarding for new developers. 

**As a result of Bitnoise's efforts, Circus Street successfully upgraded their application, meeting the deadline for the end of AngularJS support**.

![ ](\uploads\case_study_linkedin_1o8iIJJTUYcwVCgNaUVCI8.png)
You can find the full case study under the link: [Circus Street](https://www.bitnoise.pl/clients/circus_street)
.

#### **How to plan a switch from AngularJS to React - most important steps and takeaways**
I assume that we are now on the same page regarding the migration to React. I've presented a case study from a successful project and highlighted a pain point our client experienced before switching to React. Let's summarize the general steps necessary for the transition. Please bear in mind that this is just an overview, as a fully technical manual is a topic for another article.

1. **Plan and analyze the migration:** before diving into the migration process, it's crucial to plan and analyze the existing AngularJS application thoroughly. Evaluate the application's structure, components, dependencies, and complexity. Identify any potential challenges and prioritize the components that require migration. This step helps in creating a well-defined roadmap for the migration process.

2. **Understand React fundamentals:** familiarize yourself with React concepts and principles. Understand how React handles component-based architecture, state management, routing, and rendering. This step ensures a smoother transition and helps you make knowledgeable decisions while rewriting AngularJS components in React.

3. **Rewrite AngularJS components in React:** initiate migrating individual components from AngularJS to React. Commence with less complex components and gradually move to more complex ones. Divide larger components into smaller, reusable React components. Utilize React's virtual DOM and JSX syntax to rebuild the functionality and UI of AngularJS components in React.

4. **Migrate data and state management:** AngularJS uses two-way data binding, while React follows a unidirectional data flow. Choose an appropriate state management solution for your React application, such as React's built-in state management (useState) or a more advanced library like Redux or MobX. Migrate the data and state management logic from AngularJS to the chosen React state management solution.

5. **Test and refactor:** thoroughly test the migrated components and functionalities to ensure they work as expected in the React environment. Use unit testing frameworks like Jest or Enzyme to write tests for your React components. This step helps uncover any issues or bugs that might have arisen during the migration process. Revise the code if necessary, applying React best practices and optimizing performance.


#### **Conclusion**
The time to switch from AngularJS to React is now. This decision is driven by several compelling factors, including:

-  AngularJS's official support ended in January 2022.

- React is leading in popularity among web frameworks, according to the Stack Overflow Annual Developer Survey 2023.

- React's benefits, such as improved performance, scalability, flexibility, and a thriving ecosystem, make it an attractive choice for developers and businesses.

- React Native offers a smooth transition for those looking to expand into mobile app development.


Of course, there are drawbacks to migration, including the learning curve and potential breakages. However, these challenges can be overcome with careful planning and gradual migration approaches.

Transitioning from AngularJS to React is not only necessary due to the end of support for AngularJS, but it also offers significant advantages in terms of developer preference, improved productivity, and mobile app development.



small_Blog_artykul_AngularJS2ReactJS_cover_high.png

thumbnail_Blog_artykul_AngularJS2ReactJS_cover_high.png

Blog_artykul_AngularJS2ReactJS_cover_high.png

AngularJS to React: why the time to switch is now?


Storing information, showing it and giving users the ability to interact with it in some way, shape, or form is the core of every application. The quality of the application is often measured, based on the level of interactivity and responsiveness provided.

In React, when talking about storing something, the first thing that comes to mind is a state. However, as the application grows, it’ll have more and more information to store, so it’s important to manage the state in ***a clean*** and ***readable*** way that is not only ***performant*** but also ***scalable***.

#### **50 shades of state**
From opening modal or handling forms to storing user’s information (like email and password), state comes in many shades, thus it is important to divide it into two categories - **server state** and **client state**:

- **server state** - like the name suggests is anything stored on the server (for example user’s email and password).

- **client state** - to put it simply it’s everything else that is not needed to be stored on a server, for example whether modal is opened or closed.  


It goes without saying, but it’s crucial that both states work together and are in sync, for example when a user updates email, which is stored on a server, the client state should react to that change somehow f.e showing a confirmation snackbar.  

**In this blog post I will tackle client state only so It’s not unnecessary bloated and easier to digest.**

#### **Built-in tools for Client State**
React gives us multiple built-in ways of managing an application’s state with the help of hooks.

**useState**



It’s probably the first react hook anyone trying to learn React gets accustomed to. It’s straightforward and easy to use as it gives a possibility to simply retrieve and update some information.

It’s great for storing simple, ***in more professional language we would call them primitive***, values like booleans, strings or number. However it’s still possible to store more complex data structures like arrays or objects, but it’s important to remember that **state in React is immutable**.

When working with just useState, we can find ourselves calling multiple setStates in a single function, for example, clearing form state:



> React is smart and batches multiple sequential setStates into singular re-render, so it will not have performance implications to have sequential setStates functions, but it can get hard to manage.


And for that reason React has another way for managing state:


**useReducer**



More advanced hook that is useful when working with complex state that have values depending on one another, providing a more redux-like implementation.

A good example would be managing the cart state. As we add items to the cart we also need to update the total price of the order. Instead of calling two separate ***setStates*** from ***useState*** we can just dispatch an action to handle both things **at the same time**.

#### **Limitations of useState and useReducer**
Both **useState** and **useReducer** are good for managing state, but their limitations can emerge as the application grows in size. Especially when:

1. components have similar functionalities (e.g., forms, or modals), so with using just useState and useReducer app can become harder to maintain, due to lots of duplicated code,

2. there are instances where state needs to be shared between multiple components that are not necessarily descendant of one another, and with just useState or useReducer and one-directional data flow in React it can lead to a *prop drilling,*


> prop drilling - passing data through nested components, even those that are not dependent on that state.


#### **Custom hooks abstractions**
The first state management that can be introduced in any react app is ***custom hooks***, by extracting common functionalities and then reusing it anywhere in the codebase, for example **useForm**:



> It is a good practice to wrap any function inside a custom hook in useCallback to prevent unwanted re-renders and behaviors.



By extracting common form functions and making the hook generic it’s now re-usable in every component that requires it. Additionally extending the logic by adding more functionalities to a form can be done in only one place - the hook itself.  

What’s important to note is that each component that uses the hook will have a new instance of the state - **state from custom hooks is not shared between components**, to make sure that state is shared we need to use something else.

#### **Let’s give it some more context…**
To prevent *prop drilling* we can use another built-in feature of React - Context API.

It is a powerful tool that allows moving state ***outside*** of components tree and access or update it in any component inside of its provider. Handling dark mode is a perfect use case.



> It is a common pattern to use context together with custom hooks, so that it's not required to import useContext and context itself in every component.


However, on the [react documentation](https://react.dev/learn/passing-data-deeply-with-context#before-you-use-context)
 is stated, that one should be very mindful when choosing to use context. More often it is just better to send props multiple levels down the component tree, as it helps visualize the data flow within the app.

#### **So what are some drawbacks of using Context API?**
- It requires some boilerplate to create a context.      

- Any change to the state within context will trigger re-render of **any** component that is wrapped with provider (so its best to go as deep in the component tree as possible).      

- It can get messy in figuring out which components are wrapped in which contexts when there are many providers in different places within the app.


#### **Third party joins the chat**
There are plenty of additional third-party libraries that can help with managing the state within the app.

**Redux** could be one of the most known example of such library, however it can introduce some unnecessary complexity as it requires a lot of boilerplate code with setting up store, reducers, selectors and actions making most apps **over engineered** (and can only get more complex as middleware like ***redux-thunk*** is added into the mix).

Thankfully, nowadays there are more modernized tools to choose from, that could be a better fit to specific needs.

I wanted to highlight one specific state management library that I have come to know and love in couple of projects I’ve been working on recently:

#### [**Jotai**](https://jotai.org)

> Jotai means "state" in Japanese



A Light-weight atomic state manager that can be used as a replacement for  React’s Context API. It’s simple to implement with little to none  boilerplate required. Simply:




and that’s it. Atom can be accessed by any component with a help of Jotai hooks:



**It also fixes issue with Context API redundant re-renders - just components that are using the atom will rerender when that specific atom updates.**

When using Context sometimes there is a need to have some on mount functionality, and jotai also provides a solution with **onMount** property, that’s similar to React’s built-in useEffect hook:



Jotai also gives developer a full control over atoms read (getting) and write (setting) behaviors by using read / write function:



which allows to create private atoms that can be changed in only specific ways:





Jotai is also compatible with **Server-side rendering**, but it does require additional step of wrapping the app with ***Provider***.

#### **NextJS (app directory)**


You can learn more about Jotai from it’s nicely prepared [documentation](https://jotai.org/)
.



#### **What goes around comes around...**
For most modern applications, where keeping UI and client state in sync with server state is already solved by libraries like ***react-query*** or ***swr***, there is very little state left to manage solely by the client.

Keeping that in mind more often than not, using just the built-in React hooks and Context API with custom hooks will be **good enough** as it makes your client future-proofed by preventing issues with third party packages, and can make your bundle size more lean.

***Still, handling state on a client is a battle like any other, so it’s good to know your options for when you may need them ;).***



small_blog-FightOfTwoWolves_cover_high.png

thumbnail_blog-FightOfTwoWolves_cover_high.png

blog-FightOfTwoWolves_cover_high.png

The fight of two wolves within state

#### **Making the switch - Why consider the change?**
In the dynamic world of web development, staying ahead of the curve is essential to meet the demands of modern user experiences. PHP-based applications with UI generated by template engines like Twig or Blade have long been the backbone of many websites**.** 

**But have you ever wondered about the possibilities of a different approach?**

In a tech industry that constantly evolves, new and more efficient methods emerge regularly. Adopting modern front-end technologies has become imperative to ensure speed, interactivity, and maintainability. One such technology that has revolutionized the way we build user interfaces is [**React.js**](https://react.dev/)
**, a JavaScript library** created by the Facebook team.

This article explores the value of transitioning PHP-based UI templates to React and the benefits it brings to web applications.

#### **Understanding the limitations of PHP-based UI templates**
**Limited interactivity**

When a user visits a website, their browser sends a request to the server. The server then generates a response, which is the HTML that the user sees. PHP-based UI templates follow a request-response model, where the server generates and delivers a complete HTML page in response to each user request. **This design inherently lacks real-time interactivity**, as the user must trigger a new request to the server for any updates or changes to the page. As a result, user experiences can feel sluggish and less engaging, especially for applications that require frequent updates in UI.

**Reduced maintainability and mixed logics** 

Of course to improve that experience a lot of PHP-templates started to support JavaScript language. But this approach provided more flaws and limitations. **With PHP templates like Twig or Blade even supported by JavaScript, rendering logic and HTML markup are often tightly coupled together.** This coupling can lead to redundant code, making it challenging to reuse UI components across different pages or sections of the application. This hinders maintainability, enhancements which often ends with bad developer experiance and increases the chances of introducing errors during updates.

In addition if your application is not powered by widely used PHP frameworks like Symfony or Laravel it probably has mixed logics. With presentation logic mixed with business logic, locating and modifying specific parts of the UI can be time-consuming and error-prone. Which usually ends with slow performance and bad user experience

#### **The benefits of shifting to React**
**Dynamic request-response model**

Modern web applications are usually divided into two parts: the front-end and the back-end. The back-end is where your old PHP application lives, while the front-end is totally separated from the back-end and is responsible for the user interface. The most common way to create a modern UI nowadays is with a Single Page Application (SPA).  

SPAs have gained immense popularity due to their ability to deliver a smooth and interactive user experience. Unlike traditional multi-page applications, where each user action results in a complete page reload, SPAs load once and dynamically update content as users interact with the application. This approach significantly reduces loading times, enhances user engagement, and simplifies the maintenance process.  

**Here are some of the benefits of using SPAs:**	

1. Faster loading times: SPAs only need to load once, which results in faster loading times for users. 	

2. Better user experience: SPAs can provide a better user experience by dynamically updating content as users interact with the application. This makes the application feel more responsive and engaging. 	

3. Simplified maintenance: SPAs are easier to maintain than traditional multi-page applications, as there is no need to update multiple pages when making changes.



**Enhanced User Experience (UX)**


React is one of the most popular frameworks to create SPA. Improved User Experience (UX) is a byproduct of the interactive interface that React facilitates. With a smoother and more responsive UI, you'll experience higher user engagement which can ultimately lead to growing income.

**Leveraging a modern tech stack**

When you switch to React, your new front-end app will have to communicate to your new backend. REST applications are the most common way to create a modern backend now.

Transition to a RESTful API (Application Programming Interface) and a Single Page Application (SPA) can work wonders. REST, based on the principles of Representational State Transfer, provides a set of guidelines for designing networked applications. By creating a RESTful API, developers can expose specific functionalities and data endpoints, decoupling the frontend from the backend logic. This separation of concerns brings modularity and flexibility to the development process, allowing teams to work independently on different parts of the application.

**Expanding your team becomes easier**

With your new tech stack, the shift to React can attract a wider pool of talent. React has become a go-to choice for many front-end developers, so you will find it easier to expand your team with qualified individuals who are well-versed in modern technology.

The popularity of React among developers is clearly reflected in the latest [Stack Overflow Annual Developer Survey for 2023](https://survey.stackoverflow.co/2023/)
. Based on data collected from professional developers, React secured a notable 42.87% share in the realm of web frameworks and technologies.

Adding it to your tech stack means you are embracing contemporary technology. By doing so, you gain value through improved performance, maintainability, and future-proofing your software product.

![ ](\uploads\bitnoise_blog_php_to_react_2_6k5z74x0pZNcY3kZuiJsdZ.png)
#### **The Drawbacks of React Implementation**
**Major changes to your ecosystem**

Switching from PHP to React implies a significant overhaul of your system. As you may have noticed, the new frontend app will require a new backend app as well. It is important to assess the impact of such changes on your existing ecosystem to ensure a smooth transition without jeopardizing ongoing operations.

**Large project to manage**

Revamping your UI to React is undeniably a large-scale project. It requires careful planning and efficient project management skills to ensure its successful execution.

**Time-consuming and pricy**

A switch of this magnitude can be both time-consuming and pricey. It is a considerable investment that should be made after a thorough cost-benefit analysis, taking into account the long-term return on investment.

#### **The Pros and Cons: Is it worth the investment?**
Every major business decision requires careful thought and precise analysis. The shift from PHP-based templates to React is no exception. It presents numerous advantages but also brings its own set of challenges. The ultimate question: is it worth the time and money? We believe yes and we have knowledge and experienced developers to help you make that move and bring modern UI to your applications.

#### **Summary**
In this article, we have discussed the benefits and drawbacks of transitioning from PHP-based UI templates to modern React. We have seen that React is a powerful library that can offer significant improvements in performance, interactivity, maintainability, and developer productivity. However, it is important to carefully consider the cost and effort involved in making the switch before making a decision.

If you are considering migrating from PHP to React, here are some key takeaways:

- React is a popular and well-supported library that can offer significant improvements in performance, interactivity, maintainability, and developer productivity.

- Migrating from PHP to React can be a complex process, but it can be worth it if it results in a better user experience, improved performance, and reduced costs.

- It is important to carefully consider the cost and effort involved in making the switch before making a decision.


Here are some of the specific benefits of migrating to React:

- **Enhanced user experience:** React can provide a smoother and more responsive user experience, which can lead to higher user engagement and ultimately growing income.

- **Leveraging a modern tech stack:** React can help you leverage a modern tech stack, such as RESTful APIs and Single Page Applications (SPAs). This can make your application more modular, flexible, and scalable.

- **Expanding your team becomes easier:** React is a popular library among developers, so you will find it easier to expand your team with qualified individuals who are well-versed in modern technology.


Here are some of the specific drawbacks of migrating to React:

- **Major changes to your ecosystem:** Migrating from PHP to React will require significant changes to your ecosystem. This includes migrating your back-end to a modern library and updating your front-end code to use React.

- **Large project to manage:** Revamping your UI to React is undeniably a large-scale project. It requires careful planning and efficient project management skills to ensure its successful execution.

- **Time-consuming and pricy:** A switch of this magnitude can be both time-consuming and pricey. It is a considerable investment that should be made after a thorough cost-benefit analysis, taking into account the long-term return on investment.


Ultimately, the decision of whether or not to migrate from PHP to React is a complex one that should be made on a case-by-case basis. However, if you are looking for a library that can offer significant improvements in performance, interactivity, maintainability, and developer productivity, then React is a great option to consider.

small_blog-PHP-React.png

thumbnail_blog-PHP-React.png

blog-PHP-React.png

The value of transitioning your 
PHP-based UI templates to modern React

If you have a million-dollar idea, you want to validate it as quickly as possible. Spending time on things that don't add much value can be wasteful, so it's important to be strategic. Component UI libraries can help you create your MVP quickly and efficiently. 

#### Tools tailored to your requirements

There are plenty of solutions in the market that help with that, and each of them will fit different needs. 

Bootstrap has been around for quite a while and is well-known in the web development world. It was created to make it easy to build responsive web apps. It is basically a simple CSS library, but it got integrated into many popular libraries and frameworks like React or Angular. 

Material UI draws its inspiration from Google's innovative design philosophy, "Material Design," which emphasises user experience, depth, and visual consistency. Its main focus is customization, allowing developers to create interfaces tailored to their specific needs. Based on that, you could create your own design system that would fit your needs exactly as you want it.

If you’re looking for more enterprise-level solutions, Ant design might be a better choice. It offers a big collection of components designed to facilitate the development of complex business applications, which include sophisticated interfaces for data tables, forms and charts.

Chakra UI prioritises developer experience through its modular, customizable components. It allows you to define and apply themes, promoting code reusability and ensuring a consistent look and feel across elements. However, it is less known than the predecessors, so the community might be a little smaller.

While established solutions have a track record, their designs may appear dated. If you're aiming for a modern look and feel, Next UI is a compelling choice with its focus on aesthetically pleasing components. Plus, they made sure it runs fast by using Tailwind CSS as the core, which cuts down on the extra classes in the bundle.

Considering the advantages and disadvantages, most of the solutions are similar, and by the end of the day, it could be a matter of personal choice. Let’s dive in and see the use of specific components to assess the developer experience.

#### Compare different components

In the next section, I will compare specific components, showing which features are available by default and which are not. Take into account that most of the things mentioned could be somehow implemented, however, I will focus only on the aspects that are handled by the library.

#### Commonly used component

I think the Button is the most used component from such libraries, so it would be best to start the comparison with it.

![tabelka 1_.png](https://btnw-strapi-prod.dev.btndev.space/uploads/tabelka_1_63332c5fbb.png)

All the component UI libraries support different button variants such as primary, outlined or of different colours and sizes. Managing the state can also be achieved by all of them, however, Bootstrap needs a little more code to be written around the logic of the loading state. Bootstrap also lacks icon support, so if we want to implement that, we have to manage it ourselves. 

#### A more advanced example

I think working in modals can be either pleasant or a nightmare, depending on the specific developer experience the tools provide. Seeing what features different libraries could offer can help us understand what would be easier to use in the long run.

![tabelka 2_.png](https://btnw-strapi-prod.dev.btndev.space/uploads/tabelka_2_1fa58e692d.png)

Compared to Button, here we can actually see some significant differences between the libraries. Ant Design simplifies the most common use case for models, which are confirmed dialogues. It provides an additional confirm function, which takes only texts and callbacks, allowing us to trigger it anytime we need it without focusing on defining content each time. This library also handles async logic, so calling APIs and showing its effect could also be simplified. Another difficult case would be modal nesting, which is supported by Material UI and Ant Design. This could facilitate handling of some complex business flow. Material UI also lets you drag modals around. It's a handy feature, but personally, I don’t see much use in business contexts.

#### What to choose?

With so many libraries on the market, choosing the one that works best for you can be challenging. If your design is simple, it is probably a matter of personal preference. With more complex applications, it would be good to assess if there are any specific harder use cases that some of the libraries might support better than others.

Implementing a design system in React

Michał

How to make your code better with Prettier?

Łukasz

The server-first future of React – guide for CTOs

Jan

AngularJS to React: why the time to switch is now?

Łukasz

The fight of two wolves within state

Michał

The value of transitioning your PHP-based UI templates to modern React

Krzysztof

Decoding React UI: Unveiling the Best Component Libraries in a Head-to-Head Showdown!

Wioletta

Boom! How we built a pixel-perfect frontend for a SuperSonic company

Grzegorz

PozTechTalks #01: React

Magdalena

GET IN TOUCH