If I: - built Project A - left Project A and started the competitor Project B - contributed a lot of PRs to Project B each week, and - saw that a guy in a similar role at Project A, has relatively few weekly contributions to Project A

My eyebrows would be a little raised. Not that I would call them out in a tweet, but I would at least be curious where that guy is spending his time.

The problem with that mindset is that there is a huge difference between leading a greenfield project with very few users and leading an established project that's a major piece of the infrastructure in basically every front-end app. In the former case, the bulk of the work is actually building the functionality, so looking at PRs / commits can make some sense. In the latter case, there are more constraints to consider and a lot of the work is in determining _what_ needs to be worked on, as opposed to actually writing new code. Also in things like project management, fundraising, etc., which don't show up as GH commits.

> My eyebrows would be a little raised. Not that I would call them out in a tweet, but I would at least be curious where that guy is spending his time.

It is one thing to raise the issue in private with "Project A", another thing is to tweet this to thousands of followers. Especially after "Project A" already had resolved the issue on its own.

Why? Once Project A gets to feature complete, does it need to be worked on at anywhere near the same rate? Other than fixing bugs/upgrading because of APIs they are using upgrading, the number of commits should be really small. Or should people change CSS constantly to have a string of useless PRs?

At that point, a huge amount of someone's time is spent managing bug tickets, attempting to isolate debug, etc.

Rome isn’t anywhere near ready to compete with babel.

Honestly the very idea of a JavaScript compiler like that is destined for obsolescence per standardized features added to browsers.

Folks should just develop their own shims where necessary and TEST AGAINST VARIOUS BROWSERS.

Sure no one likes doing that, but it’s important to follow the fast-pace ECMAScript adoption.

> TEST AGAINST VARIOUS BROWSERS

I mean, how does that not just push all of this towards companies and open source solutions that provide access to old browsers and what not? I mean no matter what direction you push, it's going to be someone else's open source code that needs money.

You’re right that was an off topic note.

I guess what I’m getting at is that most current browsers support very nice JavaScript features anyway. And instead of adding yet another layer between our code and the browser—embrace the current generation of (at this point very robust) language features available.

And if that’s not good enough use something like TypeScript!

> most current browsers support very nice JavaScript features anyway

Maybe that's true for users in the western world. However, if you are in the asian market, there are popular browsers you've nerver heard of (some localized fork of chromium that's way behind). That is not to mention the poorer populace of the world still uses whatever that runs on WinXP or something, if they have Internet at all.

As software engineers it's not our job to use technology to dictate (control) how people access information, telling them to use newer browsers and newer hardware and what not, our job is to support as many people out there as we can.

Well put... However, the unfortunate thing about web technology is that websites no longer support NOSCRIPT. If we want true global compatibility, it’s HTML + CSS and ZERO JavaScript. That has immense privacy benefits too.

babel is a transpiler, which is more than just a way to shim shim features in browsers.

God I hate this word, it's like in bad OOP where you classify things just for the sake of having more classes. This belongs to a class called compiler, just call it compiler.

It has a specific meaning that is distinct from compilier.

You might call it a tanspiler and technically it IS. But the Babel homepage calls it a compiler.

In any case, for the plethora of down voters: Babel states: “Use next generation JavaScript, today”

At some point next gen == current gen, and therefor given enough stability, Babel becomes obsolete.

Folks, donate to Mozilla instead they actually move things forward not backward.

This assumes that javascript has stopped evolving at some point.

Actually, it assumes only that evolution of new features slows down. Once things are _slow enough_ the value of an extra dependency is dramatically reduced.