I have little to add to the article in question, but I’d like to say that I’ve fallen quite in love with Flutter and Dart.
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 recently had an idea for an app that would work on Mac, Windows, iOS and Android (and maybe even Linux). After considering the options I decided to prototype it in Flutter and so far I've been pleasantly surprised. Despite having to learn a new language and UI framework I've made rapid progress and I've been able to find solid third party packages for most of what I've needed that isn't in the framework itself. Even calling into native code via FFI was surprisingly straightforward and the ffigen tool worked without a hitch. Passing off heavy CPU work to background workers was also trivially easy.
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?
> (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.)
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.
A little off topic but why is it that whenever a Flutter/Dart topic actually gets some traction on HN the technology gets so much hate (might be too strong a word but I can't think of anything better just now).
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.
Go is well past the point of it mattering whether Google continues to use it or not. I don't think Dart or Flutter are.
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'.
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.
> 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.
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.
I'm no JS fan but this argument doesn't make sense to me - just pick from the big ones at random then? Far more weight behind them than Flutter, and I don't know why they get the higher bar of being 'evaluated' between when Flutter doesn't because it's the only option and you're stuck with it.
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.
Me neither (and I only really have 'it's basically the same as [take your pick]' level familiarity with JS/TS anyway) but I bet my manager planning the hypothetical multi-platform project would be. It means it's either greenfield or a re-write. It probably affects hiring even if I think we'd agree it shouldn't.
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'.
> And it's not just 'learning' it, the language itself, it's library availability and the general ecosystem.
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.
Adding a new language to the stack always adds costs, especially if it's a marginal language. In addition, the migration costs increases as you can't bring in old code. And all your effort is wasted the day you want to migrate away.
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.
Go would have been an interesting choice. Flutter would have been Go's defacto UI library and would have opened the language up for use in areas that it has no presence in today. I also think Flutter would have wider adoption if it used Go.
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
Think of it the other way around: Dart was created for the sake of Flutter.
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.
> You're not supposed to use Dart for any purpose other than Flutter
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:
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.
I'm not disparaging it, I'm saying it's a barrier to entry. I think if Flutter was built around CSS & JS or something it would have a lot more adoption. I'm not saying it would be better.
Using JavaScript as the language that the framework uses is one thing, but it seems to me that suggesting that it be built around css is basically suggesting that it should be a fundamentally different thing.
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?
An Electron app is running on top of Chromium and Node, so at some point you’d have to feed them HTML/CSS/JS anyway. It wouldn’t make much sense for the apps to be written in something else. Flutter apps on the other hand build to native apps. Having to build HTML/CSS/JS code into, say, a native windows GUI seems like it would be rather awkward.
The plus side is that Google can develop Dart alongside the framework. This allows some nice things like excellent hot loading support, fast AOT compilation for release builds, a GC tuned for UI work, etc that would be harder or even impossible in a general purpose language with different goals.
It's also a pretty easy language to learn if you're already familiar with any other modern mainstream language.
Think of it the other way around: Dart was created for the sake of Flutter.
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.
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:
As far as I know, Dart was created beforehand in order to "replace" Javascript. That did never work out, it never got any real traction, so Dart eventually stumbled around without any real purpose. Then Flutter came, used Dart (because they needed some language like JS, but not JS, and Dart was "there" and could be used because it was a Google product) and then Flutter started to gain traction, and so did Dart, but only as a side effect of Flutter now being the only real "user" of the language.
As a desktop user I dislike Flutter apps because they have high input latency (at least in Firefox), and their UI is always mobile-first so it strongly clashes with expectations and capabilities of a desktop.
You mean Flutter web apps? The web version of Flutter is not as mature as the other platforms. It's nice to have as an option but I wouldn't choose Flutter today if the web is your primary deployment target.
I think that Flutter apps by the framework's nature will always have non-native appearance and feeling to at least some extent. And this makes it not very good fit for apps with a sufficient budget and the need for native appearance.
It's definitely good for small one-person projects, but the job market for these is not very lucrative.
This is one of those dumb things where user tests will stir up things like "why doesn't it look or act like (insert mainstream application)?" They have their hypercritical glasses on and fail to realize that the mainstream app already looks and behaves exactly like that; they're just so accustomed to it that they don't notice it.
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.
> And this makes it not very good fit for apps with a sufficient budget and the need for native appearance. It's definitely good for small one-person projects
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.
System components is not a thing on Android. You've not seen the default EditTexts in years. Material, which you'd consider the default is a library, whether in XML or Compose (and Compose is a reimplementation of them).
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.
I'm iOS dev but right now learning flutter. Few observations:
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):
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.
I had high hopes for this new renderer, but it’s still not good enough. There’s a single frame lag when scrolling, it might not be noticeable to some people, but I do notice and it’s very annoying. There’s an issue opened: https://github.com/flutter/flutter/issues/110431
Sort of. It adds a lot of layers on top of the core components and isn't just vanilla native UI plus some tweaks. React Native apps still stick out compared to real native apps unless you put in a fair amount of extra work.
In my experience RN apps are most obviously “un-native” feeling in their navigation, which is where the most custom-rolled code seems to be. It often feels clunky, with weird transitions and foreign behaviors.
At my company it's Google and it's history of deprecating products that many people and/or companies depended on. Flutter is OS, but it can't survive without a big company to sponsor development (at this stage).
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.
FWIW I've been working on a native Swift implementation of Flutter channels [1], so I can use Swift for business logic with Sony's embedded Flutter embedder [2]. Probably a niche interest, but I'd prefer to write Swift than Dart, and there's no Objective-C runtime on Linux (so I can't use the default Darwin embedder).
I picked up Dart in a week or so and felt very productive with it in less than a month, the language itself is very easy to understand if you already know Typescript or Java.
Flutter has a learning curve as well, you need to understand the concepts and the built-in widgets but even after month or so I was able to code up basic cross-platform app for iOS/Android. Ended up spending almost a year working on that project and gradually evolving it to support offline state, geolocation and real time updates.
If you are comming from front-end side (javascript, typescript, react) then sure. But for me who didn't touch front-end since 10 years and did mostly: Java nad C++, Objective-C, Swift, Python there is no easy way to learn the React Native ecosystem. I tried RN last week and I been all the time googling to figure out all the choices:
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.
This is one of the nicest things about Flutter. Out of the box you get most of the things you need to build an app.
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.
Flutter overtook RN a while back in terms of popularity in a few different metrics if I recall correctly. I forget the specifics but something from GitHub and StackOverflow I think.
Regardless of the specifics I don’t think the narrative is true, Flutter has had substantial continued growth for years now.
Many startups around me seem to be using Flutter, about as many as are using React Native. The problem with startups is that they're chronically broke and contracts are often too short to be worth it. All the cross platform frameworks are compromises, which makes them an unprofitable business for freelancers because the only customers using them are poor.
The thing with React Native is that you essentially have the full power of the native platform, including all native UI controls. You might have to write you're own integration if you're doing something unusual, but you will definitely be able to do it. With Flutter that isn't so much the case.
Most companies are 100% focused on the logistics of delivering a product and only “care” about technical implementation inasmuch it will be a liability to the objective. Þe olde chicken and egg strikes again
Things have improved though last time I checked 4 years ago. Flutter UI kit is definitely more complete and not fragmented as RN UI kits, or even React UI kits. On top of that you have official:
- 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
When was that? It seems to me there are Flutter/Dart packages for everything these days, and if I remember correctly, Flutter has overtaken React Native on the StackOverflow popularity ranking.
How superior it can be if it just shows a native canvas element and then draws custom stuff on it, which leads to funny bugs like 1 frame lag on iOS (OS detects touch and rightfully assigns a draw action, then flutter slaps its hands and reassigns with scroll action)?
> 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.
Flutter is nice, but "typical 90% apps" can be written with literally anything.
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.
I think it's absurd to say that "developers can press Cmd+\, which is so good that we will accept a ~15% worse UX". The industry has very strongly decided that developer "productivity" is more important than anything else though. It's sad.
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.
It depends on the app, but the costs for maintaining iOS and Android separately don’t seem like 2x… with how similar Swift and Kotlin are to each other and Compose greatly streamlining what used to be a real mess (Android Framework), it’s closer to maybe 1.2x or 1.35x. More expensive but not terribly prohibitive, plus it saves some trouble in the future when/if features that don’t play nice with whatever cross platform framework are needed at some point down the road.
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.
I don't think native necessarily bring you better UX, or even better speed for that regard. On my very low end Android device, Flutter apps are more responsive than the native ones.
> The industry has very strongly decided that developer "productivity" is more important than anything else though.
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.
Not sure how it's on android market but on iOS app store its pretty rare to have app update (yep just update) that is less than 100MB even though all those apps were native - I know it's pretty crazy but this is were we live.
There are app market analytics tools, which among other things, also check how many apps use cross-platform technology. Flutter is among the most widely used:
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.
> 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.
after trying flutter I ended up with react native for mobile, wxwidgets for desktops, both solid and I don't need learn yet another language dart, I actually like dart but there are only so many languages I can focus
Languages are tools, after you learn a couple or so they’re all mostly the same and it’s the quirks that differentiate them. (Yes C and Coq are quite different, just don’t)
Now if you’re talking about ecosystems, package managers, CI/CD…
Jitsi been such garbage to work with. Their own self published numbers of the participants in an average video call is 3. Which is a piece of cake for p2p WebRTC calling which scales without a media server upto 9-10 participants on modern hardware and network.
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
Averages aren't necessarily much use here, as there are a lot more opportunities for small video calls than for large ones.
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)
I don't know what differentiated Zoom from its competitors, but a self-administered server will always be harder than using SaaS for stuff like video calls / WebRTC.
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)
Zoom does use a custom protocol. This is why it doesn’t work nearly as well when you take a call in the browser client. Not because WebRTC isn’t up to the task, but because Zoom hasn’t invested in it.
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
What's extremely high ? we've tried it at work for around 30 people, with 2-3 main speakers, sometimes more, and it was as lean as things could be. No lag, no .. nothing.
I don't know how they set it up thought, self hosted most probably, maybe that's the only way to get good performance.
I am curious .. how would you convert an inbound webrtc stream (from the presenter) to HLS for a broadcast to the viewers? Wouldn't the lag make it unusable?
It really depends on the use case. In vanilla WebRTC, all media is transmitted directly between peers. In practice, this doesn’t scale beyond 5-10 users in a session. Most home internet connections can’t sustain that amount of upstream bandwidth.
HLS is a client-driven protocol, so it has high-scale but variable latency. You could build a mostly one-way webinar experience using it, but definitely not a conference call experience.
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.
I haven't had a look at Dart for a long time (last time to see if it could do Angular with less pain). IIRC the original chief developer left Google and the language took a rather different turn, towards more type(script)-iness.
Flutter looked pretty much like its own Electron, so not primarily interested in that.
This is so much valuable but a bit late, i was looking for such flutter plugin like crazy specially during the pandemic for usecase of making online live class in my application. At that time went ahead with BigBlueButton, but that was a monolithic application.
The less I have to touch the java ecosystem the more happy and productive I become ... Also managing multiple codebases sucks. Still have to write the native parts in their native languages but it's better than the alternative.
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.