Why I Decided to Stop Working with React.js in 2025
Leon Martin

Leon Martin @holasoymalva

About: 404 bio not found

Location:
Mexico City
Joined:
Jan 10, 2019

Why I Decided to Stop Working with React.js in 2025

Publish Date: Jan 7
315 132

React.js has been my go-to framework for years. I’ve built countless projects with it, from tiny prototypes to enterprise-level apps. It’s been a journey filled with learning, late-night debugging, and the satisfaction of shipping great features. But here in 2025, I’ve made a decision: I’m stepping away from React.

This isn’t some “React is dead” rant (spoiler: it’s not). It’s more like a reflection on why the framework that once felt indispensable now feels like a weight I don’t want to carry anymore. If you’re a React dev or someone deciding whether to dive into it, let me explain my reasoning.


The Ecosystem Fatigue Is Real

React’s ecosystem is huge, and for years, that was its biggest strength. Need a router? React Router. State management? Redux, MobX, Zustand, or Context. Want server-side rendering? Hello, Next.js. But over time, this "choose your own adventure" style started to feel more like a maze.

Building a simple app often means cobbling together a dozen libraries, each with its own quirks and updates. You spend more time managing dependencies and figuring out how tools fit together than actually solving the problem you set out to tackle. It’s exhausting, and honestly, I’ve had enough of it.


React Isn’t Simple Anymore

Remember when React was all about simplicity? Back in the day, you wrote class components, passed some props, and called it a day. Then hooks arrived—and they were awesome—but they also came with their own complexity. Suddenly, every blog post and tutorial was about managing useEffect dependencies or battling React’s rendering lifecycle.

And don’t get me started on server components. They’re supposed to make things easier, but they add yet another layer to an already complicated stack. At some point, React started feeling less like a “library for building user interfaces” and more like a convoluted framework trying to be everything at once.


The Market Is Overcrowded

If you’ve been job hunting recently, you’ve probably noticed that React is still everywhere. That sounds like a good thing, right? Plenty of jobs, lots of demand. But the reality is that everyone and their dog knows React now. The market is so saturated that standing out as a React developer has become incredibly hard.

Meanwhile, newer frameworks like Svelte and Solid are carving out niches where demand outpaces supply. Learning them feels like investing in a smaller, less crowded pond where you have a better chance of catching a big fish.


The Alternatives Are Just Better

Over the past couple of years, I’ve dabbled in frameworks like Svelte, SolidJS, and Qwik, and honestly? They’re a breath of fresh air. They’re simpler, faster, and often more intuitive than React.

Take Svelte, for example. No boilerplate, no useState, no useEffect. You write what you mean, and the framework takes care of the rest. It feels like coding in React’s early days, but without all the baggage that’s piled up over the years.

Or look at SolidJS—it’s like React on steroids. It uses the same component-based architecture but with better performance and smaller bundle sizes. And then there’s Qwik, which is rethinking how hydration and rendering work entirely. These frameworks are innovating in ways that make React feel… old.


The Community Shift

The React community has always been one of its strengths, but even that’s started to change. With so many tools and libraries in the ecosystem, the community feels fragmented. Everyone has their own “best practices,” their own stack, their own way of doing things. It’s harder to find a shared sense of direction or even solid advice that works universally.

Meanwhile, communities around newer frameworks feel more unified. They’re smaller, sure, but there’s a sense of excitement and collaboration that reminds me of React’s early days. It’s invigorating to be part of something that feels fresh and full of possibility.


React Is Still Good… Just Not for Me

I want to be clear: React isn’t bad. It’s still an incredible tool for many developers and projects. If you’re working on a large app with an established React codebase, there’s no reason to rip it out. If you’re just starting your journey in web development, React can teach you a lot about modern front-end practices.

But for me, it’s time to move on. I want simplicity. I want to spend less time configuring my stack and more time building things that matter. I want to explore frameworks that feel designed for 2025, not 2013.


What’s Next?

I’m doubling down on Svelte and SolidJS. They align with what I want out of my tools: speed, simplicity, and innovation. I’m also keeping an eye on Qwik and frameworks like Astro, which offer exciting new ways to think about web development.

If you’re still using React and loving it, that’s great. But if you’re feeling frustrated or burnt out, know that there are other options out there. Explore them. Play around. You might find something that reignites your passion for coding.

What about you? Are you sticking with React, or have you started exploring alternatives? Let’s talk in the comments.

Comments 132 total

  • José Pablo Ramírez Vargas
    José Pablo Ramírez VargasJan 9, 2025

    Welcome aboard. I cannot say I went through the same realization because I'm a long-time back-end developer. I came to know React and more UI work in 2020, and in 2023 I became the team leader. By 2024 I had done research and selected Svelte as its replacement.

    For anyone wanting to get out of React or Angular, but don't know how: The answer is micro-frontends. No matter how small your development team is or how big your application(s) is(are). You can always migrate by steps using something like single-spa to do pieces progressively until you are fully migrated.

    • david duymelinck
      david duymelinckJan 12, 2025

      Is micro-frontend not a buzz word for modular architecture?

      Microservices in the backend are an over-engineered solution for most sites. Moving this idea to the frontend requires more code to load in the browser. Because if you want to do it right you need a message system, monitoring, security and so on.

      • José Pablo Ramírez Vargas
        José Pablo Ramírez VargasJan 12, 2025

        You clearly are speaking without a single shred of information or experience. A messaging system is not necessary, but if you must, there's Broadcast API, security is already set up if you come from an existing project, and "so on" is probably already covered.

        I have personally led the conversion of a 100% React code base to Svelte. We have 2 MFE's in Svelte v4 and 2 in Svelte v5. Our setup has been carefully planned and requires no messaging system: We do all with component props, native ES modules that we use as utility modules, and single-spa.

        To give you an idea, a React MFE can prompt the user with an overlay made in Svelte by simply importing a function from a utility module: import { systemOverlay } from '@app/root-service';. That's it. This works. No magic anywhere else. No messaging system. Nothing but a normal import.

        • david duymelinck
          david duymelinckJan 12, 2025

          True I have no experience with micro-frontends. But I have experience with microservices. My comment was from that point of view.

          The messaging system Is not always needed, but in some cases the services need to communicate with each other. I guess in your case the solution was setting component props at runtime?

          The monitoring comes in to play if you run the micro-frontends in different processes or on different servers. If the process/server goes down for some reason the app must have a way to react in that case. It requires more code than when you have a monolith.

          If you do the micro-frontends on a different process/server. each is responsible for the security of their endpoints. So i find it a bit strange you mention that the security of the react code can be used as is?

          That is why I specified if you do it right, meaning porting the microservice architecture to the frontend one on one.
          I don't believe many people do it like that, and that is the base for the modular architecture remark.

          The biggest problem for me with micro-frontends, is that it is more likely to load multiple frameworks. In your case react, svelte v4 and svelte v5. Svelte has a small framework footprint, but what if teams decide to use Angular, Vue, or something else.
          On the backend that is not a problem because code is not loaded to the browser before execution.

          • José Pablo Ramírez Vargas
            José Pablo Ramírez VargasJan 12, 2025

            Your main problem relies on the fact that you try to port microservices to micro-frontends. They share the name significance because they are similar if seen from a distance. When you get closer, micro-frontends have important diferences. The most important one is that all micro-frontend code shares the same process and address space, no matter the origin. This doesn't happen in microservices, where you have (usually) entirely different virtual servers.

            Communication

            Yes, a messaging system works, but it depends on the data to be serialized, so this is the most primitive and less useful. Still, browsers have the built-in system named Broadcast API.

            Since all code share the same process and address space, the most versatile methods are to pass props and to import code. This is where a library like single-spa helps. With this library, we can pass props from Svelte to React or the other way around. Still, this means that the data/code passed is only available after the component mounts. This brings me to the next solution.

            Utility modules are the most versatile and consistent. They let you import code, and that code comes (if you so wish) from another micro-frontend. For example, our application still has the top-level MFE that authenticates in React. This guy authenticates and then provides as an exportable function, a customized fetch() function that other MFE's use. This function is capable of obtaining and renewing tokens.

            The latter comes with a trade-off: One has to code the module as if it were an isolated NPM package, or imports can get circular.

            Monitoring

            It is no different to monitor a microservice or any other server. I don't see the point of bringing it up. Goes down and UI must have a way to react? This is no different to consuming microservices that can go down as well. I also fail to see why this is mentioned. Is it because it requires more code? Sure, nothing is free. Setting up MFE's comes with a cost.

            Security

            You seem to be thinking that MFE's need security on the server. Most of the time this is not the case. Most of the time, the code is allowed to be downloaded anonymously, as you should have zero secrets in the client. All security should be placed on the API side. However, if one must secure something, it is the same as securing any other HTTP server. Pick your server technology and work from there. It has no relation to MFE's.

            Multiple Frameworks

            Well, it is their fault for choosing the loser. This has nothing to do with MFE's and everything to do with the (bad) frameworks you choose (React, Angular and a few others). We're using MFE's to get rid of the bad React choice, and we're very pleased with the results.

            • david duymelinck
              david duymelinckJan 12, 2025

              The most important one is that all micro-frontend code shares the same process and address space

              So what you are saying here, that is for me modular architecture.
              And that removes a lot of concepts coming from the microservices context.

              I guess we had a discussion based on bad naming of a concept :)

    • Ilya Gorenburg
      Ilya GorenburgJan 14, 2025

      Microfrontends can be good solution if your app is huge as well as the team behind it. I was looking into it, used it in one project, but i'm not ready for another project with microfrontends. Yet

      • José Pablo Ramírez Vargas
        José Pablo Ramírez VargasJan 14, 2025

        For an app to be huge or the team to be huge are myths. Truth is: MFE's can be used to migrate technologies little by little, regardless of app or team size.

        • Ilya Gorenburg
          Ilya GorenburgJan 14, 2025

          The main goal of MFE is not migration of the technologies

          • José Pablo Ramírez Vargas
            José Pablo Ramírez VargasJan 14, 2025

            Correct, but it can serve as a migration tool. We are only 3 devs and we use it like this, quite successfully.

  • Varma Sagi
    Varma SagiJan 10, 2025

    Why didn't you consider Nuxt?

    • Leon Martin
      Leon MartinJan 10, 2025

      I have previously worked with Nuxt and although it is good, this year I am looking to experiment with new technologies and stacks.

  • Ilya Gorenburg
    Ilya GorenburgJan 10, 2025

    Every discussion I read about front-end frameworks focuses heavily on state management, learning curve, and performance. But almost no one mentions core features that must be found in the framework, like...

    FORMS. How do you manage forms (their state, validation, logic for complex forms) with Svelte, Solid, React, Vue, etc? Angular has an AMAZING @angular/forms package. Forms are the core of all enterprise-grade applications. What frameworks mentioned above can offer to developers?

    DI (dependency injection). How do most popular frameworks manage dependency injection?

    • Leon Martin
      Leon MartinJan 10, 2025

      Hi Ilya, Great question! For forms, React doesn’t have a built-in solution like Angular’s @angular/forms, but libraries like React Hook Form and Formik are very powerful, offering declarative APIs and excellent validation support. For DI, React relies on Context API for dependency sharing, but it’s not true DI like Angular’s system. Alternatives like InversifyJS can help if you need a more robust DI pattern in React. Svelte and Solid handle forms with minimal boilerplate due to their reactive nature, but you'd need libraries for advanced scenarios. For DI, these frameworks don’t natively support it, but patterns using context/providers can mimic the functionality.

      • Ilya Gorenburg
        Ilya GorenburgJan 10, 2025

        Thank you for your reply! That's the point of my comment - many frameworks don't offer standard packages for core functionality that is a core of many apps these days (name web app without form, router; just as an example 😄). And I guess there will be a delay in those libraries' updating when a new framework version is released? Migration from one library to another brings lots of headaches, and, again, as mentioned in your post... fragmentation - each project is unique and will have its own set of libraries. Choosing a framework these days is similar to choosing the country to live in if you're not happy with the current one 🤣

        Another good point I would mention in your article - is how easy it is to migrate from one version of the framework to the other - will it require an hour, day, or week in case of big breaking changes? 😎

      • Hryhorii Shkliaruk
        Hryhorii ShkliarukJan 14, 2025

        Form hook yes, Formik it's performance pain

    • hesxenon
      hesxenonJan 12, 2025

      You are right in that "every" article talks about the "wrong" things - but angular does NOT have an "amazing forms package".

      For one it's typing is - paradigm bound - much worse than the alternatives in reacts ecosystem (largely due to how inference currently works).

      But mostly because, if you think about it, its the same "state management issue" rehashed into an import.

      WHY would you even want to explicitly sync the DOM state into an "explicit" object that is often spread out across a component tree that yet again mimics the DOM tree and every so often brings up conceptually unsolvable syncing issues?

      Where does the need come from to have a way to say that a property on an object violates some constraint - that is at best a rebranding/predecessor of the Constraint API - based on a dozen other properties from that same object just to hope that the framework will then take core of stuff like preventing submits and marking fields as invalid when you could just set the damn attribute on the damn element and let the browser take care of it?!

      You say forms are at the core of every enterprise app and yes, I agree. They are also at the core of the browser. Stop translating everything into JSON by default without knowing about "the old ways" of simply writing a trivial form tag.

      Oh and btw, that doesn't even mean you have to give up on type safety, not when it matters at least.

      • Ilya Gorenburg
        Ilya GorenburgJan 14, 2025

        Angular forms are amazing! I work with them almost every day. And our forms are complex, it's not about comment or contact us form - they have lots of logic (i'm not talking about validators). Talking about validation - validation attributes can't cover even big portion of the things we need. Building native validators with attributes (custom, not just by by pattern) are complex thing and it works with DOM anyway. When then re-invent a bicycle every time? Framework is made to ease the pain. Isn't it?

        • hesxenon
          hesxenonJan 17, 2025

          Yeah, I'm talking about complex forms too. Forms with sometimes hundreds of fields that are interlinked in non-trivial ways. But in the end there arw always only two cases: either you do simple constraint based validation in the frontend or you ask the server because you rely on data that isn't available in the FE. Both of these things are easy to do without relying on angular forms.

          You do realize you can change constraint attributes and that the constraint api blocks submissions accordingly?

          Also, I find it kinda funny when people say "why not use a framework/library instead of reinventing the wheel" when that approach is exactly reinventing the wheel.

          Just try building a complex form with the constraint/formdata api instead, all you need is component associated state and knowledge about the two apis in question. You'll see that with a bit of brainpower you can circumvent many of the angular/forms problems that come up

      • Litvin Sergey
        Litvin SergeyJan 14, 2025

        @hesxenon
        Unfortunately, it is not always easy to implement the logic that the business is asking for with the DOM API for accessing form elements, FormData API for working with form data, and Validation API for form validation in a convenient way and without spending a lot of time on it.

        I believe Angular Forms has key benefits including two-way data binding, which automatically synchronizes model and view, and a robust built-in validation system with both synchronous and async validators.
        Angular provides comprehensive form state tracking and error handling through Reactive Forms, offering superior TypeScript integration and testability.
        Do you have similar solutions in React to achieve the same functionality?
        Angular Forms comes with all the necessary features out of the box.
        Angular also includes nested forms support, form arrays for dynamic forms, and the FormBuilder service.
        Everyone chooses a tool that is convenient and understandable to them. The choice of tool should still depend on the specific requirements and limitations of the project.
        But my choice is Angular if I am making a site or service more complex than a regular landing page with a form for submitting an application.

    • José Pablo Ramírez Vargas
      José Pablo Ramírez VargasJan 12, 2025

      For Svelte, people love Superforms.

      • Ilya Gorenburg
        Ilya GorenburgJan 14, 2025

        Oh! Good to now there is some solution for Svelte. Thanks!

    • Olushola Lana
      Olushola LanaJan 12, 2025

      I've been an angular developer for years and it's funny and sad at the same time how it never gets the credit it deserves sometimes.

    • Leonardo Volpatto
      Leonardo VolpattoJan 13, 2025

      Angular is a framework. It's mature and complete. We are now in 2025, faster computers and It's being a long time I don't see "performance issues".
      Learning curve? well, If you are a good software engineer you'll see that angular uses patterns and it's kinda natural to use them. Maybe this divide the juniors from seniors. Anyone can write poor react, vue, bla bla code. In angular, otherwise, you can find some better code.
      Yes, after 25 years in this industry I saw that Angular was one of the most stable and mature solutions created for frontends and webapps.

      • Ilya Gorenburg
        Ilya GorenburgJan 14, 2025

        By performance issues i mean web vitals - everyone is now trying to catch '100' points for each score. I might be unclear on that item

        I agree that you can write poor code with any framework/library. What I love about Angular - you switch the project with completely different team/company - you'll see the same patterns, set of libraries and same solutions. Oh another point i love about Angular - migrations are mostly easy - don't have to struggle with the updates from version to version - in most of the cases simply run command to migrate

    • Oziel Perez
      Oziel PerezJan 13, 2025

      Bro, this is a React crowd, you're talking to a wall here. They don't get DI nor OOP 😂. But for the record, I agree.

      Vue is pretty close if you use either a well known UI library (PrimeVue, maybe Vuetify) or a well know library like Vee-Validate.

      Svelte sort of has a philosophy of getting back to using native HTML, native UI futures, etc. which is nice, but because of that, there's no first party form handling library. SuperForms is emerging as a contender for that framework though.

      • Ilya Gorenburg
        Ilya GorenburgJan 14, 2025

        I've played with Vue 2 before - it was great, to be honest! But at that time it didn't have forms package (nor built-in, nor 3rd party). Formulate was on the horizon, but was unstable. And then Vue 3 was announced and then released and migration was a pain for all (?) projects and libraries? But apart from that issue - i think Vue is great!

        I've used SvelteKit recently - I liked it (as to me, looks closer to Vue 2 (since i haven't tried Vue 3), than to any other library), but i'm not sure i would use it for some BIG (enterprise-grade) project

        • Oziel Perez
          Oziel PerezJan 14, 2025

          I mean yeah it really depends on what the requirements are. I suspect form-heavy features with elaborate validation rules. There's definitely a need for that in the Svelte world, SuperForms aside. I do also think that while SvelteKit is fantastic, the philosophy of sticking to native HTML and browser APIs may be cumbersome if you want 1st party components like select fields with custom option components, date pickers, and data tables.

    • Hryhorii Shkliaruk
      Hryhorii ShkliarukJan 14, 2025

      Because React it's library, Angular framework.

      • Ilya Gorenburg
        Ilya GorenburgJan 14, 2025

        I do understand the difference. But what percentage of all projects with React (as a library) are developed without any framework solution? I know it doesn't make sense to compare react with angular, but nextjs and angular is proper to compare. And i guess when many developers mention react - they mean some framework based on react

    • Scott Crossan
      Scott CrossanJan 17, 2025

      Does angular still use the nx attributes of html to bind things? That's what our me if originally

      • Ilya Gorenburg
        Ilya GorenburgJan 17, 2025

        you mean ng? yes, angular still use attributes to bind things, but not all of them are ng - it's rare now

    • Scott Crossan
      Scott CrossanJan 17, 2025

      The reason react doesn't have core packages was trying not to be too opinionated, light weight focus on the UI itself. Which seemed good at the time but feels like a it's something we could do with now they're are in 900 form libraries

      • Ilya Gorenburg
        Ilya GorenburgJan 17, 2025

        It's incorrect to compare react with angular in general. it's more about comparing nextjs (or any other framework based on react) and angular

    • Coach Ko
      Coach KoJun 12, 2025

      Dont go being so practical now. Leave some room to profess your technical prowess over the next developer with your knowledge of the latest hook and library.

  • Zach
    ZachJan 10, 2025

    This perfectly describes my experience. Learning react is too much about how not to use it. I instinctively started using SolidJS as soon as I found it. So far it feels pretty ergonomic. But it is shocking how accepting the web community is of bad tools and the bad engineering that follows. Coming from any other platform is shocking. It makes me think... You all live like this?

    • José Pablo Ramírez Vargas
      José Pablo Ramírez VargasJan 12, 2025

      Hehe, me too! For example, I cannot believe people are happy with dotenv. Like, come on! This is just a bunch of flat files and the concept of environment doesn't even exist in the browser. All is artificial.

      It's the same with React. It's slow, bad, confusing, and complex, and yet people still think it's the go-to library for UI development. Sheep mentality, I suppose.

      • Zach
        ZachJan 13, 2025

        I have learned professionally that most people will accept their circumstances and not worry about if things could be better. It drives me insane because people like you and me are the minority. In a work setting where you need people to get on board, we're considered complainers.

        As for dotenv, I don't have an issue with it. I find it to be a convenient setup if not abused, and some environments are building support for it in directly.

        • José Pablo Ramírez Vargas
          José Pablo Ramírez VargasJan 13, 2025

          Being a .Net developer, coming to know dotenv felt like a huge downgrade.

          • Zach
            ZachJan 13, 2025

            How so? I haven't had the opportunity to do much with .Net

  • Leonardo Volpatto
    Leonardo VolpattoJan 11, 2025

    That's why I still love the old and good Angular. Consistency and standards and patterns.

    • José Pablo Ramírez Vargas
      José Pablo Ramírez VargasJan 12, 2025

      Your "good" Angular is one of the worst performers of 2024.

      • Leonardo Volpatto
        Leonardo VolpattoJan 13, 2025

        I don't mind. It just works, it's not just an hype. At least when I need an enterprise application Angular is a good choice and it has been for the last decade. Convince me that I'm wrong.

        • José Pablo Ramírez Vargas
          José Pablo Ramírez VargasJan 13, 2025

          I feel bad for the people that depend on your judgement, like the users of the applications you make. Or maybe you don't call the shots? That would be ideal for their sake.

          • Leonardo Volpatto
            Leonardo VolpattoJan 13, 2025

            Hi José, thanks for sharing your concerns. Angular’s solid architecture, TypeScript integration, and official tooling make it a reliable choice for large-scale enterprise apps. While some benchmarks label it slower, in real-world scenarios it’s been robust, especially with ongoing improvements (like Ivy) and Google’s long-term support.

            I’d love to know more about the specific performance issues you’ve seen. Are they still common on today’s powerful (2025) hardware? Honestly, I can’t recall major performance troubles in a properly built front-end since I started using frameworks in 2013—even when I worked with React, Vue, or Svelte. Could you give me an example of something that performs poorly or uses excessive memory? Most issues I’ve witnessed were due to questionable coding practices rather than the framework itself, and a few tips usually solved them.

            • José Pablo Ramírez Vargas
              José Pablo Ramírez VargasJan 13, 2025

              Sure. This is a website that benchmark signal runtimes: github.com/transitive-bullshit/ts-...

              Angular signals are at least 7 times slower than the leader.

              Then we have Krausest benchmarking: krausest.github.io/js-framework-be...

              Angular can brag about being significantly better than React, but its overall position is not great for such "mature and stable" framework.

              • Leonardo Volpatto
                Leonardo VolpattoJan 13, 2025

                Hi José, Thanks for the links—always good to see fresh benchmarks. However, it’s important to remember that microbenchmarks (like signal runtimes) often don’t reflect the complexity of real-world, large-scale apps. Angular Signals, in particular, is still evolving, so I’d expect further optimizations in future releases.

                Angular is more than just performance on a tight loop; it’s a comprehensive framework—routing, forms, dependency injection, build tooling, etc.—all under one roof. That can be invaluable for enterprise applications that need consistency, maintainability, and a strong support system. Of course, if a project’s top priority is raw rendering speed and minimal overhead, a lighter framework or library might win on these tests. But in many production scenarios, Angular’s performance is more than sufficient, especially with modern hardware.

                I’d be really interested in any real-world examples where Angular’s performance proves insufficient, rather than just these micro-level tests. If you’ve encountered genuine bottlenecks in a full-scale application, I’d love to learn more about them. Ultimately, each framework has trade-offs—performance, community support, developer experience, and so forth—so the best choice often depends on the project’s needs and the team’s expertise.

                Thanks again for sharing! Let’s keep the conversation going if you have more details or specific cases to discuss. I really want to be convinced that performance is a big problem nowadays...

  • Attila Szombathelyi
    Attila SzombathelyiJan 11, 2025

    reactjs not a framework but library

    • Karega McCoy
      Karega McCoyJan 11, 2025

      React started as a library but it has evolved. It's the most extensible framework in use.

      • Attila Szombathelyi
        Attila SzombathelyiJan 11, 2025

        reactjs is a library that can be combined with other libraries. i. e: Angular is a framework.

    • hesxenon
      hesxenonJan 12, 2025

      since "no one" knows how to set it up as such anymore (see reacts own getting started guides and all the react bootstrapping tools) this is splitting hairs at this point. For all intents and purposes react has become a framework because nearly no one uses the actual library on its own - hence the article.

      • José Pablo Ramírez Vargas
        José Pablo Ramírez VargasJan 12, 2025

        If I run npm create vite@latest and choose React, I get React and just React, therefore a library setup.

        • hesxenon
          hesxenonJan 14, 2025

          Ah, so dev servers and transformations to enable HMR are not qualifications for frameworks? Do you even know what the build target is by default?

          Also, your deduction is wrong. Just because you use one bootstrapping tool that installs "only" react doesn't mean that every react project uses "just react". It might be a "library setup" but it doesn't stay like that (99% of the time)

          • José Pablo Ramírez Vargas
            José Pablo Ramírez VargasJan 14, 2025

            No because they are provided by Vite. Is React distributing Vite now? No.

            • José Pablo Ramírez Vargas
              José Pablo Ramírez VargasJan 14, 2025

              Also your line or reasoning states that anything that uses "something else" is no longer a library. Are you certain that this is an acceptable definition? By this definition, everything is a framework, nothing is a library. I don't think anybody would agree with this.

              • José Pablo Ramírez Vargas
                José Pablo Ramírez VargasJan 14, 2025

                So many mistakes. You're also implying that anything that requires a server is no longer a library. Come on.

                The useful definition of a library is not what you're trying to push here. It is a library if it is functional as-is. In contrast, say Svelte, where compilation is necessasry, is a framework.

                • hesxenon
                  hesxenonJan 17, 2025

                  How do you think HMR works? It has to integrate with react, so what's being sent over the wire is not exactly what you write.

                  • hesxenon
                    hesxenonJan 17, 2025

                    I'm sorry if it came across this way. My intention was to say "when people say 'react' they don't mean 'react the rendering library'. They mean 'react and it's bootstrapping tools and it's ecosystem and every other library that is commonly used with react'". If you use react simply to associate state to components and you use (or fully understand) your own build chain (e.g. typescript ONLY, yes that's possible) then fine.

                    But saying that react is a library in general is about as accurate as saying that a human being is just a biped with advanced neuronal patterns and some guts.

                    • José Pablo Ramírez Vargas
                      José Pablo Ramírez VargasJan 17, 2025

                      HMR is provided by Vite and is non-essential for React to work. You're thinking that because we add Vite on top of React all of the sudden React is a framework, not a library. Why? React remains a library, and HMR is a Vite thing.

                      What might be a framework is the combination of Vite + React, but don't throw the "React" name there. Use a new name so this confusion stops.

    • Khang
      KhangJan 12, 2025

      It's 2025 and we still see this comment 🤷‍♂️

  • Karega McCoy
    Karega McCoyJan 11, 2025

    I really dislike these types of articles because they exhibit a lack of experience. I've worked with frontend technologies for almost 20 years. Scriptaculous, MooTools, jQuery, Dojo, Backbone, Angular, Polymer, React, and many more. Using a framework in an enterprise environment means that it has to be stable and well supported.

    • david duymelinck
      david duymelinckJan 12, 2025

      Oh where are the times of Scriptaculous, MooTools and Dojo.

      I went more into backend development around the time Angular and React popped up. But I still follow the frontend changes, because I feel as a web developer you need to know the full stack to get to the best experience for developers and end users.

      I'm amazed at how much code we were willing to let the user load in their browser, when we didn't get punished by search engines.
      I think with the new wave of backend javascript frameworks and the html-first idea, developers are back on track about the purpose of javascript. In my opinion javascript in the browser is only there to enhance the application.
      I think it is crazy html-first and island architecture are terms they had to invent to get people onboard with the new javascript solutions. This is how we did progressive enhancement when there were barely any frameworks or libraries.

      I agree that in any company stability and support are a big factor when picking software solutions. But who says those new frameworks don't meet that threshold?

      • CitronBrick
        CitronBrickJan 12, 2025

        Scriptaculous & MooTools. It's been years since I heard of those.

    • José Pablo Ramírez Vargas
      José Pablo Ramírez VargasJan 12, 2025

      What if the framework of your choosing complies with all these, but only because there was nothing better before? What if, for years, that framework had no decent competition? What if that had already changed?

      I work for Intel. They have a list of approved and banned technologies. Still, they are open to new things. I got approval for Svelte after a very convincing presentation I made where I pretty much destroyed React.

      • Ilya Gorenburg
        Ilya GorenburgJan 14, 2025

        Please share the details of that presentation. I need to destroy Nextjs in favour of Angular 😆

  • Laksh Meghani
    Laksh MeghaniJan 12, 2025

    Probably someday a framework or library will come changing the current style of writing code and react will be declared old. But currently, the framwork is very popular!

  • MFM-347
    MFM-347Jan 12, 2025

    I totally agree with your points on React! That's the reason why I chose to switch from react to Vue—it’s simple, easy to learn, and very readable. Despite its simplicity, Vue still offers the features and flexibility needed for professional development. It’s a great balance of being beginner-friendly while also powerful enough for larger projects.

    • Denys Bochko
      Denys BochkoJan 15, 2025

      I find Vue much simpler than React. At first I thought the main difference for me was the structure of the file with vue having clear template and logic, with react lucking it, but then it kind of blurred as there is still that "return" statement that makes your template.

      I was surprised when I learned a video hosting company using it for their front end.
      Even though I am primarily a back end engineer, getting my hands dirty with FE was a pretty good idea. The amount of frameworks on the market provides a good pool to choose from. Going to check SolidJs next, it's been suggested here.

      New tech is always good, so we are not sitting duck and of course each library and framework will have followers that don't like the other frameworks. :)

  • Md Mohosin Ali Shah
    Md Mohosin Ali ShahJan 12, 2025

    Great write-up! I’ve been exploring Vue and Angular recently, and I agree with your points about React’s ecosystem fatigue. These alternatives feel more structured and less overwhelming to get started with. Do you think frameworks like Svelte or SolidJS will outpace React in enterprise-level adoption, or are they still better for smaller projects?

    • José Pablo Ramírez Vargas
      José Pablo Ramírez VargasJan 12, 2025

      "Still better for smaller projects" is an unfounded myth. I use Svelte for a big project. Angular is objectively a bad choice because it shares many of React's downsides. Your best bets, IMHO, are Vue, Svelte and SolidJS.

      • hoangvutruong513
        hoangvutruong513Jan 14, 2025

        I'm curious. Do you mind sharing how Angular has many of React downsides?

        Angular does not use VDOM, does not depend on Hooks to inform re-rendering and reconcilliation like React.

        In fact Angular components are only rendered once and subsequently updated by either Zonejs or pure signals (if you don't use Zonejs) which is much more performant. In fact, modern Angular app is more similar to Svelte/Solid because all of them use signals, as compared to React.

        Angular has built-in dependency injection from the start while in React it was an afterthought with useContext and Provider.

        Angular has built-in forms, routers, animations, form validator, httpClient, interceptors, etc. React has none and depends on a bunch of unregulated 3rd party dependencies trying to break your package-lock file.

        • José Pablo Ramírez Vargas
          José Pablo Ramírez VargasJan 14, 2025

          I'm not an Angular developer. I have only glanced at it. Angular performs better than react, but it is nothing too impressive in the overall arena. Angular is, undoubtedly, more complex than React, and that's saying a lot because React is already complex.

          Then signals: Angular signals are at least 7 times slower than Svelte signals.

  • Friday candour
    Friday candourJan 12, 2025

    If you are tired with react then I suggest you try out Cradova, a new kind of steroids

    github.com/Uiedbook/cradova

    Note: created by me still maintained after 4 years of development.

    Built many apps and sites on it.

  • Jeff Edsell
    Jeff EdsellJan 12, 2025

    I'm job hunting, and it does seem like the ubiquity of React.js is a curse as much as a blessing. Lots of jobs I'm qualified for...but so are thousands of other applicants.

    I wish I could take a course in Svelte and look for Svelte jobs - but a course won't cut it when employers are looking for on-the-job experience.

  • 🅖🅡🅔🅖🅞🅡🅨 🅞🅡🅣🅞🅝
    🅖🅡🅔🅖🅞🅡🅨 🅞🅡🅣🅞🅝Jan 12, 2025

    Why the hell is Vue not in this conversation as an alternative. It’s bizarre

    • Stasi Vladimirov
      Stasi VladimirovJan 13, 2025

      It’s such an obvious choice that most people are just blind to it. None of the issues mentioned in this article, nor the comments is present with Vue. Given the choice I would pick Vue any day, any time, it’s not even close. I have tons of professional experience with React and Angular and I’ve done some explorations with Svelte, Solid and HTMLX. Neither of these is even comparable to Vue in terms of DevEx. Just look at the most popular/successful tools in the past 2 years: Vite, Vitest, VuePress… All of these come from the same ecosystem. People are just blind to the obvious. Can’t think of other answer to your question…

  • Ravavyr
    RavavyrJan 12, 2025

    This entire set of comments alone is enough to keep me away from JS frameworks.
    You guys seriously have way too many words for the exact same things.

    Do we really need a dozen ways to say "render", "api call", "include" ?

    Meh, don't get me wrong, JS is absolutely the best way to do a nice interactive frontend.
    I'm no "we should just use HTML" guy. I get it, been coding a long time to know better, been coding frontend AND backend and doing SEO stuff and DNS stuff and Email stuff, and so on.

    JS interfaces are great. The frameworks are bloated pieces of crap because we let hardcore backend engineers [remember, facebook and google started these things] dictate how the frontend should work, that's why you guys need compilers and linters and a billion things installed to even run a basic page when any frontend dev knows you could just write JS and some flat html and css to accomplish the same [with a few dynamic endpoints]

    Anywho, my 2 cents.

    • Luqman Shaban
      Luqman ShabanJan 13, 2025

      I couldn’t agree more! Most of the front end applications out there would do just fine with vanilla js and flat html & css, but they choose to use frameworks just for the sake of it.

      • Abdullah Miraz
        Abdullah MirazJan 14, 2025

        So, you say all these data handling and packages that makes developers life easier are useless? Example: framer motion. How much time will it take a developer to build that exact same app in html, css , js, rather than using any framework?

  • Thomi Jasir
    Thomi JasirJan 13, 2025

    Same thought, bro. Now I'm slowly shifting to SolidJS, React is just for office-related work.

    • Sanjeev Sharma
      Sanjeev SharmaJan 13, 2025

      How has your experience been with SolidJS? I am thinking of using it for a side project.

  • CompileConnected
    CompileConnectedJan 13, 2025

    Everytime I saw this title, you will be back to react soon.

  • Shivam Meena
    Shivam MeenaJan 13, 2025

    I used to be a backend developer. In 2020, I was working with a company and started with angular and what i hated most is NgModules declaration for a new frontend dev this is pure illogical import statement i have seen, first import the component provide it to @NgModules do the declaration, imports, providers etc. Also the file structure dir/component.css, dir/component.html, dir/component.ts. You can write three things in one when you write in basic component.html.

    Afterwards this I started using svelte in 2021(Self learnt) and at that time few companies were using but that was not the case for India but I still took the risk and learnt the basic structure and working with that i started doing small project (Fun project to solve my own issues and day to day management of finance as per my requirement). At this same time sveltekit was in alpha release Idk but i started using it. I was hired by a startup in India which game me freedom to choose a framework for an internal project and I used sveltekit and it still runs in production with:

    I didn't feel the requirement of multiple packages or anything extra, did face some issues with complex reactive states but I think they are fixed in v5. Now I'm working with another start up based in Paris and they approached me first because of my svelte and sveltekit work. I'm currently working with them and till now when it comes to libraries I haven't faced any issues because every package written in JS and meant to be used in browser works perfectly in svelte. With this trend I can say companies going to adapt svelte a lot and same goes for Vue which can be seen in State of JS 2024.

    Svelte is being is in a lot of new project within top companies Apple Music is one of those examples. People sees that react is being is used height reason 10 year ago there were only two backed frameworks/library Angular and React, for obvious reasons they started using them and when you start using a frameworks/library you wanna stick to that which is easy for a company and they can ask a dev to switch between projects if required. Same thing is going to happen in next 10 years new startups uses new frameworks/library like svelte, solid(I haven't used it in production but solves the complexity introduced by React. Also they introduced Signals to JS frameworks - after knockout), Vue.

    In recent time angular did make lots of changes. I hope they are good, I'm not switching to any frameworks/library.

    I heard lots of good things about react compiler too. Haven't used so no comments.

    Things I love about Svelte:

    1. Easy to understand and write a svelte component (One file component) - script, style, html.
    2. Reactivity model is good and now it's much better with v5.
    3. Best for beginners - I vouch for that. If you are starting to use a new frameworks/library best way to do it.
    4. Sveltekit is good but I wanna see more development here. You guys can add more points.

    You can check svelte project that I have stared over the period: github.com/theetherGit?tab=stars

    • Ilya Gorenburg
      Ilya GorenburgJan 14, 2025

      I was working with a company and started with angular and what i hated most is NgModules declaration for a new frontend dev this is pure illogical import statement i have seen, first import the component provide it to @NgModules do the declaration, imports, providers etc.

      It's there for a reason: dependency injection. If you build big applications - you'll love it...

      ...Angular v19 is out and how it's using standalone components, so you can start writing the components without all those params. You can only add those when you really need it

      • Shivam Meena
        Shivam MeenaJan 15, 2025

        It's there for a reason: dependency injection. If you build big applications - you'll love it...

        Do we need that much of complexity for starting a project? I agree big project needs it for specific use-case.

        Angular v19 is out and how it's using standalone components, so you can start writing the components without all those params. You can only add those when you really need it

        Great, But now I'm gonna stick with svelte.

        • Ilya Gorenburg
          Ilya GorenburgJan 15, 2025

          Do we need that much of complexity for starting a project? I agree big project needs it for specific use-case.

          You just answered your own question. When you start a big project - you need all those tools so you can easily scale it. If you start working on your personal blog - you choose Svelte, Astro or similar

  • Imafidon Erhahon
    Imafidon ErhahonJan 13, 2025

    I use Formik and Yup schema for form validation
    It's simple and easy to use

  • Rense Bakker
    Rense BakkerJan 13, 2025

    Agree that the community has become fragmented and that will get worse. Because most apps built with React do not need good performance, a large crowd of people have become stuck on a path that leads nowhere. This has led to the development of the React compiler in React 19. This will further facilitate this split in the community. Other frameworks like Svelte have embraced zero-performance-concern from the start. That might seem cool, but ultimately leads to terrible developers who no longer realize that they're writing JavaScript code with terrible performance, because the compiler will fix it for them.

    SolidJS is cool though, I might switch to that once the React compiler blows up in everyone's face.

    • Gianfranco Di Domenico
      Gianfranco Di DomenicoJan 14, 2025

      That's exactly what assembly and perforated cards programmers thought when what we today call "low level programming languages" came out. Look where we are now.

      The purpose of new technologies should be to build better stuff in less time. If Svelte compiler will optimize stuff for me, I don't see what's wrong with that. Programming in 2025 is not showing off about who writes the best or fastest algorithm. You have leetcode for that.

      • Rense Bakker
        Rense BakkerJan 14, 2025

        Just because things change, doesn't mean you should ignore everything that happened in the past.

        Solely relying on the compiler to optimize your code, that's full of business logic and completely losing the skill to spot possible performance issues that could be caused by your code, is not a good idea imho.

        • Gianfranco Di Domenico
          Gianfranco Di DomenicoJan 14, 2025

          As it happens with compiled languages, it then becomes a compiler issue.

          Being able to write complex logic relying on a compiler optimizing stuff for you is not a bad thing, it's something we should wish for. This is the value proposition of high-level languages. Knowing what happens under the hood is valuable, but focusing on high-level stuff without having to track every single variable it's empowering.

          Only a few applications actually benefit from microsecond-level optimizations. But many of them would benefit from reduced development time!

          • Rense Bakker
            Rense BakkerJan 15, 2025

            Knowing that there is a difference between a reference and a value in the javascript language is essential. The React compiler is not going to fix that, it just abstracts the React part into a blackbox, so you forget about those values you keep recreating on every render. The same goes for Svelte and other web frameworks that do magic using a compiler. You are no longer writing Javascript, you are writing React or Svelte.

            Your development time argument is nonsense. Adding a useMemo or useCallback takes what? 2 seconds? No React application was delayed because of that. The problem was that people were advocating AGAINST using those hooks, which has spawned millions of terribly performing React applications.

            • Gianfranco Di Domenico
              Gianfranco Di DomenicoJan 15, 2025

              And what's exactly wrong with writing Svelte or React? There are engineers out there working to make the experience with Svelte better because of their work on the compiler. I can benefit from their work and effort, knowing that the code the compiler spits out is most probably better than any code I could ever produce.

              That's not true that you need to know that difference, trust me. Lots of application have been written by people knowing nothing of the underlying, and some of them work just flawlessly. It's an added value, but it's not a must have in a lot of cases.

              It's just nonsense that you present an example against Svelte using React's useMemo and useCallback. It could take you two seconds to write them down, but for anyone else working on your code it adds up on the developer time to figure out why they are there and fix any bug related to improper usage.

              And note, I'm not stating that Svelte is better. But call out a framework because it compiles your code it's a nearly perfect parallel with calling out high level languages because you have no complete control on program and memory flow. Again, not every application needs to save a few milliseconds, especially if that costs you hundreds of thousands in developers time.

              • Rense Bakker
                Rense BakkerJan 16, 2025

                It's a problem when React or Svelte eventually die and new JavaScript frameworks take over. Now you have zero transferrable skills, it will be like learning a completely new language.

                • Gianfranco Di Domenico
                  Gianfranco Di DomenicoJan 16, 2025

                  Yes, sure, but you're assuming that anyone using frameworks does not know the fundamentals.

                  You can be proficient in JS and also exploit the convenience of a framework.

                  • Rense Bakker
                    Rense BakkerJan 19, 2025

                    The fact the react compiler became a necessity after people refused to memoize the state that would cause their components to constantly rerender seems like a good indicator that a lot of people don't understand the fundamental difference between a reference and a value yes.

  • Mx w
    Mx wJan 13, 2025

    Your frustration is my frustration. I’m so aggravated and can’t take it anymore.

    I blinked and my app was ancient.

    I had react 18.30 and now it’s 19. My MUI version is now deprecated and I only installed it 6 months ago.
    Same with file saver , react router dom, docxtemplater and ag grid.

    It’s impossible to keep up.

    I’m out here working hard to make great applications meanwhile some bored devs somewhere who have nothing to do with there lives spend there time making sons new hooks and forcing me re learn all documentation I learned already and break my app

  • Riya
    RiyaJan 13, 2025

    This post really hits home! React’s growing complexity and ecosystem fatigue are so real. Svelte and SolidJS sound like a refreshing change—what’s your top advice for someone making the switch? Excited to dive in!

  • Joe
    JoeJan 13, 2025

    I myself have learned to dislike React for many reasons (and still often use class components as a result), but the reasons given here are honestly moronic. Your #1 complaint is it has too many convenience libraries?

    The rest of us have this secret formula called DON'T INSTALL WHAT YOU DON'T WANT. You do realise don't need a CSS library for React, right? You can use good old CSS files or declare styles variables (yes, without a library). You know you don't need a bundler, right? Stop using 30MB+ libraries like Material and your app size drops to below 100kb WITHOUT bundlers, and without chunking. You don't need React Router, I have both made my own solutions and used React Router; which path I choose depends on my use-case. You don't need.... fuck this, I give up.

    Yes, totally, abandon a library because it has many options, not because it deviates from its own standards, ignores its dev community, completely misses the plot on what it's supposed to be, and outright betrays its own use-cases. No, let's leave it because it has plenty of support. This is the last ape-grade IQ dev.to article for me, I'm banning this shit from my news feeds.

  • Anon
    AnonJan 13, 2025

    Liveview

  • khi195
    khi195Jan 13, 2025

    In the UK can't find a single solidJS job, even though I think it's a great framework. Svelte has a bit more up-take, but still not enough jobs..

    • Clive Portman
      Clive PortmanJan 14, 2025

      I've deffo seen some in the Cambridge area.

  • Leonardo Volpatto
    Leonardo VolpattoJan 13, 2025

    @holasoymalva ! Great article—really enjoyed reading your perspective. I can relate to the feeling of “ecosystem fatigue” and the desire for simpler, more modern options. I’m personally a fan of Angular for large-scale, enterprise settings, because it provides an all-in-one solution (routing, forms, DI, etc.) and a solid structure for teams. That said, there’s no “one size fits all” in web development.
    Every framework—React, Angular, Vue, Svelte, Solid, Qwik—has unique strengths and trade-offs and i think that good engineers don’t limit themselves to a single tool; they learn to pick the best fit for each project and use it effectively. Whether you prefer React for its community, Svelte for its simplicity, or Angular for its opinionated approach, what really matters is solving the problem well and maintaining a clean, efficient codebase.

    So, while React may no longer be your personal favorite, it’s still a great solution in many cases. In the end, the smart move is knowing the pros, cons, and use cases of each option—and having the curiosity to explore new ones. After all, good engineering is about choosing (and using) the right tool for the job.

  • Oren Farhi
    Oren FarhiJan 13, 2025

    I was thinking similarly a year ago
    orizens.com/blog/why-i-chose-astro...
    I think astro is innovative and still offers some familiarity to what I've used to work with while let you try new and fresh frameworks.
    However, i see React is evolving abd interesting to see how the community will embrace it.

  • SkillBoostTrainer
    SkillBoostTrainerJan 13, 2025

    Really interesting ! I’ve felt the same about React lately—it’s just gotten so complex and tiring to work with. I’m curious about Svelte and SolidJS now; they sound like a much-needed change of pace. Thanks for sharing your experience

  • Fred Lunjevich
    Fred LunjevichJan 13, 2025

    I hear ya — I too have React burnout. I guess whether to double down on React or leave it depends on where you are as a dev. For novice and junior devs, I expect they'll need solid React knowledge in order to get work. Myself, I like the look of Svelte and will focus on that a bit this year. I feel that spending too much time in React land is actually making me a worse developer. Time to go make a todo app with Svelte guess!

  • Abdullah Miraz
    Abdullah MirazJan 13, 2025

    Dammnn !! Haven't read this good article and discussions for a long time. Super cool article with cool people chatting in the comments, feels so alive to me. Learned a lot . Thanks

  • Fabio Rotondo
    Fabio RotondoJan 13, 2025

    I've been a fanatic React and then next.js developer since 2018, but as the author, I went away from the framework about 2 years ago and devoted myself to Svelte only. I even contributed some PRs for Svelte5 while it was in early development. I don't regret my choice, and I don't want to go back to React.
    I like Svelte because it just adds some concepts to standard HTML and CSS, so the learning curve is really low.
    Also the compiler is pretty neat and produces great, fast and small code.

    I had a look at Solid and Qwik, but I found Svelte to be much more close to my idea of reactive framework.

  • Oziel Perez
    Oziel PerezJan 13, 2025

    Thank you. It's time to ditch React in favor of productive frameworks!

  • Maksim Kachurin
    Maksim KachurinJan 14, 2025

    You have to try Riot.js guys. Nothing could be more clean and simple than that

  • the_aceix
    the_aceixJan 14, 2025

    You should check out Vue too

  • Lê Bình An
    Lê Bình AnJan 14, 2025

    This is exactly how I feel recently. I missed the time when building application in React is faster, easier and more enjoyable than 500 lines of jQuery. But now, it become redundant itself, I can’t even count how many days have I ask my self in frustrated: “why do I have to all of this just to toggle this select box?”, “why changing just one character in the input takes so much time to handle correctly?”. To be honest, I want to switch to something else, but that not what the current market want, they demands stable developers who do what every other people do, and anyone can maintain it. So I guess that I will still stuck here for a while.

  • Martins
    MartinsJan 14, 2025

    You should give Nuxt a try, they place huge emphasis on developer experience. its really good

  • NILESH AGARWAL
    NILESH AGARWALJan 14, 2025

    How about angular now?

  • leob
    leobJan 14, 2025

    Very well articulated ... React is okay, and I use it when I "have to" or when it makes sense - but it's not my favorite, for the same reasons as you've explained so well ...

    I've always been a Vue fan, but I'm sure Svelte and Solid are great as well !

  • Paul-Sebastian Manole
    Paul-Sebastian ManoleJan 14, 2025

    The alternatives also have drawbacks, sometimes major ones, and tons of quirks. You just have to use them for a few years to find them. In the meantime React will continue to evolve and simplify while having the largest ecosystem. The grass isn't always greener on the other side.

  • Paul / Appurist
    Paul / AppuristJan 14, 2025

    You nailed it 100%. I really don't understand why people use React anymore, if they have a choice. I think it might just be the vicious popularity feedback loop, that doesn't allow them to look around at (so many) better alternatives. I rarely see a post that I agree with 100% front to back, but this is one. SolidJS is my favorite, although SolidStart was a bit rough for me (when I tried it quite some time ago). I loved Svelte as well, but one of my first loves was Vue and it has reached the point where it's been through some painful changes but is better now on the other side. And very popular so you're still going with the mainstream with it. I have projects in Solid, Svelte, Astro and now back to Vue, all of which are a breath of fresh air after the pain of React. I called Solid "React without the weird quirks and pains".

    For static site generation, e.g. for websites and blogs, also take a look at Nue.js, which is a rethink of the whole ecosystem. See also Nue 1.0 (RC) — Can it outshine Next.js? for a comparison.

  • Jaime Chung
    Jaime ChungJan 15, 2025

    I preffer angular million of time

  • Erick Paquin
    Erick PaquinJan 15, 2025

    It's true that I'm an old geezer when it comes to the web (since 1998) but I still find nothing wrong with basic vanilla stuff. I just completed a new site last month and all I used was HTML, JS, CSS and a little bit of PHP and HTMX for good measure, no DB's in my case either, even if the site is static-ish..

    Site is easy to maintain, not overbloated and super fast.

    No pre-processors or build tools, nothing, very simple. Easy to update and backup.

    All these frameworks are making me uneasy, especially because they try to re-invent each other every few years, all in the name of trying to ship quality code faster...nah, I'll stick to my vanilla ice-cream. Nothing to re-invent, always the same stuff to get used to, which does make me faster and faster each time and gives me some time to have a life in between..

    Just my 2 cents mind you, works for me.

  • Chris Brown (The Musing Cogitator)
    Chris Brown (The Musing Cogitator)Jan 15, 2025

    I just use good old fashion JavaScript, hadn't problem with it yet.

  • ygopensource
    ygopensourceJan 15, 2025

    You need Angular.

    This is based on the problems you encountered.

    SolidJS svelte could be another alternative but even for small projects Angular gets you situated.

    React otoh ecosystem is fragile.

  • Documendous
    DocumendousJan 16, 2025

    I've been saying this now for a few years. In fact, I would get away from any Javascript framework bigger than Alpine JS or HTMX.

  • Jesse Reese
    Jesse ReeseJan 17, 2025

    Angular is the way (In my opinion)

  • Kishore Kumar .v
    Kishore Kumar .vJan 17, 2025

    How do I know all this frameworks available in Market, how can I keep myself up to date.

  • Raju Dandigam
    Raju DandigamApr 15, 2025

    Interesting to see a different perspective.

  • Chima Daniel
    Chima DanielMay 14, 2025

    I habe been on jamstack for years, refused to pickup a frmaework due to laziness to learn somethinh new because i was very satisfied with the expressJs and reusable component capability of Ejs template engine

Add comment