Earlier quoted context omitted.
[flagged]
How do you know? Why are we inclined to believe you over him?
It's simple, it disagrees with their preconceived notions so obviously we're wrong and they're right.
Flutter 3.47
151–160 of 231 posts
Re: Flutter 3.47
#152Earlier quoted context omitted.
I’ve been a React Native developer for 8 years, I’ve written many apps with it professionally and personally. Until recently, I would have recommended it wholeheartedly. This weekend I had an idea I set out to experiment with: if I have an existing React Native app, how much effort would it take an LLM to rewrite it into genuinely native apps. My idea being I no longer need to write cross-platform code and pay the in…
Be careful, I’ve been using AI to translate my Swift code to Kotlin and sometimes it makes some mistakes that are invisible to you, because the languages are so similar, but it will bite you in the ass eventually, because there are subtle changes between the platforms
I am sure you are right but if you tell the LLM to be careful with those it should easily avoid those mistakes. But yeah first you need to know what to look for.
Re: Flutter 3.47
#153Flutter is good on its own but dev tooling and long compile times kills all the enjoyment.
With full hot reload support I am curious how compile times can be an issue.
Re: Flutter 3.47
#154how's Dart for back end development? is anybody using it to build APIs? the syntax doesn't look too bad
While the server side is still growing and obviously not as huge as Java etc., Dart definitely is being used on the backend. For instance, https://pub.dev/ itself is written in Dart: https://github.com/dart-lang/pub-dev . :) The language, like any other, does have some weaker parts, but in general is _very_ nice to write in - thanks to both the language itself and the toolchain built around it. The apps compile to na…
For production you may consider using dart VM also since it benefits from AOT and can actually be faster than a binary after it gets hot, similar to Java.
Re: Flutter 3.47
#155I still prefer React Native with Expo over Flutter, mostly for practical reasons: * Language and hiring: TypeScript has a much larger developer pool. Dart is a solid language, but finding experienced Flutter engineers is harder. * Platform model: React Native maps much more naturally to native platform concepts. Flutter owns much more of the rendering stack, which is powerful, but also creates another abstraction lay…
As someone who used all these frameworks professionally for years, I highly agree. Although, I do not prefer Expo due to it's highly annoying build system and dependency hell, but React Native itself in that case. While I understand Google wants a horse in this race, Flutter doesn't feel like a horse to bet on. - Dart is a really _ugly_ language with lots of tiny annoyances. Its as if someone took worst parts of Java…
Completely opposite experience for me.
I love working with Dart (which IMO is _not_ "worst parts of Java and Javascript (...) turned (...) into a language", "Terrible to write, terrible to read, terrible to use" - quite the opposite, actually) and its toolchain, including Flutter.
I find the architecture simple to follow, no need for "either print apps as fast as possible or to emulate some Clean Code like behavior", though I do think some people use overcomplicated state management solutions. But nobody forces anybody to do that.
My experience with Web has been fine so far and I've seen fully cross platform Flutter apps working absolutely fine on mobile, desktop and web.
This is not to gaslight your experience, YMMV after all.
And React Native, with its dependency hell, project rot, npm ecosystem under the hood, and transpilation with lax runtime leaking into TS, is a total no-go for me. Though I base this opinion partially on my experience with NodeJS, and partially on that of my friends who use RN.
Btw. Does your platform support bundling UI in addition to streaming it from the server? How large is the bundled runtime?
PS. Clicking on "see all supported platforms →" on your project's homepage gives 404 for https://docs.hypen.space/docs/adapters .
Re: Flutter 3.47
#156Earlier quoted context omitted.
But they also fund JetBrains, Jetpack Compose, and KMP. It feels like the company threw their support behind Kotlin a long while ago on mobile, but internal struggles keep the others limping along. Compose UI tooling no longer requires viewing on device.
Only because it was cheaper to migrate Android to Kotlin instead of Dart. JetBrains needs Google more than Google needs JetBrains.
At the time Google went with Kotlin, Flutter was still very new and a much bigger step away from Java given Kotlin already back then was seamlessly integrated with Java and compiled to JVM bytecode.
Re: Flutter 3.47
#157Need to let this project die and invest the manpower + experience into something useful.
Re: Flutter 3.47
#158Earlier quoted context omitted.
> Dart is a really _ugly_ language with lots of tiny annoyances. Its as if someone took worst parts of Java and Javascript and turned them into a language. Terrible to write, terrible to read, terrible to use. While I’m a bit ambivalent towards Flutter, I totally disagree with you on Dart. To me it’s a better version of Java/Typescript with a very mature cross-platform and JIT/AOT compiler. Admittedly there are some…
Yeah I have no idea how someone who has used all these languages can come up with a conclusion like Dart is “uglier”. I really want to know what exactly they think is ugly about it!
They have written their own UI framework. Probably the reason they are biased against other frameworks
Re: Flutter 3.47
#159I always find it strange that flutter isn’t built with golang or typescript. Why use a new language? When flutter came out both languages existed so curious about that. The main reason i can think of is generics not existing initially
There were a lot of factors that led to the dart decision. It's also important to note that Flutter is very old, we were designing it in 2014.
- we wanted hot reload
- it was supposed to feel familiar to web developers and reasonable to native developers
- iOS needed AOT compilation for speed since we couldn't use a JIT
- TypeScript had literally just reached 1.0
- Swift looked promising, but the Oracle lawsuit made the idea of using it tenuous
- Kotlin was not even 1.0 yet, that wouldn't happen for 2 more years
- Go made huge binaries. The language was also lacking features like generics and Go was unwilling to add them (remember this is 2014).
- v8 was not interested in AOT, but Dart was willing to dramatically invest in flutter
There were probably other reasons too I'm forgetting.
Dart was a really pragmatic choice to ship quickly. I have mixed feels about how the decision has aged over time, and wish we had things like Hermes and WASM back then, and a willingness to build a TypeScript compiler like other native frameworks (ex. Valdi)... But for the time I think the choice was reasonable.
Re: Flutter 3.47
#160Earlier quoted context omitted.
You should try Dart/Flutter again, they've improved a lot. - Dart. It's richer than JS/TS with stronger type safety, and seems purpose-built for UI. Fewer Dart developers than JS, but I'd argue those JS developers cannot be immediately effective coding React Native (Expo) anyway. - Emulated components vs. real native components. For multi-platform apps, this is actually desirable. These kinds of apps have their own d…
> it's unsolvable since you need to download the whole world (a few MBs) to have the app running on your browser another reason why the web should move from whole app bundling to content addressed CDNs for library code. you would only need to download one copy for each framework version not every site. and its easy to make it decentralized with IPFS if you want.
Shared caches stopped working years back, to close a security hole. They're redownloaded per domain now. https://dev.to/rstacruz/public-cdns-arent-useful-anymore-2b6...