Reviewing Our Frontend Stack Based On State Of JS 2023

What do we need to adapt and change?

One of the most impactful decisions you will make when creating a new application is the tech stack on which the solution will be based. I remember a time when this was a decision just between a handful of ways to do this. These days, you need to read yearly reports to get an idea of what is in and what is out.

I have been making decisions about tech stacks for about 15 years, and I made mistakes in the past. So far, I can say it has become stable, and for several years, we can focus on what matters: Creating value.

To keep it like that, we need to stay informed, be critical, and be open-minded at the same time.

Find the truth between hypes, trends, and solid choices.

First of all, what is a solid choice? When planning a tech stack, we aim to create a long-term basis for our application. Something that will be current in years to come.

The following qualities (NFRs) are essential to determine:

• Ecosystem richness

• Developer availability

• Community interest

• Continuity

• Substitutability

For this article, I would like to focus on these, which are very important in my experience, but of course, there are more.

The danger with hyped frameworks and languages is that we quickly get into a gambling situation; we simply don’t know if the chosen tech stack will still meet the NFRs. On the other hand, hyped frameworks often promise to become the next big thing, like React was.

The Aspect Of Current Trends

We will use similar aspects since we align this article to the State of JS 2023 report¹. I like them and have used them for years to determine the tech strategy. It’s important to understand that trends can only be viewed in hindsight. To understand the development, we must be up-to-date with available information in media, social media, or engineering blogs.

Usage

Usage refers to how extensively and frequently a technology is utilized in real-world projects. It indicates the technology's practical application and popularity among developers and organizations.

Examples: Adoption by developers and teams and industry penetration.

Interest

Technology and developer tools reflect the enthusiasm and curiosity of developers and organizations toward a particular technology. It indicates a growing desire to learn about, experiment with, and potentially adopt the technology.

Examples: Search trends, forum discussion, or conference topics.

Awareness

It refers to how well-known and understood a technology is within the developer community. High awareness means that many developers are familiar with the technology, understand its use cases, and recognize its benefits and limitations.

Examples: Social Media coverage, documentation, tutorials, and educational material.

Retention

In the context of technology and developer tools, it refers to the ability of a technology or tool to keep its users engaged and satisfied over time. High retention indicates that developers are not only adopting the technology but continuing to use it consistently.

Examples: Developer surveys, version adoption, and community engagement.

Positivity

Lastly, positivity refers to developers' overall sentiment and satisfaction with a particular technology. It reflects how favorably developers perceive and enjoy using the technology.

Examples: Reviews and ratings, case studies and testimonials, and Issue resolution.

Chapter 1: Explaining the way of thinking:
Awareness vs. Usage

This chapter is not directly related to our tech stack, but it will give you an idea of how we reviewed the State of JS 2023 report. We had questions about whether we should look into the trend of going back to vanilla and web components instead of heavy React. This is why I want to talk about Google Lit.

Looking closer into Google’s Lit.

In the Frontend Framework Section² of the report, we see clear evidence that Google’s Lit³ web component framework is firmly on the rise in awareness. I know from experience that many posts on LinkedIn and other platforms talk about Lit being a tremendous new vanilla way of developing component-based apps. So, awareness is clearly increasing:

🟢 Additionally, positivity is growing, followed by interest. If this is already hyping you up, be aware that something hidden here concerns me on a higher level;
The stagnating adoption:

Lit is clearly stagnating when it comes to usage in this report. We talk now about our more significant period of 4 years. I can say the same about real-world experience; I don’t see Lit being adopted in my circles. Both might not represent what’s happening, but they gave me an essential first idea about the trend.

🔴 A third aspect is exciting, and I would like to discuss it:
The significant retention drop.

At first glance, lit drops here a lot, but if we take a closer look, the entire JS framework world seems to have a downward trend in retention. I explain this to myself with the overall adoption fatigue and complexity we face today.

I would be careful since Lit doesn't seem to fly as a framework for the overall economy numbers and adoption rate. There is a significant chance that Lit will simply be pushed off the major ecosystems like React, Vue, or Svelte.

Even if a framework is interesting, the adoption rate is the most important one to follow for me. It’s simply about how many teams have started to build up it, which will result in an active ecosystem and will add to the NFRs mentioned before.

---

Chapter 2: Reviewing Cloudbars Frontend Tech Stack

“I am considering building the next standalone Cloudbar iteration in Vite as a project to test the hypothesis that Vite is the better substitute for 2025.”

Our Current Tech Stack With Cloudbar

For context: We build a customizable multi-tenant SaaS solution, which we use for multiple projects. With cloudbar, we migrate step-by-step existing legacy solutions in the modern stack, as well as greenfield solutions, where we use cloudbar as an engine.

This article primarily covers the front part. The following stack we have used for several years in production now in applications we have written before cloudbar. So, it’s a refined and stable version.

Thoughts about React

The stack is mainly based on React, which is, at the same time, the most immovable thing in the stack. So React does very bad on the NFR Substitutability. This isn’t because of React itself; it’s due to choosing a paradigm (ui = f(state)) over implementing a vanilla HTML stack. The same would be true with Vue.js or Svelte.

Since Substitutability isn’t great with React, there must be something that outweighs the negative aspect: the Ecosystem richness and adoption. Those were years ago initially for the same reasons and still stand today. This leads me to conclude that it's still viable after years of using React; there is no sign of a change in this report.

I have to admit, occasionally, I am interested in the Svelte and Vue realm, but especially on an application scale, those don’t perform as well as React. Hooks and the paradigm are simply too advantageous for us as a company.

React vs. Vanilla Hype

Zeitgeist has changed, and the Ecosystem matters. I ❤️ Vanilla, but I have a Family to feed and other obligations who trust my decisions, So I cannot move cloudbar into Vanilla.

There is a new push towards vanilla web technologies going on. And I understand the reasons behind it. I have been using vanilla tech for decades, and we are, as a company, still in the legacy area today.

The following reasons don’t let me go back:

• The React paradigm ui=f(state) It is clear and powerful. It’s easier to onboard new engineers without explaining the general idea behind the code architecture. That’s a huge factor and a totally different story with vanilla tech. There are frameworks like the mentioned Lit, but being reduced to web components and building complex scaling apps with those isn’t a viable option in 2024. Please note that I am interested in this topic because I love the idea of returning to my roots and having it simpler again. Simply put, it wouldn’t be more straightforward 2024 with what we do.

• NFR Developer availability is near perfect in React; vanilla, on the other hand, is the wild west. A high demand for seniors who can work with lower-level web tech and a considerable effort to align them. It’s totally violating the Average Developer Approach I advocate. I spend many years removing seniority and myself as a dependency for regular tasks and debugging. Developing vanilla is simply more complicated to align and do right. And no, it’s not helping to blame younger devs for not being able to work like that. Zeitgeist has changed, and the Ecosystem matters. I ❤️ Vanilla, but I have a Family and other obligations who trust my decisions, So I cannot move cloudbar into Vanilla.

Thoughts About Meta Framework NextJS

NextJS, on the other hand, is substitutable (NFR) when implemented correctly with React. So it’s worth taking a look into the current interest and positivity. Both are decreasing, but the positivity, in particular, tells me there is some kind of fatigue.

Three significant things came to my mind, one of which was polarizing the NextJS community.

• Turbopack

• App Router

• Serverside Components / SSR

Turbopack is simply not working yet from any real-world apps, including ours. I don’t even bother taking a deeper look into it. It doesn’t add to the trust in NextJS when implementing a half-backed solution, even when it’s called “experimental.” We are here in the production space. A bit more responsibility, please.

App Router was the substitution for the Page Router and was explicitly implemented to support SSR better. That was a fundamental change, and it was more of a hassle, especially for pure static web apps that weren’t following the SSR paradigm. The same applies atm to cloudbar since we haven’t used SSR. We preferred a standalone PWA-ready app, which would not need a server, to be more versatile.

Concern: We don’t follow the main idea of NextJS anymore.

NextJS is working for us, yet we no longer use all the features or don’t follow their main idea. Which is a concern and might require a reaction. I am very interested in Vite since it’s less opinionated, and it could tailor the application to our specific needs better than NextJS right now.

Regarding Meta Frameworks, we have no alternative to NextJS, as React is still set as the core around the front end.

Nevertheless, the usage of NextJS is impressive, and the Ecosystem is robust. We can meet all our NFRs quickly with NextJS, and since we work in a way that NextJS is a component we use, we can exchange it sooner or later.

Would NextJS be a good choice when starting a new App in 2024?

• When you want to use React + SSR, then definitely YES.

• In the case of Cloudbar, we might look into testing Vite in parallel in a real-world environment. We often start new apps in a mono-repo for specific needs. I am considering building the next standalone Cloudbar iteration in Vite as a project to test the hypothesis that Vite is the better substitute for 2025.

Migration time: I estimate the migration time of NextJS to Vite to be between 1–2 weeks for existing apps. The main challenge would be a new routine. Since we use the Ports & Adapter pattern (Hexagonal), it’s pretty easy to substitute here. This effort and timeframe are acceptable.

Navigating the Crossroads of Mobile And Web Development

Conclusion

After reviewing the State of JS with my colleagues, I concluded that urgent action is not needed. Since we build upon existing frameworks and libraries, attention is always going on if something worsens while we use it. That is obviously the downside of using frameworks.

I am happy and glad that React is that strong, and with React 19, we also see new innovations.

We have moved from Recoil to Zustand regarding state management since we discovered that Recoil is dead. No big deal; it was easy to substitute.

NextJS is an actual concern we have. Is it the right tool for the next three years? There is no pressure to change right now, but we will create the following frontend in Vite to compare ourselves in production.

Tailwind turned out to be a great decision. It’s not directly related to the State of JS 2023, but I also wanted to mention it here.

To Tailwind Or Not To Tailwind

Cypress vs. Playwright is a topic for another article. We are using Cypress happily but see several advantages in using Playwright. Let me know if you are interested in that process and determining the best solution.

About the vanilla 🍦 trend, I have to say I love the idea, but I simply cannot imagine how this shall work in scaled production. Web standards are more specifications as real “how-to” definitions. More importantly, Web Standards are not necessarily industry standards for building apps. You see that clearly in the report. The decision-making process is based on building a substantial outcome and being future-proof.

While I'm a vanilla user, I can't make a pure-hearted decision in that direction. Vanilla has never matured as an ecosystem. However, I am delighted to follow the progress and remain open-minded; let's see what the next few years bring.

Survey about this snackableCTO publication

Writing engaging articles and creating interesting videos is way more manageable when you receive feedback from the readers. Would you help me understand better?

Best,
Adrian

1. https://2023.stateofjs.com/

2. https://share.stateofjs.com/share/prerendered?localeId=en-US&surveyId=state_of_js&editionId=js2023&blockId=front_end_frameworks_ratios&params=&sectionId=libraries&subSectionId=front_end_frameworks

3. https://lit.dev/