Feature toggles, like a lot of other paradigms and patterns from the back-end are becoming popular in the front-end. However, the context to which ...
For further actions, you may consider blocking this person and/or reporting abuse
"Code splitting" seems to apply here. Lazy loading parts of your code is a feature of Webpack. survivejs.com/webpack/building/cod...
I'm actually not really sure how exactly it is approached with Webpack, but I've implemented my own sort of this thing because I'm a bit of a performance nut.
I feel like this makes sense for the use case if Webpack's features make it less messy. If it's easy enough to define what code never gets requested to the front end without creating weird race conditions, this seems like an approach to lean into. Not sure I've thought through the whole problem, but that's where my mind goes. Would love some more input.
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.
You're always delivering dead code to some extent. Most users won't use every single feature of your site, so part of that code will be unused. Just see how big of a difference it makes in the size of your JavaScript, and if it's a big difference, load the JavaScript that's needed for this feature asynchronously. Most JavaScript build tools, like webpack, have functionality for code splitting built-in.
I kind of hear you. Yesterday’s code is already dead code. But I do think that having metrics (like what I shared in my most recent article) help to avoid this problem you identified:
I found a nice table here for the minified package size:
I´m not sure, treeshaking works inside this packages, so you will deliver tons of dead code anyway....
So your point is: "we're already shipping loads of dead code, so a little more doesn't hurt"?
Not sure if I would agree. First, you can move on to the next generation of frameworks (Svelte, Solid, Qwik, ...) and already significantly reduce bundle size while second, all support tree shaking.
That being said, allowing the client to lazy load dynamic components for certain use cases would certainly beat bundles full of dead code.
My point is: we should not be too fuzzy about SOME dead code, if it is only a fraction of the complete package, including unshakable frameworks and a bulky codebase.
I don't think that one issue excuses the other. Yes, shipping dead code can be the right decision, but I think it should be at least a conscious one.