[willcipriano]

> I can't win this battle

You are fighting the wrong battle. You harp on the technology used rather than the specific functionality you desire.

The bad way to do it: "You made a single page app with PHP and {other tech} and {database}! I hate those! Don't you read (reddit, twitter, hacker news)? Best practices say..."

The good way to do it: "Our users often share links within the application with each other to navigate and the new single page app you demoed doesn't allow that."

Or: "While the page load times look great on the metrics in your power point, as everything is lazy loaded it takes 10 seconds for the page to actual become usable, the old site loaded in under a second why are we regressing the user experience here?"

Or the evergreen: "What does that buy us?"

[stavros]

This is fairly basic advice, and it feels a bit insulting to assume I'm just hating on some tech. Obviously, if things were as easy as "here's the immediate and unambiguous problem with this approach", I would have gone that way.

Things would be great if the risks were as simple as this. The actual problem is "six years later, the frontend is a ball of spaghetti code and it takes you two sprints to change a component".

How many developers do you think heed those warnings?

[willcipriano]

> heed those warnings

It's not a warning. It's a functional requirement that you put into the ticket. The project isn't done if the rewritten page takes longer to load than the old one did. Don't ship it, don't pay bonuses based on shipping it.

[stavros]

Please read my comment more carefully, you're being patronizing. I can't put "I want feature development on this codebase to be faster than two sprints in six years" in the requirements.

[willcipriano]

Sounds like you should talk to the person who is actually in charge then.

[stavros]

I'll have a chat with the mirror.

[j45]

Not enough. But they will scoff at other technologies old and new.