are going to be able to challenge React, as the predominant solution for anything web related.
I think this may actually be a cultural/industry issue rather than a technical one.
My jaw dropped when I first ran across this on the Thoughtworks Technology Radar SPA by default Hold:
"We generally avoid putting blips in Hold when we consider that advice too obvious, including blindly following an architectural style without paying attention to trade-offs … Too often, though, we don't see teams making that trade-off analysis, blindly accepting the complexity of SPAs by default even when the business needs don't justify it. Indeed, we've started to notice that many newer developers aren't even aware of an alternative approach, as they've spent their entire career in a framework like React."
i.e. at least even the perception is now bad enough for TW to call it out to their clients (2021 was the first year where React surpassed jQuery in the Stack Overflow Developer Survey as the most used web framework).
Despite of the associated complexity somehow the available tooling has created a "developer comfort zone" (which is ironic because of the continued complaints of how complex everything has become) that potential detrimental effects downstream on the end product are usually ignored (or even denied).
On the surface the SPA-preference can be explained by trying to compete with native applications (in the long run competing on native application's terms is a losing proposition).
The problem: web performance is other people:
"I believe this is why Kroger.com used a SPA in the first place — if disparate teams’ APIs can’t be trusted, at least they won’t affect other teams’ code."
This suggests that SPAs may be (ab)used to keep organizational issues at bay. And perhaps the complexity leads to teams that are larger—possibly large enough that individuals can specialize fairly narrowly where they don't think about any trade-offs that don't affect them directly. Objective analyses of the drawbacks of SPAs aren't nearly as common as the declarations of perceived DX and productivity benefits that SPA frameworks can bring.
The fact that some people seem to treat React as (the future of) the web is more than a bit disconcerting. React's design goal is to enable reuse over the React Web/React Native divide—so React is about React, not the web.
There is no inherent incentive to align with the realities of the web unless it directly benefits React and doesn't interfere with the "Native" end. React's "re-implementing the browser" could be explained by the "Native" end needing whatever is being re-implemented.
To some degree even the Thoughtworks commentary isn't helpful:
"SPAs incur complexity that simply doesn't exist with traditional server-based websites … We believe that many websites will benefit from the simplicity of server-side logic, and we're encouraged"
While Marko, Astro, and Qwik are server-first solutions they are by no means traditional, trying to "go back to the old days". They do not eliminate the need for SPAs where they are appropriate but instead offer an "optimized for the web" alternative for a wide range of applications where SPAs can be an ill fit (or difficult/high effort to get right).
So it's not really about "Marko, Solid, Svelte etc. challenging React" but getting the industry and individual developers to realize that SPAs aren't the one-size-fits-all tool they clearly want them to be and that using them as a golden hammer isn't going to be helpful in the long run.
The educational discussion has been slowly gaining momentum over the past few years but the fact that there is a significant "developer comfort zone" attached to the SPA/React ecosystem means that it is going to take more time and effort.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think this may actually be a cultural/industry issue rather than a technical one.
My jaw dropped when I first ran across this on the Thoughtworks Technology Radar SPA by default Hold:
"We generally avoid putting blips in Hold when we consider that advice too obvious, including blindly following an architectural style without paying attention to trade-offs … Too often, though, we don't see teams making that trade-off analysis, blindly accepting the complexity of SPAs by default even when the business needs don't justify it. Indeed, we've started to notice that many newer developers aren't even aware of an alternative approach, as they've spent their entire career in a framework like React."
i.e. at least even the perception is now bad enough for TW to call it out to their clients (2021 was the first year where React surpassed jQuery in the Stack Overflow Developer Survey as the most used web framework).
Despite of the associated complexity somehow the available tooling has created a "developer comfort zone" (which is ironic because of the continued complaints of how complex everything has become) that potential detrimental effects downstream on the end product are usually ignored (or even denied).
On the surface the SPA-preference can be explained by trying to compete with native applications (in the long run competing on native application's terms is a losing proposition).
The problem: web performance is other people:
"I believe this is why Kroger.com used a SPA in the first place — if disparate teams’ APIs can’t be trusted, at least they won’t affect other teams’ code."
This suggests that SPAs may be (ab)used to keep organizational issues at bay. And perhaps the complexity leads to teams that are larger—possibly large enough that individuals can specialize fairly narrowly where they don't think about any trade-offs that don't affect them directly. Objective analyses of the drawbacks of SPAs aren't nearly as common as the declarations of perceived DX and productivity benefits that SPA frameworks can bring.
The fact that some people seem to treat React as (the future of) the web is more than a bit disconcerting. React's design goal is to enable reuse over the React Web/React Native divide—so React is about React, not the web.
There is no inherent incentive to align with the realities of the web unless it directly benefits React and doesn't interfere with the "Native" end. React's "re-implementing the browser" could be explained by the "Native" end needing whatever is being re-implemented.
To some degree even the Thoughtworks commentary isn't helpful:
"SPAs incur complexity that simply doesn't exist with traditional server-based websites … We believe that many websites will benefit from the simplicity of server-side logic, and we're encouraged"
While Marko, Astro, and Qwik are server-first solutions they are by no means traditional, trying to "go back to the old days". They do not eliminate the need for SPAs where they are appropriate but instead offer an "optimized for the web" alternative for a wide range of applications where SPAs can be an ill fit (or difficult/high effort to get right).
So it's not really about "Marko, Solid, Svelte etc. challenging React" but getting the industry and individual developers to realize that SPAs aren't the one-size-fits-all tool they clearly want them to be and that using them as a golden hammer isn't going to be helpful in the long run.
The educational discussion has been slowly gaining momentum over the past few years but the fact that there is a significant "developer comfort zone" attached to the SPA/React ecosystem means that it is going to take more time and effort.