Hacker News Reader

Google has two horses in this race, because Android team doesn't acknowledge Flutter and rather go with KMM and Compose, alongside JetBrains.

The internal divisions with this are really amusing. The big driver towards Flutter seems to be needing an iOS app, but Google really underinvests in those (YT being the exception, but it might as well be a different company).

If you want to have more fun on this matter,

https://www.youtube.com/watch?v=VX6nAvRWQg4&t=3418s

Companies at the size of Google naturally have different business units with different goals. Flutter solves something from some teams with other parts of the company that do not solve for them. That doesn't mean there are some sort of systemic problems. It just means that it operates more like a series of smaller companies in many ways, which is overall healthier for everyone. It's confusing that everyone always expects some sort of unified strategy from the top. That's like suggesting countries should act more like dictatorships rather than democracies.

I mean yes, but also no. Companies the size of Google still have an overall strategy, and when one group’s strategy is to shit all over another part of the company, that usually doesn’t work out. Even worse, the scale Flutter is developed at is simply completely different than Android and Chrome. Flutter is really a symptom of just how strange Google is, as kind of a weird, anarcho-engineering collective where you can do anything as long as you can get a VP to support it.

Reminds me of Microsoft where Windows team doesn't acknowledge C#...

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 .

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

What state management solution(s) do you prefer?

I started with https://pub.dev/packages/flutter_bloc and then migrated to https://pub.dev/packages/state_beacon for my app, and so far I've settled on it. But when I publish libs to pub.dev, I stick to built-in SDK stuff.

> 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 things I wish they would take from TS (like discriminated unions), and I haven’t tried “modern” Java either so maybe that’s improved, but even so, I rarely feel like Dart is getting in the way.

They probably just haven't used the latest Dart versions which fixed a lot of the "ugliness" (which I'd call pragmatism but regardless) like primary constructors where a class can just be a single line now.

And I mean, their entire comment is a way to shill their app so I wouldn't take much stock in what they're saying.

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.

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

I don’t want to sound harsh but that’s the least convincing list of language misfeatures I’ve ever seen. Almost every point is so minor I am surprised you didn’t mention having to type semicolons and similar incredibly inconsequential things.

They are minor, but that is why I called it ugly - not bad.

It's a matter of taste, and Dart's syntax style doesn't match mine. As much as I tried to enjoy it, after a while I just couldn't look at it anymore.

All of these accumulate and make it feel overly noisy for a lazy brain.

I created something similar to Hyphen at my previous job and while it was a big shift in mentality, implementing UI in the backend and having the apps consume that and render it with native components os really underrated.

> Although, I do not prefer Expo due to it's highly annoying build system and dependency hell

Highly agree with this. I'm almost done moving an app off it into React (web, not native) because the SDK upgrades kept including unlisted breaking changes to the point I can't upgrade anymore. Biggest culprit was Reanimated.

I migrated one recently into fully native Swift UI and Compose from Expo - modern models can do it over night, and you save yourself from the dependency hell that is expo.

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

Thanks for the detailed reponse!

hypen looks very similar to SlintUI, isn't it?

There are some similarities, especially in some syntax ideas. I'd say the core difference from the DX side is that Slint stylistically aligns more with CSS on some areas and allows things such as assignments, Hypen aligns more with Swift UI and separates those things from the UI completely.

Also the integration story is quite different, where Slint is more leaning into a "component integration" model, Hypen leans more into a "just a display layer" model with strict state/UI/action segregation.