[mifino]

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 :)

-Mikael Author of LosslessCut

[latexr]

> 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.

[aspyct]

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.

[bscphil]

> 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.

[mifino]

> 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.

[nebulous1]

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.

[swyx]

> 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

[mrcrumb1]

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.

[mifino]

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.

[spindle]

I totally agree.

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.

[kmlben65]

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

[mifino]

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

[dddw]

Any chance for a flatpak ? Fedora Silver Blue users can't do snap

[nani8ot]

Flatpak is available on flathub.