Live data from Hacker News

Flutter 3.47

flutter.dev

181–190 of 231 posts

Re: Flutter 3.47

#181
post #149

Earlier 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!

Mostly its the core syntax, it's terribly noisy. Also parts of the implementation itself. While I cannot enumerate the taste, I can give you some examples.

For example:

- Class constructors cannot be in definition headers, i.e. class Something(Int a, Int b)

- The whole final and const/static const mess

- required is annoying and really "slapped on"

- shorthand syntax is => instead of =, personal pet peeve

- positional, named and optional parameters segregation makes things noisy

- concurrency, in which an event loop sounds like a great idea but ends up causing pain with multi-threading and background work so you have to spawn diff isolates

- the whole `await fn()` vs `fn()` validity issue, where you can miss the await keyword and it still compiles is such a slap in the face. think now they solved it, but you could also have returns from non-return functions and vice-versa.

- `dynamic` and generics in the same language have caused many bad designs

- extension types also feel hacked on

- type inference is annoying and highly contextual vs out of the box

- Worst sin: DateTime.now() returns different things based on the platform its running on, making it highly unreliable for something so important

Re: Flutter 3.47

#182

I vouch for Flutter over React Native; we built https://macrocodex.app/ with 16,000+ users already! And it's completely free no ads, no subscriptions, or donations, for the public benefit of improving health and fitness. It's a guaranteed weight loss or gain app; results within 2-5 weeks! Don't believe? well just read reviews. We do not have Revenue, so no money to spend on marketing. OK so that's brief description o…

I wanted to love flutter. It’s just so hard to commit to anything like this Google makes without a full expectation of getting rug pulled.

Flutter is 9 years old at this point. I do hope they move it its own open source foundation since a ton of apps use it, having all that under Google's control isn't the best (looking at you too Android)

Re: Flutter 3.47

#183

Earlier quoted context omitted.

As someone coming from MacroFactor, estimating macros on food is the hardest part of dieting. So your app is great but it tackles the part of dieting that people aren't stuggling with and doesn't address the part that they do struggle with. Most dieting apps are pushing for the AI photo and barcode scanning to make estimating easier and though far from perfect, it makes the whole experience at least somewhat doable.

>As someone coming from MacroFactor, We've had many people who have unsubscribed from MacroFactor after using our MacroCodex. Not just this, we've also built MacroFactor Workout's rival Symbiote Workout app which is also completely free! it's now in Beta and under rapid developement. For calorie tracking, you've established apps like Cronometer and MyFitnessPal or they can use our completely free AI calorie tracker C…

Why free? Just trying to understand how the monetization will work. From your comments, it didn't look like open source

Re: Flutter 3.47

#184
post #149

Earlier quoted context omitted.

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

I am biased - but mostly because I have actively used these in my career for quite a while now and encountered pains with both writing new code, upgrading old code and worst, inheriting code or helping debug someone else's code.

When given a choice, I'd rather use bland React Native nowadays than Expo or Flutter - one is a legacy addon to a framework, while the other sounds like a good idea until you step on a nail or have to read some _bad_ code. And there is a whoooole lot of bad flutter code out there due to relaxed language semantics.

Re: Flutter 3.47

#185
post #127

Earlier quoted context omitted.

Why would you want apps on different os look exactly the same?

Why would you not? I use Ableton, Figma, and Emacs regularly. I have a decade (or more) of muscle memory around these apps. If they suddenly decided to adopt the look, feel, and conventions of their underlying host platform, I’d be very upset. If I’m using Emacs, I don’t want to use Cmd+S to save my files on macOS and Ctrl+S on Windows. I’ve already memorized C-x C-s. I don’t want Ableton to adopt whatever new design…

For end user apps, I want them to look according to the OS, at least on Apple devices. That's what picky customers. For stuff where design does not matter much, such as enterprise apps that "put food on the table", as you say, I use Flutter and still get a very decent result.

But with sufficient time and effort, proper native iOS/macOS wins every time.

Re: Flutter 3.47

#186

Earlier quoted context omitted.

I wanted to love flutter. It’s just so hard to commit to anything like this Google makes without a full expectation of getting rug pulled.

Flutter is 9 years old at this point. I do hope they move it its own open source foundation since a ton of apps use it, having all that under Google's control isn't the best (looking at you too Android)

Yeah now it might be ok but when it came out I didn’t want to bet on it.

Around the same time at my job tried to build a design system off Google’s web component MD implementation and that shit stalled and then got fully abandoned.

Re: Flutter 3.47

#187
post #155

Earlier quoted context omitted.

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"…

>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.

Unfortunately sometimes you have to, and on average, that code is much worse than your average React Native spaghetti. Whole generations of Flutter devs got these patterns ingrained, and often times they make not just writing and reading code, but communication itself harder.

>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.

That was my stance too until the new architecture released - since then the framework has improved a whole lot, together with its build chain, and is the best way to do crossplatform nowadays.

>Btw. Does your platform support bundling UI in addition to streaming it from the server? How large is the bundled runtime?

Not yet unless you DIY it - currently you can bundle UI and runtime by integrating the Rust engine + renderer with your app, or TS + renderer itself.

There is work being done in a private mirror currently on bundling the whole app + runtime as WASM, exposing WASI interfaces to native such as storage, network, permissions etc, depending on how testing goes it should land in a month or two on the public branch.

>PS. Clicking on "see all supported platforms →" on your project's homepage gives 404 for https://docs.hypen.space/docs/adapters

Thanks, fixing that ASAP!

Re: Flutter 3.47

#188

Earlier quoted context omitted.

I’ve used flutter for a couple of toy web apps. One is just a personal tool , another is a small party game. Now I might vibe code such things using React, but 5 , 6 years ago Flutter got me what I wanted fast. Firebase integration is absurdly easy. You can make a crud app in about 30 minutes

Yes but its best work with SPA or WASM type of app like games for example

It's probably not the best for anything in particular.

It's the fastest way to build something if you're not a big html person.

I've never particularly been good at hmtl tbh. The older I get, the more I'm concerned with the ease of tools/frameworks vs what's the most optimal.

Re: Flutter 3.47

#189
post #131

Earlier quoted context omitted.

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…

I’ve been keeping an eye on hypen.space and hope it succeeds. What is the level of maturity now and are there any multiplatform app examples that are not trivial?

Oh wow, thanks! I never would have thought anyone was keeping an eye on it!

Regarding maturity level - I would yet say it's mature for serious applications with OAuth, local storage etc. Late alpha/early beta stage.

There are some semi-trivial examples on the landing page - most are just UI + input with DB or API fetching in the background, so nothing spectacular.

All of these are crossplatform and render in both web/desktop/mobile and web SDK's or inside the Hypen Gallery apps.

Biggest obstacles to maturity currently are:

- Does not have native platform channels yet

- Renderers need more optimization work

- Ecosystem needs more stability - i.e. test mode and studio still have hiccups

- Error handling and retry story needs improvement

- Some components are still a bit off across desktop/mobile and need syncing

- Resource references derived from state need implementing for better DX

- Protocol isn't binary yet so performance isn't all it could be

But recently things landed that improve maturity quite a lot:

- Accessibility defining & automatic inference has landed, where framework does the best it can to figure it out for you with no intervention

- Animation API has landed with a minimal DX to enable transitions and animations

- Most of tailwind surface is supported and implemented

- Performance improvements being released this week land it in "often 30-50% slower, but sometimes 50% faster than react". Will add benchmarks to docs for visibility.

- CLI improved by a large margin, with expanded template support and easy building

- Cloudflare worker adapter so you can host your app on a worker

Re: Flutter 3.47

#190
post #81

I 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…

The biggest negative with Flutter is web. Because most of the UI is canvas-rendered, DOM based tooling like session replay, analytics, accessibility audits, and browser automation require specific instrumentation. That reduces third party choices you have unless you invest in your own tooling and who has time for that. I can't imagine the situation is much better in mobile.
Post reply on HN