6 ms·

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 d

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 and Javascript and turned them into a language. Terrible to write, terrible to read, terrible to use. - While there is no Skia anymore, the whole custom rendering of Flutter often caused more trouble than not, from the UI implementation itself all the way to specific low-end chipsets not being supported. - Ecosystem propagates these insane architectures that don't make much sense and are made to either print apps as fast as possible or to emulate some Clean Code like behavior. - Web still feels terrible to use, even after all these years. Since I'm not happy with any of these, I've even taken upon writing a framework of my own that renders into native UI and works with any language (gonna shill it here https://hypen.space https://hypen.space). It was inspired directly by years of working with mobile and experiencing the pains of crossplatform development such as Flutter and Expo. We can do better than these!

deleted 1mo ago
[deleted]
lifty 1mo ago
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?
- hypendev 1mo ago
  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
  - lifty 1mo ago
    Thanks for the detailed reponse!
AbuAssar 1mo ago
hypen looks very similar to SlintUI, isn't it?
- hypendev 1mo ago
  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.
nmfisher 1mo ago
> 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.
- satvikpendem 1mo ago
  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.
- brabel 1mo ago
  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!
  - anthropodie 1mo ago
    They have written their own UI framework. Probably the reason they are biased against other frameworks
    - hypendev 1mo ago
      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.
pjmlp 1mo ago
Google has two horses in this race, because Android team doesn't acknowledge Flutter and rather go with KMM and Compose, alongside JetBrains.
- sulam 1mo ago
  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).
  - pjmlp 1mo ago
    If you want to have more fun on this matter, https://www.youtube.com/watch?v=VX6nAvRWQg4&t=3418s https://www.youtube.com/watch?v=VX6nAvRWQg4&t=3418s
    - surajrmal 1mo ago
      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.
      - sulam 1mo ago
        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.
0rzech 1mo ago
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 https://docs.hypen.space/docs/adapters .
- hypendev 1mo ago
  >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 https://docs.hypen.space/docs/adapters Thanks, fixing that ASAP!
Rohansi 1mo ago
> 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.
- hypendev 1mo ago
  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.
videogreg93 1mo ago
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.

deleted 1mo ago

[deleted]

lifty 1mo ago

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?

hypendev 1mo ago
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
- lifty 1mo ago
  Thanks for the detailed reponse!

AbuAssar 1mo ago

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

hypendev 1mo ago
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.

nmfisher 1mo ago

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

satvikpendem 1mo ago
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.
brabel 1mo ago
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!
- anthropodie 1mo ago
  They have written their own UI framework. Probably the reason they are biased against other frameworks
  - hypendev 1mo ago
    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.

pjmlp 1mo ago

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

sulam 1mo ago
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).
- pjmlp 1mo ago
  If you want to have more fun on this matter, https://www.youtube.com/watch?v=VX6nAvRWQg4&t=3418s https://www.youtube.com/watch?v=VX6nAvRWQg4&t=3418s
  - surajrmal 1mo ago
    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.
    - sulam 1mo ago
      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.

0rzech 1mo ago

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 https://docs.hypen.space/docs/adapters .

hypendev 1mo ago
>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 https://docs.hypen.space/docs/adapters Thanks, fixing that ASAP!

Rohansi 1mo ago

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

hypendev 1mo ago
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.

videogreg93 1mo ago

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.