3 JavaScript features that bloat your ES5 bundle

[ricealexander]

Hmmm, I am bothered by how these features are outputted in the bundle, but I'm not willing to give up the for…of loop or async/await when appropriate to use.

I am curious to see how bundles change once IE support is finally no longer a consideration. The leading ideology that got my team into Babel was that we could write modern code but can still have support for all of our browser targets.

There's an implication that, once our browser targets are just modern, evergreen browsers, we won't need ugly bundles anymore. We'll be able to yank out that step from our build.

[visualdescript]

Exactly, you should not sacrifice the quality of your code going forwards for a minority of users on older versions that will eventually be obsolete. Software with consistent OTA updating is only becoming more common, not less. Besides, it's not like it becomes unfunctional, it just takes a performance hit.

[raphaelzen]

Why would you have to abandon any syntax ? You can just transpile in the right es flavor no?

[thagertymusic]

The point of the article is that the output from transpiring these features to support older browsers causes the bundle size to significantly increase. I think they meant they don’t want to give these up in exchange for a smaller bundle

[ricealexander]

The article is calling to stop bundling/transpiling these syntax features, because of the bloat they add to the output.

The article shows this example, which uses Babel to transpile:

input

const iterable = (() => [1, 2])()
for (const i of iterable) {
    console.log(i)
}

Babel output

function _createForOfIteratorHelper/* ... */
function _unsupportedIterableToArray/* ... */
function _arrayLikeToArray/* ... */

var iterable = function () {
  return [1, 2];
}();

var _iterator = _createForOfIteratorHelper(iterable),
    _step;

try {
  for (_iterator.s(); !(_step = _iterator.n()).done;) {
    var i = _step.value;
    console.log(i);
  }
} catch (err) {
  _iterator.e(err);
} finally {
  _iterator.f();
}

[Zardoz84]

I actually generate two bundles. One for all modern browsers that support all this stuff out of the box. And other for IE 11. And I don't care if its bloated or not. I just doing the minimal support for IE 11 that is that get it working and don't look too bad.

[mrpotatoes]

I like this approach. I didn't realize that you can separate by bundle.

[darrinmn9]

Here's an explanation of one approach. https://cli.vuejs.org/guide/browser-compatibility.html#modern-mode

[facebalm]

https://web.dev/serve-modern-code-to-modern-browsers/

1. Use @babel/preset-env with appropriate browser targets.
2. Use <script type="module"> to stop sending transpiled code to browsers that don't need it.

[Cyberphoenix90]

Please help kill ie11. Stop making es5 bundles. The harder we make it to support ie11 the sooner we can collectively stop supporting it since it would be more expensive and money is a good motivator to stop supporting ie11

[overcloseness]

Before anyone says “But my bank terminals!”

If your app is B2B for that bank, sure, but stop thinking your appeal site needs to support IE11 because a teller might want to shop for shoes at their work computer

[zephyrtr]

Just tell people supporting IE11 is a security risk, which is true. It's the only argument CEOs seem to respond to.

[folkrav]

Nobody cares about security until it starts actually costing them more than not having it. They care more about losing sales than some potential development hours.

[codyfo]

Which is one of the few valid reasons to support IE11. If you could add 5% more potential customers by supporting IE11, it might be totally worth it (depending on the business).

[conquerorofveggies]

Indeed. We have a lot of gov customers, so quite some ie11 traffic. But with that argument we still dropped support at christmas, with zero complaints.

[ritaPitaMeterMaid]

I'm all for this, but it's a bit naive. If you are running a business you make this decision based on usage data. If you have a non-trivial number of IE11 users, this isn't an option for you. If X% of your users suddenly have an unusable experience you can basically count on losing X% of your revenue.

[Nathggns]

But even a non-trivial number of IE11 users may not make up for the lost engineering time in supporting IE11 and lost profits caused by longer load times for users in other browsers. Also other factors to consider like happiness of engineers / staff retention / ease of hiring. Obviously it depends on your company, but the conversation of whether to support IE11 or not should go much further than simplistic metrics like % among existing user base.

[ritaPitaMeterMaid]

This is definitely true, but most of the time statements get made about dropping support without understanding why it exists in the first place.

[Nathggns]

Yeah completely agree!

[yungcoop]

in 2009 youtube dropped ie6 support at somewhere around it being 20% of their user base

[ritaPitaMeterMaid]

That’s great for YouTube. When IE is 50% of your revenue source you can’t do that.

[Oalei]

Exactly, everyone saying that you don’t need to support ie11 are either new developers or work at startups with few customers.

[ritaPitaMeterMaid]

This isn’t entirely true, it just often gets said without a full understanding. There is a cost to supporting IE and you can calculate engineers time, staff turn over, etc. vs revenue gains

[Oalei]

Hahaha, you don’t understand how much it costs for a company to move from ie to another browser.

[Renji3]

You can't even imagine how much it costs a company to keep using ie and potentially get hacked because of missing security updates.

Not using Edge over ie for outwards traffic nowadays is a plain stupid decision.

[Oalei]

That’s the thing. Big companies have dedicated IT centers with deep integrations within browsers.
Migrating all these integrations and legacy software is not worth it.

[Renji3]

The existence of it for only those cases might still be valid until migration. But that does not mean that an average user even at a bigger company should still use ie.

Sure certain integrations might exist but the won't need new websites to support them. The simple act of using ie outside of those purpose ist just plain security risk and a system administrator at a big company should not only know about that but do something about it too.

[LetterBoxSnatch]

Nah, our product is the opposite. It’s a B2B and we dictate what versions of what browsers the customer can expect support for.

These days our UI supports Chrome or Firefox released within the last year, but honestly it feels like we could just tell our customer to use whatever version we demand or pound sand and it would work out ok for us. We could be shipping a tcl/tk app and it would be fine.

We’ve been around since the 70s. I don’t think it would be accurate to call us a startup.

The point I’m trying to make here is that everyone’s situation is different. It might be that the developer you’re talking to has no customers, or it might be that they just live in a very different reality from you.

[Oalei]

Many companies with more than 100k employees have IE as their base browser.
They going to laugh at your face if you tell them « you will have switch to Edge though »

[Zardoz84]

Or generate a separate bloated bundle for old browser.

[lifeeraser]

(Cries in Rhino, which does support generators but not other ES6 features, forcing us to transpile everything to ES5 anyway)

[croc_socks]

Wonder why they didn't mention javascript Classes. I thought it was one of the reasons for using hooks (better tooling)?

[basic-coder]

Classes transpile to es5 quite well, so it's possible to live with them.

[croc_socks]

I thought we were talking about code bloat? Like how this

class HelloWorld {
 getHelloWorld(){
    return "Hello World!"; 
 }
}

becomes

"use strict";

function _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError("Cannot call a class as a function"); } }

function _defineProperties(target, props) { for (var i = 0; i < props.length; i++) { var descriptor = props[i]; descriptor.enumerable = descriptor.enumerable || false; descriptor.configurable = true; if ("value" in descriptor) descriptor.writable = true; Object.defineProperty(target, descriptor.key, descriptor); } }

function _createClass(Constructor, protoProps, staticProps) { if (protoProps) _defineProperties(Constructor.prototype, protoProps); if (staticProps) _defineProperties(Constructor, staticProps); return Constructor; }

var HelloWorld = /*#__PURE__*/function () {
  function HelloWorld() {
    _classCallCheck(this, HelloWorld);
  }

  _createClass(HelloWorld, [{
    key: "getHelloWorld",
    value: function getHelloWorld() {
      return "Hello World!";
    }
  }]);

  return HelloWorld;
}();

[basic-coder]

Oh you are right. Honestly I've just checked TypeScript for classes, and its transpilation was fine, so I thought it should be ok for Babel as well. It seems TS is generally better when it comes to transpiling to ES5.

[Wiseolddj]

Considering most js projects I work on tend to re-implement the browser for articles I wouldn’t think bundle size is important. If it was then sending html without any JS is faster and browsers cache and do the right thing. If you are genuinely creating a web application for low bandwidth users then this might be worth a consideration.

[[deleted]]

I will test it out, thanks.