Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ubuntu Makes Flutter ‘Default Choice’ for Future Desktop Apps

omgubuntu.co.uk

Post reply on HN
Print view View original

91–100 of 120 posts

Re: Ubuntu Makes Flutter ‘Default Choice’ for Future Desktop Apps

#91

Post by the_why_of_y »

scaladev wrote: post #63
axaxs wrote: post #58

Earlier quoted context omitted.

In theory I agree, but Canonical really seem to do it over and over. Whether it's NIH or something else, it seems every time technology starts shifting, Ubuntu goes its own way only to drop it a year or two later. Unity/compiz, Mir , Ubuntu One, Upstart, Bazaar. And currently baking are Snaps and LXD. This isn't to say any of these are bad products, but it has real effects to the end user, who invest time in somethin…

Don't forget that snaps came almost a year before flatpak. This is being parroted all over HN and still many don't know it and blame Canonical for reinventing the wheel, which is why I'm posting this. (I agree with your general idea and the rest of your comment.) https://en.wikipedia.org/wiki/Snap_(package_manager) https://en.wikipedia.org/wiki/Flatpak

Don't forget that FlatPak has been designed out in the open and plans were presented as far back as GUADEC 2013.

https://www.superlectures.com/guadec2013/sandboxed-applicati...

Re: Ubuntu Makes Flutter ‘Default Choice’ for Future Desktop Apps

#92

Post by GekkePrutser »

Hmm I'm not a fan of flutter at all.. It's pretty poor on mobile, you can always tell when an app uses it because it feels 'out of place' on the platform.

Though I guess it is better than Electron because that's really wasteful and bad. There's a few pearls like VS Code but 95% of Electron apps are horrible (including other MS apps like Teams, Yammer etc).

Anyway pretty much everything Ubuntu does these days rubs me the wrong way. Snap in particular (super slow to start, and only works with their own store). I still use it for work a bit because we only have 2 choices and I hate Red Hat even more :)

But my point is, Canonical keeps pushing stuff that's great for their interests (snaps with their IoT ambitions, and trying to rope other distros into their snap store) and for developers, but not for the users.

Re: Ubuntu Makes Flutter ‘Default Choice’ for Future Desktop Apps

#93

Post by cassepipe »

imbnwa wrote: post #89
cassepipe wrote: post #69

Earlier quoted context omitted.

I just bought an Onivim license cause I wanted to treat myself and they're using Revery as an Electron replacement. Not sure I understand why it is faster, but I have to say the startup time is almost instantataneous and it's really responsive on a Linux 2014 i5 4Go laptop (whereas VScode ...). So it might be a good alternative.

How is Onivim? I played aroud with it v1 but wasn't impressed enough to gamble money that they'd made breakthroughs in v2

I have only used it for one day so far. I have a hard time quitting my customized terminal vim so I haven't looked much how to configure it. The only thing I can say so far is that it's beautiful, works out of the box and it is really fast and responsive.

Re: Ubuntu Makes Flutter ‘Default Choice’ for Future Desktop Apps

#94

Post by josteink »

mhoad wrote: post #86
josteink wrote: post #14

I guess that makes Dart a less dead language than it used to be, but from what I can tell there’s almost no momentum around Dart at all. Basing your future applications on a language which seemingly is already slipping into its coffin (even discounting the regular Google discontinuing thing), seems like a really weird choice.

I don’t know if this will continue to be true forever. Dart is actually an awesome language to work with generally and is only continuing to get better. I think it has HUGE potential on the server side but there is a chicken and egg problem there at the moment where there don’t appear to be any actively maintained frameworks, even some basic things like ORMs and dependency injection frameworks are few and far between…

> Dart is actually an awesome language to work with generally and is only continuing to get better

Not to kill your enthusiasm, but that can be said for almost any new language.

> I think it has HUGE potential on the server side but there is a chicken and egg problem there at the moment where there don’t appear to be any actively maintained frameworks

Which is why an active and vibrant ecosystem around the language increasingly is more important than the language itself.

Just look at Go. A terribly, inexpressive language where the common solution is to write code-generators.

But it has an ecosystem and the stuff people need. So people use it to write more software and more Go-libraries, reinforcing the platform-effect.

Re: Ubuntu Makes Flutter ‘Default Choice’ for Future Desktop Apps

#95

Post by plerpin »

scaladev wrote: post #66
eropple wrote: post #62

Earlier quoted context omitted.

I just started VSCode on my desktop. Its "_startup_ memory", with something like two dozen extensions installed, is sitting at 170MB. I also just started Discord on my desktop. Its "_startup_ memory" is 39MB. Now Slack's a pig at 380MB, fresh-opened, sure. But reality doesn't really seem to oblige these kinds of claims in 2021.

Are you looking at a single worker process out of about 10? This is such a frequent mistake it's not even funny. Do something resembling a proper measurement: run `free -m` (or the alternative on your OS) before starting VSCode, and then right after it finishes loading, ideally on a completely bare system to reduce noise. Here are my numbers for a freshly installed 1.53.2 with zero plugins and no configuration: used…

I wish there was a stickied post feature to head off these sorts of RSS measuring contests.

Multiprocess applications, and especially multiprocess applications with really big discardable caches, are extremely difficult to compare apples-to-apples.

Re: Ubuntu Makes Flutter ‘Default Choice’ for Future Desktop Apps

#96

Post by je42 »

panta wrote: post #80
preommr wrote: post #31

I am bringing some negative energy but I've been burned. I don't understand the hype about flutter - putting aside that dart is a tool that made more sense in a different timeline, or that some of the examples seem really slow/buggy, or that it's rendering behavior is a nightmare to guarantee consistency - putting all that aside, I've yet to see anyone build anything non-trivial with flutter. And then there's Ubuntu.…

Yes, in my view Canonical betting on flutter is almost a testament to flutter doom. Choosing flutter is not the right choice anyway: it’s a lot more limited compared to Qt, it requires a language which is not used anywhere else, it’s slow and heavy, its tooling is incredibly complex, on some platforms won’t probably be ported anytime soon (if ever).

what exactly of flutters tooling is complex ?

getting through the tutorial is a 15min thing. I don't see much complexity exposed to the developer.

Re: Ubuntu Makes Flutter ‘Default Choice’ for Future Desktop Apps

#97

Post by oblio »

vbezhenar wrote: post #17
candiddevmike wrote: post #4

I wish they would expand on what's wrong with Qt or GTK. Flutter support on both Windows and Linux is pretty bad. In my opinion, electron is a better choice for cross platform desktop UI--VScode is a shining example of what that can accomplish. And they're in for a lot of work if they want to customize Flutter so it doesn't look material or cupertino. Also, their big contribution to Flutter is getting it on the snap…

IMO they are bidding on Flutter hoping that it'll become next big thing replacing Android. It'll allow for easy porting mobile apps to Linux. Time will tell whether they're right or not. They made some failed bids in the past (Mir, upstart), but at least they're trying to move.

> They made some failed bids in the past (Mir, upstart)

Bzr, Launchpad, Unity, Juju, etc. They have a ton of misses.

Re: Ubuntu Makes Flutter ‘Default Choice’ for Future Desktop Apps

#98

Post by ta988 »

scaladev wrote: post #55
ta988 wrote: post #12

Earlier quoted context omitted.

Faster than? Do you compare applications that do similar things?

Take a look at desktop Telegram when you have some time. It bundles its own fork of Qt (which inflates its shared memory usage as nobody else is using the library), has a very polished UI and all the same features as any other modern messenger, and runs circles around any Electron application I've ever seen. On my machine from 2014 it starts instantly and the memory usage never goes above 200-250 MBs, which is not id…

Thanks for the numbers, thats indeed quite a difference.

Re: Ubuntu Makes Flutter ‘Default Choice’ for Future Desktop Apps

#99

Post by wetpaws »

toastercat wrote: post #77
thiht wrote: post #70

Earlier quoted context omitted.

> it's fine if it takes up a significant proportion of a machine's resources I currently run 2 VScode instances and they literally total 70 MB. So no, it's not significant, on the contrary actually. And to be fair, even if it was 700 MB, I wouldn't care. Even older machines have at least 4 GB memory.

I'm always puzzled by these kinds of retorts. It's wonderful that you've never experienced performance or resourcing issues with Electron apps. But just because you haven't, doesn't mean other people don't. For the record, VSCode chugs like a MF on my Thinkpad running XFCE with 4gb of RAM. Meanwhile, Sublime Text flies

Sublime Text has been consistently slower for me than VSCode.

Re: Ubuntu Makes Flutter ‘Default Choice’ for Future Desktop Apps

#100

Post by sho_hn »

ldiracdelta wrote: post #34
arusahni wrote: post #24

Earlier quoted context omitted.

As a KDE fan, the recent changes to QT's licensing have me concerned. [1] Given that Flutter compiles to native code, and doesn't require shipping a V8 engine with each application like Electron, this seems like a reasonable decision for them to make. 1: https://www.qt.io/blog/qt-offering-changes-2020

The KDE foundation is in the mix to ensure an open source path: http://www.olafsw.de/a-better-qt-because-of-open-source-and-... however, https://mail.kde.org/pipermail/kde-community/2020q2/006098.h... End of last year they did release 6.0, so it looks like they're not hiding their releases for a year. You won't get the LTS fixes, for a year though. For me, this means I have to stay on 5.15 until 6.2( because of locat…

You don't have to wait a year for 6.2. 6.2 will be released immediately, and also the initial bugfix releases (e.g. a future 6.2.1, or most recently 6.0.1). Only once a particular version branch is declared LTS do additional bugfix releases become commercial-only - with 6.x, that means the next feature release (and perhaps even bugfix releases for that) will most likely be already available by the time an older branch goes LTS.

Additionally, Qt changed its approach to bugfix commits to go to dev first and then get backported, so even if a distro is stuck on an older version branch in LTS mode, critical fixes will be available publically and can likely be backported manually.

Overall the change to the LTS support strategy isn't amazing, but it's impactful mainly to 5.15.x since it's LTS and the transition to Qt 6 will take some time. Once the transition is over I suspect it won't be a significant issue however.

Post reply on HN