There are already numerous answers, but almost all of them say: "Suck it up." So I will offer the contrarian advice: go with your gut. As a back-end developer, I have a healthy respect for the entire different skill set of working with the front-end. I myself would never write front-end code except with a gun pointed to my head. I certainly would not tell a front-end dev that my version was "good" or even "good enough". If they offered to rewrite it in a week using best practices, I would say: "You're my new best friend."
It is better to ask forgiveness than to ask permission.
This is a bold principle to live by, and it may eventually lead to your [professional] death. But in many cases, it works. The key is that you have to deliver results. At the end of the day, nobody actually cares whether the code is good or not other than you. They only care whether they get to claim credit for the business deliverables. As long as they push buttons and the site does what they expect, they couldn't care less how it is powered. Most likely, the former dev has already forgotten about the code and would be happy to never touch it again. The other devs likely just suck up to the senior because it's good for their careers.
Obviously, you need to maintain 100% of existing functionality. Do not break anything that already works, or you will be asking for a lot more than forgiveness. Otherwise, replace every bad bit you can possibly get away with, even if that means pushing the deadline a bit. You will really win points if you can add robustness or even functionality to your rewrite. Hopefully, you can identify some edge cases that the old code blows up on, and document repros for it as unit tests (which you check in). Then, you fix them with your refactoring.
Don't tell anyone you are doing all this. The managers who would tell you to stop don't know enough about code to have good judgment. The devs who can tell what you are doing don't have good enough judgment to recognize bad code. In the end, all that matters are the business results. If the other devs who have to work in your codebase say something, ask them if your version is better or worse than the old version. If they say it's better, then their job got easier and you have a new ally. If they say it's worse, ask them to explain why, but don't argue with them. Instead, drill down into each reason and make them justify it with technical arguments, rather than style points or "That's how we always did it." Always lead by asking questions, and think about the scenarios which make their version less desirable.
Most likely, the existing code is riddled with security vulnerabilities. Try to find a few, and document those, especially if you can point directly to OWASP principles that are being violated. If you have contacts inside your client orgs, see if you can get direct feedback from them, especially on the aesthetics. Old non-techy folks can have embarrassingly high tolerance for ugly and difficult UIs. Sometimes you need a younger person who has used good UIs and has high expectations to tell them that their product sux. If you can gather a few emails from such client reps praising your redesign, that will speak louder than any other voice in your company. That will essentially be a veto of anyone who tries to challenge your strategy. But don't pull them out unless you are actually challenged. Hold all your cards close to your vest until you need to play them.
When you are finally forced to discuss matters with your boss, go into your meeting prepared. First, be prepared that your boss punishes you severely or fires you. If you absolutely cannot afford to get fired, then don't go this route at all. If you think you can find another job fairly easily (hard to think otherwise in this market), then this risk is likely worth taking. You have to make that call yourself.
Tell your boss that you are trying to help the team win, and if they play it right, they can take a lot of credit for delivering a much-improved project. You need to make it clear that your boss should take credit for making the product look better, and explain to their peers/boss that they also directed you to refactor the code to current industry best practices because it improves your feature velocity. As your boss tries to call BS on you, interrupt them and point out how smart they will look for delivering a superior product that goes above and beyond the bare-bones requirements, and pays down technical debt at the same time. If your boss doesn't know what tech debt is, give them a tutorial so they can then go and school their peers and pump their status in the org.
Everything you say needs to be a selling point that your boss can use in meetings with peers and their boss to angle for bonuses/raises/promotions. You need to sell your improvements as something that they can resell at a personal markup. And if all that fails to move them, pull out the emails from the client peers praising the improved UI. Then say: "Look, I know I pulled the trigger on these changes, and I'm totally ready to roll them back. But, uh...some clients already know what's coming down the pipeline, and they might ask some hard questions if we just deliver more of the old UI. So...tell me when you want me to hit the rollback button, and I'd be happy to do so. And in your mind, just say: "Checkmate!"
Then make some notes in your personal journal reminding yourself how you took the initiative to improve the UI and the codebase while delivering all the business asks when you have your next major performance review. At that time, ask for a bonus/raise if that's appropriate for your delivered work.