interf4ce

You've got the ideal hardware to move to GrapheneOS

https://grapheneos.org/

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.

THANK you![1]

Calling anything ops "DevOps" is right up there with calling JSON APIs "REST."

I know it's silly to let it bother me, but man does it get under my skin.

1. https://imgur.com/gallery/thank-you-lNUh0uV

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.

100%

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.

My apologies, then, I misunderstood your point.

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 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.

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.

I'm very interested in any alternatives you can suggest.

This is very interesting. I'm not sure what I'd use it for yet, but I imagine it could be useful for triggering ad hoc jobs over the network. Maybe have Home Assistant make a network call to kick off a daily back up when I leave the office at the end of a work day.

Protecting forms with reCAPTCHA uses cookies that fall under "marketing" and gathering site stats using Google Analytics uses cookies that fall under "marketing" and "statistics," making a consent banner or dickover pretty much required.

Are these services necessary for a page to work? Not at all, but many businesses consider them crucial. Unprotected public forms almost immediately start getting spammed by bots, burying real, important communications from potential clients. GA offers insight into what visitors to your site are looking for, which has real business value.

I don't like it any more than you do, but I get why businesses would choose to use these. On their end, at least with reCAPTCHA, they're just trying to protect themselves from the complete shitshow that the modern web has become.

It can be, see Global Privacy Control [1]. As an example, the Complianz consent plugin for WordPress can detect and respect the user's GPC setting, but that feature can be toggled. So even though this exists, many sites will still ignore it.

1. https://globalprivacycontrol.org/

I don't think that's the target audience here.

Proton makes safer, more private (than, say, Gmail) email a possibility for people who don't have much technical knowledge but who know enough to want to keep their emails out of Google's hands.

If you have both the knowledge and time to run a server, by all means, that can make sense (and can be fun!). It's just not as widely applicable.

I can't help but wonder if we've already hit the point where real people now write like that because it's what they're exposed to day in and day out.

I have zero evidence to back this up but I'm convinced that autocorrect is what led to people pluralizing word's with apostrophe's. If we keep outsourcing how we express our ideas, how long until we no longer have any left?

You're right, Electron is not inherently bad and apps need RAM. There's no getting around that.

The issue with Electron is that it encourages building desktop apps as self-contained websites. Sure, that makes it easier to distribute apps across systems and OSes, but it also means you've got front end web devs building system applications. Naturally, they'll use what they're used to: usually React, which exacerbates the problem. Plus it means that each app is running a new instance of a web browser, which adds overhead.

In real life, yeah, it's rare that I actually encounter a system slowdown because yet another app is running on Electron. I just think that it's bad practice to assume that all users can spare the memory.

I'll admit that my concern is more of a moral one than a practical one. I build software for a living and I think that optimizing resource usage is one way to show respect to my users (be they consumers, ops people running the infra, or whatever). Not to mention that lean, snappy apps make for a better user experience.

The issue isn't usage, it's waste. Every byte of RAM that's used unnecessarily because of bloated software frameworks used by lazy devs (devs who make the same arguments you're making) is a byte that can't be used by the software that actually needs it, like video editing, data processing, 3D work, CAD, etc. It's incredibly short sighted to think that any consumer application runs in a vacuum with all system resources available to it. This mindset of "but consumers have so much RAM these days" just leads to worse and worse software design instead of programmers actually learning how to do things well. That's not a good direction and it saddens me that making software that minimizes its system footprint has become a niche instead of the mainstream.

tl;dr, no one is looking for their RAM to stay idle. They're looking for their RAM to be available.