it doesn't matter how many links to random posts or screenshots/embeds of external platforms you add in your comments.
There is nothing random about those links. Granted they are going to reflect my own bias but I also regularly post links to content I don't agree with inviting the reader to make up their own mind; to carefully scrutinize the information they are presented with, regardless of source and that includes everything that I state.
JSX is almost HTML
"JSX is an XML-like syntax extension to ECMAScript without any defined semantics."
It transforms to JavaScript.
In React that JavaScript creates ReactNodes, in SolidJS it creates DOM elements.
The only time HTML is the result is during SSR.
JSX elements represent components in the component tree which relates to but isn't identical to the DOM tree.
And in React Native there isn't even a DOM much less HTML.
JSX is also a standard.
Neither is a W3C standard. The point was that Svelte's approach to templating is just as "legitimate" as JSX.
When you use React you use JavaScript the entire time.
Again what is the point of this statement?
On the one hand you accept JSX as a useful DSL but on the other hand you want "just JavaScript". From that perspective a Vue SFC is as much "just JavaScript" as a React component with JSX.
and it doesn't matter because React are a bunch of functions, nothing else.
Ultimately that is true for all the other frameworks as well. And Meta is continuing to experiment with compilers.
tried Svelte when in december 2016 and Svelte 2
It has changed a lot since then.
The first one is a clear FP approach to render UI components.
Again that's a fallacy. The React community calls them Function-al components. Even the React documentation calls them Function components. React leverages immutability to it's own ends and function components, render functions, that access hooks are impure from the FP perspective.
What React gives you is "declarative UI", i.e. you don't have to constantly, imperatively fiddle with DOM elements.
easy to understand (from my PoV).
People always find matters they are familiar with easy to understand.
i.e. it's fairly easy to find testimonies that React is anything but straightforward; so it's not as cut-and-dried as you portray it.
You can handle the rest as you wish (or as your project needs).
As long as it aligns with the React community consensus; React dictates a certain architecture therefore it has a distinct opinion which in itself isn't necessarily a bad thing until such time that the particular constraints it sets actually get in the way.
"What is clear: right now, if you’re using a framework to build your site, you’re making a trade-off in terms of initial performance—even in the best of scenarios."
So I guess you'll be getting on that PHP gravy train, right? It's the most prevalent …
HTML Islands?
You really need to read things more carefully and not just see what you want to see.
"HTML Islands" doesn't occur anywhere in that article. It's Islands Architecture and a counter point to your claim of the false "site vs. app" dichotomy. There's a whole range of options in between. In fact enterprise consultancies are now starting to warn their clients about the SPA by default approach:
"the sheer prevalence of teams choosing a single-page application (SPA) by default when they need a website has us concerned that people aren't even recognizing SPAs as an architectural style to begin with, instead immediately jumping into framework selection. SPAs incur complexity that simply doesn't exist with traditional server-based websites"
If you want to work, you'll learn things that people uses.
Sure but it doesn't mean you have to settle.
good luck finding someone for the job.
The title for this article is "Getting ready for my first website: Choosing the right platform".
Web site, not app.
Nothing about being constrained to job requirements; maximum freedom of choice. People will often change the platform for their own site like for example Jekyll, to 11ty, to Astro, etc. If all you want is some pages use Github pages; something a bit more fancy Wix, Webflow, SquareSpace etc., whatever.
Moreover if a new learner starts with svelte he/she will learn it's specific syntax that nothing has to do with "the platform" in it's standards, which is not the case with React.
The extensions you need to adopt when working with Svelte are minor compared to the concepts that you have to assimilate with React. React introduced hooks in early 2019 and people are still complaining about them (and lets not forget the continued moaning about React 18; for example useEffect and useEvent).
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
There are of course a big bunch of different opinions, specially on a tech that has >15million daily downloads.
Either way and just because it has >15million daily downloads it's the go-to unless learning has not the purpose of finding a job afterwards.
In fact enterprise consultancies are now starting to warn their clients about the SPA by default approach
The question is simple. Do you need SEO?
NO -> SPA (mostly)
YES -> SSR/SSG, being SPA or not.
Is it a website? You'll be fine witj just HTML and CSS with few grains of JS.
This is applicable to the major part of cases currently.
Both SPA and classic SSR have its nuances and complexities. It was easier to develop with good Ol'SSR but it's also much harder to maintain.
Maintenance being a top cost for companies and us providing solutions come first to find "best practices", "rulesets" like SOLID and DRY, leading the industry to code separate backends. Guides arose to transform a monolithic application into services then into microservices where it suits.
Having the front-end attached to a backend leads you to few maneuver ability. i.e. you're using Smarty template engine inside a PHP backend and you see the need of complex computational tasks on new features that business needs. You may want to code this "service" in Java, Go or any other language that's capable of it efficiently. But Smarty works on PHP. So you've a problem and the cost of solving that problem is undesirable.
Options:
Stick with PHP, raising in costs (infrastructure resources) and lowering your computational capabilities; lower performance, longer response time spans, worse UX, servers can freeze if not capable of handling enough requests, you may need a Node gateway, a queue service and/or a load balancer much earlier because you're not using the right tool for the job (more costs).
Use the "Islands architecture" and create a whole new application for the purpose, embed it on a given place and start praying you don't need much interaction between the wrapper and the new one, because it can quickly become another costly problem).
Rewrite the entire frontend and backend with the main reason being a backend (only) need.
As I'm always saying there's no tech to rule them all, but if anything goes mainstream there are technical reasons behind that choice.
There are hundreds of thousands of template engines, frameworks, libraries and so on out there, a good number of which are mostly useless, others have its niche and others have a general purpose.
Understanding the target of each and the differences against the rest of the options as well as acknowledging the context you're dealing with is key to make the right choice.
Either way and just because it has >15million daily downloads it's the go-to
So you're advocating tool selection based on popularity, not whether it's the right tool to solve the problem.
Do you need SEO?
So people who access services behind a login screen don't deserve the UX that contemporary SEO is attempting to foster? The prediction is that Interaction to Next Paint (INP) is going to heavily penalize many React-based apps.
It was easier to develop with good Ol'SSR but it's also much harder to maintain.
Hard to maintain perhaps but harder than an SPA?
The reports that I've come across suggest that SPA projects require more staffing than more conventional sites, compounding the negatives.
"best practices", "rulesets" like SOLID and DRY
Best practices are valid within a specific context outside of which they are no longer best practices. That's why DRY has to be balanced with Beware of the Share and SOLID is being challenged by CUPID; there are no universally applicable rule sets.
Guides arose to transform a monolithic application into services then into microservices where it suits.
Actually there is a perspective that properly bounded microservices are valuable because of they're (quickly) replaceable:
That has more to do with boundaries exerting just the right amount of cohesion on the inside combined with the right level and kind of coupling on the outside.
That maintenance cost could be lower when things are easier to replace isn't too great a stretch.
But just because you are using microservices or components doesn't mean that you'll be able to find the optimal boundaries right away. So there is no guarantee of "lower cost maintenance"; using more complex tooling makes it easier to miss the target. And at times components are not the right boundary:
Meet eBay's Marko. It has supported out of order streaming even back in 2016 (Marko 3). It will start to stream the page even before "the calculation service" has finished.
but if anything goes mainstream there are technical reasons behind that choice.
Popularity doesn't necessarily correlate to quality and popularity isn't necessarily based on technical characteristics. Many have argued that PHP's popularity was primarily due to the availability of cheap shared hosting, so the driver would have been an economic one.
React's popular feature is "declarative UI", translation: "You don't have to fiddle with DOM elements/objects". And while React Native was released 22 months later, VDOM could have been adopted with that end goal in mind. So "declarative UI" could have been a happy accident. And as the Elm community keeps pointing out components are objects (even with function components). So there's the theme of the promise of reuse in terms of components and across platforms. However that kind reuse comes with trade offs:
The rule of three: Reuse makes components harder to write and more complex.
Cross platform reuse tends to block platform specific optimizations. By extension if you don't use the cross platform capability then you are paying for trade offs that you never cash in on.
Again the motivation behind reuse seems to be largely economic, not technical, since this kind of reuse introduces undesirable coupling.
Now lets say "declarative UI", components and promise of reuse is enough to let React hit critical mass in terms of developer availability; i.e. it becomes easy to hire for. At that point the "popularity" becomes self perpetuating; React is chosen because it is easy to hire for, people learn React because it's in demand. Again this kind of popularity is non-technical.
So I think it is entirely possible for something to get popular without "technical reasons" contributing to it.
as well as acknowledging the context you're dealing with is key to make the right choice.
But that is the core of the problem; SPA/React predominantly being chosen without any consideration of context; that's essentially the Thoughtworks radar assessment:
"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'm working on a new mental model and could use some feedback: Do all websites fall on this spectrum?
22:01 PM - 12 Apr 2022
Lots of services don't need to be either stateful nor apps but go SPA just for the native-like perception and aesthetics, not any real usability benefits.
React was only created for stateful and apps (taking on additional trade offs to accommodate React Native). Creating ecommerce apps with React can be risky:
amazon.com is server side rendered and has no client side rendering framework. The potential latency hit didn't justify it.
We were stuck with jQuery 1.6.4 😬
SSR React wasn't fast enough for us. This blew my mind.
19:26 PM - 22 Jan 2022
Now Shopify's Hydrogen is React based but they are pushing hard to get React Server Components going to make up for lost ground (and as it so happens Jason Miller is now at Shopify (Platform DX) as well).
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
So people who access services behind a login screen don't deserve the UX that contemporary SEO is attempting to foster?
The only reason for using SSR for SEO purposes is the inhability of the crawlers to properly crawl an entire SPA site.
Don't you remember why we jumped from SSR to SPA? Just because you don't need to reload the entire site each time a click is made.
Yes, AJAX as popular just before SPAs, do you remember?
Many have argued that PHP's popularity was primarily due to the availability of cheap shared hosting, so the driver would have been an economic one.
Isn't that the most important?
Reuse makes components harder to write and more complex.
Yes. And finding what you need if you don't use reusable components is just a matter to find your button inside the rest of 93810 buttons. Sure it will make things easier 😂
The Amazon being SSR is changing btw, the contact part of the web app is now reactive (I noticed the upgrade on Sunday), we could dicuss why amazon is so slow changing its web app but that's another story that doesn't compete here. Oh and, know what? Amazon used React for the job :)
"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."
React is a framework now? How come?
The only devs I met who don't know other approaches came from a codecamp (3 month, stack rush learning approach) or self-taught (you learn what you like or what you feel necessary) and from both groups together only 3 of those I met fall in this description.
On the rest, let me state a sort of a rule:
For the same features and behavior, the complexity is always the same and every time you add more features you add more complexity as well.
The question is not if it's complex or not, the question is where do you want the complexity to be.
Poor page experience signals tank your search rank. SSR has been about good "user experience criteria" for a while now which meant that SSR needed to be fast and in the general it wasn't.
While revisiting SSR benchmarks for the next @solid_js release I went ahead and updated all the libraries and witness some big performance improvements from Svelte, React, and Vue.
React 18 is 48% React 17 Vue 3 is 61% over Vue 2 Svelte 3.49 is 97% over Svelte 3.44
Being able to pay the bills is important. But if you can only make a profit by negatively impacting everything else then you need to stop and find something else.
"But also, by choosing the framework that is dominant today, we maximize our chances to find volunteers, contractors and consulting shops to help us when we need it."
React appearing everywhere just illustrates the current human resourcing situation, it's not an indication that React is the best-of-breed solution for the problems it is being applied to.
What the Amazon tweet was about is that React isn't used in parts of Amazon's software that are critical to the business.
React is a framework now? How come?
I'm not going down that rabbit hole again. In software engineering terms React is a framework; it doesn't matter that the React docs call it a library and that React is nothing like Angular.
The question is not if it's complex or not, the question is where do you want the complexity to be.
"A fundamental point the article makes is that there are two types of complexity feeding the software crisis; accidental complexity and essential complexity. Accidental complexity occurs due to mismatch of paradigms, methodologies, and/or tools in our application. This type of complexity can be eliminated given sufficient resources to build or buy tools that complement one another. […] The real culprit of the software crisis is essential complexity. Essential complexity revolves around the fact that software is intrinsically complex, and no methodology or tool is going to eliminate this complexity. There are several reasons why software possesses essential complexity:
Software applications, for their size, are the most complex entities that humans build.
Software is intangible and, for the most part, invisible.
Software does not wear out in the traditional sense of machinery with moving parts wearing out. However, software is constantly being used in ways its authors never expected (often uncovering errors), and end users are constantly demanding extensions to their software."
Riel, Arthur J. (1996). Object-Oriented Design Heuristics. Addison-Wesley. (pp.3-4)
Over the years React hasn't been eliminating accidental complexity but accreting it.
Ultimately that is why SolidJS is becoming more compelling to developers who use React despite its much smaller ecosystem; it helps them eliminate accidental complexity.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Pointing the mdn github thingy but just mentioning the statement that suits you wasn't right, let me take care of it:
For the record, though, let's be clear that React is open-source and that React is a tool for producing websites that are built from the web standards of HTML, CSS and JavaScript. Yes, there are intermediate steps (jsx) that are not web standards, but the end product–the MDN website–is still based on standards. Its not like we're using Flash for our drop-down menus and an ActiveX plugin to display documentation in MS Word format!
I love web components. I had the opportunity to use them just a little bit as the FirefoxOS project was wrapping up years ago. And I look forward to using them again some day. But: I spent 18 months using React at Khan Academy and found it to be a huge productivity boost. There is a reason that so many developers use React: it, and the mature ecosystem of tools around it, works really, really well for rapid frontend development. This may sound harsh, but if you haven't used React on a midsize (like MDN) or larger website, I don't believe that you are qualified to judge our decision. And if you haven't worked as a frontend developer in an environment where you've got product managers and user researchers and marketing teams asking you weekly to add features and A/B tests and banners to the website, then you're also not qualified to judge this decision, either.
Actually David Flanagan did so good speech that I don't even need to go further with this.
Oh and by the way, your comment here is completely wrong.
You call ReactDOM.render(<App />, document.getElementById("root")); and YOU pass the components you want inside App component, it's not React calling you, it's you sending functions (components) to React. And those other things exists to fill some needs few have on this topic as IoC is not applied nor provided by React.
Sure you'll find people buying your nonsense but to anyone reading this, just go to React's homepage and you'll read "A JavaScript library for building user interfaces" right in the hero. I don't think this needs further absurd discussion.
I barely can hear that far cry that says "Punk's not dead!" but the stubbornness to go against the current is reaching unsuspected limits in this topic and the last stand should be taken in a different place, not on a science related field IMHO.
Actually David Flanagan did so good speech that I don't even need to go further with this.
"and found it to be a huge productivity boost."
Out of context this sounds great.
However whenever I dig into it, it always comes across as the "productivity boost" from moving something from an "artisan craft" to an "assembly line". And while that was responsible for industrialization, today's car assembly lines are serviced by robots, i.e. those areas will be automated into oblivion at which point one better be the plant owner or have moved into robot maintenance or bespoke car assembly.
YOU pass the components you want inside App component, it's not React calling you.
If React is going to do the framework thing of calling user code then you have to inject the user code somewhere … 🤦
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
The context seems to matter just when it cames convenient to your message, Isn't that the Appeal to Convenience fallacy?
Bringing the Argumentum ad populum has lots of sense on ideology, thoughts and likenesses but here is claiming that the entire industry is wrong and that the reasons behind are not valid; technical profiles, architects, business...
You've work to do pal. Overall you bringed an argumentum ad lapidem and that's a bit sad because no knowledge can be extrapolated, just references.
If React is going to do the framework thing of calling user code then you have to inject the user code somewhere
?? You injecting the code is just the opposite of inverting the control, that's why it's called inversion of control 😅🤷🏻♀️
I heartly recommend you to try to understand why React has the lead instead pushing against it.
I tried some of the frameworks and libs (Angular, Svelte, Preact, React, Next...) and have a formed opinion on every one of them. I do like more than one and I use more than one in a regular basis (when they suit). Solid JS (that seems to be your favourite one) is on my list for future check after Polymer and a couple of things that are more urgent to me (I do not work only in frontend).
You can like more than one at the same time, is not that difficult.
Is like buying a car, you like some different models, you may test them, see the equipment each bring, the optionals, the pros and cons and end up picking one because at the end you only have one ass and a limited budget, hence you just need one of them and it needs to be convenient. That doesn't mean that you don't like the rest from now on.
At the current State of the Art, React is usually more convienent for different reasons, not necessarily technical and it is what it is like it or not.
That doesn't mean that the rest are shit. While Angular has some bad vibes, svelte seems to be pushing step by step and I don't know if solid will ever be a market option, will see.
Disregarding my arguments (ease to use, web standards, market share, ecosystem, ease to find devs with previous experience, less decoupled of the language core API...) just because you don't like them or they are against what you would like the world to be won't make'em falsy.
Gosh You even disapproved the arguments of David Flanagan, -which you linked by the way- and which is a reputed engineer in the industry.
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.
There is nothing random about those links. Granted they are going to reflect my own bias but I also regularly post links to content I don't agree with inviting the reader to make up their own mind; to carefully scrutinize the information they are presented with, regardless of source and that includes everything that I state.
"JSX is an XML-like syntax extension to ECMAScript without any defined semantics."
ReactNodes, in SolidJS it creates DOM elements.JSX elements represent components in the component tree which relates to but isn't identical to the DOM tree.
And in React Native there isn't even a DOM much less HTML.
Neither is a W3C standard. The point was that Svelte's approach to templating is just as "legitimate" as JSX.
Again what is the point of this statement?
On the one hand you accept JSX as a useful DSL but on the other hand you want "just JavaScript". From that perspective a Vue SFC is as much "just JavaScript" as a React component with JSX.
Ultimately that is true for all the other frameworks as well. And Meta is continuing to experiment with compilers.
It has changed a lot since then.
Again that's a fallacy. The React community calls them Function-al components. Even the React documentation calls them Function components. React leverages immutability to it's own ends and function components, render functions, that access hooks are impure from the FP perspective.
What React gives you is "declarative UI", i.e. you don't have to constantly, imperatively fiddle with DOM elements.
People always find matters they are familiar with easy to understand.
Solid.js feels like what I always wanted React to be
i.e. it's fairly easy to find testimonies that React is anything but straightforward; so it's not as cut-and-dried as you portray it.
As long as it aligns with the React community consensus; React dictates a certain architecture therefore it has a distinct opinion which in itself isn't necessarily a bad thing until such time that the particular constraints it sets actually get in the way.
"What is clear: right now, if you’re using a framework to build your site, you’re making a trade-off in terms of initial performance—even in the best of scenarios."
[ref,
alt]Framework Usage Distribution in the Top 1 Million Sites
So I guess you'll be getting on that PHP gravy train, right? It's the most prevalent …
You really need to read things more carefully and not just see what you want to see.
"HTML Islands" doesn't occur anywhere in that article. It's Islands Architecture and a counter point to your claim of the false "site vs. app" dichotomy. There's a whole range of options in between. In fact enterprise consultancies are now starting to warn their clients about the SPA by default approach:
"the sheer prevalence of teams choosing a single-page application (SPA) by default when they need a website has us concerned that people aren't even recognizing SPAs as an architectural style to begin with, instead immediately jumping into framework selection. SPAs incur complexity that simply doesn't exist with traditional server-based websites"
Sure but it doesn't mean you have to settle.
The title for this article is "Getting ready for my first website: Choosing the right platform".
The extensions you need to adopt when working with Svelte are minor compared to the concepts that you have to assimilate with React. React introduced hooks in early 2019 and people are still complaining about them (and lets not forget the continued moaning about React 18; for example useEffect and useEvent).
There are of course a big bunch of different opinions, specially on a tech that has >15million daily downloads.
Either way and just because it has >15million daily downloads it's the go-to unless learning has not the purpose of finding a job afterwards.
The question is simple. Do you need SEO?
Is it a website? You'll be fine witj just HTML and CSS with few grains of JS.
This is applicable to the major part of cases currently.
Both SPA and classic SSR have its nuances and complexities. It was easier to develop with good Ol'SSR but it's also much harder to maintain.
Maintenance being a top cost for companies and us providing solutions come first to find "best practices", "rulesets" like SOLID and DRY, leading the industry to code separate backends. Guides arose to transform a monolithic application into services then into microservices where it suits.
Having the front-end attached to a backend leads you to few maneuver ability. i.e. you're using Smarty template engine inside a PHP backend and you see the need of complex computational tasks on new features that business needs. You may want to code this "service" in Java, Go or any other language that's capable of it efficiently. But Smarty works on PHP. So you've a problem and the cost of solving that problem is undesirable.
Options:
As I'm always saying there's no tech to rule them all, but if anything goes mainstream there are technical reasons behind that choice.
There are hundreds of thousands of template engines, frameworks, libraries and so on out there, a good number of which are mostly useless, others have its niche and others have a general purpose.
Understanding the target of each and the differences against the rest of the options as well as acknowledging the context you're dealing with is key to make the right choice.
So you're advocating tool selection based on popularity, not whether it's the right tool to solve the problem.
So people who access services behind a login screen don't deserve the UX that contemporary SEO is attempting to foster? The prediction is that Interaction to Next Paint (INP) is going to heavily penalize many React-based apps.
Hard to maintain perhaps but harder than an SPA?
The reports that I've come across suggest that SPA projects require more staffing than more conventional sites, compounding the negatives.
Best practices are valid within a specific context outside of which they are no longer best practices. That's why DRY has to be balanced with Beware of the Share and SOLID is being challenged by CUPID; there are no universally applicable rule sets.
Actually there is a perspective that properly bounded microservices are valuable because of they're (quickly) replaceable:
That has more to do with boundaries exerting just the right amount of cohesion on the inside combined with the right level and kind of coupling on the outside.
That maintenance cost could be lower when things are easier to replace isn't too great a stretch.
But just because you are using microservices or components doesn't mean that you'll be able to find the optimal boundaries right away. So there is no guarantee of "lower cost maintenance"; using more complex tooling makes it easier to miss the target. And at times components are not the right boundary:
Components are Pure Overhead
Ryan Carniato for This is Learning ・ May 10 '21 ・ 6 min read
Meet eBay's Marko. It has supported out of order streaming even back in 2016 (Marko 3). It will start to stream the page even before "the calculation service" has finished.
Popularity doesn't necessarily correlate to quality and popularity isn't necessarily based on technical characteristics. Many have argued that PHP's popularity was primarily due to the availability of cheap shared hosting, so the driver would have been an economic one.
React's popular feature is "declarative UI", translation: "You don't have to fiddle with DOM elements/objects". And while React Native was released 22 months later, VDOM could have been adopted with that end goal in mind. So "declarative UI" could have been a happy accident. And as the Elm community keeps pointing out components are objects (even with function components). So there's the theme of the promise of reuse in terms of components and across platforms. However that kind reuse comes with trade offs:
Again the motivation behind reuse seems to be largely economic, not technical, since this kind of reuse introduces undesirable coupling.
Now lets say "declarative UI", components and promise of reuse is enough to let React hit critical mass in terms of developer availability; i.e. it becomes easy to hire for. At that point the "popularity" becomes self perpetuating; React is chosen because it is easy to hire for, people learn React because it's in demand. Again this kind of popularity is non-technical.
So I think it is entirely possible for something to get popular without "technical reasons" contributing to it.
But that is the core of the problem; SPA/React predominantly being chosen without any consideration of context; that's essentially the Thoughtworks radar assessment:
"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."
SPA/React is the current industry's Golden Hammer.
Lots of services don't need to be either stateful nor apps but go SPA just for the native-like perception and aesthetics, not any real usability benefits.
React was only created for stateful and apps (taking on additional trade offs to accommodate React Native). Creating ecommerce apps with React can be risky:
Now Shopify's Hydrogen is React based but they are pushing hard to get React Server Components going to make up for lost ground (and as it so happens Jason Miller is now at Shopify (Platform DX) as well).
The only reason for using SSR for SEO purposes is the inhability of the crawlers to properly crawl an entire SPA site.
Don't you remember why we jumped from SSR to SPA? Just because you don't need to reload the entire site each time a click is made.
Yes, AJAX as popular just before SPAs, do you remember?
Isn't that the most important?
Yes. And finding what you need if you don't use reusable components is just a matter to find your button inside the rest of 93810 buttons. Sure it will make things easier 😂
The Amazon being SSR is changing btw, the contact part of the web app is now reactive (I noticed the upgrade on Sunday), we could dicuss why amazon is so slow changing its web app but that's another story that doesn't compete here. Oh and, know what? Amazon used React for the job :)
React is a framework now? How come?
The only devs I met who don't know other approaches came from a codecamp (3 month, stack rush learning approach) or self-taught (you learn what you like or what you feel necessary) and from both groups together only 3 of those I met fall in this description.
On the rest, let me state a sort of a rule:
For the same features and behavior, the complexity is always the same and every time you add more features you add more complexity as well.
The question is not if it's complex or not, the question is where do you want the complexity to be.
May 2020: Page Experience Signals
Poor page experience signals tank your search rank. SSR has been about good "user experience criteria" for a while now which meant that SSR needed to be fast and in the general it wasn't.
And we're going back again, doing it differently this time.
The point was that it's not a technical reason.
Being able to pay the bills is important. But if you can only make a profit by negatively impacting everything else then you need to stop and find something else.
🙄
David Flanagan @Mozilla 2019-02-15:
"But also, by choosing the framework that is dominant today, we maximize our chances to find volunteers, contractors and consulting shops to help us when we need it."
React appearing everywhere just illustrates the current human resourcing situation, it's not an indication that React is the best-of-breed solution for the problems it is being applied to.
What the Amazon tweet was about is that React isn't used in parts of Amazon's software that are critical to the business.
I'm not going down that rabbit hole again. In software engineering terms React is a framework; it doesn't matter that the React docs call it a library and that React is nothing like Angular.
No Silver Bullet (1986)
"A fundamental point the article makes is that there are two types of complexity feeding the software crisis; accidental complexity and essential complexity. Accidental complexity occurs due to mismatch of paradigms, methodologies, and/or tools in our application. This type of complexity can be eliminated given sufficient resources to build or buy tools that complement one another. […] The real culprit of the software crisis is essential complexity. Essential complexity revolves around the fact that software is intrinsically complex, and no methodology or tool is going to eliminate this complexity. There are several reasons why software possesses essential complexity:
Riel, Arthur J. (1996). Object-Oriented Design Heuristics. Addison-Wesley. (pp.3-4)
Over the years React hasn't been eliminating accidental complexity but accreting it.
Ultimately that is why SolidJS is becoming more compelling to developers who use React despite its much smaller ecosystem; it helps them eliminate accidental complexity.
Pointing the mdn github thingy but just mentioning the statement that suits you wasn't right, let me take care of it:
Actually David Flanagan did so good speech that I don't even need to go further with this.
Oh and by the way, your comment here is completely wrong.
You call
ReactDOM.render(<App />, document.getElementById("root"));and YOU pass the components you want inside App component, it's not React calling you, it's you sending functions (components) to React. And those other things exists to fill some needs few have on this topic as IoC is not applied nor provided by React.Sure you'll find people buying your nonsense but to anyone reading this, just go to React's homepage and you'll read "A JavaScript library for building user interfaces" right in the hero. I don't think this needs further absurd discussion.
I barely can hear that far cry that says "Punk's not dead!" but the stubbornness to go against the current is reaching unsuspected limits in this topic and the last stand should be taken in a different place, not on a science related field IMHO.
"and found it to be a huge productivity boost."
Out of context this sounds great.
However whenever I dig into it, it always comes across as the "productivity boost" from moving something from an "artisan craft" to an "assembly line". And while that was responsible for industrialization, today's car assembly lines are serviced by robots, i.e. those areas will be automated into oblivion at which point one better be the plant owner or have moved into robot maintenance or bespoke car assembly.
If React is going to do the framework thing of calling user code then you have to inject the user code somewhere … 🤦
50 billion flies can not be wrong. …
bandwagon fallacy
"If imho can mean humble or honest, then the internet is full of noise and empty of soul: little more than a broadband Tower of Babel."
[source]
Look, I can be wrong but you continue to fail at producing convincing arguments.
I'm sure you'll have some last words to get in edgewise.
Oh sure!
The context seems to matter just when it cames convenient to your message, Isn't that the Appeal to Convenience fallacy?
Bringing the Argumentum ad populum has lots of sense on ideology, thoughts and likenesses but here is claiming that the entire industry is wrong and that the reasons behind are not valid; technical profiles, architects, business...
You've work to do pal. Overall you bringed an argumentum ad lapidem and that's a bit sad because no knowledge can be extrapolated, just references.
?? You injecting the code is just the opposite of inverting the control, that's why it's called inversion of control 😅🤷🏻♀️
I heartly recommend you to try to understand why React has the lead instead pushing against it.
I tried some of the frameworks and libs (Angular, Svelte, Preact, React, Next...) and have a formed opinion on every one of them. I do like more than one and I use more than one in a regular basis (when they suit). Solid JS (that seems to be your favourite one) is on my list for future check after Polymer and a couple of things that are more urgent to me (I do not work only in frontend).
You can like more than one at the same time, is not that difficult.
Is like buying a car, you like some different models, you may test them, see the equipment each bring, the optionals, the pros and cons and end up picking one because at the end you only have one ass and a limited budget, hence you just need one of them and it needs to be convenient. That doesn't mean that you don't like the rest from now on.
At the current State of the Art, React is usually more convienent for different reasons, not necessarily technical and it is what it is like it or not.
That doesn't mean that the rest are shit. While Angular has some bad vibes, svelte seems to be pushing step by step and I don't know if solid will ever be a market option, will see.
Disregarding my arguments (ease to use, web standards, market share, ecosystem, ease to find devs with previous experience, less decoupled of the language core API...) just because you don't like them or they are against what you would like the world to be won't make'em falsy.
Gosh You even disapproved the arguments of David Flanagan, -which you linked by the way- and which is a reputed engineer in the industry.