Live data from Hacker News

Server-Side Only React with Next

webcloud.se

51–60 of 75 posts

Re: Server-Side Only React with Next

#51
I'm tired of the dogma that's behind all the hyped up software development tools and techniques.

For years, I was telling people that React and related tooling was a bad idea, that it adds a lot of unnecessary bloat which is not worth it. Everyone (like 99% of developers) disagreed with me and kept insisting that it was a simple solution.

Fast forward half a decade, now pretty much everyone agrees that React adds a lot of unnecessary bloat... The level of bloat just had to get truly appalling for people to actually notice (I swear a lot of projects seem to take 10 minutes to build). It took 5 years for people to accept the PREMISE of my original argument.

But now even though a lot of people finally accept the premise, they are still desperately trying to rationalize the existence of their favorite hyped up tools in any way they can.

I'm tired of explaining to people that "simpler solutions are better than complex ones". If any idea should be recited dogmatically, that should be it. Someone should write a book about it so that people can repeatedly whack themselves over the head with it until it gets through their thick primal skulls.

Re: Server-Side Only React with Next

#52

I'm tired of the dogma that's behind all the hyped up software development tools and techniques. For years, I was telling people that React and related tooling was a bad idea, that it adds a lot of unnecessary bloat which is not worth it. Everyone (like 99% of developers) disagreed with me and kept insisting that it was a simple solution. Fast forward half a decade, now pretty much everyone agrees that React adds a l…

You may want to check the temperature again. The react community is still huge, still growing, and still improving. React jobs are still widely available and new companies get started using react (or transition to react).

You aren't the first person (or the last) to care about payload size to the browser. Everyone cares about that, including the React core team.

Re: Server-Side Only React with Next

#53
Maybe it's a good idea if you already had a React codebase and want to switch to a static site with few code changes, but I think it makes zero sense to start a new project with React only to have it rendered on the server-side.

Re: Server-Side Only React with Next

#54

Step 1: Server Side HTML -> Website needs to be more interactive. Step 2: Server Side HTML + Client Side React SPA -> Website is now interactive but performance decreased. Step 3: Server Side HTML + Server Side React + Client Side React SPA -> Website is interactive, performance is good but now it's overly complex. Step 4: Server Side HTML + Server Side React -> Let's make it a bit more simple and even more performan…

Cheap comment ..

I see them as options, not steps, options within the same ecosystem

A lot changed, but the limitation is still the same - the delivery platform - browser (dom + js)

Re: Server-Side Only React with Next

#55

I'm tired of the dogma that's behind all the hyped up software development tools and techniques. For years, I was telling people that React and related tooling was a bad idea, that it adds a lot of unnecessary bloat which is not worth it. Everyone (like 99% of developers) disagreed with me and kept insisting that it was a simple solution. Fast forward half a decade, now pretty much everyone agrees that React adds a l…

You may want to check the temperature again. The react community is still huge, still growing, and still improving. React jobs are still widely available and new companies get started using react (or transition to react). You aren't the first person (or the last) to care about payload size to the browser. Everyone cares about that, including the React core team.

>> React jobs are still widely available

I don't doubt React's effectiveness as an economic tool for job creation. No economic tool is able to turn a simple 1-person job into a complex 100-person job as effectively React does. The Federal Reserve Bank loves React.

But is it the most effective tool for writing web apps? Not by a long shot.

Re: Server-Side Only React with Next

#56

Step 1: Server Side HTML -> Website needs to be more interactive. Step 2: Server Side HTML + Client Side React SPA -> Website is now interactive but performance decreased. Step 3: Server Side HTML + Server Side React + Client Side React SPA -> Website is interactive, performance is good but now it's overly complex. Step 4: Server Side HTML + Server Side React -> Let's make it a bit more simple and even more performan…

> You can see that nothing really changed

Nah, you've started with a good framework focused on querying data and rendering them, and finished with one focused on async network IO and live-updating an interface.

Re: Server-Side Only React with Next

#57
post #38

Step 1: Server Side HTML -> Website needs to be more interactive. Step 2: Server Side HTML + Client Side React SPA -> Website is now interactive but performance decreased. Step 3: Server Side HTML + Server Side React + Client Side React SPA -> Website is interactive, performance is good but now it's overly complex. Step 4: Server Side HTML + Server Side React -> Let's make it a bit more simple and even more performan…

> also less complex. And less interactive.

I always wondered what is not interactive in pressing a form submit button, being brought to another page with results.

What is the definition of interactive?

Re: Server-Side Only React with Next

#58

I'm tired of the dogma that's behind all the hyped up software development tools and techniques. For years, I was telling people that React and related tooling was a bad idea, that it adds a lot of unnecessary bloat which is not worth it. Everyone (like 99% of developers) disagreed with me and kept insisting that it was a simple solution. Fast forward half a decade, now pretty much everyone agrees that React adds a l…

> "simpler solutions are better than complex ones"

Everything is a tradeoff. React adds bloat but simplifies development. If any idea should be recited dogmatically it should be "software development is too complicated to live by blanket statements".

Re: Server-Side Only React with Next

#59

Earlier quoted context omitted.

You may want to check the temperature again. The react community is still huge, still growing, and still improving. React jobs are still widely available and new companies get started using react (or transition to react). You aren't the first person (or the last) to care about payload size to the browser. Everyone cares about that, including the React core team.

>> React jobs are still widely available I don't doubt React's effectiveness as an economic tool for job creation. No economic tool is able to turn a simple 1-person job into a complex 100-person job as effectively React does. The Federal Reserve Bank loves React. But is it the most effective tool for writing web apps? Not by a long shot.

> But is it the most effective tool for writing web apps

What's your preferred alternative, pray tell?

Re: Server-Side Only React with Next

#60
post #27

Earlier quoted context omitted.

Yes, and it's nonsense. "I needed something to convert markdown to html", "I like the component mental model", "I wanted to use Node libraries for date formatting etc.", "Next has a great developer experience" None of these justify using React. It all boils down to "I'm doing it because I can and I'm familiar with those tools".

> None of these justify using React. It all boils down to "I'm doing it because I can and I'm familiar with those tools". "I'm using x technology because I'm familiar with it" is exactly what most people should be doing. Many people try to create production sites with tooling they're not familiar with, or take too long learning something new. Why do none of these justify using React? They probably care about differen…

> "I'm using x technology because I'm familiar with it" is exactly what most people should be doing.

Not necessarily, there are multiple tools in the world and not without reason - almost all of them were created with specific purpose. One can be very familiar and skilled with using hammer but it doesn't mean that it will be efficient to cut a slice of bread with it.

For software tools makers it is very tempting to try to make it versatile enough to be able to use it for every possible case, however this is not possible and never will be without sacrifices - and most frequently speed, clarity and ease of use is sacrificed first - there are multiple examples of this: jira, gitlab, facebook, clickup. Complexity, bloat and cognitive load is growing, users are starting to have difficulties to grasp all options and possibilities - and boom suddenly from most loved to most hated.

Post reply on HN