I hope you will mature one day and that you will see that whatever bad experience you had with PHP (probably many years ago if not decades) is not universal.
This app is dead in the water. That doesn't mean it's not gonna provide some usefulness to groups of people, just that a iOS-only, freemium group chat will never reach mass appeal if their goal is to make money off of it.
Yup, the group-chat-thread-first model sounds very interesting
But, iOS only/first is a nonstarter for a huge portion of the population. If they're just trying to experiment is a small pond first to get it right (sort of as a throwaway version), then that is excellent. If they're planning to stay in the Apple walled garden exclusively or as a first-class/peasants model, then, well, good luck with that.
The fine article already mentions in the body and at the summary at the end that an Android client is planned but they have a small team so it will take time:
Wavelength is currently available only for iPhone, iPad, and Mac. An Android app is planned (see next item)
…
As mentioned above, Wavelength’s development team is very small. Two people, Henry and Patterson. That puts a limit on how much they can accomplish — hence the lack of an Android app at the moment.
Regardless, I don’t personally have any interest in this App at this time.
I mean, they are two people, and this product just left beta. They certainly need to prioritize. That would be equally true if they'd started with Android.
And it's especially true early in the development of any product, when major decisions are still being made, and even more true when there are sudden bursts of uptake, which can impact infrastructure in unexpected ways, which can then affect architectural decisions about the app.
Trying to do all of that on two platforms simultaneously is almost certainly an unnecessary dilution of effort this early in the development of the product.
That doesn't make Android an afterthought. It just makes it next.
I think you overestimate how huge that proportion of the population actually is. Android users heavily skew older and less interested in technology. Yes there are some tech users who use android for ideological reasons, but they are a small minority.
In terms of addressable market, Android isn’t a stumbling block to begin with.
I think self-hosting is the future of analytics for the reasons described in many of the other comments: ad blockers, browser privacy settings and content filters are here to stay and will only become more powerful. If we can’t self-host, it’s going out with the tide.
It took me about six months to notice anything to be honest. I've been on it for almost two years now and I still don't feel 100% but I feel like it's a very very very slow gradual improvement.
Getting older projects to run was a huge pain for me when I started working with JavaScript, but I have found two easy steps to get around this:
1. Use nvm + an .nvmrc file in your project to pin the major version of Node.js you are using. I recently got a five year old Node 8 project up and running with no issues using this method.
2. Try to avoid packages that has binary dependencies (like node-sass). 99% of binary issues are fixed when using the correct Node version, the only other problem that can occur is if you switch architecture (eg. x86 => ARM).
We recently solved this problem org-wide with Volta. It allows pinning both the Node and package manager (npm, yarn, etc.) version in each project's package.json file.
Even better, Volta automatically uses whatever node and package manager versions are declared in package.json -- no explicit call required. In other words, `node -v` and `npm -v` always return the version specified in package.json. It's been helpful for working with hundreds of repos and keeping CI and local dev synced on which versions to use automatically.
Why rely on nvm to pin the NodeJS version you are using? That's natively supported as a field in your package.json [0], assumimg you're using npm/yarn/pnpm (you are).
Example:
{
"engines": {
"node": ">=0.10.3 <15"
}
}
Also, god forbid you are actually running anything using Node 8 and whatever dependencies you have there, that's a recipe for security disaster.
The truth is that to use the NodeJS ecosystem we must have the discipline to keep projects up-to-date. I personally have a policy to update all my NodeJS projects at least yearly, even if they are abandoned, this includes all dependencies and the NodeJS version. Because I do it often most of the times there are not many problems to keep it working, and consequently updating is fast, but if I leave it for a few years and then come back I'll be in for a (bad) surprise.
Mostly because you want your project to just work. You've tested your project with a certain version of Node, and you want to ensure that you use the same exact version when you come back to the project in a year and want to perform some minor updates. You can set the node constraint in package.json, but that doesn't install the correct version of Node for you, unlike nvm.
Well that makes sense, as long as the developer running the code has nvm installed. Does nvm-windows read and install the versions in these nvmrc files? If it does your strategy is indeed pretty cool and I might start doing it myself. I wonder if there's any way to force specific versions of NodeJS without relying on nvm or some compatible tool.
edit: someone here in this thread suggested Volta [0] which seems literally like what I was looking for. No need for the nvmrc as it simply follows what's in the engine property of the package.json. Even better is that it's not a weird massive shell script but instead an actual program written in Rust. I'll have to try it out sometime.
How does fnm compare to volta [0] if you don't mind me asking? I see both are written mostly in Rust instead of being bloated shell scripts, although I'm not sure why choose one over the other.
