twhitmore

Scrap the entire PR experience, start again from basics. Fire the people responsible.

Github PR viewer UX is just horrible. The UI is bloated, slow and very very difficult to use. (For example, commenting on a Copilot comment frequently takes 5-8s to the UI to submit and update.)

Why not fix the garbage UI first?

If we could just see unresolved comments and CI status in a page that take 100ms to load and 1 second to scroll to the bottom, everything would be fine.

The problem is that it the PR Conversation page takes 20-25 seconds to load a scroll through; and is full of outdated reports from Copilot/ Devin that don't go away of themselves, and don't have a good UI to be dismissed, once they're irrelevant.

I'm outside the US so poor UI <-> server network interaction may be magnified. But for something that could be simple and reasonable, it's just overloaded with garbage and an appalling experience.

Fix the basics first. I'd fire the entire team and every single Product Manager/ UX Lead involved. Anybody from Github listening?

Bjarne Stroustrup has been pushing Profiles, which would allow C++ code (or the majority of it) to become type-safe and memory safe.

Contracts are useful, but don't guaranteed anything if type safety & memory safety can be bypassed.

I think the ISO panel made the right call. The real world consider memory safety & execution integrity to be critical issues, and C++ no longer to be viable. Without some major improvements -- I would consider this view to be correct.

Contracts are useful, but don't guaranteed anything if type safety & memory safety can be bypassed.

I think the ISO panel made the right call. The real world consider memory safety & execution integrity to already be critical issues (and C++ no longer to be viable), and they are correct. The WG has its priorities wrong.

I tried it on a job I'm applying to, I like it!

Great work guys.

I liked Fable 5, as it didn't gabble like Opus did. It was good at clarity & conciseness.

Fable 5.1 -- to my early impressions -- seems to have gone backwards again.

Opus 4.8 was terrible for babbling self-invented jargon. (But still better than other options at the time for coding and logic.)

Good article, and I agree with the author's enthusiasm.

However his points that "cheap parts are a great enabler" and "shipping costs are high to Trinidad and Tobago", while true, don't actually counter the OP's points that "feature determination needs to be universal" and "the instruction set is poorly designed".

Others have said application authors will code to the specific platform, but that's not true of library authors -- they need portability.

Why can the RISC-V team not get basic stuff like feature determination right? No matter how stupid the rest of the instruction set is, I'm with OP that the responsible individuals should retire from the committee.

A typical place this distinction is useful is that it determines whether the test-suite runs to completion with multiple tests, or panics/terminates hard on the first failure.

Some of it is Conway's Law, much though seems purely "cargo cult engineering" or "FAANG cosplay".

Less-competent devs and CTOs hear that Amazon & Google use it, then decide their 12-person team needs to rewrite their product as 5 separate services. I have encountered companies with 50 services where they needed 5, spending 60% of their dev velocity on overhead.

If you're contemplating microservices & haven't already nailed your business transaction boundaries, reliability mechanisms, idempotence, deployment management/ versioning, observability, testability and the operational discipline to run distributed systems you should just stop -- you have no freaking clue and you're going the wrong way.

Or not. For simple to moderate requirements, plain HTML with a small templating helper is genuinely simpler than React.

React’s complexity isn’t just components — it’s effects, state‑management conventions, data‑loading patterns, and the surrounding build ecosystem. If your UI doesn’t need those abstractions, adopting them early is pure overhead.

For these kinds of projects, React usually carries a much larger total cost than vanilla HTML + JS.

The “vanilla becomes a bespoke framework” claim assumes the UI will inevitably grow until it needs framework‑level abstractions. Most UIs don’t. React front‑loads complexity even when the UI is small, while vanilla only adds what the actual requirements demand.

A few helpers aren’t “reinventing React” — they’re choosing a simpler design avoiding numerous unnecessary abstractions, and with lower costs & complexity for the moderate apps they're building. It's a very valid architectural choice.

Grid layout error in your CSS/ HTML, I think.

You've assigned `grid-area: main` to the content but the parent grid doesn’t define "main" in its grid-template-areas; the browser creates an implicit grid row/column to satisfy the placement, and this ends up being below the defined areas. Thus requiring 1 page blank space to scroll down.

You can investigate the `<div class="main-content">` in Dev Tools by toggling the 'grid-area' CSS attribute off; that fixes the display.