Dev UX is only good in that we regressed to the point that there's not much left but Web, and that's what the majority of devs know as a result. The Dev UX of the Web is pretty bad, though, compared to past and present alternatives, and I'm far from having as much fun putting together UXes for the Web as I was with older tech like Qt, Swing, JavaFX, etc (the tooling was better, more efficient, they had builders for rapid prototyping that were offering a more faithful representation of the design more quickly than figma ever will, etc).
I've used Qt, Swing and JavaFX, and found all of them absolutely terrible. Qt might have at least led to some good results, but it's fairly bad to use and deploy. Especially if you want to use the latest Graphics APIs, which worked pretty badly back when I last used Qt in 2016. I much prefer Electron, or imgui for C++. I'll happily sacrifice some features so long as I dont have to use Qt.
You seem to focus on the outcome while what interests me is the programming model. Say what you want about object-oriented programming, the problem-space lends itself very well to it. In Qt/Swing/… components are just classes whose behaviour and appearance are determined by function overrides, taking as parameter event or graphics objects. Just like that, you cleanly solve everything that "webcomponents" stands for: interface contracts are determined by class constructors/parameters, customisation is just class inheritance with member override, look&feel customisation is plain calls into the graphics API primitives, layouting/responsive-design is taken care of at the just level of abstraction, and all of it takes place in the same language and ecosystem/stdlib (no HTML to CSS to JS references to keep in sync and mental overhead).
React reproduces some of this model, but with much more technical and mental complexity, bringing trade-offs of its own. I'm not calling this easier to work with, simpler, or easier to debug. It certainly gives more creative options, but only because the ecosystem is broader (and full of supply-chain risks).
> For many of them, each branch has taken of its own life and could be considered its own completely different codebase.
Seems you have bigger process issues to tackle. There's nothing inherently wrong with having per-env branches (if one thing, it's made harder by git being so terrible at branching in the general/long lived case, but the VCS cannot alone be blamed for developers consistently pushing to inadequate branches).
> There's nothing inherently wrong with having per-env branches
There is when you stop thinking in terms of dev, staging and prod, and you realize that you might have thousands of different environments, all named differently.
Do you create a branch for each one of them?
Using the environment name as branch name is coupling your repository with the external infrastructure that's running your code. If that infrastructure changes, you need to change your repository. That in itself is a cue it's a bad idea to use branches this way.
Another issue with this pattern is that you can't know what's deployed at any given time in prod. Deploying the "production" branch might yield a different result 10 minutes from now, than it did 25 minutes ago. (add to the mix caching issues, and you have a great recipe for confusing and hard to debug issues)
If you use tags, which literally are meant for that, combined with semver (though not necessarily a requirement, but a strong recommendation), you decouple your code and the external environment.
You can now point your "dev" environment to "main", point staging to ">= v1.25.0" and "prod" to "v1.25.0", "dev-alice" to "v2.0.0", "dev-john" to "deadb33f".
When you deploy "v1.25.0" in prod, you _know_ it will deploy v1.25.0 and not commit deadb33f that so happened to have been merged to the "production" branch 30 seconds ago.
Before git abused the terminology, a branch used to refer to a long-lived/persistent commit lineage, most often implemented as a commit-level flag/attribute,
OTOH, git branches are pointers to one single commit (with the git UI tentatively converting this information sometimes into "that commit, specifically" or sometimes as "all ancestors commits leading to that commit", with more or less success and consistency).
Where it matters (besides fostering good/consistent UX) is when you merge several (topological) branches together: git won't be able to tell if you just merged A into B or B into A. Although the content is identical at code-level, the semantic/intent of the merge is lost. Similarly, once the head has progressed so much ahead and your history is riddled with merges, you can't tell from the DAG where the individual features/PR/series start and end. This makes bisecting very hard: while hunting down a regression, you would rather avoid checking-out mid-series commits that might break the build, and instead stick to the series boundaries. You can't do that natively with git. That also makes maintaining concurrent versions unnecessarily difficult, and many projects are struggling with that: have you seen for instance Django¹ prefixing each and every commit with the (long-lived) branch name? That's what you get with git while most other VCSes (like Mercurial, my preference) got right from the start.
Branch is semantic. The true unit is commit and the tree is applying a set of commits. Branching is just selecting a set of commits for a tree. There’s no wrong or right branch, there is just the matter of generating the wrong patch
Branches are mutable and regularly point to a new commit. Branching is selecting an active line of development, a set of commits that change over time.
That's why git also offer tags. Tags are immutable.
Signal don't want you to build 3rd party clients and integrations, they are another fully centralised product meant to capture and lock users into what signal believes is better for them. That's the whole "we love opensource but we won't merge your PRs and might lock your account out of the network for using forked clients that got rid of features like crypto that you might not like". I'm still sour for all the bad faith placating "the ecosystem is moving" post by Moxie and the lame excuse for not supporting federation. And no, I'm not finding it hard to onboard family and friends onto secure XMPP clients and accounts.
XMPP was a well intended idea but a bad protocol. Sure federation is good, but they needed a proper standard instead of making everything an optional extension that C2S and S2S never agree on. Like getting the right auth and encryption is even messier than on email.
Also, XML was the wrong choice. Pissed me off as a dev, back when I was doing stuff with ejabberd.
That's the kind of "compelling in theory, irrelevant in practice" comment I would make if I had no/obsolete experience with XMPP. It just works, with a healthy and thriving ecosystem of compatible client/server implementations developed independently by many organisations (small and large) around the world. At the user-level, it's just plug and play. As a developer, you don't even have to see any XML (you can deserialize your stanzas into whatever higher-level/prettier construct the programming language/stack your product depends on)
The argument that xmpp problems stem from XML format is the silliest of all: from 15 years of working with xmpp, we had all kinds of problems, but none of them were caused by XML format.
On the contrary, xmpp is a very good protocol. The problem with it is that most of extensions are bad: half-baked, often contradict or duplicate other extensions, and sometimes solve only part of the problem that they intend to solve.
Disclosure: my team and I are actively working on improving xmpp, but in a rather orthogonal direction to general XSF council route.
> The problem with it is that most of extensions are bad: half-baked, often contradict or duplicate other extensions, and sometimes solve only part of the problem that they intend to solve.
I think that's in the organic nature of protocols catching-up to changing goals and priorities, as the state of the art and the user needs evolve. I think it's pretty-well acknowledged by the XSF (and to a further extent by modernxmpp.org) by curating a short-list of XEPs and behaviours to implement.
I'm glad you aren't finding it hard. I can't even get people to move from Whatsapp and Messenger over to Signal. Only computer geeks seem to care or bother, so that's who is on my Signal list.
That's why I skip the Signal intermediate stage plain and simple: once Signal inevitably enshittifies (a property of centralised services), the people you painfully brought there will no longer kindly listen to you when, lesson learned, you will try to pull them into federated services.
For anyone else (i.e. the majority, which already has 2-5-10 messaging services on their device depending on how you count), quicksy.im does a decent job at emulating the onboarding experience of phone-based social graphs (WhatsApp & al.) and substantially lowers the barrier to being reachable over XMPP.
I admire your perseverance, I gave up on Matrix personally. When was the last time you had a shot at XMPP? Have you tried ejabberd? That's probably one of the most "fire and forget" services I sysadmin, and it does everything out of the box as a single server (STUN/TURN, audio/video calls, …). That's refreshing.
Thanks for the suggestion, I am looking at it now - for some reason my first scan of the first page about it found on DDG I was convinced it was a non-self-hosted 'service' only.
Then a downloads page (which I clicked to wonder if it was 'you need a client to interact with our cloud service' kind of page.. seems to point to self hosting as an option - so I will give this a go.
I recently gave a presentation for another biz about chat community options. During the research I stumbled upon rocket chat with a totally grown up look and feel quite shockingly, and found trillian.im as possible self host contenders.
There were a couple others but some things in my features matrix made them less likely as a replacement for matrix as an option for those needs.
I'm still hopeful for matrix to become easier to deploy and easier to use, as it has real potential.
One reason wordpress got so popular is it's famous 5 minute install; and that was doing it manually.
Any noob can rent a $10 shared host, login to cpanel (or other panel these days) and click a button that installs wordpress, it's needed DB, creates the admin and emails you the details. Up an running in seconds.
somebody get matrix to run via one click with softalicious / fantistico like abilities please!
Of course wordpress benefits from lots of paid addons (for hundreds of developers not just wp/automattic) and a healthy 'pay for development ecosystem' - but most of that grew from the ease of install (and at the time lots of fancy free themes that were subsidized from many groups with different reasons).
With matrix I wish there was a chart of wanted features / fixes and people could escrow vote with dollars for things and they get released to everyone.
I think I group funded a feature for rocket chat years ago with options via bug county source? Something like that.
I also think Matrix would be better as a no federated self hosted install and connect some sort of bridge on a different server if someone wants to connect the federated stuff - less complaints and support issues with being bogged down.
The agony of trying to install has made me find other things to do so I can avoid having to do it this weekend, and I should of redone it last weekend. sigh.
> I'm still hopeful for matrix to become easier to deploy and easier to use, as it has real potential.
I mean, I'm admittedly biased here, but the "easy to deploy, $10 shared host IM" already exists and is XMPP. Matrix is doomed to be inefficient, and that's baked at the protocol level. It won't ever get easy and cheap to deploy and run, judging from the recent year's trajectory, with more and more components being added to the mix.
> somebody get matrix to run via one click with softalicious / fantistico like abilities please!
> I also think Matrix would be better as a no federated self hosted install and connect some sort of bridge on a different server if someone wants to connect the federated stuff
Another software delivering a slack-lite experience geared towards corporations is prose: https://prose.org/ it's also XMPP, their client can be used with ejabberd but they have an easy-deployment bundle that ships Prosody instead (yeah, unlike the Matrix ecosystem, XMPP has multiple completely viable and compatible implementations, ejabberd and prosody being only the two most popular).
> I wish it were easier to be a Synapse admin! It seems like all server updates are focused on scaling matrix.org and the little guys that provide network diversity are not really being considered a priority.
Matrix is a product of venture capital and the growth at all cost culture, the absurd price to play (reqs to federate with the canonical matrix.org server) made it clear from the get go. If you have your users managed externally, you could probably have a shot at setting-up an XMPP server alongside Synapse, for a tenth of the hassle and resources consumption, and see for yourself if that's an acceptable plan B.
I second the sibling comment recommending XMPP. Take a mature server like ejabberd, set up your DNS and firewall, and you are good to go. Easy, secure, extremely reliable and scalable.
Matrix problem statement/what it set to do differently is "rooms should survive their server going down". Although nice-sounding, it's never realized in practice: your server going down means your account is unavailable too, and you can't use the network. Rooms syncing is essentially "old IRC net splits" with more steps (and much more RAM/CPU). This way of tackling this sort of "high availability" at the protocol level makes implementing the Matrix spec impossible (there is only one almost-compliant server implementation to talk with almost one feature-complete client, all by the same entity, selling it as opencore). Now compare that with the half dozen or so well-maintained XMPP servers (and plethora of clients), most of which support a form for HA/resilience that happens at runtime-level instead of protocol-level (via Erlang clustering/distributed JVM). In other words, if that's what you care about, XMPP implements Matrix mission statement better, more efficiently and with less organisational centralisation than Matrix.
Yeah, no. I lost hope that they have any idea of what they are doing, or any willingness to improve and drop out of the sunk cost fallacy that paralyses them. Every two years or so they break protocol and implementations with big promises that "this time the charm, finally", and it's essentially the same slow mess with some new bugs.
Following your argument we should just outright reject progress because, for the most part, humanity has been really really shitty. Also, how much thought did you put into it before writing that this type of society isn't sustainable? Can't the things that happened since (mostly, a massive wealth consolidation) be undone? Why?
You are the best kind of correct since "many" can refer to some large number that is also insignificant. The pro-European sentiment is vastly dominant, though, and that's what matters.
reply