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.
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.
What an incompetence & embarrassment. This seems like a failure of product management, management & executives rather than actual software craftspeople.
Those responsible -- all of the people -- should be promoted to digging ditches.
Does the Zig language not have useful exceptions/stacktraces that can be propagated out?
At a high level, all non-trivial programming is composition. And (see principle of encapsulation) the vast majority of errors shouldn't be recovered and just need to be propagated out.
Then, to be useful, errors need enough information to be diagnosed or investigated. It seems like this should have been a straight-forward requirement in the language design.
Exception handling would be better than what we're seeing here.
The problem is that any non-trivial software is composition, and encapsulation means most errors aren't recoverable.
We just need easy ways to propagate exceptions out to the appropriate reliability boundary, ie. the transaction/ request/ config loading, and fail it sensibly, with an easily diagnosable message and without crashing the whole process.
C# or unchecked Java exceptions are actually fairly close to ideal for this.
The correct paradigm is "prefer throw to catch" -- requiring devs to check every ret-val just created thousands of opportunities for mistakes to be made.
By contrast, a reliable C# or Java version might have just 3 catch clauses and handle errors arising below sensibly without any developer effort.
Interesting to see Rust error handling flunk out in practice.
It may be that forcing handling at every call tends to makes code verbose, and devs insensitized to bad practice. And the diagnostic Rust provided seems pretty garbage.
There is bad practice here too -- config failure manifesting as request failure, lack of failing to safe, unsafe rollout, lack of observability.
Back to language design & error handling. My informed view is that robustness is best when only major reliability boundaries need to be coded.
This the "throw, don't catch" principle with the addition of catches on key reliability boundaries -- typically high-level interactions where you can meaningfully answer a failure.
For example, this system could have a total of three catch clauses "Error Loading Config" which fails to safe, "Error Handling Request" which answers 5xx, and "Socket Error" which closes the HTTP connection.
Checked exceptions were a reasonable idea, but the Java library implementation & use of these was totally wrong.
Checked exceptions work well for occasional major "expectable" failures -- opening a file, making a network connection.
They work extremely poorly when required for ongoing access or use of IO/ network resources, since this forces failures which are rare & impossible to usefully recover from to be explicitly declared/ caught/ rethrown with great verbosity and negative value added.
All non-trivial software is composition, so the idea of calling code "recovering" from a failure is at odds with encapsulation. What we end up with is business logic which can fail anywhere, can't recover anything, yet all middle layers -- not just the outer transaction boundary -- are forced to catch or declare these exceptions.
Requiring these "technical exceptions" to be pervasively handled is thus not just substantially invalid & pointless, but actually leads to serious rates of faulty error-handling. Measured experience in at least a couple of large codebases is that about 5-10% of catch clauses have fucked implementations either losing the cause or (worse) continue execution with null or erroneous results.
The examples at the start seem confused & poor. A type that "can return either one result, many results or an error" is trying to fit two different cardinalities into a single API.
APIs should either be typed to be unary (possibly with optionality/ error), or plural (allowing 0..many).
I've dealt with similar woolly design before. Introducing clear distinction between cardinalities gave a major improvement in logical clarity.
Interesting. The corruption was in a math.pow() calculation, representing a compressed filesize prior to a file decompression step.
Compressing data, with the increased information density & greater number of CPU instructions involved, seems obviously to increase the exposure to corruption/ bitflips.
What I did wonder was why compress the filesize as an exponent? One would imagine that representing as a floating-point exponent would take lots of cycles, pretty much as many bits, and have nasty precision inaccuracies at larger sizes.
This article is very interesting. I have previously noticed the contrast between strict state representations, and the messier practicalities of user- and externally-sourced data.
I like the insight of splitting Intent and State. There's a lot to the article & I'm not sure I fully understand the latter half yet, but I'm filing this one away for further exploration.
I don't know, I've met a lot of devs who've found the "true religion" of strict data integrity and have been reluctant to allow for the messier practicalities of user- and externally-sourced data.
None of them called Stanley, but there's definitely a fairly common pattern I recognise.
Yes, there's this amazing thing called "documentation".
Confluence works well if you KISS - write just what the audience needs to know, in terms they can read & find.
Avoid writing grand tracts of wanna-be architecture, policy, theory or planning; just write useful actionable material on topics your audience needs. You will find this works.
Source: I led 400 devs and this was the only way that could scale.
My particular beef is disposable/ short-lived goods -- the impact on the Earth of a product that lasts for 30 years is far less than one designed to need replacement after 5.
Yet weenie product managers & vulturous MBAs are constantly engineering things weaker & less repairable.
Sometimes to make the unit cost 0.5 cents cheaper, but perhaps more often to force earlier replacement and another revenue opportunity.
Chinese hackers intent on collecting intelligence on the United States gained access to government email accounts, Microsoft disclosed on Tuesday night.
Microsoft said that in all, about 25 organizations, including government agencies, had been compromised by the hacking group, which used forged authentication tokens to get access to individual email accounts.
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.