twhitmore

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.

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.

https://literatejava.com/exceptions/ten-practices-for-perfec...

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.

https://literatejava.com/exceptions/checked-exceptions-javas...

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.

Difficulty & cost evolving the interface between microservices can seriously hinder improving the actual product.

I've seen the misguided adoption of microservices affect a couple of companies & products.

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.

http://literatejava.com/documentation/how-to-write-good-wiki...

Exactly this. At this point the obsession with categorising potentially useful & useable behaviour as UB should be widely acknowledged.

Greed, excess and short-term capitalism.

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.

Perhaps I can share my personal experience. I have always felt tired/ crashed after having sugary foods. Sugary cakes & chocolate can leave me feeling pretty unpleasant. It might have been workable if eating more restored my mental state, but it didn't.

I figured this out in my twenties, stopped eating convenience food with sugar (cookies, sweet crackers, instant noodles, breakfast cereals), and instantly felt better.

I eat a high-protein breakfast of multigrain toast, avocado, cottage cheese, red onion and ham.

When you eat decent food with protein and vegetables you won't have cravings any more for sugary rubbish.

I snack on roast nuts (no peanuts), eat slightly more often and, for a pick-me-up in the afternoon, eat a small sandwich/ piece of sushi/ etc.

I am occasional only with desserts, cakes and ice-cream; typically only after dinner. Quality makes a big difference; quality cakes for example are mainly eggs, butter, chocolate and a bit of sugar whereas cheap cakes are sugar sugar sugar, refined flour and artificial flavours. Protein and fat seem to help stabilize the effects of dietary sugar on my blood sugar levels and mood.

My personal experience, YMMV.

Haven't read the full paper, but several aspects of this sound less than fully reliable.

It reminds me specifically of 90's multi-client LAN database systems (dBase, Clipper) where clients coordinated via file locks. Unreliability & hangs became a big problem for us.

In the summarized RDMA database, I'd be pretty concerned about reliability & integrity:

1) Crashed servers will leave records locked, and the system will hang. 2) Question whether lock timeouts can be adjudicated reliably. 3) Any errors in server behaviour can easily & widely corrupt data across any other nodes. 4) Overall the RDMA coordination makes me cautious. Can we really replace Paxos with RDMA reliably? If not, problems squeeze out elsewhere. 5) Proposed single-threaded recovery procedure sounds a hazardous operational bottleneck. 6) I'm also cautious about coordination requirements around recovery/ or to transact knowing that recovery is not in process, unless we can show that can be reliable & not add cost to the protocol.

Yes. The Archive version seems fine though.

https://web.archive.org/web/20230327033150/https://www.wired...

Behaviour is what needs to despatched, and behaviour is what benefits from applying eg. strategy pattern, delegation, orchestration.

Extracting important business behaviour into objects allows applying OO (ie, powerful despatch rules) where it is valuable.

Subtyping your model to achieve many of these possible usecases would give poor design results.

For example, if payment processing were in Payment.process() the Payment entity would need to be subtyped or composed for any of 1) a different payment gateway, 2) a sales tax in a new jurisdiction, 3) a new confirmation, or 4 a new payment flow. Having all that in your model entity is probably wrong.

Simple behaviour is fine in the model, major business TN usually not.

Limited in size as URLs encounter size limits:

https://stackoverflow.com/a/417184/768795

I wouldn't consider state in the URL fully general, as data can easily exceed that for many apps; but it's a useable technique where it fits.

Meaningful individual parameters are preferable, but similar size limits apply either way.

Cliff Click & John Rose on the JVM's subtype check -- achieving complete subtype checks in only 3 instructions and 1 memory reference, essentially all of the time.

Nice paper for those interested in language implementation & optimization.

My understanding is that radioactive waste volumes & activity differ based on reactor type. Light-water reactors (PWR/ BWR) only burn 3% of the fuel energy hence leaving large energies as mid- and high-level radioactive waste.

Heavy-water reactors such as CANDU can achieve greater burn-up, can avoid enrichment, and even reportedly burn waste from PWRs as fuel. There are downsides but to my mind they seem small.

https://en.m.wikipedia.org/wiki/CANDU_reactor#Fuel_cycle

Eclipse IDE (Java) can run your project, even if it doesn't all compile.

I expect this must be fairly common among IDEs with incremental compilers. You can run valid sections & gradually progress the complete correctness. No need for a dynamic language.

With static typed language, reliability and refactoring are easy.

I'm scripting some small scripts in Python this week but every time I come back to it, I am reminded how not actually very good it is.

I've had extensive experience on both sides of the fence -- working on apps within existing frameworks, and also maintaining custom frameworks & libs for apps using those. Unfortunately I find this article of very little value.

The author's claimed idea of "decoupling from the framework" is generally ineffective & impractical. It leads to extra layers of adapters & SPI with high cost and almost always zero value.

These sure add bloat & make the codebase pointlessly difficult to navigate, but are improbably unlikely to ever add value in allowing the framework to actually be changed.

Difficulties include mismatched abstractions, endless adapter layers, parameter types for methods also all needing to be abstracted, restricted capabilities, difficulty conveying behaviour/ dynamism rather than static values, and -- of course -- poor performance.

Results are severe choke-points hindering functionality, broken abstractions where stuff actually had to be done, and 90% of the SPI abstractions turning out worthless if you ever did try to migrate to another framework.

I'm an architect. I've seen people's non-portable abstractions so many times. The article's advice just seems so unlikely to help.

Pick a framework that offers long-term maintainability and lets you separate out your domain model & business logic, and just code directly in it.

Rather than railing against bad frameworks from limited experience (perhaps in rickety languages too), the author should perhaps spend some time to find a good one. Spring is fine for many purposes. The MVC is coupled at the front, but your domain model need not & should not be. Focus on that, which should be your business value.

As an architect working on maintenance & refactoring, I find regular value in being able to understand the context (issue tracker ticket) in which a commit was made.

Also more than mildly useful for devs doing porting work.

Commit comments are rarely substantive enough, and "asking relevant people" is nice but not an actual substitute for keeping meaningful records.

Capturing is not supported. That eliminates many normal regex usecases, where you want to be able to capture & interpret the data.

The right abstractions?

React's functional components are a monument to concept over practicality, and the overall ecosystem is a hot mess.

Populating initial state should not be a difficult special case. Handling state changes should not be a choice of esoteric extras. These are just basic requirements of any reasonable application.

React got quite a bit right, and it seemed cool at the start, but at a certain point the enthusiasm for "concept" diverged from actual requirements.

I laughed at the authors CS Salad, B Noodles and C Fajita -- Google in that case having parsed a cafeteria lunch menu.

I agree -- the OP said space for all the separate HTTP response variations might be an issue, and "With a smart enough storage format all of these could be solved".

I think he misses that storing HTML and having a webserver turn this into HTTP responses, might be exactly the storage format that solves this problem.