loading...

Feature toggles in the front-end - useful pattern or delivering dead code? #discuss!

lexlohr profile image Alex Lohr ・1 min read

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 they apply is very different.

A feature toggle in the back-end will not expose the toggled code to the customer until it is activated. In the front-end, unless the feature is loaded only after its activation, it will be delivered and at least partially exposed to the user. There are several ways to reduce the exposure, ranging from hiding the feature behind display: none; to not executing the code.

The former will dirty up the DOM with hidden elements while the latter will still mean that you deliver dead code to the customer.

Please discuss how for you the advantages outweigh these drawbacks or not.

Posted on by:

lexlohr profile

Alex Lohr

@lexlohr

...former musician, voice actor, martial artist, turned senior front-end developer.

Discussion

markdown guide
 

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.

 

"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.

 

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:

Most users won’t use every single feature of your site