DEV Community

Discussion on: Getting ready for my first website: Choosing the right platform

 
joelbonetr profile image
JoelBonetR πŸ₯‡ • Edited
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.

Thread Thread
 
peerreynders profile image
peerreynders

The only reason for using SSR for SEO purposes is the inability of the crawlers to properly crawl an entire SPA site.

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.

Don't you remember why we jumped from SSR to SPA?

And we're going back again, doing it differently this time.

Isn't that the most important?

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.

πŸ˜‚

πŸ™„

Amazon used React for the job :)

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.

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.

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:

  1. Software applications, for their size, are the most complex entities that humans build.
  2. Software is intangible and, for the most part, invisible.
  3. 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.

Thread Thread
 
joelbonetr profile image
JoelBonetR πŸ₯‡ • Edited

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.

Thread Thread
 
peerreynders profile image
peerreynders

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 … 🀦

but the stubbornness to go against the current

50 billion flies can not be wrong. …

bandwagon fallacy

IMHO

"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.

Anyways, thanks for the debate.

I'm sure you'll have some last words to get in edgewise.

Thread Thread
 
joelbonetr profile image
JoelBonetR πŸ₯‡ • Edited

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.

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.