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.
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.
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.
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.
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.
> The whole thing stinks. Will Rome Tools employees get called out and shamed in public if they don't have enough visibility on their github profile?
I had no idea he had started a competing project. This really stinks, almost like he is sabotaging his competitor.