Idempotency is a crucial trait in the world of web APIs (and any other system where commands that modify state might need to be retried due to communication failures). It's not a new word or concept, but it's certainly a niche one.
I think you're conflating general "boringness" with tech-specific features. Test driving solutions is useful but it tells you nothing about reliability.
Say it's 2012 and you need a new car. Toyota Corollas have generally proven to be incredibly reliable. The Tesla Model S is brand new: definitely not boring. On paper both meet your needs, so you test drive both. The Tesla is way more fun to drive, and that's appealing, but if you just want your car to work for a long time with predictable maintenance, you should take the Corolla.
Choosing the most appropriate tech is not mutually exclusive with choosing boring tech. In fact, "boring" (well-known, battle-tested) is very likely the most appropriate because it reduces unnecessary risk.
I'd welcome the ternary conditional operator but I hope exception handling never gets introduced (at least as I'm used to it from Java, C#, JS, etc.).
Exceptions should not be conflated with regular error handling, especially when they're allowed to bubble up from anywhere. I very much appreciate that functions that can return errors force the caller to deal with them, for the most part. True exceptions can already be thrown with panic, although I actually find it incredibly rare that I need to reach for that tool. I'd argue that when people talk about exceptions they almost always actually want "unhappy path" error handling.
Now, if Go wanted to add a sleeker way to handle those errors, similar to Rust's approach, I'd be very interested. Minimum three lines for every call to a function that returns an error does get a bit verbose, arguably hurting readability. A little sugar could improve readability without making error handling implicit.
But the whole point was that it wasn't a separate role: it was a re-distribution of work so the developers were doing operations. Instead, a lot of people entirely missed the point and just renamed their ops people to devops.
Whether this is actually beneficial (let alone possible) depends heavily on the type of site.
Web apps that are valuable to use offline also tend to be the kind that really do warrant client-side logic and rendering (a spreadsheet web app is a classic example).
If the site's focus is providing information (e.g. Wikipedia), then working offline really just means loading all the backing data into the browser, which quickly becomes impossible.
I'm sure there are cases where offline availability is a huge plus (your site might be a good example), I just don't think it's universally applicable.
The author is reinforcing the false dichotomy between using front end frameworks and hand-rolled JS, as if rendering data from JSON APIs is the only way to display information from the server.
Almost as an aside, he says
> Server Side Rendering is also no better, because while they can do certain things in more straightforward way, they break browser behaviour [...]
but he provides no examples or supporting evidence, so it's difficult to know what browser behaviour he's referencing. "SSR" is just how the web has worked since the beginning and it works very well. Maybe he's specifically talking about SSR as provided by Next? I've never used it, so I'm not sure what browser behaviour it might be breaking.
> The whole point of indication is to signal my intention to move, so that the car in my blind spot creates room for me to merge into their lane.
That is definitely not the point of a turning signal. The car that's already in the lane has right of way and it's your responsibility not to plow into them. If they opt to make room for you, great (that's just courteous driving), but it's not an obligation.
If you can't see the car in your blindspot when changing lanes, you're not doing a proper shoulder check, hence the blindspot warning.
> That is definitely not the point of a turning signal
Incorrect. The turning signal is called an Indicator, because it give other drivers an indication of your intentions. So you first look and check that it's possible and likely safe to merge. Then you indicate your intention. You then merge if/when safe.
Indicating an intention to merge into a narrow gap is fine - as long as you only merge when there is sufficient room to do so.
But if the car beeps at you just because you indicated - then there is a design issue.
> If they opt to make room for you, great (that's just courteous driving), but it's not an obligation.
Absolutely - I was not implying it was an obligation. I am only saying that you use your indication to indicate to other drivers your intention. It is totally valid to turn off your indicator and not merge after indicating.
That said, I still think it's a generally good feature. If a person is distracted and fails to see the vehicle in their blind spot during their inital shoulder check, that beep might prevent an accident.
On my vehicle that warning can be disabled, which I think is the right way to provide features like this. People who find it useful can leave it on and people who find it distracting can turn it off.
The one time I rented a car with this feature, it claimed there was a car in my blind spot when there was none. It seemed to be reacting to a car that I had already determined was clear of my path.
When I write the code I know what my intention is with each line. Sure I can (and do) make mistakes, but identifying those mistakes during debugging is relatively easy during debugging because I can clearly see the discrepancy between what I intended and what I did.
With an LLM I must first understand (usually really just infer and guess) its intention, which is much more difficult.
is the LLM not acting on your stated intent? maybe you can find a middle ground, where you can plan and act in small enough chunks that it doesn't start getting its "own" ideas about what to do, or how to do it
a chainsaw is a coarse tool and I liken it to vibe coding. you maintain at least some level of control, but the edges are rough and you might slice off more (or less) than you meant to. I want to model my usage more like a table saw, a precision instrument that can make the exact cut just as I planned it
https://grapheneos.org/
reply