Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

My thought process was, if I’m gonna have to rewrite the app, I may as well use the web dev skills I already have, so that at least the UI work will be in my wheelhouse. Rust is new to me, as is low-level ffmpeg stuff, both of which I’ve had to learn from scratch.

I learned Swift in order to build the Mac app, and I know from that experience that building custom UI controls while learning a new ecosystem slowed me down a lot. I didn’t love the idea of repeating that experience, and where I’m headed there’s gonna be a good bit of custom UI.



That sounds like a responsible way to divide focus. Kudos

I forget the word or the link, but I think there was a "rule of thumb" thing that circulated HN about having a limited budget for taking-risks/being-bleeding-edge, and focus in spending that on differentiating properties of your projects, while the rest should stay "old and boring"


Thanks, and yes! "Choose Boring Technology", love this: http://boringtechnology.club/

The idea of spending fewer "innovation tokens" was definitely on my mind when I was thinking through this.


Sounds like an easier process for you, but at the cost of your users. This proliferation of web tooling when it clearly doesn't suit the environment (desktop) is part of the reason why our software is getting slower, even as our hardware is improving.


Being very conscious of those downsides, I'm putting in extra effort to make sure it's fast. So far it seems to be working!

It uses less CPU than any other Electron-based video apps I've seen (and even less than a few Qt-based editors I tried) and it feels snappy.

I think tools like Figma have shown what's possible when enough attention is paid to performance early on – but yeah, it's one of my main worries with going with Electron and I'm trying to avoid the downsides as much as I'm able.

The ones I have less control over are memory usage and disk space. I'd love to get those down but it seems like that'd require digging into Chromium and ripping things out. Which, honestly, I looked at doing, but that code base is a beast and I'd rather get something into peoples' hands sooner.

On a related note: I think there's a real opportunity for an "Electron Lite", like some kind of custom Electron/Chromium build that turns off stuff you don't need. I suspect it could help disk usage + memory usage + startup time. Chromium's build system has lots of flags that make it seem like you can turn things off. But it didn't work that way when I tried, so I think it probably requires source-level changes, which then means maintaining those patches across Chromium updates etc. But really, though: I don't need WebRTC, or printing, or media codecs, or probably a zillion other things. It'd be so cool to be able to turn those things off at will.


Not always at the cost of the users?

If dceddia is able to add features and fixes more quickly, that's good for users too.

And if Svelte on the desktop becomes popular, people will likely come up with more efficient options. For example, a more efficient Electron or something like "Svelte Native", which could be a good thing.

I'd love if all software were more efficient, but getting up to speed on a new platform has a huge opportunity cost too.


Not clear from your wording, but Svelte Native incidentally does exist:

https://github.com/halfnelson/svelte-native

It's a Svelte renderer for NativeScript (a framework targeting iOS and Android), rather than being a port of React Native to Svelte.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: