Jitsi Meet Flutter SDK
jitsi.org
jitsi.org
I think of Dart as being C#-lite, although the latest changes with class modifiers have somewhat complicated the sentiment. For reference, my background is in OOP/JavaScript land, with patches of Scheme, Rust, and way more Go than I ever wanted. I really think Dart is one of my favorite languages, it’s just a joy to work in. Clean, fast enough, and to my experience so far, footgun free. I also know @munificent here is a principal developer of the language, and he’s done a good job. (But in case he’s listening, please add Rusts discriminated enums, it really hurts to move from a language with them to a language without them.)
As for Flutter, as a WinForms and UWP developer, coming to terms with its Dart-declared UIs was tricky, especially when coupled with the constraints based layout system. But I’ve long since crossed the threshold in my mind, and now I can strongly say I don’t want to program UIs in anything else again.
The one real complaint I can agree with is that the ecosystem kind of sucks, but it’s growing and getting better. I’ve seen some profound growth in the area over the last two years.
I'm not a programming language expert, but my understanding is that discrimitated enums is jut a way to support sum types. Dart now has the sealed class modifier [1], that fills this role.
Dart isn't a flashy language but it's easy to learn and overall I much prefer it to the JS I have to deal with in my day job.
My main hesitation now is Google's longer term commitment to Flutter. They seem to be putting a lot of resources into it at the moment but who knows if that will be true a few years from now?
(Zulip uses jitsi as a default meetings provider).
For me personally, not a professional developer, and certainly for personal projects if not for projects that need to be cross platform, I don't see a product with less fruition/baggage. I'm not saying it's perfect but it seems the best there is, especially if you're coming at it without any previous dev experience.
I get the Google thing. But dart/flutter do seem integral to Google going forward so I don't see them abandoning them any more than they'd abandon Go at this point. Could be wrong though.
You seem to think that the framework designers at Google just decided to pick a niche language called Dart to write Flutter in when they could have picked Javascript to write Flutter in. No. They decided to make the design of Flutter as a framework so clean and pure that they would have to work backwards to figure out what language it would need to be written in and then they created Dart.
At least that's how I like to imagine it.
My understanding is no one was using dart really prior to flutter due to that history. Though it was obviously pivoted for flutter.
I don't have an issue with any of this though.
Dart pre-dates Flutter by a few years and had failed (a couple of times) as a web development language before Flutter chose to employ it. Would Dart be around today, outside of Google if not for Flutter? Seems unlikely.
Flutter indeed did decide to pick a niche language, albeit one that was used internally at Google. Tim Sneath discusses it on Software Engineering Radio:
https://www.se-radio.net/2020/12/episode-437-tim-sneath-on-a...
It's also a pretty easy language to learn if you're already familiar with any other modern mainstream language.
And Dart's more of a barrier to that level of adoption than Flutter itself (if it were somehow language-agnostic, or a multi-platform JS framework even). Tauri has mobile support coming, and once it does with some level of polish, it's harder to imagine Flutter ever getting that popular? It would be trying to convince 'this is a great framework, this is the one you should choose [but sorry you need to learn Dart]' versus 'use whatever [JS] framework you want, you probably already have a favourite'.
At this point in my career I'm definitely not intimidated by having to pick up some new syntax -- especially if it is straightforward and sensible.
And it's not just 'learning' it, the language itself, it's library availability and the general ecosystem. Which is obviously a bit of a chicken-and-egg problem or tautological even that '~nobody wants to use it because ~nobody uses it'.
Exactly, there’s a whole universe in a bottle that comes with each language, and I think that is what is the largest source of friction these days when developers consider using a language, especially when the language has little to nothing unique to offer in exchange.
It's just so utterly pointless, Dart doesn't bring anything to the table as a language and isn't used for anything else. I have no idea what internal Google politics made Flutter go with Dart, but it would have been way better if they had used Go. I say that as a certified Go skeptic, at least that is a widely used language.
You seem to think that the framework designers at Google just decided to pick a niche language called "Dart" to write Flutter in when they could have picked Javascript to write Flutter in.
No.
They decided to make the design of Flutter as a framework so clean and pure that they would have to work backwards to figure out what language it would need to be written in and then they created Dart.
You're not supposed to use Dart for any purpose other than Flutter -- that's not a drawback to learning Dart -- that's the whole point. An entire team at Google literally created a language to make it easier for you as a developer to express yourself in this domain, and you think that's a drawback? That's like thinking being given a ladder is a drawback when you want to get up on the roof.
Sure, you could just assemble a big pile of rubble and scramble up it to get on the roof, and it is true that you might be able to later use the rubble for other purposes (whereas a ladder is built for a specific purpose) -- but that does not make the ladder the more limiting tool.
If there is one repeated comment I hear about Flutter it is "wow, it seems like such superior technology, I wonder why it isn't more widely used".
To which the answer I keep hearing is "it is only superior for doing the thing it is built for -- it isn't superior for other things."
Those who would give that answer consider Javascript, on the other hand, an (inferior) tool not only for this problem, but also for other problems, so it is the more generalizable tool and therefore it makes more sense to use Javascript.
The argument seems to be that at least if you're using the same crappy tool for everything then you can claim the efficiency of never having to change your tool.
"Only a fool would use the best tool for the job", is the implication of those who disparage Dart.
Dart was a JavaScript alternative that was started back in 2011. It's evolved a lot since then but in no way was it created for Flutter.
(I worked physically adjacent to the Flutter team for a couple years)
https://docs.flutter.dev/ui/layout/tutorial#step-2-implement...
There's not even a JS alternative required here, this step is showing purely an HTML & CSS alternative?
Flutter in my mind is 'competing' with Tauri or Electron, which give me an HTML/CSS/JS (or any equivalent traditional web) frontend cross-platform. But I haven't actually used Flutter (or Dart), just looked at docs, so maybe I'm wrong?
That’s definitely revisionist history. Dart was first intended for use in the browser, it’s why Dart has JS interoperability. Google even planned for the direct use of Dart in Chrome:
https://techcrunch.com/2015/03/25/google-will-not-integrate-...
> then they created Dart
Dart’s first release was in 2013. Flutter wasn’t even announced until 2015. It was created as a JS replacement, it was not successful in that goal, then it was used for Flutter. Which is all fine! But let’s not rewrite history.
In retrospect, it seems like an obvious choice. It could be that Go wasn't what it is today back in 2015. Go was just finding it's footing in the cloud native stuff back then. Maybe they would have gone with Go or Kotlin Native if they had to do it over again today
I don't want to have an opinion about which JS framework I should use. I want to worry about the client's requirements and build the software. Having 20 frameworks to evaluate and choose between just means that the entire toolset is less well documented and less stable and no one framework has any weight behind it.
And after working for years in JavaScript I just don't like it -- I hate the constant brain-breaking workarounds that other languages solve by just not having the problem in the first place.
Javascript sucks.
But anyway if you want to use Dart & Flutter fine just use it? My comment wasn't about why someone shouldn't, it's why I think people don't, i.e. why it doesn't have that much adoption.
Taking client requirements and selecting appropriate software is part of the job. Choosing Dart for said project is just as much of a choice.
There are hundreds of human languages in the world, but English still manages to have far and away the most weight behind it. JavaScript frameworks are in a similar boat: all the tiny frameworks together make up a tiny fraction of the total usage. React is far and away the largest, followed by Angular and Vue in a distant second and third. Most of the new frameworks you see on HN are actually layered on top of React, which means they're contributing to its weight, not detracting from it.
So, if you want to make a decision based solely on weight, straight React is a no-brainer. If other factors matter more, then you've got other choices with different trade-offs.
But I still don't understand why most companies still focus on React Native for their cross platform development.
It is fantastic for side projects and personal projects or when you are contracted. But I find it very difficult to get a job with Flutter.
Google needs to do better marketing for the technology.
I learnt Flutter and find that it's very hard to get a Job with the technology.
Also, Android has never pushed for unification of UIs. Use Material if you want because it's an alright design system, or write yours entirely from scratch.
React Native & Flutter look... Exactly how you want them to look. Unless there's a bug in Flutter's Material implementation, it'll be the same.
1) Difference between new latest Material You (aka material 3.0) and SwiftUI is smaller than Material 2.0 and UIKit - at least regarding look & feel.
2) I find old UIKit style quite boring same with older material 2.0. On the other hand SwiftUI and Material 3.0 looks more modern. There is rarely any iOS app that use native widgets without completely changing branding and styling.
3) Comparing to SwiftUI, new Material 3.0 feels more complete - there is more widgets and navigation choices. UIKit and SwiftUI is lacking in widget departments regarding: snackbar, bottom sheet, modal bottom sheet, navigation drawer, navigation rail, modal navigation drawer, cards, multiple dialog options.
I recommend to checkout and play with material 3.0 demo (just keep in mind this is web version- you will have even better experience when using native compiled version on mobile or desktop - web version of flutter could be better):
https://flutter.github.io/samples/web/material_3_demo/#/
4) Try web flutter gallery to see numerous app samples (more complex) and widgets
https://gallery.flutter.dev/#/
again even better to download mobile or desktop version that there is in play store:
play store: https://play.google.com/store/apps/details?id=io.flutter.dem...
macos dmg (.zip): https://github.com/flutter/gallery/releases/latest
I tried both macos flutter gallery and on iOS and surpassingly is pretty good these days and smooth and feel native - even text selection works these days, moving cursor with long press on keyboard space etc. Occasionally was more difficult to dismiss keyboard on iOS and back/next mouse keys or touchpad gestures didn't work on macOS flutter gallery. But overall I'm quite satisfied and surprised comparing how it looked 4 years ago.
This is what it looks like now in terms of performance if you want a demo https://flutter.gskinner.com/wonderous/
Do you have any data to back this claim. From my experience, many big budget applications (at least on desktop) don't have native appearance. Eg. products by Adobe, Steinberg, Autodesk, JetBrains etc.
I'm not sure what you do about it. I fell victim to this a couple decades ago trying to reconcile theme inconsistencies between GTK and KDE apps on my Linux desktop. It was so irritating, but for longest time I was overlooking that Windows at the time also had apps using different Windows UIs from different eras. IIRC Outlook actually had an XP scrollbar for the Inbox frame and a Win32 scrollbar in the Preview frame. Two different UI styles in different frames of the same window within one application.
Simple as that. Using a flutter app has non system scrolling acceleration, scroll speed etc.
It doesn't feel like a native app, because it isn't a native app.
With react native, there are many parts of it that use the underlying system's UI, and so it feels like it could almost be a native app.
Also hitching their horse to dart was a poor move to get devs to switch over from swift/kotlin and JS.
Regardless of the specifics I don’t think the narrative is true, Flutter has had substantial continued growth for years now.
1) should I use nvm, n, nodenv for for nodejs management? Should I use script or homebrew?
2) what's the difference between npm, npx? Why npx giving mi different version number than node? Did I had some old version of nodejs from some dependency when using homebrew? Will it bite me in the future (those all questions were in my head)
3) should I use expo cli, ignite cli, react native cli?
4) expo vs repack vs vite vs capacitor vs tauri
5) webpack vs metro vs swc vs esbuild vs rollout vs sucrase...
6) vanilla react or next.js or react native or solido?
7) what ui kit to use? native-base? tamagui? react-native-paper? They all sucks in some way comparing to flutter proposition
8) should I use style-components? emotion? tailwindcss? nativewind?
9) should i use vanilla javascript or typescript? (is learning typescript straight away is too big to swallow in one bite?)
10) learn vscode shortcuts + figure out which plugin to install and how to setup
11) JSON config hell in RN for everything: postcss, vite, tailwind etc.
12) react-navigation vs react-native-navigation vs expo-router
13) redux vs mobx vs mobx-state-tree
React native feels to me like thinkpad + dekstop linux: you like the philosophy, crossing finger it gets better and less fragmented and working out of the box
But in the end you end up buying macbook with macOS (feels like flutter) even though you hate apple solders stuff and it's gonna cost you a lot of it breaks and apple giving you limited choices and too much constrained walled garden.
There's a lot of competition for state managers but other than that you have a lot fewer choices you have to make to get started and fewer third party pieces to break on you.
I played around with Flutter for a personal project and there very few third party packages.
- firebase
- supabase
- revenue cat
- stripe
- google maps
- google ads / analytics
- grpc
- webview
- tensorflow
just to name a few - there is even more community one e.g: lottie, mobx, just_audio etc.
interop seems also improved:
cffi got improved and been out of beta for a while and they also added FFIgen [0] that can generate bindings to C and Rust C
rust flutter bridge [1] - even though not official is very popular and well maintained. So you can use vast cross-platform crates if you need something more advanced and low latency like for Audio you have CPAL
Saying that, we've started a flutter project this year to see how it goes (the rest stays native or RN)...
Apart from Flutter or Google employees, there are close to zero Dart developers.
Even managers have heard of React and its success by now. Nobody has heard of Flutter or Dart.
By this point, betting on Google technology is known to be a high risk, as Google might kill off Flutter/Dart without transition to anything close at any point in time. Even managers have heard of this "behavior" by now.
> But I still don't understand why most companies still focus on React Native for their cross platform development.
Because it uses native components, which leads to native feeling apps. For bonus points, they added new engine that makes performance differences between react-native and native apps very small (unless you're working on interval trading terminal or games, which flutter does not handle as well). Plus its simply easier and entry barrier is non existent, therefore its cheaper.
> Google needs to do better marketing for the technology.
Dart as a language is a bad marketing for their technology. I also hate the amount of boilerplate I have to write and how weird it looks compared to RN/SwiftUI/Compose.
If your use case is "typical" like 90% of the apps out there, I think there's no reason to invest in native anymore (I did native Android a while back, so I can't comment if you're coming from iOS). Flutter has very strong developer productivity (such as "press Cmd+\ to auto-reload"), wide array of plugins (now with official Firebase plugins). Heck, somebody wrote a "Visual Basic" for Flutter (https://flutterflow.io/) using Flutter.
The real problem with Flutter is it's tendency to attract bottom-of-the-barrel cheapskate customers. I don't want to double down on my earlier mistakes and box myself into lower-paid 10% of already lower-paid (compared to iOS) Android development market.
OK let's put a constraint: multiplatform. Take Flutter out of the equation, then what do we have: RN, Ionic, Kotlin Multiplatform... what else?
- RN, Ionic: errr I'm still having nightmares reading JS/TS code
- Kotlin Multiplatform: not stable yet?
Qt can even be deployed to embedded systems if that's your jam.
Most apps are budget constrained - doing 2x native over flutter budget doesn't get you 15% better UX. It probably doesn't even give you two working apps in the budget. And getting to them you're still likely 2x bugs and worse UX because of the time spent redeveloping common shit.
If you're not budget constrained, have a team that can execute better UX without flutter, and this matters to your app - go for native. But there's so many scenarios where it doesn't.
Dual native also gets you better portability to new platforms branching off of iOS and Android — for example most native iOS apps can be turned into suitable AR apps for visionOS with two clicks and it does most of the UI adaptations required for you. Flutter won’t be able to do that for years if ever.
It's not productivity, it's cost. If an app costs twice as much to build for "20% better UX" then that's ridiculous. You can release earlier and spend half the difference on bugfixes/polish/additional features based on what you see in the wild.
GCP support in Flutter is excellent. You know… because Google…
Now if you’re talking about ecosystems, package managers, CI/CD…
I would be curious to know how many apps with a 1M+ downloads use these frameworks.
I can imagine many big / popular apps switch to native once they have the resources to do so but start off with cross-platform.
Not really. Startups looking to keep costs as low as possible tell themselves this and there’s a lot of advice out there from people who will tell you the same, but it’s very rare. If you are tempted to go with the cheap option and plan on switching once you have the budget, make your peace with the fact you will probably be stuck with the cheap option forever.
6% of the top ranked apps use Flutter.
React Native: 5.43% of apps (4.18% of installs) Flutter: 4.22% of apps (1.39% of installs)
It's clear from the ratio of apps to installs that React Native is used by apps that are on average 3x more popular, but that isn't really a sign that the framework is less viable, just that more of the most popular apps are were written using something else - and I'd speculate that in many cases those apps predated Flutter.
I actually find it more interesting that the number of apps written with Flutter compared to React Native is fairly similar. To me, that suggests that Flutter is gaining ground rapidly, because that very much wasn't the case when I first starting using Flutter on my hobby project a few years back.
In any case, your 25% target seems unrealistic for any framework [1]. Unless your takeaway is also that React Native is not a viable target until it too hits 25%.
[1] I'm discounting Kotlin from these stats as it's not a framework [2], and similarly I don't understand why they counted the Android components as a framework.
[2] Actually, I'm surprised Kotlin is this way down in the charts... If native code is now more popular than Kotlin, that could cause compatibility issues now some phone manufacturers are starting to experiment with RISC-V instead of Arm.
1. Common libraries (api clients) need to be built for all 3-runtimes (swift, kotlin, and dart).
2. Flutter runtimes increases the app size (539kb vs 4,700kb [0]), which is a problem for apps that are already too big.
[0] - https://medium.com/android-news/comparing-apk-sizes-a0eb37bb...
The users literally don't have the space to install apps, so they don't.
Fun fact about the Flutter SDK: it's a wrapper over our native SDKs, which themselves wrap our React Native codebase :-)
Right now we have a shared codebase between web and react-native, and from there are able to provide all our mobile SDKs:
- Native Android SDK (Java wrapper for RN) - Native iOS SDK (ObjC wrapper for RN) - React Native SDK (JS component of the RN parts) - Flutter SDK (Kotlin / Swift wrapper of the Java / ObjC SDKs)
It has been quite fun to work on these!
For extremely high users in an effective webinar you'd anyway need HLS based streaming so what even is the point of a media server at that time
It dosen't limit number of P2P participants.
It's just a matter of pipelines with ffmpeg
I don't know how they set it up thought, self hosted most probably, maybe that's the only way to get good performance.
If a team of seven has one team meeting and each non-manager has a one-to-one with the manager, the average number of people in a call is ~three. But they're still not going to use a system that can't cope with seven in a call. And they won't have any calls with more than seven participants even if the software can scale to dozens.
(It's also worth noting that Zoom have shown that it's possible to develop "video conferencing" UX than scales to hundreds of participants. I have no idea whether they do this by naively scaling up or by radically changing the way the conference works past a threshold number of participants, but as a participant I don't care)
WebEx seems to work fine too for huge calls, although I use the native client for it.
At a previous job, I once helped a tiny bit with setting up and configuring the company's Jitsi instance (wasn't the admin though).
As far as I can tell, the differences mainly affect non-P2P mode, which the server will enable above some bandwidth or participant number threshold.
Another thing all these WebRTC clients have to achieve reliably is dealing with different NAT setups and firewalls (one piece of this seems to be achieved with technologies STUN and TURN).
I guess video conferencing is at least as complex as implementing real-time multiplayer games over the internet.
Edit: Just read up that WebEx predates WebRTC and uses it only for interop with other tools. Zoom uses a custom technology stack as well as far as I know (I have no idea if it involves WebRTC).
So maybe WebRTC really is hard to scale up large numbers of participants.
Haven't heard much good about Teams in this regard either (which uses WebRTC AFAIK)
Ignoring costs, while having someone host infra for you will always be easier than managing it yourself, I think we’ve really improved the DX of hosting your own WebRTC infra with LiveKit: https://github.com/livekit/livekit
The primary issue with traditional WebRTC media servers and services is they didn’t horizontally scale. That’s changed recently. You can get pretty high numbers of users in a single WebRTC session now.
Many think they can go P2P, but browsers implement one bandwidth estimator per PeerConnection, so that begins to hurt quickly in practice.
In addition, sending multiple HD streams to serveal participants it's going to hurt the sender, but an SFU helps with that.
There are many more reasons, this is just scratching the surface.
Flutter looked pretty much like its own Electron, so not primarily interested in that.
https://groups.google.com/a/dartlang.org/g/misc/c/9V_mS2IHT_...
It have spatial audio , much better performance , easy to configure backend for UDP Holepunching , STUN/ICE or TURN Relay.