I just discovered this post, and I'm really happy to see a lot of satisfied long time users as well as excited new users who recently discovered this.
I think the most common criticism is that the app is large and uses a lot of memory (compared to Notepad?:P) due to it being Electron based. Somewhat unpopular opinion, but here goes: Developing an app using Electron gives such tremendous benefits that it far outweighs any downsides. It lets you easily build a cross-OS app on a super optimised, stable and secure platform that's being battle tested by billions of people around the world every day (Chromium). It gives you all the features of the web, and it "just works" on almost any popular OS. The web has all the big tech pushing new features and improvements all the time and it maintains really good backwards compatibility. I don't think I ever had the LosslessCut app actually crash on me. CI, automatic building and releasing to all different kinds of channels is a breeze due to tools like `electron-builder`.
I think if you compare it to most other lossy video editors, you'll find that the CPU usage is much lower (especially per minute of produced video!), and the memory footprint is probably lower than many other popular video editors. Storage is cheap, and what is 500mb when working with 4K video anyways, so optimising for size is mostly a waste of time and doesn't really benefit 99% of users. Counter arguments are welcome :)
> Developing an app using Electron gives such tremendous benefits that it far outweighs any downsides.
As someone who wrote performant Electron apps, I disagree. Electron has great documentation, but I found little else to praise.
> stable and secure platform
A major factor to me stopping to write Electron apps was the frequent updates needed due to some new flaw upstream. To make matters unbearable, every time there was an update something else had changed with the build tool or the Electron API, which I then had to relearn and painstakingly change everywhere.
I like apps to be done, I don’t want to be forced to babysit in perpetuity an otherwise working app.
> Storage is cheap
It is not. People buy computers and mostly stick to the internal disk which they can’t or don’t know how to change. No one is happy to have to buy and use an external hard drive because their apps—which are orders of magnitude larger than they could be—are eating up all available space.
I can't comment on your first two points, but in the context of video editing, yes, 500MB is cheap. Most of us photo/videographers are used to handling hundreds of GB of data.
You’re used to professional apps which do a lot. LosslessCut is a simple, limited app (I say this as a positive) which is perfectly usable by non-pros who don’t deal with that much data.
> in the context of video editing, yes, 500MB is cheap
This type of thinking is pretty common in HN, where they live in a rich country. Then the same people apply their situation to whole world. It's not same in developing world. People still have to manage their savings for storage.
> It lets you easily build a cross-OS app on a super optimised, stable and secure platform ... Storage is cheap, and what is 500mb when working with 4K video anyways, so optimising for size is mostly a waste of time
I get this perspective from the developer point of view, but I'm not a video editor. I'm a person who occasionally edits videos. Elsewhere in this thread I mentioned that I use vidcutter, a free and open source tool that does the same basic task. After installation it takes 14 MB on my Linux distribution (it's a 4 MB download).
The thing is, I have dozens or hundreds of tiny little utilities like this installed that make one-off tasks that I do once a month or so much easier. I can't afford for them to be Electron based on my 128 GB SSD. For people who edit videos every day it's obviously not an issue, but I wouldn't be surprised if the majority of people who use tools like this don't use them every day. Maybe not even every week. All this extra space adds up.
I think, in fairness, that a lot of the anti-Electron criticism comes from Linux users like myself. Windows users expect to have everything packaged as one gigantic binary with all the dependencies. (Vidcutter is a 175 MB download on Windows.) This strikes most of us as "poorly engineered", which for some is already enough of a reason not to use something. On Linux, the norm is that distribution maintainers put together a package with the dependencies separate, and these are shared between multiple packages. Electron applications are rarely distributed this way, and that's the biggest part of the problem and the source of a lot of the bloat from a Linux user's perspective.
> I get this perspective from the developer point of view
I'd argue also for most end users' point of view as they will most likely get a more stable app when the average developer doesn't have to write C/C++.
> The thing is, I have dozens or hundreds of tiny little utilities like this installed that make one-off tasks that I do once a month or so much easier. I can't afford for them to be Electron based on my 128 GB SSD.
That's a fair point. I also feel the pain of installing large apps on my MacBook with 256GB SSD. But I think I would still take a large app with all the other benefits than an app that might SEGFAULT all the time, but is small because it's written in C/C++ (like what has been my experience with avidemux for example).
> On Linux, the norm is that distribution maintainers put together a package with the dependencies separate, and these are shared between multiple packages
I get this point, and I used to be an avid Gentoo user myself so I compiled everything from scratch and liked the small size and efficiency of a dynamically linked system. I think the biggest drawback with this approach is that sometimes sharing libraries with "compatible" versions will cause bugs because those versions actually have certain tiny differences that cause bugs to appear, whereas with a static build you lock down the whole dependency tree (except the OS level libs), so you know almost for sure that the app is going to work exactly the same regardless of the system you run it on.
Actually because the bundled JS itself is quite small for LosslessCut (32MB), it would be theoretically possible to bring-your-own electron (even from source), e.g. use a single system-installed electron that can be shared by many different electron apps, as well as use the system installed ffmpeg. Then you could run `electron Resources/app.asar`. It might be possible to setup such a minimal build.
I very rarely have to cut video. I used to use vidcutter, but I now use LosslessCut. My experience with LC has been far better than with vidcutter. I've never even considered going back to vidcutter. I don't entirely disagree with your criticism, however the reality of the usage can easily outweigh these points (for me, obviously). Which is just to say I would recommend trying it if you haven't.
It's quite possible that LC is far better than vidcutter, I agree. Another reply to me mentioned better keyboard shortcuts, for example. I don't think this speaks to the point of whether or not the extra storage usage is justified, though, as building the application in Electron doesn't necessarily translate to a better experience.
In fact one of the reasons people dislike Electron is that it tends to result in a non-native UI appearance, which can make an application harder to learn and use.
> On Linux, the norm is that distribution maintainers put together a package with the dependencies separate, and these are shared between multiple packages.
honest question from a non-linux user - how much time do you spend in dependency hell? dynamic linking all the things sounds like a recipe for constant nightmare
I've never dealt with dependency hell, even once, on my current distribution. When necessary, distributions can ship multiple versions of a library and the software that requires each version will be linked appropriately. Basically, the answer is that the distribution is supposed to solve all these problems for you - and it does in fact work out that way in practice 99% of the time.
I understand why devs choose Electron and the benefits seems worth it overall and I'm glad it exists (and as you point out, a video editor might be an especially appropriate application for electron). That being said, it has a cost, and part of that cost is that there are certain users who don't like the experience of using electron apps. You may not agree with how big a deal this is for them, but the tone of this seems to be that they are wrong for having that preference. As a dev you don't really get to decide what users do and don't like; it's of course your prerogative to make whatever tradeoffs you wish, but I'd be careful about denying people's experience of your software.
Which exact experience with using an electron app are you talking about that some people don't like? The size or memory usage? I get that some people like to run multiple apps at the same time and are running out of memory, but I think many other apps use more memory than Electron based apps. Of course trying to reduce the memory footprint of an app is always a good thing, so that's indeed a trade-off.
Hi, actual third world person reporting from the third world.
Most of our machines have no SSD and 8GB RAM on a laptop is a luxury. You can buy brand new Celeron machines like it's 1998. Windows 10 runs like shit and Windows 11 is basically a slideshow. Electron apps are the bane of our existence.
I'm not speaking of anything specific. Clearly enough people dislike the experience enough to avoid using apps based on it altogether. That's not my view or experience of electron apps broadly, but I'm single user on a specific setup. My point is less about specific criticisms of electron and more about the fact that dismissing people's experiences with it doesn't really do anything to win those folks over.
I object to Electron apps when they use a lot of my CPU cycles AND they're for functions that I want to run all the time, like chat programs. Not a problem for a video editor.
thank you very much for it being free and open source.
can container repacking be avoided? currently hls ts container is being extracted which takes time.
seeking "unsupported videos" is much slower than supported
Not sure what you mean by container repacking, but if you mean "Converting to supported codec", you can try instead from the File menu to convert using the "Fast: Full quality remux (no audio), likely to fail"-method. that is much faster and if it works it allows native scrubbing. Also I'm planning on improving the "Unsupported videos" experience in the future by using something like the MediaStream API
If you mean a video where the camera was rotated while recording, I believe no, that's not possible to do losslessly. I believe the orientation flag stored in the metadata cannot change over time. Correct me if I'm wrong.
- author
HEVC is supported in the latest beta version, if your computer has a hardware HEVC decoder. It's a WIP as HEVC support was just recently introduced into Chromium (source: author)
You should try to learn JS - it's really awesome. Asynchronous, incredibly stable, battle tested by billions of users every day, it has one of the best open source module ecosystems in the world, and it runs everywhere.
I might add the ffmpeg-static npm package, then no need for system ffmpeg. But that package does not work on raspberry pi, so yeah.. Downloading and installing static ffmpeg builds from ffmpeg.org is pretty easy these days
If by mute you mean cut away, then that's not implemented yet. You can achieve an inverse cutting by adding the same clip twice though, with cutFrom and cutTo.
I agree that Electron apps can be slow. I think that has to do with the single thread event loop, which it is very easy to block when doing some heavy processing, if you don't think about it all the time. On the other hand Electron apps are very stable and I don't think I've ever had one segfault on me, like happens with a lot of native applications. It's still quite early in the world of Electron, so I can imagine speed will increase as people develop new techniques for writing better code for complex apps. Like VS Code probably did something right there.
That's a bug then: https://github.com/mifi/lossless-cut/issues
Edit: could you check if ffmpeg was still running while it was spinning? Maybe we need to kill it if it takes too long.
