small_avatar_AdrianR3.png

thumbnail_avatar_AdrianR3.png

avatar_AdrianR3.png

Adrian

small_avatar_Grzegorz.png

thumbnail_avatar_Grzegorz.png

avatar_Grzegorz.png

Grzegorz

GET IN TOUCH

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

In the third episode of our videopodcast, which we create together with Apptension, STX Next and Krzysztof Kempiński, we talk about:

- browsers API,

- PWA states,

- what's new in recent updates,

- what will happen to PWA when Apple and Mozilla change their policy,

- why web applications are not able to replace native applications? 


**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:**

- 39 years on the market

- +496 employees

- + 70 projects per year




PozTechTalks odc. 3 - Nowości na frontendzie

small_Blog_artykul_PozTechTalks_03.jpg

thumbnail_Blog_artykul_PozTechTalks_03.jpg

Blog_artykul_PozTechTalks_03.jpg

PozTechTalks #03: News on the frontend 

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

In the fourth episode of the #PozTechTalks videopodcast, we talk about the recruitment process at Bitnoise, Apptension and STX Next. What challenges are we facing? What are we doing to grow without losing the organizational culture? Who is the perfect candidate?

**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:**

- 39 years on the market

- +496 employees

- + 70 projects per year




PozTechTalks odc. 4 - Jak prowadzimy rekrutacje na stanowiska frontendowe?

small_Blog_artykul_PozTechTalks_04.jpg

thumbnail_Blog_artykul_PozTechTalks_04.jpg

Blog_artykul_PozTechTalks_04.jpg

PozTechTalks #04: How we recruit for frontend positions

During my career, I worked with many React.js teams and was involved in some way in dozens of projects. Over the years I feel I witnessed enough to say with a degree of certainty what is needed to build a well-functioning, technically precise, and efficient team.

Unsurprisingly, we follow many of those principles and practices at Bitnoise. While you can freely adapt some of them, a few come from past projects and attitudes which is difficult to emulate.

In any case, I hope the below summary will be an inspiration.

So what makes React.js teams truly special?

#### Experience
At Bitnoise, We’ve been part of the React.js journey since its beginning. When it was released in 2013, we already had years of experience in software development. Before the advent of this library, we worked with various technologies where we struggled trying to achieve user-friendly and efficient applications. However, we’re always looking for new technologies to help expedite our work and provide top-notch solutions using the best possible tools.

Over the past decade or so, we’ve watched React.js grow and evolve. Unfortunately, it has become bloated with multiple offshoot libraries making it rather clumsy to use. Consequently, a few challenger frameworks have emerged, including Vue.js.

Lately, we’ve been contented to see that React.js has become leaner, more efficient, and developer-friendly. We can thank the community and amazing frameworks such as Next.js and Remix.js for helping facilitate this change.

As for our role, it’s safe to say that after delivering dozens of software projects, building multiple frontend and full-stack teams, and speaking to hundreds of developers over the past decade, we know React.js inside-out. This technology bears few surprises to us.

Without this experience, we would not be able to build such good teams, and I doubt others would.

![ ](\uploads\Blog_artykul_PiotrB_React.js_blog01_1l87xFkyuQoNZiiA1pNBe0.jpg)
#### True engineering on the frontend
Typically, you might reserve the term “software engineer” for backend developers. And yet, this term fits front-end developers perfectly. It is not about the part of the application they work on or the technology they specialize in. Things like a degree in Computer Science or some other STEM subject are a great background for a great frontend engineer.

That’s why we tend to hire React.js developers with solid, relevant academic backgrounds. Furthermore, we have several backend and full-stack developers on our [team](https://www.bitnoise.pl/team)
. Node.js, Python, .NET, and PHP are just a few of the tools these developers work with. Whenever we work on a front-end project, our developers are always ready for consultation or ad-hoc work.

#### Pixel-perfect mentality
Being capable of expressing every imaginable design through code should be within reach of any good frontend team. To transform [clients](https://www.bitnoise.pl/clients)
’ blueprints into a reality, expert UX/UI designers should work hand in hand with developers. As a client, you can work with these designers one-on-one as they service your project. Otherwise, they should be available for consultations if you provide us with designs from an external agency.

In our case, part of our commitment to perfection comes in the form of our use of state-of-the-art tools for design and collaboration.

- **Figma** is a powerful cloud-based design collaboration tool. As such, it allows designers, product managers, owners, and developers to communicate and collaborate simultaneously. 

- **Storybook** is a workshop where developers can build frontend components and pages individually. This is useful because it enables us to demonstrate and check the component pieces of an application without needing to have the entire view or page ready at once. 

- **QA engineers** test all of the apps we build. At the bare minimum, we run our products through automated testing to ensure that the UX is excellent from day one. 


![ ](\uploads\Blog_artykul_PiotrB_React.js_blog02_1H7vOvuCMd7jNlJjqcps8H.jpg)
#### Bitbucket, Eslint, Next.js and Remix to complement React.js
Cutting edge projects usually take advantage of modern tools to complement React.js and streamline frontend work. As a result, high-quality software is created faster. Here are a few of the tools you might use:

- **Bitbucket/Vercel/Fly.io** for Continuous Development and Continuous Delivery (CI/CD). This toolkit helps us avoid long builds and unnecessarily complex configuration work. I.e., it relieves us of the typical mess and stress that comes with tedious development and QA processes. Furthermore, we like this combo because it provides collaboration tools alongside instant previews – thus leading to rapid iteration.  

- **Eslint/Prettier** for code quality. Linting tools analyze our code and look for errors within it. Since React.js does not have built-in compilers to check the validity and quality of our code, Eslint and Prettier are essential to our development process.   

- **Next.js** and **Remix** for a fast, slick UI. Using these two frameworks, we can optimize interactions even with the most intricate designs. They also help improve the developer experience while we’re coding thus making our jobs easier.  

- **React-Query, Redux-Toolkit, and styled-components** as libraries of our choice.


#### TypeScript
By using TypeScript on top of raw JavaScript, code becomes a lot more consistent. Of course, JavaScript is a scripted language, however, it does not use compilers. Therefore, it’s easy for developers to make errors while coding with it. TypeScript fixes this and makes code more maintainable in the process. Plus, it keeps code up to date with browsers as they change their standards.

Here are some of the many concrete benefits of using TypesScript:

- Increasing team performance

- Easier code management

- Early spotted bugs Increasing code readability

- Easily readable and understandable components


#### SEO mindset
Regrettably, raw React causes some issues with search engine optimization. Sometimes, search engine algorithms will shun pages built on React - especially if they’re a single-page application. We resolve this problem with Next.js. Since Next.js permits rendering React applications server-side, the SEO issue vanishes.

#### Community and knowledge sharing
Best teams are not the ones who become isolated from the rest of the world. Learning, teaching, talking to others, inspiring them, and helping others in the software community brings in a lot of new energy and motivation to developers.

In our case - the commitment to education is everlasting. We’re constantly investing in professional development and growth at every level. Here are some examples of our philosophy in action that may help your teams grow too:

- **Internal training**, which is directed and delivered by our senior developers or an external specialist.

- **Bitnoise Meet** is a learning initiative we began to encourage education and research in our field. In doing so, we invite professionals from other companies to learn alongside us.

- **PozTechTalks** is a series of podcasts and videocasts that we coordinate with other local software companies in Poznań. During these sessions, we discuss advanced computing concepts and challenge each other on our perspectives.

- **Land on Moon** is a meetup initiative where CEOs, founders, and product owners share their inside stories from the software development industry.




Blog_artykul_PiotrB_React.js_blog03.jpg

Blog_artykul_PiotrB_React.js_blog04.jpg

Blog_artykul_PiotrB_React.js_blog05.jpg

Bitnoise_events

I hope those hints will help your team become better and happier. If you’d like to work with me or my colleagues check out some of the services we offer and do not hesitate to reach out to us.

- [React.js teams](https://www.bitnoise.pl/services/remote-react-js-teams-next-js-typescript)
 

- [CTO as a Service](https://www.bitnoise.pl/services/cto-as-a-service)
 

- [Process consulting](https://www.bitnoise.pl/services/software-development-process-consulting)





small_Blog_artykul_PiotrB_React.js_blog_cover_high.png

thumbnail_Blog_artykul_PiotrB_React.js_blog_cover_high.png

Blog_artykul_PiotrB_React.js_blog_cover_high.png

What do best React.js teams have in common?

Adam Misiorny is a Frontend Engineer and Tech Lead at Bitnoise. Since Adam is one of the most experienced software developers on our team, we thought he would be the perfect person to offer insight into how our different developers cooperate during their work.

#### You are a leader, but what exactly is your role in your current project?
At the moment, I’m a Frontend Principal Engineer in a long-term project with JOIN. This means I have the most detailed knowledge of the project and the associated systems. As a result, I’m the one who makes decisions regarding development directions and front-end architecture. It’s a big responsibility. Sometimes, I work on developing the platform itself, but mostly, I’m in a leadership role.

From the perspective of the front-end developers working alongside me, my task is to accelerate product development and render it as efficient as possible. Since I am tasked with ensuring efficiency, I also get in the trenches and help solve complex problems should the situation require it. I’m always of use to other developers.

#### As a Frontend Principal Engineer, do you take part in onboarding new developers at Bitnoise?
Indeed, I often introduce new developers to the project. I take an active role so that each developer can get started working on our products quickly and eliminate onboarding uptake time.

Part of this onboarding task is to acquaint developers with our application architecture and coding standards. This helps light the path forward for quality work to get done. Under my watch, developers familiarize themselves with the common processes we use with each project. These range from pull requests to production deployment.

#### And how do you work with new developers in the project?
I assign each of my junior and middle-tier developers a senior “coding buddy” who assists them with their daily tasks if necessary. As the Principal, I supervise the developers at the review stage with an emphasis on the initial stages to ensure that we set the right tone. Should any of my developers have an inquiry, I am quick to answer them and assuage their doubts.

My role as a consultant is one of the most critical parts of my job. I need to give every developer context as to why we approach each problem a certain way. Less experienced developers soon absorb our general programming ethos at Bitnoise as a result. Understanding is the key to growth.

![ ](\uploads\Blog_artykul_Adam_React.js_02_BZ72URItqw8KOX2g07eZS.jpg)
#### What surprises you about working with less experienced developers? What attitude do you expect from juniors and mids?
While I am usually busy shepherding young developers, it’s not uncommon for me to learn a thing or two from them myself. My experience is a major asset, but that can sometimes mean that my programming approach is rather fixed. I benefit quite a bit when I receive fresh perspectives from young computer science graduates. Our work is enriched when I can look at an issue from a different angle.

Above all, I prize developers who have a passion for learning. Anyone who hungers for knowledge can be taught anything, making them more adaptable as programmers. It’s no use trying to force-feed solutions to a disinterested developer. You can lead a horse to water, but you can’t make it drink.

#### What keeps you in Bitnoise for so many years? If I'm not mistaken, this year we'll be celebrating your 10th anniversary at Bitnoise!
It’s a fantastic atmosphere. Isn’t it? After 9 years of working here, I still haven’t tired of my role. And I’ve grown along with it. Even as Bitnoise has evolved and grown, the team spirit has never changed.

When I was a young programmer, I worked on several projects with diverse topics. Consequently, my breadth of programming knowledge skyrocketed, and today I am happy to say that I have experience that ranges the entire spectrum of software development.  Once Bitnoise assigned me as the leader of a long-term project, I appreciated the new stability. It felt as though I had been preparing for years for this role given my work in so many different fields. After 4 years of working with JOIN, I still haven’t grown bored of the project – it keeps me on my toes as I learn new ways to solve the problems we encounter.

If you’re looking to work for a stable company where you can grow your programming skills, I highly recommend working at Bitnoise. The atmosphere is, as I said, top-notch. Personal development is a priority for all of us.



small_Blog_artykul_Adam_React.js_cover_high.png

thumbnail_Blog_artykul_Adam_React.js_cover_high.png

Blog_artykul_Adam_React.js_cover_high.png

How do mid and senior React.js developers cooperate at Bitnoise?

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