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.
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.
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.
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.
> 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/
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.
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/
The incentive structures around technical books are pretty weird.
Most major publishers pay quite small royalty rates, so even a popular tech book won't actually make the author much money. And the effort to write a good technical book is pretty huge. Also, the set of people who will actually finish writing a book is quite a bit smaller than the set of people who aspire to. (An editor at O'Reilly told me once that only about 1/3 of the authors they sign deals with actually end up finishing the book.)
So for a book to appear, you need to find someone who:
1. Knows this particular topic in depth.
2. Is interested in spending a lot of time writing a book about it.
3. For relatively little money in return.
4. And actually has the discipline to finish it.
Not a lot of people in that set. It's also particularly hard for technologies that are in flux since the quicker the book gets out of date, the less value there is in writing it.
Former O'Reilly editor here: story checks out. The 1/3 might be a bit low -- I had some surprises (one guy joined the Peace Corps and moved to South America, plus usual divorces and deaths and job changes) but it felt more like 80% completed. This might be the rosy glasses of memory, though.
There's also a weird difference in incentive between writing the first edition and working on updates: if the author was just after "I wrote a book!" then they already have that, and won't be so interested in updating.
If they were made famous and now have a lot of work as a result of the first book, they may not have time for it. It's quite the delicate dance to get someone else to update the book: without the update, sales will drop, but 1st edition authors feel weird giving a lot of their (not sizable) royalties to someone who didn't write most of the text.
That is fascinating. As someone who has writing a technical book as a life goal, I'd love to ask--do you have any insights you'd be willing to share regarding how to get started?
Are you already blogging? If not, I would start doing that. Writing short form technical articles and sharing them is like bootcamp for longer form writing. You'll learn the mechanics of organizing thoughts into a linear narrative, the discipline to finish, and you'll get feedback from readers about what works and what doesn't.
I blogged for a few years (and wrote thousands and thousands of comments on Reddit, which was also helpful) before I wrote a book.
Alternative to (3) - Company that owns a language and is willing to pay decent money for someone qualified to write a book in order to increase popularity
Yeah, this is viable, but the cost is quite high if you're paying a skilled software engineer for their time. The company driving the language can probably spend that budget better elsewhere. (For example, on online documentation that is more easily incrementally maintained and grown.)
Picking it up is really easy if you have any experience with Java or C# and the QOL improvements compared to the former make it seem like a treat for me. What language are people who hate it coming from?
> 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?
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.
“Everything” working in a web app is unlikely to happen any time soon. The security model is so different, though less different between mobile and web than mobile and desktop. Also the Apple/Safari ecosystem is the new IE and dragging down some of the innovation.
However, I believe it might not matter. 95% apps can be done as web apps today, especially what comes to boring business applications. 5% we can wait for some time.
What comes to Flutter, it can never integrate well within a browser as it sufferes from the same issue as Java applets. It does not use the web browser native rendering engine and widgets will always feel kludgy, have accessibility issues and so on. Not a big deal for some apps like games. And Google Docs is already using Canvas based rendering so seems like Flutter canvas based apps might have hope.
That plumbing is there and easily doable, but up to Apple… just like how the proliferation of QR codes in America didn’t happen until Apple decided to include it in the camera app. It (QR codes) was widely used for maybe almost a decade in China due to inclusion in the ubiquitous Wechat app.
However given the app store is a cash cow for Apple I highly doubt they’d want to integrate web more deeply.
Notifications is the main one which is still missing (at least on iOS, not sure about android). If notifications are possible for websites, then it would make web dev so much better for vast majority of apps.
Local storage already does a lot of needed data storage (though apple has recently made this complicated with their auto delete after certain period). Local file access for uploads is also now possible on iOS using the Files app.
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
I'm well aware of hybrid apps and Ionic. I wouldn't call those solutions properly "web" though. They're basically only using web tech as a presentation layer, and deferring to native plugins to do the heavy lifting when required. Very similar to how Flutter does it.
So if your claim is simply that CSS/HTML/JS is capable of creating good user interfaces, I'm not arguing against it.
> a presentation layer, and deferring to native plugins to do the heavy lifting when required
bruh it's not just UI, the JS/TS code is where the business logic code is. And anyway the UI is the whole point, we are debating UI libraries.
But most importantly native plugins are niche, you use them very rarely and for very specific needs, they occupy generally less than 1-5% of the code base.
e.g. when you need to access the camera or sensors, which you usually don't need and most apps don't actually benefit from plugins.
I'm not even talking about the fact that most of those niche needs are generally covered by equivalent modern web APIs (e.g. web share) but since plugins are trivial to use, people often use them even when a web api already exist.
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.)
> The web is the cross platform that runs everywhere (as in in a browser or webview).
I understand that argument but 100% disagree. Development is horrible, it's anything but standard, comes with a lot of baggage, the performance is atrocious. It doesn't even run anywhere, it runs in a browser. A huge, bloated, hungry browser.
You say Electron is not ideal, I say it's the worst thing that had happened to desktop computers ever. It's bad for the planet too. Some argue that without "js on desktop" we wouldn't have these amazing apps. I think it's not worth it to have those apps if they are built using those technologies. They make me miserable every single day. It's the only thing that forces me to upgrade my computer. It's so bad. Things that were possible 20 years ago are suddenly an unachievable goal. Stop it.
I may have very different uses for my PC than you (I use it primarily for gaming and my job as a game developer), but I find the notion of having to upgrade your PC to run a browser-based application very strange.
I am not saying that electron-based apps are generally good or efficient. Most of them are frustratingly slow and awkward. But this inefficiency rarely seems to be constrained by local resources: the apps often stand still, consuming barely any resources (CPU time, memory, etc.) and taking ages to load each page. At the same time you can often visit the same page in Chrome and it will load almost instantly.
It is frustrating and I have no idea what is going on, but it doesn't seem like upgrading the PC would solve the issue.
I came here to say this too. Build your app as a website, then just use a simple browser window of an app that loads your site. Then you only develop in one place, and have nothing to compile or build. Hardly ever have to update your "app" builds even. This won't replace every app of course depending on what you're trying to do and if it requires specific hardware features, but I'd say about 99% of apps don't need to be native.
> The web is the cross platform that runs everywhere (as in in a browser or webview)
Yes, but the web is crappy system for designing UIs in.
As a community we've got good at designing UIs with web technologies (HTML+CSS), because we have no other choice if you want to build web-apps. But the level of experience we've gained with those tools has hidden the fact that they have some real issues - mostly due to the fact that they've developed piecemeal over many years. Getting the layout of your page to behave correctly under all the circumstances it needs to requires a lot of experience with CSS, a lot of simple page behaviour we'd now expect as users require adding JS sprinkled around (and I'm not talking app logic, just UI logic).
I freely admit that I'm not great with CSS - I'm not a web developer although I have done some web development. If I do any at work (e.g. web UI for embedded device) I need a pro to come along and make things look nice. But when I did app development in Flutter it took about 2 days to be able to build screens that looked good, did complicated dynamic behaviour, and behaved reliably regardless of screen size and shape.
Interesting, I've had the opposite experience. I'd love to develop in native with something like Flutter or React Native, but I find CSS to be much easier and more flexible to use. The base components always /seem/ flexible enough until I want to do something visually complicated like add an animation that blurs an image on hover. I know CSS is horrendous in consistency, but it's piecemeal development has led to it having every UI feature I could really want/need now that I've paid the price and met its learning curve.
For what it’s worth CSS is all I knew prior to Flutter so the learning curve was a bit weird initially but once you start matching concepts you already know like Flutter also has “flexbox” for example it was pretty easy from there. Also having a strongly typed language with great docs is a huge help.
I wish this were true, but in my (admittedly limited) research I'm not sure it is.
For one, you mention Electron. That targets all desktop platforms, but not mobile. Mobile development from webapps is absolutely possible, but you need to use something else for that. Meanwhile, on the flutter side of things, if you want to target desktop platforms, you use flutter. If you want to target mobile platforms, you use flutter. There isn't a need to learn a whole new framework to target a new platform.
Aside from that, local file storage and offline use can also be a bit finnicky with Electron. Absolutely possible, but its another thing you have to figure out that Flutter just does by default.
If I'm wrong on any of this, please do let me know, I know web dev far better than I know Flutter so it'd make my life a lot easier, but the above reasons are why flutter hasn't budged from my todo list
Other than what sibling comments said, I have to add that flutter is much more approachable for new developers than web is. Most widgets are built-in, and development workflow is also simpler. This is what I heard from college students.
"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).
I think that's pretty short-sighted. Dart is hardly an esoteric/niche language like Haskell or Futhark, anyone familiar with Java/Javascript/TypeScript should be able to pick it up in a day or so.
Flutter's performance issues, on the other hand, is a separate story.
Knowing nothing about Dart, I'd guess learning the language itself is not much of a task, but learning the libraries, build tools, and the whole ecosystem would take a while.
I don't think that's accurate. Seems like native apps have the best performance but Flutter comes a close second. React native on the other is much slower:
This has been a long-standing issue that has completely ruled out Flutter for us. E.g, the Flutterfolio idle login screen uses 14% CPU on my Mac. For a while it sounded like Google was saying that it can't be fixed. But I think they have done some work to address this issue. I'll be very interested in finding out whether it has been fixed in Flutter 3.
I think this might be a bit of an outlier honestly.
Reading the bug report my takeaways were the following:
1. Here is a specific issue we ran into which to be fair is unacceptable in terms of perf but a blinking cursor in an otherwise idle application has crazy high CPU usage numbers trying to run the animations associated with the blinking cursor.
2. They tried the same thing on Linux and CPU usage was 0% so already it appears this is more of a specific mac bug rather than some general widespread thing.
3. Further in the thread a number of potential solutions get mentioned and were under development including just writing a custom shader to handle the blinking cursor (so a solution looks possible)
They just made Mac desktop support stable as of less than 24 hours ago for the first time. None of this strikes me as that egregious. A whole number of major perf improvements have landed since then and it's not even clear if this is still an active problem in Flutter 3.
I think trying to extrapolate this one bug into some widespread disaster scenario is a mistake.
I don't know if there is a larger issue because this show stopping "outlier" has stopped me from exploring Flutter any further. I'll give it another try now that a new major version has been released.
The question in my mind is whether Flutter is consistently and significantly more resource efficient than web technologies for my particular use cases.
Hey there. I'm an engineer working on Flutter Desktop. We're definitely aware of the macOS cursor behaviour issue and are looking at ways we can fix it. We haven't landed anything (that I'm aware of) that should improve this for 3.0, but if it helps, it's something that's actively on our radar and we've discussed potential fixes for. One potential solution is to implement a custom shader [1].
While I understand this may be a dealbreaker issue for your use-case, we've been pretty busy getting a few higher-priority (overall) issues fixed (universal binary support, CJK text input, key event APIs, etc.) prior to 3.0, but we'll get to this.
Flutter and Dart seemed to have been internal tools built by engineers looking for an interesting project to spend their time on while at Google.
Kotlin swelled up around the limitations of Java 8 in outside organizations and took over the ecosystem so Android devs could be productive while Google was fighting with Oracle
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.
Speaking from personal experience I found the process of using dart to be VERY painless. I'm mostly a web developer, but have taken some Java courses in college and have dabbled in a bit of C# outside of my normal PHP/JS work.
We decided to take on an app project at work. We had made one using nativescript-vue, but the experience left much to be desired and I wanted to look for alternatives.
A friend had talked favorably about Flutter so I decided to install and check it out. Within a few hours, I had a pretty good looking MVP of the app we were building (it was very basic to begin with). The experience developing a Flutter
app was really good.
It felt like I already knew the language from the get go. It worked pretty much as expected. I only had to google things like async/await because dart writes their functions like `(arg) async => expr` while javascript puts the async before the function `async arg => expr`.
YMMV if you're not using the languages which Dart draws inspiration from I guess. But I'dd be surprised if you feel you would need to spend significant amount of time learning Dart.
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.
I wrote extensive amount of Dart without even reading documentation and any prior Dart experience. Knowing dart is never an issue if you know basic Java/Php/JavaScript.
The only thing I really hated about Dart was poor enum support. Now that's fixed.
> 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.
As an early Flutter adopter, the ecosystem was a big problem, and while it seems to have progressed, it's still pretty anemic compared to other language's ecosystems.
> Google Cloud Functions does not currently provide an officially supported Dart language runtime, but we're working to make running on Google Cloud Run as seamless and symmetric an experience as possible for your Dart Functions Framework projects.
It's not natively supported - runs on Google Cloud Run instead.
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.
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) 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) 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) 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/ 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/) 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) 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/) 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) 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.
It has been out for a serious while though, just in a very high quality beta. I've personally been using it just fine, though for nothing too complicated
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.
FWIW I kind of agree and I’m a big fan of both Flutter and the web in general.
There are a couple of web platform technologies that I think are going to take Flutter web from ok to great in the next year or two including.
WASM Garbage Collection is going to allow them to move from compiling to JS to WASM. They have already built a WASM compiler ready to go when it lands.
WebGPU is another obvious one. Flutter is by definition a canvas optimised framework rather than strictly DOM based (although they support that too as a target). But they should be able to get blazing fast canvas rendering with those two technologies alone.
The other big one that I think will help them is going to be AOM. Lots of the built in browser accessibility stuff was built for a DOM based world, the web platform needs better primitives to support canvas frameworks too.
Yah, this is a pretty solid list of things that, if they all hit and work as we hope they do, it could enable building things with tech like Flutter and having it work well. I think that's why I generally say FlutterWeb isn't production ready and not that it'll never be. I don't care for the path they took originally, it feels like a bandaid and has a lot of issues. They may get there eventually, and I'll be happy to adjust my position when/if they do.
I’m betting on Flutter web across a 2-3 year timeframe but none of the things I’ve listed there are conceptual ideas that are only going to land in the distant future.
WebGPU and WasmGC are both already implemented in most browsers and are currently just behind a flag as far as I know.
It doesn’t feel like magical thinking to me at all, it’s a pretty clear path forward IMO.
Oh, I do mostly agree with you that it isn't magical thinking. I do think there were some choices made that might make it a bit more difficult to switch, but the Flutter team has been willing to make big shifts in the past.
Personally, I'm not willing to be on Flutter Web right now, and as you can see, I still actively dissuade it's use as I don't think it's good for the web as it is. But that doesn't mean that in a few years I'll think differently.
Isn’t Dart a very JS-like language? I really don’t believe that compiling to JS would cause any bottlenecks at all, like compiling Java to JS is also possible with Google’s own Closure compiler which produces crazy fast JS output.
Sure, JS is not a good compilation target but if you have a sufficiently similar language it is not too hard, and with the man-hours spent on JS JIT-compilers these won’t be slow at all.
Though surely the render codepath could use wasm, but that could be written natively as well without a need for GC.
As for WebGPU, I don’t think a web app would be okay with the latency of compiling shaders. Not sure whether it will be needed, or if it can be cached but it is not a trivial win either.
For the record Dart has something extremely similar to the Closure compiler built with the same ideas and similar performance AFAIK.
It’s totally fine, impressive even and currently runs the code producing the majority of their revenue via Ads which is all Dart.
But they also recognise (same with Google’s Java teams) that as the platform landscape is changing WASM with garbage collection should be the “next generation” of compile targets for the web for those languages for performance reasons. Both Java and Dart teams already have compilers ready to go once WasmGC is finalised and both of those teams are heavily involved in the standards team driving the broader effort.
I saw some hints at I/O about them building something called “managed languages” into the browser that covered both Dart and Java as well which seems to build on top of that.
I think this has some broader implications for the JS community as a whole for what it’s worth where “compile to JS” is no longer the only game in town in the near future.
As for WebGPU I don’t know enough about the internals to get real deep on the topic but they already have all those problems today but just with WebGL. This too as I understand things is just the “next generation” target for that code.
They (Flutter team) are also rewriting their entire shader pipeline engine from scratch as we speak to take advantage of everything they have learned to date.
In short, I believe them when they say it’s going to be fast and like native.
Edit: I missed your point initially about they could use WASM today. They do that also for parts of the code already (underlying graphics engine is C++ not Dart) but this allows them to move all of the Dart code to WASM now too.
> Flutter is by definition a canvas optimised framework
Not really, flutter has not the resources to develop their own 2D renderer so they use the chromium renderer for drawing. (Skia). It is canvas-like, everything is canvas-like at low level. But flutter like browsers implement retained mode rendering which is necessary for being jank free and have low energy consumption. Flutter on web canvas cannot properly do retained mode rendering.
spoiler, flutter non-web is generally slower than Ionic
CanvasKit still renders to canvas (maybe that's what you meant by "canvas-like", but it is still directly drawing to an HTML canvas), it just enables Flutter to utilize a more advanced feature set than the DOM canvas API. It also comes with a 2MB or so download (which is why by default it's off on mobile last I checked).
you did not understand my point, canvaskit is skia but slower, over wasm. It output to an HTML canvas and HTML canvas are immediate mode, they do not have retained mode rendering (display lists, occlusion, caching, etc).
Besides I don't think canvaskit is faster than regular HTML canvas. Even if canvaskit might avoid some compute that would normally be done at the HTML canvas level, canvaskit could implement retained mode rendering but 1) it does not 2) it would not really be appropriate because of the unstructured API (unlike DOM), 3) the final HTML canvas would still behave immediately.
As I said, it's important to realize that you are rendering skia (html canvas) on skia (canvaskit wasm) the amount of overhead and rendering duplication is in theory crazy.
SEO is important for websites which for the record you 100% should not use Flutter for.
Flutter is a great fit for applications which (and I say this as someone who did SEO for fortune 500s for many years) aren’t really all that relevant for SEO purposes and are difficult to index at best.
But the short answer to your question is the accessibility object model API is what gets used to surface relevant information that could be used by search engines along with all the other things that have nothing to do with the stuff that sits inside your body tags. Like it wouldn’t actually be that different IRL.
Important for web apps or websites? There's a difference, a product's landing page will need SEO, definitely, but the app itself, ie app.example.com, likely does not need SEO. For example, an easy example is Figma. The landing page is built with HTML, CSS and JS, but the actual app itself is actually built with WASM [0], very similar to the canvas based implementation of Flutter apps.
I'm not sure there's a good distinction between web apps or websites today.
Would you consider Instagram or Twitter a website or a web app?
If I type 'IG ${username}' or 'Twitter ${username}' or '@${username}' in a search engine, you should expect what is to be expected within the first result.
True, if the app needs SEO, then yes it should be built with HTML, CSS and JS, and not Flutter which uses a canvas element. However, there are many apps where SEO is unneeded, such as Figma above (no one will search for your company's design files on Google) or other such corporate apps, and that's where Flutter comes in handy.
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.
I’ve encountered a Flutter web app exactly once, https://app.travellerdeclaration.govt.nz/. It was very painful. (Part of the pain was related to them using a selectable-button style for radio buttons, which isn’t entirely Flutter’s fault, though I bet it contributed to that misguided decision; but when there’s no scrollbar and the Yes/No button you clicked is at the very bottom of the visible page—well, that was the position.) When I filled it out last year, they had an alternative, vastly better accessible version that I think didn’t even require JavaScript, though good luck finding it, since it was accessed by an invisible button that Flutter event handling made unfocusable. Now that button sets a flag in sessionStorage and reloads, and on startup checks for the flag and sets flutterWebRenderer = "html", so that at least the content is in the accessibility tree, even if they still badly reimplement half the stuff the browser provides manually (links, focus, scrolling, they even damage bits of IME).
That was painful indeed! Why you would use Flutter for something that seems to be web-only, and on a govt website that presumably values accessibility, is beyond me.
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.)
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.
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.
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.
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.
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.
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.
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.
Someone else told him he should disclose that he works for Ionic and he’s claiming that he doesn’t work there. I don’t buy it, because the CEO of Ionic himself responded to me in this thread with some equally dismissive comments. Really weird behavior and it makes the Ionic team look super thin-skinned.
No, the ionic CEO yesimahunan often comment on HN and give generally neutral statements.
I am sick of people ignorance in GUI rendering engines and the religious myths they build over native, so I actively comment too because online GUI conversations are still on a middle age like era. If I wzs tied to Ionic I would try to please people, which I don't.
In fact Ionic communication has often self victimized itself by corroborating the native rendering myth in lany of their blogs.
The internet and HN indeed is a small place and seeing the Ionic CEO and one of the only person with expertise in 2D GUI renderers (me) on thr flutter 3.0 announcement is actually, not unlikely. But it surprises because on average on the internet, people don't care to push depth/accuracy into discussions.
BTW I am capable of pointing flaws in Ionic, the documentation on the web is often not up to date, and inn general I would much prefer a Kotlin based GUI framework (such as jetpack compose) over a JS framework (ionic).
I am in fact the only person on HN to have an actual argument to defend a true Ionic competitor, based either on fastuidraw, piet-gpu or gecko but there's no point in discussing this given no one could contribute to the discussion.
fwiw I totally agree with your other comment on the insanity of CanvasKit. I'm just digging into low-level rendering myself, and immediately thought...wait, so you're writing in Skia, only to be compiled into WASM, feeding into a 2D canvas context, which is rendered by...Skia? tf?
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/
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.
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
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.
> 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.
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 ¯\_(ツ)_/¯.
> 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.
That matches my experience. Getting Qt Widgets to resize in an even remotely sane way proved to be just about impossible.
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/) has their mobile apps built with it.
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.
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?
> 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...
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.
> 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.
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.
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/
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.
As a user, I want native apps with some added value compared to web apps. I don't actually care about "polished", 60fps and things like that. So we are in a different camps.
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.
Every experience I had with React Native was truly horrible.
Gigantic, messy JS dependency tree. Constant build breakages after minor version updates. Random flakiness. Unmaintained or buggy native plugins. Questionable support for issues that didn't affect FB.
That's the story with Javascript in general, the tooling is just terrible.
This is one of the underappreciated part of flutter, 4 months of upgrade take me 30min of work and the hot reload just works, good luck with that in the JS world.
> I never really have issues with the JS side of things, care to elaborate on what specifically is "terrible"?
Packages are usually poorly tested (and the fact that it's dynamic language does not help), upgrades are often and painful, the tooling is not very stable in my opinion.
Before settling for Flutter, I've made a limited version of my app in both ecosystem to try both and on the RN one, I already had upgrade issues only after a month...
> Generally what breaks RN is the same stuff that breaks Flutter, native tooling like CocoaPods, Gradle, etc.
You need much less native tooling in Flutter since almost everything is canvas based. Broken stuff on the native part is very rare, I can't really remember anything like this from the past 3 years. I had to upgrade the graddle version once but that's about it.
I have ~30k lines of dart excluding tests and about 15 lines of Kotlin (and zero in ios), that's the kind of ratio we're talking about.
Just in general? I don't know of any packages in my app that are poorly tested. Simply do not choose dependencies that don't meet your standard, whether it's TS or Dart.
> and the fact that it's dynamic language does not help
Most packages nowadays are written with TypeScript or Flow. JS itself is fast and stable thanks to the billions put into the VMs.
> upgrades are often and painful
You don't have to upgrade. In the early days things were more painful, but I've upgraded the past few major React and RN versions with no hassle.
> the tooling is not very stable in my opinion.
Seems stable to me since the last couple years.
Personally the apps that Flutter makes are of worse quality vs RN apps. Emulated native will always feel cheap compared to real OS controls.
> Just in general? I don't know of any packages in my app that are poorly tested. Simply do not choose dependencies that don't meet your standard, whether it's TS or Dart.
In general, it's not really part of the js culture. Sure you have those very nice packages which have stellar dev practices (such as react) but that's far from the norm.
The testing story also feels better with Flutter to me, one nice thing about the canvas based rendering is that you have very good and useful screenshot testing.
> You don't have to upgrade. In the early days things were more painful, but I've upgraded the past few major React and RN versions with no hassle.
If you don't upgrade, you're left behind and it will become more and more painful to upgrade later. Upgrade policies of languages also have to be taken into account for the dev time.
> Personally the apps that Flutter makes are of worse quality vs RN apps. Emulated native will always feel cheap compared to real OS controls.
No mainstream app is using native controls anyways. Facebook doesn't, Twitter doesn't, Whatsapp doesn't...
Additionally, if you have a terrible phone, this is where Flutter stands out in terms of speed. That's why it's so popular in developing countries. On my Galaxy J3 (bottom of the barrel of samsung), my app is the fastest app I have installed.
> In general, it's not really part of the js culture
As opposed to the Dart culture? Quite a sweeping generalization. There's bad packages in every ecosystem. There's really good packages in every system. Pick the right ones.
> one nice thing about the canvas based rendering is that you have very good and useful screenshot testing.
React you can snapshot test the component tree, as well as diff images on each platform.
> If you don't upgrade, you're left behind and it will become more and more painful to upgrade later. Upgrade policies of languages also have to be taken into account for the dev time.
Sure, I update major versions every year or so. Past 2 years of React Native have been easy.
> No mainstream app is using native controls anyways. Facebook doesn't, Twitter doesn't, Whatsapp doesn't...
That's plain false, they for sure do.
> Additionally, if you have a terrible phone, this is where Flutter stands out in terms of speed. That's why it's so popular in developing countries. On my Galaxy J3 (bottom of the barrel of samsung), my app is the fastest app I have installed.
React Native performs well on older devices as well.
> As opposed to the Dart culture? Quite a sweeping generalization. There's bad packages in every ecosystem. There's really good packages in every system. Pick the right ones.
Not every ecosystem is created equal, they are better testing cultures than dart (such as ruby for example) but they are also worse ones and javascript is definitely worse at that.
Packages you install will be on average less tested and less care will be put into the dev experience than in some other languages.
They are exceptions of course such as RN & React but they are far outside the norm.
> Sure, I update major versions every year or so. Past 2 years of React Native have been easy.
As with any other JS project, RN and React are not the main issue but everything around it is and you certainly need extra packages.
> That's plain false, they for sure do.
Have a look at those apps and tell me if they look Material (they don't).
Highly recommend trying expo.dev sometime they have come a long way in providing support for native modules and take care of all that underlying "mess" for you.
I absolutely agree with this. At this point I don't really think there's much reason to _not_ use Expo. I found setting up RN without Expo absolutely awful, and switching to Expo was the only reason I didn't start rebuilding my app in Kotlin+Swift.
> 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.
Politely, I would point out that the makers of Ubuntu have said that as far as they are concerned Flutter is the future of desktop app development on Linux and all their projects moving forward will be using it by default because they believe in it so much.
They just started in Ubuntu 22.04 by rewriting their installer (I.e the very first thing users see when coming into contact with Ubuntu) to be a Flutter app.
It has proper first class support rather than the hacky and unofficial (and possibly poorly maintained) workarounds you suggested to do cross platform development.
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.
> 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.
Or it's stable? Look at the codebase, it's a pretty dead simple bridge. Make your app open source and all those Linux devs you're supporting can help you out!
> That's one of the only realistic solution for now in my opinion.
Yup, and you get it for free with if you build your app with RN and React Native Web.
> Or it's stable? Look at the codebase, it's a pretty dead simple bridge. Make your app open source and all those Linux devs you're supporting can help you out!
Even the simplest bridge needs upgrades, unless you want to be stuck with react 16.
> Yup, and you get it for free with if you build your app with RN and React Native Web.
That's better than nothing I'd say yeah. That's kind of the issue with react native, you need platform-specific rendering code and since companies don't really care that much about linux desktop it's not really there.
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.
I have never seen anyone statically linking Qt anywhere, even with a commercial license. The main issue is iOS, where it's basically impossible to ship anything (L)GPLv3 on the app store, but that's due to Apple's lock-in policies.
Also, JNI requires you to use DLLs/shared objects, so you definitely can use them on Android.
> I have never seen anyone statically linking Qt anywhere, even with a commercial license.
from a quick grep on my hard drive, Telegram and QBittorrent statically link against Qt on Windows ; my own software also does, on all platforms. I assume there are others.
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
It seems unlikely that FB would give up on Litho, which is extremely performance focused, to use react native instead. Not for their bread & butter flagship news feed anyway https://fblitho.com/
First, both Litho and React Native build on Yoga so there's a fair amount of code sharing.
Second, they serve different purposes. Litho will be used for FB scale optimization of certain intensive views. React Native is used for fast developer productivity. I'd wager that RN will be used in most places and Litho is used in hot spots sparingly.
If I’m wrong then I’m happy to admit it. I don’t follow that ecosystem closely and was only going off a few old blog posts I remember and everyone making a big deal of it at the time.
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.
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#.
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
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.
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.
I don't think that's how Ionic developers would describe it today. Have you actually used it or Capacitor recently? The quality of apps being built on the platform has never been higher. (one random example: https://reflect.app)
For what it's worth I'm an Ionic developer and I find the grand-parent's description pretty accurate. I do like Capacitor though, but I think that's mostly because I've had to deal with Cordova before.
I feel like I'm having a deja-vu. I remember having a similar discussion in the past and it turns out it happened exactly one year ago when Flutter 2 was released: https://news.ycombinator.com/context?id=26336657
Every framework has bugs and feature requests that are fighting for resources. And the ones affecting you _always_ seem more important than the ones that don't.
That being said, the fact that memory leaks in widely used components (e.g.: `<ion-img>` [1]) go mostly unnoticed both by Ionic developers and by the community [2] just doesn't give me confidence in Ionic being a framework used to build quality apps.
[1] - https://github.com/ionic-team/ionic-framework/issues/19242#issuecomment-556182556
[2] - the issue linked above has 5 upvotes in 3 years and no one even bothered to report a separate issue for the memory leak in `<ion-img />`, which seems even more serious and the developers have been made aware of it
> the issue linked above has 5 upvotes in 3 years and no one even bothered to report a separate issue for the memory leak in `<ion-img />`
It looks like you answered yourself, this issue does not seem to affect people.
Either it is a rare intermittent or only happen in very specific configurations, either there is a leak but it is negligeable, or shortlived.
OR maybe this leak cause suboptimal performance but it must not be "feelable" although you did a great find, this issue has been overlooked and its severity should be better investigated. I'd like to remind you that Ionic is not the point, Ionic is simply a packaging of good practices and optimized components (because yes ion-img implement important optimizations over a normal img tag). Some might have leaking issues but the point is that you can trivially use a standard img tag, or a regular react/angular image lazy loading library or even better https://chromestatus.com/feature/5637156160667648
The web BTW will probably be the first ecosystem to provide support for JPEG XL images, which are a significant evolution in performance.
Compare the discussed underinvestigated suboptimality with e.g. this 50% CPU increase over a trivial GIF, and mostly ignored/delayed https://github.com/flutter/flutter/issues/88858 or even https://github.com/flutter/flutter/issues/94205
> Every framework has bugs and feature requests that are fighting for resources.
relativism has its limits, chromium has thousands more human resources than flutter and react native devs combined
welcome back,
about the issue you mentioned, one of the original author wrote a blog in how to address it and how the issue is related to angular.
https://github.com/ionic-team/ionic-framework/issues/25283
It does make a significant difference in profiling though
I have been working with it recently, yes. Again, I'm not criticizing their tech, moreso the underlying idea - rendering a webview as if it's a native app.
Seeing the quality of apps coming from the community especially with the latest updates in Ionic 6, I can’t agree with your framing at all. The team is highly receptive to specific feedback if you have anything we should improve or GitHub links
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?
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.
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?
Just a hint: if you work for Ionic it's customary on HN to disclose that fact.
Also: what makes a framework "native" for me is that it has it's own rendering stack. With webview solutions you are still facing cross platform inconsistencies between Safari/iOS, Android and Electron.
I am not an Ionic employee, I have zero affiliation. I am a hobbyist in GUI rendering libraries technologies, which include Skia, blend2d, pathfinder, webrender, piet-gpu, etc
> what makes a framework "native" for me is that it has it's own rendering stack
lel, the point of react native is exactly that it doesn't have its own rendering stack, it defer rendering to external rendering stacks (android native lib, swift native lib)
Flutter and the web are not native and are not different. They both have their own custom rendering stack, which allow them to improve it.
flutter has not created its own 2d renderer btw, it uses the chromium 2D renderer named skia, in fact android native use the chromium 2D renderer since a few versions already. Simply because its the fastest to exist.
> With webview solutions you are still facing cross platform inconsistencies
crazy how reversed with reality your argument is. React native is by design inconsistent, it uses a separate library for each platform which result in an impedence mismatch of features, performance, and bugs.
A webview has no inconsistencies between android and electron, it's the same chromium behind. Safari is slighly inconsistent (webkit) but order of magnitudes less than using a completely different library.
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)
I was recently tasked to build a mobile app at my work, that would have maybe 5% of the feature-set of our gargantuan web product. However, this 5% was mission critical. Coming from React-TS, building with Flutter was a bit weird at first (where's my CSS???) but the productivity gains came quickly. The Pub ecosystem is fairly mature, in that all the third party packages are pretty high quality and address most common use cases. Unlike npm where there are 10+ solutions for the same problem, there will only be one - maybe 2 in Flutter land.
I was very pleased to find out, that Flutter supported web as well. Now, it's not as good as mobile yet - some of the animations are render blocked by the JS main thread - but it is a very nice 'middle' solution to somebody who needs to use the app who doesn't have iOS or Android (for example, Surface tablet). Also great for internal testing - push up the latest changes to a dev web environment, and everyone can test without installing APKs or using TestFlight.
In my use case, I was actively discouraged against making something that looked beautiful or pretty - the software is designed to be spartan, minimalist and essential. Flutter is perfect for that.
All in all, Flutter is awesome. Is it the right answer for everything? No. But when you only have one developer to spare whose job it is to build a mobile app, it's perfect for that. The web support is a nice bonus - haven't tried any of the desktop stuff yet.
Dart, as a language, is nice. Not spectacular, but certainly tidier than Java or JavaScript. I've gotten used to functionality programming, so writing everything in classes was jarring at first.
Having used Flutter web in production, I would overall advise against it. It can be brilliant for building forms with elaborate validation logic - and quickly so, but once the site gets heavier and you add more complexity to it, the more issues will pop up. There are still major issues they haven't sorted out yet like occasional odd behavior with input fields and autofocus on Safari etc.
I'm also used to functional programming. The only thing I can not stand about Dart is that types are coupled to classes. If you want to use stateless functions and typed data shapes, you're out of luck. Compare this to TypeScript that truly allows both paradigms and has a very expressive type system.
Doesn’t `typedef` let you specify arbitrary type aliases for pretty much anything in Dart? Or are you talking about something else? For my own curiosity, can you provide an example of Typescript vs Dart in this case?
Flutter 3 comes with an upgrade to Dart 2.17 [1], which has quite a few improvements as well... including state on enums.
While that's great, I was hoping it would be like in Rust, where each enum variant can declare its own state components, but unfortunately it seems to be more like Java: same state for all variants.
Well, at least there's quite a few other small but useful improvements... and they showed how they really listen to the community by implementing the new syntax for passing on constructor parameters to a super-class... and by improving the docs of the 200 most popular packages with lots of examples, as requested by the people.
I like how they're listening to the community as well to implement meta-programming (like macros) [2] to solve the main pain point, currently, in Dart, which is how verbose it is to generate code for things like serialization and data types.
Once they get that, Dart will be a really good language to work on (it's already quite ok IMO, despite most people, usually those who don't actually use it much, hating on it).
> While that's great, I was hoping it would be like in Rust, where each enum variant can declare its own state components, but unfortunately it seems to be more like Java: same state for all variants.
Yes, the enhanced enums we shipped in 2.17 are like Java enums.
I say "style" here because object-oriented languages like Dart can already mostly model sum types using subclasses. What you need to get the rest of the way there is basically just:
1. Sealed types so that the compiler can check for exhaustiveness when you match over all of the subclasses.
2. A nice pattern matching syntax to let you discriminate between the subclasses and destructure them.
3. Ideally, a nice lightweight syntax for defining a sum type family as a superclass and set of subclasses, though this is relatively less critical.
We're hard at work on this, but pattern matching in general is a pretty large feature and retrofitting it into a language whose syntax wasn't initially designed around it is a challenge.
I'm very excited about macros too. That's another large, difficult feature, but one that I hope will provide a lot of power to users and make the entire ecosystem more valuable over time.
Any thoughts on the freezed package [0]? That's what I use currently for ADTs and exhaustive pattern matching on them, would be cool to see similar syntax in the official implementation.
That feels like quite an awkward way to squash tagged unions into a class structure... But maybe it will work. I would say special syntax for it probably is critical because defining an entire class for each variant does not sound like fun!
> That feels like quite an awkward way to squash tagged unions into a class structure... But maybe it will work.
It's what Scala and Kotlin do and I think it's a fairly natural mapping. (Swift takes a different approach with their enums).
> defining an entire class for each variant does not sound like fun!
If you come at it expecting the brevity of ML, yes, it's not. But if you accept that those variants are real classes and may also have their instance methods, documentation comments on the fields, etc. then the overhead starts to feel less onerous.
> While that's great, I was hoping it would be like in Rust, where each enum variant can declare its own state components, but unfortunately it seems to be more like Java: same state for all variants.
As much as I like Rust’s enums, I think they messed up on the naming. Java (and according to your comment, Dart) gets enum rights. What Rust has under this name is sum types, which is a separate (more expressive) concept and the two only correspond with each other in the case of a sum type where each component is of a zero-arity type.
I agree (that’s what I meant under the more expressive part), though it is a bit more complex with identity in the way. Java’s enums are also the singleton pattern.
Java recently got ADTs as well in the form of sealed classes and records, here an enum would look like this:
sealed interface Color permits Red, Blue, Green {
}
record Red() {}
record Blue() {}
record Green() {}
You can now create as many Red instance as you want, they will be “equals” only under equals(), not under ==, while the latter is also true for the enum case.
I disagree. "Sum" and "product" types are really really unclear names that only make sense if you've studied some advanced CS and even then they're bad names - not descriptive at all.
Enum is much better - you just enumerate all the values the type can be (plus optional associated data).
Perhaps, though given that it is already used slightly differently in a very well-known language can also cause hiccups.
For the record, algebraic data types get there names from the fact that the “number” of instances that are under a given type gets added or multiplied together. Let’s say we have a ColorChannel “enum” of R, G, B. That is there are 3 instances ever under this ColorChannel type. Let’s create (with some syntactic sugar) an 8bit unsigned int which has exactly 256 possible instances.
Now create a Pair (ColorChannel, u8) type. This will be a product type, since the number of possible constituents is 3x256.
Let’s look at the often used Option type, which wraps another type. This looks something like
enum Option<T> {
Some(T),
None
}
We have two possible types here, but one can contain T possible types. So Some(T) is basically a product type of 1 other type, resulting in it holding that type’s cardinality, while None has a single instance — the Optional sum type thus has card(T)+1 possible instances.
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.