42 ms·

Despite many maturity issues in practice Flutter is the only realistic option for true cross platform UIs that run everywhere. Apart from Qt , but the licensing

Despite many maturity issues in practice Flutter is the only realistic option for true cross platform UIs that run everywhere. Apart from Qt , but the licensing issue is a hindrance. And yes, the web backend isn't ideal, but it will improve over time. I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages. Dart isn't horrible and is getting better, but it is still a somewhat awkward mish mash of Java and JavaScript, and I don't really enjoy using it. The only reason to use Dart is Flutter, which really hurts ecosystem health / library availability and prevents code sharing with the backend.

mhoad 4y ago
For what it’s worth Dart is hands down the nicest OOP language I’ve ever used in my opinion. It’s like they took all the good things about JS and Java and cut out all the bad parts. What’s left is basically Dart.
- Mertax 4y ago
  I think the decision of which cross platform technology to use mostly depends on a team's preferred tech stack. C++ -> QT C#/.NET -> MAUI/Blazor JS/Web -> React.Native/Electron Dart -> Flutter This is what I think is holding back Flutter -- that it wasn't built on an incumbent technology. Because Dart doesn't have quite the following, it has to evangelize itself a bit more than the other options.
  - SemanticStrengh 4y ago
    note that many languages credibly interop with JS/TS nowadays
  - qalmakka 4y ago
    I've used PySide6 recently and I must say it's great, so you can also add Python to Qt's side.
  - orthecreedence 4y ago
    Rust -> ='[
    - nu11ptr 4y ago
      gtk-rs
    - sharno 4y ago
      https://iced.rs/ https://iced.rs/
    - ogoffart 4y ago
      Rust -> Slint? https://github.com/slint-ui/slint/ https://github.com/slint-ui/slint/
  - heavyset_go 4y ago
    Qt has some pretty good bindings for other languages other than C++.
  - francisl 4y ago
    Kotlin -> Jetpack Compose > Native Android, Native iOS (KMM) and soon Desktop+Web (Compose Multiplatform)
    - deleted 4y ago
      [deleted]
- SemanticStrengh 4y ago
  People being pleased with Dart is only because they have not tasted better, everything is relative. Kotlin is miles ahead.
  - mhoad 4y ago
    Yes, of course, everyone who disagrees with me is just an idiot who doesn’t know better. Excellent discourse.
    - SemanticStrengh 4y ago
      That's right, my discourse has no argumentative value. I do not advance any substance allowing you to agree or disagree. It's just a difference at the premise level, I have experienced dart and I have experienced Kotlin. Learn boths properly (reading the kotlin guide is sufficent and can be done in an afternoon) and then you will be able to judge if I was wrong or not. From experience, the difference is huge and affect every aspects/features of the language, without even talking about the JVM ecosystem interop.
      - mhoad 4y ago
        You seem to have a lot of very strongly held opinions in this thread that aren’t backed up by any evidence other than your personal opinion. It’s clear that Flutter wasn’t for you for whatever reason and you seem to love Iconic which is great but obsessively hanging out on this thread and just trying to shit all over it at every opportunity you get without citing any evidence is weird. Just go an enjoy Iconic. I don’t know why you keep trying to pick arguments with everyone here.
        SemanticStrengh 4y ago
        Sometimes people must be protected from themselves and from the delusions of misinformation. See a recent example of people having their lifes ruined because they have been fooled by the promise of a crypto stablecoin here https://www.reddit.com/r/TerraLuna/ https://www.reddit.com/r/TerraLuna/ I mean yes flutter or newShinyFrameworkX does not cause as much harm and it is much more subtle. But the platform does matter. We are building user experiences, things that people will experience, a LOT. Any non-web solution is much inferior in terms of feature completeness/expressivity, and conteary to popular belief, is inferior in performance and energy efficiency. So yes I might have commented too much in this thread but that is a political act in essence, trying to advocate for the serious trustable solution that receive the most human resources.
- toastal 4y ago
  > nicest OOP That's the thing. Dart is useless for my preferred style of programming. A modern language without ADTs and pattern matching is not even meeting my bare minimum for acceptable to use. Not just this, but the docs explicitly said the don't want these basic features.
  - mhoad 4y ago
    They are building pattern matching as we speak for what it’s worth. One of the main people designing it is in this thread talking about it.
    - mhoad 4y ago
      Thought this link might actually be more helpful by the way if you're interested but Dart team does all of their language design in the open on Github which is pretty cool and also gives you a lot of context about how things end up the way they do. I also mentioned elsewhere in the thread how impressed I was just watching that repo in general for a year. They clearly give a shit on a such a deep level about building a solid long term language in a way that I was totally unfamiliar with say coming from a Ruby background previously. Here is the section on pattern matching specifically https://github.com/dart-lang/language/tree/master/working/0546-patterns https://github.com/dart-lang/language/tree/master/working/05... and this is the design spec itself https://github.com/dart-lang/language/blob/master/working/0546-patterns/patterns-feature-specification.md https://github.com/dart-lang/language/blob/master/working/05...
eweise 4y ago
I don't know the history, but wouldn't Kotlin be a saner approach? Better language and at least native to android.
- SemanticStrengh 4y ago
  nowadays you can do web programming in KotlinTS
- NonNefarious 4y ago
sph 4y ago
I keep hearing this, but none of the cross platform apps I run use Flutter. It's all Electron and Qt. I don't think I've ever seen Flutter in the wild.
- brundolf 4y ago
  Or have you, and you just couldn't tell? (I personally don't know if it's this good, but it's plausible)
  - peterangular 4y ago
    Not OP - but almost all of the Flutter work I've ran into is mobile-centric. If you're looking for cross-platform on the desktop it really hasn't been a popular option vs. Electron/Qt.
    - qaq 4y ago
      Given that "Today, we are excited to announce that Flutter is now stable for macOS and Linux, in addition to Windows!" thats not surprising
      - peterangular 4y ago
        Of course, and to be clear I'm excited there are more cross-platform options even though I've had a reluctant history with Dart.
    - brundolf 4y ago
      I read "I don't think I've ever seen Flutter in the wild" to include mobile, but maybe I misinterpreted
- sarmasamosarma 4y ago
  I have a few apps out there and you can’t tell them apart from native. They are insanely snappy. Flutter is the bomb.
criddell 4y ago
> Flutter is the only realistic option for true cross platform UIs that run everywhere. Do you really want cross platform everywhere? You might want it but what you inevitably get is something that is huge and just okay everywhere instead of something truly great anywhere. Is that a trade off you are happy with as a user? That said, I do happily use a couple of cross platform applications. PyCharm and SublimeText which are great and Fusion 360 which is powerful but awful to use.
- SergeAx 4y ago
  We really want cross platform on Android and iOS. Windows and MacOS are nice to have, why not?
  - criddell 4y ago
    Who is “we”? As a user I want highly polished, efficient apps. That pretty much rules out anything built with a cross platform toolkit. (Games are a major exception.) As a developer, I personally want to make those kinds of programs too. I periodically check into the state of the cross platform toolkits and frankly they really aren’t any better than they were a decade ago. Separating out a UI layer that is unique in each platform helps and writing with native toolkits helps, but there are still fundamental differences that you can’t really abstract away. I think the biggest market for these toolkits is in enterprise software. There, lowering development costs seems to be more important than anything else.
    - mhoad 4y ago
      I think this assumption that cross platform UI solutions can’t be extremely fast is a very strange one. There have been some bad efforts at this in the past which is maybe how you arrived at the conclusion but the concept of Flutter is pretty straightforward and not dissimilar to games in some sense where you just need to push pixels to a screen. They even have a some game engineers who used to work at EA on the team. One even wrote a popular book on it https://gameprogrammingpatterns.com/ https://gameprogrammingpatterns.com/ Like in short, Flutter is going to be fine. It compiles to native code that just needs to push pixels to a screen, it has a bunch of smart people on it and some extremely heavy incentives to get this right.
mattsolle 4y ago
I thought I would hate Dart since it seems like such a bland language but after working in it for a year and a half its easily one of my favorites. Its straightforward and tailored directly for Flutter's use-cases. It feels like it doesn't come with a lot of the baggage you get with other, longer-lived languages. It is also incredibly readable without hiding how it works behind decades of syntactic sugar. All that to say, I definitely see how it can be disliked and I also disliked it when I started working with it but it definitely grew on me.
- KronisLV 4y ago
  > It feels like it doesn't come with a lot of the baggage you get with other, longer-lived languages. Doesn't this mean that you are currently simply in the sweet spot where the language is usable but also not bloated yet? As in, it could all change in a decade and therefore isn't an intrinsic quality of the language itself, but merely the passage of time. I recall this blog post exploring the possible correlation between the age of any programming language and the developers' disposition towards it: https://earthly.dev/blog/brown-green-language/ https://earthly.dev/blog/brown-green-language/
  - mhoad 4y ago
    This might not be obvious in anyway if you’re not pretty deep in the Dart ecosystem but I’ve never seen anyone pay as much attention about building a good long term language as that team. They put crazy amounts of thought and effort into how they evolve it. Their entire strategy as far as I know was to intentionally aim for “boring and predictable” so that no matter how large or complicated your application got that you would never outgrow it. Then they built a bunch of really nice tooling and DX on top of it. It’s genuinely a pleasure to work with in my experience.
- clumsysmurf 4y ago
  I was enjoying the frog book (The Dart Programming Language, Gilad Bracha & Erik Meiker) but that was 2015, and now very out of date. Its strange to see there is no up to date book from major publisher, like the Rust book at https://doc.rust-lang.org/book/ https://doc.rust-lang.org/book/
jackosdev 4y ago
I've had to bounce around from Mac, Windows and Linux for work, the main programs I use everyday are all Electron based (Postman, VS Code, Spotify etc), they all behave basically the same just everything is slower in Windows on my laptop. Egui (immediate mode GUI) and Tauri (like Electron but Rust backend) have worked well cross platform just messing around with them, but I haven't used any big apps yet to know for sure.
peterangular 4y ago
> Dart isn't horrible and is getting better, but it is still a somewhat awkward mish mash of Java and JavaScript, and I don't enjoy using it. All anecdotal: I've only met one person who was excited to work with Dart, huge Google fanatic/fanboy. Otherwise it's sorta seen as a unique language choice that makes other devs go, "oh..." The Java/ECMA ergonomics are weird, it's hard to find devs who have experience with the lang, and due to the language popularity there's a lot less community/3rd party deps available. I really tried hard to give it a fair shake back in the day but I just ended up sticking with Node (and now +Deno), Typescript, or Go if I need performance/types. There are way better ecosystems around these and I find the tooling/ergonomics much less awkward. Also, if/when I need to hire devs onto my teams I will have a much easier time. Also, I can actually write a serverless function in these tools (GCP Functions, AWS Lambda) - as far as I know there's nothing like this available for Dart. --- EDIT: It's worth mentioning I've only had Dart jammed down my throat on the backend (API's, data transforms, jobservers, etc). It may be a fine tool in regards with Flutter, but it felt like a really awkward tool for where it's come up in my career.
- sofixa 4y ago
  IIRC you can transpile Dart to JavaScript, so technically you can deploy it as serverless functions.
- JyB 4y ago
  I may be missing something, but why would you want to build a serverless function in Dart? you want a common backend/frontend language?
  - peterangular 4y ago
    I don't. It is one of my arguments against devs trying to bring Dart into solutions. Historically, I have had colleagues push to use Dart for backend/cloud/automation work which I personally disagree with.
  - mhoad 4y ago
    This is the entire reason for Node's existence no? Nobody who was in the backend space prior to it's arrival was in anyway excited about JS running in their servers. Node however allowed people with only front end experience to make that transition and start writing backend apps / logic / functions using the same language and now it's an insanely popular project. Wanting a common backend / frontend language seems like a perfectly reasonable goal especially on smaller teams. Dart has a LOT of catching up to do when it comes to the overall size of the ecosystem here to be fair because in reality as of right now 90% of the Dart community is just Flutter and nothing else. However, from a straight up language perspective it has a lot of big advantages over JS when it comes to writing backend code but close to zero momentum / adoption. It's a space I am currently very interested in personally because I feel like I see a path here that is currently more or less undiscovered. I would say the "secret" I have discovered to making it work thus far is very heavily tied to finding the right abstractions / entry points and caveating it with just like Node and any other backend stack it clearly isn't the right choice for all solutions. Where I ended up landing was basically: ===Front End=== Flutter for applications and Lit (different project not related to Dart / Flutter but TypeScript is VERY similar and a small team can handle both no problems) for websites. Flutter in particular if you are looking to do anything that isn't JUST web otherwise Lit might be a better choice currently for just web but I expect that calculus to possibly change in 2-3 years as Flutter's web support matures. ===Backend=== Went all in on Google Cloud stack, skipped K8s and instead went with Cloud Run. Only create a gRPC interface in my code but take advantage of the API gateway product to pick up the following benefits: - Natively integrates with Google's core service infrastructure so my code gets run the exact same way and with the exact same benefits as when I use a native Google API. This gets me all the same security, monitoring, tracing, serving, deployment etc out of the box with zero effort on my behalf. - Working with gRPC over handrolling JSON interfaces is night and day when it comes to both performance and developer experience. It's just better in every conceivable way. I don't write any manual glue code between my front and backend. Everything is autogenerated and typesafe. - Just to continue the gRPC story in general for a second, it also addresses one of the bigger limitations of Dart on the server which is that small ecosystem. The majority of things I need to integrate with now are other Google services which is supported both through an official autogenerated library (HTTP / JSON transport) but also I can just use the proto files Google provides to do a native gRPC integration if I wanted to. It does however also let me think about 3rd party integrations in a different way now. Let's take an example like Stripe. No native Dart library, no gRPC interface etc. One option is to just just HTTP and do it manually but I don't want to maintain that. Another low cost idea I have found for this kind of scenario is that it doesn't feel like a big deal to just break out that functionality into it's own service and take one of their well supported integration options like Node as an example. Take advantage of the fact that the SDK code continues to be maintained by Stripe and I only have to pick whatever calls I want and drop a gRPC interface on top of it that aligns with whatever functionality I want using a well established pattern so I don't have to do too much cowboy coding and I keep a clean separation of concerns in the process (https://martinfowler.com/articles/gateway-pattern.html https://martinfowler.com/articles/gateway-pattern.html) in practice I haven't had to do this much but if you have a lot of 3rd party services you are using that would be something to consider. - Also worth mentioning that making use of Google Cloud's API gateway (https://cloud.google.com/api-gateway https://cloud.google.com/api-gateway) also get's me a free JSON / REST <-> gRPC gateway for web along with a free gRPC-web <-> gRPC gateway which is a necessary feature until WebTransport (https://web.dev/webtransport https://web.dev/webtransport) makes native gRPC in the browser a viable option. - Because I am intentionally aligning myself against Google's native service infrastructure (it's pretty similar to the K8s one which is where it comes from but the key difference here is I don't touch any of the complexity myself) I pick up an amazing resource in terms of how to actually write and structure my APIs here https://google.aip.dev/ https://google.aip.dev/ which gives me a totally coherent set of standards and patterns no matter what I am writing. This keeps my entire backend horizontally scalable and aligned with all the relevant "cloud native" best practices by default. - Cloud Run and Cloud Native Buildpacks (https://buildpacks.io/ https://buildpacks.io/) get me a incredibly slick CI/CD pipeline that takes less than an hour to set up. The experience is basically Heroku where I just push code to the dev / non-dev / prod branch and everything just works. - The images I run are tiny, they are just a single binary compiled to native x86 code and placed inside a blank Docker image thanks to Buildpacks. Google maintains the image best practices for me so I never am touching Dockerfiles for example. Not only is start up time incredibly quickly (meaning I can now safely do scale to zero) but runtime performance is also great because again... it's native x86 code. - Managed services for everything else such as Firestore or managed Postgres for a DB, managed redis for caching etc.. - The security story is also amazing. Because Dart is a Google project and I am staying pretty strictly in the Google ecosystem I get signed binaries, signed images, a secure build environment, I get SBOMs (https://www.cisa.gov/sbom https://www.cisa.gov/sbom) in my container image (thanks to Buildpacks) so I know exactly what is running at any given point across time. The Google Build platform and Dart are also both converging on the SLSA standard (https://slsa.dev/ https://slsa.dev/) and will allow me to hit level 4 compliance by the end of the year. I rarely need a lot of 3rd party code dependencies (the difference here between Dart and Node in particular is absolutely wild). - The overall developer experience is also incredible. Dart and Flutter's tooling is genuinely first class. As I mentioned elsewhere a few times in this thread, Google's primary money making venture (Ads) is all Dart and as a result they have put a LOT of effort in at this level to keep things smooth and predictable. For example when new versions of the language roll out I just run a single command `dart fix` (https://dart.dev/tools/dart-fix https://dart.dev/tools/dart-fix) and it just upgrades my code for me with no work on my behalf to the latest best practices. There are a whole range of features like this that is just one of them but it helps demonstrate the kind of thing I am talking about. - Also keeping with the overall security / DX theme the developer onboarding story is also great. I don't have Flutter or Dart SDKs on my machine. I set up a VSCode devcontainer to create reproducible dev environments that just work. That clears up another whole set of potential problems for me if I want to do local development but it also allows me to sit down at ANY computer now and take advantage of Github's Codespaces and without any setup required I have a fully remote secure development environment. ===Wrap Up=== That's what fullstack Dart looks like for me currently as a solo developer. It get's me an incredibly slick setup that rivals most companies out there today. I didn't mention this in the post but I was also very intentional about building sensible escape hatches if I need to escape the GCP ecosystem for some reason. The upgrade path out of there is basically all of this can transfer to plain K8s if that is your thing and you have the resources to support it. I picked open source projects / standards wherever possible despite that initially reading as an incredibly Google focused stack which it also is to be fair. Also not covered here is the tension I guess between "microserves" and monoliths. I'm doing solo dev work so microservices don't make sense to me and I think are also just a dumb place to start in general. This let's me basically write this super nice combination between the two where I have a single API binary that contains multiple entry points "services in gRPC lingo" (roughly equivalent to "a group of routes in HTTP lingo") that really cleanly abstract out into their own thing as required. So for example let's say you were building a SaaS application the path to go from a single server / deployment running multiple "services" that covered everything from the apps core functionality to billing to admin stuff and to then split them back out into their own independent set of APIs (app-api, billing-api, admin-api) is really pretty trivial (mostly copying and pasting, no big code changes) and because I am using that native GCP service infrastructure the integration setup is tiny and not meaningfully different to say I wanted to bring in any other Google API to my codebase. But the important part to me here is that it gives me the time and space to find those abstractions as needed and not have to start there. My previous observations around people going from monolith to microservice is that it usually means a total rewrite and it's never feasible until things are seriously on fire and then it becomes a rush job and you end up with even more problems. This keeps the conceptual alignment from the start without needing to take on the risk and the complexity from day 1. It's a path that I think makes sense for everything from start ups to many companies doing serious growth numbers and let's you build consistent tooling / workflows around that. Honestly, it's worth exploring. Like I said, this is NOT at all a well documented path at the moment but I hope I find the chance to write about this more in the future because what I found so far has been nothing short of amazing.
curuinor 4y ago
they got clojuredart now, which is still kind of a fly-by-night thing but those Roam Research peeps are apparently using it in production https://github.com/Tensegritics/ClojureDart https://github.com/Tensegritics/ClojureDart (and in turn, clojure itself is a highly opinionated thing which isn't gonna turn into a blub that everyone uses...)
amelius 4y ago
> I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages. Any chance that someone will build a transpiler from e.g. Go or even Rust to Dart? Or is Dart too exotic to be used like that in a practical way?
- skybrian 4y ago
  Flutter and Dart have co-evolved to the extent that separating them would be difficult. One problem would be expressing the Flutter API as a Go API. For example, Flutter has lots of constructors with lots of keyword arguments. Flutter is doing things with keyword arguments that would be expressed as props in a React-style UI. A similar thing happened with JavaScript and JSX - while you can write a React-style UI without JSX, you probably wouldn't want to. Maybe you could define props using structs in Go, but the result would be awkward, particularly because Go doesn't have an easy way to bulk-copy fields from one struct to another, like you do with spread arguments in JavaScript. Also consider that Flutter uses class hierarchies extensively and Go doesn't have inheritance. Maybe look at how web development is done in Go when it's compiled to WebAssembly. Is that how you'd want to do web dev?
  - irq-1 4y ago
    > Go doesn't have an easy way to bulk-copy fields from one struct to another FYI, In Go you can embed one struct in another and the embedded fields are accessible from the top/parent struct. https://go.dev/doc/effective_go#embedding https://go.dev/doc/effective_go#embedding
SemanticStrengh 4y ago
> is the only realistic option for true cross platform UIs that run everywhere wtf.. Ionic/electron is the true cross platform, no debate. Flutter web is dog shit.
- danielvaughn 4y ago
  Ionic is pretty awful too, though I can't fault them. It's just that papering a web interface on top of a native app is gonna be a poor experience no matter what.
  - SemanticStrengh 4y ago
    sounds very unsubstantiated. please examplify, Ionic capacitor native support is excellent, in fact you can arbitrarilly call the android/IOS SDKs, with or without nativescript. You do understand there is no native difference between Ionic and flutter right?
    - danielvaughn 4y ago
      Not sure what kind of substantiation you're looking for, but I've been working with Ionic and Capacitor for over 6 months now, as part of an ongoing client project. Previously, I worked with Cordova way back in 2015/2016. So I'm familiar with the technology. My comment addressed the fact that I'm not criticizing the tech, I'm criticizing the overall concept - rendering an application inside of a web view as if it's a native app.
      - SemanticStrengh 4y ago
        I fail to see the issue here > rendering an application inside of a web view as if it's a native app. That doesn't mean anything. A native app doesn't mean anything. Native is a ad-hoc property of being the UX framework shipped by default on the OS On chromium OS, chrome is native. Who cares? What matters are the merits of framework x vs framework y. As for the graphical charts 1) material design is as well supported on the web 2) most apps should not be in material design if they want to have a personality. You said the word awful, don't you have concrete pain points?
michaelbrave 4y ago
I was thinking MAUI(rebranded Xamarin) might be somewhat useful with .NET6 coming out. I've been playing with it the last week or so, it's quite nice.
- heavyset_go 4y ago
  Pretty sure it excludes Linux as a GUI target.
  - JamesSwift 4y ago
    It has a Skia target (in Microsoft.Maui.Graphics) which is theoretically very similar to how Flutter does UI.
    - boondaburrah 4y ago
      Did they give up on GTK? I remember Suse Linux Enterprise in particular shipped with a bunch of nice .NET/GTK apps that seemed to work well.
      - pjmlp 4y ago
        They did. Gtk# hasn't seen updates in ages.
    - heavyset_go 4y ago
      Nice, thanks for the correction.
ttcbj 4y ago
I have been developing in Flutter for a few years now, and I really enjoy the ecosystem. It is the only mobile development environment I have every really enjoyed using. When I started, flutter worked on mobile, and web support was in beta. Now, my app works on iOS/Android/MacOs/Web. If you are a small developer with limited resources for cross-platform development, its an amazing environment. As for Dart, it is actually one of the things I like most about flutter. I really like the parameter passing/naming syntax. It is flexible and expressive. If you are looking for something that will challenge all your basic assumptions about what a language should be, you'll be disappointed. But if you come from any c-syntax background, you will pick it up almost instantly, and find a lot of nice ways to make code more concise and maintainable that previous languages. In my experience, Flutter is a great environment for getting things done with limited resources.
- busymom0 4y ago
  Is the Web version of Flutter still using canvas? I tried it a while back and it was just a canvas rendering everything. That makes SEO impossible. It's also useless for accessibility/screen readers. Please correct me if I am wrong.
  - divan 4y ago
    https://docs.flutter.dev/development/platform-integration/web/renderers https://docs.flutter.dev/development/platform-integration/we...
    - mattste 4y ago
      I'm curious if anyone can comment on their experience using the HTML renderer.
      - CrimsonRain 4y ago
        Very slow. Not yet ready for production.
  - 4y ago
samwillis 4y ago
> Flutter is the only realistic option for true cross platform UIs that run everywhere. I understand that argument but 100% disagree. The web is the cross platform that runs everywhere (as in in a browser or webview). True it has many issues and some forms of it (electron) are not ideal for some use case but I believe it’s a better platform than flutter in almost every way. You say “true” cross platform and could argue that the web isn’t “true” cross platform. But really is anything?
- FpUser 4y ago
  >"The web is the cross platform" Nope, The web is The Platform. And while it offers numerous benefits it has plenty of flaws / inability to do some things as well.
- LocalPCGuy 4y ago
  This 100%. Also, Flutter Web is still pretty much an abomination (right now), IMO. Sure, it "works". So did Flash. (edit: Just wanted to add, I love Flutter for mobile, even think desktop might work. Just don't think it's for web. Maybe for very specific app types.)
- deleted 4y ago
  [deleted]
- mekkkkkk 4y ago
  I have yet to see a world in which local file access, background services, local notifications, timers, alarms, native media controls, etc, works as well on web as in native apps. A lot of it is there "in theory", but web tech has the achilles heel of only allowing stuff that would be safe to have in a random website that some asshat links you on twitter. Of course this is only relevant if that deeper plumbing into the OS is needed, and of course it's quickly changing. Perhaps the day comes when web apps can truly be first class citizens in all major OSes, but it ain't here yet.
  - SemanticStrengh 4y ago
    You have yet to see a world where people update their beliefs more than once per decades. Hybrid native web apps are trivial, see e.g. Ionic capacitor plugins
jonahx 4y ago
> Despite many maturity issues in practice Flutter is the only realistic option for true cross platform UIs that run everywhere. What are your thoughts on flutter vs react native? (assuming you're only targeting phones)
- hunterb123 4y ago
  Not GP but my comparison is here: https://news.ycombinator.com/item?id=31346887 https://news.ycombinator.com/item?id=31346887
- mhoad 4y ago
  One anecdote that I find compelling here is looking at how each of the parent companies think of them. The majority of Google’s revenue is directly tied to their Ads platform. Their mobile app is written in Flutter and the web interface is written in Dart (not flutter as flutter web support is like around a year old). Facebook uses React on the web and abandoned react native on mobile. Both are responsible for billions of dollars but only one passed the test.
  - hunterb123 4y ago
    > Facebook uses React on the web and abandoned react native on mobile. That's not true, FB very much still uses RN on mobile.
    - mhoad 4y ago
      The Facebook app is not written in React Native. They tried it and famously abandoned it no?
      - hunterb123 4y ago
        The Marketplace tab in the FB app is written in React Native. The Ads Manager app is written in React Native. The Instagram app is written in React Native. The entire FB app is not written in React Native yet, but overtime I'd expect more things to be. The statement that FB "abandoned react native on mobile" is demonstrably false.
LocalPCGuy 4y ago
I still maintain that Flutter Web is not production ready. It could have a nice niche, like games. But for real apps, it's just not as good as web. They are still re-implementing things that have existed in the web for ages, and are not going to be able to keep up. It's basically good for an applet style usage IMO. I'll keep trying it out, I think Flutter is pretty great for mobile, even desktop, but every time I use a web app example I find issues and just shake my head at what they did.
- mekkkkkk 4y ago
  The way it atleast used to be framed is that web is a fallback target. Meaning if the target device isn't running Linux, Windows, macOS, iOS or Android (unlikely), then hey, you can atleast build a passable version that will run in a browser. I don't know if this has changed, but I know only a mad man would try to build a proper website in Flutter. It's not the tool for the job.
  - LocalPCGuy 4y ago
    No, it is 100% being framed as "You can build your app once and deploy it everywhere" with everywhere including web. It's sorta maddening, IMO. There are certain types of apps I could see using Flutter for (basically, ones that would lean heavily on canvas anyways, games, drawing, etc.)
    - mekkkkkk 4y ago
      It's hard to quantify exactly what "everywhere" means, but for the vast majority of end-user devices, you'll have a more efficient Flutter build target than web. You're probably right in that they are pushing the "first class web target" narrative a bit far, though.
      - LocalPCGuy 4y ago
        Just to be clear, I used the word everywhere. I believe they are quite a bit more explicit in framing it for all platforms, including web specifically. It's possible we'll see it get there, but I think there is a lot of things to do (and undo) to do that.
hunterb123 4y ago
I disagree, Flutter is probably the worst choice. React Native is the all around best choice for targeting all platforms natively, otherwise use pure web tech (Ionic + Electron) The desktop and web targets for Flutter are laughable in their current state. Completely unusable so I consider Flutter to be a mobile only platform at this time. Another downside is Flutter's emulated UI, it doesn't bridge to native controls like React Native, it's noticeable on iOS especially and will be hard to maintain the fake physics / styling. React Native is ready for production now for all platforms, including Windows & Xbox via react-native-windows, Web via react-native-web, MacOS via react-native-macos or Catalyst. Then there's the question as to why would you choose a Google only language and framework with their track record. With React you can use TypeScript or JS, you don't have to learn a new language or get locked into a framework.
- realusername 4y ago
  > React Native is ready for production now for all platforms, including Windows & Xbox via react-native-windows, Web via react-native-web, MacOS via react-native-macos or Catalyst. All platforms ... except Linux. React-native-gtk is abandoned as far as I know.
  - hunterb123 4y ago
    You can wrap the React Native Web target in Tauri or Electron for Linux. There's also https://github.com/valence-native/valence-native https://github.com/valence-native/valence-native that can use either wxWidgets or Qt. All in all it's better than the current Flutter web / desktop implementation.
    - realusername 4y ago
      > There's also https://github.com/valence-native/valence-native https://github.com/valence-native/valence-native that uses Qt. There's been more than a year without a commit in this project, I'm not going to say it's abandoned yet but that's not that far off I guess, good luck with the issues you'll encounter. > You can wrap the React Native Web target in Tauri or Electron for Linux. That's one of the only realistic solution for now in my opinion.
fmakunbound 4y ago
> I just wish Google had built Flutter on a low level core that isn't tied to Dart Why did they tie Flutter to Dart anyway?
- mhoad 4y ago
  Take a look at this video from the team that talks about this exact topic. After watching it initially it became very obvious to me why and I agree it was the right choice https://youtu.be/J5DQRPRBiFI https://youtu.be/J5DQRPRBiFI
ClumsyPilot 4y ago
> Dart isn't horrible and is getting better, but it is still a somewhat awkward mish mash of Java and JavaScript Sounds like they should have used TypeScript?
- maxloh 4y ago
  TypeScript isn't a language that can compile to machine code. It must be converted and distributed as JavaScript bundle, which is slow compared to Dart.
qalmakka 4y ago
> Apart from Qt, but the licensing issue is a hindrance Qt is LGPLv3, which is really a problem only if you plan to develop embedded software. Sure, there are a few GPL v3 modules here and there, but it's mostly very specific stuff (virtual keyboards, Wayland compositors, ...)
- NonNefarious 4y ago
  How is it not a problem if you want to sell closed-source software? I guess you can dynamically link desktop applications (although I'm not sure how this works in Apple's Mac app store), but you can't do that with mobile apps.
  - kevin_thibedeau 4y ago
    You can use LGPL with closed source so long as you provide object files to relink against.
  - pjmlp 4y ago
    If you to sell closed-source software be a good boy/girl and give part of the money pile to Qt developers, so that they keep working on Qt.
    - NonNefarious 4y ago
      And I do. I'm just saying that is not operating under GPL.
  - jcelerier 4y ago
    LGPL is not about dynamic linking, and there are plenty of LGPL (and even GPL) apps in the Apple, Android, Mac and Windows app stores. Like, Chromium itself is mostly LGPL and it's never an issue for electron apps, why would it be for Qt ones
    - NonNefarious 4y ago
      LGPL IS about dynamic linking if you don't want to release your source. That's the workaround.
robertlagrant 4y ago
I quite like Dart. I can't remember what they're called, but I remember it has something that lets you declare a stream (actually, maybe that's what it's called) that I thought was pretty ergonomic.
heavyset_go 4y ago
> Apart from Qt , but the licensing issue is a hindrance. Most of Qt is available under the LGPL. Some application specific libraries are available under the GPL, but there's no reason you'd need to use them unless you have special use cases that their libraries would make easier to handle. > I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages. Agreed, I figured that was the direction Flutter was going to go, with wrapper APIs for other languages, but it seems it never happened. Dart is okay, but it's not a language I'd choose to write anything in. The only reason to use it is because of Flutter, as you've said. In practice, it isn't just UI code that ends up getting written in Dart + Flutter, but the entire application and client code, excluding things like REST backends. With Qt's QML, you're very much just writing UIs in QML and JavaScript, leaving a clean separation between the UI, core, and application and client code.
- NonNefarious 4y ago
  We just built a desktop app with QML in a CMake-based Qt project, and I've been pleasantly surprised by the experience. Our brief experimentation with Qt Widgets, on the other hand, revealed a shocking level of dysfunction in basic UI-layout implementation, in what is supposed to be a very mature UI toolkit. But it seems that they're basically abandoning Widgets at this point, so ¯\_(ツ)_/¯.
  - jcelerier 4y ago
    So interesting, even after years of doing QML, layouting with widgets makes for me much simpler to get what I want
    - heavyset_go 4y ago
      QtQuick Controls 2's QML widgets, along with whatever KDE's MauiKit QML widgets are called now, might suit your needs.
      - jcelerier 4y ago
NonNefarious 4y ago
"I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages." Exactly. Dart is a deal-breaker. I was tasked with choosing a cross-platform development solution, and rejected Flutter because nobody at my company (including me) knows Dart or has time to learn it. Nor would any contractors we were likely to find know it. After quite a bit of research on other potential solutions, I determined (as did a crowded and lengthy thread in this forum) that Qt was the only viable one for now. The recent proliferation of languages has been pretty annoying. Google should have at least used Kotlin. Alienating their own community of Android developers and making Flutter a pain in the ass to integrate into a development organization was dumb. The other problem people cited with alleged cross-platform solutions is the need to write native code anyway if you need access to system/hardware resources (Bluetooth, USB, what have you).
- the_duke 4y ago
  To be fair: Dart is relatively straight forward and simple to learn. You should have decently qualified developers be productive within a week. But forcing a new language on people usually doesn't go well.
  - NonNefarious 4y ago
    Sure, I'm not trashing the language, because I know nothing about it. Our whole dev team is C/C++, with random people who know Python and a few other things. I'm the only one who knows Swift. They're bright people and not hostile toward new ideas, but they're already overtaxed and can't cater to an outlier project written in a language no one knows and built on a framework no one knows.
    - postalrat 4y ago
      - adwn 4y ago
        I really dislike C and C++, but I think your comment is needlessly hostile and insulting to C and C++ developers, and it doesn't add anything of value to this discussion. Please consider rewriting or deleting it.
gcanyon 4y ago
> only realistic option for true cross platform UIs that run everywhere Depending on your needs, Livecode has you covered. https://livecode.com https://livecode.com Runs on Mac, Windows, Linux. Delivers on all three, plus iOS and Android. The underlying language is patterned after HyperTalk and people either love it or hate it, but I haven't seen any other tool where you can open the new installation and within 2 minutes deliver single-file executables for three platforms. (Disclosure: I build a developer tool for Livecode)
perfopt 4y ago
I tried Flutter in 2020 for a side project but decided not to use it. It felt clunky and slow. I later ditched the side project also since I decided to not build any mobile Apps for now. Maybe I'll revisit Flutter if I ever consider building a mobile front end for any side-projects.
NtGuy25 4y ago
There's definitely competitors opening up and realizing the space is worth the investment. C# Maui for example, especially with Blazor, is extremely cross platform as well(including web), but it has full party support in C#.
no_wizard 4y ago
What about .NET with MAUI / Xamarin?
asiachick 4y ago
It's not remotely a realistic option. CJK is all second class citizen. I just tried their latest demos. Tried to enter 日本. It utterly failed. First it's still trying to draw on it's own so you get to see some placeholder □ while typing. Then, it effup and typing n-i-h-o-n kept producing Nいほん on this example https://gallery.flutter.dev/#/demo/cupertino-text-field https://gallery.flutter.dev/#/demo/cupertino-text-field As long as they keep insisting on rendering everything themselves instead of relying on the OS/DOM Flutter will always be a poor choice for UI
- cbracken 4y ago
  Thanks for reporting this. IME-based input is super important to me -- we only speak Japanese at home. I've filed a bug [1]. I manually tested on each of Windows, macOS, Linux, and iOS (where I've done a lot of work specific to CJK input) and was able to correctly input Japanese, Chinese, and Korean text [2], so looks like this is likely an issue specific to Flutter's web runtime. I work on Flutter's desktop embedders, but if there isn't someone who's a heavy IME user on the web team, I'll gladly give em a hand to help get this fixed. [1] https://github.com/flutter/flutter/issues/103645 https://github.com/flutter/flutter/issues/103645 [2] https://www.youtube.com/watch/0Bt-c9-h92c https://www.youtube.com/watch/0Bt-c9-h92c
  - asiachick 4y ago
    Fixing that one bug won't fix the plethora of issues * emoji is not the system emoji. * neither the browser's nor the OS's spelling error highlighting works (the place I have my own words registered) * reconvert and other IME options don't work just to name a few. Just please stop with the canvas rendering!
    - deleted 4y ago
      [deleted]
askonomm 4y ago
There's ClojureDart, which means you can now do Dart and Flutter development in Clojure: https://github.com/Tensegritics/ClojureDart https://github.com/Tensegritics/ClojureDart
- ducktective 4y ago
  Anyone has used this? Opinions?
  - askonomm 4y ago
    It's very new, like, a month or so old, but I'm seeing quite a few people experimenting with it already in the Clojure community. Roam Research (https://roamresearch.com/ https://roamresearch.com/) has their mobile apps built with it.
johnywalks 4y ago
> Dart isn't horrible Dart is horrible and the sole reason i don't touch Flutter
- zeroc8 4y ago
  What's so horrible about it? It's pretty much on par with Java and C#, but feels lighter, generates native Code and makes it easier to talk to C libs.
  - neoberg 4y ago
    not op but Java and C# are horrible, too.
aa-jv 4y ago
> realistic option for true cross platform UIs that run everywhere I switched from Flutter to JUCE and haven't looked back. Its a far better user experience, and a far better developer experience too. People often overlook it, because its pitched as a framework for Audio developers, but the work to make a truly operational cross-platform GUI has pushed it into 'suitable for normal application' territory, imho. Anyone looking to solve the platform issue would be very wise to do a few workbench sessions with JUCE, and to a lesser degree, the Godot gaming framework as well. These are perfectly cromulant ways to build high-performance, cross platform, accessible applications...

mhoad 4y ago

For what it’s worth Dart is hands down the nicest OOP language I’ve ever used in my opinion. It’s like they took all the good things about JS and Java and cut out all the bad parts. What’s left is basically Dart.

Mertax 4y ago
I think the decision of which cross platform technology to use mostly depends on a team's preferred tech stack. C++ -> QT C#/.NET -> MAUI/Blazor JS/Web -> React.Native/Electron Dart -> Flutter This is what I think is holding back Flutter -- that it wasn't built on an incumbent technology. Because Dart doesn't have quite the following, it has to evangelize itself a bit more than the other options.
- SemanticStrengh 4y ago
  note that many languages credibly interop with JS/TS nowadays
- qalmakka 4y ago
  I've used PySide6 recently and I must say it's great, so you can also add Python to Qt's side.
- orthecreedence 4y ago
  Rust -> ='[
  - nu11ptr 4y ago
    gtk-rs
  - sharno 4y ago
    https://iced.rs/ https://iced.rs/
  - ogoffart 4y ago
    Rust -> Slint? https://github.com/slint-ui/slint/ https://github.com/slint-ui/slint/
- heavyset_go 4y ago
  Qt has some pretty good bindings for other languages other than C++.
- francisl 4y ago
  Kotlin -> Jetpack Compose > Native Android, Native iOS (KMM) and soon Desktop+Web (Compose Multiplatform)
  - deleted 4y ago
    [deleted]
SemanticStrengh 4y ago
People being pleased with Dart is only because they have not tasted better, everything is relative. Kotlin is miles ahead.
- mhoad 4y ago
  Yes, of course, everyone who disagrees with me is just an idiot who doesn’t know better. Excellent discourse.
  - SemanticStrengh 4y ago
    That's right, my discourse has no argumentative value. I do not advance any substance allowing you to agree or disagree. It's just a difference at the premise level, I have experienced dart and I have experienced Kotlin. Learn boths properly (reading the kotlin guide is sufficent and can be done in an afternoon) and then you will be able to judge if I was wrong or not. From experience, the difference is huge and affect every aspects/features of the language, without even talking about the JVM ecosystem interop.
    - mhoad 4y ago
      You seem to have a lot of very strongly held opinions in this thread that aren’t backed up by any evidence other than your personal opinion. It’s clear that Flutter wasn’t for you for whatever reason and you seem to love Iconic which is great but obsessively hanging out on this thread and just trying to shit all over it at every opportunity you get without citing any evidence is weird. Just go an enjoy Iconic. I don’t know why you keep trying to pick arguments with everyone here.
      - SemanticStrengh 4y ago
        Sometimes people must be protected from themselves and from the delusions of misinformation. See a recent example of people having their lifes ruined because they have been fooled by the promise of a crypto stablecoin here https://www.reddit.com/r/TerraLuna/ https://www.reddit.com/r/TerraLuna/ I mean yes flutter or newShinyFrameworkX does not cause as much harm and it is much more subtle. But the platform does matter. We are building user experiences, things that people will experience, a LOT. Any non-web solution is much inferior in terms of feature completeness/expressivity, and conteary to popular belief, is inferior in performance and energy efficiency. So yes I might have commented too much in this thread but that is a political act in essence, trying to advocate for the serious trustable solution that receive the most human resources.
toastal 4y ago
> nicest OOP That's the thing. Dart is useless for my preferred style of programming. A modern language without ADTs and pattern matching is not even meeting my bare minimum for acceptable to use. Not just this, but the docs explicitly said the don't want these basic features.
- mhoad 4y ago
  They are building pattern matching as we speak for what it’s worth. One of the main people designing it is in this thread talking about it.
  - mhoad 4y ago
    Thought this link might actually be more helpful by the way if you're interested but Dart team does all of their language design in the open on Github which is pretty cool and also gives you a lot of context about how things end up the way they do. I also mentioned elsewhere in the thread how impressed I was just watching that repo in general for a year. They clearly give a shit on a such a deep level about building a solid long term language in a way that I was totally unfamiliar with say coming from a Ruby background previously. Here is the section on pattern matching specifically https://github.com/dart-lang/language/tree/master/working/0546-patterns https://github.com/dart-lang/language/tree/master/working/05... and this is the design spec itself https://github.com/dart-lang/language/blob/master/working/0546-patterns/patterns-feature-specification.md https://github.com/dart-lang/language/blob/master/working/05...

eweise 4y ago

I don't know the history, but wouldn't Kotlin be a saner approach? Better language and at least native to android.

SemanticStrengh 4y ago
nowadays you can do web programming in KotlinTS
NonNefarious 4y ago

sph 4y ago

I keep hearing this, but none of the cross platform apps I run use Flutter. It's all Electron and Qt. I don't think I've ever seen Flutter in the wild.

brundolf 4y ago
Or have you, and you just couldn't tell? (I personally don't know if it's this good, but it's plausible)
- peterangular 4y ago
  Not OP - but almost all of the Flutter work I've ran into is mobile-centric. If you're looking for cross-platform on the desktop it really hasn't been a popular option vs. Electron/Qt.
  - qaq 4y ago
    Given that "Today, we are excited to announce that Flutter is now stable for macOS and Linux, in addition to Windows!" thats not surprising
    - peterangular 4y ago
      Of course, and to be clear I'm excited there are more cross-platform options even though I've had a reluctant history with Dart.
  - brundolf 4y ago
    I read "I don't think I've ever seen Flutter in the wild" to include mobile, but maybe I misinterpreted
sarmasamosarma 4y ago
I have a few apps out there and you can’t tell them apart from native. They are insanely snappy. Flutter is the bomb.

criddell 4y ago

> Flutter is the only realistic option for true cross platform UIs that run everywhere. Do you really want cross platform everywhere? You might want it but what you inevitably get is something that is huge and just okay everywhere instead of something truly great anywhere. Is that a trade off you are happy with as a user? That said, I do happily use a couple of cross platform applications. PyCharm and SublimeText which are great and Fusion 360 which is powerful but awful to use.

SergeAx 4y ago
We really want cross platform on Android and iOS. Windows and MacOS are nice to have, why not?
- criddell 4y ago
  Who is “we”? As a user I want highly polished, efficient apps. That pretty much rules out anything built with a cross platform toolkit. (Games are a major exception.) As a developer, I personally want to make those kinds of programs too. I periodically check into the state of the cross platform toolkits and frankly they really aren’t any better than they were a decade ago. Separating out a UI layer that is unique in each platform helps and writing with native toolkits helps, but there are still fundamental differences that you can’t really abstract away. I think the biggest market for these toolkits is in enterprise software. There, lowering development costs seems to be more important than anything else.
  - mhoad 4y ago
    I think this assumption that cross platform UI solutions can’t be extremely fast is a very strange one. There have been some bad efforts at this in the past which is maybe how you arrived at the conclusion but the concept of Flutter is pretty straightforward and not dissimilar to games in some sense where you just need to push pixels to a screen. They even have a some game engineers who used to work at EA on the team. One even wrote a popular book on it https://gameprogrammingpatterns.com/ https://gameprogrammingpatterns.com/ Like in short, Flutter is going to be fine. It compiles to native code that just needs to push pixels to a screen, it has a bunch of smart people on it and some extremely heavy incentives to get this right.

mattsolle 4y ago

I thought I would hate Dart since it seems like such a bland language but after working in it for a year and a half its easily one of my favorites. Its straightforward and tailored directly for Flutter's use-cases. It feels like it doesn't come with a lot of the baggage you get with other, longer-lived languages. It is also incredibly readable without hiding how it works behind decades of syntactic sugar. All that to say, I definitely see how it can be disliked and I also disliked it when I started working with it but it definitely grew on me.

KronisLV 4y ago
> It feels like it doesn't come with a lot of the baggage you get with other, longer-lived languages. Doesn't this mean that you are currently simply in the sweet spot where the language is usable but also not bloated yet? As in, it could all change in a decade and therefore isn't an intrinsic quality of the language itself, but merely the passage of time. I recall this blog post exploring the possible correlation between the age of any programming language and the developers' disposition towards it: https://earthly.dev/blog/brown-green-language/ https://earthly.dev/blog/brown-green-language/
- mhoad 4y ago
  This might not be obvious in anyway if you’re not pretty deep in the Dart ecosystem but I’ve never seen anyone pay as much attention about building a good long term language as that team. They put crazy amounts of thought and effort into how they evolve it. Their entire strategy as far as I know was to intentionally aim for “boring and predictable” so that no matter how large or complicated your application got that you would never outgrow it. Then they built a bunch of really nice tooling and DX on top of it. It’s genuinely a pleasure to work with in my experience.
clumsysmurf 4y ago
I was enjoying the frog book (The Dart Programming Language, Gilad Bracha & Erik Meiker) but that was 2015, and now very out of date. Its strange to see there is no up to date book from major publisher, like the Rust book at https://doc.rust-lang.org/book/ https://doc.rust-lang.org/book/

jackosdev 4y ago

I've had to bounce around from Mac, Windows and Linux for work, the main programs I use everyday are all Electron based (Postman, VS Code, Spotify etc), they all behave basically the same just everything is slower in Windows on my laptop. Egui (immediate mode GUI) and Tauri (like Electron but Rust backend) have worked well cross platform just messing around with them, but I haven't used any big apps yet to know for sure.

peterangular 4y ago

> Dart isn't horrible and is getting better, but it is still a somewhat awkward mish mash of Java and JavaScript, and I don't enjoy using it. All anecdotal: I've only met one person who was excited to work with Dart, huge Google fanatic/fanboy. Otherwise it's sorta seen as a unique language choice that makes other devs go, "oh..." The Java/ECMA ergonomics are weird, it's hard to find devs who have experience with the lang, and due to the language popularity there's a lot less community/3rd party deps available. I really tried hard to give it a fair shake back in the day but I just ended up sticking with Node (and now +Deno), Typescript, or Go if I need performance/types. There are way better ecosystems around these and I find the tooling/ergonomics much less awkward. Also, if/when I need to hire devs onto my teams I will have a much easier time. Also, I can actually write a serverless function in these tools (GCP Functions, AWS Lambda) - as far as I know there's nothing like this available for Dart. --- EDIT: It's worth mentioning I've only had Dart jammed down my throat on the backend (API's, data transforms, jobservers, etc). It may be a fine tool in regards with Flutter, but it felt like a really awkward tool for where it's come up in my career.

sofixa 4y ago
IIRC you can transpile Dart to JavaScript, so technically you can deploy it as serverless functions.
JyB 4y ago
I may be missing something, but why would you want to build a serverless function in Dart? you want a common backend/frontend language?
- peterangular 4y ago
  I don't. It is one of my arguments against devs trying to bring Dart into solutions. Historically, I have had colleagues push to use Dart for backend/cloud/automation work which I personally disagree with.
- mhoad 4y ago
  This is the entire reason for Node's existence no? Nobody who was in the backend space prior to it's arrival was in anyway excited about JS running in their servers. Node however allowed people with only front end experience to make that transition and start writing backend apps / logic / functions using the same language and now it's an insanely popular project. Wanting a common backend / frontend language seems like a perfectly reasonable goal especially on smaller teams. Dart has a LOT of catching up to do when it comes to the overall size of the ecosystem here to be fair because in reality as of right now 90% of the Dart community is just Flutter and nothing else. However, from a straight up language perspective it has a lot of big advantages over JS when it comes to writing backend code but close to zero momentum / adoption. It's a space I am currently very interested in personally because I feel like I see a path here that is currently more or less undiscovered. I would say the "secret" I have discovered to making it work thus far is very heavily tied to finding the right abstractions / entry points and caveating it with just like Node and any other backend stack it clearly isn't the right choice for all solutions. Where I ended up landing was basically: ===Front End=== Flutter for applications and Lit (different project not related to Dart / Flutter but TypeScript is VERY similar and a small team can handle both no problems) for websites. Flutter in particular if you are looking to do anything that isn't JUST web otherwise Lit might be a better choice currently for just web but I expect that calculus to possibly change in 2-3 years as Flutter's web support matures. ===Backend=== Went all in on Google Cloud stack, skipped K8s and instead went with Cloud Run. Only create a gRPC interface in my code but take advantage of the API gateway product to pick up the following benefits: - Natively integrates with Google's core service infrastructure so my code gets run the exact same way and with the exact same benefits as when I use a native Google API. This gets me all the same security, monitoring, tracing, serving, deployment etc out of the box with zero effort on my behalf. - Working with gRPC over handrolling JSON interfaces is night and day when it comes to both performance and developer experience. It's just better in every conceivable way. I don't write any manual glue code between my front and backend. Everything is autogenerated and typesafe. - Just to continue the gRPC story in general for a second, it also addresses one of the bigger limitations of Dart on the server which is that small ecosystem. The majority of things I need to integrate with now are other Google services which is supported both through an official autogenerated library (HTTP / JSON transport) but also I can just use the proto files Google provides to do a native gRPC integration if I wanted to. It does however also let me think about 3rd party integrations in a different way now. Let's take an example like Stripe. No native Dart library, no gRPC interface etc. One option is to just just HTTP and do it manually but I don't want to maintain that. Another low cost idea I have found for this kind of scenario is that it doesn't feel like a big deal to just break out that functionality into it's own service and take one of their well supported integration options like Node as an example. Take advantage of the fact that the SDK code continues to be maintained by Stripe and I only have to pick whatever calls I want and drop a gRPC interface on top of it that aligns with whatever functionality I want using a well established pattern so I don't have to do too much cowboy coding and I keep a clean separation of concerns in the process (https://martinfowler.com/articles/gateway-pattern.html https://martinfowler.com/articles/gateway-pattern.html) in practice I haven't had to do this much but if you have a lot of 3rd party services you are using that would be something to consider. - Also worth mentioning that making use of Google Cloud's API gateway (https://cloud.google.com/api-gateway https://cloud.google.com/api-gateway) also get's me a free JSON / REST <-> gRPC gateway for web along with a free gRPC-web <-> gRPC gateway which is a necessary feature until WebTransport (https://web.dev/webtransport https://web.dev/webtransport) makes native gRPC in the browser a viable option. - Because I am intentionally aligning myself against Google's native service infrastructure (it's pretty similar to the K8s one which is where it comes from but the key difference here is I don't touch any of the complexity myself) I pick up an amazing resource in terms of how to actually write and structure my APIs here https://google.aip.dev/ https://google.aip.dev/ which gives me a totally coherent set of standards and patterns no matter what I am writing. This keeps my entire backend horizontally scalable and aligned with all the relevant "cloud native" best practices by default. - Cloud Run and Cloud Native Buildpacks (https://buildpacks.io/ https://buildpacks.io/) get me a incredibly slick CI/CD pipeline that takes less than an hour to set up. The experience is basically Heroku where I just push code to the dev / non-dev / prod branch and everything just works. - The images I run are tiny, they are just a single binary compiled to native x86 code and placed inside a blank Docker image thanks to Buildpacks. Google maintains the image best practices for me so I never am touching Dockerfiles for example. Not only is start up time incredibly quickly (meaning I can now safely do scale to zero) but runtime performance is also great because again... it's native x86 code. - Managed services for everything else such as Firestore or managed Postgres for a DB, managed redis for caching etc.. - The security story is also amazing. Because Dart is a Google project and I am staying pretty strictly in the Google ecosystem I get signed binaries, signed images, a secure build environment, I get SBOMs (https://www.cisa.gov/sbom https://www.cisa.gov/sbom) in my container image (thanks to Buildpacks) so I know exactly what is running at any given point across time. The Google Build platform and Dart are also both converging on the SLSA standard (https://slsa.dev/ https://slsa.dev/) and will allow me to hit level 4 compliance by the end of the year. I rarely need a lot of 3rd party code dependencies (the difference here between Dart and Node in particular is absolutely wild). - The overall developer experience is also incredible. Dart and Flutter's tooling is genuinely first class. As I mentioned elsewhere a few times in this thread, Google's primary money making venture (Ads) is all Dart and as a result they have put a LOT of effort in at this level to keep things smooth and predictable. For example when new versions of the language roll out I just run a single command `dart fix` (https://dart.dev/tools/dart-fix https://dart.dev/tools/dart-fix) and it just upgrades my code for me with no work on my behalf to the latest best practices. There are a whole range of features like this that is just one of them but it helps demonstrate the kind of thing I am talking about. - Also keeping with the overall security / DX theme the developer onboarding story is also great. I don't have Flutter or Dart SDKs on my machine. I set up a VSCode devcontainer to create reproducible dev environments that just work. That clears up another whole set of potential problems for me if I want to do local development but it also allows me to sit down at ANY computer now and take advantage of Github's Codespaces and without any setup required I have a fully remote secure development environment. ===Wrap Up=== That's what fullstack Dart looks like for me currently as a solo developer. It get's me an incredibly slick setup that rivals most companies out there today. I didn't mention this in the post but I was also very intentional about building sensible escape hatches if I need to escape the GCP ecosystem for some reason. The upgrade path out of there is basically all of this can transfer to plain K8s if that is your thing and you have the resources to support it. I picked open source projects / standards wherever possible despite that initially reading as an incredibly Google focused stack which it also is to be fair. Also not covered here is the tension I guess between "microserves" and monoliths. I'm doing solo dev work so microservices don't make sense to me and I think are also just a dumb place to start in general. This let's me basically write this super nice combination between the two where I have a single API binary that contains multiple entry points "services in gRPC lingo" (roughly equivalent to "a group of routes in HTTP lingo") that really cleanly abstract out into their own thing as required. So for example let's say you were building a SaaS application the path to go from a single server / deployment running multiple "services" that covered everything from the apps core functionality to billing to admin stuff and to then split them back out into their own independent set of APIs (app-api, billing-api, admin-api) is really pretty trivial (mostly copying and pasting, no big code changes) and because I am using that native GCP service infrastructure the integration setup is tiny and not meaningfully different to say I wanted to bring in any other Google API to my codebase. But the important part to me here is that it gives me the time and space to find those abstractions as needed and not have to start there. My previous observations around people going from monolith to microservice is that it usually means a total rewrite and it's never feasible until things are seriously on fire and then it becomes a rush job and you end up with even more problems. This keeps the conceptual alignment from the start without needing to take on the risk and the complexity from day 1. It's a path that I think makes sense for everything from start ups to many companies doing serious growth numbers and let's you build consistent tooling / workflows around that. Honestly, it's worth exploring. Like I said, this is NOT at all a well documented path at the moment but I hope I find the chance to write about this more in the future because what I found so far has been nothing short of amazing.

curuinor 4y ago

they got clojuredart now, which is still kind of a fly-by-night thing but those Roam Research peeps are apparently using it in production https://github.com/Tensegritics/ClojureDart https://github.com/Tensegritics/ClojureDart (and in turn, clojure itself is a highly opinionated thing which isn't gonna turn into a blub that everyone uses...)

amelius 4y ago

> I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages. Any chance that someone will build a transpiler from e.g. Go or even Rust to Dart? Or is Dart too exotic to be used like that in a practical way?

skybrian 4y ago
Flutter and Dart have co-evolved to the extent that separating them would be difficult. One problem would be expressing the Flutter API as a Go API. For example, Flutter has lots of constructors with lots of keyword arguments. Flutter is doing things with keyword arguments that would be expressed as props in a React-style UI. A similar thing happened with JavaScript and JSX - while you can write a React-style UI without JSX, you probably wouldn't want to. Maybe you could define props using structs in Go, but the result would be awkward, particularly because Go doesn't have an easy way to bulk-copy fields from one struct to another, like you do with spread arguments in JavaScript. Also consider that Flutter uses class hierarchies extensively and Go doesn't have inheritance. Maybe look at how web development is done in Go when it's compiled to WebAssembly. Is that how you'd want to do web dev?
- irq-1 4y ago
  > Go doesn't have an easy way to bulk-copy fields from one struct to another FYI, In Go you can embed one struct in another and the embedded fields are accessible from the top/parent struct. https://go.dev/doc/effective_go#embedding https://go.dev/doc/effective_go#embedding

SemanticStrengh 4y ago

> is the only realistic option for true cross platform UIs that run everywhere wtf.. Ionic/electron is the true cross platform, no debate. Flutter web is dog shit.

danielvaughn 4y ago
Ionic is pretty awful too, though I can't fault them. It's just that papering a web interface on top of a native app is gonna be a poor experience no matter what.
- SemanticStrengh 4y ago
  sounds very unsubstantiated. please examplify, Ionic capacitor native support is excellent, in fact you can arbitrarilly call the android/IOS SDKs, with or without nativescript. You do understand there is no native difference between Ionic and flutter right?
  - danielvaughn 4y ago
    Not sure what kind of substantiation you're looking for, but I've been working with Ionic and Capacitor for over 6 months now, as part of an ongoing client project. Previously, I worked with Cordova way back in 2015/2016. So I'm familiar with the technology. My comment addressed the fact that I'm not criticizing the tech, I'm criticizing the overall concept - rendering an application inside of a web view as if it's a native app.
    - SemanticStrengh 4y ago
      I fail to see the issue here > rendering an application inside of a web view as if it's a native app. That doesn't mean anything. A native app doesn't mean anything. Native is a ad-hoc property of being the UX framework shipped by default on the OS On chromium OS, chrome is native. Who cares? What matters are the merits of framework x vs framework y. As for the graphical charts 1) material design is as well supported on the web 2) most apps should not be in material design if they want to have a personality. You said the word awful, don't you have concrete pain points?

michaelbrave 4y ago

I was thinking MAUI(rebranded Xamarin) might be somewhat useful with .NET6 coming out. I've been playing with it the last week or so, it's quite nice.

heavyset_go 4y ago
Pretty sure it excludes Linux as a GUI target.
- JamesSwift 4y ago
  It has a Skia target (in Microsoft.Maui.Graphics) which is theoretically very similar to how Flutter does UI.
  - boondaburrah 4y ago
    Did they give up on GTK? I remember Suse Linux Enterprise in particular shipped with a bunch of nice .NET/GTK apps that seemed to work well.
    - pjmlp 4y ago
      They did. Gtk# hasn't seen updates in ages.
  - heavyset_go 4y ago
    Nice, thanks for the correction.

ttcbj 4y ago

I have been developing in Flutter for a few years now, and I really enjoy the ecosystem. It is the only mobile development environment I have every really enjoyed using. When I started, flutter worked on mobile, and web support was in beta. Now, my app works on iOS/Android/MacOs/Web. If you are a small developer with limited resources for cross-platform development, its an amazing environment. As for Dart, it is actually one of the things I like most about flutter. I really like the parameter passing/naming syntax. It is flexible and expressive. If you are looking for something that will challenge all your basic assumptions about what a language should be, you'll be disappointed. But if you come from any c-syntax background, you will pick it up almost instantly, and find a lot of nice ways to make code more concise and maintainable that previous languages. In my experience, Flutter is a great environment for getting things done with limited resources.

busymom0 4y ago
Is the Web version of Flutter still using canvas? I tried it a while back and it was just a canvas rendering everything. That makes SEO impossible. It's also useless for accessibility/screen readers. Please correct me if I am wrong.
- divan 4y ago
  https://docs.flutter.dev/development/platform-integration/web/renderers https://docs.flutter.dev/development/platform-integration/we...
  - mattste 4y ago
    I'm curious if anyone can comment on their experience using the HTML renderer.
    - CrimsonRain 4y ago
      Very slow. Not yet ready for production.
- 4y ago

samwillis 4y ago

> Flutter is the only realistic option for true cross platform UIs that run everywhere. I understand that argument but 100% disagree. The web is the cross platform that runs everywhere (as in in a browser or webview). True it has many issues and some forms of it (electron) are not ideal for some use case but I believe it’s a better platform than flutter in almost every way. You say “true” cross platform and could argue that the web isn’t “true” cross platform. But really is anything?

FpUser 4y ago
>"The web is the cross platform" Nope, The web is The Platform. And while it offers numerous benefits it has plenty of flaws / inability to do some things as well.
LocalPCGuy 4y ago
This 100%. Also, Flutter Web is still pretty much an abomination (right now), IMO. Sure, it "works". So did Flash. (edit: Just wanted to add, I love Flutter for mobile, even think desktop might work. Just don't think it's for web. Maybe for very specific app types.)
deleted 4y ago
[deleted]
mekkkkkk 4y ago
I have yet to see a world in which local file access, background services, local notifications, timers, alarms, native media controls, etc, works as well on web as in native apps. A lot of it is there "in theory", but web tech has the achilles heel of only allowing stuff that would be safe to have in a random website that some asshat links you on twitter. Of course this is only relevant if that deeper plumbing into the OS is needed, and of course it's quickly changing. Perhaps the day comes when web apps can truly be first class citizens in all major OSes, but it ain't here yet.
- SemanticStrengh 4y ago
  You have yet to see a world where people update their beliefs more than once per decades. Hybrid native web apps are trivial, see e.g. Ionic capacitor plugins

jonahx 4y ago

> Despite many maturity issues in practice Flutter is the only realistic option for true cross platform UIs that run everywhere. What are your thoughts on flutter vs react native? (assuming you're only targeting phones)

hunterb123 4y ago
Not GP but my comparison is here: https://news.ycombinator.com/item?id=31346887 https://news.ycombinator.com/item?id=31346887
mhoad 4y ago
One anecdote that I find compelling here is looking at how each of the parent companies think of them. The majority of Google’s revenue is directly tied to their Ads platform. Their mobile app is written in Flutter and the web interface is written in Dart (not flutter as flutter web support is like around a year old). Facebook uses React on the web and abandoned react native on mobile. Both are responsible for billions of dollars but only one passed the test.
- hunterb123 4y ago
  > Facebook uses React on the web and abandoned react native on mobile. That's not true, FB very much still uses RN on mobile.
  - mhoad 4y ago
    The Facebook app is not written in React Native. They tried it and famously abandoned it no?
    - hunterb123 4y ago
      The Marketplace tab in the FB app is written in React Native. The Ads Manager app is written in React Native. The Instagram app is written in React Native. The entire FB app is not written in React Native yet, but overtime I'd expect more things to be. The statement that FB "abandoned react native on mobile" is demonstrably false.

LocalPCGuy 4y ago

I still maintain that Flutter Web is not production ready. It could have a nice niche, like games. But for real apps, it's just not as good as web. They are still re-implementing things that have existed in the web for ages, and are not going to be able to keep up. It's basically good for an applet style usage IMO. I'll keep trying it out, I think Flutter is pretty great for mobile, even desktop, but every time I use a web app example I find issues and just shake my head at what they did.

mekkkkkk 4y ago
The way it atleast used to be framed is that web is a fallback target. Meaning if the target device isn't running Linux, Windows, macOS, iOS or Android (unlikely), then hey, you can atleast build a passable version that will run in a browser. I don't know if this has changed, but I know only a mad man would try to build a proper website in Flutter. It's not the tool for the job.
- LocalPCGuy 4y ago
  No, it is 100% being framed as "You can build your app once and deploy it everywhere" with everywhere including web. It's sorta maddening, IMO. There are certain types of apps I could see using Flutter for (basically, ones that would lean heavily on canvas anyways, games, drawing, etc.)
  - mekkkkkk 4y ago
    It's hard to quantify exactly what "everywhere" means, but for the vast majority of end-user devices, you'll have a more efficient Flutter build target than web. You're probably right in that they are pushing the "first class web target" narrative a bit far, though.
    - LocalPCGuy 4y ago
      Just to be clear, I used the word everywhere. I believe they are quite a bit more explicit in framing it for all platforms, including web specifically. It's possible we'll see it get there, but I think there is a lot of things to do (and undo) to do that.

hunterb123 4y ago

I disagree, Flutter is probably the worst choice. React Native is the all around best choice for targeting all platforms natively, otherwise use pure web tech (Ionic + Electron) The desktop and web targets for Flutter are laughable in their current state. Completely unusable so I consider Flutter to be a mobile only platform at this time. Another downside is Flutter's emulated UI, it doesn't bridge to native controls like React Native, it's noticeable on iOS especially and will be hard to maintain the fake physics / styling. React Native is ready for production now for all platforms, including Windows & Xbox via react-native-windows, Web via react-native-web, MacOS via react-native-macos or Catalyst. Then there's the question as to why would you choose a Google only language and framework with their track record. With React you can use TypeScript or JS, you don't have to learn a new language or get locked into a framework.

realusername 4y ago
> React Native is ready for production now for all platforms, including Windows & Xbox via react-native-windows, Web via react-native-web, MacOS via react-native-macos or Catalyst. All platforms ... except Linux. React-native-gtk is abandoned as far as I know.
- hunterb123 4y ago
  You can wrap the React Native Web target in Tauri or Electron for Linux. There's also https://github.com/valence-native/valence-native https://github.com/valence-native/valence-native that can use either wxWidgets or Qt. All in all it's better than the current Flutter web / desktop implementation.
  - realusername 4y ago
    > There's also https://github.com/valence-native/valence-native https://github.com/valence-native/valence-native that uses Qt. There's been more than a year without a commit in this project, I'm not going to say it's abandoned yet but that's not that far off I guess, good luck with the issues you'll encounter. > You can wrap the React Native Web target in Tauri or Electron for Linux. That's one of the only realistic solution for now in my opinion.

fmakunbound 4y ago

> I just wish Google had built Flutter on a low level core that isn't tied to Dart Why did they tie Flutter to Dart anyway?

mhoad 4y ago
Take a look at this video from the team that talks about this exact topic. After watching it initially it became very obvious to me why and I agree it was the right choice https://youtu.be/J5DQRPRBiFI https://youtu.be/J5DQRPRBiFI

ClumsyPilot 4y ago

> Dart isn't horrible and is getting better, but it is still a somewhat awkward mish mash of Java and JavaScript Sounds like they should have used TypeScript?

maxloh 4y ago
TypeScript isn't a language that can compile to machine code. It must be converted and distributed as JavaScript bundle, which is slow compared to Dart.

qalmakka 4y ago

> Apart from Qt, but the licensing issue is a hindrance Qt is LGPLv3, which is really a problem only if you plan to develop embedded software. Sure, there are a few GPL v3 modules here and there, but it's mostly very specific stuff (virtual keyboards, Wayland compositors, ...)

NonNefarious 4y ago
How is it not a problem if you want to sell closed-source software? I guess you can dynamically link desktop applications (although I'm not sure how this works in Apple's Mac app store), but you can't do that with mobile apps.
- kevin_thibedeau 4y ago
  You can use LGPL with closed source so long as you provide object files to relink against.
- pjmlp 4y ago
  If you to sell closed-source software be a good boy/girl and give part of the money pile to Qt developers, so that they keep working on Qt.
  - NonNefarious 4y ago
    And I do. I'm just saying that is not operating under GPL.
- jcelerier 4y ago
  LGPL is not about dynamic linking, and there are plenty of LGPL (and even GPL) apps in the Apple, Android, Mac and Windows app stores. Like, Chromium itself is mostly LGPL and it's never an issue for electron apps, why would it be for Qt ones
  - NonNefarious 4y ago
    LGPL IS about dynamic linking if you don't want to release your source. That's the workaround.

robertlagrant 4y ago

I quite like Dart. I can't remember what they're called, but I remember it has something that lets you declare a stream (actually, maybe that's what it's called) that I thought was pretty ergonomic.

heavyset_go 4y ago

> Apart from Qt , but the licensing issue is a hindrance. Most of Qt is available under the LGPL. Some application specific libraries are available under the GPL, but there's no reason you'd need to use them unless you have special use cases that their libraries would make easier to handle. > I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages. Agreed, I figured that was the direction Flutter was going to go, with wrapper APIs for other languages, but it seems it never happened. Dart is okay, but it's not a language I'd choose to write anything in. The only reason to use it is because of Flutter, as you've said. In practice, it isn't just UI code that ends up getting written in Dart + Flutter, but the entire application and client code, excluding things like REST backends. With Qt's QML, you're very much just writing UIs in QML and JavaScript, leaving a clean separation between the UI, core, and application and client code.

NonNefarious 4y ago
We just built a desktop app with QML in a CMake-based Qt project, and I've been pleasantly surprised by the experience. Our brief experimentation with Qt Widgets, on the other hand, revealed a shocking level of dysfunction in basic UI-layout implementation, in what is supposed to be a very mature UI toolkit. But it seems that they're basically abandoning Widgets at this point, so ¯\_(ツ)_/¯.
- jcelerier 4y ago
  So interesting, even after years of doing QML, layouting with widgets makes for me much simpler to get what I want
  - heavyset_go 4y ago
    QtQuick Controls 2's QML widgets, along with whatever KDE's MauiKit QML widgets are called now, might suit your needs.
    - jcelerier 4y ago

NonNefarious 4y ago

"I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages." Exactly. Dart is a deal-breaker. I was tasked with choosing a cross-platform development solution, and rejected Flutter because nobody at my company (including me) knows Dart or has time to learn it. Nor would any contractors we were likely to find know it. After quite a bit of research on other potential solutions, I determined (as did a crowded and lengthy thread in this forum) that Qt was the only viable one for now. The recent proliferation of languages has been pretty annoying. Google should have at least used Kotlin. Alienating their own community of Android developers and making Flutter a pain in the ass to integrate into a development organization was dumb. The other problem people cited with alleged cross-platform solutions is the need to write native code anyway if you need access to system/hardware resources (Bluetooth, USB, what have you).

the_duke 4y ago
To be fair: Dart is relatively straight forward and simple to learn. You should have decently qualified developers be productive within a week. But forcing a new language on people usually doesn't go well.
- NonNefarious 4y ago
  Sure, I'm not trashing the language, because I know nothing about it. Our whole dev team is C/C++, with random people who know Python and a few other things. I'm the only one who knows Swift. They're bright people and not hostile toward new ideas, but they're already overtaxed and can't cater to an outlier project written in a language no one knows and built on a framework no one knows.
  - postalrat 4y ago
    - adwn 4y ago
      I really dislike C and C++, but I think your comment is needlessly hostile and insulting to C and C++ developers, and it doesn't add anything of value to this discussion. Please consider rewriting or deleting it.

gcanyon 4y ago

> only realistic option for true cross platform UIs that run everywhere Depending on your needs, Livecode has you covered. https://livecode.com https://livecode.com Runs on Mac, Windows, Linux. Delivers on all three, plus iOS and Android. The underlying language is patterned after HyperTalk and people either love it or hate it, but I haven't seen any other tool where you can open the new installation and within 2 minutes deliver single-file executables for three platforms. (Disclosure: I build a developer tool for Livecode)

perfopt 4y ago

I tried Flutter in 2020 for a side project but decided not to use it. It felt clunky and slow. I later ditched the side project also since I decided to not build any mobile Apps for now. Maybe I'll revisit Flutter if I ever consider building a mobile front end for any side-projects.

NtGuy25 4y ago

There's definitely competitors opening up and realizing the space is worth the investment. C# Maui for example, especially with Blazor, is extremely cross platform as well(including web), but it has full party support in C#.

no_wizard 4y ago

What about .NET with MAUI / Xamarin?

asiachick 4y ago

It's not remotely a realistic option. CJK is all second class citizen. I just tried their latest demos. Tried to enter 日本. It utterly failed. First it's still trying to draw on it's own so you get to see some placeholder □ while typing. Then, it effup and typing n-i-h-o-n kept producing Nいほん on this example https://gallery.flutter.dev/#/demo/cupertino-text-field https://gallery.flutter.dev/#/demo/cupertino-text-field As long as they keep insisting on rendering everything themselves instead of relying on the OS/DOM Flutter will always be a poor choice for UI

cbracken 4y ago
Thanks for reporting this. IME-based input is super important to me -- we only speak Japanese at home. I've filed a bug [1]. I manually tested on each of Windows, macOS, Linux, and iOS (where I've done a lot of work specific to CJK input) and was able to correctly input Japanese, Chinese, and Korean text [2], so looks like this is likely an issue specific to Flutter's web runtime. I work on Flutter's desktop embedders, but if there isn't someone who's a heavy IME user on the web team, I'll gladly give em a hand to help get this fixed. [1] https://github.com/flutter/flutter/issues/103645 https://github.com/flutter/flutter/issues/103645 [2] https://www.youtube.com/watch/0Bt-c9-h92c https://www.youtube.com/watch/0Bt-c9-h92c
- asiachick 4y ago
  Fixing that one bug won't fix the plethora of issues * emoji is not the system emoji. * neither the browser's nor the OS's spelling error highlighting works (the place I have my own words registered) * reconvert and other IME options don't work just to name a few. Just please stop with the canvas rendering!
  - deleted 4y ago
    [deleted]

askonomm 4y ago

There's ClojureDart, which means you can now do Dart and Flutter development in Clojure: https://github.com/Tensegritics/ClojureDart https://github.com/Tensegritics/ClojureDart

ducktective 4y ago
Anyone has used this? Opinions?
- askonomm 4y ago
  It's very new, like, a month or so old, but I'm seeing quite a few people experimenting with it already in the Clojure community. Roam Research (https://roamresearch.com/ https://roamresearch.com/) has their mobile apps built with it.

johnywalks 4y ago

> Dart isn't horrible Dart is horrible and the sole reason i don't touch Flutter

zeroc8 4y ago
What's so horrible about it? It's pretty much on par with Java and C#, but feels lighter, generates native Code and makes it easier to talk to C libs.
- neoberg 4y ago
  not op but Java and C# are horrible, too.

aa-jv 4y ago

> realistic option for true cross platform UIs that run everywhere I switched from Flutter to JUCE and haven't looked back. Its a far better user experience, and a far better developer experience too. People often overlook it, because its pitched as a framework for Audio developers, but the work to make a truly operational cross-platform GUI has pushed it into 'suitable for normal application' territory, imho. Anyone looking to solve the platform issue would be very wise to do a few workbench sessions with JUCE, and to a lesser degree, the Godot gaming framework as well. These are perfectly cromulant ways to build high-performance, cross platform, accessible applications...