Earlier quoted context omitted.
I may be missing something, but why would you want to build a serverless function in Dart? you want a common backend/frontend language?
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 lik…
Flutter 3
421–430 of 453 posts
Re: Flutter 3
#422Earlier quoted context omitted.
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 a…
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?
I blogged for a few years (and wrote thousands and thousands of comments on Reddit, which was also helpful) before I wrote a book.
Re: Flutter 3
#423Despite 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,…
It's not remotely a realistic option. CJK is all second class citizen. I just tried their latest demos. Tried to enter 日本. It utterly failed. First it's still trying to draw on it's own so you get to see some placeholder □ while typing. Then, it effup and typing n-i-h-o-n kept producing Nいほん on this example https://gallery.flutter.dev/#/demo/cupertino-text-field As long as they keep insisting on rendering everything…
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.
Re: Flutter 3
#424Earlier quoted context omitted.
> 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. We are also working on support for pattern matching and algebraic datatype-style programming: https://github.com/dart-lang/language/blob/master/working/05.…
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!
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.
Re: Flutter 3
#425Earlier quoted context omitted.
For the vast majority of (mobile) apps, the benefit of being able to be built from a single code base outweighs being slightly behind vendor capabilities. Particularly things like there where it doesn't come up in some apps and relatively few people actually notice/care about it in those it does.
Google doesn’t think it’s own cross platform framework is good enough for its own applications https://9to5google.com/2021/10/10/google-ios-apps-native/
Doesn't seem like the article you linked accurately represents your statement.
Re: Flutter 3
#426Earlier quoted context omitted.
Doesn't appear to based on the website, which is just sad considering it's almost zero effort to create an Android build as well. I'd consider using this app also.
I could indeed build it for Android, but since I'm using the Cupertino components, it would look and feel like an iOS app. As I said replying to the parent comment, I'm currently waiting on the Material 3 components to be available before I do that.
Re: Flutter 3
#427Earlier quoted context omitted.
This right here should tell you why you shouldn't use Flutter for Web. The Web is pretty great for accessibility out of the box until us devs mess it up, we shouldn't use a technology that needs to completely build it from scratch to get it to work.
Just as an FYI that is how the official web spec works https://wicg.github.io/aom/spec/ I'm going off of memory here but I think it's approximately correct. They were playing around with the idea for a while of creating "virtual trees" to handle accessibility and ultimately had to abandon it for privacy reasons because you would be able to imply that anyone who was using the virtual tree was differently abled and tha…
As of Feb, 2022:
> While still in draft form within the Web Incubator Community Group, the Accessibility Object Model (AOM) intends to incubate APIs that make it easier to express accessibility semantics and potentially allow read access to the computed accessibility tree.
Re: Flutter 3
#428Earlier quoted context omitted.
> I just wish Google had built Flutter on a low level core that isn't tied to Dart, so it would be usable from other languages. Any chance that someone will build a transpiler from e.g. Go or even Rust to Dart? Or is Dart too exotic to be used like that in a practical way?
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 with…
FYI, In Go you can embed one struct in another and the embedded fields are accessible from the top/parent struct.
Re: Flutter 3
#429Earlier quoted context omitted.
Works fine for me in Asahi Linux, both Flutter 2.x and after upgrading to 3.
Really using Asahi as a daily driver? Thought it didn't have video acceleration yet?
Re: Flutter 3
#430Earlier quoted context omitted.
> 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 arg…
> 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…