There are a number of things I don't like about mastodon.
1. The platform is outright hostile to discovery. You generally can't even index posts in a search engine. This is not what I want, at all.
2. Moderation is awful. Letting individual servers control moderation at their whim is not what I want. In contrast, Bluesky's idea of labelling services and opt-in moderation sounds amazing.
3. After point 1, it probably goes without saying that Mastodon is outright hostile to algorithms. While I agree that algorithms can be very problematic, Bluesky's approach to opt-in algorithms is an interesting approach.
4. I think the ship has long sailed on Mastodon. It's failed time and again to gain enough critical mass for non-tech people to adopt. Clearly the combination of above issues, or even maybe the confusion of onboarding, is too much.
Overall I'm glad Mastodon exists, and perhaps Bluesky wouldn't be what it is without first seeing what worked and didn't work with Mastodon.
That's my impression too. There was a flock of academics and relatively non-tech folks joining a few years ago. Most didn't stay, and a few of those who did are now flocking to Bluesky.
But the others seem to be very much at home. They are not millions. They are probably prioritizing the small communities that have formed over maximum reach.
> You generally can't even index posts in a search engine.
That's a per-instance setting in an easy to find place in the Administration section. It's not doing anything more complex than swapping ROBOTS.txt files.
If on per-instance, there are also per-user settings to opt-in. (Again, it mostly just tweaks ROBOTS.txt.)
The off-by-default nature makes it seem "hostile" if your intent is to roll your own Fediverse index, because you actually have to read ROBOTS.txt files and abide by them. On the other hand, it is nice because it sets an ecosystem norm that indexes and bots should respect ROBOTS.txt and are considered bad actors to destroy if they can't be bothered to do the simple thing of respecting a ROBOTS.txt file.
The off-by-default nature makes it a little bit harder to find an instance if you do want your posts indexed in a search engine, but that's a part of why good federation means a diversity of instances.
Also, if they are your posts you want searchable nothing is stopping you from using an API to repost them to any other website you control with search engine indexing. I've seen several bloggers include their microblog posts from ActivityPub on their blog. That's my "eventual" plan for my own ActivityPub posts; I don't want the "live feed" search indexed, but I may want to eventually curate "best of" stuff, add context, do some revisions/editing, and upgrade them to blog posts.
And Nostr. Nostr is smaller than either Bluesky or ActivityPub, but it has some benefits over those two. It has a large number of cool clients (twitter-like, medium-like, music related, instagram-like) and the fact that instance admin can't de-platform you like they can on Mastodon, which literally happened to me.
Nostr also shows signs of being able to support the developers via very easy "tipping" feature. For example when new Amethyst (nostr client on android) is released, it makes it super easy to send the developers couple cents. And those cents add up. I don't think it's self sustainable currently, but it's not that far either.
No, there are no instances, there are just caching servers called "relays" that are run by many different people.
You create the content on your device and then send it to many of these relays (usually 10-20) and other users pull the content from also 10-20 relays. So if one relay decides to block you, then people still get your content from other relays. If all relays decide to block you, then you can (quite easily) run your own relay and tell your friends to pull the data from it. You own your data and you can resend it to wherever you want (it's signed by your private key, so it's verifiably from you).
Because there are no instances. There are relays that you post to, and that people use to fetch notes from. But there are no “user accounts” on the relays. If the note is signed by your private key, it comes from you, regardless of how it came to me. It can be through a bunch of relays.
Relays can and do filter notes by pub key. To fight spam, and problematic content. But you as a user can always change the relay set that you post to. And, of course, host your own relay, which is pretty straightforward.
Yeah, probably. Nostr is quite hated by the Hacker News community from what I have observed. This is most likely because it's used by folks that are into freedom technologies that explicitly don't allow excluding any users from participating. And so it attracts people that are into bitcoin, Tor, cryptography, etc. "Crypto" is actually quite hated at Nostr and you get called out for bringing any stupid crypto coins. You are free to talk about anything though and the system can't block or exclude you, but people may mute you in their clients.
My experience with Mastodon is that discovery is terrible. It’s great that it’s open, but it was far too much work to find people and topics to follow outside of my instance (indieweb.social). BlueSky makes discovery natural and easy.
My experience with Mastodon is that discovery is wonderful. It is natural and easy - no algorithm, no manipulation, nothing at all. Just type in details of person you want to follow and follow them.
Their discovery is so bad that they were touting new discovery algorithms for account recommendations in some recent release. So much for "no algorithm".
Both are written with the idea of decentralization and federation in mind. Bluesky at least superficially looks centralized like Twitter, which is simply put, what I want. I believe that's the case for most ex Twitter users too.
Deceptive. While half the tech people I used to follow on Twitter moved to Mastodon, three quarters of them have either shifted to bsky or post to both via mirroring.
Aside from tech, though: practically none of the non-tech people I followed on Twitter moved to Mastodon. Almost all of them went to Bluesky. I follow a mix of people, so I ended up mostly on Bluesky.
I would have been happy on Mastodon too, and I don't know why it didn't catch on with non-tech people, but it just hasn't. So Bluesky is our main opportunity for an open social web, at this time.
It sounds stupid but I think the bit where you pick your host was too much for normies or led to pushing off the decision and just not joining. Even when you have an account you know have to pick a client.
Hey, question. Is mirroring officially supported by either platform. So for example, can I configure my blue sky account to just monitor my mastodon feed and re-post things for me?
Have the non-tech people you used to follow on Twitter also migrated to Mastodon? What about the other half of the tech people, where did they go?
Labeling another post as deceptive and then trying to use just one demographic (and not a very large one at that) as proof for whether mastodon is "large" in percentage terms is not very reassuring as to the level of discussion on Mastodon tbh.
I am just relaying my experience. Bluesky and Mastodon together cover 90% of the intelligent discussion I used to get on Twitter, weighed more heavily towards Mastodon. To pretend it’s a dead platform is ridiculous.
Sure they are, it's just that it's centralised and you don't see it. If bluesky shut down it's business guess where you data goes? Into the void, correct.
Data isn't tied to an instance in mastodon, it resides in an instance and can be easily migrated. If you either host yourself or subscribe to a reputable service that offers mastodon, like omg.lol then it's a safe bet your data will live long after the other proprietary services get shut down.
User identities are not user data. Your identity is only lost if you used an identity provider that shut down. Your data is separately stored. You can, in effect, own your bluesky identity forever, even if every BS server shuts down, so long as DNS still exists and functions.
1. This is true for did:web but less true for did:plc identities.
2. For did:plc identities to survive a full "bluesky PBC" death, you'd need to to transfer master authority for your PLC identity to a set of keys you control. If you don't then ultimately bluesky PBC would still have final authority over your identity. But if you transfer control to your own keys ahead of time then you can use those keys to make changes long after bluesky PBC's death.
Wound be great if you posted the URL to the relevant documentation for this… I guess there must be some docs about these delicate details? Thank you very much!
It's generally pretty sparse docs because everything is fairly "beta" still and because it is cryptography if you fuck it up you permanently lose control over your account forever. This is one of the reasons they don't advertise non-custodial recovery keys super aggressively.
And the protocol that is used for maintaining a ledger of key changes isn't exactly ideal or to my knowledge final but rather is in a "it's good enough until we douse the other fires" state.
That's not actually true. If you host your data yourself with a PDS then everything continues to work. And your data is all stored in a big merkle tree so you can actually just back it up from the network and if bluesky shits itself you can upload it to your own PDS and continue as if nothing happened.
Same goes for identity (albeit in a different way)
I don't maintain a blog so my opinion may not count for much, but I feel like if what you are trying to do doesn't fit neatly into an SSG's existing templates/themes, it may in fact be easier just to use pandoc and some simple tooling around it. Certainly when I looked into a few SSGs for the purpose of making a simple personal website (without a blog) I found I would spend more time trying to bend them to my will than just writing what I want in markdown and running pandoc on it.
Most of them bend to your will very easily if you are the one writing the HTML and not trying to use an existing template/theme. Even Jekyll the "themes" are optional and you can entirely ignore them.
Also most of the complexity disappears if you aren't trying to make a blog. They generally all have "simple pages" support that is much simpler than trying to figure out their blog mechanics.
Of course the hard part is picking an SSG you like, and it is easier to just build your own which is a big part of why SSG proliferation happens. Too many options? Make a new one.
My main sites are still in Jekyll for now, for historic reasons of GitHub Pages support.
My latest discovery and new love in this space is Lume [0]. It's definitely on the simpler side of the scale. I haven't tried it for a full blog yet, but the simple website I have built with it has indeed continued to feel simple throughout the process and even using some of the features Lume's documentation labels "Advanced".
I've tried Hugo and Jekyll a few times and they are pretty complicated. If you just want to post something online every now and then, then it might be easier to just to HTML.
Alternatively pick a light-weight template engine from your favorite language and use it to generate the html. More flexible than plain html files and very low learning commitment.
I've been doing that for years and really happy with the result.
I would rather say that the former group are wrappers around the latter group. Using an SSG doesn't just mean converting Markdown etc. source and orchestrating a build process of some sort, but also filling in templates and providing useful build steps to orchestrate (such as generating additional pages that reference the actual article content: archives, collections grouped by tags or categories, etc.). They also generally implement things like the live reloading that the author mentioned as missing.
I'm currently using Nikola and have done quite a bit of customization - by hacking around and learning modern web stuff as I go (the last time I did this stuff seriously, jQuery was dominant and Bootstrap was brand new - of course I'm not writing a bunch of JavaScript for a blog, but that also presumably dates my understanding of HTML and CSS). I've found that even though there's way more stuff in here than I really want, it's really nice to have that kind of scaffolding to start, and I can strip it away as I customize.
Yeah, obviously this is literally what something like Jekyll or Hugo does. It's just (at least to me) a simpler version of that where you can fully see what's happening. Also I didn't want all the theme-ing overhead that comes with those - just something I could inject into my existing site.
>Also I didn't want all the theme-ing overhead that comes with those - just something I could inject into my existing site.
I didn't like how complex that stuff is with Nikola - I didn't have an obvious entry point for making the kinds of customizations I really wanted, and yet there was still so much to look at in order to understand the system. But at the same time I really didn't want to spend hours re-learning CSS more or less from scratch, when I could actually use the examples already in the existing themes.
I did something really awful: instead of trying to make yet another layer of theme "extension", I copied everything locally and have been condensing it as I go.
This had the benefit that I didn't have to decide on a bunch of CSS classes up front in order to have anything look passable. There may be tons of unused stuff, but I'm cleaning that up as I implement my own things - and bit by bit, I get something smaller and more comprehensible that fits my mental models. This conversion process might not be any faster, but I'm certainly enjoying myself more.
At some point in the future I'm considering doing a simple templating engine and converting these templates (originally Mako) to it. It just irritates me that I still have to deal with close tags - both in HTML and in template directives - when I'm doing everything in Python. I have a vague memory of a 2010-era JavaScript templating system - I think it was called Express or something like that? - which used indent-based syntax without closing tags. So I'm inspired by my recollection of that.
> I would normally think that with the rise of LLMs, writing would be come obsolete
If LLMs obsolete writing, then they will also obsolete reading. Why waste time on reading texts when you know that no effort has been put into creating them, when they do not encourage trust, or sparkle joy.
WebGL. At least for 2d graphics. And brush up on the simple aspects of the maths that are involved.
Web accessibility.
Would be great if I could finally finish a simple static website for myself. I've been stuck in the analysis paralysis phase for so long it's embarrassing.
> People don't bother going through official react handbook thoroughly and understanding that react is nothing more than a handful of hooks
React is 10+ years old. Hooks are about five years old. There was react before hooks; and people who hate react don't always do so because they failed to learn the hooks api...
Also, the official react documentation is, predictably, a living document that keeps changing. I guarantee you that when react hooks were introduced in 2019, they were presented as a more convenient alternative to lifecycle methods, with a near-direct correspondence between the component lifecycle methods api and the hooks api. The useEffect hook was presented as a better and more powerful componentDidMount + componentDidUpdate combo. There was no talk of "you might not need an effect", which came out of several conference talks and culminated into a separate article in the docs. The first version of that "you might not need an effect" article appeared, according to github history, in 2022, three years after the early adopters had started using hooks including the useEffect. You were never supposed to update the state during render; now you are. You were always allowed to read component class properties during render; now with useRef, you aren't. And after all these years, react still seems to be in denial that sometimes you want some actions to happen only once over component's lifetime, upon its mounting; and you have to fight with the strongly encouraged StrictMode component for that privilege...
React pre and post 16.8 are two completely different libraries. I remember 2019, hooks we presented as a replacement to lifecycle methods and class-based components at all, not as alternative. The useEffect hook was presented as something which let's you split your code based on logic instead of component lifecycle, and few examples were there showing how the new effect concept better splits the async logic which was previously a solid mess inside the componentDidMount/Update.
>in 2019, they were presented as a more convenient alternative to lifecycle methods
Again, no one presented hooks as an alternative, it was strictly a replacement for class-based components which were obsoleted.
From the rest of it I see you have a very big problem with react, "you might not need an effect" article was written for folks like you. Update the state during render? what? if you need to read something during render you need to use State, and if you need a reference to a variable outside of React you use Ref; there is a clear way to make a side-effect happen only once over component's lifetime, which is to use Effect without dependencies. StrictMode component has no use other than debugging.
> React pre and post 16.8 are two completely different libraries.
The two apis still coexist within the same library.
> The useEffect hook was presented as something which let's you split your code based on logic instead of component lifecycle, and few examples were there showing how the new effect concept better splits the async logic which was previously a solid mess inside the componentDidMount/Update.
That is exactly what I mean by the word "alternative". As in, previously, you achieved certain results by calling componentDidMount/DidUpdate methods; now, in order to achieve same results, you would use the useEffect in a certain way.
> Update the state during render? what?
See "Adjusting some state when a prop changes" section of "You Might Not Need an Effect"
> if you need to read something during render you need to use State, and if you need a reference to a variable outside of React you use Ref
Sure. But what if during a render you want to check something in the DOM (geometry of a DOM node or something). I do not think that pre-2019 there were any guidelines that you mustn't. There weren't any such recommendations after the hooks were released either, when all we had to go by was the hooks api documentation in what now is the legacy documentation site [0]. The caution against doing this only appeared in the new react docs in 2022. My point here is that the docs change, and the patterns of usage of the library change, and what was considered ok once no longer is. This might be why some folks are complaining, even if they don't fit the "don't bother reading the docs" profile that you proposed.
> there is a clear way to make a side-effect happen only once over component's lifetime, which is to use Effect without dependencies. StrictMode component has no use other than debugging.
StrictMode unmounts and remounts every component causing every useEffect to fire at least twice. Which means a useEffect with an empty array of dependencies will execute twice, unlike in production build in which it will indeed execute just once. This makes the code in the development mode behave differently than in production mode. This also makes useEffect with an empty dependency array incapable of guaranteeing that it will execute only once.
As for the empty array of dependencies to emulate the previous componentDidMount method, this was indeed the original message in 2019. I am almost certain — though I can't find this online now — that Dan Abramov subsequently tweeted to not rely on the empty dependencies array as a guarantee that the useEffect only fires once per component's lifetime.
I understand react is not easy for some, and this article is made for those who are finding a hard time with it. "Adjusting state when prop changes" only means your dataflow is a whack and your logic is a mess, and article explains it well. I have shipped quite a few React interfaces to production and never in my life I had to adjust the state when prop changes, this even sounds like nonsense and smells of bad react code. StrictMode mounts components twice specifically to find bugs where an effect is lacking a clean-up, good react UI means an effect can be ran 100 times with the same effect, and StrictMode helps to ensure that.
>Dan Abramov subsequently tweeted to not rely on the empty dependencies array as a guarantee that the useEffect only fires once per component's lifetime
It is very strange that you can't find online such a non-sensical tweet from Dan, because in case of effect there is no component, and it's lifetime is non-existent, there is only function, and it can be called, and it might call a side-effect or not in it's execution, depending on X or nothing. He was probably explaining that a useEffect is not equal to a lifecycle method componentDidMount – and empty dependencies mean actual side-effect of your render function without dependencies, which you still need to clean-up properly – not the shortcut to the old "component lifecycle". After 2019 the whole concept of "mounting" and "unmounting" the "component" was obsoleted and replaced with just a function and it's side-effect, which was a dramatic shift towards procedural and functional react which does work at scale from the class-based lifecycle concept which failed at scale. For some people it is harder to grasp something procedural and functional, especially if they are used to think inside some other concept or paradigm, they mess up their one-way data flow, immutability, function composition and end up in pain using react, and it can be hated for that, i agree.
> As for the empty array of dependencies to emulate the previous componentDidMount method, this was indeed the original message in 2019. I am almost certain — though I can't find this online now — that Dan Abramov subsequently tweeted to not rely on the empty dependencies array as a guarantee that the useEffect only fires once per component's lifetime.
This is one of the big reasons why I personally dislike React and the community around it. They seem to envision at the start certain ways to do things, and push them to the point of being "this is how you do X". Then, after not very long at all, the old way is discovered to be bad and inefficient and buggy and hard to reason about or whatever, now do it this other way. Repeat three or four times until a new API is created or something.
This also means that going from project to project can feel very whiplash-inducing. The code you find is not even dependant on the version of React that's installed, but on how the community was feeling about the "best practices" around the time that particular project was started.
I remember when render props were a thing. Then I remember when they stopped being considered a thing and now the new thing to do was HOCs.
Things like React Router also being wildly different between versions, or at least v3 -> v4. I remember needing to find out how to achieve certain behaviour with v3, only to then try to find that the docs only existed for v4 (which was the newest at the time), and addons that helped me with my original problem also only existed for v4. (Then React Router was no longer the Best Thing, so let's all switch to Reach Router... then back to React Router when it was again considered the new hotness. I may have forgotten one or two others in there, I just stopped paying attention around that point.)
Another example is CSS scoping, which is a complete non-issue with vanilla Vue and Svelte. But in React land you have styled-components, emotion, styled-jsx, and who knows what else in which you don't write CSS, but JS that looks like CSS but not quite, enough to throw me off every single time.
The whole periodic shifting of opinions about useEffect from "this is your componentDidUpdate replacement" to "use a linter to warn you about the footguns that we can no longer fix, also use one of these hooks instead" is just one more thing that adds to the frustration of having to work with a React-based project.
I'm actually starting to wonder if Facebook isn't so much "writing" React, but "discovering" it. Much like how we didn't quite invent fire, and we had to figure out how to use it properly over many, many thousands of years.
> Imagine you decided to start developing websites today, how do you even start?
Not with React?
Seriously, if you are starting developing websites today, the first thing you need to do is learn the web platform: html, css, javascript (probably typescript as well while you are at it), svg; and some basic server-side stuff. React is for when you get pretty comfy with those.
At no point do you change your focus to what works best for the user. Who is the user; what kind of devices does he use; what does he want to accomplish on your website; what does he need to accomplish that; etc.
Why do you think that choosing an SPA hurts my users? If I'm selling a service, it's in my best interest to give my users the best service possible; it's entirely possible to write accessible SPAs with great UX, as it's entirely possible to do that with server-rendered applications (and vice-versa). If I'm not selling a service and I'm prototyping or giving something away for free, I obviously tend to give more importance to my DX and time - if it means a worse experience for users because I'm cutting corners, so be it. They're still getting stuff for free.
Additionally, there is an entire class of web apps that I wouldn't have written if they weren't SPAs. The luxury of uploading some files for free to an industry-grade CDN and using a ready-made backend of which I'm not the admin on its free tier allows me to write stuff that I wouldn't have even started if I had to rent a machine and spawn a server somewhere, with all the admin / maintenance costs attached.
Of course there is a class of people who don't want to run Javascript on their devices. I understand that and I respect that. I might be one of them in certain cases. But unless I'm writing life-saving software or I'm running a monopoly (which is generally not the case), their importance in my audience will be evaluated on a cost/benefit basis.
As a solo developer, especially when you are building free stuff to scratch your itch, of course you are free to pick whatever tech works best for you. My complaint is that this kind of mindset extends beyond solo developers to dev teams in commercial companies, and even worse, in the public sector.
I tend to not understand that mindset as well: unless they're writing life saving software or they're running a de facto (like Google) or de jure (like .gov) monopoly(+), which means you're forced to use them even if you don't want, the technology they decide to use is entirely their choice. If they provide a worse experience, don't use their services / use an alternative that provides a better experience. If they provide a good experience at the cost of running Javascript on your device, you still have the choice of not using their service, or of making an exception for them and running their code. Someone can even write an alternative and market it to anti-SPA folks.
(+) If they are a monopoly, I would say that the problem are not SPAs, but the existence of monopolies itself.
> unless they're writing life saving software or ... you're forced to use them even if you don't want, the technology they decide to use is entirely their choice
The technology is always (or almost always?) their choice. However, if it is a public sector organisation, it owes it to the public to care about them, to be informed about devices they are using and the conditions they are using them in; and to strive to provide its services in the most accessible way. "How fast does a page load", "how fast does the page perform on users' devices once it's loaded", and "how gracefully it degrades under unfavorable conditions" should be important parts of the conversation.
Businesses in the private sector have fewer responsibilities to the public, and are primarily controlled by market forces; but still, it would probably benefit them to have similar considerations.
> The xenomorph’s multicellular structure serves as a cornerstone for its classification within Animalia (Ros-Rocher et al., 2021). Its intricate organization of cells, tissues, and organs reflects a level of biological complexity commonly associated with animals. Xenomorphs can be included into the Arthropoda phylum due to the morphological similarities shared with certain terrestrial arthropods such as an exoskeletal structure, a segmented body plan, the presence of hemolymph, etc.
I don't understand the logic of this argument. If Xenomorph has evolved on a different planet, it will surely not have the same common ancestor as Animalia, let alone Arthropoda. Why would anyone classify it under those taxons?
> It means downloading MBs of javascript just to render a simple page.
React + react-dom minified gzipped is around 60kB. Yes, this is a lot; but no, this is not MBs of javascript. If your (simple) pages download MBs of javascript, that means you have added lots of other stuff on top of react.
While I completely agree that react is unnecessary for simple sites, react itself is not guilty of megabyte-size javascript bundles.
You’re writing your entire website in react then downloading it to the client every time. This means the weight is react plus hundreds or thousands of dependencies (which this is ecosystem seems to actively encourage) plus all your app logic. MBs is not uncommon for larger websites.
Why do they write as if activitypub and mastodon do not exist?