₦airaland Forum

This guy's blog is wrong on Kubernetes, as this should the determined by the number of different operating systems the application will be deployed to which will then require containerization and not by the number of developers in the team.

From a blog post not mine: A little over a year ago, a friend of mine hired an agency to build a web application for his business. The application is basically a simple online platform for medical appointments and consultations via video calls using Twilio. Since my friend doesn’t have that much technical knowledge, he asked me to help him validate what the agency was proposing. When I read the proposal, I was shocked. Not only because of the value they were asking but even more so due to the technological choices. It was clear to me right away that they were the typical agency where no one knew anything other than Javascript and MongoDB (thanks, Freecodecamp! 😠) - in other words, they know very little about proper software engineering.

They mentioned React, Strapi, MongoDB and GraphQL as the foundational technologies for the application. This made absolutely no sense:

Strapi is a framework to build CMS, not a framework or library to build a full-fledged web application.
MongoDB is a document store but this type of application will obviously be based on relational data and thus, it needs a relational database.
GraphQL is meant for scenarios where you have a lot of scattered data and you need to easily be able to fetch random pieces of data from random places.
React might be a good fit for large teams building very large and very complex frontends but this is a fairly simple application and the agency building it is very small. [Would suggest jQuery still for any size project]

In summary, none of the tools they chose were meant to solve the problem at hand, which was building a very specific and very well-defined type of web application. Sure, any of those tools could be used to build the application, just as you can also use a spoon to cut your potatoes and a fork to eat your soup - but does it make sense? Just because you can doesn’t mean you should.

All of those choices added unnecessary complexity, which meant unnecessary time spent building the application, unnecessary electricity spent and the accompanying carbon footprint, unnecessary money spent by my friend, and ultimately even unnecessary frustration for the developers who are working on it. Yes, “working”, not “worked”, because they still haven’t finished it and are way beyond their original estimation of three to four months.

I’m not sure exactly how we got here but I think it’s a combination of at least three things:

The “anyone can code” culture, which led to too many pseudo-programmers contributing negatively to the ecosystems.
Marketing folks pushing buzzwords to everyone’s mind.
Script kiddies wanting to use the cool tools from the big guys because they all want to be the next Zuckerberg, without understanding the problems these tools were designed to solve.

The vast majority of companies are small. Your company is most likely a small company. What huge companies like Google and Facebook do does not apply to you. Not only does it not apply, trying to replicate what they do on your smaller company is actually detrimental. You do not have the same problems they do, and certainly not at the same scale. And even if you did, you don’t have the amount of money or people to absorb the complexity of the systems and tools they use. It’s incredibly counter-productive to adopt, for example, micro-services and Kubernetes in a company that has 6 or 7 engineers. Such a company does not have the type of problem these tools solve, nor do they have the capacity to absorb the complexity that comes with said tools. And yet, this is exactly what many small companies do.

Returning to my friend’s project: over a year later, what started as a simple medical appointments platform has become a cautionary tale of modern software development gone wrong. The unnecessary complexity introduced by poor technological choices has led to delays, increased costs, and frustrated developers - exactly the problems I’ve outlined above. Through this series of posts, I hope to show that there’s a better way: one that focuses on choosing the right tools for the job, embracing simplicity where possible, and remembering that our goal is to solve real problems, not to chase the latest trends. Perhaps by examining these issues one at a time, we can start shifting our industry back towards more sensible, maintainable, and enjoyable software engineering.

https://www.borfast.com/blog/2023/06/19/software-engineering-is-broken/

It's the issue we are facing.

One project I'm working on here and the so called project manager created 3 different repos because the figma has 3 different dashboards. I was totally against it and they set up an urgent meeting to discuss that.

Can you imagine me trying to convince tech guys that that was a horrible decision. Such a waste of time and a guy who claim he is also a backend developer supported the funny idea, because he is a developer too.

Their reasons are: scalability and its how things are done there.

I be wan ask the guy to define scalability. I just had to calmy explain why it's a horrible idea because there's no point being rude.

If you are learning this tech thing on your own, please go out and understudy seasoned professionals and if you are good please be loud.

3 different repos because the figma has 3 different dashboards: Depends on if the dashboards are to be used by 3 different departments and the 3 have their own separate databases.

MindHacker9009:
3 different repos because the figma has 3 different dashboards: Depends on if the dashboards are to be used by 3 different departments and the 3 have their own separate databases.

Trust me, even if they are used by a million departments, all you need is a singular repo. You also don't need 3 different databases.

JUST ONE!


ONE!!!!


If hypothetically, the project is now having 10s to 100s of million of data entries per day, then you would have to replan the application's structure but by then the project is probably a big success, in the league of Facebook, Instagram, ticktock and co and the owner is at least a millionaire in USD.

You see say you sef don dey fail am , because you don't actually practice. I am assuming.

Theoretical knowledge can only take you so far, that's why non-practionals should be humble when discussing with professionals.

Just pulling your legs. I don't want fight abeg.

Having 3 different repos is a good software engineering architectural design, this is why:

1. If one department wants a change or a new feature to their dashboard or any other part of their own project, this can be done and deployed with out having to stop the other departments when deploying to the production environment.

2. Different programming teams can work separately on their own project.

3. Access Control & Security: If each department's data and codebase need strict access control, separate repos make it easier to enforce.

4. Department-Specific Customization – If each department has significantly different workflows, business logic or UI requirements, separate repositories allow tailored development.

This type of architecture is called SOA or Microservices which are used for large enterprise applications.

So you can see now that na you sef don fail am and now wants to break a good software engineering architecture.

Nairaland is like a boxing ring, and once you throw the first punch, you don start the fight, so prepare for a return punch and na knockout remain

Karleb:
Trust me, even if they are used by a million departments, all you need is a singular repo. You also don't need 3 different databases.

JUST ONE!


ONE!!!!


If hypothetically, the project is now having 10s to 100s of million of data entries per day, then you would have to replan the application's structure but by then the project is probably a big success, in the league of Facebook, Instagram, ticktock and co and the owner is at least a millionaire in USD.

You see say you sef don dey fail am , because you don't actually practice. I am assuming.

Theoretical knowledge can only take you so far, that's why non-practionals should be humble when discussing with professionals.

Just pulling your legs. I don't want fight abeg.

MindHacker9009:
Having 3 different repos is a good software engineering architectural design, this is why:

1. If one department wants a change or a new feature to their dashboard or any other part of their own project, this can be done and deployed with out having to stop the other departments when deploying to the production environment.

2. Different programming teams can work separately on their own project.

3. Access Control & Security: If each department's data and codebase need strict access control, separate repos make it easier to enforce.

4. Department-Specific Customization – If each department has significantly different workflows, business logic or UI requirements, separate repositories allow tailored development.

This type of architecture is called SOA or Microservices which are used for large enterprise applications.

So you can see now that na you sef don fail am and now wants to break a good software engineering architecture.

Nairaland is like a boxing ring, and once you throw the first punch, you don start the fight, so prepare for a return punch and na knockout remain

All these things you listed are no enough reasons to split a project into multiple repos because it has more than one dashboard.

Talking of microservices, if you are familiar with the tech community on Twitter, it's a pattern that has now been ditched for monolithic because is 'premature optimization' for most projects.

The reason why people use microservices is to allow developers of different language work on a project.

You are suggesting the exact thing you condemn in your write up. The fact that you can eat eba with fork doesn't mean you should.

Keep it simple stupid and don't repeat yourself.

The project requirements will determine whether there is a need for 3 repos. For complex projects used buy three different departments, it's better to have 3 repos. When starting a new project, designing a good architecture is important and this will determine what pattern is good for the application, just like building a house, the architect comes up with the best design based on the requirements they are given for the building.

You are the one going against the writeup as you have not considered the requirements from the stakeholders but you just want to start coding away. This is what the writeup is against, like using React, MongoDB and GraphQL for all projects just because that's all a coder knows, without first doing some analysis to determine which tools are best for the job.

Keep it simple stupid and don't repeat yourself: Can mean to use Microservices if that will make it simple or can also mean to use a monolithic approach if that will make it simple.

The tech community on Twitter, should not be the ones to determine if a system should follow Microservices or a monolithic system. This will depend on the requirements gathered during the initial process.

Karleb:
All these things you listed are no enough reasons to split a project into multiple repos because it has more than one dashboard.

Talking of microservices, if you are familiar with the tech community on Twitter, it's a pattern that has now been ditched for monolithic because is 'premature optimization' for most projects.

The reason why people use microservices is to allow developers of different language work on a project.

You are suggesting the exact thing you condemn in your write up. The fact that you can eat eba with fork doesn't mean you should.

Keep it simple stupid and don't repeat yourself.

MindHacker9009:
From a blog post: A little over a year ago, a friend of mine hired an agency to build a web application for his business. The application is basically a simple online platform for medical appointments and consultations via video calls using Twilio. Since my friend doesn’t have that much technical knowledge, he asked me to help him validate what the agency was proposing. When I read the proposal, I was shocked. Not only because of the value they were asking but even more so due to the technological choices. It was clear to me right away that they were the typical agency where no one knew anything other than Javascript and MongoDB (thanks, Freecodecamp! 😠) - in other words, they know very little about proper software engineering.

They mentioned React, Strapi, MongoDB and GraphQL as the foundational technologies for the application. This made absolutely no sense:

Strapi is a framework to build CMS, not a framework or library to build a full-fledged web application.
MongoDB is a document store but this type of application will obviously be based on relational data and thus, it needs a relational database.
GraphQL is meant for scenarios where you have a lot of scattered data and you need to easily be able to fetch random pieces of data from random places.
React might be a good fit for large teams building very large and very complex frontends but this is a fairly simple application and the agency building it is very small. [Would suggest jQuery still for any size project]

In summary, none of the tools they chose were meant to solve the problem at hand, which was building a very specific and very well-defined type of web application. Sure, any of those tools could be used to build the application, just as you can also use a spoon to cut your potatoes and a fork to eat your soup - but does it make sense? Just because you can doesn’t mean you should.

All of those choices added unnecessary complexity, which meant unnecessary time spent building the application, unnecessary electricity spent and the accompanying carbon footprint, unnecessary money spent by my friend, and ultimately even unnecessary frustration for the developers who are working on it. Yes, “working”, not “worked”, because they still haven’t finished it and are way beyond their original estimation of three to four months.

I’m not sure exactly how we got here but I think it’s a combination of at least three things:

The “anyone can code” culture, which led to too many pseudo-programmers contributing negatively to the ecosystems.
Marketing folks pushing buzzwords to everyone’s mind.
Script kiddies wanting to use the cool tools from the big guys because they all want to be the next Zuckerberg, without understanding the problems these tools were designed to solve.

The vast majority of companies are small. Your company is most likely a small company. What huge companies like Google and Facebook do does not apply to you. Not only does it not apply, trying to replicate what they do on your smaller company is actually detrimental. You do not have the same problems they do, and certainly not at the same scale. And even if you did, you don’t have the amount of money or people to absorb the complexity of the systems and tools they use. It’s incredibly counter-productive to adopt, for example, micro-services and Kubernetes in a company that has 6 or 7 engineers. Such a company does not have the type of problem these tools solve, nor do they have the capacity to absorb the complexity that comes with said tools. And yet, this is exactly what many small companies do.

Returning to my friend’s project: over a year later, what started as a simple medical appointments platform has become a cautionary tale of modern software development gone wrong. The unnecessary complexity introduced by poor technological choices has led to delays, increased costs, and frustrated developers - exactly the problems I’ve outlined above. Through this series of posts, I hope to show that there’s a better way: one that focuses on choosing the right tools for the job, embracing simplicity where possible, and remembering that our goal is to solve real problems, not to chase the latest trends. Perhaps by examining these issues one at a time, we can start shifting our industry back towards more sensible, maintainable, and enjoyable software engineering.

https://www.borfast.com/blog/2023/06/19/software-engineering-is-broken/

You're against companies using microservices or ochestration tools like Kubernetes just because the dev team consists of 6-7 engineers? Is it the team size alone that determines whether to use these tools or not, or the complexity of the product the company is building and other data points such as the number of users the company is serving?

Babtunz:
You're against companies using microservices or ochestration tools like Kubernetes just because the dev team consists of 6-7 engineers? Is it the team size alone that determines whether to use these tools or not, or the complexity of the product the company is building and other data points such as the number of users the company is serving?

True the blog writer is wrong on that one! The use of Kubernetes should the determined by the number of different operating systems the application will deployed to which will then require containerization and not by the number of developers in the team.

MindHacker9009:
This blog is wrong on Kubernetes, as this should the determined by the number of servers needed for load balancing and not by the number of developers in the team.
But with the rest of the blog he is right.

From a blog post: A little over a year ago, a friend of mine hired an agency to build a web application for his business. The application is basically a simple online platform for medical appointments and consultations via video calls using Twilio. Since my friend doesn’t have that much technical knowledge, he asked me to help him validate what the agency was proposing. When I read the proposal, I was shocked. Not only because of the value they were asking but even more so due to the technological choices. It was clear to me right away that they were the typical agency where no one knew anything other than Javascript and MongoDB (thanks, Freecodecamp! 😠) - in other words, they know very little about proper software engineering.

They mentioned React, Strapi, MongoDB and GraphQL as the foundational technologies for the application. This made absolutely no sense:

Strapi is a framework to build CMS, not a framework or library to build a full-fledged web application.
MongoDB is a document store but this type of application will obviously be based on relational data and thus, it needs a relational database.
GraphQL is meant for scenarios where you have a lot of scattered data and you need to easily be able to fetch random pieces of data from random places.
React might be a good fit for large teams building very large and very complex frontends but this is a fairly simple application and the agency building it is very small. [Would suggest jQuery still for any size project]

In summary, none of the tools they chose were meant to solve the problem at hand, which was building a very specific and very well-defined type of web application. Sure, any of those tools could be used to build the application, just as you can also use a spoon to cut your potatoes and a fork to eat your soup - but does it make sense? Just because you can doesn’t mean you should.

All of those choices added unnecessary complexity, which meant unnecessary time spent building the application, unnecessary electricity spent and the accompanying carbon footprint, unnecessary money spent by my friend, and ultimately even unnecessary frustration for the developers who are working on it. Yes, “working”, not “worked”, because they still haven’t finished it and are way beyond their original estimation of three to four months.

I’m not sure exactly how we got here but I think it’s a combination of at least three things:

The “anyone can code” culture, which led to too many pseudo-programmers contributing negatively to the ecosystems.
Marketing folks pushing buzzwords to everyone’s mind.
Script kiddies wanting to use the cool tools from the big guys because they all want to be the next Zuckerberg, without understanding the problems these tools were designed to solve.

The vast majority of companies are small. Your company is most likely a small company. What huge companies like Google and Facebook do does not apply to you. Not only does it not apply, trying to replicate what they do on your smaller company is actually detrimental. You do not have the same problems they do, and certainly not at the same scale. And even if you did, you don’t have the amount of money or people to absorb the complexity of the systems and tools they use. It’s incredibly counter-productive to adopt, for example, micro-services and Kubernetes in a company that has 6 or 7 engineers. Such a company does not have the type of problem these tools solve, nor do they have the capacity to absorb the complexity that comes with said tools. And yet, this is exactly what many small companies do.

Returning to my friend’s project: over a year later, what started as a simple medical appointments platform has become a cautionary tale of modern software development gone wrong. The unnecessary complexity introduced by poor technological choices has led to delays, increased costs, and frustrated developers - exactly the problems I’ve outlined above. Through this series of posts, I hope to show that there’s a better way: one that focuses on choosing the right tools for the job, embracing simplicity where possible, and remembering that our goal is to solve real problems, not to chase the latest trends. Perhaps by examining these issues one at a time, we can start shifting our industry back towards more sensible, maintainable, and enjoyable software engineering.

https://www.borfast.com/blog/2023/06/19/software-engineering-is-broken/

So use jquery instead of react that obviously someone that hasn't done frontend in a very long time. Whats wrong with mongoDB? Also seems like someone who hasn't used mongoDB since 1700s. Mongoose makes mongoDB essentially a relational database.

All I see here is just an old programmer stuck in his ways, not willing and open to update his knowledge and understanding of technologies he so much criticise.

Even with jquery and a SQL database, if the developers don't know what they are doing which will likely be the case if they are building a website with jquery in 2025, they will still struggle to deliver.

I am pretty sure if you ask this guy what are signals in javascript he will have never heard of it. These are the dangers of living in your own little bubble, not willing to keep your self updated.

ReactExpress:
So use jquery instead of react that obviously someone that hasn't done frontend in a very long time. Whats wrong with mongoDB? Also seems like someone who hasn't used mongoDB since 1700s. Mongoose makes mongoDB essentially a relational database.

All I see here is just an old programmer stuck in his ways, not willing and open to update his knowledge and understanding of technologies he so much criticise.

Even with jquery and a SQL database, if the developers don't know what they are doing which will likely be the case if they are building a website with jquery in 2025, they will still struggle to deliver.

I am pretty sure if you ask this guy what are signals in javascript he will have never heard of it. These are the dangers of living in your own little bubble, not willing to keep your self updated.

The blog post is not mine but I agree with many of his comments.

You mentioned signals in JavaScript, so describe the projects you have done with React that jQuery cannot do?

MindHacker9009:
The blog post is not mine but I agree with many of his comments.

You mentioned signals in JavaScript, so describe the projects you have done with React that jQuery cannot do?

Oh I definitely knew it wasn't your post, which is why my comment weren't directed to you.

Your last paragraph is confusing, how is my mention of signals and project with React that JQuery cannot do correlate? React doesn't use signals. E be like say you and the blog poster are cut from the same cloth, no wonder you agree with him

Also I never said jquery can't be used for websites. But its an old technology, and the developer experience with it compared to newer technologies like React, vue, svelte, solidjs are miles away. You will almost always develop any website at faster speed and efficiency with these technologies than using jquery where you have to do the monotonous selection of dom elements before doing anything with them. To do a simple incremental count will see you jumping from one file to the other like a headless chicken. Manipulation of css even loading api data on the page require tedious unnecessary code setup. These are all done with ease in react. With the power of new technologies like server components, you can serve pages at lightning speed.

I mean its 2025 if you want to die on that hill feel free, each his own but the blog post writer is definitely out dated in his views. I can very much relate because I have actually worked with developers like him in the past. Too rigid to learn new things, too stiff to bend to modern approach. How can you be a developer and not be willing to learn,

So you mean because Fortran, C or C++ or Java or Ruby or VBScript are old means they should not be used anymore when there are new languages out now? This is the problem with the low barrier to entry in programming and the tech world, you see someone with a degree in maths, chemistry, biology etc or no degree at all but just a coding boot camp and they are all calling themselves Software Engineers. When the word Software Engineer should only be reserved for those with a degree in computer science or software engineering or computer engineering because these are the people who will first analyse a project requirement to determine which language and framework is best for the software application before they will begin to code. But those without these degrees will just use any latest language or framework just because it's the latest not knowing what type of projects they are good for.

You can use React with JavaScript Signals for real-time updates. Means your don't even know much about React you are promoting here.

In 2025 you can die on your ignorance not knowing when and what each framework is good for.

ReactExpress:
Oh I definitely knew it wasn't your post, which is why my comment weren't directed to you.

Your last paragraph is confusing, how is my mention of signals and project with React that JQuery cannot do correlate? React doesn't use signals. E be like say you and the blog poster are cut from the same cloth, no wonder you agree with him

Also I never said jquery can't be used for websites. But its an old technology, and the developer experience with it compared to newer technologies like React, vue, svelte, solidjs are miles away. You will almost always develop any website at faster speed and efficiency with these technologies than using jquery where you have to do the monotonous selection of dom elements before doing anything with them. To do a simple incremental count will see you jumping from one file to the other like a headless chicken. Manipulation of css even loading api data on the page require tedious unnecessary code setup. These are all done with ease in react. With the power of new technologies like server components, you can serve pages at lightning speed.

I mean its 2025 if you want to die on that hill feel free, each his own but the blog post writer is definitely out dated in his views. I can very much relate because I have actually worked with developers like him in the past. Too rigid to learn new things, too stiff to bend to modern approach. How can you be a developer and not be willing to learn,

MindHacker9009:
So you mean because Fortran, C or C++ or Java are old means it should not be used anymore when there are new languages out now? This is the problem with the low barrier to entry in programming and the tech world, you see someone with a degree in maths, chemistry, biology etc or no degree at all but just a coding boot camp and they are all calling themselves Software Engineers. When the word Software Engineer should only be reserved for those with a degree in computer science or software engineering or computer engineering because these are the people who will first analyse a project requirement to determine which language is best for the software application before they will begin to code. But those without these degrees will just use any latest language or framework just because it's the latest not knowing what type of projects they are good for.

You can use React with JavaScript Signals for real-time updates. Means your don't even know much about React you are promoting here.

In 2025 you can die on your ignorance not knowing when and what each programming framework is good for.

React doesn't use js signals oga, react uses virtual dom. Try to learn things before spitting trash. Framework like solidjs use signals.

And who is promoting react? I am only responding to the massive ignorance on display. I even mentioned several other frameworks

How is JQuery synonymous to java and C and the likes. The level of mental gymnastics you have to do to relate both in this context is crazy. Jquery is a js framework others I mentioned are js frameworks.

I literally listed some few bone of contention in using jquery obviously you have no insight into the js ecosystem to respond to them, to even say React uses signals just proves you have no idea what you are talking about. You just dey open mouth waaa like your blog post brother. No solid ground of knowledge to stand on just vibes.

These are all again frameworks, the idea of jquery was to improve developer experience with vanilla js. Other framwork that came after did jquery jobs 10 times better. No project requirement will make any frontend dev use jquery in 2025, you can take that to the bank except they are like you with no knowledge no hands on experience just vibes and all talk.

You don't know something you will not ask questions and learn. Na to carry ego dey yarn trash. See how you disgrace yourself now. I even rated you high small but as you mentioned react uses signals I know say this one is gone, you have nothing to contribute to this discusss.

While at it yeah you and your blog post brother can tell node js developers not to use frameworks like express, fastify, nest, adonis but instead use vanilla nodejs because the project needs it.

It you that has a problem with using jQuery in 2025. I have asked you to describe the projects you have done with React that jQuery cannot do but instead you are jumping around with your ignorance.

You do even know what JavaScript signals are. JavaScript signals can be just a click or keypress, but I was referring to advance JS signals like Signals in WebSockets. Shows you don't even know what all the different types of JS signals are.

I mentioned programing languages as well as they are not different from choosing the right framework to use for a project, but you were ignorance of these example I made.

You are the ones the blog writer is referring to that will just use a tool they only know for a project and will end up not being able to deliver the project or will deliver one that does not me the users needs.

ReactExpress:
React doesn't use js signals oga, react uses virtual dom. Try to learn things before spitting trash. Framework like solidjs use signals.

And who is promoting react? I am only responding to the massive ignorance on display. I even mentioned several other frameworks

How is JQuery synonymous to java and C and the likes. The level of mental gymnastics you have to do to relate both in this context is crazy. Jquery is a js framework others I mentioned are js frameworks.

I literally listed some few bone of contention in using jquery obviously you have no insight into the js ecosystem to respond to them, to even say React uses signals just proves you have no idea what you are talking about. You just dey open mouth waaa like your blog post brother. No solid ground of knowledge to stand on just vibes.

These are all again frameworks, the idea of jquery was to improve developer experience with vanilla js. Other framwork that came after did jquery jobs 10 times better. No project requirement will make any frontend dev use jquery in 2025, you can take that to the bank except they are like you with no knowledge no hands on experience just vibes and all talk.

You don't know something you will not ask questions and learn. Na to carry ego dey yarn trash. See how you disgrace yourself now. I even rated you high small but as you mentioned react uses signals I know say this one is gone, you have nothing to contribute to this discusss.

MindHacker9009:
It you that has a problem with using jQuery in 2025. I have asked you to describe the projects you have done with React that jQuery cannot do but instead you are jumping around with your ignorance.

You do even know what JavaScript signals are. JavaScript signals can be just a click or keypress, but I was referring to advance JS signals like Signals in WebSockets. Shows you don't even know what all the different types of JS signals are.

I mentioned programing languages as well as they are not different from choosing the right framework to use for a project, but you were ignorance of these exaple.

You are the ones the blog writer is referring to that will just use a tool they only know for a project and will end up not being able to deliver the project or will deliver one that does not me the users needs.

Lol this guy is desperately trying to get a W . I am sorry I can't take you seriously any more. You have displayed your ignorance for all to see.

How will anyone who have their head together and knows the js ecosystems be thinking about Websocket when I mentioned signals and I even stated they aren't used in react. If your head cannot boot after hearing the context that you now have to bring wack narrative to safe face, I don't know. You don't have anything else to say.

I won't be surprised if you struggle with English in school. I literally address your first paragraph above when I quoted that message. But instead of addressing it like a normal human being you ran away and started drawing weird comparison of jquery with other languages when we are talking about frameworks in the same language. And then made the powerful claim that React js uses signals.

How will you even read my response when all you do is carry ego and spit trash. If you were speaking facts self eh we can manage the ego. But this one facts patapata you nor get. Na why you dey use touch light find wetin no lose. Na why you think FE dev should use jquery in 2025. Just vibes I swear, I can't take you seriously again brother

You are just spilling out trash dues to your ignorance. Bringing in js signals mean you don't even know what you are taking about and you are the one that had problem with English at school.

Let me lecture you on React you think you know but you are even ignorant of. In React, events like onClick, onChange, and onSubmit can be seen as signals.

Here are the key Downsides of React on the Client’s Machine
Increased initial load time due to large JavaScript bundles.
Memory consumption for rendering complex UIs and handling state.
Increased JavaScript execution time can cause slowdowns on lower-end devices.
Dependency on JavaScript—no fallback if JS is disabled.
SEO challenges without server-side rendering.
Performance overhead on low-end devices or for complex applications.
Difficult debugging in larger apps with deep component trees.
Fragmented ecosystem of React libraries can cause incompatibility issues.
Abstraction overhead can sometimes hinder performance for simpler apps.

You are running away from my question to describe what projects you have used React for that jQuery cannot do but to hide you ignorance you are jumping around to show more of your ignorance.

ReactExpress:
Lol this guys desperately trying to get a W . I am sorry I can't take you seriously any more. You have displayed your ignorance for all to see.

How will anyone who have their head together and knows the js ecosystems be thinking about Websocket when I mentioned signals and I even stated they aren't used in react. If your head cannot boot after hearing the context that you now have to bring wack narrative to safe face, I don't know. You don't have anything else to say.

I won't be surprised if you struggle with English in school. I literally address your first paragraph above when I quoted that message. But instead of addressing it like a normal human being you ran away and started drawing weird comparison of jquery with other languages when we are talking about frameworks in the same language. And then made the powerful claim that React js uses signals.

How will you even read my response when all you do is carry ego and spit trash. If you were speaking facts self eh we can manage the ego. But this one facts patapata you nor get. Na why you dey use touch light find wetin no lose. Na why you think FE dev should use jquery in 2025. Just vibes I swear, I can't take you seriously again brother

MindHacker9009:
You are just spilling out trash dues to your ignorance. Bringing in js signals mean you don't even know what you are taking about and you are the one that had problem with English at school.

Let me lecture you on React you think you know but you are even ignorant of. In React, events like onClick, onChange, and onSubmit can be seen as signals.

Here are the key Downsides of React on the Client’s Machine
Increased initial load time due to large JavaScript bundles.
Memory consumption for rendering complex UIs and handling state.
Increased JavaScript execution time can cause slowdowns on lower-end devices.
Dependency on JavaScript—no fallback if JS is disabled.
SEO challenges without server-side rendering.
Performance overhead on low-end devices or for complex applications.
Difficult debugging in larger apps with deep component trees.
Fragmented ecosystem of React libraries can cause incompatibility issues.
Abstraction overhead can sometimes hinder performance for simpler apps.

You are running away from my question to describe what projects you have used React for that jQuery cannot do but to hide you ignorance you are jumping around show more of your ignorance.

You see another reason why I said you and your blog post brother are cut from the same cloth. When I mentioned server components and how it makes serving webpage at fast speed you didn't see it. Oh yeah I stated it in the post you are still using touch light to find . Sorry oh maybe I should stop answering so you stop disgracing yourself.

Every thing you mentioned are problems with create react app which has been deprecated already. Lemme guess you didn't know same way you didn't know React doesn't use signals . Oh right you thought it was Websocket... Sure sure

You are a joker I swear, you are trying so hard to sound like you know what you're talking about. But time after time you keep showing you are a lost puppy. With literally zero insight. Please do well do go to the official react page and set up a react project any of the ways they recommend and see if you will have these issues.

Ignorance is really a bad thing. But ignorance with pride is the worst.

You and your mates using React for every project without doing analysis as to which framework is best, but just use React are the ones that are ignorant and continue to show pride in your ignorance.

You still cannot describe projects you have worked on that jQuery cannot do.

Even with version 18: These are still the Issues Not Fully Fixed in React:
Performance Overhead in complex applications (deep component trees, frequent updates).
Bundle Size and dependency-heavy applications.
SEO challenges with client-side rendering (especially in dynamic apps).
Memory Leaks due to improper cleanup.
Overhead in simpler apps due to React's abstraction.
Fragmented ecosystem and tool/library compatibility issues.
Handling complex forms or large UI components with high performance.
Unpredictable performance with Concurrent Mode.

ReactExpress:
You see another reason why I said you and your blog post brother are cut from the same cloth. When I mentioned server components and how it makes serving webpage at fast speed you didn't see it. Oh yeah I stated it in the post you are still using touch light to find . Sorry oh maybe I should stop answering so you stop disgracing yourself.

Every thing you mentioned are problems with create react app which has been deprecated already. Lemme guess you didn't know same way you didn't know React doesn't use signals . Oh right you thought it was Websocket... Sure sure

You are a joker I swear, you are trying so hard to sound like you know what you're talking about. But time after time you keep showing you are a lost puppy. With literally zero insight. Please do well do go to the official react page and set up a react project any of the ways they recommend and see if you will have these issues.

Ignorance is really a bad thing. But ignorance with pride is the worst.

MindHacker9009:
You and your mates using React for every project without doing analysis as to which framework is best, but just use React are the ones that are ignorant and continue to show pride in your ignorance.

You still cannot describe projects you have worked on that jQuery cannot do.

Even with version 18: These are still the Issues Not Fully Fixed in React:
Performance Overhead in complex applications (deep component trees, frequent updates).
Bundle Size and dependency-heavy applications.
SEO challenges with client-side rendering (especially in dynamic apps).
Memory Leaks due to improper cleanup.
Overhead in simpler apps due to React's abstraction.
Fragmented ecosystem and tool/library compatibility issues.
Handling complex forms or large UI components with high performance.
Unpredictable performance with Concurrent Mode.

This one doesn't even know there is react 19

Thats all I will say about your delusion. You need help brother seriously this is troubling. The chat bot that is helping you isn't doing a good job at all

I don't use react for all my project thats why I listed several other js framework for you. There was simple site I did for someone some months ago I used Astro js.

Unlike you that want to die with jquery and that you can build every site with jquery. I will never use jquery for any website, because there are so many better options to pick from. React isn't the only kid in town them plenty and I recommend. But jquery you are on your own in that madness

All these new frameworks you want to die on are all built on JavaScript and the creators are just after making a name for themselves rather than coming out with something as stable as jQuery that can handle any task properly.

These are still the issues with the latest version of React 19 you want to die on:
Migration Challenges – The React 19 migration tool has bugs, making it difficult to upgrade from React 18. Some issues stem from the new JSX transform.
Suspense Behavior Changes – Suspense now prevents sibling components from pre-rendering, potentially causing performance issues due to sequential data fetching.
Dependency Conflicts – Some third-party libraries, like @testing-library/react, are still optimized for React 18, leading to compatibility issues.
Ecosystem Compatibility – Many React libraries and tools have not yet fully adapted to React 19, causing version conflicts and upgrade difficulties.

ReactExpress:
This one doesn't even know there is react 19

Thats all I will say about your delusion. You need help brother seriously this is troubling. The chat bot that is helping you isn't doing a good job at all

I don't use react for all my project thats why I listed several other js framework for you. There was simple site I did for someone some months ago I used Astro js.

Unlike you that want to die with jquery and that you can build every site with jquery. I will never use jquery for any website, because there are so many better options to pick from. React isn't the only kid in town them plenty and I recommend. But jquery you are on your own in that madness

MindHacker9009:
All these new frameworks you want to die on are all built on JavaScript and the creators are just after making a name for themselves rather than coming out with something as stable as jQuery that can handle any task properly.

These are still the issues with the latest version of React 19 you want to die on:
Migration Challenges – The React 19 migration tool has bugs, making it difficult to upgrade from React 18. Some issues stem from the new JSX transform.
Suspense Behavior Changes – Suspense now prevents sibling components from pre-rendering, potentially causing performance issues due to sequential data fetching.
Dependency Conflicts – Some third-party libraries, like @testing-library/react, are still optimized for React 18, leading to compatibility issues.
Ecosystem Compatibility – Many React libraries and tools have not yet fully adapted to React 19, causing version conflicts and upgrade difficulties.

Lol so jquery is built on the moon not javascript. You are sounding less intelligent every single post you make.

Even with all these issues I will gladly die on the hill of react than step one foot on that of jquery. You cannot pay me enough to go through that torture.

But does react 19 have all those your many problems you have been listing upandan do well to ask chatgpt lets hear what it has to say.

As much as I hate react I still come back to it. I ran away to solid, to vue to svelte to astro to remix even to qwik trust me I have ran places. But react just feels like home, when I want to build scalable website react is my go to because its tested and trusted. When I want to build smaller website I experiment.

The only framework I haven't really experimented with well is angular. The battery of files the set up created when I first installed it was crazy I just didn't continue. However that was long ago before typescript became a thing in React. I was sha using it to show my self small for work that time because I had a little bit of experience with it in angular.

But you see your precious jquery, I use it for one site several years ago and I have never returned and will never returned. Although I did see they pushed a new update late last year. Made me think of giving it a chance but nah, when you can have chicken why settle for chewing stick

These companies have dropped or avoided your React, but because they are been misinformed by your mates they don't want to go back to jQuery, so they are going to still be dropping the new frameworks they have moved to.

1. Airbnb (Partial Rollback of React & React Native)
Issue: Airbnb initially adopted React Native for mobile development but later abandoned it due to performance issues, integration problems, and developer experience challenges.
What happened?
Difficulty integrating React Native with native code.
Slower performance compared to fully native solutions.
Issues maintaining a unified React Native codebase across Android & iOS.
Result: Airbnb switched back to native development but still uses React.js for their web app.
Source: Airbnb Engineering Blog

2. Twitter Lite (Switched from React to Preact for Performance)
Issue: Twitter initially used React for its lightweight mobile web app but faced bundle size and performance bottlenecks on low-end devices.
What happened?
React’s large bundle size (~40KB) slowed down initial load times.
Increased JS execution time on slower devices.
Twitter needed a more lightweight alternative to improve UX.
Result: They switched from React to Preact, a smaller alternative (~3KB), improving load times and performance.
Source: Twitter Engineering Blog

3. Instagram (Struggles with React’s Performance in Complex UIs)
Issue: Instagram, owned by Meta (the creators of React), faced performance issues with React in their web app, especially with state-heavy components.
What happened?
Large component trees led to inefficient re-renders.
Complex animations and interactions suffered from React’s reconciliation process.
Memory usage spiked when handling extensive media content.
Result: Instagram had to optimize React performance aggressively and introduced server-side rendering (SSR) and memoization techniques to handle the issues.
Source: Internal reports & discussions from Instagram engineers.

4. Medium (Dropped React for Preact)
Issue: Medium initially used React but switched to Preact due to performance and bundle size concerns.
What happened?
React’s large bundle size slowed down page loads.
Heavy client-side rendering (CSR) caused delays in rendering content quickly.
Result: Medium moved to Preact, which provided similar capabilities with a smaller footprint.
Source: Developer reports & discussions.

5. Basecamp (Dropped React for Hotwire/Turbo)
Issue: Basecamp (creators of Ruby on Rails) initially used React for dynamic UI elements but found it too complex for their needs.
What happened?
React’s state management was overly complicated for their architecture.
Too much JavaScript overhead for an app that needed mostly HTML-based updates.
Result: They switched to Hotwire/Turbo, a server-driven approach that minimized frontend complexity.
Source: Basecamp Blog

6. GitHub Avoids React
What happened?
What happened?
Slow initial page loads – React’s client-side rendering (CSR) required downloading and processing large JavaScript bundles before displaying content.
High JavaScript overhead – GitHub’s UI is mostly static, and React’s reactivity system added unnecessary complexity.
Performance issues on large repositories – React’s reconciliation process slowed down rendering complex diffs and issue threads.
Security concerns – Using minimal JavaScript reduced the risk of cross-site scripting (XSS) attacks.
SEO challenges – Server-rendered HTML ensured that GitHub’s content remained fully indexable by search engines.

ReactExpress:
Lol so jquery is built on the moon not javascript. You are sounding less intelligent every single post you make.

Even with all these issues I will gladly die on the hill of react than step one foot on that of jquery. You cannot pay me enough to go through that torture.

But does react 19 have all those your many problems you have been listing upandan do well to ask chatgpt lets hear what it has to say.

As much as I hate react I still come back to it. I ran away to solid, to vue to svelte to astro to remix even to qwik trust me I have ran places. But react just feels like home, when I want to build scalable website react is my go to because its tested and trusted. When I want to build smaller website I experiment.

But you see your precious jquery, I use it for one site several years ago and I have never returned and will never returned. Although I did see they pushed a new update late last year. Made me think of giving it a chance but nah, when you can have chicken why settle for chewing stick

MindHacker9009:
These companies have dropped or avoided your React, but because they are been misinformed by your mates they don't want to go back to jQuery, so they are going to still be dropping the new frameworks they have moved to.

1. Airbnb (Partial Rollback of React & React Native)
Issue: Airbnb initially adopted React Native for mobile development but later abandoned it due to performance issues, integration problems, and developer experience challenges.
What happened?
Difficulty integrating React Native with native code.
Slower performance compared to fully native solutions.
Issues maintaining a unified React Native codebase across Android & iOS.
Result: Airbnb switched back to native development but still uses React.js for their web app.
Source: Airbnb Engineering Blog

2. Twitter Lite (Switched from React to Preact for Performance)
Issue: Twitter initially used React for its lightweight mobile web app but faced bundle size and performance bottlenecks on low-end devices.
What happened?
React’s large bundle size (~40KB) slowed down initial load times.
Increased JS execution time on slower devices.
Twitter needed a more lightweight alternative to improve UX.
Result: They switched from React to Preact, a smaller alternative (~3KB), improving load times and performance.
Source: Twitter Engineering Blog

3. Instagram (Struggles with React’s Performance in Complex UIs)
Issue: Instagram, owned by Meta (the creators of React), faced performance issues with React in their web app, especially with state-heavy components.
What happened?
Large component trees led to inefficient re-renders.
Complex animations and interactions suffered from React’s reconciliation process.
Memory usage spiked when handling extensive media content.
Result: Instagram had to optimize React performance aggressively and introduced server-side rendering (SSR) and memoization techniques to handle the issues.
Source: Internal reports & discussions from Instagram engineers.

4. Medium (Dropped React for Preact)
Issue: Medium initially used React but switched to Preact due to performance and bundle size concerns.
What happened?
React’s large bundle size slowed down page loads.
Heavy client-side rendering (CSR) caused delays in rendering content quickly.
Result: Medium moved to Preact, which provided similar capabilities with a smaller footprint.
Source: Developer reports & discussions.

5. Basecamp (Dropped React for Hotwire/Turbo)
Issue: Basecamp (creators of Ruby on Rails) initially used React for dynamic UI elements but found it too complex for their needs.
What happened?
React’s state management was overly complicated for their architecture.
Too much JavaScript overhead for an app that needed mostly HTML-based updates.
Result: They switched to Hotwire/Turbo, a server-driven approach that minimized frontend complexity.
Source: Basecamp Blog

6. GitHub Avoids React
What happened?
What happened?
Slow initial page loads – React’s client-side rendering (CSR) required downloading and processing large JavaScript bundles before displaying content.
High JavaScript overhead – GitHub’s UI is mostly static, and React’s reactivity system added unnecessary complexity.
Performance issues on large repositories – React’s reconciliation process slowed down rendering complex diffs and issue threads.
Security concerns – Using minimal JavaScript reduced the risk of cross-site scripting (XSS) attacks.
SEO challenges – Server-rendered HTML ensured that GitHub’s content remained fully indexable by search engines.

Do you know the funny thing everything you listed here only proves my point.

None not one even consider moving to jquery

I have always said there are alot of alternatives but jquery isn't one of them. Thank you for proving my point without a reasonable doubt.

Show us one company that moved from react to jquery oga. Or forever hold your peace

If you cannot read my comments then you should forever hold your peaces in ignorance.

You mates that don't want to hear of jQuery are the ones adverting them not to use jQuery, just because they want to trend by saying they are using the latest frameworks, but does not want to admit that jQuery is better.

Event the Hotwire/Turbo one of them have moved to still have these issues:

Turbo aims to minimize JavaScript, but some applications with complex, dynamic interactivity may face challenges when trying to fully leverage Turbo’s model.
Problem: Highly dynamic UI elements (e.g., complex forms or components with lots of interactive states) that rely on client-side JavaScript may not fit well with Turbo’s server-driven approach.
Impact: It may require workarounds or introducing more custom JavaScript to handle specific interactivity that Turbo doesn’t naturally support.

ReactExpress:
Do you know the funny thing everything you listed here only proves my point.

None not one even consider moving to jquery

I have always said there are alot of alternatives but jquery isn't one of them. Thank you for proving my point without a reasonable doubt.

Show us one company that moved from react to jquery oga. Or forever hold your peace

Karleb:
It's the issue we are facing.

One project I'm working on here and the so called project manager created 3 different repos because the figma has 3 different dashboards. I was totally against it and they set up an urgent meeting to discuss that.

Can you imagine me trying to convince tech guys that that was a horrible decision. Such a waste of time and a guy who claim he is also a backend developer supported the funny idea, because he is a developer too.

Their reasons are: scalability and its how things are done there.

I be wan ask the guy to define scalability. I just had to calmy explain why it's a horrible idea because there's no point being rude.

If you are learning this tech thing on your own, please go out and understudy seasoned professionals and if you are good please be loud.

Just to confirm my understanding, I assume your project consists of three layers:

API Layer – Fetches data from the API.
Data Layer – Processes data, implements business logic.
UI Layer – UI from Figma that displays data and handles user inputs / animations.

If only the Dashboard UI is changing while the API and Data Layer remains the same, why is the Project Manager maintaining three separate repositories for a single project?

Wouldn't a theming system be a better approach? A structure where UI components for each of the three dashboards are stored in sub-folders while still consuming the same API/endpoint?

If my assumption is correct, the Project Manager may not fully grasp the benefits of using a single repo. It might help to explain the advantages clearly, because his resistance could come from a lack of understanding rather than preference.

To even go further: Whenever they make a change on 1 repo due to API changes, it means they need to replicate that change on 2 other repos. WHY? It does not make sense.

tosinhtml:
Just to confirm my understanding, I assume your project consists of three layers:

API Layer – Fetches data from the API.
Data Layer – Processes data, implements business logic.
UI Layer – UI from Figma that displays data and handles user inputs / animations.

If only the Dashboard UI is changing while the API and Data Layer remains the same, why is the Project Manager maintaining three separate repositories for a single project?

Wouldn't a theming system be a better approach? A structure where UI components for each of the three dashboards are stored in sub-folders while still consuming the same API/endpoint?

If my assumption is correct, the Project Manager may not fully grasp the benefits of using a single repo. It might help to explain the advantages clearly, because his resistance could come from a lack of understanding rather than preference.

To even go further: Whenever they make a change on 1 repo due to API changes, it means they need to replicate that change on 2 other repos. WHY? It does not make sense.

The repo has 2 layers, we are not consuming an external api.

Its the business logic and the ui layer which already have 2 separate github repos, now the dummy project manger created 3 repos per layer, making it a total of 6 DIFFERENT REPOSITORIES! Just because it has 3 dashboards.

That's the most rookie thing I have seen in my life and I have spent the past 3 posts explaining it to a guy who doesn't code on this thread why it's a terrible idea.

It just reminds me of how a guy was arguing with a lawyer on Twitter and when they asked of his law degree, he said he learnt everything off suits series.

The project uses 2 repos now because that nonsense cannot happen on my watch.

MindHacker9009:
If you cannot read my comments then you should forever hold your peaces in ignorance.

You mates that don't want to hear of jQuery are the ones adverting them not to use jQuery, just because they want to trend by saying they are using the latest frameworks, but does not want to admit that jQuery is better.

Event the Hotwire/Turbo one of them have moved to still have these issues:

Turbo aims to minimize JavaScript, but some applications with complex, dynamic interactivity may face challenges when trying to fully leverage Turbo’s model.
Problem: Highly dynamic UI elements (e.g., complex forms or components with lots of interactive states) that rely on client-side JavaScript may not fit well with Turbo’s server-driven approach.
Impact: It may require workarounds or introducing more custom JavaScript to handle specific interactivity that Turbo doesn’t naturally support.

Lol its simple na its not rocket science we don't need to call Elon Musk for this. You have friends na, I am sure your blog post brother has friends too. So just name one, I am not asking for alot here, name only 1 big company you and your friends have been able to convince to leave react and move to jquery. We are waiting

Karleb:
The repo has 2 layers, we are not consuming an external api.

Its the business logic and the ui layer which already have 2 separate github repos, now the dummy project manger created 3 repos per layer, making it a total of 6 DIFFERENT REPOSITORIES! Just because it has 3 dashboards.

That's the most rookie thing I have seen in my life and I have spent the past 3 posts explaining it to a guy who doesn't code on this thread why it's a terrible idea.

It just reminds me of how a guy was arguing with a lawyer on Twitter and when they asked of his law degree, he said he learnt everything off suits series.

The project uses 2 repos now because that nonsense cannot happen on my watch.

I saw what you did there

Karleb:
The repo has 2 layers, we are not consuming an external api.

Its the business logic and the ui layer which already have 2 separate github repos, now the dummy project manger created 3 repos per layer, making it a total of 6 DIFFERENT REPOSITORIES! Just because it has 3 dashboards.

That's the most rookie thing I have seen in my life and I have spent the past 3 posts explaining it to a guy who doesn't code on this thread why it's a terrible idea.

It just reminds me of how a guy was arguing with a lawyer on Twitter and when they asked of his law degree, he said he learnt everything off suits series.

The project uses 2 repos now because that nonsense cannot happen on my watch.

You've tried, Imagine having to fight off a group of people. You will constantly be seen as the enemy of the project. The project would have failed woefully if that project manager had succeeded in his approach and then blame the developers for not being good enough.

ReactExpress:
Lol so jquery is built on the moon not javascript. You are sounding less intelligent every single post you make.

Even with all these issues I will gladly die on the hill of react than step one foot on that of jquery. You cannot pay me enough to go through that torture.

But does react 19 have all those your many problems you have been listing upandan do well to ask chatgpt lets hear what it has to say.

As much as I hate react I still come back to it. I ran away to solid, to vue to svelte to astro to remix even to qwik trust me I have ran places. But react just feels like home, when I want to build scalable website react is my go to because its tested and trusted. When I want to build smaller website I experiment.

The only framework I haven't really experimented with well is angular. The battery of files the set up created when I first installed it was crazy I just didn't continue. However that was long ago before typescript became a thing in React. I was sha using it to show my self small for work that time because I had a little bit of experience with it in angular.

But you see your precious jquery, I use it for one site several years ago and I have never returned and will never returned. Although I did see they pushed a new update late last year. Made me think of giving it a chance but nah, when you can have chicken why settle for chewing stick

The guy you are talking to can't write frontend code to save his life. Let him keep advocating for jQuery, actual frontend dev will continue to use the better options out there no doubt about it. It's clear for everyone to see his 100% clueless about this. Even when he listed companies that left react he listed Instagram in the same post it was noted react was improved on to fix these issues by introducing server components. Anyone who know an atom will understand that the reason most of those companies left react has been fixed and addressed with server components that let you serve pages with very little js and with 100% SEO compatibility.

The fact he wrote that and still don't understand its implications and he think its a plus in his argument says all you need to know

You are the one that can't write frontend code to save your life. See how clueless you are not to know that Instagram is owned by Facebook the creator of React, so they will stay what the like to defend their React. You have now clue of what front-end development it, you are just following your brother above without know what you are doing.

Sultan5:
The guy you are talking to can't write frontend code to save his life. Let him keep advocating for jQuery, actual frontend dev will continue to use the better options out there no doubt about it. It's clear for everyone to see his 100% clueless about this. Even when he listed companies that left react he listed Instagram in the same post it was noted react was improved on to fix these issues by introducing server components. Anyone who know an atom will understand that the reason most of those companies left react has been fixed and addressed with server components that let you serve pages with very little js and with 100% SEO compatibility.

The fact he wrote that and still don't understand its implications and he think its a plus in his argument says all you need to know