Hacker News Reader

Comment by cfv | Hacker News Reader

You probably don't need a single-page app, right up to the point where it's a business requirement and you have to translate a GB worth of convoluted JSPs into one because the client likes smoothness in their flows, continuous saving, and all those nicely choreographed state transitions you just cannot get without having a framework hijack the History and File APIs from the browser's paws.

Yes, a nice state machine-like flow with each thing happening only once at a given time is great, right until you get asked to make it so that clicking on a thing shouldn't reset all user input, and progress of a task should be communicated live, maybe while we also we want this app to just not show a blank screen like, ever, just comes and happens to you and that's what you kind of have to do now.

View on HN

This is what HN is always missing on the anti-SPA rants. It’s almost always a requirement from the client. How many hours have been wasted on here by programmers writing overwrought comments about how we’re losing touch with the user because of all of our complicated frontend frameworks? No. It’s almost always because the client’s designer wanted a real-time updating hamburger menu or whatever.

The client is rarely the user. Clients always ask for the latest buzzwords.

This is why it's important to understand the probable business requirements early.

Website != Browser app != Mobile app != Desktop app != AR/gaming platforms

If you know which of those you need, you can make an optimal technology decision. No one can expect to turn a wood-framed structure into a steel-framed structure. Nor build a steel-framed structure for the price of a wood-framed one.

In this day and age, chances are better than not for anything reasonable involved, that this smooth interaction is a business requirement, but YMMV.

not to mention the UX people coming up with neat animations and subflows with gradually revealed content.

> smoothness in their flows

...what?

> continuous saving

No problem.

> and all those nicely choreographed state transitions

Learn to say "no." It works wonders whenever people tell you that your aircraft has to go under water now.

It's difficult to tell the person who's writing your paycheck "this is totally possible I just don't like it and so won't do it."

Like if you're doing SSR you could at least use something like turbooinks to implement state transitions.

How about “that’s totally possible. It will cost you 10x what you’re paying now, it will be much more brittle and harder to fix. I personally would love to work on it, just keep in mind that any changes will require 10x the time and budget”

And ...

“Here are a couple of technologies which would allow us to speed up the experience at a very low cost. I recommend we try these first.”

Turbolinks for the win :)

10x the cost!? Well, I have a quote from your competitor that's a fraction of that amount. If you keep quoting unreasonable prices, perhaps I should rethink our business relationship and move elsewhere.

> It will cost you 10x what you’re paying now, it will be much more brittle and harder to fix.

I say this as someone who's done a lot of freelance work: No, you can't bullshit your clients like this. You may be able to tell them that if it's not an actual lie, but in your case, if you actually would endure such costs and fragility, it speaks volumes about your agency's skill levels.

If you're in the business of selling websites, maybe it's time to actually learn how to write a good SPA rather than bury your head in the sand, because yeah, clients do actually want those.

Maybe I should’ve made it clear that the 10x is an example. In most cases it would be 2x to 4x, the cost for implementing two apps instead of one.

Of course the cheaper option (monolith app + turbolinks and js sprinkles) could be framed as a discount.

And I can imagine how many agencies would not mention the expense of maintenance, because they’d actually want to lock in the client first.

...and it breaks linking to URLs and backspace.

Turbolinks? Huh? You have to write your code keeping turbolinks in mind because certain onload events will only fire once but you use turbolinks specifically because you want those things to work but want the speed advantage of not doing a full page refresh.

Sure, you can say that. You will lose your clients to the agency down the road who happily use React and say "no problem." Especially once it turns out that it _doesn't_ require 10x the time and budget and your prospective client tells everyone you bullshitted them.

> learn to say no

Good luck keeping that client after the end of your contract.

Reply on news.ycombinator.com