Portal Windows for Electron
blog.tandem.chat
blog.tandem.chat
- Easy cross platform support
- Singular language/framework (typescript/react) for everything you're doing
- Can share a lot of components/logic with mobile apps if you use React Native
Do I want my CAD software as an electron app. Obviously not, but for most applications electron is just as good an option as anything else.
And sure, if you just run one app and that’s it, you might get away with acceptable performance. But now try to install it over slow or metered Internet. Try to run it alongside Chrome/Discord/Eclipse/Spotify/Android Studio. Try to install all those apps without chewing up your disk space. These aren’t hypothetical scenarios, these are very real usability concerns.
I live in France, a first world country, just checked Amazon, the N°1 best seller laptop currently has 4GB of RAM, a 64GB SSD, and a 1366x768 screen and a dual-core Intel Celeron CPU which does not even reach 3Ghz: https://www.amazon.fr/HP-14s-dq0000sf-Ultraportable-Microsof...
this is what the average user looks like (and will still look like in a few years, if people buy a laptop today it's generally to keep it 5 years). I have never ever ever seen anyone say "hey, my computer is fast" it's always "do you think you could look at it, it's super slow / it has viruses / ..."
You get substandard desktop applications that tend to frustrate people who are deeply immersed in any one ecosystem and expect native applications to have deep integration with each platform and comply with each platform’s design sensibilities.
But history shows that applications written against cross-platform toolkits have done just fine, as have applications that completely embraced “going native” on particular platforms.
I’m left with the thought that either strategy works if you go “all in,” the mistakes come from:
1. Going cross-platform but then doing ridiculous back-flips to try to make the app feel really, really native. Just take what the platform gives you, and accept that you’re giving people a web-like experience that happens to have some native affordances. Learn to live with the few complaints from retro-grouches.
Or, 2. Going native, but skimping on deep integration and fully embracing the look and feel of each platform. This is one of those “penny-wise, pound-foolish’ strategies: You ship faster, but you lose the big benefits of a cross-platform tool, and you don’t satisfy the users that appreciate what a native app offers in look, feel, and integration.
Totally agree.
And it's a program that is slick, intuitive, and supports so, so many use cases without ever feeling overloading.
I'm only member of 6 channels and have maybe only that many private messages open at a time, maybe it becomes more intuitive it there are more? But I don't understand how that would be.
One thing that is extra annoying is that the settings window can't be a separate window, so every time I have to adjust audio settings I get muted and lose the chat focus.
I think the UI mostly makes sense, it has a hierarchy from left to right, so it is essentially a amped-up tree-view. You could argue for actually using a tree view (a la TeamSpeak), at least on desktop, and I wouldn't disagree, but it kind of makes sense given parity with the mobile app.
I don't see a need for minimal input delay for text, compared to a code editor, as when writing natural languages, they are mostly formed in sentences and therefore have a lot of "buffer" in my brain, I don't need a closed feedback loop to type. Suppose that someone that relies on that would be rightfully befuddled with any delay.
It uses 156 megabytes of memory even on this high-volume scenario, so I would say that while baseline performance is low, it doesn't get slower, which is good.
That being said, I can always find what I want in the UI, it is rather internally consistent. The voice features are excellent and it has less outages than Slack, in my experience!
no ! it's not good ! this mindset is why everything sucks :( at no point one should have to accept that "baseline performance is low" for a software developed by a multi-hundred-million-dollar company that was almost bought by MS for a few billions
I want a chat program that is: - Tolerable to use - Does not require, incessant fiddling to get to work right (it's OK if it could allow so to get it to work even better) - Has some sort of rich-text formatting - Good, low-latency voice - Tolerable video or screen sharing - I can onboard people easily - Is group-oriented, not 1-to-1-oriented - Bonus points if it has reasonable moderation tools for guests or similar
If not for Discord, I would be using something like Slack (which somehow manages to have concurrency issues when typing and some jank occurs, uses 3x the memory, and does not scale nearly as well for multiple workspaces), TeamSpeak (which has very obscure UX, requires self-hosting, and doesn't provide a reasonable rich-text-chat), Matrix (I have to either pick an equally-bloated Electron client or one of the many incomplete native clients), or something else.
The fact is that raw performance itself is rather low in my list of priorities, as long as it a) doesn't stop my train of thought and b) does not overburden my system unnecessarily when idle.
As you can see all of that is very much subjective, I'm not saying you are wrong to demand utmost performance. I also try to strive for it in the programs I write, but when consuming I prioritize stability and features.
Not to mention stuffing their UI with payment prompts left and right, showing emotes you can't use in the emote menu, replacing useful screen estate with "get nitro" and "boost servers" buttons.
I'm not excusing it, I curse Slack every day I have to use their Electron app (though mostly just use it in a browser tab now) but we have this exact same conversation every time anything about Electron is posted on HN. None of the parameters for making the choice have changed since the last time we did.
I did that too for the last couple of years, but recently switched to this client: https://cancel.fm/ripcord/ Found the link in comments here on HN.
Works well so far. There’re couple minor UX issues, e.g. hard to react to messages with these modern hieroglyphs, also images are loaded in web browser, but I can live with them. The upsides (ability to setup font faces and sizes, resource usage, GUI latency) are far more important for me.
And don't tell me development time will be remotely similar either.
Where does this come from? This is a program being distributed to other people.
> And don't tell me development time will be remotely similar either.
It will be in my experience. I haven't felt like C++ slows me down in a long time. Modern C++ and STL vectors + hash maps is the vast majority of what you need. There is no memory management to be found, just moving variables when returning them from an inner scope.
Then you have a single binary that is incredibly fast on any modern computer and even many that aren't so modern any more.
What does this have to do with anything? Everyone in the company works on 3 languages. Introducing a new language, with new runtimes and build tools and domain expertise introduces a ton of overhead.
> It will be in my experience. I haven't felt like C++ slows me down in a long time. Modern C++ and STL vectors + hash maps is the vast majority of what you need.
Every tool set has its own set of idiosyncrasies and bugs and general bs that has to be learned. Saying that introducing a new set of tools is cost free is a stupid lie.
Also known as "laziness," "greed," and "lack of pride in one's work."
I'm OK with some rando startup using something like Electron in their formative years. But companies like Microsoft have no excuse other than some middle manager's desire to buy a new boat.
It's not just a monetary/time/effort value to Microsoft or other developers either. It has value to me a user. I prefer applications that I can take with me anywhere I go and they'll be exactly the same on every type of desktop that I use them on.
The list of native desktop applications which can actually do this well for me is pretty short.
Good enough for me to consider tech. Means you can have acceptable result without spending more money.
What's Tandem are doing here is (interesting, but) atypical behaviour.
Is this a macOS specific issue, or is the JS API these guys are providing not able to catch up quickly enough?
In the actual Tandem app, windows moving like this is uncommon.
See this demo: http://stewd.io/pong/
It's still not 100% smooth, but it seems slightly better and demonstrates the ability to manually tween values. Similar performance in both Chrome and Safari.
Realistically, you won’t need to chain window movement like this in most cases (other than our chatbox, I think none of our windows stay open when their parent window is moved). Fast auto-resizing, on the other hand, is more common, and works great.
We can get the position of our _own_ windows easily, but when it comes to getting Spotify’s position, we need to do some more complex polling, which is slower (and only works when the 3rd-party window is in focus).