33 ms·

Building a fast Electron app with Rust

248 points by hellerve 9y ago

matthewmacleod 9y ago
I think it’s cool that people are playing around with this sort of thing. The truth is, though, I don’t understand why this architecture is attractive in this case. This is essentially a thin front-end UI on top of a fast cross-platform backend. That’s a great structure - but why not make the UI native for each platform? Calling into a Rust backend from Swift, or from whatever UI framework you use on Linux or Windows, is going to be just as easy as with Neon. At the moment, you are including vast amounts of code and using a large amount of memory to display a very small amount of text on-screen. It seems very inefficient for such an otherwise elegant application!
- miohtama 9y ago
  The cost of UI development is substantial; as you say "whatever" framework it means that you would need to learn 1) what frameworks are available 2) what paradigms they use 3) what programming languages and tools you need to know to drive them. As the development is mostly web driven nowadays, HTML/CSS/JavaScript is something that the most developers tend to already know and thus have crossed the first barriers of entry to this kind of development.
  - matthewmacleod 9y ago
    I have no doubt that native UI development for multiple platforms is tricker than a single cross-platform browser-based implementation. But I do think the level of those barriers to entry can be overstated. Building a simple MacOS GUI is not complex; likewise for Windows and say QT for Linux. It requires a little bit of thought and a little bit of research, and more time than a single implementation. The output is also better by quite a few metrics, and my general feeling is that an application where most of the complexity is hidden away in a cross platform library with a very simple API is the best possible case for this approach.
    - Aaargh20318 9y ago
      > I have no doubt that native UI development for multiple platforms is tricker than a single cross-platform browser-based implementation. I would argue the exact opposite is true for anything more complicated than 'hello world'
      - matthewmacleod 9y ago
        I can agree with that from the perspective of a single front-end. If I were building multiple front-ends for different platforms, I’m less sure. I do think that developers who have previously only worked with web tech have a distorted idea about native platforms though. I spent my whole career working on the web, intimidated by the complexity of native apps. It turned out that native UI toolkits really are very well suited to building native UIs with minimal effort!
        Aaargh20318 9y ago
        > I do think that developers who have previously only worked with web tech have a distorted idea about native platforms though. I spent my whole career working on the web, intimidated by the complexity of native apps. As a native developer I have the exact opposite view. Web development is insanely complicated compared to native. It's a complete jungle of flavour-of-the-day frameworks all designed to make web-development somewhat workable (and all of them failing in some ways. If you're building a website, you have little choice, but if you're actually building a desktop app it's totally insane to use web based UI.
        _Tev 9y ago
        Maybe you have distorted view as well.
        postfacto 9y ago
        > I do think that developers who have previously only worked with web tech have a distorted idea about native platforms though. There’s an irony that people who will drop whatever they’re doing to learn this week’s hot crazy brain-bending quasi-DSL JavaScript framework think that learning Swift is too hard and don’t want to have to learn something new.
  - Aaargh20318 9y ago
    > HTML/CSS/JavaScript is something that the most developers tend to already know If you know both HTML and a proper UI toolkit, you'll see how insane it is to use HTML for anything else than marking up text. It's like launching a space shuttle to go to the supermarket around the corner instead of just walking. The only thing HTML has got going for it is how easy it is to show 'Hello World' on screen. Anything more complicated than that and it becomes a total horror show, especially compared to how easy to use and simple regular UI toolkits are.
    - ctw 9y ago
      Which regular, simple UI toolkits do you recommend to a web developer who wants to learn desktop development? Do you also have a recommendation on which resources/approaches to use to learn those toolkits?
      - wander_homer 9y ago
        Obviously this depends on what you want to do. Most importantly: Which platforms do you want to target?
      - Aaargh20318 9y ago
        Use whatever is the native toolkit for the OS you're targeting.
      - CyberDildonics 9y ago
        Juce (GPL unless you pay for a license) FLTK Nanogui (simplistic GUI for openGL)
- cornholio 9y ago
  Because writing, testing and deploying on each of those platforms will increase your effort from X to N*X. I don't think Electron a good match for this project, which while fast during use, probably has horrendous startup times and memory usage. But I can certainly understand the sentiment pushing developers into Electron and driving them to avoid multiple native applications like the plague. I have developed and deployed custom Eclipse environments that supported Windows and Linux, with a mix of Java and C/C++. It costed me years out of my life.
  - matthewmacleod 9y ago
    It costs more to build native UIs, that’s true. But a project like this specifically seems to have most of the secret sauce implemented in a cross-platform library. That seems to be to be a great application structure and candidate for native UI implementation. It increases the development effort from n+m to 3n+m, where n is hopefully much smaller than m.
  - Aaargh20318 9y ago
    > Because writing, testing and deploying on each of those platforms will increase your effort from X to N*X. No, it won't. Building any non-trivial UI in HTML takes orders of magnitude more effort and time than building it in a UI toolkit that was actually designed to build user interfaces in.
    - Klathmon 9y ago
      That is absolutely false in my experience. I can put together a full HTML/CSS/JS UI for a screen in hours where it will take me days to do it on Android or iOS alone, ignoring the fact that I'd have to make sure it's responsive on all those platforms anyway (because tablets), then still build it for windows, linux, mac, and sometimes a web version anyway.
      - postfacto 9y ago
        A competant iOS or OS X developer can use Interface Builder to create great native UI’s in minutes.
- steveklabnik 9y ago
  That’s the approach Xi is taking, incidentally.
  - dualogy 9y ago
    What's Xi? Not the most websearch-able name, care to drop a url?
    - kiejo 9y ago
      https://github.com/google/xi-editor https://github.com/google/xi-editor
    - deleted 9y ago
      [deleted]
    - deleted 9y ago
      [deleted]
  - matthewmacleod 9y ago
    That’s a really interesting approach to take for an editor - I love the idea!
- deleted 9y ago
  [deleted]
- hacker_9 9y ago
  It's a valid point, simply because browser UI kits are outdated, memory hogs, and have a ton of legacy cruft. I've recently been using Windows Forms with C# again and am amazed at the ease of use, if only they had made styling easy this framework would have been a gold standard for years to come. It's even cross platform too thanks to Mono.
  - Const-me 9y ago
    Windows forms is based on decides old WinApi. There's some support for styling there, e.g. owner drawn items, custom painted controls, but using it correctly is tricky as hell. WPF is based on Direct3D 9, and is easily stylable. I consider it is the gold standard. But it is Windows only. There are cross platform alternatives, xamarin, avalonia, but I don't have hands on experience with them.
  - seabrookmx 9y ago
    > would have been the gold standard for years to come I've written a lot of webforms and do really like it for "quick and dirty" UI's, but it has a lot of limitations that make it a bad choice for non-trivial apps. Off the top of my head: -styling -resizing (text reflow and re-layout of items is very hard to get right/working) -screen scaling (non-integer, say 150%) I also found it requires a ton of boilerplate code to programmatically change the UI. That said, my favourite part is the first class support for events. Knowing this paradigm made my shift to Qt (which has something similar called signals) much easier.
- pas 9y ago
  Maybe you have missed the part about the laughably hostile native APIs. No hotkey support, no easy windowing (or lack of thereof).
  - matthewmacleod 9y ago
    I didn't, but I'm wondering if you maybe misunderstood it – that was specifically about implementing the app in what the author describes as a 'game-like' manner, using an SDL library from Rust. In contrast, platform-native UI frameworks are absolutely optimised for things like this. There's definitely no difficulty in using hotkeys or windowing functions in Appkit, for example.
- pornel 9y ago
  > but why not make the UI native for each platform? As a developer I prefer web tech for UIs, because it's actually a nice toolkit to work with, and has great tooling. I can easily debug and live edit the UI with DevTools. OTOH in Xcode's constraint-based layout I struggle to even move buttons around (if I fail to update all constraints right, the whole layout collapses). On Windows I don't even know which of the many UI frameworks is the least deprecated this year.
  - matthewmacleod 9y ago
    I can understand that, and certainly the web platform is much nicer than it used to be – especially when building for a constrained, known environment like Electron. Don't discount the native platforms though, which are still very powerful. Constraint-based layout can be frustrating at first, but I've found it's not noticeably more awkward than CSS after a little experience. Similarly, it's no worse figuring out how to build a native Windows GUI than it is figuring out what CSS or JS framework to use. Just a bit of research :)
  - ken 9y ago
    > I struggle to even move buttons around (if I fail to update all constraints right, the whole layout collapses) I would say that accurately describes my experience with CSS. Any selector has the potential to mess up the entire page. With NSLayoutConstraints, not only does it match my mental model of how layout ought to work, but I know that in a properly-factored layout, constraints can only mess up their local section. Globals make debugging tough in any context, and I wouldn't blame the language simply for allowing their use.
    - jakelazaroff 9y ago
      > Any selector has the potential to mess up the entire page. That's true, but the modern web stack has several solutions to this. If you don't mind "CSS-in-JS", I've been using the excellent styled-components [1] library for my company's React app. I believe Vuejs supports scoped styles out of the box [2]. And if you'd prefer to just write plain CSS, CSS modules [3] will mangle the classnames in your CSS files so you don't have to worry about collision. [1] https://www.styled-components.com/ https://www.styled-components.com/ [2] https://vue-loader.vuejs.org/en/features/scoped-css.html https://vue-loader.vuejs.org/en/features/scoped-css.html [3] https://github.com/css-modules/css-modules https://github.com/css-modules/css-modules
- amarsahinovic 9y ago
  Some might find this interesting for native cross-platform apps http://www.lazarus-ide.org/ http://www.lazarus-ide.org/
hardwaresofton 9y ago
I wonder how this approach will combine/contrast with compiling rust to wasm directly -- I'm under the impression that the benefits would be similar. I absolutely believe building electron apps is the future -- why would you struggle with the M*N effort of building different UIs when you can get comfortable with a paradigm that you already know that works relatively predictably across OSes and is constantly being improved (HTML+CSS). Unfortunately, one of the big problems left to get tackled (I think?) is the lack of native system accessiblity features that are more advanced than what the web can/does offer. So excited to see this idea getting attention -- I really want to work on a cross-platform app with neon + rust in the future, and see if we can finally get past the gripe of memory usage for electron apps so that people can stop bashing them.
- lynaghk 9y ago
  Author here. I'm compiling Rust to WASM on another project, so I can address this question. I haven't studied relative perf, so can't make any claims there. But for this application your guess is correct: It's iterop. It's easier to go with Rust via Neon rather than WASM because Finda needs to: + Walk the filesystem for file results + Call OS X CoreGraphics APIs to list windows + Run a websocket server to collect results from browsers and VSCode All of this requires leaving the browser sandbox, and so can't be done in WASM.
LeoNatan25 9y ago
Just to show how well this works, the attached GIF on that site uses OS X Mavericks, now 5 years old. I also like how they only considered one real alternative, which is "XCode" (incorrectly capitalized). What about Xamarin / Mono? What about qt? With those, they don't even need to upgrade their outdated OS. Instead, they chose the worst of all worlds, both development and user. The state of development in 2018 is ridiculous.
- kiriakasis 9y ago
  It is written in the article that the author had experiences with electron. > they chose the worst of all worlds, both development and user. to me this looks needlessly inflammatory, the whole point of the post is "hey, electron has a bad name for both lags and high memory and CPU usage, but with rust i was able to get its benefits without its common drawbacks". If you think this is so ridiculous i think some more explanations are needed.
- cheez 9y ago
  Yeah... Qt/QML would have been a better idea here IMO. Performance, memory, size, etc.
alfonsodev 9y ago
> The architectural tl;dr is that Electron is used as a user interface layer, with a Rust binary handling everything else. Interesting, but the major complaint about electron that usually pops in HN is about memory consumption. Is it that avoided in this case?
- tarruda 9y ago
  If the app uses no Javascript UI frameworks, and completely maintains all UI/DOM state in Rust code, it might be possible to significantly reduce memory usage when compared to typical Javascript apps. Keep in mind that "electron-quick-start" (basically an empty Electron app) uses 40 MiB on Linux, so anything with a slightly complex UI would probably not use less than 50 MiB, regardless of the "backend language".
  - AnIdiotOnTheNet 9y ago
    To put this in perspective, all of Windows 95 fit in about 50MiB on disk and ran in something like 8MB.
krzat 9y ago
I've been playing with Flutter recently and their approach may dominate UI toolkits in the future. They took low level rendering API from Chrome (Skia) and build simple but fast layout engine around that. Already works pretty well on mobile and there are some experiments on desktops: https://github.com/rxlabz/flutter_desktop_markdown_reader https://github.com/rxlabz/flutter_desktop_markdown_reader Rust people could maybe do the same with Webrender from servo.
- hardwaresofton 9y ago
  The only downside to Flutter is the immense amount of effort to bootstrap an approach like that. I think it made sense for Google since they have the resources and free engineers to throw at the problem, but for more resource-constrained project I'm not sure it's tenable. Nevermind the fact that the ongoing maintenance burden is also a thing -- using iOS7 UI elements on iOS9 is probably a non-starter for a large part of the audience.
  - k__ 9y ago
    AFAIK they did it because when they started there weren't any viable alternatives. Today they would probably invest their time in React-Native or something.
- mnem 9y ago
  The downside of custom rendering engines is that they’re rarely as efficient as the standard platform affair. While that’s less impactful on desktop, it can be a killer for batteries on mobile devices and laptops.
  - Const-me 9y ago
    Standard platforms on desktops are decades old and therefore render stuff on CPU. Theoretically, a GPU-centric custom engine can be much more power efficient.
  - pcwalton 9y ago
    That's not true. There's no magic sauce that the platform vector graphics library has: it's a userspace library like any other (well, except for GDI, but nobody wants to use that anymore). It's absolutely possible to improve upon it.
holydude 9y ago
The other problem is that most electron apps are incredibly big. I do not want to download 150mb single purpose apps. The memory hog is not the only it's also the battery drain most electron apps suffer from. If you compare Finda to something like voidtool's Everything it's night and day.
- KeitIG 9y ago
  I don’t understand the size argument. Disk space is super cheap today. Facebook’s Android app is 350MB and not a lot of people really care, on Desktop, 150MB is nothing. Plus it satisfies the “all libs/dependencies in one app”, which is exactly what macOS’s .app, Linux’s Snaps and AppImage, or more generally all Android/iPhone apps are doing. I agree with the RAM/power things too, but these issues come from web pages in general, not Electron itself.
  - petecox 9y ago
    If anyone seeks an alternative to Facebook's app, there's Face Slim from the f-droid repository: https://f-droid.org/en/packages/org.indywidualni.fblite/ https://f-droid.org/en/packages/org.indywidualni.fblite/ 1.3 MiB
  - LeoNatan25 9y ago
    A clean "hello world" Electron excrement takes 200+ MB in RAM. How is that an "issue from web pages" exactly?
    - tarruda 9y ago
      Where did you get this information? I just tested "electron-quick-start" on Linux and all 3 processes use 40 MiB together
      - wander_homer 9y ago
        Here on my systems (Ubuntu, Gentoo) electron-quick-start leads to ~90 MB more memory usage and it spawns 4 processes which use 110MB, 74MB, 74MB and 44MB of resident memory. So obviously quite some memory is shared between those and probably other processes on my system, but nevertheless the resulting memory consumption is far above 40 MB.
tybit 9y ago
I noticed the atom team are trying something similar with an experiment called X-ray https://github.com/atom/xray https://github.com/atom/xray It will be nice if this becomes a thing, I think it’s more likely that electron apps become significantly more performant than that everyone starts rewriting their apps in QT, for better or worse.
- tonyedgecombe 9y ago
  POC?
  - tybit 9y ago
    Edited to be clearer, thanks.
  - Mononokay 9y ago
    I'd imagine "Proof of Concept."
framel 9y ago
electron is cancer
- joefarish 9y ago
  What are your issues with Electron?
- dang 9y ago
  Please don't do this here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
minus7 9y ago
Is it really so hard to write a native GUI for three OSes if you must?
- hollerith 9y ago
  or 2 OSes if 98% of the potential desktop / laptop market will suffice and your product is not aimed at developers.
- allover 9y ago
  > Is it really so hard to write a native GUI for three OSes if you must? Yes. What makes you think otherwise?
  - matthewmacleod 9y ago
    I think this is often the perception - and I understand why, because I shared it for a very long time - but I don’t think it’s true. Building a simple UI for multiple platforms may be somewhat more time consuming than a single cross-platform Electron implementation. This will scale with the complexity of the UI. This particular application has about the simplest UI imaginable. Consume some keystrokes, render some rows of text. Implementing this is any native UI platform will not be hard - but it will reduce the memory footprint, rendering time, and application bundle size. Native UI frameworks are actually really good at rendering simple applications on their platforms. There’s usually plenty of documentation and good development tools. Building an application using one of them is definitely different from web tech - but I don’t think it qualifies as hard. And I reckon it would be useful for more of us to experience as many different platforms as possible - it’s a great way to learn!
    - postfacto 9y ago
      The native platforms backed by real money also have lots of official documentation, real GUI builders, high quality debuggers built into their IDE’s and one cardinal way/library to do something. The importance of all this stuff in speeding up things can’t be overstated.
  - 9y ago
jayflux 9y ago
> Given this goal, you might be surprised to learn that Finda is built with Electron, a framework that’s often decried for being the opposite of fast. I thought the criticism was more about its memory usage, not that it wasn’t fast.
- tluyben2 9y ago
  Most applications I have tried feel slow as well; especially when running for a while.
  - sebazzz 9y ago
    That might be caused by GC, which is ultimately caused by memory usage and the runtime attempting to reduce that.
- JepZ 9y ago
  In fact, there are many downsides performance wise when you think about electron: - it is as slow as any other web rendering engine - it uses as much memory as any other browser - you have huge binaries The key benefit of electron is that you can easily build cross-platform apps which run on every notable platform. Many of the general weaknesses of electron can be eliminated by building a Progressive Web App, but that doesn't solve the performance challenges that come with building a web app. Performance wise web apps are very slow when compared to C/C++/Rust/Go. E.g. for a C program, a single millisecond itself is a long time. For web-apps you struggle to get everything in a 16ms window to not break your 60fps experience. But the point is that while web apps are in fact much slower, they can be fast enough. And if you have a technology that is very platform independent and you can built good experiences with it, then you probably find some nice use-cases.
  - afranchuk 9y ago
    >The key benefit of electron is that you can easily build cross-platform apps which run on every notable platform. I've been a bit confused about the draw of this feature. I understand that there are a lot of JavaScript developers out there, and things like Electron allow them to use their JavaScript knowledge to make applications on many platforms. But there are now a large number of GUI libraries (GUI being a typical obstacle for cross-platform support) that can target all these platforms (and sometimes more) as well. GTK+, Qt, and WxWidgets name a few. And they have bindings across many languages! Of course, to make something that's completely custom-looking using these libraries may be more of a hassle than an html/css document. Maybe Electron's popularity _is_ primarily driven simply by the high numbers of JavaScript programmers out there. I guess it's like you pointed out: if you can get it to be fast _enough_, it's acceptable. Kind of similar to interpreted vs compiled languages.
tixocloud 9y ago
Thanks for sharing this. I’ve been dabbling with Electron to build a data analysis tool app but have been slightly concerned about speed. I am glad to hear how quick it’s running for you and getting ideas on how I can make my app faster. Thanks!
Humphrey 9y ago
I wonder if there is a use-case for a simplified lightweight edition of Electron that uses the system webviews instead of Chromium. Obviously this would be much less capable, require cross platform testing, and limit node usage. But for a project like this that barely does anything fancy in the front-end, it would solve the size and memory issues.
- LeoNatan25 9y ago
  Taking a WebKit2 webview should give you enough benefit. But for some reason they chose Chrome.
- roryisok 9y ago
  I've often wondered this. You could write a set of generic webview based apps (say, Windows 10 and MacOS to start) and a small js library that would allow cross platform access to low level apis, even just a few at first like file dialogs. React native is sort of like this.
dreta 9y ago
You can't seriously justify introducing massive library into your code just to display some text, and use a few native calls. If it works for you, that's great, but if anybody needs an example of why the software you use is so terrible these days, even though we had huge leaps in technology, look no further.
- tarruda 9y ago
  If all this app does is display text, it would have been simpler to embed a rich terminal emulator widget and implement the backend as a Rust program with terminal UI
  - derimagia 9y ago
    It has a GUI...
snarfy 9y ago
Whenever I find myself wanting to build an app that is electron/chromium/webkit frontend + C++/C#/Rust/Go backend I can never justify it over building a web app + web api instead. If you want to run it locally there is a one line docker command to do it.
- filleduchaos 9y ago
  Sometimes I wonder if people on this site realize that there is such a thing as an end user.
- roryisok 9y ago
  Doesn't the user need to have docker installed to run that one line? That's kind of a big prerequisite
  - snarfy 9y ago
    Since it's a web app, they could go to my hosted site if they can't install it locally. That wouldn't work for the OPs app but it would work for most. The point being there has to be a better way than frankensteining the browser.
    - roryisok 9y ago
      It depends on what you consider "better". I'd much rather install an electron app than mount and run a docker container, and I say that as a developer who uses docker every single day.
cheez 9y ago
> 1) I want the option to port Finda to Windows and (I can’t believe I’m saying this) Linux, since beta testers asked if they could buy a version for their respective platforms. Anyone else reading this: Linux support is required for any tech-related thing. Many times I have sold licenses into a single person using Linux who then has their company come back to buy 10s or 100s of licenses.
- AnIdiotOnTheNet 9y ago
  > Anyone else reading this: Linux support is required for any tech-related thing. Which is why pretty much everywhere I've ever worked has run off a combination of Exchange, Office, Sharepoint, Windows file servers, and a plethora of legacy Windows-only crapware. If you work with nothing but webdevs all day though, I could see how you'd get the impression that Linux support for GUI apps is something anyone cares about.
charlieflowers 9y ago
I thought this was intriguing, so I installed it. Doesn't work at all for me. Running finda shows the instruction screen. Try to use it by typing, and the window goes completely white. I can use ctrl-\ to bring the white window up and down, but nothing else works. I had to find the launchd process in Activity Monitor to kill it so I could uninstall.
- omnimus 9y ago
  Exactly same experience. Probably because author (he even mentions it in the post) has outdated OSX and there is probably some difference between versions there.
- superasn 9y ago
  I though the whole reason people created Electron apps is because they can run on any platform. This one just runs on MacOS only so I can't even download it :/
- lynaghk 9y ago
  Author here. Sorry that it's giving you a hard time. Can you say what OS X version you're running or provide any other details so I can try and reproduce/fix? (You can email me privately at finda@keminglabs.com) I tested with a dozen folks before releasing and this issue never came up.
  - lynaghk 9y ago
    Haven't heard from OP, but another person emailed me and the issue is likely because Finda relies on AVX2 CPU instructions for fast search. These instructions were introduced in 2012, so it's likely the OP was running on older hardware. I'll add CPU detection to a future version of Finda so that it can fallback to slower, non-vectorized instructions.
pughmans 9y ago
I hate javascript so this might be good.
BlackLotus89 9y ago
Interesting that nobody seems to talk about the software itself and maybe it's alternatives. I for once welcome the concept of something like Finda and am looking for alternatives for me. > Finda finds things — windows, browser tabs, code editor buffers, browser history, apps, files, etc. Finda looks and acts like a normal launcher. The concept isn't new, but fast good launchers are rare. When we look at the Finda-Page (I didn't download the demo since I don't use Mac OS) we can conjecture how it works and there are a few things that bother me. It seems to always run in the background and listen for inputs. It's cross platform so it will probably have it's own file indexer. This all seems to add up to a rather large memory consumption. Anyway right now I'm still using the dmenu [1] launcher and am looking at many alternatives, most of which haven't been updated in some time. First the ones that haven't been updated in some time dmenu2 [2], interrobang [3], and lighthouse [4]. All nice launcher, but here comes my current favourite rofi [5]. Not only is it an active project, but it defines itself as window switcher and launcher (so what finda kinda does). Combined with it's extendable nature it seems to be a solid launcher. Bookmark functionality is for instance given with the buku [6] integration. But I'm still looking for the best solution. Here is the feature list I'm looking for: program launcher, simple calculator (through bc or python), file locator (maybe through locate), bookmark manager (firefox preferably). Other things like quick (online) search, clipboard management or the whole slew of other features provided Finda and panther and whatnot would just be extra. Does anyone of you have a nice lightweight solution? [1] https://github.com/stilvoid/dmenu https://github.com/stilvoid/dmenu [2] https://github.com/muff1nman/dmenu2 https://github.com/muff1nman/dmenu2 [3] https://github.com/TrilbyWhite/interrobang https://github.com/TrilbyWhite/interrobang [4] https://github.com/emgram769/lighthouse https://github.com/emgram769/lighthouse [5] https://github.com/DaveDavenport/rofi https://github.com/DaveDavenport/rofi [6] https://github.com/jarun/Buku/ https://github.com/jarun/Buku/ - bl
- lynaghk 9y ago
  Author here, and happy that you're interested in the software itself rather than the implementation =) I'll probably write a detailed post about file indexing, since it's pretty interesting from a technical standpoint. I looked into spotlight (via `mdfind`) but it was too slow and I wanted to port to Windows/Linux later, so your speculation is correct: Finda has its own file walking and indexing mechanism. It walks a user-configurable set of directories, but not in the background --- it's actually done every time you open Finda, so you only pay the CPU cost when you are actually using the program. The index is stored in memory, and size is proportional to the number of files/folders walked. However, Finda does respect .gitignore files, so you can exclude things you don't want to show up in the search results (or consume memory).
actf 9y ago
I really like where the author went with this. Everytime I read something like this though I can't help but think how we as developers really need a better low level, UI framework for cross platform applications. What the author has done here is a cool idea, but ultimately this still feels flawed, and like it's a workaround to the difficulties of writing a cross platform UI. Everytime I read something like this I can't help but think about how great a low level, cross platform C (or C ABI) library would be (think something like libuv but for UIs). Such a library would abstract away the OS specific system calls of the UI while still providing the ability to easily do things like: * Create a window * Draw to the screen * Declaratively (i.e. html like) add UI widgets to a scene * Apply CSS like styling (like QML, JavaFX, or XAML) * Use native file dialogs, menus, notifications, etc * Statically link as a single dependency I don't even think something like this necessarily needs to provide native UI elements, rather it just needs to be a more performant, easier to use, smaller, version of electron that could easily be used from any language. It needs to provide common UI elements like buttons, textboxes, divs, grid layouts, etc, but judging by the popularity of electron - I don't think those necessarily need to use native elements. Qt is close to this, but it feels heavyweight and in my opinion its biggest flaw is that it's difficult to link to an application and setup a development environment for. Tk is kind of like this, but way too limited. JavaFX is a really good example, and would be perfect if it wasn't Java only (same with WPF but it's C# only). Right now the closest attempt to something like this that I know of is https://github.com/andlabs/libui https://github.com/andlabs/libui I think libui could even be a starting point for such a library, but the library I'm thinking of would need some type of declarative UI support (i.e. html like, maybe even support for a subset of html), built in support for styling, and less of a focus on using native widgets. I really wish somebody would build something like this.
- mherrmann 9y ago
  > Qt's [...] biggest flaw is that it's difficult to link to an application and setup a development environment for. Check out (my) https://github.com/mherrmann/fbs https://github.com/mherrmann/fbs. It's for PyQt but I think does get around the obstacle you mention.
- arel 9y ago
  There is a point that is always missed about Electron - UI. By using HTML, CSS & JS you have an extremely rich toolkit to create UI with constant improvements from browser vendors and standards bodies. If a designer can create a pattern library in sketch then chances are it can be implemented using web technologies. This is a much bigger and more active open platform when contrasted to the capabilities of a particular framework and community. Theres another topic around whether you should detour from the OS UI look and feel. But most designers and product owners worth their salt are conscious of keeping known UX patterns and least surprise.
swsieber 9y ago
OK. Dream time. I'd love to build a cross platform app / ui toolkit with support for pluggable backends. The first two would probably ncurses and electron if I were building it. (I'd do it rust for its excellent Web assembly story and perfeomance.)
- roryisok 9y ago
  You have my permission, fire away
angel_j 9y ago
what is require('Native')?
tzahola 9y ago
Cool! Still waiting for “building an electron app that uses less than 200 mbyte of RAM” though.
lynaghk 9y ago
Author here. For more background on product development about Finda, there are notes on my personal website here: https://kevinlynagh.com/datatron/ https://kevinlynagh.com/datatron/ I started this as a UI research project to try and replace OS X Finder with a keyboard-only UI. A strong inspiration was the Helm Emacs package. My initial prototype was in ClojureScript/Electron, and I was exploring far more features like inline preview, and a command/argument (verb/noun?) builder system. However, after showing my prototype to a few friends, they were all much more interested in the fast search and window switching capabilities, so I decided to cut scope, focus the project on those features, and get something out the door. This is my first Rust project, and I've been thrilled with the language and that community in terms of great libraries, documentation, and their willingness to help beginners like myself. p.s. Sorry I'm late to the party, I pushed this blog post online immediately before going to sleep for the night =P
- vkjv 9y ago
  Just wanted to say "hi" and that this is a great read! If you are interested, there is a Neon slack where some of us hang out. For example, you might be interested in neon-serde which could clean-up some of the argument parsing and match logic. https://crates.io/crates/neon-serde https://crates.io/crates/neon-serde
tracker1 9y ago
I think it's wild that the browser has become the UI layer in so many applications... CSS + HTML simply make things more consistent in a way that no other toolkit ever has. On the flip side, it's sad that every app now packages the entire jungle (so to speak). I know that this is what Adobe Air was supposed to be, and part of me would love to see something akin to Chrome's autoupdate mechanisms for an Air-like platform around Electron's base that could be shared. That doesn't get around performance issues, but would at least mean some reduction. I think it's a great option to have, but still concerning in some ways. I also think that React-Native will probably grow to be easier to create more native-like cross platform apps over time. Definitely interesting times.
mamcx 9y ago
This is only possible because the browser on desktops is "fast". I try the same idea with Android/iOS. In iOS, all fly, but man... android is super-slow. I can't believe it myself, so I downloaded several demos of html-based apps and the results hold. I totally will kill for a webview-like control on android that I could reliable use and be almost 80% as fast as on iOS.. Now I implementing the UI on both, and seriously is harder than I expected... Never imagine the Apis were that bad...

248 points by hellerve 9y ago

I think it’s cool that people are playing around with this sort of thing. The truth is, though, I don’t understand why this architecture is attractive in this case. This is essentially a thin front-end UI on top of a fast cross-platform backend. That’s a great structure - but why not make the UI native for each platform? Calling into a Rust backend from Swift, or from whatever UI framework you use on Linux or Windows, is going to be just as easy as with Neon. At the moment, you are including vast amounts of code and using a large amount of memory to display a very small amount of text on-screen. It seems very inefficient for such an otherwise elegant application!

miohtama 9y ago
The cost of UI development is substantial; as you say "whatever" framework it means that you would need to learn 1) what frameworks are available 2) what paradigms they use 3) what programming languages and tools you need to know to drive them. As the development is mostly web driven nowadays, HTML/CSS/JavaScript is something that the most developers tend to already know and thus have crossed the first barriers of entry to this kind of development.
- matthewmacleod 9y ago
  I have no doubt that native UI development for multiple platforms is tricker than a single cross-platform browser-based implementation. But I do think the level of those barriers to entry can be overstated. Building a simple MacOS GUI is not complex; likewise for Windows and say QT for Linux. It requires a little bit of thought and a little bit of research, and more time than a single implementation. The output is also better by quite a few metrics, and my general feeling is that an application where most of the complexity is hidden away in a cross platform library with a very simple API is the best possible case for this approach.
  - Aaargh20318 9y ago
    > I have no doubt that native UI development for multiple platforms is tricker than a single cross-platform browser-based implementation. I would argue the exact opposite is true for anything more complicated than 'hello world'
    - matthewmacleod 9y ago
      I can agree with that from the perspective of a single front-end. If I were building multiple front-ends for different platforms, I’m less sure. I do think that developers who have previously only worked with web tech have a distorted idea about native platforms though. I spent my whole career working on the web, intimidated by the complexity of native apps. It turned out that native UI toolkits really are very well suited to building native UIs with minimal effort!
      - Aaargh20318 9y ago
        > I do think that developers who have previously only worked with web tech have a distorted idea about native platforms though. I spent my whole career working on the web, intimidated by the complexity of native apps. As a native developer I have the exact opposite view. Web development is insanely complicated compared to native. It's a complete jungle of flavour-of-the-day frameworks all designed to make web-development somewhat workable (and all of them failing in some ways. If you're building a website, you have little choice, but if you're actually building a desktop app it's totally insane to use web based UI.
        _Tev 9y ago
        Maybe you have distorted view as well.
      - postfacto 9y ago
        > I do think that developers who have previously only worked with web tech have a distorted idea about native platforms though. There’s an irony that people who will drop whatever they’re doing to learn this week’s hot crazy brain-bending quasi-DSL JavaScript framework think that learning Swift is too hard and don’t want to have to learn something new.
- Aaargh20318 9y ago
  > HTML/CSS/JavaScript is something that the most developers tend to already know If you know both HTML and a proper UI toolkit, you'll see how insane it is to use HTML for anything else than marking up text. It's like launching a space shuttle to go to the supermarket around the corner instead of just walking. The only thing HTML has got going for it is how easy it is to show 'Hello World' on screen. Anything more complicated than that and it becomes a total horror show, especially compared to how easy to use and simple regular UI toolkits are.
  - ctw 9y ago
    Which regular, simple UI toolkits do you recommend to a web developer who wants to learn desktop development? Do you also have a recommendation on which resources/approaches to use to learn those toolkits?
    - wander_homer 9y ago
      Obviously this depends on what you want to do. Most importantly: Which platforms do you want to target?
    - Aaargh20318 9y ago
      Use whatever is the native toolkit for the OS you're targeting.
    - CyberDildonics 9y ago
      Juce (GPL unless you pay for a license) FLTK Nanogui (simplistic GUI for openGL)
cornholio 9y ago
Because writing, testing and deploying on each of those platforms will increase your effort from X to N*X. I don't think Electron a good match for this project, which while fast during use, probably has horrendous startup times and memory usage. But I can certainly understand the sentiment pushing developers into Electron and driving them to avoid multiple native applications like the plague. I have developed and deployed custom Eclipse environments that supported Windows and Linux, with a mix of Java and C/C++. It costed me years out of my life.
- matthewmacleod 9y ago
  It costs more to build native UIs, that’s true. But a project like this specifically seems to have most of the secret sauce implemented in a cross-platform library. That seems to be to be a great application structure and candidate for native UI implementation. It increases the development effort from n+m to 3n+m, where n is hopefully much smaller than m.
- Aaargh20318 9y ago
  > Because writing, testing and deploying on each of those platforms will increase your effort from X to N*X. No, it won't. Building any non-trivial UI in HTML takes orders of magnitude more effort and time than building it in a UI toolkit that was actually designed to build user interfaces in.
  - Klathmon 9y ago
    That is absolutely false in my experience. I can put together a full HTML/CSS/JS UI for a screen in hours where it will take me days to do it on Android or iOS alone, ignoring the fact that I'd have to make sure it's responsive on all those platforms anyway (because tablets), then still build it for windows, linux, mac, and sometimes a web version anyway.
    - postfacto 9y ago
      A competant iOS or OS X developer can use Interface Builder to create great native UI’s in minutes.
steveklabnik 9y ago
That’s the approach Xi is taking, incidentally.
- dualogy 9y ago
  What's Xi? Not the most websearch-able name, care to drop a url?
  - kiejo 9y ago
    https://github.com/google/xi-editor https://github.com/google/xi-editor
  - deleted 9y ago
    [deleted]
  - deleted 9y ago
    [deleted]
- matthewmacleod 9y ago
  That’s a really interesting approach to take for an editor - I love the idea!
deleted 9y ago
[deleted]
hacker_9 9y ago
It's a valid point, simply because browser UI kits are outdated, memory hogs, and have a ton of legacy cruft. I've recently been using Windows Forms with C# again and am amazed at the ease of use, if only they had made styling easy this framework would have been a gold standard for years to come. It's even cross platform too thanks to Mono.
- Const-me 9y ago
  Windows forms is based on decides old WinApi. There's some support for styling there, e.g. owner drawn items, custom painted controls, but using it correctly is tricky as hell. WPF is based on Direct3D 9, and is easily stylable. I consider it is the gold standard. But it is Windows only. There are cross platform alternatives, xamarin, avalonia, but I don't have hands on experience with them.
- seabrookmx 9y ago
  > would have been the gold standard for years to come I've written a lot of webforms and do really like it for "quick and dirty" UI's, but it has a lot of limitations that make it a bad choice for non-trivial apps. Off the top of my head: -styling -resizing (text reflow and re-layout of items is very hard to get right/working) -screen scaling (non-integer, say 150%) I also found it requires a ton of boilerplate code to programmatically change the UI. That said, my favourite part is the first class support for events. Knowing this paradigm made my shift to Qt (which has something similar called signals) much easier.
pas 9y ago
Maybe you have missed the part about the laughably hostile native APIs. No hotkey support, no easy windowing (or lack of thereof).
- matthewmacleod 9y ago
  I didn't, but I'm wondering if you maybe misunderstood it – that was specifically about implementing the app in what the author describes as a 'game-like' manner, using an SDL library from Rust. In contrast, platform-native UI frameworks are absolutely optimised for things like this. There's definitely no difficulty in using hotkeys or windowing functions in Appkit, for example.
pornel 9y ago
> but why not make the UI native for each platform? As a developer I prefer web tech for UIs, because it's actually a nice toolkit to work with, and has great tooling. I can easily debug and live edit the UI with DevTools. OTOH in Xcode's constraint-based layout I struggle to even move buttons around (if I fail to update all constraints right, the whole layout collapses). On Windows I don't even know which of the many UI frameworks is the least deprecated this year.
- matthewmacleod 9y ago
  I can understand that, and certainly the web platform is much nicer than it used to be – especially when building for a constrained, known environment like Electron. Don't discount the native platforms though, which are still very powerful. Constraint-based layout can be frustrating at first, but I've found it's not noticeably more awkward than CSS after a little experience. Similarly, it's no worse figuring out how to build a native Windows GUI than it is figuring out what CSS or JS framework to use. Just a bit of research :)
- ken 9y ago
  > I struggle to even move buttons around (if I fail to update all constraints right, the whole layout collapses) I would say that accurately describes my experience with CSS. Any selector has the potential to mess up the entire page. With NSLayoutConstraints, not only does it match my mental model of how layout ought to work, but I know that in a properly-factored layout, constraints can only mess up their local section. Globals make debugging tough in any context, and I wouldn't blame the language simply for allowing their use.
  - jakelazaroff 9y ago
    > Any selector has the potential to mess up the entire page. That's true, but the modern web stack has several solutions to this. If you don't mind "CSS-in-JS", I've been using the excellent styled-components [1] library for my company's React app. I believe Vuejs supports scoped styles out of the box [2]. And if you'd prefer to just write plain CSS, CSS modules [3] will mangle the classnames in your CSS files so you don't have to worry about collision. [1] https://www.styled-components.com/ https://www.styled-components.com/ [2] https://vue-loader.vuejs.org/en/features/scoped-css.html https://vue-loader.vuejs.org/en/features/scoped-css.html [3] https://github.com/css-modules/css-modules https://github.com/css-modules/css-modules
amarsahinovic 9y ago
Some might find this interesting for native cross-platform apps http://www.lazarus-ide.org/ http://www.lazarus-ide.org/

hardwaresofton 9y ago

I wonder how this approach will combine/contrast with compiling rust to wasm directly -- I'm under the impression that the benefits would be similar. I absolutely believe building electron apps is the future -- why would you struggle with the M*N effort of building different UIs when you can get comfortable with a paradigm that you already know that works relatively predictably across OSes and is constantly being improved (HTML+CSS). Unfortunately, one of the big problems left to get tackled (I think?) is the lack of native system accessiblity features that are more advanced than what the web can/does offer. So excited to see this idea getting attention -- I really want to work on a cross-platform app with neon + rust in the future, and see if we can finally get past the gripe of memory usage for electron apps so that people can stop bashing them.

lynaghk 9y ago
Author here. I'm compiling Rust to WASM on another project, so I can address this question. I haven't studied relative perf, so can't make any claims there. But for this application your guess is correct: It's iterop. It's easier to go with Rust via Neon rather than WASM because Finda needs to: + Walk the filesystem for file results + Call OS X CoreGraphics APIs to list windows + Run a websocket server to collect results from browsers and VSCode All of this requires leaving the browser sandbox, and so can't be done in WASM.

LeoNatan25 9y ago

Just to show how well this works, the attached GIF on that site uses OS X Mavericks, now 5 years old. I also like how they only considered one real alternative, which is "XCode" (incorrectly capitalized). What about Xamarin / Mono? What about qt? With those, they don't even need to upgrade their outdated OS. Instead, they chose the worst of all worlds, both development and user. The state of development in 2018 is ridiculous.

kiriakasis 9y ago
It is written in the article that the author had experiences with electron. > they chose the worst of all worlds, both development and user. to me this looks needlessly inflammatory, the whole point of the post is "hey, electron has a bad name for both lags and high memory and CPU usage, but with rust i was able to get its benefits without its common drawbacks". If you think this is so ridiculous i think some more explanations are needed.
cheez 9y ago
Yeah... Qt/QML would have been a better idea here IMO. Performance, memory, size, etc.

alfonsodev 9y ago

> The architectural tl;dr is that Electron is used as a user interface layer, with a Rust binary handling everything else. Interesting, but the major complaint about electron that usually pops in HN is about memory consumption. Is it that avoided in this case?

tarruda 9y ago
If the app uses no Javascript UI frameworks, and completely maintains all UI/DOM state in Rust code, it might be possible to significantly reduce memory usage when compared to typical Javascript apps. Keep in mind that "electron-quick-start" (basically an empty Electron app) uses 40 MiB on Linux, so anything with a slightly complex UI would probably not use less than 50 MiB, regardless of the "backend language".
- AnIdiotOnTheNet 9y ago
  To put this in perspective, all of Windows 95 fit in about 50MiB on disk and ran in something like 8MB.

krzat 9y ago

I've been playing with Flutter recently and their approach may dominate UI toolkits in the future. They took low level rendering API from Chrome (Skia) and build simple but fast layout engine around that. Already works pretty well on mobile and there are some experiments on desktops: https://github.com/rxlabz/flutter_desktop_markdown_reader https://github.com/rxlabz/flutter_desktop_markdown_reader Rust people could maybe do the same with Webrender from servo.

hardwaresofton 9y ago
The only downside to Flutter is the immense amount of effort to bootstrap an approach like that. I think it made sense for Google since they have the resources and free engineers to throw at the problem, but for more resource-constrained project I'm not sure it's tenable. Nevermind the fact that the ongoing maintenance burden is also a thing -- using iOS7 UI elements on iOS9 is probably a non-starter for a large part of the audience.
- k__ 9y ago
  AFAIK they did it because when they started there weren't any viable alternatives. Today they would probably invest their time in React-Native or something.
mnem 9y ago
The downside of custom rendering engines is that they’re rarely as efficient as the standard platform affair. While that’s less impactful on desktop, it can be a killer for batteries on mobile devices and laptops.
- Const-me 9y ago
  Standard platforms on desktops are decades old and therefore render stuff on CPU. Theoretically, a GPU-centric custom engine can be much more power efficient.
- pcwalton 9y ago
  That's not true. There's no magic sauce that the platform vector graphics library has: it's a userspace library like any other (well, except for GDI, but nobody wants to use that anymore). It's absolutely possible to improve upon it.

holydude 9y ago

The other problem is that most electron apps are incredibly big. I do not want to download 150mb single purpose apps. The memory hog is not the only it's also the battery drain most electron apps suffer from. If you compare Finda to something like voidtool's Everything it's night and day.

KeitIG 9y ago
I don’t understand the size argument. Disk space is super cheap today. Facebook’s Android app is 350MB and not a lot of people really care, on Desktop, 150MB is nothing. Plus it satisfies the “all libs/dependencies in one app”, which is exactly what macOS’s .app, Linux’s Snaps and AppImage, or more generally all Android/iPhone apps are doing. I agree with the RAM/power things too, but these issues come from web pages in general, not Electron itself.
- petecox 9y ago
  If anyone seeks an alternative to Facebook's app, there's Face Slim from the f-droid repository: https://f-droid.org/en/packages/org.indywidualni.fblite/ https://f-droid.org/en/packages/org.indywidualni.fblite/ 1.3 MiB
- LeoNatan25 9y ago
  A clean "hello world" Electron excrement takes 200+ MB in RAM. How is that an "issue from web pages" exactly?
  - tarruda 9y ago
    Where did you get this information? I just tested "electron-quick-start" on Linux and all 3 processes use 40 MiB together
    - wander_homer 9y ago
      Here on my systems (Ubuntu, Gentoo) electron-quick-start leads to ~90 MB more memory usage and it spawns 4 processes which use 110MB, 74MB, 74MB and 44MB of resident memory. So obviously quite some memory is shared between those and probably other processes on my system, but nevertheless the resulting memory consumption is far above 40 MB.

tybit 9y ago

I noticed the atom team are trying something similar with an experiment called X-ray https://github.com/atom/xray https://github.com/atom/xray It will be nice if this becomes a thing, I think it’s more likely that electron apps become significantly more performant than that everyone starts rewriting their apps in QT, for better or worse.

tonyedgecombe 9y ago
POC?
- tybit 9y ago
  Edited to be clearer, thanks.
- Mononokay 9y ago
  I'd imagine "Proof of Concept."

framel 9y ago

electron is cancer

joefarish 9y ago
What are your issues with Electron?
dang 9y ago
Please don't do this here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

minus7 9y ago

Is it really so hard to write a native GUI for three OSes if you must?

hollerith 9y ago
or 2 OSes if 98% of the potential desktop / laptop market will suffice and your product is not aimed at developers.
allover 9y ago
> Is it really so hard to write a native GUI for three OSes if you must? Yes. What makes you think otherwise?
- matthewmacleod 9y ago
  I think this is often the perception - and I understand why, because I shared it for a very long time - but I don’t think it’s true. Building a simple UI for multiple platforms may be somewhat more time consuming than a single cross-platform Electron implementation. This will scale with the complexity of the UI. This particular application has about the simplest UI imaginable. Consume some keystrokes, render some rows of text. Implementing this is any native UI platform will not be hard - but it will reduce the memory footprint, rendering time, and application bundle size. Native UI frameworks are actually really good at rendering simple applications on their platforms. There’s usually plenty of documentation and good development tools. Building an application using one of them is definitely different from web tech - but I don’t think it qualifies as hard. And I reckon it would be useful for more of us to experience as many different platforms as possible - it’s a great way to learn!
  - postfacto 9y ago
    The native platforms backed by real money also have lots of official documentation, real GUI builders, high quality debuggers built into their IDE’s and one cardinal way/library to do something. The importance of all this stuff in speeding up things can’t be overstated.
- 9y ago

jayflux 9y ago

> Given this goal, you might be surprised to learn that Finda is built with Electron, a framework that’s often decried for being the opposite of fast. I thought the criticism was more about its memory usage, not that it wasn’t fast.

tluyben2 9y ago
Most applications I have tried feel slow as well; especially when running for a while.
- sebazzz 9y ago
  That might be caused by GC, which is ultimately caused by memory usage and the runtime attempting to reduce that.
JepZ 9y ago
In fact, there are many downsides performance wise when you think about electron: - it is as slow as any other web rendering engine - it uses as much memory as any other browser - you have huge binaries The key benefit of electron is that you can easily build cross-platform apps which run on every notable platform. Many of the general weaknesses of electron can be eliminated by building a Progressive Web App, but that doesn't solve the performance challenges that come with building a web app. Performance wise web apps are very slow when compared to C/C++/Rust/Go. E.g. for a C program, a single millisecond itself is a long time. For web-apps you struggle to get everything in a 16ms window to not break your 60fps experience. But the point is that while web apps are in fact much slower, they can be fast enough. And if you have a technology that is very platform independent and you can built good experiences with it, then you probably find some nice use-cases.
- afranchuk 9y ago
  >The key benefit of electron is that you can easily build cross-platform apps which run on every notable platform. I've been a bit confused about the draw of this feature. I understand that there are a lot of JavaScript developers out there, and things like Electron allow them to use their JavaScript knowledge to make applications on many platforms. But there are now a large number of GUI libraries (GUI being a typical obstacle for cross-platform support) that can target all these platforms (and sometimes more) as well. GTK+, Qt, and WxWidgets name a few. And they have bindings across many languages! Of course, to make something that's completely custom-looking using these libraries may be more of a hassle than an html/css document. Maybe Electron's popularity _is_ primarily driven simply by the high numbers of JavaScript programmers out there. I guess it's like you pointed out: if you can get it to be fast _enough_, it's acceptable. Kind of similar to interpreted vs compiled languages.

tixocloud 9y ago

Thanks for sharing this. I’ve been dabbling with Electron to build a data analysis tool app but have been slightly concerned about speed. I am glad to hear how quick it’s running for you and getting ideas on how I can make my app faster. Thanks!

Humphrey 9y ago

I wonder if there is a use-case for a simplified lightweight edition of Electron that uses the system webviews instead of Chromium. Obviously this would be much less capable, require cross platform testing, and limit node usage. But for a project like this that barely does anything fancy in the front-end, it would solve the size and memory issues.

LeoNatan25 9y ago
Taking a WebKit2 webview should give you enough benefit. But for some reason they chose Chrome.
roryisok 9y ago
I've often wondered this. You could write a set of generic webview based apps (say, Windows 10 and MacOS to start) and a small js library that would allow cross platform access to low level apis, even just a few at first like file dialogs. React native is sort of like this.

dreta 9y ago

You can't seriously justify introducing massive library into your code just to display some text, and use a few native calls. If it works for you, that's great, but if anybody needs an example of why the software you use is so terrible these days, even though we had huge leaps in technology, look no further.

tarruda 9y ago
If all this app does is display text, it would have been simpler to embed a rich terminal emulator widget and implement the backend as a Rust program with terminal UI
- derimagia 9y ago
  It has a GUI...

snarfy 9y ago

Whenever I find myself wanting to build an app that is electron/chromium/webkit frontend + C++/C#/Rust/Go backend I can never justify it over building a web app + web api instead. If you want to run it locally there is a one line docker command to do it.

filleduchaos 9y ago
Sometimes I wonder if people on this site realize that there is such a thing as an end user.
roryisok 9y ago
Doesn't the user need to have docker installed to run that one line? That's kind of a big prerequisite
- snarfy 9y ago
  Since it's a web app, they could go to my hosted site if they can't install it locally. That wouldn't work for the OPs app but it would work for most. The point being there has to be a better way than frankensteining the browser.
  - roryisok 9y ago
    It depends on what you consider "better". I'd much rather install an electron app than mount and run a docker container, and I say that as a developer who uses docker every single day.

cheez 9y ago

> 1) I want the option to port Finda to Windows and (I can’t believe I’m saying this) Linux, since beta testers asked if they could buy a version for their respective platforms. Anyone else reading this: Linux support is required for any tech-related thing. Many times I have sold licenses into a single person using Linux who then has their company come back to buy 10s or 100s of licenses.

AnIdiotOnTheNet 9y ago
> Anyone else reading this: Linux support is required for any tech-related thing. Which is why pretty much everywhere I've ever worked has run off a combination of Exchange, Office, Sharepoint, Windows file servers, and a plethora of legacy Windows-only crapware. If you work with nothing but webdevs all day though, I could see how you'd get the impression that Linux support for GUI apps is something anyone cares about.

charlieflowers 9y ago

I thought this was intriguing, so I installed it. Doesn't work at all for me. Running finda shows the instruction screen. Try to use it by typing, and the window goes completely white. I can use ctrl-\ to bring the white window up and down, but nothing else works. I had to find the launchd process in Activity Monitor to kill it so I could uninstall.

omnimus 9y ago
Exactly same experience. Probably because author (he even mentions it in the post) has outdated OSX and there is probably some difference between versions there.
superasn 9y ago
I though the whole reason people created Electron apps is because they can run on any platform. This one just runs on MacOS only so I can't even download it :/
lynaghk 9y ago
Author here. Sorry that it's giving you a hard time. Can you say what OS X version you're running or provide any other details so I can try and reproduce/fix? (You can email me privately at finda@keminglabs.com) I tested with a dozen folks before releasing and this issue never came up.
- lynaghk 9y ago
  Haven't heard from OP, but another person emailed me and the issue is likely because Finda relies on AVX2 CPU instructions for fast search. These instructions were introduced in 2012, so it's likely the OP was running on older hardware. I'll add CPU detection to a future version of Finda so that it can fallback to slower, non-vectorized instructions.

pughmans 9y ago

I hate javascript so this might be good.

BlackLotus89 9y ago

Interesting that nobody seems to talk about the software itself and maybe it's alternatives. I for once welcome the concept of something like Finda and am looking for alternatives for me. > Finda finds things — windows, browser tabs, code editor buffers, browser history, apps, files, etc. Finda looks and acts like a normal launcher. The concept isn't new, but fast good launchers are rare. When we look at the Finda-Page (I didn't download the demo since I don't use Mac OS) we can conjecture how it works and there are a few things that bother me. It seems to always run in the background and listen for inputs. It's cross platform so it will probably have it's own file indexer. This all seems to add up to a rather large memory consumption. Anyway right now I'm still using the dmenu [1] launcher and am looking at many alternatives, most of which haven't been updated in some time. First the ones that haven't been updated in some time dmenu2 [2], interrobang [3], and lighthouse [4]. All nice launcher, but here comes my current favourite rofi [5]. Not only is it an active project, but it defines itself as window switcher and launcher (so what finda kinda does). Combined with it's extendable nature it seems to be a solid launcher. Bookmark functionality is for instance given with the buku [6] integration. But I'm still looking for the best solution. Here is the feature list I'm looking for: program launcher, simple calculator (through bc or python), file locator (maybe through locate), bookmark manager (firefox preferably). Other things like quick (online) search, clipboard management or the whole slew of other features provided Finda and panther and whatnot would just be extra. Does anyone of you have a nice lightweight solution? [1] https://github.com/stilvoid/dmenu https://github.com/stilvoid/dmenu [2] https://github.com/muff1nman/dmenu2 https://github.com/muff1nman/dmenu2 [3] https://github.com/TrilbyWhite/interrobang https://github.com/TrilbyWhite/interrobang [4] https://github.com/emgram769/lighthouse https://github.com/emgram769/lighthouse [5] https://github.com/DaveDavenport/rofi https://github.com/DaveDavenport/rofi [6] https://github.com/jarun/Buku/ https://github.com/jarun/Buku/ - bl

lynaghk 9y ago
Author here, and happy that you're interested in the software itself rather than the implementation =) I'll probably write a detailed post about file indexing, since it's pretty interesting from a technical standpoint. I looked into spotlight (via `mdfind`) but it was too slow and I wanted to port to Windows/Linux later, so your speculation is correct: Finda has its own file walking and indexing mechanism. It walks a user-configurable set of directories, but not in the background --- it's actually done every time you open Finda, so you only pay the CPU cost when you are actually using the program. The index is stored in memory, and size is proportional to the number of files/folders walked. However, Finda does respect .gitignore files, so you can exclude things you don't want to show up in the search results (or consume memory).

actf 9y ago

I really like where the author went with this. Everytime I read something like this though I can't help but think how we as developers really need a better low level, UI framework for cross platform applications. What the author has done here is a cool idea, but ultimately this still feels flawed, and like it's a workaround to the difficulties of writing a cross platform UI. Everytime I read something like this I can't help but think about how great a low level, cross platform C (or C ABI) library would be (think something like libuv but for UIs). Such a library would abstract away the OS specific system calls of the UI while still providing the ability to easily do things like: * Create a window * Draw to the screen * Declaratively (i.e. html like) add UI widgets to a scene * Apply CSS like styling (like QML, JavaFX, or XAML) * Use native file dialogs, menus, notifications, etc * Statically link as a single dependency I don't even think something like this necessarily needs to provide native UI elements, rather it just needs to be a more performant, easier to use, smaller, version of electron that could easily be used from any language. It needs to provide common UI elements like buttons, textboxes, divs, grid layouts, etc, but judging by the popularity of electron - I don't think those necessarily need to use native elements. Qt is close to this, but it feels heavyweight and in my opinion its biggest flaw is that it's difficult to link to an application and setup a development environment for. Tk is kind of like this, but way too limited. JavaFX is a really good example, and would be perfect if it wasn't Java only (same with WPF but it's C# only). Right now the closest attempt to something like this that I know of is https://github.com/andlabs/libui https://github.com/andlabs/libui I think libui could even be a starting point for such a library, but the library I'm thinking of would need some type of declarative UI support (i.e. html like, maybe even support for a subset of html), built in support for styling, and less of a focus on using native widgets. I really wish somebody would build something like this.

mherrmann 9y ago
> Qt's [...] biggest flaw is that it's difficult to link to an application and setup a development environment for. Check out (my) https://github.com/mherrmann/fbs https://github.com/mherrmann/fbs. It's for PyQt but I think does get around the obstacle you mention.
arel 9y ago
There is a point that is always missed about Electron - UI. By using HTML, CSS & JS you have an extremely rich toolkit to create UI with constant improvements from browser vendors and standards bodies. If a designer can create a pattern library in sketch then chances are it can be implemented using web technologies. This is a much bigger and more active open platform when contrasted to the capabilities of a particular framework and community. Theres another topic around whether you should detour from the OS UI look and feel. But most designers and product owners worth their salt are conscious of keeping known UX patterns and least surprise.

swsieber 9y ago

OK. Dream time. I'd love to build a cross platform app / ui toolkit with support for pluggable backends. The first two would probably ncurses and electron if I were building it. (I'd do it rust for its excellent Web assembly story and perfeomance.)

roryisok 9y ago
You have my permission, fire away

angel_j 9y ago

what is require('Native')?

tzahola 9y ago

Cool! Still waiting for “building an electron app that uses less than 200 mbyte of RAM” though.

lynaghk 9y ago

Author here. For more background on product development about Finda, there are notes on my personal website here: https://kevinlynagh.com/datatron/ https://kevinlynagh.com/datatron/ I started this as a UI research project to try and replace OS X Finder with a keyboard-only UI. A strong inspiration was the Helm Emacs package. My initial prototype was in ClojureScript/Electron, and I was exploring far more features like inline preview, and a command/argument (verb/noun?) builder system. However, after showing my prototype to a few friends, they were all much more interested in the fast search and window switching capabilities, so I decided to cut scope, focus the project on those features, and get something out the door. This is my first Rust project, and I've been thrilled with the language and that community in terms of great libraries, documentation, and their willingness to help beginners like myself. p.s. Sorry I'm late to the party, I pushed this blog post online immediately before going to sleep for the night =P

vkjv 9y ago
Just wanted to say "hi" and that this is a great read! If you are interested, there is a Neon slack where some of us hang out. For example, you might be interested in neon-serde which could clean-up some of the argument parsing and match logic. https://crates.io/crates/neon-serde https://crates.io/crates/neon-serde

tracker1 9y ago

I think it's wild that the browser has become the UI layer in so many applications... CSS + HTML simply make things more consistent in a way that no other toolkit ever has. On the flip side, it's sad that every app now packages the entire jungle (so to speak). I know that this is what Adobe Air was supposed to be, and part of me would love to see something akin to Chrome's autoupdate mechanisms for an Air-like platform around Electron's base that could be shared. That doesn't get around performance issues, but would at least mean some reduction. I think it's a great option to have, but still concerning in some ways. I also think that React-Native will probably grow to be easier to create more native-like cross platform apps over time. Definitely interesting times.

mamcx 9y ago

This is only possible because the browser on desktops is "fast". I try the same idea with Android/iOS. In iOS, all fly, but man... android is super-slow. I can't believe it myself, so I downloaded several demos of html-based apps and the results hold. I totally will kill for a webview-like control on android that I could reliable use and be almost 80% as fast as on iOS.. Now I implementing the UI on both, and seriously is harder than I expected... Never imagine the Apis were that bad...