I've always been skeptical of the JS community's mania for Babel plugins and compile-to-JS languages, and honestly, working with the Mastodon codebase and trying to shrink a 2.6MB JS bundle, I feel like my worst fears have been realized.

I've decomposed all of Mastodon's Babel presets into these plugins. If I remove a single one, I get some inscrutable error apparently caused by some other plugin in the pipeline. Feels like a big Jenga tower. 😞 #MastodonPerf

In my ideal world, we'd have two bundles:

1. ES6 without polyfills (for modern browsers)
2. ES5 fallback (using a "cut the mustard" test like fetch+Object.assign+etc.)

At this point I can't even figure out what the savings would be for #1 vs #2 because I can't get the codebase to compile *without* the Babel transforms. I wanted to try Rollup and/or Bublé too but those just feel off the table given all the JSX/spread/rest/decorators fanciness. Feeling like a JS curmudgeon here. #MastodonPerf

Like, in 99.9% of my JS projects I use vanilla ES5 and *maybe* ES6 modules, but only because then I can use Rollup to compile down to the smallest possible JS, which I then ship to consumers.

Performance is a top priority for me, and I just don't feel like syntactic sugar like arrow functions, template strings, const/let, etc. are so important that it's worth shipping a bunch of polyfills and transpiler bloat to my consumers. But I feel like I'm in the tiny minority on this one. #MastodonPerf

Anyway enough complaining. The goal here is to help make things better and not just tell these kids to get off my damned lawn. Back to reading about how Babel plugin order works and how to debug which plugin needs which other plugin. 😅 #MastodonPerf
OK, I take back what I said. I am a moron. The source of the error was Uglify, which of course doesn't support ES6. 🤦 I'm back on track, working on my "slimmer JS bundle for modern browsers" PR. #MastodonPerf
Actually I take back my take-back. Trying to string together Rollup and Browserify and Babel with about 20 different plugins to handle JSX correctly and I'm starting to get a taste of why backend folks smack-talk modern JS practices so much. Some of these things are configured in 3 different places and it's hard to tell which config is actually winning. I get an error message and it's impossible to tell which plugin/transform/package caused it. We've ruined JavaScript, folks. #MastodonPerf
So unfortunately I haven't managed to trim a single byte from the Mastodon JS bundle yet, but on the bright side I am drinking again, so there's that. #MastodonPerf
All right, I wanted to accomplish at least one thing this weekend, so here's a PR to simplify the Babel configuration to make it less confusing: https://github.com/tootsuite/mastodon/pull/2377 #MastodonPerf
Seriously though I am just trying to configure Rollup to do ES6 module-inlining on the codebase and this error has a cutesy little emoji, but I have no idea what's causing it or how to fix it. I literally can't even tell if it's rollup, rollup-plugin-babel, babel, or some babel plugin that is causing the error. I just want Rollup/Babel/whatever to ignore jQuery since it's defined globally anyway. #MastodonPerf
@nolan This is the kind of stuff that backend devs like me cry into our C++ textbooks about.

@maiyannah The thing is, I'm deeply embedded in this community: I've written Browserify transforms and Rollup plugins, and I personally know many of the folks who maintain Babel, Rollup, Webpack, etc. And yet even *I'm* a bit baffled trying to navigate this codebase.

This feels kinda like Perl, where every time you look at a new codebase you might as well be looking at an entirely different language. Wondering how much I've contributed to this situation. 😕

@nolan Oh yeah, there's definitely good JS and such out there, it's just, when we complain about javascript being a bit rubbish?  Yeah, THIS is what we're talking about.  It gets convoluted really quickly and I sometimes wonder if even the people who developed it really understand it.
@maiyannah We don't. We really don't. I work for a browser vendor and I've written over 100 npm modules and I've been doing JS for years and yet here I am researching what `babel-plugin-transform-decorators-legacy` is and why there's a legacy version and why we need this thing in the first place. 😕
@nolan "Maiya, why are you taking like three months pre-release to document everything?"

Basically, because this.

@nolan @maiyannah move fast and break thing mentality.

Backward compatibility doesn't matter .😕

@maiyannah There is nothing wrong with JavaScript itself; it's a pretty dang good language as evidenced by the fact that it powers this beautiful thing called the web, but because it's the #1 language in the world, it has a lot of different philosophies and fiefdoms and interests and they all kind of clash and conflict with each other at the same time.
@nolan Except that true is false, anyways ;)
@maiyannah Bah, that's what linters are for. 😉
@maiyannah @nolan 749 trillion devices use Java. Doesn't make it good 😋
@nolan Possibly ridiculous idea that I'm just throwing out there: Would it be worth looking into whether TypeScript could replace Babel in this case? In theory it supports almost all ES6 syntax as well as annotations/decorators, and can be run of JS files without porting them to full TypeScript.
@dpogue I feel hesitant to add yet another abstraction… :/ Also despite working at MSFT, I actually haven't used TypeScript yet. 😅

@nolan stupid idea: did you grep node_modules for that emoji?

Reading this thread, I feel your pain. I probably spent whole weeks of my life fiddling with our company's babel/webpack configuration; we joke about me being the "senior webpack consultant" 😄.
You talk about the JS community being too focused on DX - i would argue that many tools didn't really care at all about DX in a holistic/ecosystem-wide sense and we are just starting to move into a sane direction with approaches like CRA.

@nolan good. if you forget to eat or drink you die
@nolan It feels like the JS community is not caring about optimization a lot anymore, most people want their "it works, even in IE6" thing, and performance, size etc. do not matter anymore, because we can scale that at anytime.

@nolan same is with the choice of frameworks. Instead of working together to improve something, people think it's wise to jump ship and create their own thing, so now we have 1000 frontend frameworks, test runners, bundlers for every single purpose ever.

Which is absolutely not newcomer friendly and it's getting worse day by day.

@pixel The JS community these days seems way more concerned with developer convenience than user experience. 😞 I tried to raise the alarm over a year ago and got a bit heckled for it (http://www.pocketjavascript.com/blog/2016/1/25/composers-and-audiences).

Many of us working for browser vendors try to bring this up and we get slammed for it, because it's basically like insulting your customers (i.e. webdevs). Although TBF honey vs vinegar yada yada.

@nolan I don't see it convenient if I need 2 hours to set up a simple ES6 -> browser-compliant JS pipe because I need to test out all the tech I heard of to find one that works.

I know it has to do with experience and knowing a toolbelt, but it's kinda annoying that there is just waaaaaaaaaaaaaay too much out there, complete oversaturation in all terms.

@nolan I really don't like the JS ecosystem as it is right now.

God thanks I already have a somewhat solid toolbelt I use for a lot of projects, because otherwise I'd be completely lost in working on stuff.

@nolan I can perfectly understand competition of tools, and that is healthy as well

but...what's going on in the JS world is abnormal. Most languages I worked with usually have like the "big favorite" and a (few) competitors with a different mindset, equally good to use.

If I look at bundlers in JS...Grunt, Gulp, Webpack, Rollup, Fusebox...but...every outside dev asks themselves why there are so many and which one to pick in the end.

@pixel @nolan This, actually, is my barrier to entry into "proper" javascripting.  I know JS and can read it/hack on it on the wild if its pure JS, but fuck if I have time to figure out toolchains that take a day just to set up.
@nolan we live in the age of tooling... that came after the age of trivia... I wonder what will be the next age #JavascriptThroughTheAges