This article would have been significantly easier to comprehend if the author had given the tradeoffs names instead of constantly referring to them by "first", "second", and "third" tradeoff. (Granted, he finally does so at the end of the article.)
(I'm not OP) Zulip is good in theory, but I had two problems with it:
1) they had no [simple] means to install it on an existing server (VPS, what-have-you). It assumed (required!) that Zulip would be the only thing on whatever you installed it on. That is, it seemed to assume a container environment (docker, etc.)
B) The public Zulip instance exposed everyone's email address in plain text, ready for easy harvesting.
iii) It's hard to alter the inertia of a team or organization of sufficient size that is already using Slack.
I like what Zulip tries to be in theory (the "topics" feature is really great), but there are two knocks against it, in my opinion:
1. They do not support self-hosting the code on a system with anything else hosted on it. You are strongly recommended to dedicate a server (VPS, Docker, whatever) to your Zulip installation. You can try to install it on an existing server, but it is far from trivial, and doing so is unsupported.
In my experience, Nextcloud's file sharing features are great, working as expected. We use it mainly to share large files with business contacts, both directions. I haven't tried the desktop apps. We use the web interface and the mobile apps.
Anecdata point: I had a lot of trouble setting up Nextcloud Talk with my own STUN & TURN servers. Even after I'd gotten that going, NCT video calls have been extremely unreliable, with it fully working only maybe 1 in 5 times, or worse. I still don't know why. Could be dependent on the kind of Internet each side is connected to (home network behind ISP router vs. coffee shop vs. corporate network with potential firewall, etc. etc.)
I'm using coturn for TURN and STUN, and they are on the same VPS that hosts the Nextcloud code, version 13. If you actually want to help me solve the problems, send me a DM on github (username Pistos), and I can give you more of the technical details.
From what I understand of STUN and TURN, there is absolutely no point running STUN an TURN on the same server as Nextcloud - if you do, you could just as well skip running them in the first place. STUN and TURN only help if they are on a dedicated box, as close to a internet root server as possible, ideally in a big datacenter somewhere on the internet backbone. They can't be behind firewalls and layers of routers...
So your performance will already improve if you delete your local STUN and TURN and use the Nextcloud STUN as our free STUN runs in a big data center. Then you have to find a TURN somewhere that you can run also close to the backbone, or try using without...
Yes, running STUN and TURN properly is a pita.
I'm no super expert so check what I'm saying, but this is based on my best understanding of what these do and I had to write our documentation for customers about our Spreed High Performance Backend which, among other things, does STUN and TURN ;-)
(Nextcloud marketing dude here)
I get the point of this, but me personally, I prefer to have aspects of me forgotten/gone rather than remembered, stored and searchable in the future. Yes, it's true that, about once every two months, I am looking for something that I swear I came across on the Internet at some point. However, the rest of the time, I'm able to re-find it just by doing another search, whether on search-engine-of-choice, or a search box on particular-website (e.g. socnet, stackoverflow, reddit, github, hacker news...).
I can't imagine writing a real-world Vue app without Vuex. As such, I can't help feeling like this article, despite the best of intentions, is probably misrepresenting things. The last several Vue apps I've written have not used `emit`; not one single time. (context: `emit` is shown/used in this article)
Well, not even Vuex is needed for that matter. It's funny that the author goes out of their way to comment on how you can mutate state directly in Vue, then doesn't take advantage of that.
Both components can share a single "plain old javascript" model object, which they just both freely update. The TodoListItem doesn't need to notify its parent of anything. In a small scale app, it's fine.
I agree, generally, that most apps eventually need it, and that this isn't the best representation of real-world vue, but there are also plenty of lightweight use cases for vue that do not require a vuex store, or even emit. if the linked comparison did use vuex, it would then suffer from a lack of redux on the react side of things, too.
Contentment comes when "the way you want it" and "the way it is" overlap enough -- but sometimes in life, you can really only change one of those.