[luxphl]

I truly do not think it's a lie. Not sure why you think it's a thrill. It's saved me hundreds of hours, if not more.

It's certainly faster to use jQuery to change a CSS attribute than it is to setup a React project but what's not considered in that calculation is maintaining the state of that attribute or making changes to the logic in the future. Especially on code you didn't write originally.

If all you have to do is validate a form, sure, use jQuery if that's your cup of tea. But I would still rather use something like React because I know I'm less likely to write buggy code or introduce a regression in the future. To each their own though.

[chipotle_coyote]

I think the problem/frustration is simply this: there are a lot of web sites out there that are, well, web sites, not web applications. Looking back at the linked article, it goes out of its way to talk about many ways that React is "pretty great" and "for a particular scope of use cases it's the best tool you can find," but then goes on:

> There are a lot of problems for which I can't see any concrete benefit to using React. Those are things like blogs, shopping-cart websites, mostly-CRUD-and-forms websites.

And the thing is, this still comprises an awful lot of the web. If I can produce a web site with Lektor or Hugo or some other sophisticated static site builder, it's hard to see how React is going to bring anything to the table that either makes that web site easier for me to maintain or provides a better experience for that web site's users. If you introduce some dynamic elements to the web site -- well, just what are those elements? Ad banners? A simple image carousel?

And I think that's really the argument being made here -- use the right tool for the right job. If all you have is React, everything look likes like an SPA, but that doesn't mean that it is.

[inapis]

Your argument hinges on the assumption that the products have a final conclusion. I can start building a product in hugo, say - I’m just displaying information in charts and generating predefined reports. Time passes more users are added and now I need to identify each users reports. Now I need a server and at this stage I can get away with SSR. More time, more organizations, more complexity. All of this can still be handled by SSR. The real kicker happens when people start demanding the ability to generate their own reports by supplying their parameters. They want the ability to write their own queries. They want WYSIWYG building blocks. They want to define their own templates.

Very quickly we are in a territory well done with react than with Hugo.

Most products, especially if it’s a company, are like this. Products are constantly evolving. Whether products should be constantly evolving is a different discussion and tools are only a small part of that discussion.

[chipotle_coyote]

I would say rather that my argument hinges on the assumption that the majority of web sites in the world are not the primary products of the companies that produce them. I would argue, in fact, that you're looking at web sites from a very particular lens. An absolutely valid lens, to be sure, but a particular one. nonetheless.

If you're an SaaS (or PaaS or whatever-aaS) company, then your web site is literally the core of your being. You're building an application that happens to run in the browser, so you want to build it like an applications! But a lot of companies aren't doing that. Hacker News, the web site we're on right now, doesn't need to be an SPA (and isn't). Does any CMS need to be designed like one? I'd never give a blanket "no," but I'd sure never give a blanket "yes." How about a company blog? A simple storefront? A customer-facing restaurant site?

Also, don't get hung up on my particular example of a static web site -- I wasn't arguing that all sites can be done with Hugo. :) But you could absolutely design a modern, maintainable CMS that lets internal customers generate their own reports, write their own queries, and define their own templates using Rails or Django or Laravel as the back end -- and that seemed to me to be what the original article was really trying to get at. We've gotten so hooked on "JavaScript is everything everywhere" that we may not always be considering whether a given project really fits that paradigm. "This project doesn't fit it now, but it might in the future" is nearly always a technically correct response -- but "what you're building couldn't possibly scale up to unicorn level" is nearly always a technically correct response, too.

[austincheney]

My problem is that developers seem to be generally afraid of the technology and employers allow fragile products due to a talent deficit.

https://news.ycombinator.com/item?id=23137367

[arvinsim]

Serious question:

Is this really a problem with web developers? Or is it with product managers who demand SPA like behavior?

[danjac]

For all the talk of "resume driven development" I think most developers - unless they are playing around with side projects and non-essential experimental stuff - prefer to do the simplest thing that will get the job done and keep the site maintainable, and the reason they resort to more complex and advanced frontend solutions is due to onerous requirements from stakeholders for more and more intricate and complex UI. It's another question entirely whether this more intricate and complex UI actually delivers business value or provides a better experience for the end users, but that question is above the developers' pay grade.

[chipotle_coyote]

I suspect a little of both. Developers do like to play with cool new technologies, and product managers do like to see how spiffy they can make their products.

Having said that, though, I do not think it's a universal truth that all web sites must expand to fill all available functionality, which seems to be implicit in a lot of arguments here and in the highest-rated rebuttal to me.

[theonething]

> It's saved me hundreds of hours, if not more.

How did you come up with that? You tracked the time it took to complete the project with and without React and diffed it?

[luxphl]

The same way anyone would come up with a time estimate if asked how long it would take to mow the lawn with a pair of scissors or lawnmower -- experience and extrapolation.

[theonething]

Fair enough on the experience and extrapolation. But I would argue your analogy is a bit off. It's undeniable that a lawnmower is faster than scissors. I don't think that's the case between React and no React.

A closer analogy would be a comparison between different models of lawnmower or between a lawnmower and a different kind of mechanical grass cutting device. In which case, it seems you would need to log time to see if you've saved time using one over the other.

[austincheney]

> I truly do not think it's a lie. Not sure why you think it's a thrill. It's saved me hundreds of hours, if not more.

Its a lie so long as the number sounds completely invented. I suspect the number comes from somewhere, maybe a vague memory, or a grossly unqualified estimation, but it isn't based on anything. It is something superficial that primarily serves as self reassurance.

When you have never had to bill people for your time, or you have never been to a board meeting, or never briefed senior executives this kind of fantasy is perfectly fine. The moment there is money on the table you are expected to do more than invent fictional numbers, or you will be replaced by somebody who can.

[luxphl]

I have worked as a consultant for 5 years where I billed people for my time, and paid at least $200k to other contractors in that period for help on projects; it's not made up and it is based on my experience tracking my own time and productivity, and that of my subcontractors.

I do think it's more abstract and harder to justify properly when someone is a well paid salaried employee for a FAANG. But that's not me.