gr__or

not-federalized != walled-garden

A walled garden implies captured user data and social graph, which is the decentralized part of Bluesky (ATProto to be precise). The difference to Mastodon (ActivityPub to be annoyingly precise again) is in funding needed to host the entire thing.

With ActivityPub, you have to find recluse with a war-lord who will now own your data and handle, and spend a not-too-insignificant amount to keep up the infra (enough that instances have folded due to finances). With ATProto, one has to find a seemingly sympathetic oligarch who does NOT own your handle or your data, and has to spend an average european income on keeping up the infra.

Different threat models, different game theoretical plays really

For the curious ones who are not so excited about gifting page views to the fascist:

https://xcancel.com/elonmusk/status/1881923570458304780

If you do cloud infra stuff, AWS will try to undercut you on price but will never outdo you on D/UX. So I wouldn't let Beezus hold me back

Cookie dialogs are a medium-size meh.

Browser choice vs Microsoft were a big win.

GDPR is a big win.

I'd say it's 20:1

It's par for the course with HN libertarian virtue signaling

There is a cultural divide on where you stand wrt transphobia. The default appview is indeed not down with it, where Twitter is ofc very down with it.

The protocol is ambivalent towards it, so if you seek hate, you could host your own. I'm very fine (happy even) with the bsky team not being invested in that side of history.

Economists, a conservatively skewed bunch, are not optimistic about his plans: https://qz.com/donald-turmp-taxes-tariffs-economy-simon-john...

The majority of women are not enthusiastic about his plans on that front either

I don’t understand how it’s different to Perplexity, looks pretty much the same. Can you enlighten me?

I think there is an interesting piece to be written about how prone bsky is to being captured by a single entity. It would look at how the reality of PDS today is 99.9999% (not the actual number, but ballpark) bsky hosted, also true for the relay. Then it would outline EEE scenarios, their likelihoods and whether bksy is sufficiently decentralized to fend them off.

This post is not that and misses the mark for me.

There is nothing I miss more in TS than pattern matching, so I came in with a lot of good will, but the syntax for it looks jarring to me. Might be a matter of taste, I'm not made for meaningful whitespaces

This has the essential bits of one of the most common critiques of React, its claimed slowness.

As a seasoned React dev of 10 years (aka a heavily biased person) I would claim 99% of this issue is better explained by: - React is the most popular choice => used in all kinds of places by all kinds of people - with varying skill - under all kinds of business pressure to deliver features => a lot of slow apps in React

I'm not saying a case for specific areas where React is slow can not be made, these anecdotes just don't do it for me.

We do have the synthetic framework benchmark, where React is indeed one of the slower candidates. I have yet to build an app with functionality akin to adding 10s of millions of rows, so it has not been an instructive decision driver for technology choice. The project I have been working on (also in Vue, Svelte, SwiftUI) had their bottlenecks in other places.

The non-synthetic argument in favor of React passing the performance test is billions of people using FB, Insta, Netflix, MS Office (to name some of the big React apps), about which I have not much in terms of complaints.\ This is usually where the second big React critique kicks in: it being a Fortune-500 framework. That has not been my non-fortune-ate experience.

I think a residual argument can still survive this: I/my org has not been able to write performant React. I'd be curious to read someone go into the details of where it broke down and how switching view layers solved for that specific situation (I hope that does not read cynical, I'd really be curious).

This kind of feels like an accidental release, would not expect one of the big frameworks to drop a new major with so little doc around it?!

absolutely beautiful mission, thank you!

I'm jazzed about Jazz, I think Anselm got the priorities right and I'm excited to use it soon. If you get the chance to hear him talk about it, I highly recommend that too!

I am very non-eager to help any further platform grow that has not been built on-top of sth like atproto (the BlueSky protocol), to prevent silos and the monopolist landlords that come with those.

Great idea though, would love to use sth like this, if it existed on a federalized protocol.

let the record show that we're talking about 6 years

I've been a React boi since day 1, was happy to leave v1 Angular behind back then. Since then, I've played with them all, and have had a couple professional experiences with Vue, one very recent:

It is not close to React in terms of maturity, which is for me the largest issue with it, especially around TypeScript, Storybook and bugs. In my 10 years of React I have not encountered a single bug in it (not saying there weren't any, I just wasn't affected). In my month of Vue I had one blocking tooling bug and one ripping-my-hair-out-for-a-few-hours core bug. On the upside, a Vue contributor had a video call with me on the former and Evan himself fixed the latter within a day or two

Docs are mostly good, but React wins here too. What React Docs do really well, and what might be under-appreciated, is talking about trade-offs and pitfalls. Vue could use some of that, especially since it promotes mutability as its most idiomatic path, which can have subtle side-effects one should be mindful of. And I would bet many people, coming from more immutable frameworks, fall head-first into these pitfalls.

Vue, like Svelte, is (since v3 afaik) all-in on SFC (Single File Components). I personally dislike the singular focus on this style of component-ing. I like having multiple components per-file, doing higher-order component-ing (e.g. having a record of components) and having other exports from the same file. Sure, one could probably work around these by adding more files, but I don't like it when frameworks incentivize spraying files. I also have that critique with Next.js, though I find the bundler-boundary trade-off argument more convincing there. I do like the ease of co-located styles though!

An interesting nut that I'm trying to crack is how I feel about Vue's model-binding. Binding a state variable directly to a component, without separately specifying the getter & setter like in React, does make for more concise code. But then there is the aforementioned pitfall of this leading to mutation and possible spooky actions at a distance.

So my summary is: Some interesting differences to React, but overall not worth the divergence and community energy splitting. I think the things React is innovating on are still the most interesting ones in the view-library ecosystem. That said, I found the Vue contributors to be very nice people to interact with.

Awesome, bookmarked!

Looking forward to login being oauth based, but from what I've vaguely remember skimming these weeks, that's an @proto limitation that is being worked on?!

Pardon the delayed response, I'm not sure if this will still reach you but I'll type it nonetheless.

I unfortunately am not very fast at reading Tex so I could not quite grasp it. My main touch points with literate programming were probably iPython Notebooks and ObservableHQ. I like interspersing code with (rich) text, and starting with a top-down view of a codebase is imo also the way to go.

I'm less sure about the macro bits, I have yet to see a language where it makes for sane means of abstraction. It certainly solves for a hole in our meta-programming design space, but I don't think we've found the right hammer for that nail yet.

From the ones I know of, Pharo is probably closest to my vision, though it is still very far from it, being brutally OOP (the obtuse kind, for me at least) and it still puts a wall between code and visualization. A wall which I intend to tear down.

Thanks for the Hesse recommendation, first time I'm getting one in my native german on this site.

I'm sure I'm making JBlow very unhappy with my choices of technologies and my disregard for performance (for now)

I was wondering these days if something like this could exist. Can one follow along somewhere?

I'm finally frustrated enough by the state of coding that I'm developing my own coding environment and language. The leading question is: What if UI was first-class while programming?

Happy to elaborate if anyone is interested, I will also write about it on my blog (https://watwa.re) at some point

> In many cases animals graze on marginal land that can’t be used to grow human food directly. In these cases the alternative ways to get the same protein production could imply cutting down land in other countries to grow protein rich crops for humans.

Just to make the implicit explicit: the current reality of meat production is feeding livestock with protein rich crops grown on cut down land in other countries. An alternative’s model scalability and economic viability has not been shown yet.

So the hope of such a thing existing in the future should probably not influence how you choose to nourished yourself today

Came here for exactly this, the post is proposing a solution while only understanding one half of the problem.

Toasts are a global UI feedback mechanism for non-blocking/fallible/undo-able actions. That does make them out-of-place by default, but at least consistently so.

A solution I'd accept is local-view-first with toasts-as-fallback when the view is dismissed. That said, loading indicators _might_ make users hesitant to dismiss a view.

Caleesi voice: React wasn’t invented to stop the wheel of MVC, it was invented to break the wheel

And I think life is better without the V-C distinction. Models ofc still exist but the field has gotten more fine grained for the term to still cary meaning

I find it dubious to make this comparison in an article which does not talk about EQ, but about ability (willingness?) to play company politics. I'd wager that one is *at most* slightly correlated with EQ.

The general critique is: McKinsey over-optimizes on short term profitability over meaningful, longer term, harder-to-measure values. Your framing drops the most important aspect of the critique to make it sound contradictory.

Thanks for your hard work on making JS safer. You were working on exactly what I am missing most, sane error-handling. I hope TS picks up where you left off at some point.

I was also happy to see the shout-out to Ben's Ezno. I'd recommend people start sponsoring that kind of work, it has the potential to make our JS life much saner.

Yeah it's kind of mind-boggling to me that the creators of React (which SwiftUI is ofc heavily inspired by) and the most successful cross-platform quasi-native library (React Native), have not managed to bring those powers to their biggest investment.

I truly don't get it.

Just as a point of fair comparison, here is their prompt for CSV parsing in Rust (brought to you by Gemini):

  use std::error::Error;
  use csv::Reader;
  use reqwest::Client;
  use serde_json::Value;
  
  #[tokio::main]
  async fn main() -> Result<(), Box<dyn Error>> {
      // Define the CSV file path
      let file_path = "data.csv";
  
      // Open the CSV reader
      let mut reader = Reader::from_path(file_path)?;

      // Create a new HTTP client
      let client = Client::new();

      // Iterate over each record in the CSV
      for record in reader.records() {
          let record = record?;

          // Get the value from the first column
          let url = record[0].to_string();

          // Perform GET request
          let response = client.get(&url).send().await?;

          // Check for successful response
          if response.status().is_success() {
              // Read response body
              let body = response.text().await?;

              // Parse JSON
              let json: Value = serde_json::from_str(&body)?;

              // Process the parsed JSON (e.g., print it)
              println!("JSON for URL {}: {}", url, json);
          } else {
              eprintln!("Error fetching URL: {}", url);
          }
      }

      Ok(())
  }

The thing that makes it perfect in Rust, that you can keep the above for a simple script, but if you want to solidify it you just think about how you want to handle the `?`-annotated spots (retries, error-repacking, panics, etc.)