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

Alex Lohr @lexlohr

About: ...former musician, voice actor, martial artist, started coding 38 years ago and turned front-end developer 25+ years ago.

Location:
Germany
Joined:
Jun 13, 2017

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

Publish Date: Oct 18 '17
16 8

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.

Comments 8 total

  • Frederik 👨‍💻➡️🌐 Creemers
    Frederik 👨‍💻➡️🌐 CreemersOct 18, 2017

    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.

    • Cubicle Buddha
      Cubicle BuddhaApr 17, 2019

      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

  • Leighton Darkins
    Leighton DarkinsOct 18, 2017

    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.

  • Ben Halpern
    Ben HalpernOct 18, 2017

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

  • Eckehard
    EckehardJul 26, 2023

    I found a nice table here for the minified package size:

    Image description

    I´m not sure, treeshaking works inside this packages, so you will deliver tons of dead code anyway....

    • Alex Lohr
      Alex LohrJul 26, 2023

      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.

      • Eckehard
        EckehardJul 26, 2023

        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.

        • Alex Lohr
          Alex LohrJul 26, 2023

          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.

Add comment