Hacker News Reader

Comment by api_or_ipa | Hacker News Reader

Why do we keep seeing posts like this? My team absolutely needs React/Redux/Sagas/Webpack/whatever-you-want-to-hate-on-today, to ship and yeah we ship our backend with Docker. Why do I know we need it? Because we have years of experience in our workflow and we understand the problems we need to solve in the development workflow and timeline our company uses. Do you know who doesn't understand our needs? Someone writing a low-quality post about how _their_ specific needs can be met with existing technology. Please just leave me be and go focus on solving your own problems, I wouldn't be using this technology if I didn't think it worked better than anything else.

/rant.

View on HN

My theory is its like this mostly because on HN because there's no downvote for posts. Everything useful that can be said about how bloated web frameworks supposedly are has pretty much been said imo, but there's a niche of people convinced every web app is actually simple and should be done using Netscape 4 era HTML.

I'm all for simplicity... but if you are developing a large web application, you probably would benefit from "heavy" web frameworks (they're not really that bad though.) What "large" is can be debated, but I'd argue most pages we use today are "large" enough. HN is a good exception. GitHub, large publications, webmail, online shops, anything dealing with realtime data... It's probably worth it.

Github is actually a great example - i think it's getting better gradually, but for a lot time it was really obvious that it was server-rendered pages with a few ajax calls sprinkled in to do small things like update the status when the tests finish. And it led to all kinds of weird edge cases and unpredictability, some things would live update, other things you need to do hard refresh to see the latest version, sometimes when using the back button it would reload the original version of the page before the ajax calls had succeeded so you'd see old data.

Clearly it wasn't bad enough to drive everyone off the platform, but there's no way you'll convince me that that was a better system that a well-written SPA built with modern tools.

I'm with you. Whenever I see posts like this, I can't help but think, "More job security for me."

You may be joking, but I really think some of these posts may be by design. Some of these frameworks are so easy to use and in skilled hands lead to such impressive results, that it becomes harder to get a competitive advantage with UX. A single developer can do today what once took a small team. Thus we see these fucked up ladder kicking posts where people are encouraged to go use last generation tech, so they get left in the dust by companies pushing ever forward. By the time they realize how far behind they’ve fallen, it’s too late.

> A single developer can do today what once took a small team.

When was this, in the 80's? Web productivity is just catching up to RAD platforms like Visual Basic in the 90's and still a lot more complicated than a good UI framework like Gtk/Qt.

The hard part in my experience is that a lot of teams don't know if they absolutely need it. I have worked on some projects that are more hype driven development using React/Redux/Sagas for a barely interactive webapp. It adds a ton of complexity for little to no benefit.

Can we stop grouping React, Redux and Sagas when discussing complexity/bloat? They all have totally different complexity profiles. For example React adds tons of software complexity but very little development complexity, whereas Redux is the polar opposite. And Saga is just a clusterfuck. I don't even understand how people can use it with a straight face.

Ok, but only if we can also stop saying React and Vue in the same breath. React is the spearhead of a galaxy of the biggest, heaviest, enterprisiest solutions in it's class, and it has it's place, but Vue is at it's best in lighter applications. You can do quite robust SPA development with Vue, but I'd argue it's even better when it's sprinkled lightly into a project, as a drop-in replacement for the ajaxing and updating we used to use jQuery for.

Some people just want a project with particular frameworks on their resume. "Professional side projects" carry more weight than something up on Github.

The audience for this post is at the opposite end of the market from you: two buddies building an MVP in a garage on a shoestring budget.

Genuinely curious: how long have you been doing web development and what technologies were you using before you found yourself absolutely needing React and co?

He could be right. The complexity of these front end frameworks decouples modules increases complexity by a significant amount. There is no way to prove that your current designs are the best possible way of solving your problem as designs by definition aren't proveable solutions.

To listen to him blindly is ignorant but to ignore him is just as perilous.

> My team absolutely needs React/Redux/Sagas/Webpack/whatever-you-want-to-hate-on-today

Then you're in the 1% of people that use these tools and actually need them. The point of articles like this isn't that they never make sense and nobody needs them, it's that they're way over used where they aren't needed.

> ...way over used where they aren't needed...

Bingo! Engineers love to change things like Scotty said, but they also blather on about if it aint broke, dont fix it?

But does the customer need it? To wait for the bundle to download and parse? Doesn't the customer deserve instant loading?

Because your team is the exception. Isn’t that implied by the title?

That's the thing though. Is my team really the exception? When you look at the highly immersive web that product managers and customers have come to expect, you simply can't build it without javascript. Once you've crossed that bridge, is it really easier to finagle some event handling using vanilla js/jquery or pull down create-react-app and get all the tooling necessary to 1-click-deploy to Heroku, S3 or Github pages and not have to deal with the multitude of bugs that hand rolled events and state can cause?

I am not sure exactly wtf a "highly immersive" experience is, what I do know is I'm shipping marketing pages that take like two minutes to load on "slow" connections and "old" phones (a.k.a. "our real users") and don't have top-of-page content or layout figured out (a.k.a. do their job) without a shitton of JS, CSS, a front-end "framework" and we can't ship new functionality (a.k.a. do our jobs) without a huge conversation about components, assets, and how the build process should work, disagreements on pet patterns.

I wish I could rebuild the home page in server-rendered HTML, a minimal hand-written set of JS and CSS for top-of page plus a fairly lean set for everything else, cut down to two fonts (headings and body text), preload the blocking assets, defer non-blocking assets, put pages and everything into object storage + CDN, and just... I dunno... serve our users. Any build tools or automation or content editor tools should lie on top of any of the above (Most of the "immersion" or whatever should remain intact, aside from what I see as bonuses: minor improvements to consistency in type and presentation).

I have no idea. But saying that you feel like you need a project is not a counterargument to the thesis: most teams don’t need it, even if some do. Maybe that’s right, or maybe it’s wrong, but your original comment was not a rebuttal.

You questioned why we keep seeing these arguments. Perhaps it’s because nobody on the other side cares to listen?

Why are there even "sides"? it's very obvious that this new tooling can be very useful for the modern Web. it's also apparent that a certain intersection of skill set and project requirements can do better with more classic tooling. why is there a continuous need to pull someone to one side or another? whatever happened to using the most appropriate tool for the job?

Because there are two or more sides to every debate.

The “most appropriate tool for the job” is exactly what the article is arguing for.

On the other hand, I'd say applications so trivial they couldn't benefit from something like React are the exception.

"When you're holding a hammer, everything looks like a nail."

There is a tendency for mgmt to sign up engineers to a vision quest with pre-established non-negotiable requirements whereby the customer expects what would be tantamount to solving all the world's problems in one easy to use, intuitive SPA that 'just works, always'. This is a big factor in the endless new framework releases, mutually-exclusive complexities and vulnerabilities.

Reply on news.ycombinator.com