Live data from Hacker News

We shrunk our Javascript monorepo git size

jonathancreamer.com

131–140 of 226 posts

Re: We shrunk our Javascript monorepo git size

#131

> We work in a very large Javascript monorepo at Microsoft we colloquially call 1JS. I used to call it office.com.. Teams is the worst offender there. Even a website with a cryptominer on it runs faster than that junk.

We were all impressed with google docs, but office.com is way more impressive. Collaborative editing between a web app, two mobile anpps and a desktop app with 30 years of backwards compatibility and it pretty much just works. No wonder that took a lot of JavaScript!

You must be kidding about "just works". There are so many bugs in word and excel that you could spend the rest of your life fixing. And the performance is disastrous.

Re: We shrunk our Javascript monorepo git size

#132

> We work in a very large Javascript monorepo at Microsoft we colloquially call 1JS. I used to call it office.com.. Teams is the worst offender there. Even a website with a cryptominer on it runs faster than that junk.

We were all impressed with google docs, but office.com is way more impressive. Collaborative editing between a web app, two mobile anpps and a desktop app with 30 years of backwards compatibility and it pretty much just works. No wonder that took a lot of JavaScript!

What's impressive is that MS has such well trained customers that it can get away with extremely buggy and broken web apps. Fundamental brokenness like collaborative editing frequently losing data and thousand cuts of the more mundane bugs.

Re: We shrunk our Javascript monorepo git size

#133
post #127

Earlier quoted context omitted.

Ok. There are a dozen examples of exactly this behaviour, and exactly this argumentation in response over the years. Right now the most important thing for them is for people to start thinking the microsoft fork is the superior one, even if things are “backported”.

Which examples?

VSCode is a prominent one that is in everyones mind, its starting its journey into extinguish.

For more examples I would consult your local greybeard; since the pattern is broad enough that you can reasonably argue that “this time, its different” which is also what you hear every single time it happens.

Re: We shrunk our Javascript monorepo git size

#135
post #100

Earlier quoted context omitted.

We were all impressed with google docs, but office.com is way more impressive. Collaborative editing between a web app, two mobile anpps and a desktop app with 30 years of backwards compatibility and it pretty much just works. No wonder that took a lot of JavaScript!

> [...] and it pretty much just works. I beg to differ. Last time I had to use PowerPoint (granted, that was ~3 years ago), math on the slides broke when you touched it with a client that wasn't of the same type as the one that initially put it there. So you would need to use either the web app or the desktop app to edit it, but you couldn't switch between them. Since we were working on the slides with multiple peopl…

could it be a font issue?

Re: We shrunk our Javascript monorepo git size

#136

Hacking Git sounds fun, but isn't there a way to just not have 2.500 packages in a monorepo?

Yeah, have 2500 separate Git repos with all the associated overhead.

Can’t we split the packages into logical groups and maybe have 20 or 30 monorepos of 70-100 packages? I doubt that all the devs involved in that monorepo have to deal with all the 2500 packages. And I doubt that there is a circular dependency that requires all of these packages to be managed in a single monorepo.

Re: We shrunk our Javascript monorepo git size

#137
post #98

Earlier quoted context omitted.

As a German, I assumed he's talking about poor connection speeds.

You Germans have slow internet speed? Why’s that?

https://youtu.be/W1ZZ-Yni8Fg?si=493ozTdkEsXJnPpB does a good job of explaining it.

Re: We shrunk our Javascript monorepo git size

#138
post #76

Earlier quoted context omitted.

[flagged]

Why? You do realize their fork is open source? The fix described in this post have been submitted as a patch to the official Git project. The fix is improving a legitimate inefficiency in Git, and does nothing towards "embracing", "extending", or "extinguishing" anything.

It’s open-source at start, later it turns into open-core.

Re: We shrunk our Javascript monorepo git size

#139

Earlier quoted context omitted.

Why? You do realize their fork is open source? The fix described in this post have been submitted as a patch to the official Git project. The fix is improving a legitimate inefficiency in Git, and does nothing towards "embracing", "extending", or "extinguishing" anything.

It’s open-source at start, later it turns into open-core.

Is this fix evidence of that?

Re: We shrunk our Javascript monorepo git size

#140

I'm surprised they are actually using Azure DevOps internally. Creating your own hell I guess.

I find the “Boards” part of DevOps doesn’t work well for us a small org wanting a less structured backlog, but for components like Pipelines and the Git repositories it’s neither here nor there for us. What aspects of Azure DevOps are hell to you?

Some examples, in no particular order.

Hampering the productivity:

- Review messages get sent out before review is actually finished. It should be sent out only once the reviewer has finished the work.

- Code reviews are implemented in a terrible way compared to GitHub or GitLab.

  - Re-requesting a review once you did implemented proposed changes? Takes a single click on GitHub, but can not be done in Azure DevOps. I need to e.g. send a Slack message to the reviewer or remove and re-add them as reviewer.

  - Knowing to what line of code a reviewer was giving feedback to? Not possible after the PR got updated, because the feedback of the reviewer sticks to the original line number, which might now contain something entirely different.
- Reviewing the commit messages in a PR takes way too many clicks. This causes people to not review the commit messages, letting bad commit messages pass and thus making it harder for future developers trying to figure out why something got implemented the way it did. Examples:

  - Too many clicks to review a commit message: PR -> Commits -> Commit -> Details

  - Comments on a specific commit does not shown in the commits PR
- Unreliable servers. E.g. "remote: TF401035: The object '' does not exist.\nfatal: the remote end hung up unexpectedly" happens too often on git fetch. Usually works on a 2nd try.

- Interprets IPv6 addresses in commit messages as emoji. E.g. fc00::6:100:0:0 becomes fc00::60:0.

- Can not cancel a stage before it actually has started (Wasting time, cycles)

- Terrible diffs (can not give a public example)

- Network issues. E.g. checkouts that should take a few seconds take 15+ minutes (can not give a public example)

- Step "checkout": Changes working folder for following steps (shitty docs, shitty behaviour)

- The documentation reads as if their creators get paid by the number of words, but not for actually being useful. Whereas GitHub for example has actually useful documentation.

- PR are always "Show everything", instead of "Active comments" (what I want). Resets itself on every reload.

- Tabs are hardcoded (?) to be displayed as 4 chars - but we want 8 (Zephyr)

- Re-running a pipeline run (manually) does not retain the resources selected in the last run

Security:

- DevOps does not support modern SSH keys, one has to use RSA keys (https://developercommunity.visualstudio.com/t/support-non-rs...). It took them multiple years to allow RSA keys which are not deprecated by OpenSSH due to security concerns (https://devblogs.microsoft.com/devops/ssh-rsa-deprecation/), yet no support for modern algos. This also rules out the usage of hardware tokens, e.g. YubiKeys.

Azure DevOps is dying. Thus, things will not get better:

- New, useful features get implemented by Microsoft for GitHub, but not for DevOps. E.g. https://devblogs.microsoft.com/devops/static-web-app-pr-work...

- "Nearly everyone who works on AzDevOps today became a GitHub employee last year or was hired directly by GitHub since then." (Reddit, https://www.reddit.com/r/azuredevops/comments/nvyuvp/comment...)

- Looking at Azure DevOps Released Features (https://learn.microsoft.com/en-us/azure/devops/release-notes...) it is quite obvious how much things have slowed down since e.g. 2019.

Lastly - their support is ridiculously bad.

Post reply on HN