Feature toggles in the front end can absolutely deliver more dead code to customers, that's part of their intent: to keep alternative code paths dead until you want them to be active.
Feature toggles are also invaluable in allowing teams to continuously and confidently release new features to their customers.
If I was forced to choose between dead code and an untidy DOM or a slower release cadence and feedback loop, I'd chose dead code 100% of the time.
That said, I also make conscious choices about how I build new features and how and where to toggle them to ensure that I'm not polluting my codebase.
In general I think the same rules apply to feature toggles regardless of whether they exist in the front or back end. You should have as few of them as possible, and they should live for the shortest possible time.
This way, your delivery of dead code to your customers is always temporary.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Addressing your title. I'd say it's both.
Feature toggles in the front end can absolutely deliver more dead code to customers, that's part of their intent: to keep alternative code paths dead until you want them to be active.
Feature toggles are also invaluable in allowing teams to continuously and confidently release new features to their customers.
If I was forced to choose between dead code and an untidy DOM or a slower release cadence and feedback loop, I'd chose dead code 100% of the time.
That said, I also make conscious choices about how I build new features and how and where to toggle them to ensure that I'm not polluting my codebase.
In general I think the same rules apply to feature toggles regardless of whether they exist in the front or back end. You should have as few of them as possible, and they should live for the shortest possible time.
This way, your delivery of dead code to your customers is always temporary.