Comment by chipotle_coyote | Hacker News Reader

Comment by chipotle_coyote | Hacker News Reader

Parent Full thread

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.

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.

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.

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

Serious question:

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

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.

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.

Reply on news.ycombinator.com