17 ms·

Why Remotion is a native macOS app, not Electron

157 points by ushakov 5y ago

weejewel 5y ago
Sometimes I feel teams choose Electron/webapps because nobody knows how to design a great Windows-native application. If Windows truly had a great UI+UX equal to macOS, the investment of native apps would be much more worth. Now creating a web app for windows is almost the de facto choice because there’s nothing better!
- forgotpwd16 5y ago
  If Windows was only the case we wouldn't be having a blog post explaining why they didn't chose Electron for a program running exclusively in some other platform. As that implies that Electron is very widespread even in that platform.
- duxup 5y ago
  >because nobody knows how to design a great Windows-native application In that case it is a question of resources right? Nobody in our org knows how to do that thing well, so we could have them go learn or ... use Electron and get the app out the door... The choice for an organization with limited resources seems obvious.
  - weejewel 5y ago
    I meant to say — Because Microsoft doesn't lead by example and doesn't offer the correct documentation & tooling.
    - MiddleEndian 5y ago
      They also don't lead by example in their software. In basically every single text field/area in Windows, `CTRL Delete` deletes the current word and leaves the space before it, so if you type "Hello Hello", hit ctrl delete, and then type "Goodbye" your result will be "Hello Goodbye". In Windows Mail, for reasons unknown, it deletes all the way to the last character of the previous word. So if you type "Hello Hello", hit ctrl delete, and type "Goodbye", you get "HelloGoodbye". It's baffling. Why make a unique UI element just for this that's inconsistent with the rest of the operating system?
- ushakov 5y ago
  - speedgoose 5y ago
    I’m quite sure Microsoft has enough applicants to filter such candidates and only go with experienced or competent web developers.
    - ushakov 5y ago
      yeah, imagine what desktop apps would look like without web developers fast startup time, no battery drain, low system requirements, native look and feel… guess we don’t deserve it
      - speedgoose 5y ago
        You forgot “doesn’t exist for your operating system” in your list.
        ushakov 5y ago
        i’d love to have an OS that doesn’t support Electron
        jakear 5y ago
        FreeBSD. Let me know how it goes for you. Genuinely interested.
        johnny22 5y ago
        seems there's a port now (based on electron 13), although not merged upstream
        speedgoose 5y ago
        FreeDOS perhaps.
- tapoxi 5y ago
  I think Electron won out because Microsoft kept pulling the rug out from under Windows developers as they went from Win32, to Windows.Forms, to WPF, to UWP, to WinUI 3. Why take the risk on the most modern Windows framework when you could just go Electron, have a broader pool of developers, and get Mac & Linux support as well?
  - throw10920 5y ago
    I'd like to point out that, while that's a good reason why Electron might have won in terms of developer mindshare, that's not necessarily the reason why it won on in terms of marketshare. I personally believe that the cause of the latter is a combination of (1) cost-saving through fewer platforms to support (2) cost-saving through a larger developer pool and (3) better branding support, but I've never worked in the business myself.
  - TYPE_FASTER 5y ago
    Don't forget Silverlight!
  - yardie 5y ago
    I remember having to import obscure Win32 libraries because the latest platforms were never complete. Like the fontpicker would drop you from WPF to Win32 because MS couldn't be bothered to update it.
  - aejae 5y ago
    This. We (at Remotion) are currently evaluating what platform to build for, given our start with macOS native / Cocoa. But for Windows, what is Windows Native? Seeming like more of a collection of half-baked ideas than robust frameworks that we'd want to bet a bunch of dev time on. As you both mention, we might end up with a cocoa macOS app and an Electron app for Windows & Linux.
    - jeppester 5y ago
      Please don't make Linux users suffer because of Windows.
- drcongo 5y ago
  This might be a stupid question, but is MS Teams Electron on Windows? It would strike me as weird that the maker of the operating system doesn't use their own UI toolkits?
  - aejae 5y ago
    Yep! https://docs.microsoft.com/en-us/microsoftteams/teams-memory-usage-perf#:~:text=Teams%20is%20designed%20to%20use,browsers%2C%20including%20Edge%20and%20Chrome https://docs.microsoft.com/en-us/microsoftteams/teams-memory....
    - drcongo 5y ago
      Good lord. I can't imagine Apple putting out an Electron app.
      - raydev 5y ago
        The Apple Music app was effectively an Electron app for a few years before the Catalyst version arrived, just a shell around webviews. And even now, there's still a bunch of webviews in the app today. Mac Messages was comically just a plain webview for years. Again, that changed with Catalyst.
        heresaPizza 5y ago
        MacOS 12.3 just changed that and the difference is incredible. All the Apple music screens load much faster, especially the search one that previously was not just slow but also broken
        oscarmv 5y ago
        Uh no. The old client's chat transcript was using WebView for display with a bunch of custom-fed CSS/HTML/DOM that was built in code. The rest of the app was good ol' AppKit. The whole chat transcript being a web view thing was one of the main reasons the app eventually got killed in favor of a Catalyst version. There was zero expertise in the team to make all the random new transcript features that the designers kept throwing on the iOS client and there was also no way to reuse the knowledge and code of the iOS team either. Various attempts to rewrite the mac client's chat transcript to native throughout the years failed due to lack of resources and/or corporate bullshit.
- jenscow 5y ago
  You're right. On Windows, the current "native" UI toolkit is WinUI. I quoted "native", because it's not really native. It's just what's in active development by Microsoft at this point in time. Creating a desktop-web-app is just more convenient, because of skill re-use and you know it will continue to work, not only on Windows but Linux and OSX. Web is more mature and will continue to evolve. On Windows, no one cares anymore if your app has a "native" UI - the OS itself has conflicting UI styles, and most main-stream apps are different. Not the way I like things, but it's the way things are.
  - fassssst 5y ago
    What does “native” mean to you? WinUI is implemented in C++, contains the control set of the current design language, and is used by the Windows shell itself and even Notepad. Yea it looks different than what you can get from CreateWindowEx with the various control styles, but those also look different than MFC, Windows Forms, etc.
    - jenscow 5y ago
      Win32 is what I would call native, and MFC/WinForms are wrappers around that. So in technical sense, WinUI is as native as Qt/wxWidgets. Just my preference on terminology, rather than anything against WinUI (I've been developing a WinUI app).
      - fassssst 5y ago
        None of that Win32 UI stuff is being updated anymore so it’s more “classic” than “native.”
        marwis 5y ago
        One could say both are native Windows UI toolkits. Kind of similar to when Apple shipped Carbon and Cocoa.
    - captainmuon 5y ago
      I would call it almost, but not quite native. There are some things MS internal apps can do, but that WinUI 3 can't. (Until recently, creating additional Windows, but also things like blurred transparency.) I think a real native solution would be shipped with the system, and get an updated theme and feel with an OS update. But the last version that did this was Win32/Uxtheme and to some extent WPF. Metro/UWP formally did this, but it encourages you to hardcode a lot of styles, so you have to update your app when a new Windows version comes out. But I think MS has moved away from shipping the UI library with the system. The real native UI is what MS uses internally, and for a lot of products that is DirectUI. It is used in Explorer, the start menu used it for some time in Win10, I think the control center also used it. But also MSN messenger used it, and Office, too. Spiritually it is similar to WinUI 3 I think: implemented in native code, drawing "windowless", and using some kind of XAML.
- ravenstine 5y ago
  Maybe that's the contributing factor, but I really think it's more of an economic decision. There are far more JavaScript developers out there, so it's easier to hire people to work on an Electron app and have crossover between other teams working on web-based projects. Write-once-runs-anywhere is also a part of it. JavaScript is also extremely forgiving and has possibly the easiest debugging experience of any language I'm aware of. This isn't to say that JavaScript developers don't often do things that completely subvert the advantages of writing web-based apps, but those advantages are nevertheless on the table regardless. Writing a truly native application will always be more challenging than writing a web app (or even something like a Python-based app) and will always require some amount of specialization no matter what anyone says (as has been observed with React Native and I'm guessing that will inevitably happen with Flutter). UI is also one of the hardest things to do right when writing cross-platform applications. Business logic is usually quite portable, but UI introduces geometry and fundamental incompatibilities between widget toolkits. The web, with some exceptions, ignores native widgets, thus the problem of writing UI code mostly goes away because there's only one toolkit to work with.
  - socialdemocrat 5y ago
    “Extremely forgiving” is what I think is worst with JavaScript and makes debugging harder. Stuff does not blow up when it should. Good debugging requires “fail fast” IMHO, not JavaScript style “keep going until it is not humanely possible to continue with broken state”
    - ravenstine 5y ago
      Anything that is easy can as easily have pitfalls. > Stuff does not blow up when it should. Good debugging requires “fail fast” IMHO, not JavaScript style “keep going until it is not humanely possible to continue with broken state” It depends on what you value. JavaScript and the rest of web technology is good at getting something on-screen and working, more or less. Many businesses, for better or worse, don't care about software architecture and developer happiness. They want something working, and ASAP, and more features to be rolled out for all platforms. Web technology, for all its faults, is going to win every time. Even better when code is written in such a way that debugging your JavaScript doesn't end up being so much of a hunt through a stack trace with layers upon layers of framework code. Granted, I do agree in general that "fail fast" is better, and I absolutely think that it's practical to write JavaScript code in such a way, but that's not an attractive selling point for JavaScript or Electron. That's like a PSA telling people to eat their broccoli; Electron is like telling people to eat plenty of donuts, and most people are going to eat donuts because companies of all sizes are all too happy to treat the resulting diabetes (metaphorically speaking).
- holbrad 5y ago
  If I wanted to make a native windows application I really wouldn't know what to use ? WPF is what I've worked with. But WPF is awful. When I was doing some games programming using Imgui for little widgits was actually quite nice. But wouldn't want to use C++ generally for an application. What do people actually recommend ? Electron seems to be the go to.
  - n8cpdx 5y ago
    I work in WPF, UWP, and Xamarin.Forms daily. I’m a little offended by the comment about WPF; WPF is stuck in 2006 but at least is about as polished as you can expect from a 16 year old product. Microsoft should aspire to make their other UI offerings half as good as WPF. UWP is like WPF, but with critical features stripped out, broken core functionality (e.g. renderers for paths/SVGs are super broken), and an 80% chance of facing a COM exception if you try to do anything remotely interesting. I’m learning web tech so I can make a career change - I built my career on .NET client technologies and I deeply regret it. Take it from a (former) Windows fanboy, choose Electron.
- me_me_mu_mu 5y ago
  I think Electron/crossplatform tools are great at very early stages in order to test whether the product can work. You can quickly put together a working cross platform application to start testing features. I am a noob at startups (working on some of my own ideas) but I almost always start with the most simple set ups (zapier + google forms tbh) to try some process with 5-10 people. If that seems promising I'll build a app over a weekend/5 days using flutter, and then get that into people's hands. I've not used electron, but at least my thinking is that if I can validate an idea and come up with a good business model, I can grow to a point that I can hire actually competent engineers to build the best experience for the users. The primary goal (at least as it seems to me) is to solve some problem that people are comfortable making some tradeoffs(mostly unnoticed by normal people, let's be honest otherwise they wouldn't even want to try a bare bones google forms + email) while providing far more value to them. Ultimately these are all tools, use the right one where it matters until it needs to be upgraded or changed.
- SureshG 5y ago
  > because there’s nothing better! You should check out compose multi platform - https://www.jetbrains.com/lp/compose-mpp/ https://www.jetbrains.com/lp/compose-mpp/
- tinus_hn 5y ago
  Is there even such a thing as a Windows-native application?
  - ChasingEchoes 5y ago
    yes. There is only one that i can think of. Notepad++
- NicoJuicy 5y ago
  They are getting there ( after a very long road) - https://devblogs.microsoft.com/dotnet/dotnet-maui-preview-14/ https://devblogs.microsoft.com/dotnet/dotnet-maui-preview-14...
nicolas_t 5y ago
Just reading that he wrote Watson. I really loved that app and I really hate Apple for having sherlocked it and then left that new app to die.
- danremo 5y ago
  Thanks for your kind words, Nicolas!
atonse 5y ago
This is kind of an Ask HN: Is there actually a trend in the grand cycle of ideas where we're returning to native apps? If so, what's causing that? Is there some tech that's making it easier? (Maybe easier memory management, big enough market on each platform, React Native on the desktop, or many native-mapping frameworks, or Swift UI on macOS) Maybe people are tired of Electron? I'm only talking about devs because many users won't really explicitly notice.
- duxup 5y ago
  I don't know if there is a trend, just developer folks talking about it. There are endless amounts of developer chatter about using / not using Electron. As a user ... I really don't care what they use, the app runs well or it doesn't and I don't care why.
  - finiteseries 5y ago
    Users don’t consciously care about 99% of UI and UX, the entire field is at some level the art of ensuring they continue not to care, not to notice.
  - jbverschoor 5y ago
    > As a user ... I really don't care what they use, the app runs well or it doesn't and I don't care why. Well, Facebook almost lost the game completely because they were using a hybrid app.. Users cannot articulate why something si ruining performance (maybe not their app, because it simply has a higher priority set..)
    - BackBlast 5y ago
      Facebook's initial offering was horrible because it was a horribly developed app, it wasn't the fault of the underlying technology whatever they claim. Lots of people have built similar apps on web views that don't suck. PWAs, for example, can have downloadable bundle sizes < 5 MB, run in < 50MB ram, and have plenty of headroom for lots of features. You only need electron with it's own copy of a browser if the browser sandbox is unacceptable for your use case.
finiteseries 5y ago
I’ll be following along, hopeful you’ll publish more specifically on hiring as time goes on. Would also love any other recentish articles about hiring macOS developers if anyone’s got em. I’m very bearish on native macOS after the most stereotypical “worse is better” experience in the late 2010s working on a macOS (now electron) product, but am increasingly reconsidering. It’s too early to say and I’m too cynical to anyways, but it’s starting to feel like the release of the M1s really has injected a bit of life and taste back into the scene.
- copperx 5y ago
  > It’s too early to say and I’m too cynical to anyways, but it’s starting to feel like the release of the M1s really has injected a bit of life and taste back into the scene. If anything, this creates a justification for using Electron. "Macs are too fast, even when using Rosetta, so who cares if we use Electron?"
  - chipotle_coyote 5y ago
    I'm sure that's going to happen -- arguably, it already is, with 1Password moving from native toolkits to Electron on the Mac -- but it at least feels like there's a bit of a pushback on that in the Mac indie dev community in particular. Apple Silicon is part of that, but Catalyst's also starting to get its act together and SwiftUI is...well, arguably a couple years out from getting its act together, but promising.
  - oscarmv 5y ago
    I guess the question would be if a larger pool of users willing to vote for native apps with their $$$ would counteract the dynamic you mention. After all the worst possible dev environment will get extensively used if there's money to be made using it (I'm thinking of talking with PS2 developers 20 years ago…).
- embirico 5y ago
  (Cofounder @ Remotion here.) One challenge with hiring macOS devs is that they don't usually come from cookie-cutter backgrounds. For example, they might have been indy devs, or consultants for a while. And those folks often fare poorly in traditional tech interviews. Hiring for macOS led us to drop standard loops in favor of contracts, projects, or however the candidate can best demonstrate skills. We have a recent blog post about "objective-based recruiting" here: https://www.remotion.com/blog/standardized-interviews-stifle-diversity-fix-them-with-objective-based-recruiting https://www.remotion.com/blog/standardized-interviews-stifle...
rbanffy 5y ago
One of the things I like about native apps is that they can tie into the platform’s specifics. If you build it right, a lot of your code can be platform-neutral calling into platform-specific behaviours such as, but not limited to, the UI.
drcongo 5y ago
I'm starting to wish Apple would ban Electron apps on macOS. They'd all be so much better if I never had to look at them.
- criddell 5y ago
  macOS doesn't give Apple anywhere near the leverage on desktops that iOS gives them in mobile. If they banned Electron, the only thing that would change is you would now run the app in Chrome or not at all.
  - drcongo 5y ago
    Yeah, good point. It will remain a fanciful daydream.
- tjpnz 5y ago
  I'd be happy with some "nutritional" information alongside the usual app info. If I'm trying to choose between several note taking apps for instance (assuming they both claim to deliver a similar set of functionality) I might just go with the one that's not going to hog all my memory or drain my battery. Like nutritional labels on food it won't be completely accurate, but at least I'll know to choose the crackers over the chocolate cake if I'm trying to lose weight.
  - aejae 5y ago
    This is a really cool idea. This could start with a small but growing group of apps that opt into that transparency.
  - kitsunesoba 5y ago
    Something Apple could do is extend macOS’ finger-pointing at resource hogs. It already lists egregiously heavy apps in the battery status item, but if it did something more visible like show a notification (or maybe even paint a red outline around windows of offending apps, it’d increase user awareness and thus pressure on developers to do better when it comes to efficiency.
criddell 5y ago
It seems like macOS is the only desktop operating system that has anything interesting happening on it (I say that as a person who primarily uses Windows and Ubuntu on the desktop). Not a lot, mind you, but there appears to be at least some interesting new things popping up for macOS. For Windows, I'm not counting games because that feels like its own thing.
- city41 5y ago
  Recently Flathub was posted here on HN. It looks like a decent attempt to inject some life into desktop Linux. https://flathub.org https://flathub.org
  - smoldesu 5y ago
    Flathub is it's own can of worms, as is Flatpak. There's a number of "next-gen" Linux users who love to demonize people who are critical of new tech like Wayland, GNOME and the like, but I'm the most critical towards Flatpak. Linux doesn't need more hack-y ways to get bad software running: we need more robust ways to get software running well. Flatpak is a shotgun approach to getting an app working, where someone said "your app doesn't run? let's just containerize it!" Needless to say, this is not a great idea in concept, practice, or it's current execution. I think a much better idea would have been to copy what NixOS does. Yes, your developers have to do a little more work, but you can finally have reliable builds, fix your dependency graph, and actually run your software natively. I'd love for a more uniform "AppImage" style of installation, but Flatpak is definitely not it. Too many sharp edges.
    - zozbot234 5y ago
      Containers are a native technology in Linux. The issue with Flatpak is that it comes with its own bundles for underlying desktop components that add some duplication and overhead (in memory use and disk space) compared to what's provided out of the box, but that's a requirement if you want genuinely portable applications.
      - 5y ago
endisneigh 5y ago
This app is a great example of why you should use electron in the eyes of some: this is Mac only. If it were electron it wouldn’t be.
- friedman23 5y ago
  Yep, if you were making a purchasing decision for your company and you had some users on windows or linux this app is immediately crossed off the list.
  - copperx 5y ago
    And the list of Mac-centric businesses is minuscule.
  - embirico 5y ago
    Cofounder here. Yep, this happens and it sucks. We view it as a hard and temporary tradeoff to be loved by few rather than liked by many.
    - ushakov 5y ago
      maybe you consider Apple’s approach with FaceTime: offer app for Apple platforms but allow joining via Web Browser?
      - aejae 5y ago
        :) Planning to release this next week!
- throw10920 5y ago
  No, this isn't a reason. They're Mac-only because they used Cocoa, which is exclusive to macOS. If they'd used GTK or Qt they could have shared 90% of their application code between at least the three major desktop operating systems, without using Electron.
  - 5y ago
1123581321 5y ago
This product looks great. I think their instincts are correct, that an app constantly open needs to be performant or else even regular users will grow to resent it and use it less than they might’ve. The comment about the difficulty of hiring is an interesting one. I haven’t come across a helpful, beautiful and interactive resource to teach those paradigms, as you find created for any language/framework combo used for web development. There also aren’t many huge desktop teams outside of Apple, Microsoft, AgileBits, etc., so it’s hard for someone to find a starter role where it’s okay to contribute minimally as they learn. Lots more lone wolf or tiny team programming where any kind of apprentice would just be a drag.
- oscarmv 5y ago
  It's honestly not that hard for a random iOS dev to learn the macOS ropes, the principles and paradigms between UIKit and AppKit are the same and at this point both frameworks have a comparable amount of baggage and quirks. AppKit adds some complexity in some areas (window management comes to mind, which UIKit has now but no one bothers with) but helps in others (document management is still miles ahead of UIKit's). The problem is convincing someone to try. There's a reputational issue "AppKit is haaaaard" "AppKit is baaaaad" "AppKit is dyiiiiiing". There's also a career issue as it's felt that building native mac apps is a career dead end.
smoldesu 5y ago
Fine with me, it just means I'm not going to use this. On an individual basis that's fine, but if you intend to get some B2B action by selling this app to shops and groups >25 people, you should be aware that supporting only one OS is going to make it a lot harder to pick your app. Again though, serve whatever niche fulfills you. I don't even know what their app is/does after reading this article, so I'm going to assume it's not a life-changer so much as it is a native version of something we already have.
- viktorcode 5y ago
  They didn't say they are going to support macOS only.
- aejae 5y ago
  Agreed—and we're currently deliberating how we'll build for other OSes. Re the article not explaining what Remotion does, we're trying to avoid plugging our app itself in our technical posts—we figure anyone who's interested can click onto the main site.
  - smoldesu 5y ago
    That's fine. I just don't really see much of a use for this personally, especially if it's Another Competing Standard for video calls. I've been able to get similar results by just pinning a Google Meet window at the top of my screen, but maybe I'm missing a killer feature here?
    - aejae 5y ago
      Fair enough. Many of our users used to do what you do. Reasons they sometimes switch from long-lived Meet calls: - Free up 200-300 MB of RAM when in call. - Features specific to coworking (e.g. shared music DJing) or eng pairing (e.g. multi-way screen share). - Presence when out of video calls. For example, you'd see if anyone on your team is in the Meet without having to ping each other. Leads to more unplanned hang outs.
vikeri 5y ago
The fact that Apple's developer tooling is described as great makes me suspicious if the author has used JS tooling in a serious way. VS Code is just so much better than XCode. My experience developing native apps in SwiftUI is also that the documentation is very very lacking. And lastly I wasn't able to get a hover effect without dropping tons of frames. My lack of experience I'm sure is partly to blame for the app's poor performance, but it certainly wasn't performant out of the box. React would have been significantly more performant for my use case.
- Shadonototra 5y ago
  Wrong People who say such thing have no idea what they are talking about Debugging with VSCode is a joke, and there is no GUI preview for Cocoa/UIKit/SwiftUI XCode has many flaws, but it's properly integrated and helps you to make beautiful native apps VSCode is a UX nightmare
  - jeffkeen 5y ago
    VS code feels so third-party-extension and custom-config dependent and I’m sure OP has their VS code settings _just right_ for them, but that does not make it a good editor for everyone. I love this community, but the people who are comfy configuring Linux and cant understand why everyone doesn’t roll their own solutions generally don’t know shit about what good UX is. VScode ain’t it, that’s for sure.
    - handsaway 5y ago
      Installing the most popular LSP implementation for the language you're using is hardly comparable to setting up, like, an Arch install.
  - realusername 5y ago
    I'm not going to be objective but XCode is the single worst piece of software I ever used. 12 GB to download, more sluggish than the worst electron app, terrible UX, undocumented config files screwing up with git, terrible error messages, app upload is so unreliable even Apple had to create a third party app and tied to the OS version. Developers have no choice, it's clear and they know it.
mc4ndr3 5y ago
But does Remotion support native Windows and Linux ports? I've never minded the speed, expressiveness, intuition, or integration of Electron. All the value is in portability. A desktop app limited to just one operating system is near useless today.
- aejae 5y ago
  Not yet, but soon! TBH only time will tell whether our decision to go native-first, then cross-platform (vs Chromium-based cross-platform) was the right call.
sirwhinesalot 5y ago
For anyone thinking the tradeoff is fully native, single OS specific vs cross-platform Electron, do remember there are intermediate options, and I'm not talking Qt (though that's also an option). You could make a minimal native app shell for each platform, with the most relevant integration points, and then host a native webview within that shell that shares its UI across platforms. Not quite as nice as true native, not quite as fire-and-forget as Electron, but certainly more efficient and integrated than the latter and a lot more cross-platform than the former. Would have been nice to have a real, cross-platform UI library that uses the native controls everywhere, kinda like what WxWidgets hoped to be. Unfortunately Microsoft in their push to make Windows desktop development into a Lovecraftian nightmare, made that all but impossible.
- exfascist 5y ago
  Mobile OS dev makes Windows look nice. At least windows has some cross platform toolkits (TCL/TK, Wx etc.)
- embirico 5y ago
  This sounds great in principle and I saw this tried for several years for Dropbox mobile. It was a failed experiment though: > By writing code in a non-standard fashion, we took on overhead that we would have not had to worry about had we stayed with the widely used platform defaults. This overhead ended up being more expensive than just writing the code twice. https://dropbox.tech/mobile/the-not-so-hidden-cost-of-sharing-code-between-ios-and-android https://dropbox.tech/mobile/the-not-so-hidden-cost-of-sharin...
  - sirwhinesalot 5y ago
    Isn't the Dropbox desktop app Electron crap these days? It's certainly not the pleasant experience it used to be. Plus what you're talking about there is the opposite of what I'm suggesting, you wrote 2 UIs with a shared C++ logic, I'm suggesting two native platform layers with hosted webviews.
    - aejae 5y ago
vxNsr 5y ago
I’d be interested to understand how this app is any different from iMessage and FaceTime aside from not having an iOS app?
Shadonototra 5y ago
the Apple culture at its best - look good - native - fast by default Microsoft on other hand... they still don't know what UI framework to use, and all of them are bloated AF
- oscarmv 5y ago
  Don't worry, nowadays mac devs don't know what UI framework to use either!
howon92 5y ago
I was going to say the downside of not being able to support the platforms other than Mac seems too big. But I think it makes sense if the experience is 10x better on Mac because of it being a native app. After you build a good fanbase, you can probably raise more money for you to recruit a team to build a native app on other platforms and maintain separate codebases. Then, you’d have 10x better experience on all platforms!
- hn_throwaway_99 5y ago
  I mean, there are some companies out there that are 100% Mac only, but even then with a chat app you are extremely limiting your userbase if there are no interoperability options. The second you need one person on a Windows machine you can't use this.
rubyist5eva 5y ago
Interesting article, got me to actually check out Remotion itself too and the demo video is definitely slick. Would love to try it out but we're only a handful of developers that use macOS at my job so I'm afraid we wouldn't get much mileage out of it unfortunately.
- aejae 5y ago
  Cofounder here. Thanks, appreciate it! What platforms are your coworkers on? You're welcome to try it if you'd like or I can let you know when we support those platforms. If interested LMK at alexander [at] remotion [dot] com
  - rubyist5eva 5y ago
    Mostly Windows, and I believe one person using Ubuntu.
neya 5y ago
Ok, the discussion of MacOS vs Electron aside, I happened to check out the actual product and to me it seems like a glorified surveillance tool for remote workers. I think the best part of remote work you get is the flexibility, privacy and freedom that you don't normally get with 9-5 day jobs. To turn your desktop into a CCTV seems like solving the wrong problem for me. I don't know how employees even agree to this! "We will monitor you 24/7 via a video call on your laptop" Why would you do that? I have never been pissed off at a product this bad.
- peppertree 5y ago
  Yeah no thank you. It's fine if they pitch it as a slicker alternative to zoom but not an always on surveillance tool.
  - aejae 5y ago
    Cofounder here. See my reply(ies) to the first comment in this thread: We are emphatically not building an always-on surveillance tool.
- 1123581321 5y ago
  Your comment made me curious about this. I found their old home page that seems much more oriented around assuring that it’s not meant to be an always-on tool. https://www.remotion.com/home-old-2 https://www.remotion.com/home-old-2 It’s important when applying for a remote job to figure out what kind of remote culture the team has. Some are reading and writing only, some like frequent short video interactions, some longer video meetings. This seems optimized for the second type of culture with the option to use it as the third type.
  - aejae 5y ago
    Cofounder here. Thank you for taking the time to check that out. Spot on re culture: - Teams who are strict-async don’t want Remotion. - Teams who are distributed but still like hanging out want Remotion.
- 5y ago
kyle-rb 5y ago
>There is a silver lining here: if you plan to eventually build a mobile app, building a macOS app gives you a head start on building for iOS. Translation: "We plan to deprioritize Android in the same way that we're currently deprioritizing Windows and Linux."
seba_dos1 5y ago
I've seen some bad and unresponsive native applications that looked out of place, but I've never seen an app that used Electron (or CEF) that wasn't unresponsive and looking out of place.
watermelon0 5y ago
> Better AV quality thanks to direct access to low-level hardware and device APIs Can you maybe expand a bit on what differences did you encounter between using Electron vs native APIs? That might also be a good post, if you are willing to share the details.
viktorcode 5y ago
> It's difficult to hire macOS developers. Replace 'macOS' with any native platform name, and you'll get the whole reason behind Electron proliferation. It's just cheaper to make something with Electron, if you are a software development business.
StillBored 5y ago
I find many of the cross platform toolkits arguments somewhat bogus. Sure if you pick electron it looks nothing like a native app because they basically created their own UI interface that just happens to run on multiple OSs. Same for java. OTOH, QT for example still tries to use native dialogs so when you click open file, you get the native OS open dialogs/etc. Sure if your an expert you can find place where they aren't quite right, but for most people they won't notice the difference. Plus, if your really OCD about it, given your in C++ you can just add your own OS shim layer (or custom components) to correct the slight differences you might see here/there by calling the OS services natively.
sgt 5y ago
Is this the same Dan Wood as the amiga guy?
- danremo 5y ago
  Nope, never used an Amiga. However I loved Amigas since they were used to get Babylon 5 going …
  - sgt 5y ago
    Ah yes. Amigas were great back in the day. There's another Dan Wood, Amiga enthusiast, in the UK. He does a YouTube show and podcasts and such. https://en.m.wikipedia.org/wiki/Dan_Wood_(broadcaster) https://en.m.wikipedia.org/wiki/Dan_Wood_(broadcaster)
rsstack 5y ago
It doesn't matter how much RAM you're saving and how much fun you're having "thinking outside the box": our company won't use your product because we won't exclude from team communication our employees that choose to use Linux, or need to use Windows for financial software. It's absurd to me to have collaboration software that excludes people just for some technical clout.
- aejae 5y ago
  (Cofounder here) Agreed, we aren’t ready for your team yet. We’re starting with a small but opinionated target audience, and building out for other platforms from there. > just for some technical clout I think we both know that’s oversimplifying :)
- nemothekid 5y ago
  Reply this so I have a quick link I can search whenever someone complains about companies only developing Electron apps.
  - johnny22 5y ago
    but many folks (including myself) aren't counting apps specific to a platform like this one. You should have a set of quick links to cross platform apps that are native.
  - cercatrova 5y ago
    HN has a "favorite" button if you click on the permalink of a comment.
  - blub 5y ago
    I’ll reply here so that you can also quickly have access to the counter-argument: people complain about Electron because of quality issues. OP is arguing for Electron for business reasons. Which is why we’re generally exposed to so much mediocre software. Business is king and most companies do the minimum possible to get customers and grow. And if they for some reason do engineer to higher quality than their competitors, it’s quite likely that they will be outcompeted.
evanmoran 5y ago
My team is also building a native Mac app instead of electron. I used to joke that we were the last one so I’m very glad to see it isn’t so. The app looks great. Congrats Dan!

157 points by ushakov 5y ago

Sometimes I feel teams choose Electron/webapps because nobody knows how to design a great Windows-native application. If Windows truly had a great UI+UX equal to macOS, the investment of native apps would be much more worth. Now creating a web app for windows is almost the de facto choice because there’s nothing better!

forgotpwd16 5y ago
If Windows was only the case we wouldn't be having a blog post explaining why they didn't chose Electron for a program running exclusively in some other platform. As that implies that Electron is very widespread even in that platform.
duxup 5y ago
>because nobody knows how to design a great Windows-native application In that case it is a question of resources right? Nobody in our org knows how to do that thing well, so we could have them go learn or ... use Electron and get the app out the door... The choice for an organization with limited resources seems obvious.
- weejewel 5y ago
  I meant to say — Because Microsoft doesn't lead by example and doesn't offer the correct documentation & tooling.
  - MiddleEndian 5y ago
    They also don't lead by example in their software. In basically every single text field/area in Windows, `CTRL Delete` deletes the current word and leaves the space before it, so if you type "Hello Hello", hit ctrl delete, and then type "Goodbye" your result will be "Hello Goodbye". In Windows Mail, for reasons unknown, it deletes all the way to the last character of the previous word. So if you type "Hello Hello", hit ctrl delete, and type "Goodbye", you get "HelloGoodbye". It's baffling. Why make a unique UI element just for this that's inconsistent with the rest of the operating system?
ushakov 5y ago
- speedgoose 5y ago
  I’m quite sure Microsoft has enough applicants to filter such candidates and only go with experienced or competent web developers.
  - ushakov 5y ago
    yeah, imagine what desktop apps would look like without web developers fast startup time, no battery drain, low system requirements, native look and feel… guess we don’t deserve it
    - speedgoose 5y ago
      You forgot “doesn’t exist for your operating system” in your list.
      - ushakov 5y ago
        i’d love to have an OS that doesn’t support Electron
        jakear 5y ago
        FreeBSD. Let me know how it goes for you. Genuinely interested.
        johnny22 5y ago
        seems there's a port now (based on electron 13), although not merged upstream
        speedgoose 5y ago
        FreeDOS perhaps.
tapoxi 5y ago
I think Electron won out because Microsoft kept pulling the rug out from under Windows developers as they went from Win32, to Windows.Forms, to WPF, to UWP, to WinUI 3. Why take the risk on the most modern Windows framework when you could just go Electron, have a broader pool of developers, and get Mac & Linux support as well?
- throw10920 5y ago
  I'd like to point out that, while that's a good reason why Electron might have won in terms of developer mindshare, that's not necessarily the reason why it won on in terms of marketshare. I personally believe that the cause of the latter is a combination of (1) cost-saving through fewer platforms to support (2) cost-saving through a larger developer pool and (3) better branding support, but I've never worked in the business myself.
- TYPE_FASTER 5y ago
  Don't forget Silverlight!
- yardie 5y ago
  I remember having to import obscure Win32 libraries because the latest platforms were never complete. Like the fontpicker would drop you from WPF to Win32 because MS couldn't be bothered to update it.
- aejae 5y ago
  This. We (at Remotion) are currently evaluating what platform to build for, given our start with macOS native / Cocoa. But for Windows, what is Windows Native? Seeming like more of a collection of half-baked ideas than robust frameworks that we'd want to bet a bunch of dev time on. As you both mention, we might end up with a cocoa macOS app and an Electron app for Windows & Linux.
  - jeppester 5y ago
    Please don't make Linux users suffer because of Windows.
drcongo 5y ago
This might be a stupid question, but is MS Teams Electron on Windows? It would strike me as weird that the maker of the operating system doesn't use their own UI toolkits?
- aejae 5y ago
  Yep! https://docs.microsoft.com/en-us/microsoftteams/teams-memory-usage-perf#:~:text=Teams%20is%20designed%20to%20use,browsers%2C%20including%20Edge%20and%20Chrome https://docs.microsoft.com/en-us/microsoftteams/teams-memory....
  - drcongo 5y ago
    Good lord. I can't imagine Apple putting out an Electron app.
    - raydev 5y ago
      The Apple Music app was effectively an Electron app for a few years before the Catalyst version arrived, just a shell around webviews. And even now, there's still a bunch of webviews in the app today. Mac Messages was comically just a plain webview for years. Again, that changed with Catalyst.
      - heresaPizza 5y ago
        MacOS 12.3 just changed that and the difference is incredible. All the Apple music screens load much faster, especially the search one that previously was not just slow but also broken
      - oscarmv 5y ago
        Uh no. The old client's chat transcript was using WebView for display with a bunch of custom-fed CSS/HTML/DOM that was built in code. The rest of the app was good ol' AppKit. The whole chat transcript being a web view thing was one of the main reasons the app eventually got killed in favor of a Catalyst version. There was zero expertise in the team to make all the random new transcript features that the designers kept throwing on the iOS client and there was also no way to reuse the knowledge and code of the iOS team either. Various attempts to rewrite the mac client's chat transcript to native throughout the years failed due to lack of resources and/or corporate bullshit.
jenscow 5y ago
You're right. On Windows, the current "native" UI toolkit is WinUI. I quoted "native", because it's not really native. It's just what's in active development by Microsoft at this point in time. Creating a desktop-web-app is just more convenient, because of skill re-use and you know it will continue to work, not only on Windows but Linux and OSX. Web is more mature and will continue to evolve. On Windows, no one cares anymore if your app has a "native" UI - the OS itself has conflicting UI styles, and most main-stream apps are different. Not the way I like things, but it's the way things are.
- fassssst 5y ago
  What does “native” mean to you? WinUI is implemented in C++, contains the control set of the current design language, and is used by the Windows shell itself and even Notepad. Yea it looks different than what you can get from CreateWindowEx with the various control styles, but those also look different than MFC, Windows Forms, etc.
  - jenscow 5y ago
    Win32 is what I would call native, and MFC/WinForms are wrappers around that. So in technical sense, WinUI is as native as Qt/wxWidgets. Just my preference on terminology, rather than anything against WinUI (I've been developing a WinUI app).
    - fassssst 5y ago
      None of that Win32 UI stuff is being updated anymore so it’s more “classic” than “native.”
      - marwis 5y ago
        One could say both are native Windows UI toolkits. Kind of similar to when Apple shipped Carbon and Cocoa.
  - captainmuon 5y ago
    I would call it almost, but not quite native. There are some things MS internal apps can do, but that WinUI 3 can't. (Until recently, creating additional Windows, but also things like blurred transparency.) I think a real native solution would be shipped with the system, and get an updated theme and feel with an OS update. But the last version that did this was Win32/Uxtheme and to some extent WPF. Metro/UWP formally did this, but it encourages you to hardcode a lot of styles, so you have to update your app when a new Windows version comes out. But I think MS has moved away from shipping the UI library with the system. The real native UI is what MS uses internally, and for a lot of products that is DirectUI. It is used in Explorer, the start menu used it for some time in Win10, I think the control center also used it. But also MSN messenger used it, and Office, too. Spiritually it is similar to WinUI 3 I think: implemented in native code, drawing "windowless", and using some kind of XAML.
ravenstine 5y ago
Maybe that's the contributing factor, but I really think it's more of an economic decision. There are far more JavaScript developers out there, so it's easier to hire people to work on an Electron app and have crossover between other teams working on web-based projects. Write-once-runs-anywhere is also a part of it. JavaScript is also extremely forgiving and has possibly the easiest debugging experience of any language I'm aware of. This isn't to say that JavaScript developers don't often do things that completely subvert the advantages of writing web-based apps, but those advantages are nevertheless on the table regardless. Writing a truly native application will always be more challenging than writing a web app (or even something like a Python-based app) and will always require some amount of specialization no matter what anyone says (as has been observed with React Native and I'm guessing that will inevitably happen with Flutter). UI is also one of the hardest things to do right when writing cross-platform applications. Business logic is usually quite portable, but UI introduces geometry and fundamental incompatibilities between widget toolkits. The web, with some exceptions, ignores native widgets, thus the problem of writing UI code mostly goes away because there's only one toolkit to work with.
- socialdemocrat 5y ago
  “Extremely forgiving” is what I think is worst with JavaScript and makes debugging harder. Stuff does not blow up when it should. Good debugging requires “fail fast” IMHO, not JavaScript style “keep going until it is not humanely possible to continue with broken state”
  - ravenstine 5y ago
    Anything that is easy can as easily have pitfalls. > Stuff does not blow up when it should. Good debugging requires “fail fast” IMHO, not JavaScript style “keep going until it is not humanely possible to continue with broken state” It depends on what you value. JavaScript and the rest of web technology is good at getting something on-screen and working, more or less. Many businesses, for better or worse, don't care about software architecture and developer happiness. They want something working, and ASAP, and more features to be rolled out for all platforms. Web technology, for all its faults, is going to win every time. Even better when code is written in such a way that debugging your JavaScript doesn't end up being so much of a hunt through a stack trace with layers upon layers of framework code. Granted, I do agree in general that "fail fast" is better, and I absolutely think that it's practical to write JavaScript code in such a way, but that's not an attractive selling point for JavaScript or Electron. That's like a PSA telling people to eat their broccoli; Electron is like telling people to eat plenty of donuts, and most people are going to eat donuts because companies of all sizes are all too happy to treat the resulting diabetes (metaphorically speaking).
holbrad 5y ago
If I wanted to make a native windows application I really wouldn't know what to use ? WPF is what I've worked with. But WPF is awful. When I was doing some games programming using Imgui for little widgits was actually quite nice. But wouldn't want to use C++ generally for an application. What do people actually recommend ? Electron seems to be the go to.
- n8cpdx 5y ago
  I work in WPF, UWP, and Xamarin.Forms daily. I’m a little offended by the comment about WPF; WPF is stuck in 2006 but at least is about as polished as you can expect from a 16 year old product. Microsoft should aspire to make their other UI offerings half as good as WPF. UWP is like WPF, but with critical features stripped out, broken core functionality (e.g. renderers for paths/SVGs are super broken), and an 80% chance of facing a COM exception if you try to do anything remotely interesting. I’m learning web tech so I can make a career change - I built my career on .NET client technologies and I deeply regret it. Take it from a (former) Windows fanboy, choose Electron.
me_me_mu_mu 5y ago
I think Electron/crossplatform tools are great at very early stages in order to test whether the product can work. You can quickly put together a working cross platform application to start testing features. I am a noob at startups (working on some of my own ideas) but I almost always start with the most simple set ups (zapier + google forms tbh) to try some process with 5-10 people. If that seems promising I'll build a app over a weekend/5 days using flutter, and then get that into people's hands. I've not used electron, but at least my thinking is that if I can validate an idea and come up with a good business model, I can grow to a point that I can hire actually competent engineers to build the best experience for the users. The primary goal (at least as it seems to me) is to solve some problem that people are comfortable making some tradeoffs(mostly unnoticed by normal people, let's be honest otherwise they wouldn't even want to try a bare bones google forms + email) while providing far more value to them. Ultimately these are all tools, use the right one where it matters until it needs to be upgraded or changed.
SureshG 5y ago
> because there’s nothing better! You should check out compose multi platform - https://www.jetbrains.com/lp/compose-mpp/ https://www.jetbrains.com/lp/compose-mpp/
tinus_hn 5y ago
Is there even such a thing as a Windows-native application?
- ChasingEchoes 5y ago
  yes. There is only one that i can think of. Notepad++
NicoJuicy 5y ago
They are getting there ( after a very long road) - https://devblogs.microsoft.com/dotnet/dotnet-maui-preview-14/ https://devblogs.microsoft.com/dotnet/dotnet-maui-preview-14...

nicolas_t 5y ago

Just reading that he wrote Watson. I really loved that app and I really hate Apple for having sherlocked it and then left that new app to die.

danremo 5y ago
Thanks for your kind words, Nicolas!

atonse 5y ago

This is kind of an Ask HN: Is there actually a trend in the grand cycle of ideas where we're returning to native apps? If so, what's causing that? Is there some tech that's making it easier? (Maybe easier memory management, big enough market on each platform, React Native on the desktop, or many native-mapping frameworks, or Swift UI on macOS) Maybe people are tired of Electron? I'm only talking about devs because many users won't really explicitly notice.

duxup 5y ago
I don't know if there is a trend, just developer folks talking about it. There are endless amounts of developer chatter about using / not using Electron. As a user ... I really don't care what they use, the app runs well or it doesn't and I don't care why.
- finiteseries 5y ago
  Users don’t consciously care about 99% of UI and UX, the entire field is at some level the art of ensuring they continue not to care, not to notice.
- jbverschoor 5y ago
  > As a user ... I really don't care what they use, the app runs well or it doesn't and I don't care why. Well, Facebook almost lost the game completely because they were using a hybrid app.. Users cannot articulate why something si ruining performance (maybe not their app, because it simply has a higher priority set..)
  - BackBlast 5y ago
    Facebook's initial offering was horrible because it was a horribly developed app, it wasn't the fault of the underlying technology whatever they claim. Lots of people have built similar apps on web views that don't suck. PWAs, for example, can have downloadable bundle sizes < 5 MB, run in < 50MB ram, and have plenty of headroom for lots of features. You only need electron with it's own copy of a browser if the browser sandbox is unacceptable for your use case.

finiteseries 5y ago

I’ll be following along, hopeful you’ll publish more specifically on hiring as time goes on. Would also love any other recentish articles about hiring macOS developers if anyone’s got em. I’m very bearish on native macOS after the most stereotypical “worse is better” experience in the late 2010s working on a macOS (now electron) product, but am increasingly reconsidering. It’s too early to say and I’m too cynical to anyways, but it’s starting to feel like the release of the M1s really has injected a bit of life and taste back into the scene.

copperx 5y ago
> It’s too early to say and I’m too cynical to anyways, but it’s starting to feel like the release of the M1s really has injected a bit of life and taste back into the scene. If anything, this creates a justification for using Electron. "Macs are too fast, even when using Rosetta, so who cares if we use Electron?"
- chipotle_coyote 5y ago
  I'm sure that's going to happen -- arguably, it already is, with 1Password moving from native toolkits to Electron on the Mac -- but it at least feels like there's a bit of a pushback on that in the Mac indie dev community in particular. Apple Silicon is part of that, but Catalyst's also starting to get its act together and SwiftUI is...well, arguably a couple years out from getting its act together, but promising.
- oscarmv 5y ago
  I guess the question would be if a larger pool of users willing to vote for native apps with their $$$ would counteract the dynamic you mention. After all the worst possible dev environment will get extensively used if there's money to be made using it (I'm thinking of talking with PS2 developers 20 years ago…).
embirico 5y ago
(Cofounder @ Remotion here.) One challenge with hiring macOS devs is that they don't usually come from cookie-cutter backgrounds. For example, they might have been indy devs, or consultants for a while. And those folks often fare poorly in traditional tech interviews. Hiring for macOS led us to drop standard loops in favor of contracts, projects, or however the candidate can best demonstrate skills. We have a recent blog post about "objective-based recruiting" here: https://www.remotion.com/blog/standardized-interviews-stifle-diversity-fix-them-with-objective-based-recruiting https://www.remotion.com/blog/standardized-interviews-stifle...

rbanffy 5y ago

One of the things I like about native apps is that they can tie into the platform’s specifics. If you build it right, a lot of your code can be platform-neutral calling into platform-specific behaviours such as, but not limited to, the UI.

drcongo 5y ago

I'm starting to wish Apple would ban Electron apps on macOS. They'd all be so much better if I never had to look at them.

criddell 5y ago
macOS doesn't give Apple anywhere near the leverage on desktops that iOS gives them in mobile. If they banned Electron, the only thing that would change is you would now run the app in Chrome or not at all.
- drcongo 5y ago
  Yeah, good point. It will remain a fanciful daydream.
tjpnz 5y ago
I'd be happy with some "nutritional" information alongside the usual app info. If I'm trying to choose between several note taking apps for instance (assuming they both claim to deliver a similar set of functionality) I might just go with the one that's not going to hog all my memory or drain my battery. Like nutritional labels on food it won't be completely accurate, but at least I'll know to choose the crackers over the chocolate cake if I'm trying to lose weight.
- aejae 5y ago
  This is a really cool idea. This could start with a small but growing group of apps that opt into that transparency.
- kitsunesoba 5y ago
  Something Apple could do is extend macOS’ finger-pointing at resource hogs. It already lists egregiously heavy apps in the battery status item, but if it did something more visible like show a notification (or maybe even paint a red outline around windows of offending apps, it’d increase user awareness and thus pressure on developers to do better when it comes to efficiency.

criddell 5y ago

It seems like macOS is the only desktop operating system that has anything interesting happening on it (I say that as a person who primarily uses Windows and Ubuntu on the desktop). Not a lot, mind you, but there appears to be at least some interesting new things popping up for macOS. For Windows, I'm not counting games because that feels like its own thing.

city41 5y ago
Recently Flathub was posted here on HN. It looks like a decent attempt to inject some life into desktop Linux. https://flathub.org https://flathub.org
- smoldesu 5y ago
  Flathub is it's own can of worms, as is Flatpak. There's a number of "next-gen" Linux users who love to demonize people who are critical of new tech like Wayland, GNOME and the like, but I'm the most critical towards Flatpak. Linux doesn't need more hack-y ways to get bad software running: we need more robust ways to get software running well. Flatpak is a shotgun approach to getting an app working, where someone said "your app doesn't run? let's just containerize it!" Needless to say, this is not a great idea in concept, practice, or it's current execution. I think a much better idea would have been to copy what NixOS does. Yes, your developers have to do a little more work, but you can finally have reliable builds, fix your dependency graph, and actually run your software natively. I'd love for a more uniform "AppImage" style of installation, but Flatpak is definitely not it. Too many sharp edges.
  - zozbot234 5y ago
    Containers are a native technology in Linux. The issue with Flatpak is that it comes with its own bundles for underlying desktop components that add some duplication and overhead (in memory use and disk space) compared to what's provided out of the box, but that's a requirement if you want genuinely portable applications.
    - 5y ago

endisneigh 5y ago

This app is a great example of why you should use electron in the eyes of some: this is Mac only. If it were electron it wouldn’t be.

friedman23 5y ago
Yep, if you were making a purchasing decision for your company and you had some users on windows or linux this app is immediately crossed off the list.
- copperx 5y ago
  And the list of Mac-centric businesses is minuscule.
- embirico 5y ago
  Cofounder here. Yep, this happens and it sucks. We view it as a hard and temporary tradeoff to be loved by few rather than liked by many.
  - ushakov 5y ago
    maybe you consider Apple’s approach with FaceTime: offer app for Apple platforms but allow joining via Web Browser?
    - aejae 5y ago
      :) Planning to release this next week!
throw10920 5y ago
No, this isn't a reason. They're Mac-only because they used Cocoa, which is exclusive to macOS. If they'd used GTK or Qt they could have shared 90% of their application code between at least the three major desktop operating systems, without using Electron.
- 5y ago

1123581321 5y ago

This product looks great. I think their instincts are correct, that an app constantly open needs to be performant or else even regular users will grow to resent it and use it less than they might’ve. The comment about the difficulty of hiring is an interesting one. I haven’t come across a helpful, beautiful and interactive resource to teach those paradigms, as you find created for any language/framework combo used for web development. There also aren’t many huge desktop teams outside of Apple, Microsoft, AgileBits, etc., so it’s hard for someone to find a starter role where it’s okay to contribute minimally as they learn. Lots more lone wolf or tiny team programming where any kind of apprentice would just be a drag.

oscarmv 5y ago
It's honestly not that hard for a random iOS dev to learn the macOS ropes, the principles and paradigms between UIKit and AppKit are the same and at this point both frameworks have a comparable amount of baggage and quirks. AppKit adds some complexity in some areas (window management comes to mind, which UIKit has now but no one bothers with) but helps in others (document management is still miles ahead of UIKit's). The problem is convincing someone to try. There's a reputational issue "AppKit is haaaaard" "AppKit is baaaaad" "AppKit is dyiiiiiing". There's also a career issue as it's felt that building native mac apps is a career dead end.

smoldesu 5y ago

Fine with me, it just means I'm not going to use this. On an individual basis that's fine, but if you intend to get some B2B action by selling this app to shops and groups >25 people, you should be aware that supporting only one OS is going to make it a lot harder to pick your app. Again though, serve whatever niche fulfills you. I don't even know what their app is/does after reading this article, so I'm going to assume it's not a life-changer so much as it is a native version of something we already have.

viktorcode 5y ago
They didn't say they are going to support macOS only.
aejae 5y ago
Agreed—and we're currently deliberating how we'll build for other OSes. Re the article not explaining what Remotion does, we're trying to avoid plugging our app itself in our technical posts—we figure anyone who's interested can click onto the main site.
- smoldesu 5y ago
  That's fine. I just don't really see much of a use for this personally, especially if it's Another Competing Standard for video calls. I've been able to get similar results by just pinning a Google Meet window at the top of my screen, but maybe I'm missing a killer feature here?
  - aejae 5y ago
    Fair enough. Many of our users used to do what you do. Reasons they sometimes switch from long-lived Meet calls: - Free up 200-300 MB of RAM when in call. - Features specific to coworking (e.g. shared music DJing) or eng pairing (e.g. multi-way screen share). - Presence when out of video calls. For example, you'd see if anyone on your team is in the Meet without having to ping each other. Leads to more unplanned hang outs.

vikeri 5y ago

The fact that Apple's developer tooling is described as great makes me suspicious if the author has used JS tooling in a serious way. VS Code is just so much better than XCode. My experience developing native apps in SwiftUI is also that the documentation is very very lacking. And lastly I wasn't able to get a hover effect without dropping tons of frames. My lack of experience I'm sure is partly to blame for the app's poor performance, but it certainly wasn't performant out of the box. React would have been significantly more performant for my use case.

Shadonototra 5y ago
Wrong People who say such thing have no idea what they are talking about Debugging with VSCode is a joke, and there is no GUI preview for Cocoa/UIKit/SwiftUI XCode has many flaws, but it's properly integrated and helps you to make beautiful native apps VSCode is a UX nightmare
- jeffkeen 5y ago
  VS code feels so third-party-extension and custom-config dependent and I’m sure OP has their VS code settings _just right_ for them, but that does not make it a good editor for everyone. I love this community, but the people who are comfy configuring Linux and cant understand why everyone doesn’t roll their own solutions generally don’t know shit about what good UX is. VScode ain’t it, that’s for sure.
  - handsaway 5y ago
    Installing the most popular LSP implementation for the language you're using is hardly comparable to setting up, like, an Arch install.
- realusername 5y ago
  I'm not going to be objective but XCode is the single worst piece of software I ever used. 12 GB to download, more sluggish than the worst electron app, terrible UX, undocumented config files screwing up with git, terrible error messages, app upload is so unreliable even Apple had to create a third party app and tied to the OS version. Developers have no choice, it's clear and they know it.

mc4ndr3 5y ago

But does Remotion support native Windows and Linux ports? I've never minded the speed, expressiveness, intuition, or integration of Electron. All the value is in portability. A desktop app limited to just one operating system is near useless today.

aejae 5y ago
Not yet, but soon! TBH only time will tell whether our decision to go native-first, then cross-platform (vs Chromium-based cross-platform) was the right call.

sirwhinesalot 5y ago

For anyone thinking the tradeoff is fully native, single OS specific vs cross-platform Electron, do remember there are intermediate options, and I'm not talking Qt (though that's also an option). You could make a minimal native app shell for each platform, with the most relevant integration points, and then host a native webview within that shell that shares its UI across platforms. Not quite as nice as true native, not quite as fire-and-forget as Electron, but certainly more efficient and integrated than the latter and a lot more cross-platform than the former. Would have been nice to have a real, cross-platform UI library that uses the native controls everywhere, kinda like what WxWidgets hoped to be. Unfortunately Microsoft in their push to make Windows desktop development into a Lovecraftian nightmare, made that all but impossible.

exfascist 5y ago
Mobile OS dev makes Windows look nice. At least windows has some cross platform toolkits (TCL/TK, Wx etc.)
embirico 5y ago
This sounds great in principle and I saw this tried for several years for Dropbox mobile. It was a failed experiment though: > By writing code in a non-standard fashion, we took on overhead that we would have not had to worry about had we stayed with the widely used platform defaults. This overhead ended up being more expensive than just writing the code twice. https://dropbox.tech/mobile/the-not-so-hidden-cost-of-sharing-code-between-ios-and-android https://dropbox.tech/mobile/the-not-so-hidden-cost-of-sharin...
- sirwhinesalot 5y ago
  Isn't the Dropbox desktop app Electron crap these days? It's certainly not the pleasant experience it used to be. Plus what you're talking about there is the opposite of what I'm suggesting, you wrote 2 UIs with a shared C++ logic, I'm suggesting two native platform layers with hosted webviews.
  - aejae 5y ago

vxNsr 5y ago

I’d be interested to understand how this app is any different from iMessage and FaceTime aside from not having an iOS app?

Shadonototra 5y ago

the Apple culture at its best - look good - native - fast by default Microsoft on other hand... they still don't know what UI framework to use, and all of them are bloated AF

oscarmv 5y ago
Don't worry, nowadays mac devs don't know what UI framework to use either!

howon92 5y ago

I was going to say the downside of not being able to support the platforms other than Mac seems too big. But I think it makes sense if the experience is 10x better on Mac because of it being a native app. After you build a good fanbase, you can probably raise more money for you to recruit a team to build a native app on other platforms and maintain separate codebases. Then, you’d have 10x better experience on all platforms!

hn_throwaway_99 5y ago
I mean, there are some companies out there that are 100% Mac only, but even then with a chat app you are extremely limiting your userbase if there are no interoperability options. The second you need one person on a Windows machine you can't use this.

rubyist5eva 5y ago

Interesting article, got me to actually check out Remotion itself too and the demo video is definitely slick. Would love to try it out but we're only a handful of developers that use macOS at my job so I'm afraid we wouldn't get much mileage out of it unfortunately.

aejae 5y ago
Cofounder here. Thanks, appreciate it! What platforms are your coworkers on? You're welcome to try it if you'd like or I can let you know when we support those platforms. If interested LMK at alexander [at] remotion [dot] com
- rubyist5eva 5y ago
  Mostly Windows, and I believe one person using Ubuntu.

neya 5y ago

Ok, the discussion of MacOS vs Electron aside, I happened to check out the actual product and to me it seems like a glorified surveillance tool for remote workers. I think the best part of remote work you get is the flexibility, privacy and freedom that you don't normally get with 9-5 day jobs. To turn your desktop into a CCTV seems like solving the wrong problem for me. I don't know how employees even agree to this! "We will monitor you 24/7 via a video call on your laptop" Why would you do that? I have never been pissed off at a product this bad.

peppertree 5y ago
Yeah no thank you. It's fine if they pitch it as a slicker alternative to zoom but not an always on surveillance tool.
- aejae 5y ago
  Cofounder here. See my reply(ies) to the first comment in this thread: We are emphatically not building an always-on surveillance tool.
1123581321 5y ago
Your comment made me curious about this. I found their old home page that seems much more oriented around assuring that it’s not meant to be an always-on tool. https://www.remotion.com/home-old-2 https://www.remotion.com/home-old-2 It’s important when applying for a remote job to figure out what kind of remote culture the team has. Some are reading and writing only, some like frequent short video interactions, some longer video meetings. This seems optimized for the second type of culture with the option to use it as the third type.
- aejae 5y ago
  Cofounder here. Thank you for taking the time to check that out. Spot on re culture: - Teams who are strict-async don’t want Remotion. - Teams who are distributed but still like hanging out want Remotion.
5y ago

kyle-rb 5y ago

>There is a silver lining here: if you plan to eventually build a mobile app, building a macOS app gives you a head start on building for iOS. Translation: "We plan to deprioritize Android in the same way that we're currently deprioritizing Windows and Linux."

seba_dos1 5y ago

I've seen some bad and unresponsive native applications that looked out of place, but I've never seen an app that used Electron (or CEF) that wasn't unresponsive and looking out of place.

watermelon0 5y ago

> Better AV quality thanks to direct access to low-level hardware and device APIs Can you maybe expand a bit on what differences did you encounter between using Electron vs native APIs? That might also be a good post, if you are willing to share the details.

viktorcode 5y ago

> It's difficult to hire macOS developers. Replace 'macOS' with any native platform name, and you'll get the whole reason behind Electron proliferation. It's just cheaper to make something with Electron, if you are a software development business.

StillBored 5y ago

I find many of the cross platform toolkits arguments somewhat bogus. Sure if you pick electron it looks nothing like a native app because they basically created their own UI interface that just happens to run on multiple OSs. Same for java. OTOH, QT for example still tries to use native dialogs so when you click open file, you get the native OS open dialogs/etc. Sure if your an expert you can find place where they aren't quite right, but for most people they won't notice the difference. Plus, if your really OCD about it, given your in C++ you can just add your own OS shim layer (or custom components) to correct the slight differences you might see here/there by calling the OS services natively.

sgt 5y ago

Is this the same Dan Wood as the amiga guy?

danremo 5y ago
Nope, never used an Amiga. However I loved Amigas since they were used to get Babylon 5 going …
- sgt 5y ago
  Ah yes. Amigas were great back in the day. There's another Dan Wood, Amiga enthusiast, in the UK. He does a YouTube show and podcasts and such. https://en.m.wikipedia.org/wiki/Dan_Wood_(broadcaster) https://en.m.wikipedia.org/wiki/Dan_Wood_(broadcaster)

rsstack 5y ago

It doesn't matter how much RAM you're saving and how much fun you're having "thinking outside the box": our company won't use your product because we won't exclude from team communication our employees that choose to use Linux, or need to use Windows for financial software. It's absurd to me to have collaboration software that excludes people just for some technical clout.

aejae 5y ago
(Cofounder here) Agreed, we aren’t ready for your team yet. We’re starting with a small but opinionated target audience, and building out for other platforms from there. > just for some technical clout I think we both know that’s oversimplifying :)
nemothekid 5y ago
Reply this so I have a quick link I can search whenever someone complains about companies only developing Electron apps.
- johnny22 5y ago
  but many folks (including myself) aren't counting apps specific to a platform like this one. You should have a set of quick links to cross platform apps that are native.
- cercatrova 5y ago
  HN has a "favorite" button if you click on the permalink of a comment.
- blub 5y ago
  I’ll reply here so that you can also quickly have access to the counter-argument: people complain about Electron because of quality issues. OP is arguing for Electron for business reasons. Which is why we’re generally exposed to so much mediocre software. Business is king and most companies do the minimum possible to get customers and grow. And if they for some reason do engineer to higher quality than their competitors, it’s quite likely that they will be outcompeted.

evanmoran 5y ago

My team is also building a native Mac app instead of electron. I used to joke that we were the last one so I’m very glad to see it isn’t so. The app looks great. Congrats Dan!