hydrogen-web VS Alpine.js

Yes! See https://github.com/vector-im/hydrogen-web/releases/tag/v0.3....

I think you're right, the experience of element on Android isn't great, I use mostly the web app that seems to get more attention and doesn't feel as sluggish. But to bring some hope, I think this will change soon-ish. The Matrix ecosystem has been in kind of a MVP state for several years, the focus was more on the protocol/APIs and not so much on the performance that translates in user experience. But efforts are on the way to improve all of this, on the client side there are several projects working on other clients that might be more performant, including the company behind Element, they have a work-in-progress lightweight client https://github.com/vector-im/hydrogen-web On the server side most servers run Synapse which is written in Python without much though for performance or scalability but there are faster/lighter alternatives on the way like Dendrite or Conduit. It also doesn't help that most accounts are in the same overcrowded Synapse server(matrix.org), overtime it should become more common to have more alternatives and people even running their home server embedded in their device.

It’s using normal Matrix olm/megolm double ratchet encryption.

To track the identity of who you’re talking to we can do TOFU and/or normal out of band Matrix verification as per https://github.com/vector-im/hydrogen-web/issues/518 - but this isn’t yet exposed in Chatterbox. We’ll get it added, as without verification you obviously can’t spot a MITM.

You can use this web app to access the chat. Join the #general channel. https://github.com/vector-im/hydrogen-web

Hydrogen's installation process was pretty much exactly the same as Element, the github README was just a lot less specific and there is no config file so you have to edit the HTML directly to get it to point to your site instead of matrix.org by default.

> I'm rather convinced at this point that all of these people chanting "Can we just go back to traditional approaches!" have never built a web app of reasonable complexity, never used something like React, or have some sort of combination of FOMO and/or comfort in their long-held approach.

I've got plenty of React & front-end experience and vastly prefer a thin library on top of the DOM than something like React, also for large applications. React is ok if all goes well, but when you have to debug or profile something, all the complexity behind the scenes occludes what you are looking for. Most of the time, people want JSX so you need a transpiler. Also keeping up with changes in new React releases seems like a lot of lost time.

I've been building [1] without a transpiler and just a 600 lines template library (see [2]), and it has been such a breath of fresh air. The fact that there is so little code between you and the browser makes it very easy to see what is going on. Call stacks of max around 15 frames.

It sounds like you are comparing React to jquery code without components, and I justed wanted to highlight that DOM APIs have evolved since those days, and that you don't need a library like React to structure your code.

React has popularized good ideas in front-end development, like components, but I think the complexity cost of a virtual DOM is often underestimated.

1: https://github.com/vector-im/hydrogen-web/

Matrix's resource utilisation is improving very rapidly at the moment.

Dendrite is still in beta, and hasn't been tuned that much yet, but every release has had a substantial improvement. In other words, if you're not using today's release (0.3.5) you're on stale data. For context, dendrite.matrix.org (running 0.3.5) has ~5K users on it, and is in ~3K rooms spanning 162K users... and its RAM usage is stable at 488MB (occasionally spiking to 2GB during traffic spikes). This doesn't seem unreasonable at all for a chat server of that size. Meanwhile, Synapse has been steadily improving too.

On the client side, Hydrogen (https://hydrogen.element.io, https://github.com/vector-im/hydrogen-web) is our next-gen client implementation, which gives you full E2EE, complete with backup (I have no idea what Durov is banging on about in the OP) - and uses 14MB of RAM for an account in 3,000 rooms spanning 350K users (i.e. my personal one). This is an 100x improvement on Element Web which uses 1.4GB for the same account, although there's also a lot of optimisation that can be done there too.

If I was going to criticise Matrix, I'd focus more on the fact that there are still a lot of papercuts on Element's UX which are holding us back. We're painfully aware of this though and are trying to fix as rapidly as we can.

it’s a entirely new codebase; probably best way to visualise progress is to look at the contributor graphs at https://github.com/vector-im/hydrogen-web

Alpine.js for reactive frontend

✨ In recent months, I have been developing web projects using GOTTHA stack: Go + Templ + Tailwind CSS + htmx + Alpine.js. As soon as I'm ready to talk about all the subtleties and pitfalls, I'll post it on my social networks.

> But honestly, torn towards htmx but undecided.

We are in the middle of migrating from our monster react application into server rendered pages (with jinja2). The velocity at which we are able to ship and the reduction of complexity has been great so far.

Managing client side state for simple things like (is the dropdown open/closed), listening to keyboard events and such can be done with something like alpine-js [1] without all the baggage that something like react brings.

It appears this is already the trend with JS frameworks too - with server side rendering being the new norm.

[1] https://alpinejs.dev/

Sure, you can use any number of JS-avoidance libraries. I'm a fan of Turbo, and there's also htmx, Unpoly, Alpine, hyperscript, swup, barba.js, and probably others.

Direct DOM, but with a library. Specifically AlpineJS since it follows Vue closely in design practices allowing me to scale into a full web application if necessary (basically swapping to Vue takes minimal work). The Morph plugin is specifically what I like using.

If you want more details on the initial setup I encourage you to take a look at the Part I that covers more of the initial implementation. For this portion, I added Prisma as an ORM, a frontend style library called Tachyons, and AlpineJS to handle any client-side interactions. I did this to avoid needing to add a client-side bundler to the build and instead just rely on plain old module imports to compose the frontend. This is now the default for Rails and it is quite nice to not need any additional build tools for the client.

- [swallow-pywebview](https://github.com/rangwea/swallow-pywebview)： Base on [pywebview](https://pywebview.flowrl.com/) using Python，the frontend base on [alpinejs](https://alpinejs.dev/) and [tailwindcss](https://tailwindcss.com/)。

If you’ve followed our other tutorials, you might be familiar with Alpine.js. It’s a lightweight JavaScript library that allows you to add interactivity to your site without writing a single line of JavaScript. It’s incredibly easy to use, and we’ll show you how to make the animation trigger when the user scrolls to it.

The approach is not new, essentially a variation of Knockout, Alpine, and similar "JS-in-HTML" approaches.