Hacker News Reader

Comment by monsieurbanana | Hacker News Reader

For something that puts "not using electron" so prominently I didn't expect it using flutter. I admit I don't really have much experience with it, I thought it was like react-native (but better?), still far from truly native apps.

Im here to being told I'm wrong. I would love to, specially since we can transpile clojure to dart

View on HN

Yep. This app uses 230mb of RAM on my machine compared to Spotify that uses 208mb. But it's definitely more performant than my hideously slow Electron Spotify client. I'm really done with Electron. I hope this shaming of Electron apps continue because I can't stand this degradation of software. The only Electron app of recent that had good performance is Notion Calendar (used to be Cron). Although, Notion itself is painfully slow. This is why I'm building a Notion alternative in Qt C++ and QML[1].

[1] https://www.get-plume.com/

EDIT: Is the app down? It doesn't load the "Browse" content for me.

Plume looks so sick. Looking forward to it. A Vim-like modal editing mode would be so cool, I think.

Thanks! I heard many requests for this, so I'll consider it, but if I do get to that it will be at a later stage.

Weird, it takes up ~150MB while having a 500+ song playlist loaded.

To respond to your edit, yes - it seems like the app is down - nothing seems to load at all on the Browse tab or anywhere else...

Plume looks nice! How does the sync work? Local first rocks, but I do want some redundancy as well. Are there plans for multiplayer or sharing?

Thanks! One of the next features we'll on work will be support for arbitrary folders (basically all notes will be plaintext inside folders, currently they are all plaintexts but inside a local database), so you could sync your notes with any cloud provider (e.g., Dropbox). We'll also provide our own built-in sync option. There are plans for sharing notes, but not quite for real-time collaboration, if that's what you mean by "multiplayer". There are plans for collaboration in the future, but not real-time - I just don't think real-time collaboration is good for text-based formats.

Coming from AppKit/UIKit I tried to learn Qt and it was just awful. I hated how tightly coupled with C++ it was. Everything was based around subclassing and overriding methods, there was no way to just have a dumb UIView and set its frame and add a bunch of subviews to it. There was also no clean way to expose a C ABI to use a scripting language (with an FFI) to configure the UI easily

All of the Qt apps I know about (Ripcord, Dolphin) are fast but the aesthetics of the UI was just terrible. So I gave up on learning Qt. But this thing you made, Plume, actually looks good. If there isn't a monstrosity of hacks and boilerplate underneath this UI I might give Qt another shot. Otherwise I think I might just build my own thing from scratch on top of OpenGL or something....

I feel ya! I thought the same, until I discovered the world of combining Qt C++ and QML. QML is extremely easy to learn (I studied all the basics in one day using this Udemy course[1] (not affiliated, just love his work). BTW, he has many free awesome YouTube videos for Qt C++. Creating an aesthetically pleasing app in any framework takes a lot of effort (it's mostly about being focused on what necessary and then creating a lot of white space around it, haha). It's so easy to create beautiful, fluid UI with QML. I've created a short video that demonstrate what I'm working on currently[2] - a Kanban view inside my block editor (kinda buggy now, still WIP). Hopefully, this does inspire you that it's possible.

And it's actually pretty easy to write the C++ code. I don't really use custom sub-classing much. I use Qt's QtObject which allows me to create C++ object that work beautifully with QML. Bryan's course doesn't delve deeper as that, I had to do a lot of searching to figure it out. I hope to open source some of Plume's components to inspire others to do the same. Another point regarding aesthetics, it really takes effort, but Qt can be extended using community libraries. For example, if you want your app to look native on macOS and Windows with a sexy frameless border with a transparent window, then you could use the awesome qwindowkit[3]. Another example, I wanted to position the window buttons on macOS (the traffic light buttons) differently, but couldn't figure it out, and obviously this can't be done using Qt alone, so I looked at Electron's source code and saw how they do it there in Objective-C and incorporated it in my app (ChatGPT-4 wasn't very helpful at that). Now I really want to have these buttons' fill color transparent like Things 3 does, so I'm looking at how to achieve that haha. I already got some ideas. If you need any further help, let me know![4][5].

EDIT: A cool feature of combining Qt C++ with QML is that you get the performance of a compiled language like C++ with the reactivity, ease-of-use, fluid and easy animations (and more) of QML. You can see on Plume's website that it's 4x faster than the fastest comparable native app on macOS.

[1] https://www.udemy.com/course/qml-for-beginners/

[2] https://www.loom.com/share/b40009316f6b420b9ece15a1f99e987c

[3] https://github.com/stdware/qwindowkit

[4] https://twitter.com/mamistvalove

[5] ruby AT mamistvalove DOT gmail

Thanks for the candid reply. Man... this sounds like too much for me. Oh well. Guess I'll use AppKit for now and if I wanna add Windows/Linux I'll bring in Qt. Definitely will come back to this comment if/when that happens.

No problem mate, let me know if you need any help. Good luck with AppKit!

I know what you mean. Would love to just have AppKit/UIKit with some platform integrations (e.g. correct widget themes) on other platforms. Closest that exists to that is GNUStep, but it’s stuck on an old version of Objective-C (no Swift) and targets something like OS X 10.6 with API compatibility.

Outside of the that the next closest I’ve tinkered with is GTK, but since version 3 it kinda gave up on looking right running under anything but GTK/Qt-based desktops. It’s easy to make idiomatic bindings for which is nice though.

Yea, GNUstep isn't bad.

It uses an old version of ObjC? Are you sure that's correct? ObjC is open source right? There is no reason to be using an old version.

Yeah the frameworks are kinda old but the new frameworks (since ~2014) don't really bring anything new to the table. And Swift is overrated anyway.

Not entirely sure about Obj-C version.

Disagree regarding frameworks, though. The newer snapshot-based APIs for NSTableView, NSOutlineView, and NSCollectionView (added in 2020 as part of macOS 11) are a massive improvement over the old index-based ones for example, and there’s been numerous polish and quality of life improvements scattered throughout.

Also disagree about Swift if only for the large number of things it comes with out of the box that’d require a third party dependency with Objective-C, but so many more errors being caught at compile time, no need to maintain header files, and no awkward split between C and Obj-C for basic types are nice too. I still enjoy Obj-C for some types of projects but as project complexity increases so too does my preference towards Swift.

Oh I didn't realize they were still adding APIs to AppKit. That's cool.

Yea I mean the ObjC vs Swift thing.... a matter of preference. I trust Steve Jobs more than I trust Tim Cook. I hate the feature creep in Swift. I hate Swift optionals. ObjC compiles faster than Swift. The ObjC ABI/runtime is superior to the Swift ABI/runtime (which allows for cool stuff like https://cycript.org). I like the dynamic typing a lot. Managing headers is a non-issue for me, I just consolidate everything into one monolithic header file.

I've worked in pretty big ObjC codebases (1M+ lines) so I know most of the tricks to deal with complexity. For Swift, max I've dealt with is 100k lines and it was crippled with tech debt. Frankly, the other engineers on the team were terrible, so maybe that's why. They abused the shit out of RxSwift and refused to use the `!` force-unwrap optional feature

Yeah, electron is so over.

Now tbe modern tech stack is to build a bash+python app in an env, add a touch of R, some js, and bundle it into docker container, then make that docker container into wasm with container2wasm, and give that out as the executable.

It's wonderful honestly. You can get just about anything working with stitching together stuff, and then serve your 10GB executable to anyone :).

So MuCh BeTtEr ThIs MoDeRn WaY!

Serious question: What's the feasibility of local web apps in containers, which appear to the user to be a "regular" app. E.g. Django + SQLite, running in a Docker container, and run by a Mac app shortcut. How would you recommend setting up and running that stack? Better ideas?

Flutter, from experience, works really well on Android. Unfortunately the same cannot be said about the web (see for example [1]).

I think that if these performance issues were to be solved, Flutter would see a bigger adoption. In any case IMHO Flutter >>>>> Electron

[1]: https://github.com/flutter/flutter/issues/56257

Last I knew it had significant performance issues on iOS (framerate drops/stutters), which dampens its cross platform appeal somewhat and is part of why I’ve heard of apps using Flutter for the Android port of their app, but nowhere else.

How old is that info? We’re using it, and it is buttery smooth on both phone platforms.

Not that old. Only when Impeller was enabled by default last year did Flutter become usable on ios.

Flutter on the web is absurd: At least when I last checked, it's been rendering UI widgets into an HTML canvas by default, using its own low-level drawing library.

That sounds about as good of an idea as the old Java desktop GUI framework that used to (poorly) imitate native UI elements of Windows and macOS: Everything always looked three major versions behind and felt extremely janky.

I wouldn't care less if it worked in a performant way - in the end Flutter apps are using their own design (Material 2 / 3) - so rendering them in a Canvas is OK-ish.

The problem is that, on the web, the performance is extremely poor, so Flutter is still not worth being used there (IMHO).

I’m sort of surprised it’s considered a good thing. Some of my favourite programs use electron, like visual studio code. I haven’t used Spotify though, so maybe that is one of the many electron apps that suck?

I was very unimpressed by flutter when we PoC it at work, but that was years ago, so maybe it’s gotten better since.

Spotify's desktop app has been pretty snappy for me, and it's been like that for many years across different machines.

Spotify Desktop also doesn't exactly use Electron, but 1 layer below: CEF

Also, they've used CEF since before Electron was even a thing (before Atom even).

Yes, and they are doing it better than Steam Client i think.

VSCode couldn't support multiple windows until just recently, entirely because of a limitation from the early days of Electron.

When "multiple windows" is a feature to be announced (as if weren't trivial on any native stack), you know it's a sad state is affairs.

> VSCode couldn't support multiple windows until just recently, entirely because of a limitation from the early days of Electron.

That sounds like Microsoft deflecting blame. You've been able to do multiple windows for a very long time in Electron, I remember being able to do so in 2019 at the very least, and the book "Electron in Action" (https://www.manning.com/books/electron-in-action) even have a chapter dedicated to it, a book which was released in 2018.

VSCode always could have multiple windows. You can open multiple projects and they all share the same process(es), so clearly Electron supports multiple windows.

What it couldn't do, though, was to have a single workspace span multiple windows (ie "detach" tabs).

Whether or not this was caused by an electron limitation or a design flaw in VSCode, I can't say. Though I find it hard to believe that it would have been impossible to implement had they really wanted to.

Don’t understand all the fuss about VSCode. I’m sticking with neovim.

Flutter is pretty native as far as resource usage goes. The language does use a VM and GC but it's performant enough. There isn't native look and feel though. (They can emulate it a bit, but it isn't perfect)

Flutter doesn't use a VM for release builds anymore. (Still GCed obviously).

The last time I tried Flutter it was hilariously bad. The "Flutter Gallery" sample was blasting my GPU to render at max framerate without even moving the cursor.

Now with Spotube it appears it has gotten better. But I can still see:

- "off feeling" scrolling with the scrollwheel

- some kind of framepacing issue when using the scrollbar at the right hand side

- Click latency that's better than electron but still worse than anything QML/QT has to offer.

- DPI set in KDE/X11 seems to be ignored. I'm not sure about this, could be a personal preference of the developer to have things this size.

I'm using the flatpak build with a 6700XT.

People will always complain, but in reality you can make an electron app which no one will distinguish from a native app, and you can make a native app which will lag so hard that it would feel like a browser page from 2004. People just like to put the label "electron" or "flutter" on it and base their blames on that.

I tried Flutter on my previous project, it’s good, like really good. Dart has its weird parts but other than that, I enjoy it a lot.

I've heard many good things about it from Android developers. As an iOS user, I despise it. Apps written in it feel extremely janky. How is it even possible to bring down an iPhone 15 Pro to what seems like less than 10 fps in simple UI element scrolling?

I think it's skill issue

Sounds like bad implementation, Flutter especially now with the Impeller engine is very smooth on Android / iOS. I don’t know about the web though.

It happens for me even with Google Pay on iOS. I’d hope that at least Google would know how to use it correctly.

I was surprised when I learned Flutter actually runs as native code without needing a JavaScript bridge like so many others.

Although similar to something like React Native - Flutter does paint the screen. Personally I see it as a potential Electron replacement in the future.

From what I’ve seen Impeller is also a big help on iOS. Screen jank was pretty bad for us when Flutter was using Skia as a rendering engine, although when I last messed with Flutter (~6 months ago) Impeller felt almost production ready but iirc there were still a couple small things, not sure if they are better now.

Personally I’ve become a big fan of Flutter, especially for back-office/utility type apps. We would follow all the Material Design 3 guidelines and when it comes to time spent, if you need to develop the same app on more than 1 platform, it’s worth consideration.

I’ve found some people will say: “But it’s hard to get it to look like a native app in Flutter” but for me I’ve always seen that as more of a skill issue. You are literally painting the screen, you can get whatever pixel perfect design you want, if it can be Figma’d it can also be Fluttered and to be fair there are Cupertino widgets and you absolutely can get the best of both/many worlds if you want. Just like how on the web you can do a transform based on device width to switch between the mobile or web view, if you desire you can have different widgets show up for different platforms and give everybody a native feel. I personally still think that’s easier than writing/maintaining multiple individual apps.

I think the biggest downside though is that search engines don’t do well with Flutter Web. It isn’t the nice easy to crawl HTML, and it’s really hard to get a flutter app indexed or to give it good SEO. There’s also silly rules that search engines have about how the content displayed to the user vs crawlers has to have the same data. (I.e. when the web-crawler asks for your page, you are supposed to give it a page with the same data you would give the user.) The best we could do to improve SEO was to make the landing page a page that in the background ran all the same queries and shoved the data into HTML tables, with a popover that said “this is a page for robots that had a button that said “Take me to ABC.com” and a check box that said “automatically redirect me next time” that we stored in a cookie. It was hacky and not a good user experience.

For now, whenever I need to do anything GUI I will use React for the web and Flutter for everything else, but it would be nice to truly be able to only use 1 framework for every platform, which to be fair I’ve used Flutter web and it isn’t all to bad if it weren’t for the issue with search-engines web-crawlers. For apps that don’t need SEO.. Flutter is a great choice. I suspect we’ll see a lot more SaaS apps building in Flutter in the next few years. I think it’s on the cusp of being mature enough to be seriously considered for production scenarios.

I’m just mostly worried about the ecosystem. Google chose Dart for flutter after the results of a lot of research that only Google scale companies can do and to be honest although it IS a lesser known language it isn’t a bad one. It’s AOT and JIT so the hot reload is amazing. It reads like “insert most language you know” here. If you know how to code nothing in Dart should be drastic or surprising. If anything I’d almost say Dart is boring, which I like boring things. I’ve experience with a handful of languages, and for me Dart ranks highly in terms of usability/ergonomics. But there’s a not unsubstantial risk that Google could decide to drop the ball and Flutter could become kind of like the Windows phone. Really great, but canned because people didn’t build enough things for it.

If I were on the Flutter team I’d be most focused on figuring out how to deal with SEO issues. (assuming impeller does indeed provide a full fix for the screen jank, I’d assume it’s gotten better in the past few months, can anyone comment as to if it’s “there” yet or not?)

>can anyone comment as to if it’s “there” yet or not?

It's enabled for ios by default. Android probably in two more releases if I had to guess. If you were doing a lot of custom stuff you may run into issues with Impeller on some CPU bound tasks regarding tessellation but for a regular flutter app it will almost always outperform Skia especially around previous pain points like scrolling and animation.

Reply on news.ycombinator.com