beaker VS tachyons

For me, the peak of decentralization efforts were Beaker Browser [1] and Stealth [2].

But one project didn't make enough money and the author of the other one got doxxed into oblivion, so I guess we can't have nice things.

A peer to peer browser has so much potential, I wish somebody else might give it a try.

[1] https://github.com/beakerbrowser/beaker

[2] https://github.com/tholian-network/stealth

I wanted to mention Beaker Browser, but sadly, it's been archived: https://github.com/beakerbrowser/beaker/blob/master/archive-...

AT proto has some significant similarities to Matrix:

* Both are work by self-authenticating git-style replication of Merkle trees/DAGs

* Both define strict data schemas for extensible sets of events (Matrix uses JSON schema - https://github.com/matrix-org/matrix-spec/tree/main/data/eve... and OpenAPI; AT uses Lexicons)

* Both use HTTPS for client-server and server-server traffic by default.

* Both are focused on decentralised composable reputation - e.g. https://matrix.org/blog/2020/10/19/combating-abuse-in-matrix... on the Matrix side, or https://paulfrazee.medium.com/the-anti-parler-principles-for... on the bluesky side, etc.

* Both are designed as big-world communication networks. You don't have the server balkanisation that affects ActivityPub.

* Both eschew cryptocurrency systems and incentives.

There are some significant differences too:

* Matrix aspires to be the secure communication layer for the open web.

* AT aspires (i think) to be an open decentralised social networking protocol for the internet.

* AT has portable identity by default. We've been working on this on Matrix (e.g. MSC1228 - https://github.com/matrix-org/matrix-spec-proposals/pull/122... and MSC2787 - https://github.com/matrix-org/matrix-spec-proposals/blob/nei...) and have a new MSC (and implementation on Dendrite) in progress right now which combines the best bits of MSC1228 & MSC2787 into something concrete, at last. In fact the proto-MSC is due to emerge today.

* AT is proposing a asymmetrical federation architecture where user data is stored on Personal Data Servers (PDS), but indexing/fan-out/etc is done by Big Graph Servers (BGS). Matrix is symmetrical and by default federates full-mesh between all servers participating in a conversation, which on one hand is arguably better from a self-sovereignty and resilience perspective - but empirically has created headaches where an underpowered server joins some massive public chatroom and then melts. Matrix has improved this by steady optimisation of both protocol and implementation (i.e. adding lazy loading everywhere - e.g. https://matrix-org.github.io/synapse/latest/development/syna...), but formalising an asymmetrical architecture is an interesting different approach :)

* AT is (today) focused on for public conversations (e.g. prioritising big-world search and indexing etc), whereas Matrix focuses both on private and public communication - whether that's public chatrooms with 100K users over 10K servers, or private encrypted group conversations. For instance, one of Matrix's big novelties is decentralised access control without finality (https://matrix.org/blog/2020/06/16/matrix-decomposition-an-i...) in order to enforce access control for private conversations.

* Matrix also provides end-to-end encryption for private conversations by default, today via Double Ratchet (Olm/Megolm) and in the nearish future MLS (https://arewemlsyet.com). We're also starting to work on post quantum crypto.

* Matrix is obviously ~7 years older, and has many more use cases fleshed out - whether that's native VoIP/Video a la Element Call (https://element.io/blog/introducing-native-matrix-voip-with-...) or virtual worlds like Third Room (https://thirdroom.io) or shared whiteboarding (https://github.com/toger5/TheBoard) etc.

* AT's lexicon approach looks to be a more modular to extend the protocol than Matrix's extensible event schemas - in that AT lexicons include both RPC definitions as well as the schemas for the underlying datatypes, whereas in Matrix the OpenAPI evolves separately to the message schemas.

* AT uses IPLD; Matrix uses Canonical JSON (for now)

* Matrix is perhaps more sophisticated on auth, in that we're switching to OpenID Connect for all authentication (and so get things like passkeys and MFA for free): https://areweoidcyet.com

* Matrix has an open governance model with >50% of spec proposals coming from the wider community these days: https://spec.matrix.org/proposals

* AT has done a much better job of getting mainstream uptake so far, perhaps thanks to building a flagship app from day one (before even finishing or opening up the protocol) - whereas Element coming relatively late to the picture has meant that Element development has been constantly slowed by dealing with existing protocol considerations (and even then we've had constant complaints about Element being too influential in driving Matrix development).

* AT backs up all your personal data on your client (space allowing), to aid portability, whereas Matrix is typically thin-client.

* Architecturally, Matrix is increasingly experimenting with a hybrid P2P model (https://arewep2pyet.com) as our long-term solution - which effectively would end up with all your data being synced to your client. I'd assume bluesky is consciously avoiding P2P having been overextended on previous adventures with DAT/hypercore: https://github.com/beakerbrowser/beaker/blob/master/archive-.... Whereas we're playing the long game to slowly converge on P2P, even if that means building our own overlay networks etc: https://github.com/matrix-org/pinecone

I'm sure there are a bunch of other differences, but these are the ones which pop to the top of my head, plus I'm far from an expert in AT protocol.

It's worth noting that in the early days of bluesky, the Matrix team built out Cerulean (https://matrix.org/blog/2020/12/18/introducing-cerulean) as a demonstration to the bluesky team of how you could build big-world microblogging on top of Matrix, and that Matrix is not just for chat. We demoed it to Jack and Parag, but they opted to fund something entirely new in the form of AT proto. I'm guessing that the factors that went into this were: a) wanting to be able to optimise the architecture purely for social networking (although it's ironic that ATproto has ended up pretty generic too, similar to Matrix), b) wanting to be able to control the strategy and not have to follow Matrix's open governance model, c) wanting to create something new :)

From the Matrix side; we keep in touch with the bluesky team and wish them the best, and it's super depressing to see folks from ActivityPub and Nostr throwing their toys in this manner. It reminds me of the unpleasant behaviour we see from certain XMPP folks who resent the existence of Matrix (e.g. https://news.ycombinator.com/item?id=35874291). The reality is that the 'enemy' here, if anyone, are the centralised communication/social platforms - not other decentralisation projects. And even the centralised platforms have the option of seeing the light and becoming decentralised one day if we play our parts well.

What would be really cool, from my perspective, would be if Matrix ended up being able to help out with the private communication use cases for AT proto - as we obviously have a tonne of prior art now for efficient & audited E2EE private comms and decentralised access control. Moreover, I /think/ the lexicon approach in AT proto could let Matrix itself be expressed as an AT proto lexicon - providing interop with existing Matrix rooms (at least semantically), and supporting existing Matrix clients/SDKs, while using AT proto's ID model and storing data in PDSes etc. Coincidentally, this matches work we've been doing on the Matrix side as part of the MIMI IETF working group to figure out how to layer Matrix on top of other existing protocols: e.g. https://datatracker.ietf.org/doc/draft-ralston-mimi-matrix-t... and https://datatracker.ietf.org/doc/draft-ralston-mimi-matrix-m... - and if I had infinite time right now I'd certainly be trying to map Matrix's CS & SS APIs onto an AT proto lexicon to see what it looks like.

TL;DR: I think AT proto is cool, and I wish that open projects saw each other as fellow travellers rather than competitors.

it sounds a lot like you're reinventing what Beaker Browser had built on top of DAT, except that it could do more. For example, they made a distributed Twitter clone as a proof of concept, but folks actually started using it. Definitely included blogging stuff.

Really cool stuff around taking sites and things other folks had built and using them as a basis for your new thing.

https://github.com/beakerbrowser/beaker/

As a long time patchwork user —April 2017 for the win…— that just recently quit, I could see how the multitude of half finished clients, deprecated functionality would get to that outcome.

SSB is dead, other than the few trying to make a go financially at it, via either crowdfunding, NLnet grants, or VC.

I've reverted to Web 1.0 blogging, with none of the bs that is consistent with using a archived client, focus on trying to fit a database into a mobile app — without regard to front end functionality.

> When I look at Beaker, I think it was probably 50% easy. The initial demo took 2 weeks: 20%. It was a full website editor in about 2 months: 30%. The feedback was great: 50%. The users didn't stick: 50%. We got invited to talks which increased exposure: 51%. A few niche communities took an interest: 53%. Folks liked it enough to donate via OpenCollective and Patreon: 54%. You get the idea. Notably absent is "usage and retention went through the roof: 80%" and then "usage continued to grow for years: 100%."

Everything that pfrazee wrote here about Beaker Browser at https://github.com/beakerbrowser/beaker/blob/master/archive-... is true for ssb.

I'm sad to see this go, a remnant of another web which could have been. I actually spent a lot of time playing with Beaker and hacking it up for my own purposes.

We actually had a discussion a few years ago where I made a suggestion about change to the default behavior. At the time, you made a perfectly valid response and declined my suggestion, but I'm curious if your thinking is the same today, given how things played out: https://github.com/beakerbrowser/beaker/issues/1444

Beaker, Hybercore

Disclosure: It's in Romanian, no cookies, no JS, no trackers

Beaker Browser https://beakerbrowser.com/ seems dead, loved the concept but it's no longer updated

Now that you've asked, nope, didn't found anything with a clear future on the "Web3" side of the internet. Vast majority make use of crypto/blockchain and IMHO blockchain is anything but not decentralization.

I chose Tachyons over Tailwind because Tachyons is an atomic CSS framework, similar to Tailwind, however it's much lighter weight. Tailwind tends to be a bit heavier without using post CSS processing so I wanted to stick with something smaller.

The CSS framework we will use in this project is Tachyons CSS, which we will install by running the command below in the terminal.

> (https://github.com/tachyons-css/tachyons)

What makes this 'functional'? Is it related to functional programming? Or is it used as a synonym for 'usable'?

Tachyons is a similar utility class framework, and a lot smaller at somewhere under 20kb, IIRC.

https://tachyons.io/

I like using a functional CSS library (tachyons.io, tailwindcss, or SLDS) and setup components separately. The CSS has my colors and units declared (and the aim is to not have 40 different gray colors, it's to limit yourself with a definition list). Then the actual components are setup via a component library. Plenty to choose from: React, VueJS, LWC, AngularJS, or just native web components.

Note how each class in the atomic version maps to just a single CSS property and value. In fact, if I hadn’t included the second block, I bet you’d have had no problem determining each class’ effect from the markup alone! This is a hallmark of atomic CSS — the effect of a class is typically self evident from its name alone, whereas the specifics of a class name like media are more ambiguous.

For anyone familiar with atomic CSS today, the example above will likely appear unremarkable. The transition towards this approach was anything but, however — and on some corners of the web today, debate still rages about whether atomic CSS has been the best or worst thing to happen to styling on the web since CSS.

There was, however, clearly an appetite for this approach amongst a non-trivial swath of web developers: the year 2014 saw the release of both Adam Morse’s Tachyons and Brent Jackson’s Basscss, the first two frameworks to go all-in on atomic CSS. These frameworks were instrumental in writing the blueprints for the atomic CSS methodology and turning the status quo on its head — and indeed, the shift was so monumental that, within a number of years, ‘utility-first’ CSS frameworks started becoming multimillion dollar businesses.

The atomization of CSS had officially begun.

Atomic CSS: successes and perceived failures

In order to understand the success of atomic CSS (even if that success remains a point of debate in some circles), we should first examine its principles, and the goals those principles seek to achieve. Many of these principles are derived from functional programming, hence the alternative name ‘functional CSS’. Additional inspiration came from the Unix philosophy.

The most fundamental principles of atomic CSS are:

Classes should have a single purpose.

Classes should do one thing, and they should do it well. This makes each class more reusable. A class that applies a margin, and only a margin, is more reusable than a class that applies and margin and a text colour.

A class’ effect should be self evident.

There should be no mystery about the effect of using a class — clarity should always trump cleverness. The effect of a class named flex which sets the display property to flex is self evident. The effect of a class named media which may set any number of property values is ambiguous.

Classes should be composable.

Complex styles should be achieved by composing multiple single purpose classes together, rather than by writing new, complex, and less reusable classes.

Classes should be immutable and free of side effects.

For example, the underline class should only ever apply an underline style. It should never not apply the underline, or apply another style, or change any other property of any other element. Under no circumstances should it change the effect of another class.

It’s important to note that these principles were not devised for their own sake — each plays an important role in authoring performant, maintainable, robust styles:

• Single purpose classes are more reusable and composable than multipurpose classes. Thus, single purpose classes provide greater flexibility as well as reduced CSS file sizes, both at the outset of new projects and throughout their lifecycle (as fewer styles need to be added to deliver iterations and additions to UI).

• Classes with singular, self evident effects reduce cognitive overhead for developers; the resultant styling systems are thus easier to learn, and this in turn helps frontend teams scale their efforts across people and time.

• Classes which are immutable and free of side effects result in fewer bugs — and where bugs occur, easier debugging and resolution follows.

In these ways and in others, I have always felt that the nature of atomic CSS flows very much with the grain of CSS itself. Remember that CSS was designed to be independent of markup, and atomic CSS is by design untethered to any particular markup structure or content based semantics. Atomic CSS also honors CSS’ specificity algorithm rather than attempting to game it — it does not concern itself with optimized selector ranking or scope, since every class is of single purpose and equal specificity. This also means CSS’ inheritance model becomes an advantage as it was originally intended: compositions can be built up with inheritance in mind, over several layers of markup.

There are, however, many common objections raised against the atomic CSS methodology. In general, these tend to be:

’It’s not semantic.’

We’ve touched on this already, but it’s worth repeating: semantics, accessibility, and clarity do matter, but with all due respect to Zeldman, there is nothing inherently unsemantic, inaccessible, or unclear about ‘visual class names’, nor is there a reason for CSS to map to the same semantics as HTML.

‘This is inline styles all over again.’

Nope. Inline styles are defined in HTML; atomic classes are defined in a style sheet. Inline styles do not permit media queries, pseudo elements, or pseudo classes; atomic classes do. Inline styles have a specificity ranking of 1-0-0-0, which can only be outranked by !important; atomic classes have a specificity of 0-0-1-0, the same as any single class. An inline style’s source of truth is its own singular invocation on a given element; an atomic class’ source of truth is a style sheet. There is a lexical resemblance between class='red' and style='color: red'; this is where the similarities end.

‘Putting so many classes on my elements looks ugly/is hard to read.’

Admittedly, doesn’t read like poetry (and yes, that snippet is taken from this very page as of this writing). However, something that is a delight is being able to rapidly iterate on this composition — from the logical origin of that composition (the markup), whether in the browser or my editor — to explore different combinatorial spaces within the bounds of a design system. Iterating in this fashion simply cannot be matched when using other methodologies.

‘This is so not DRY.’

It’s true, atomic CSS can lead to repeating declarations of various styling rules — but I vastly prefer repeating declarations to repeating definitions (which, in my experience, are much harder to maintain). Also, remember that every time you repeat a class name, that’s one more addition you didn’t have to make to your style sheet! Ultimately, this is a matter of choosing what kind of repetition you want, not one of avoiding repetition altogether.

‘Atomic CSS is at odds with modern component modeling.’

‘Thinking in React’ is one of those articles that changed the way I thought about web development when it was published, and there’s no denying that building frontends on the web has become a component centric process. However, it’s important to differentiate the process of thinking in components and the process of styling components. A conceptual abstraction does not require an equivalent material abstraction, and the fact of a component’s existence does not necessitate a dedicated CSS class.

‘This still doesn’t solve the problem of global scope or one off styles.’

It doesn’t, and in fact atomic CSS is not designed for this. For scoped or one off styles, a different approach is absolutely required.

Atomic CSS can provide a fantastic foundation that covers the vast majority of styling needs for a given website and its constituent components, and it can deliver those styles in a fraction of the file size and complexity of other methodologies. To be clear, these claims are not theoretical: this has been my experience both as a contributor and leader of frontend teams over the past 8 years, and the same has been true for many others both within and outside of my professional circle. But as we’ve noted, atomic CSS doesn’t cover every use case: scoped and one off styles are not part of its wheelhouse. So what’s to be done when a need for these sorts of styles emerges?

Going bespoke

Photo by Chris Ralston on Unsplash

Where one off styles are needed, or where we want to ensure certain styles are scoped to a given component, additional measures beyond an atomic CSS methodology will be required. There are several techniques that can be used to address these concerns, with a few notable examples having become more popular in recent years:

CSS in JS

The obvious contender in this list. I used CSS in JS for many years myself, and have to say the developer ergonomics are pretty impressive, as is the ability to leverage both repeatable and bespoke, scoped styles (especially when using libraries like Styled System or Theme UI). Unfortunately, great developer ergonomics and scoping are not enough. CSS in JS can add significant weight to client side bundles, along with increased setup complexity (especially when server side rendering is involved). Some solutions can also lock you in to certain frontend frameworks, limiting the portability of your styles. There are some solutions emerging to address these concerns (e.g. Vanilla Extract), but at the end of the day, I admit I’m growing tired of learning abstractions of CSS — there are so many more valuable things I could be doing with my time. This isn’t necessarily a popular opinion, but I think CSS is actually pretty amazing on its own, and the closer to the metal I can stay, the happier I am.

CSS Modules

The name may suggest that CSS Modules are part of the CSS spec, but this is not the case. CSS Modules allow authors to extract styles from a vanilla .css file and into a JavaScript file containing markup; at build time, these extracted styles are then regenerated as locally scoped styles wherever they are used. This seems to offer some of the benefits of CSS in JS, but without the ergonomics of colocating styles, content, and behavior within a given component.

Shadow DOM

Shadow DOM is a web standards specification which is designed to provide encapsulation of content, styles, and behavior — but it has a number of hard to swallow caveats. For one, Shadow DOM roots need to be initialized in JavaScript (though Declarative Shadow DOM should address this in the future.) Further, styling encapsulation doesn’t work quite like you think it does, and this can cause some headaches. I believe the Shadow DOM holds promise, but for many use cases, it can end up being more trouble than it’s worth.

Fortunately, a compelling solution for dealing with scoped and one off styles exists in the form of HTML custom elements, which are part of the web components spec along with Shadow DOM and HTML templates. I may be biased, but I think the best way to work with custom elements right now is with Enhance (though to be fair, I got a sneak peak at Enhance before joining Begin in 2022, and was just as enthusiastic at that time).

Using Enhance to author custom elements in the form of Single File Components (SFCs) has a number of huge benefits:

1. Custom elements are expanded on the server, providing great performance and an excellent baseline for progressive enhancement on the client.

2. Locally scoped, one off styles can be authored simply by including a </code> block in your SFC. When your component is expanded on the server, these style blocks will be hoisted into the document head, with all of that style block’s selectors scoped to your custom element. This allows for one off styles to be encapsulated and scoped to the component they’re authored in, without needing to touch the Shadow DOM. Scoped styles written within an SFC are also a great place to leverage strategies like <a href="https://css-tricks.com/are-we-in-a-new-era-of-web-design-what-do-we-call-it/">intrinsic design</a>, which can happily coexist alongside a global, atomic class system.</p></li> <li><p>If you don’t need to write client side behavior, <strong>you never have to interface with JavaScript classes or the <a href="https://developer.mozilla.org/en-US/docs/Web/API/CustomElementRegistry">Custom Elements Registry</a></strong>. This is particularly handy for engineers (or designers) who might excel at HTML and CSS but lack experience in JavaScript. Although SFCs are authored as JavaScript functions, the bulk of the authored code is written in HTML and CSS, as seen below:<br> </p></li> </ol> <div class="highlight js-code-highlight"> <pre class="highlight javascript"><code><span class="c1">// my-button.mjs</span> <span class="k">export</span> <span class="k">default</span> <span class="kd">function</span> <span class="nx">MyButton</span><span class="p">({</span> <span class="nx">html</span> <span class="p">})</span> <span class="p">{</span> <span class="k">return</span> <span class="nx">html</span><span class="s2">` <style> /* One off styles applied only to button elements rendered by MyButton. */ /* Any button outside this component will not be affected. */ button { appearance: none; box-shadow: 0 2px 4px rgba(0,0,0,0.1); } ` } // index.html <my-button>Click Me!</my-button>

Therefore, I totally got to buy in for the utility-first approach. In that world, the only thing is worth mentioning is Tachyons. However, although it came way earlier than Tailwind, it is said to be feature-complete, and one cannot expect new features to be added or problems discussed. The latest release is almost five years old, which definitely violates the principle “Bleed Responsibly”. You can also see that from the star trend:

The CSS framework to be used in this project is Tachyons CSS. Install it by running the command below in the terminal.

As you can see from the above code, we have separate css for each value of padding. So instead of defining css manually everytime, you can simply define these helper css or use an existing css utility framework. I've been working with a lot of such utitlity frameworks, and people have their own utilty css'. Some of the famous css utility frameworks are Tailwind Css, Windi Css and Tachyons etc. So basically these utility frameworks will have a list of helper classes which provide basic css functionalities.