Hacker News Reader

Comment by axegon_ | Hacker News Reader

I'm actually a great fan of flutter and imo it is the best cross-platform solution out there. Probably except for web: though it produces very good result performance-wise, the end result is never really "web" and doesn't act like traditional web. As for desktop applications(whether it be windows, linux or mac), it seems like it's too mobile-oriented. I see great potential for simple solutions like self-service operations where you need a basic UI and it would be great if it could easily target platforms like raspberry pi (arm processors running Linux). But at the moment, while possible, it is a very painful thing to tackle and I wouldn't rely on something like that for an end product. I would assume that this is why google is working on fuchsia but way too few devices are supported. And neither of them is cheap(which is what could be a game changer, going back to the raspberry pi).

View on HN

I've been using Flutter in the last few months and agree. It's the best multi-platform solution for mobile, although it still doesn't match native behavior and performance, it only gets close.

On the web it's DOA for most use cases - it's just a canvas, so scrolling, text selection, shadow rendering, etc. is custom, doesn't feel native and must be downloaded and compiled.

It can have a future on desktop. One "cultural" obstacle is that the de facto default widget system is Material, which is simply a wrong approach to desktop UI.

>It's the best multi-platform solution for mobile

They announced beta version for Windows in the last few weeks, so what to expect? I've been using it on linux desktop for 4 months so far, there were many problems, but it's absolutely the best framework so far. It's miles ahead of Qt (which I've been programming in since 2010). Dart and flutter are just years ahead of Java, C#, Qt and React Native in terms of positive programmer experience, productivity, good looking UI. There are so many bad things to say too, but all I can think about are only due to immature ecosystem, but that's changing literally daily.

Hoe is it ahead of Qt (on desktop)?

I'm wondering this, too. While I enjoy Flutter, it doesn't hold a candle to the extensive Qt library and QML.

Specially to the graphical designer tools, or the quality of third party component libraries.

I wrote it's more pleasant to be used by programmers by giving better experience, then I wrote it's ecosystem is immature, but growing. As of now, it has its better and worse sides.

Dart is the reason I don't like flutter.

Why do you feel C# is worse then Dart?

Dart is...fine. The real value comes in its code generation features, which enable packages to add whatever language features they want even if the language maintainers don't (yet), such as algebraic data types, functional programming features, etc. You can argue this as being good or bad for future maintenance but it's nice to have the ability to add to the language.

> The real value comes in its code generation features, which enable packages to add whatever language features they want

Got any eamples of ADTs, pattern matching, immutable collections, data classes, named parameters, etc.?

Coming from Scala and TypeScript the Dart language is pretty unappealing wrt syntax and functionality, kind of archaic actually. Flutter looks amazing and have been hoping that Dart would evolve more quickly than it has.

https://pub.dev/packages/freezed is ADTs, pattern matching, Dataclasses. named parameters are already part of the language.

There’s about 4 different packages that provide immutable collections, built_collections might be the most popular.

Dart is just about tolerable but Dart + Flutter widget hell is not.

> It's miles ahead of Qt (which I've been programming in since 2010).

Would you mind elaborating?

Flutter widget hell makes Javascript callback trees look tame. I just don't get the buzz around this atrocious style of coding.

You commented this elsewhere too without elaboration. I'm curious as to what you mean by 'widget hell'.

I founded the nested tree of widgets syntax good after getting over the (short) initial learning curve. Some basic good programming practice over shared bits and it was very maintainable even for complex screens.

Why is this style of programming frowned upon in Javascript yet idiomatic in Flutter?

I'm not sure what you are talking about. Javascript developers also use HTML and the ability to nest HTML elements is "idiomatic" as well.

This is a wonderful answer and much better than what I was about to write.

Flutter Widgets, like HTML are declarative. They're just hierarchical information. This works in HTML, and it works in Flutter - there's nothing to get confused about.

Nested control flow (if statements, loops etc.) obscures the actual behaviour and so good practice is to break it up until it is clear and understandable.

Widgets are declarative, like in HTML, the nesting is additional information. With callback hell, you nest logic, and actually obfusc information about the control flow.

Flutter for web feels like going back to the .net "webforms" days, where you could supposedly build a web app the same way as a desktop one and the whole client-server thing was abstracted away. Except it sucked, I still have nightmares about viewstate. Seeing Flutter apps that render everything to canvas feels similar.

Developing once for iOS and Android seems obvious and doable, but extending that to the web is a different game.

Welcome to WebAssembly + WebGL future.

I think the goal of running native speed compiled-ish code on the browser in a sandboxed way would be great if it worked. CSS and HTML for "apps" has always seemed like a hack to me. The problem is every single attempt to do this in the past has resulted in a bloated mess. Maybe this time will be different...

I am a believer!

The irony is that with WebAssembly maturing, we will have the revenge of plugins, and stuff like Flash is already being brought back, but hey now it is a standard browser feature.

> Developing once for iOS and Android seems obvious and doable

After shipping an app in it this year I've become a big fan of Kotlin Native, you can do enough code sharing to take the edge of doing two apps as a solo dev while having very little friction to access native views and APIs. The two apps feel like platform citizens on each OS but I have networking, persistence, utils and state management shared between them.

Flutter only falls back on the canvas, it avoids using anything but html elements if it can. Fancy animations tend to resort to the canvas

I wish the dart/flutter team would focus on improving dart for web (e.g. by updating/fixing the JS bindings) instead of chasing flutter for web which seems like a long shot and rather hacky (referring to using the canvas for rendering content)

> using the canvas for rendering content

This sounds like Flash all over again. Let me guess - no native text select, copy & paste supported? Scrolling is "wrong" in a subtle way?

We haven't reached perfection yet (that's why we're still in beta), but our goal is to be _very_ different to Flash in these kinds of areas.

Here's an example of text fields: https://gallery.flutter.dev/#/demo/text-field

Right-click and you have access to the browser context menu; choose Inspect and you can see a <textarea> or <input> control.

Frankly that feels exactly like a Flash page. Natively selecting text content isn't supported on either Firefox or Chrome on Android (apart from within inputs). Scrolling is broken ("yanky").

Flutter for Web further feels like a nightmare for accessibility. I tried enabling the native Google screenreader on my device. It only says "No text found at that location" when I try to read any of the Flutter demo pages in either Chrome or Firefox. In addition to being extremely hostile to people with disabilities, it will soon actually be illegal to build new products with accessibility-hostile tech like Flutter for Web for large parts of the European public and private sector:

https://en.wikipedia.org/wiki/European_Accessibility_Act

> we're still in beta

From these viewpoints that feels more like an early alpha product. In 2020 no accessibility support is a non-starter.

About accessibility, you need to find the "Enable accessibility" button and press it first. It's not visible on screen, but you should be able to find it with your screen reader's navigation commands (e.g. swiping left and right on a touch device). Yeah, it kind of sucks that the user has to turn accessibility on, and for that reason alone, I will never willingly develop a web application with Flutter. But at least it does support accessibility.

Right, to be fair I was able to enable the accessibility mode with your instructions. This way, the text content is indeed accessible to a screen reader. However, navigation in any of the demo apps with a screen reader was completely broken. So a user might be able to read a single page but not discover further content. With normal web pages we usually have <a> elements that enable navigation regardless of visual gimmicks.

Don't kid yourselves. Web target is very much early alpha for Dart.

There are so many obvious problems with it:

- Everything relies on 1500 nested custom elements with hardcoded transforms to put them in place

- This breaks default browser interaction with the page entirely. Because what may look like a page is actually a bunch of absolutely positioned controls with absolutely positioned canvas inside them.

- Scrolling, one of the most important things in a browser, is broken. It's janky and slow (manually re-implemented?). I'm guessing containers have to be explicitly marked as scrollable with correct sizes, because resizing the browser window does not make content scrollable (try it with the demo you linked).

- Text is broken. Because it's rendered onto a canvas. So, all text interactions + accessibility is broken. Fonts are rendered incorrectly. I mean, on the demo page you can't even copy code other than through the "Copy All" button.

- Navigation is broken. Navigating the demo apps (which have more than one page) is not reflected in the url, so the back/forward buttons are broken

- Keyboard navigation is broken. Nearly none of the elements can be tabbed to. Except some buttons in demo pages. I guess they are explicitly marked as such?

- When elements can be navigated to by keyboard, they can only be activated by Spacebar. Even though Enter also exists. I'm pretty sure forms cannot be submitted by pressing enter, either.

- iOS-style date pickers are clipped in Safari

- 2D transformations demo is broken in Safari

It's just me spending five minutes on the demo site.

The effort is certainly commendable. It's not beta yet. It's possible you may want to scrap this and go the Figma route. They implemented their own rendering engine in WebGL: https://www.figma.com/blog/building-a-professional-design-to...

That demo runs horribly on Firefox.

And clicking around seems to completely ignore my back button.

And hotspots didnt change to the finger cursor.

It looked pretty slick, except for those points. Oh well...

It's also super laggy for me on Chrome.

That's really cool but I think all text, such as "Please enter only alphabetical characters", should be selectable. For example someone may want to copy & paste it into a bug report.

https://gallery.flutter.dev/#/fortnightly

Basic features like selecting the text doesn't work.

"Flutter allows content providers to protect their IP by not allowing text theft out of the box"

I loaded that page in both Chrome and Firefox Preview on a Pixel 3a and switching between text inputs or scrolling feels quite janky

The gallery apps don't even support the browser back button after going into a detail page. I guess this is still alpha stuff presently.

Yea, Flutter Web isn’t viable and likely never will be. The approach will require re-implementing browser primitives (like copy paste) which means you’re always going to need to ship a ton of JS to clients which makes it antithetical to the PWA approach.

EDIT: thanks for the downvote. But you don’t have to take my word for it, this sentiment is (privately) shared by Googlers themselves working on Chrome and PWAs.

Om The flip side, modern javascript frameworks seems to like to reinvent the basic primitives as well (based on how often my back button is broken), so I'm not certain that will be a deal-breaker.

Tie it in with AMP and you have the webdev cocktail from hell.

+1 on this one. I've fiddled with angular dart for instance and tbh as someone who is horrible with doing frontend and hates js with a passion, this was enjoyable. Yet the release of the newer version[0] is taking forever.

[0] https://github.com/dart-lang/angular/pull/1892

Flutter's ability to "compile to web" was something that confused me at first as well, but on second thought it's genius. It makes it easier to ease managers into selecting Flutter since deployments and updates are done via a web browser. If that works for them then maybe there's never a need to go fully native though that option exists if they want to -- and the ability to go back to compiling for web gives managers a sense of "this isn't a one-way, I'm screwed if something goes wrong" journey.

> and the ability to go back to compiling for web gives managers a sense of "this isn't a one-way, I'm screwed if something goes wrong" journey

It wouldn't be a good idea to believe that though. Flutter website are just canvas paintings, and have nothing to do with the web. You can't add new html or js to it easily. can't make much use of new improvements in the web world.

Most importantly, if you are running a business, flutter web isn't really accessible, so please don't use it for any non internal tools

Or internal tools.

Internal tools should not exclude people needing accessibility features.

Dart actually has a lot of characteristics that make it appealing for a lot of the areas I'd have (begrudgingly) used Go - command-line tools or local utilities. It "can" be scripted, but also AOT compiles, has a saneish type system with generics, and doesn't have pointers to deal with. It's hard for me to want to use it on the web, but I keep watching it and wishing good things for it.

Dart produces surprisingly small docker images for server code. I recently created small Cloud Run web service with Dart - the docker image is 5.2MB compressed, 12.9 MB as reported by docker.

I'm not even sure Go would do better on image size. Tree shaking does wonders here.

> command-line tools or local utilities.

FFI is quite a PITA, though. Soomer or later you will have to interface some platform libraries, and Dart doesn't make that easy.

Curious what platforms you're interested in integrating with. We're experimenting here and looking for feedback. As a fun demonstration of the effectiveness of FFI, you can now build Petzold-style native Windows code with Dart: https://github.com/timsneath/win32/blob/master/example/hello...

And here's a 500-line version of the Kilo console text editor built with Dart: https://github.com/timsneath/dart_console/blob/master/exampl...

Unlike the original, it runs on both Windows and UNIX-based operating systems.

I'm actually more interested in Linux side of things. That doesn't prevent me from looking how things are done on Windows, of course.

To be fair, last time I looked into dart, the idea of FFI was ports, which was too overcomplicated and undercapable, if you needed something like Gtk or Vulkan. Looking into it now, I see the dart:ffi package is shaping up nicely, so I will have another look at dart again.

Tim, it should be possible that the main .exe (or binary on linux/osx) to export functions, and they can be found back through the flutter_engine.dll/.so, right? (At least on windows it's possible for the exe to __declspec(dllexport) things, not sure on Linux).

But even if not, if there is a way to (given might be slow and tedious) to compile what would've been flutter_engine.dll statically linked to your main (host) app, and maybe somewhat hinting here is how to find the "GetProcAddr/dlsym/etc." functions - if one is to look for them.

Further on, the generated from dart .so file can be embded (as resource? or slapped at the end of the binary/.exe?) + slapping all other resource - resulting in single app :)

I know it's possible, just not so easy to support it (I guess). It's similar to have java/python can be packed into one executable with all C/C++ ffi functions they call (at cost of some build time and effort to achieve so).

Then you'll have killer platform for video conferencing (zoom, bluejeans, etc.), messaging (slack, etc.) - and just single binary to deploy.

(Oh, on top of that slap a web server into it, and make it that if called with specific command-line option, now it acts as web-server, and the app is visible through the web).

> FFI is quite a PITA

This is what made me nope out of it last time I experimented with a Flutter module in my app. I'm still watching it closely though as it could be a great fit for other projects.

This might be outdated opinion (hard to tell without OP explaining what he finds "a PITA").

dart:ffi (https://dart.dev/guides/libraries/c-interop) is a recent addition to Dart and from where I stand it's a decent FFI system.

Maybe not as good as PInvoke in C# or ffi in luajit but better than, say, jni in Java (and any other FFI system that requires you to write glue code in C i.e. python, ruby, nodejs).

good thing to have in an FFI system is ability from one language to call another from callback, and back and forth (if it need to). I believe Dart allows for that. That to be said, stack walking is going to be painful to decode (probably), best I've seen is C#/C++ on Windows - where it flows naturally from one to another.

Thanks good to know, my experience was most likely outdated as well.

My experience with Flutter was that making the UI itself was pretty great. But making the rest of the app sucked. FFI support is bad. Platform channels are miserable. Doing it all in Dart is awful because there's no cheap concurrency - it's the same multi-heap with expensive "IPC" shittiness that you get with webworkers, but way less justified since you're nearly always on platforms with native threads. It's a huge pain to try and migrate piecemeal too, so if you have an existing app/codebase you're looking at a re-write.

UI performance was fine (not any better than native though), but RAM usage was pretty bad, a lot higher than native.

Really fantastic iteration workflow, though.

> Platform channels are miserable

ya, I hear you. It's a very common annoyance. We've been adding some support in the form of https://pub.dev/packages/pigeon to make the interop calls and data class passing more "direct".

disclosure: in the Flutter team

What I found ironical with flutter was, besides everything being a 'widget' in flutter it doesn't actually support creation of android widgets or iOS widgets[1].

And that I'm worried that Google might just pull the plug as I feel the community is not in the position to continue development without Google's involvement unlike React Native.

Also, I'm not entirely sure about the future of Dart language now that we have TypeScript. Overall I feel flutter to be a risky investment, I personally would rather develop PWA in-spite of Apple's explicit hurdles(which I think may change after couple of anti-trust litigations).

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

And except for windows..

Reply on news.ycombinator.com