andyrichardson

Hype culture in developer tooling has gotten out of hand imho. A SPA with precaching is almost always going to be the most responsive experience.

Next and similar tools are decent if you NEED SSR and don't want to go the prerendering route - but there's some extra work involved.

Having used Fedora Silverblue in the past, I went all in on nixOS as it seemed perfect for me.

Setup was easier than Arch and I had more trust in the stability of the system because there's no state/config that I wasn't aware of (albeit after a learning curve).

The biggest issue though is how rigid it is. The "nix way" spreads like a plague into everything and I often felt like I couldn't do basic tasks such as install some node modules without having to relearn how to do it in nix.

I told myself that FHS was a good enough fallback, but that just wasn't the case. Despite using FHS for node development, I still encountered nix-specific issues that needed a nix-specific fix (i.e. using prisma binaries).

I'm stuck with a 15" 2018 macbook pro running macOS because of T2. I feel your pain.

But how does this compare to Rx?

Prior to my current job, OSS was just something that I did in my free time and considered an investment.

My current employer pays me for any OSS I do in my free time which is pretty cool. We collaboratively maintain OSS projects and are able to actively work on them when between client contracts.

I blamed the Chrome Web Store team at first but I can understand why they're anxious about allowing extensions onto the store which basically access everything on your browser.

The issue is the outdated permission spec for browser extensions (I've gone into more detail on another comment on this thread)

I want to share my opinion on this as it's something that I've spent a lot of time thinking and talking to the Chrome Web Store team about.

The very core of the issue here is less about the manual review process (although that sucks) and more about how the review process is necessary due to how extension permissions work in browsers to-date. The current process works similar to how Android and IOS permissions worked back in the day by requiring the user to grant all permissions up front (equivalent to giving an extension sudo permission to your browser).

The feedback you'll most likely get from Google on this isue is that the solution to this is to narrow down what URLs your extension works on... but that comes with a pretty big assumption that an extension can declare that information up front. Many extensions (including developer tooling) don't need to run on EVERY page - they need to run on specific pages where some extension-specific code is running (this is the case with Urql, Preact, React, Rexux devtools). Narrowing down by URL just isn't possible and an ad-hoc solution where extension-specific code on the webpage can trigger permission requests (similar to how a website requests access to your camera) is needed.

I've written up a proposal for this case which I think addresses 90% of use cases where "sudo permissions" are being requested up front and in reality, could be requested on an ad-hoc basis. Whether it's an agreement or some criticism, anyone who is able to get involved in this discussion - please do! Every other platform is using ad-hoc permissions and we need to push for the same with browser extensions.

Here's the proposal: https://groups.google.com/a/chromium.org/forum/#!topic/chrom...

Here's my rant on Twitter about this problem (see retweeted comment): https://twitter.com/andyrichardsonn/status/12529205656960040...

You're 100% right. Look at #1 of their leadership principles

https://www.amazon.jobs/en-gb/principles

As a customer and as a former interviewee, their motives were always very clear.

^^ This guy gets it