Not only is GitHub focused on AI, but they’re also making their UI slower and jankier by rewriting it in React.

I feel like a “Linear for GitHub” is due.

Uh... I have no idea what that was, just that the design is completely counter to any attempt to read it.

Which means, probably not a good replacement workflow for a daily driver.

Is it true that it is React’s fault? Is there any other replacement for heavy user interaction, that is clearly more performative? You cannot do that on server side.

GitHub worked great for 15+ years without React everywhere. I'm finding interacting with issues to be a whole lot jankier over the past few months.

IIRC only search is React. Everything else is still Hotwire or Hotwire-like, with numerous bugs

GitHub Issues is React now - I think as of a month or so ago. Try running the React Developer Toolbar on those pages to see.

> Is there any other replacement for heavy user interaction, that is clearly more performative?

Well-written React?

After reading a bunch of stuff as result of this, I think you are the most correct. Difference in performance on different frameworks seems to be more like philosophical rather than practical.

It is enough that your website has just a couple of images, comparison of the "shipping size" of the runtime bundling becomes rather meaningless. It is the same for initial latency for showing the rendered content.

These frameworks were designed for heavy sites, and their "base speed" becomes irrelevant. If you understand how do they work and use them correctly, there shouldn't be that much difference. Assuming, that we use JavaScript on client-side in the end.

How many well-written code bases have you seen?

React is a PITA to learn, and even the easiest frameworks encounter devs who jump right in and commit shot code to deliver "value" right away, only for that code to live on forever haunting the devs left with mess after the founder coders move on.

SolidJS

Vue, Svelte, Solid.

Yes, there are lots of better options. React is around the bottom 25th percentile of frameworks when comparing speed. https://krausest.github.io/js-framework-benchmark/2025/table...

In my experience performance issues in React also creep in without it being obvious when developing, especially across a larger team. It tends to be more obvious with server-side frameworks like django or rails.

Whatever is at fault, their code viewer now sucks. I often cannot even use basic text functionality like double click + drag to highlight/select whole words. It has become broken software at some point.

For the code search one annoyance that they introduced was, that one needs to be logged in to search a project. Another annoyance is how the search works. Why, oh why, do soooo many programs/websites/software things have issues searching for a simple 100% substring match? There should always be an option in a search for most software, to search for exact substring without involving any magic. Then the checkbox to optionally ignore case. Only when this basic search functionality is ensured, should they care about developing anything else.

Just selecting text in the code viewer is so broken it drives me nuts everytime. Thankfully you can just press "." to open VS Code Web with the current file open.

Linear? That website makes my laptop heat up like nuts.

If also hijacks standard browser shortcuts: I try to open the file menu with alt-f, but instead it (un-) marks the issue as "Favorite".

Fwiw im generally ok with this as long as hotkeys are customizable. Apps should behave like apps, and I like having the full array of shortcuts available

Holy crap, is that why it's felt so syrupy recently? What was wrong with the old implementation?!

It wasn't React. Everyone knows modern applications must be written in React.

We are in Hell. Ugh.

As a greybeard sysadmin, this is why I write pure html5/css3 with as little js as possible, and where it can't be avoided, vanilla with no frameworks.

I really have grown to hate most frameworks... (and I don't hate em, but for the devs who push them... it's become the new Java, another bane of linux admins everywhere.)

Linear itself has a workflow for Github: https://linear.app/docs/github

GitHub was ignoring users needs long before the AI craze.

It's hard to remember, but as soon as gitlab showed up, GitHub went from a "maybe someday if I make it" site to a "let's just use GitHub for everything" site.

Prior to gitlab ratcheting up the usability, features, and cost effectiveness, I preferred hosted git for 99% of use cases.

I just started using git, can you give me some advice?

Use it everyday, preferable with a porcelain such as magit in emacs.

Alias commands help.

Run your own git server instead of using one of the big names.

Use git hooks. (https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)

When starting out, looking at visuals of how git works can help a lot I've found when training others. (https://www.junosnotes.com/wp-content/uploads/2021/07/basic-...)

Is that why Gitlab doesn't innovate anymore? No point if GitHub just steals the features?

The Markdown parsing library I'm using supports MDX, so it shouldn't be too difficult to come up with syntax for those components. I haven't done that yet, but mostly because I didn't want to go down that path until I knew there was interest and had a concrete use case or two to inform the query syntax.

If you want to open an enhancement request issue, I'm happy to take a look (PRs also welcome, but not required). If you're not on GitHub, let me know and we can figure out some other way to get the request tracked.

Thanks for taking a look at the project!

I don't write rust and already have an MDX toolbox that fits my needs. Browser, GH, and IDE search / TOC are good enough for me.

I'm currently in a phase of trying to shed tools and added complexity, rather than add them

Fair enough!

it's a shame when core feature development seems to lag. i've also been working w/ MDX lately & agree that support would be a great addition.

> This is because GitHub is not building the features we need, instead they are putting their energy towards the AI land grab.

You throw the ball to where it's going. Gitlab might be delivering more value in the short term, but if things wind up looking significantly different in ten years, they might be in for a world of hurt. Innovator's dilemma is real.

It's a danger to ignore the tectonic changes happening. It's also incredibly risky to lean fully in, because we're not sure where the value accrues or which systems are the most important to build. It doesn't seem like foundation models are it.

It's smart to build basic scaffolding, let the first movers make all the expensive mistakes, then integrate the winning approaches into your platform. That requires a lot of energy though.

> That requires a lot of energy though.

So do the plagiarism machines!

> Bitbucket, by contrast, has a feature where you can block PRs using a checkbox list outside of the description box

I'm not sure this is better. I like the idea of the full context of the PR being available in a small set of relatively standardised fields. Smaller, non-semantic sets are easier to standardise.

I'm not sure how having a list of remaining tasks that can be added to adhoc and block PRs from merging is not better than check boxes in markdown description box that are little more than aesthetic...

It has saved us from self induced pain and is a great coordination point

Or maybe GitHub built these features over 10 years ago and millions upon millions of people use them daily without issue. You can literally have any semblance of what you're describing with a PR check, and that feature is also pretty old. The API is right there, you just have to use it.