[HN Gopher] Valdi - A cross-platform UI framework that delivers ...
___________________________________________________________________
Valdi - A cross-platform UI framework that delivers native
performance
Author : yehiaabdelm
Score : 449 points
Date : 2025-11-08 00:14 UTC (22 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| digianarchist wrote:
| > Valdi is a cross-platform UI framework that delivers native
| performance without sacrificing developer velocity. Write your UI
| once in declarative TypeScript, and it compiles directly to
| native views on iOS, Android, and macOS--no web views, no
| JavaScript bridges.
| justin66 wrote:
| "We've got both kinds. Country _and_ western!"
| jakobloekke wrote:
| Favourite Blues Brothers quote!
| joenot443 wrote:
| I was at Snap during this project's early days (Screenshop!) and
| spent a bit of time debugging some stuff directly with Simon.
| He's a wonderful engineer and I'm thrilled to see this project
| out in the open. Congratulations Snap team! Well deserved.
| IgorPartola wrote:
| Would you use this framework for a project today?
| hummusFiend wrote:
| Definitely one of the cooler projects to watch while I was
| there. I recall the goal was to open-source it from early on,
| so I'm glad to see it come to fruition!
| daveidol wrote:
| "Composer" ;)
| stuckinaloop wrote:
| Same! I've worked with Simon on this and tried (and failed) to
| port it to web. Truly a smart guy - and congratulations to the
| rest of the team!
| xmprt wrote:
| I'm surprised Snap of all companies invested in a cross-
| platform UI framework given how simple their app seems in
| comparison to more complex ones out there.
|
| And more importantly, Snapchat seems like an app which could
| highly benefit from tight integration with native features (eg.
| camera, AR features, notifications, screenshot detection, etc.)
| ingenieros wrote:
| Perhaps for the same reason we got Airbnb of all companies to
| create Lottie. https://lottie.airbnb.tech/#/
|
| These companies have super talented engineers and can afford
| to invest in skunkworks projects like these when they can't
| find any suitable options in the market.
| pols45 wrote:
| More like "super talented engineers" will keep increasing
| cost of such projects until they get told this stuff
| doesn't generate revenue/cost cutting is happening, so work
| more on ad tech, leave or find external free
| labor("community") to maintain it.
| ramraj07 wrote:
| As far as Im concerned, Snapchat is onw of the most
| complicated apps thats routinely used by hundreds of millions
| of people. You yourself listed all the features they have.
| And every one of them is pixel perfect, with insane amounts
| of time spent perfecting the user experience of every single
| ome of those features. In fact, the success of Snap could be
| attributed to how pixel perfect the app is.
|
| And then you call it simple?
| Alifatisk wrote:
| I share your opinion, but I think of the comment above like
| this. If something thinks your ui "just makes sense" and is
| dead simple to use, then you know you've perfected it. That
| is the best compliment you can get.
| xmprt wrote:
| You kind of just proved my point. If they want attention to
| detail and good performance then writing native is probably
| better. The simplicity that I was referring to was the
| number of views that need to be implemented. A cross
| platform UI framework would help if there were hundreds of
| views that needed to be built consistently but for the
| number of views in Snapchat, I think native implementations
| would probably be faster and cheaper.
|
| As for the "success of Snap could be attributed to how
| pixel perfect the app is". I think the success of Snap can
| be attributed to a lot of things. But if you took a look at
| how unoptimized the Android experience was in 2017 when it
| was taking off I don't know how you could call it pixel
| perfect.
| ramraj07 wrote:
| They famously DID NOT have any android app for a while.
| Contrary to what the Emacs HN keyboard warriors might
| think, the world actually used predominantly iPhone as
| the smartphone especially among the kids in the US. Their
| android experience didnt really matter.
| xmprt wrote:
| So once again... why focus so much on cross platform?
| You're glazing Snap a whole lot but not answering my
| question. I don't deny that they have some incredible
| engineering, but that's not a reason to invest a lot into
| a cross platform UI framework rather than just using
| something off the shelf like React Native or building the
| app natively to begin with.
| FridgeSeal wrote:
| Snapchat, an app which half-assed picture taking so hard that
| it did so by simply snapshotting the camera preview, rather
| than bothering to take an actual photo.
| mholm wrote:
| I'm not sure I trust snap of all companies to make a good cross
| platform framework after how terrible their android app has been.
| buffet_overflow wrote:
| I think it's been changed since, but wow was it weird finding
| out that instead of taking photos, the Android app used to
| essentially take a screenshot of the camera view.
| kridsdale1 wrote:
| I worked on the camera in Instagram iOS for a while. There at
| least, there could be a 5,000ms latency delta between the
| "screen preview" and the actual full quality image asset from
| the camera DSP in the SOC.
|
| I don't know a thing about Android camera SDK but I can
| easily see how this choice was the right balance for
| performance and quality at the time on old hardware (I'm
| thinking 2013 or so).
|
| Users didn't want the full quality at all, they'd never zoom.
| Zero latency would be far more important for fueling the
| viral flywheel.
| dmix wrote:
| > Users didn't want the full quality at all, they'd never
| zoom.
|
| Dating apps use awful quality versions of the photos you
| upload too. Seems to be good enough for most people.
| ahoka wrote:
| Must increase engagement, surely.
| cosmic_cheese wrote:
| Things have improved since then, but as I understand it, the
| technical reason behind that is that it used to be that only
| the camera viewfinder API was universal between devices.
| Every manufacturer implemented their cameras differently, and
| so developers had to write per-model camera handling to take
| high quality photos and video.
| greysonp wrote:
| I worked on the Snapchat Android back in 2017. It's only
| weird for people who have never had to work with cameras on
| Android :) Google's done their best to wrangle things with
| CameraX, but there's basically a bajillion phones out there
| with different performance and quality characteristics. And
| Snap is (rightfully) hyper-fixated on the ability to open the
| app and take a picture as quickly as possible. The trade off
| they made was a reasonable one at the time.
| yalok wrote:
| :) this is exactly how we used to do it even on iOS, back in
| the days before camera APIs were not made public, but Steve
| Jobs personally allowed such apps to be published in the iOS
| App Store (end of 2009) ...
| IshKebab wrote:
| That was the only way to avoid the insane shutter lag that
| was very common on Android phones at the time. It's called
| SnapChat not HoldStillForAMinuteChat so it made sense.
|
| Blame Google if you want to blame anyone. They could have
| mandated maximum shutter lag times (maybe they do now, I
| don't know).
| IgorPartola wrote:
| This looks promising. I would love to see more examples of what
| this can do along with screenshots. As is, there is a single
| Hello World and the components library is "coming soon". But if
| it can deliver what it promises that would be pretty cool. React
| Native is I think the main popular framework in this space.
| yieldcrv wrote:
| So this is like all those other frameworks that compile to native
| components, except this one is natively Typescript?
|
| I'll take it
| internetter wrote:
| I think? there isn't a typescript runtime? just a build time?
| I'm not positive how business logic gets executed but:
|
| > it compiles directly to native views
| rFlex wrote:
| One of the Valdi's authors here. It's using native views
| under the hood, like React Native, and there are 3 modes of
| compilation/execution for the TS source. It can be
| interpreted from JS (TS compiled to minified JS source),
| interpreted from JS bytecode (TS compiled to JS source,
| minified, then compiled to JS bytecode ahead of time), or
| compiled to native code directly (TS compiled to C ahead of
| time).
| mappu wrote:
| An AOT TS -> C compiler is fantastic - how much of the
| language is supported, what are the limitations on TS
| support? I assume highly dynamic stuff and eval is out-of-
| scope?
| rFlex wrote:
| Most of the TS language is supported, things that are not
| can be considered bugs that we need to fix. Eval is
| supported but it won't be able to capture variables
| outside of the eval string itself. We took a reverse
| approach than most other TS to native compiler projects:
| we wanted the compiler to be as compatible with JS as
| possible, at the expense of reducing performance
| initially, to make it possible to adopt the native
| compiler incrementally at scale.
|
| There are significant trade-offs with this compiler at
| the moment: it uses much more binary size than minified
| JS or JS bytecode, and performance improvements goes from
| 2x to sometimes zero. It's a work-in-progress, it's
| pretty far along in what it supports, but its value-
| proposition is not yet where it needs to be.
| noveltyaccount wrote:
| Can this compiler be used outside of Valdi? TS to native
| AOT sounds incredible.
| maxdo wrote:
| Not to troll , Do you need such shims in the era of llm ?
| internetter wrote:
| Yes? Dear lord I want determinism
| prmoustache wrote:
| by llm you surely mean tech debt generators right?
| lrei wrote:
| tech debt generator - another job AI is taking away from
| humans!
| tclancy wrote:
| I'll finally accept I've been replaced when they start
| leaving #TODO notes to themselves that never get fixed.
| Y-bar wrote:
| Not every user interface need to become a LLM chat app.
| sans_souse wrote:
| So now I can finally implement the most god-awful, ugly,
| cumbersome and unintuitive GUI methodology ever to face a large
| population of users into my own apps? This abomination that
| started the whole user-experience decline by making this kind of
| yuck the gold standard for apps today is finally open source?
|
| Color me yellow.
| Neywiny wrote:
| I hope it has "load spam ads directly into the list the user
| was about to touch somehow the millisecond before they touch it
| using magical force field technology so they click the wrong
| thing every time" functionality. I've been missing that in my
| apps
| sans_souse wrote:
| Now offering 4 swipe directions!
| sgc wrote:
| With instant, subpixel precision!
| hippo22 wrote:
| God forbid someone try something different. The app isn't
| really made for people that only know how to doom scroll.
| ramraj07 wrote:
| Snap is the greatest innovator of user experiences in this
| generation. This is evidenced by the fact that literally every
| other social media app is just a hodgepodge copycat of sorts of
| what snap invented. For people who introduced themselves to
| tech with snap as one of their first apps, its the most
| intuitive thing ever.
|
| When they first introduced video calls, schools had to close
| for a day.
|
| Imagine then you come here and see someone calls it awful.
| Can't help but think its just an instance of "old man yelling
| at clouds".
| Jyaif wrote:
| > For people who introduced themselves to tech with snap as
| one of their first apps, its the most intuitive thing ever
|
| By definition, the first app someone uses will be from their
| POV the most intuitive app ever. It will also be the least
| intuitive app ever.
| sans_souse wrote:
| All valid points. Made me actually think about the likely
| first actions an alien or newborn would take with a 2025
| touch screen device. Chomp. Chew. Swipe.
|
| xD
| sans_souse wrote:
| Don't take me argument as one against the point that it was
| massively popular and influential, en contraire, that's often
| the common factor in things I tend to dislike: the norm/ the
| mainstream.
|
| It's mostly subjective when talking UI, and a lot plays in
| too regarding the lack of competive platforms with different
| UI's.
| ramraj07 wrote:
| My point is that (I think) they became popular because of
| their UI and UX. They remagined how a small touch screen
| user experience could be most intuitive if you dont come
| with legacy mindset. For people used to keyboard and mice
| this might look weird but snap makes sense to the newer
| generation.
|
| If all the other apps look similar its because they copied
| it. This is like calling Citizen Kane boring.
| FridgeSeal wrote:
| > have userbase
|
| > introduce feature
|
| Phwoar, ground breaking UX design there!
|
| > When they first introduced video calls, schools had to
| close for a day.
|
| Which schools, where? Are they in the room with us now?
|
| > For people who introduced themselves to tech with snap as
| one of their first apps, its the most intuitive thing ever
|
| Point camera. Press button. Pick users.
|
| Gotta try real hard to screw that one up, UI wise.
| ramraj07 wrote:
| I suppose you're just salty they didnt make a linux app.
| mrweasel wrote:
| It's a really wonky app. The main feature works fine, no issue.
| Their "Stories" section, I can't can navigate that at all,
| there a no hint to how it works, so I don't use it. Seems a
| little weird, given that this is where the ads are, why
| wouldn't Snapchat make that easier to use?
|
| There's also views I can get into which I can't figure out how
| to leave, so I force close the app to get back.
|
| I don't necessarily think that's a flaw of the framework, just
| how Snapchat designs their app.
| instagary wrote:
| I wish the native iOS part was written in Swift rather than
| Objective-C like RN.
| samtheprogram wrote:
| Why though? You aren't interacting with it. What difference
| does it make?
| adastra22 wrote:
| How are you not interacting with it? It's a UI library, no?
| littlecranky67 wrote:
| You are using the components, not interacting with that 3rd
| party code. Unless you are debugging/contributing back
| Julien_r2 wrote:
| If the framework is used, eventually there will be 3rd party
| lib adding new features (from the top of my mind, maps), and
| someone will need to write the bridging with the native SDK.
| It means the bridge will most likely need to be written in
| objective-C instead of Swift
| bearjaws wrote:
| Working at a company that uses react-native I wish nothing more
| than for the end of app stores and differing platform languages.
|
| We're heavily considering just having a website next year with a
| mobile app using webview, and then native code for the native
| notifications, GPS and healthkit / health connect.
|
| I feel like AI is changing the equation, its nearly better to
| write your business UI 3 times one for each platform.
| FlamingMoe wrote:
| Wholeheartedly agree.
| DecoPerson wrote:
| I did this and never looked back.
|
| It's called a "WebView app" and you can get a really good
| experience on all platforms using them. Just:
|
| - don't make any crazy decisions on your fundamental UI
| components, like breadcrumbs, select dropdowns, etc
|
| - add a few platform-specific specialisations to those same
| components, to make them feel a bit more familiar, such as
| button styling, or using a self-simplifying back-stack on
| Android
|
| - test to make sure your webview matches the native browser's
| behaviour where it matters. For example, sliding up the view
| when the keyboard is opened on mobile, navigating back & forth
| with edge-swipes on iOS, etc
|
| I also went the extra step and got service workers working, for
| a basic offline experience, and added a native auto network
| diagnostic tool that runs on app startup and checks "Can reach
| local network" "Can reach internet (1.1.1.1)" "Can resolve our
| app's domain" etc etc, so users can share where it failed to
| get quicker support. But this is an app for small-to-medium
| businesses, not consumer-facing, and the HTML5 part is served
| from the server and cached. I haven't thought much about what
| you might need to do additionally for a consumer app, or a
| local-first app.
| arcanemachiner wrote:
| I made a (hobby) project that utilized this strategy (Flutter
| + wrapped webview app), and it honestly seems like the way to
| go for my needs.
| sebmellen wrote:
| Works until you need complex native code for things like
| automatic image capture assisted by a bounding model.
| littlecranky67 wrote:
| There is no reason you can't do that via web. Image capture
| in a canvas gives you access to the raw image pixmap data.
| adastra22 wrote:
| I have never once experienced a WebView app that I would say
| had "a really good experience."
| serial_dev wrote:
| It's because if a webview app experience is good, you don't
| notice it, you only notice if it's bad.
|
| A while ago saw a blog link on HN that explained how Apple
| uses it everywhere and we never notice it because they are
| done well. Of course I can't find that link now, I summon
| the HN gods...
| smokel wrote:
| Is this what you mean?
| https://news.ycombinator.com/item?id=45250759
|
| (In the context of "Apple has a private CSS property to
| add Liquid Glass effects to web content")
| serial_dev wrote:
| Yes, thank you!
| hn8726 wrote:
| > It stands to reason that Apple wouldn't have developed
| this feature [liquid glass css property] if they weren't
| using it. Where? We have no idea. But they must be using
| it somewhere. The fact that none of us have noticed
| exactly where suggests that we're interacting with
| webviews in our daily use of iOS without ever even
| realising it.
|
| There's some jump from _a property exists_ to _it must be
| used_, but a massive one from _a property exists_ to
| _Apple uses it everywhere and we never notice it because
| they are done well_.
| jmb99 wrote:
| > It's because if a webview app experience is good, you
| don't notice it, you only notice if it's bad.
|
| Aside from Apple's apps (which imo _are_ noticeably worse
| than the old ones, but that's beside the point), what are
| some good WebView apps on iOS right now?
| la_fayette wrote:
| Somebody scraped the play store and checked the
| framework, so a list for Android WebView apps, built with
| capacitor, is here: https://capgo.app/top_capacitor_app/
| Maybe an equivalent is there on iOS for the same app...
| riderx wrote:
| Sadly i couldn't find a reliable way to do it on Apple
| Store, it's pretty hard to download from the store
| outside of apple device. If anyone know how i can do it
| too
| la_fayette wrote:
| It might not be possible but others have scraped just the
| app store and matched based on Android meta data: https:/
| /people.ece.ubc.ca/amesbah/resources/papers/mobilesof...
| fluidcruft wrote:
| lichess is really good. Thanks for the info, I'm not
| surprised to learn it's a webview app, but it is really
| good.
|
| It doesn't look native but who even cares. I think when a
| UI sucks or is unintuitive or buggy then "it's not
| native" is a sort of catchall easy complaint. Native is a
| crutch. Sometimes it's a good crutch (accessibility etc).
| But that's more about developer efficiency and bare
| minimums of polish.
| crossroadsguy wrote:
| Yes, Apple's apps are really really bad - including the
| app store. I am not even sure whether that app store can
| be considered a stand alone app or we should call it part
| of the OS.
|
| A webview app is by design bad. Webviews were made for
| one thing - web views.
| riversflow wrote:
| The app store is the only application that I am aware of
| that you can't find through spotlight search. You can
| search the app store directly from spotlight search, but
| it will never list the App Store as an app. Very
| annoying.
| adastra22 wrote:
| I just opened spotlight and typed "ap" and App Store came
| up as the first option.
| hn8726 wrote:
| Maybe this https://blog.jim-nielsen.com/2022/inspecting-
| web-views-in-ma... and
| https://news.ycombinator.com/item?id=30648424?
|
| On mobile the webview app experience is crap and it's
| immediately obvious that an app is not native. Simply
| nobody asks customers how they like it. The management
| assumes that as long as nobody complains and the users
| don't leave in droves, the experience must be impeccable.
| dietr1ch wrote:
| It's often easy to tell, but my concern has shifted from
| "Why isn't this native? It's ugly/slow" to "Why isn't
| this a goddamn webpage? It can't justify neither its
| permissions nor its space".
| csomar wrote:
| Can you give examples of good webview apps on iOS?
| troupo wrote:
| > Apple uses it everywhere and we never notice it because
| they are done well.
|
| Done well as in: laggy, non-performant, break OS
| conventions and you can see elements load with the naked
| eye?
|
| See App Store as an example:
| https://grumpy.website/post/0RsaxCu3P or Apple Arcade:
| https://grumpy.website/618 or...
| Maken wrote:
| The Arcade video, taking several seconds to load a few
| low resolution images, causes me pain.
| jonplackett wrote:
| If Apple are using it for the AppStore - then I defo
| Italy do notice it. The AppStore runs so badly.
|
| I would be interested in any links to Webview apps that
| run really well, I've never seen one that I'm aware of
| but so many that I am aware of and are bad!
| risyachka wrote:
| Not really. The difference between high quality web app
| and native app is very noticeable.
|
| And between average native and average web view - it is
| night and day.
|
| 99% of web apps in _desktop_ browser are laggy. And on
| mobile it feels like crap.
|
| Sure if you are an expert in top1% you can probably get
| it working really good. But this is true only for 1 in
| 100 if not less.
| LtWorf wrote:
| A webview app can be good, but finding one is harder than
| finding russel's teapot :D
| rayiner wrote:
| Apple's app experience has also been going in the toilet
| for the last five-six years so there's that. It's like
| slowly boiling the frog.
| adastra22 wrote:
| It is immediately obvious when you are using a web view
| app, as it uses browser layout and non-native controls.
| And I have never found one to be as intuitive or nice an
| experience as native controls.
| creichenbach wrote:
| I've done it before on a personal project and I was pretty
| obsessed with user experience. For example, I changed the
| way buttons work (because they were natively links with
| Cordova, which trigger upon tap, not "finger lift", like
| native buttons). Also, implemented some gestures to e.g.
| switch between pages (tab-style navigation). While not
| really in line with system UI (wasn't my goal), I think
| usability is quite decent.
|
| In case you're interested, the app is named "QuickOV" - not
| relevant to anyone outside Switzerland, but just for trying
| it out: https://play.google.com/store/apps/details?id=com.b
| illhillap...
| erlend_sh wrote:
| I use Voyager, a client for Lemmy, on a daily basis and
| it's my favorite mobile (iPad) app. Voyager is the
| spiritual successor to the Apollo client for Reddit.
|
| https://github.com/aeharding/voyager
|
| The app uses Ionic's Capacitor, which to my rudimentary
| understanding is the webview-based upgrade of Cordova. I've
| had far fewer issues with this app than the likes of
| Bluesky (react native) and Discord (I think also react
| native but not sure).
|
| The webview approach seems to be the only way for a one-
| person team to feasible provide a cross-platform app with
| an app-store presence. Another promising alternative to
| Capacitor is Tauri Mobile which does essentially the same
| thing, but mobile doesn't seem to be a high priority for
| them.
| kevinak wrote:
| Like GP I haven't experienced many WebView based apps
| that are great so I had to give this a spin and I have to
| say it's actually pretty good! I would not have
| identified this as a WebView app if I didn't already know
| about it from this comment.
| hn8726 wrote:
| I installed this on Android, and unless iOS experience is
| massively different, this is not a good example:
|
| - there's no touch feedback (ripple) on many of clickable
| components. Some that do have it look non-native,
| inconsistent and sometimes gets stuck
|
| - the search bar on top app bar in `search` tab looks
| very non-native and non-standard (it's elevated on top of
| elevated app bar already)
|
| - the lists look iOS-y, especially settings
|
| - the settings list item has weird glitch where it loses
| background after touching (but not clicking)
|
| - collapsing comments is pretty choppy (on a Samsung S25
| so a pretty powerful phone)
|
| - can't swipe down a bottom sheet (with post
| options/actions)
|
| - it's just not android-y -- the navigation is weird, the
| design is all over the place,
|
| It's not unusable and it's a good tradeoff for a small
| team I guess. But this is nowhere near the experience a
| native app can provide, and has lots of small papercuts
| that would make for at least a slightly frustrating
| experience. It is a decent app don't get me wrong, but
| it's clearly not native
| adastra22 wrote:
| You are comparing web view apps to web view apps. "React
| Native" has muddied the waters here with intentional
| misuse of terminology. With React Native you still write
| a web view app - it just ahead of time compiles to run
| without the browser view on device. But it doesn't use
| any native UI components, which is what "native app" used
| to mean.
| hjort-e wrote:
| Do you use iOS by any chance? On android I've very noticed
| performance problems. Even in apps like Discord and
| Instagram. But Google maps and Duolingo are pretty bad at
| times for example. So it's not webviews that are the common
| denominator here
| kelvinjps10 wrote:
| Obsidian. In android it's the best markdown editor.
| torginus wrote:
| I have experienced the opposite with Zed, which has its own
| bespoke UI framework - it behaved somewhat unexpectedly and
| didn't work exactly how I'm used to an UI to behave giving
| me this uncanny feeling.
|
| This kinda shows you how much effort and experience goes
| into getting an UI framework right, and the long tail
| quirks (of which there are a zillion) matter for UX, and
| while I appreciate they took on the task of breaking away
| from the browser, it's understandable why someone wants to
| ship an app on time and budget goes with a web based
| solution.
| adastra22 wrote:
| Zed isn't native either. As you said, it uses its own
| bespoke UI framework with custom widgets.
| sheepscreek wrote:
| Well you haven't used the cutting-edge latest breed. Try
| using Uber in a browser. There's many high-quality apps
| today where you honestly cannot tell that it's a website
| running in a browser. There are many many more but I can
| only think of Uber off the top of my head.
| simjnd wrote:
| What is your app? Would love to try it out to get a feel for
| the experience.
| lenkite wrote:
| Do you use some framework for "WebView app" ? Like Tauri, etc
| ? Or is everything coded from scratch ?
| fakedang wrote:
| Perhaps you mean PWAs and not WebView apps? WebView apps suck
| big-time.
|
| At least now I know who the offending devs are.
| tiborsaas wrote:
| Isn't there a high chance your app is going to be rejected
| from app stores because you use a web view? You can change
| your whole app completely upon approval.
|
| Or you ship your HTML/JS and not just embed a URL?
| hjort-e wrote:
| It's mostly shipped with the web assets. But yes that would
| make it very difficult to get approved by Apple. Not by
| Google though
| gcanyon wrote:
| Gathering all the metaphors (I know) here for reference:
| - "All toupees look fake. I've never seen one that I couldn't
| tell was fake." [1] - All CGI in movies looks fake. It
| jumps out at me every time I see it." - All WebView
| apps suck. Every one I've seen has a bad obviously-web-
| derived UI.
|
| re: that last one though -- I'd at least acknowledge that
| WebView apps are roughly at the end of the early-2000's era
| of CGI: not exactly "The Rock in The Scorpion King" bad, but
| generally not at the level of Avatar or Les Miserables.
|
| 1. https://news.ycombinator.com/item?id=45250878
| mesm3 wrote:
| Using webviews on native platforms can look very appealing
| from a management perspective: a single codebase, simpler
| coordination, reduced UX overhead, and faster iteration
| cycles.
|
| However, from the user's side, this approach often results in
| a buggy, inconsistent experience that lacks the
| responsiveness and smoothness of a true native app that
| elusive "snappy" feeling (i know, I hate that word too)
|
| Companies usually choose this route because it's cheaper, but
| that same "cheap mentality" often seeps into the overall
| product quality. Corners get cut, bugs get ignored, and long-
| term maintenance becomes a mess.
|
| From a developer's perspective, it's a nightmare You're
| essentially expected to deliver on three platforms doing the
| work of three people for the same $ In theory, any web
| developer could handle it. In practice, you need to
| understand all the native platforms just to maintain some
| basic, stable integrations even with frameworks like React
| Native.
|
| The result? Maybe 20% of your time goes into actual feature
| development, 30% into testing, and the remaining 70% into
| fixing obscure, platform-specific bugs while working overtime
| under pressure from cost-driven management.
|
| In my experience, developers will do almost anything to avoid
| dealing with the native parts of this kind of setup those
| tasks usually get dumped on whoever is most "familiar" with
| native, because it's such a pain to handle.
|
| And let's not forget QA testing across these hybrid layers is
| an absolute nightmare as well.
|
| In the end, my view is simple: If a company can't afford
| dedicated native teams, they probably shouldn't build a
| native app. (Of course, smaller apps with limited complexity
| should be fine)
| cyberax wrote:
| That. And specifically, fuck Apple and their prohibition on
| JITs.
|
| We have a React Native app that shares some code with a webapp,
| and that needs to do some geometry processing. So we're
| constantly playing the game of "will it interpret quick
| enough". Everything works fine in browsers, but in a RN app it
| often slows down to unusable speeds.
| Torn wrote:
| Could your processing work in a webview? i.e. webgl or webasm
| or similar and you communicate with it via postMessage.
| Something like Polygen might help with the scaffolding, but I
| have not tried it personally
| cyberax wrote:
| No, it's far too brittle. The latency is also terrible. In
| our case, we had to reimplement some parts in C++ to have
| reasonable performance.
| rTX5CMRXIfFG wrote:
| I personally have a preference for Apple's native frameworks.
| From a purely engineering standpoint, they're very well thought
| out and have very clear separations of concerns. Spending my
| time with their libraries helped me write good, scalable code
| for platforms beyond their own.
|
| That said, platform lock-in is bad for business because it
| makes operations dependent on a single provider, but I have no
| delusions that a web front-end is better.
|
| From an engineering standpoint, front-end web frameworks are
| less complete and require too many third-party libraries and
| tooling to assemble. From a UX standpoint, it's actually worse
| --almost every website you visit today spams you upfront with
| Google sign-in and invasive cookie permission requests that you
| can't refuse. But never mind that--from a purely business
| standpoint, a single platform accessible anywhere saves costs.
| Most importantly, however, the web is a "safe space" for
| deploying software anti-patterns without an intermediary entity
| (i.e an app store) to police your code, so you can do whatever
| the heck you want.
|
| I'd wish for nothing more than the end of web and app front-
| ends in favor of purely structured data derived from natural
| language prompts by users. However, the more realistic mindset
| seems to be that: the front-end layer is such a high level of
| abstraction with a very low barrier to entry, so that its tech
| stack will be in constant flux, in favor of whoever's currently
| the best-financed entity seeking the most market share, the
| most developer mind-share, and the most behavioral control
| among its users.
| blub wrote:
| It's a bad idea to put the fox (front-end developers) to guard
| the henhouse (great, consistent user experiences).
| khalic wrote:
| lol, yeah what do front ender devs know about UX. SMH...
| zelphirkalt wrote:
| Unfortunately, all too often not enough. But then again
| often one has UX designers for that, but they are all too
| often off to build flying castles in Figma.
| zdragnar wrote:
| Visual design is only one part of UX- interaction design
| and information architecture are equally important
| components.
|
| At my last two jobs, when I did v front end work I had to
| coach designers through UX on a regular basis, because
| the designers did as much for the marketing department as
| they did for the development team.
|
| Sadly, UX as a discipline doesn't get much love from most
| companies.
| array_key_first wrote:
| Most of UX design for the past ~15 years has been new and
| innovative ways to trick users, lie without really lying,
| and annoy your users _just enough_ so you can extract what
| ever you need to extract, but not too much such that they
| actually leave.
|
| If you want to create good UX, I would look at whatever the
| big dogs are doing (Amazon, Meta, Google, et. al.) and
| _not_ do that.
| bigstrat2003 wrote:
| In my experience? Very, very little.
| DeathArrow wrote:
| Then why bother making an app? The user can access the web app
| using the browser.
| johnisgood wrote:
| We (they) wanted "easy accessibility" and "constantly seeing
| this app's icon" bs.
| yetanotherjosh wrote:
| So you can get native behaviors when it's critical. Like
| share sheets, push and many other critical features that only
| apps get even if the bulk of the experience can be done in a
| webview. This is because mobile OS platforms choose not to
| make these available to web apps, because app store profits
| are better for them than an open ecosystem where sites can do
| the same things as apps.
| hjort-e wrote:
| Both the things you mention have been possible on web and
| widely supported for a while.
|
| https://developer.mozilla.org/en-
| US/docs/Web/API/Web_Share_A...
|
| https://developer.mozilla.org/en-US/docs/Web/API/Push_API
|
| And not having to wait a week between bug fixes being
| deployed is a major selling point that native just can't
| compete with.
| logicprog wrote:
| CapacitorJS makes for a REALLY awesome app dev experience
| compared with React Native. It's basically just a really well
| integrated system for building exactly what you describe. The
| company I work at made the switch from an RN app to a CJS one
| and it was might and day in so many ways, performance included!
| mexicocitinluez wrote:
| How is this different than Expo?
| isaachinman wrote:
| This is laughably wrong. Expo exported to a web target is the
| same or better than Capacitor.
| _kidlike wrote:
| we shipped this last year. Best decision ever.
|
| I saw another comment calling it "webview app", which is also
| valid, but we call it "hybrid app".
| saubeidl wrote:
| You could just use Kotlin Multiplatform and Multiplatform
| Compose instead.
| maxloh wrote:
| I recently downloaded the Moodle app and was surprised to find
| it's powered by Ionic and a webview, which I only realized due
| to CSS misconfigurations that caused the app to fall back to
| Serif font for CJK glyphs.
|
| Recent mid-tier phones are powerful enough that webview has a
| negligible impact on performance.
| sandGorgon wrote:
| https://developer.android.com/develop/ui/views/layout/webapp...
| Razengan wrote:
| Using apps made with Electron or those so-called "universal" UI
| frameworks I wish nothing more than for everything to be
| native.
|
| They always have to give up some basic or hidden conveniences
| that native controls get for free, so they always feel slightly
| different and "off" in a weird way which induces a constant
| vague annoyance while using them, like walking with a little
| pebble in your shoe, or a sitting in an chair that isn't
| balanced right.
|
| It's funny how even after 50 years UI still isn't "solved"
| ..before writing a universal API, we don't even have universal
| consensus, or at least some kind of standards authority, on how
| controls should behave.
|
| Hell not even users can't agree, as would be seen on any
| comments about this topic, on stuff like whether lists should
| scroll up when swiping down, or scroll down when swiping up :')
| scosman wrote:
| I try this every decade. Love the first few months for speed.
| Then I end up paying the price later when I want to integrate
| "new OS feature X" or make a system gesture/style/animation
| feel native.
|
| Lack of swipe for back on iOS is usually the easiest way to
| tell I'm looking at a web view.
|
| But it's been about a decade so I'm due...
| qw wrote:
| Swipe to go back can be implemented in frontend.
|
| It's been a couple of years since I used it, but I think the
| Ionic framework has this feature.
|
| https://ionicframework.com/
| hjort-e wrote:
| Lack of swipe back actually isn't an indicator. Apple doesn't
| even follow that pattern everywhere
| port11 wrote:
| I see some downvotes but you're correct. For example, in
| the App Store feature cards swipe left only bounces the
| card, you have to keep swiping to close. Swipe down closes
| it at once. It's not that far from the usual but has always
| felt strange to me. This same gesture won't close Home's
| new accessory card.
| myko wrote:
| Isn't the App Store heavily webview based? Apple doesn't
| follow it but one of the complaints in this thread is
| that Apple has been overusing WebViews
| Alifatisk wrote:
| Isn't this how Hotwire works with Rails?
| geokon wrote:
| that only works if you have a simple app that displays some
| stuff from a server.
|
| if you want to do something actually requires some compute,
| then suddenly this doesnt work so great
|
| ex: youre prolly not going to want to edit images in JS
| officialchicken wrote:
| The <canvas> tag using webgl offers a lot lower access to
| buffers than you might imagine and is very accessible using
| JS/DOM. I've gotten surgical AR devices approved from FDA -
| if it works good enough for life or death situations - it can
| certainly work for a toy app.
| seanwilson wrote:
| > its nearly better to write your business UI 3 times one for
| each platform.
|
| Anyone have any experience of doing this for a complex and
| long-life app?
|
| Sounds like a nightmare that would increase friction and
| decrease development fun by x10 because of the huge overhead
| and tedium of having to keep your features and tests in sync
| across platform for every change you want to iterate on, and
| requiring developers be proficient at multiple stacks.
|
| I get the usual complaints about bad webview implementations,
| but separate native codebases sounds like a prohibitively
| enormous tradeoff if most users only perceive the UX as being a
| little better than a good webview implementation. I feel like
| I'm missing something that native codebases is suggested as if
| it's a simple alternative, or this is coming from people that
| aren't actually involved in this?
| skydhash wrote:
| You don't do that though. You write your logic in a common
| languages and then the UI is an external layer you switch
| with build settings. The thing is, yiur choice is usually
| c|c++. Or an embedded language like lua. RN has gone the
| latter route and then extend it further by using React as a
| DSL for the UI.
| seanwilson wrote:
| > You write your logic in a common languages and then the
| UI is an external layer
|
| Isn't reimplementing all your UI widgets, views, layouts
| and interactions for multiple platforms still a ton of work
| though? I'm not meaning people using things like React
| frameworks, but the suggestion of sticking to native only.
| skydhash wrote:
| If you do that, then you intent to take advantage of the
| native framework (or a mature one like qt for some
| platform). They are really expansive and you can create
| an interface very quickly. You usually get animations,
| themability, navigation,... for free and you're mostly
| arranging the layout and writing glue code.
|
| Also, you usually get better tooling in regards to
| instrumentation and the like.
| baduiux wrote:
| I can share a bit on this one. I'm doing hybrid apps for the
| last 8 years and stick to Cordova on my day job but also
| tried Flutter and RN for a bit. As I've seen some other
| comments about the iOS/Android look and feel (swiping
| gestures, etc.), Ionic (or the Cupertino package in Flutter)
| is the way to go. Without this, it would be a lot of trouble.
| However, as the recent iOS 26 update has shown, neither Ionic
| nor Flutter is going to support the new liquid glass design
| (yet). Since we never went with "our app must exactly match
| the (apple) design guides" this is not a problem for us but
| I'm sure others would love to be able to adapt the new liquid
| glass style. I also never heard of any app being rejected due
| to being a hybrid app or not having the correct look and
| feel. Of course, you might see/feel that it's not a native
| app but who cares. Back in the days we even used a OTA plugin
| (it was a MS plugin, don't remember the name) to
| automatically ship new .js/.html files without going through
| the review process. If I remember correctly Ionic still
| provides something like this.
|
| When it comes to native stuff it get's tricky. As always it
| really depends on the use case of the app. In our case we
| develop a navigation app using a native SDK to show a map +
| turn-by-turn nav + offline maps etc. This is probably the
| most non ideal use case for a hybrid app. We developed a few
| plugins to share data between js /native to initialize the
| map etc. However, the idea of sharing business logic is long
| gone. There's so much stuff that's happening natively and
| each time we implement it on Android, we have to switch to
| iOS and implement the Swift version of it.
|
| Some others have also mentioned that a single person now has
| to know three platforms (iOS, android and Cordova (in our
| case with ionic + angular). This is true and the real
| downside. I'm quite familiar with iOS and android yet I'd
| never call myself a native iOS / Android developer. Yet, I've
| to write so much native code regarding permission handling,
| geolocation, threading (Ui/non-ui) and there's always a ton
| to stuff happening from version to version (e.g. 16 KB Page
| Size on Android, iOS support for rotation the device/adaptive
| layout on iPadOS, etc). This is where a lot of time is lost.
| And the time is not only lost there but also with
| unmaintained outdated community plugins you suddenly need to
| understand and fix.
| nwienert wrote:
| [delayed]
| j45 wrote:
| It's rarely better to write the business UI 3 times for each
| platform.
|
| At the time such decisions are made, maybe the platforms
| couldn't do what was needed, but those platforms do tend to
| evolve, but not remain tracked.
|
| Flutter to me has been one of the platforms that can quietly
| ship to multiple platforms as long as the parameters of what
| you're after can be accomplished in Dart, and if needed a bit
| of custom code for any particular platform.
| flanbiscuit wrote:
| Is Cordova still actively developed? Or are people just rolling
| their own per OS these days?
| bob1029 wrote:
| If you still need to wrap a cross-platform web experience in a
| native container, I really begin to lose the plot. Once you are
| engaged with the iOS code signing monster, you might as well go
| all the way into the ecosystem.
|
| To me, the web is the way _around_ the app stores and codesign.
| I know how to visit HN on my iPhone despite there not being an
| official native app for it. It _can_ work. The challenge is
| making it work in your particular case. Fear that the user wont
| know how to access the product seems to be a primary factor
| driving hyperbolic takes on how consumer apps must be built.
| Perhaps a bit of marketing budget (scan this QR code / visit
| this link) could eliminate a very expensive tech problem. Why
| fight visibility in the crowded App Store when there are
| countless other advertising channels you could pour your
| resources into?
|
| > native code for the native notifications, GPS and healthkit /
| health connect.
|
| Modern web can address everything here but the HealthKit item.
| You could consider handling this with a simple companion
| application that is exclusively about the collection and
| transfer of the data while respecting user privacy & consent
| procedures.
| exhaze wrote:
| Push notifications and mental real estate by being "an app"
| are the primary business reason (based on both statsig
| experiments I've seen across my career as well as some
| intuition about behavioral psychology regarding the app
| mental real estate bit).
| ojr wrote:
| AI doesn't change the Apple Guidelines, I write my business UI
| once and translate it between React Native and React using an
| LLM
|
| 4.2 Minimum Functionality Your app should include features,
| content, and UI that elevate it beyond a repackaged website. If
| your app is not particularly useful, unique, or "app-like," it
| doesn't belong on the App Store. If your App doesn't provide
| some sort of lasting entertainment value or adequate utility,
| it may not be accepted. Apps that are simply a song or movie
| should be submitted to the iTunes Store. Apps that are simply a
| book or game guide should be submitted to the Apple Books
| Store.
| rock_artist wrote:
| With the first iPhone Steve Jobs wanted a web based future.
| Then jailbreaking got us native apps and AppStores and the rest
| is history.
|
| I still remember my Nexus One running flash!
|
| Anyway, I wonder if the web path would've been the chosen one,
| how Apple would've played the web standards that are crippled
| today especially on Safari.
| culi wrote:
| Would love to see it. Even Apple's support for PWAs has come a
| long way. Still can't list them on the app store though
| sreekanth850 wrote:
| Not related to this, but abandoning Key DB was the worst thing
| they could do.
| topherPedersen wrote:
| This is so cool! I'm a React-Native developer, and I'm glad to
| see more options like this coming into existence.
| topherPedersen wrote:
| Rename it Snapp
| skeptrune wrote:
| Its hard to imagine not going fully native in the modern day with
| coding agents. Most of the code can just be clanked out.
| ramraj07 wrote:
| If your entire company is all about making a single good app, I
| doubt having AI changes the architecture much. Its still an
| architectural decision of whether you're going to have a single
| codebase for your app and focus on a framework to transpile it.
| Either way you need actual teams of experts on iOS android etc,
| no single person is going to master all of them.
| bigstrat2003 wrote:
| Yeah, with coding agents you can turn out a buggy mess 10 times
| as fast!
| maxloh wrote:
| If you are curious how components' state is handled, they
| employed the React class components method: //
| Import the StatefulComponent import { StatefulComponent }
| from 'valdi_core/src/Component'; // ViewModel +
| State interfaces for component export interface
| TimerViewModel { loop: number } interface TimerState {
| elapsed: number } // Component class export
| class Timer extends StatefulComponent<TimerViewModel, TimerState>
| { // Initialize the state state = { elapsed: 0 };
| // When creating the component, start a periodic logic
| private interval?: number; // Initialize the
| setInterval that will update state once a second incrementing
| // the `elapsed` state value. onCreate() {
| this.interval = setInterval(() => { // Increment the
| state to trigger a re-render periodically const
| elapsed = this.state.elapsed; const loop =
| this.viewModel.loop; this.setState({ elapsed:
| (elapsed + 1) % loop }); }, 1000); }
| // When component is removed, make sure to cleanup interval logic
| onDestroy() { if (this.interval)
| clearInterval(this.interval); } // Render
| visuals will depend both on the state and the view model
| onRender() { <view padding={30}
| backgroundColor='lightblue'> <label value={`Time
| Elapsed: ${this.state.elapsed} seconds`} />; <label
| value={`Time Looping every: ${this.viewModel.loop} seconds`} />;
| </view>; } }
|
| https://github.com/Snapchat/Valdi/blob/main/docs/docs/core-s...
| Liquidor wrote:
| I miss the React class components. No need for 30 different and
| error prone useFunctions
| simianwords wrote:
| I often wonder how the economics are justified in making in house
| frameworks. What is it about Snapchat that requires a new
| framework but not other apps?
| barnabee wrote:
| Given the user hostility of Google and Apple (and the rest) and
| the rate at which they emulate competitors and try to crush
| them, I'd start at a small library or framework and not stop
| until I had a whole OS.
| austin-cheney wrote:
| As opposed to what? As opposed to not using a framework or
| using some other framework?
|
| Using frameworks is expensive by orders of magnitude. It's
| additional code which greatly increases tech debt and slows the
| execution time of the given product pretty significantly. Think
| about it like this: a business with high confidence developers
| can ship a new SPA in a tenth of the time just using vanilla
| JavaScript that fully renders to screen with complete state
| restoration across the internet in less than a quarter second.
| That also means the business saves boat loads of cash by
| shipping faster, experimenting against its user's behavior, and
| needing only a quarter of the headcount. So, where do you find
| these people and how do you retain them?
|
| The economics are pretty simple and completely
| offensive/hostile to the developers. It's ultimately about
| hiring and firing. Developers are a cost center to the business
| so the goal is to always eliminate training and turn them into
| a replaceable commodity. That's it. That developers believe
| this is somehow a great empowerment is a double win for the
| employer.
|
| The reason a company might introduce a new framework is because
| they encounter a problem not immediately solved by existing
| frameworks. The more frequently that same problem occurs the
| more a new framework pays for itself.
| jeremyjh wrote:
| So developing a project with a framework takes 100x longer
| than using "vanilla javascript"? That is not my experience.
| austin-cheney wrote:
| Not only does it take dramatically longer it also requires
| dramatically more people, which perfectly aligns with the
| Brooks's Law.
| pzo wrote:
| Valdi seems very similar in concept to React Native but Meta
| being the biggest competition to them you unlikely gonna depend
| on that even if better. Same reason ByteDance (Tiktok) doing
| Lynx.js (also similar to Valdi and React Native and also based
| on React).
|
| The only FAANG scale companies that adopted React Native are
| Microsoft and Amazon because they aren't directly competing
| with Meta.
| GaryBluto wrote:
| I cannot possibly think of something I would want to use less. A
| Snapchat-developed UI framework where communication is done via
| Discord sounds like something carefully designed to repulse me.
| noitpmeder wrote:
| Tons of software projects have moved their communities to
| discord. Not saying it's a great thing, but you're self
| selecting out of the future.
| GaryBluto wrote:
| If the future is unable to think critically, I'll stay in the
| past.
| nomdep wrote:
| What would you use instead?
| GaryBluto wrote:
| Self-hosted forums, github's built-in forums, IRC;
| Practically anything but Discord.
| 0manrho wrote:
| Just because everyone is doing it doesn't mean it's a good
| idea, or that we should just shut up and accept it. That's
| the non-monied part of how enshittification proliferates:
| "Well everyone else is doing it!" "It's the future, get with
| the times and deal with it"
| 0manrho wrote:
| I wholeheartedly agree for the same reasons, and I even use
| discord a lot (for personal/social reasons, not for
| support/business reasons).
| FridgeSeal wrote:
| Ah yes, Snapchat, an app famous for its high performance,
| efficient apps, which definitely never made your phone hot and
| drained your battery.
|
| Seriously, if there's an app that sticks in my head for being
| noticeably laggy, you couldn't pick a better example than
| Snapchat.
| hulitu wrote:
| > Valdi - A cross-platform UI framework
|
| I presume this is a Text UI. How does it compares with ncurses
| and termcap ? /s
| a2800276 wrote:
| Unfortunately no Linux, Windows or even HTML targets?
| JaggerJo wrote:
| Just write 2 native UIs in the 2 platform native languages and
| share a common core written in any language that offers a C like
| FFI.
|
| How hard could it be?
| imiric wrote:
| I agree, this is the way. To be clear: I'm not a mobile
| developer, and have only dabbled with it over the years, but
| I'm generally familiar with the stacks.
|
| If you want to simplify development of a cross-platform app,
| your work should start by architecting the software in a way
| that the core business logic is agnostic to the user
| interfaces. Then your web, mobile, and desktop GUIs, CLI, TUI,
| API, and any other way a user interacts with your program are
| simply thin abstractions that call your core components.
|
| The complexity of each UI will inevitably vary, and it might
| not be possible to offer a consistent experience across
| platforms or to leverage unique features of each platform
| without making your core a tangled mess, so this is certainly
| not "easy" to do in practice, but this approach should avoid
| the bulk of the work of targetting individual platforms than if
| you had done it any other way. It should also avoid depending
| on a 3rd-party framework that may or may not exist a few years
| down the line.
| JaggerJo wrote:
| Agreed.
|
| One extra clarification: If the quality of your app is
| business critical you should really use the native UI toolkit
| to offer the best platform integration and user experience.
|
| If your app is not business critical (you just have to offer
| it - example: dishwasher app, ..) you might get away with
| using a cross platform toolkit like flutter or react native.
| But even then this adds a 3rd party dependency as you
| mentioned which adds risk.
|
| Writing an App in Swift on iOS is boring. The same thing is
| true for writing an Android app using Kotlin/Java. This is a
| good thing. Now your developers can concentrate on shipping
| great features.
| pedalpete wrote:
| This is the direction we are going, but at the moment we are
| doing iOS only, but with the plan of learning the users UX
| needs in iOS before investing in Android, which is a bit
| strange because most of our team are on Android, but our users
| are on iOS.
|
| Every time I see a new project like Valdi, I am hoping for
| something that is truly magical and cross platform, but I'm
| always steered away by comments like yours and people saying
| "you have to do native".
|
| For context, I am a dev, and I've done RN apps in the past.
| potato-peeler wrote:
| What does using native view mean? Do they invoke native ui
| controls instead of drawing their own? Seems similar to boden -
| https://www.boden.io/
| pzo wrote:
| Looks in concept very similar to React Native. So now we have
| React Native, Lynx.js (ByteDance/Tiktok) and Valdi all based on
| React. I think competition is good for devs. But not sure if any
| of those will create ecosystem and community big enough and fast
| enough to React Native.
|
| React Native grew a lot this year and a lot of things got or will
| be improved and copied from Lynx or Valid:
|
| - 3 modes of compilation (AOT, JIT) from Valdi will be in static
| hermes (RN) in coming months.
|
| - native binding generation -> RN already have such official
| generator and also nitro/nitrogen, they also working on Node-API
|
| - executing animation and JS code in different thread (Lynx.js)
| -> worklet library in RN from swmansion
|
| - tailwindcss support (Lynx) -> uniwind in RN land.
|
| I think Lynx.js maybe have better shot at React Native since they
| want to support other frameworks instead of only React.
| pzo wrote:
| after small digging they have Full VSCode debugging [0] which
| is nice. RN have Radon IDE but it's a paid sub. What's
| interesting Valdi using Hermes (the one from RN) so maybe there
| is a way to retrofit this to work for RN. Wondering if they did
| AOT and JIT by themselve or they using static hermes branch or
| using only hermes in dev mode.
|
| [0]
| https://github.com/Snapchat/Valdi/blob/main/docs/docs/workfl...
| xngbuilds wrote:
| Is there an AI agent that excels that translating UI codes
| between SwiftUI, Jetpack Compose and web?
| sheepscreek wrote:
| I looked at the source code (as an amateur application developer)
| and boy, is it over-engineered and complex! Then I remember
| having built a complex Cordova app more than a decade ago, where
| I had to make C++, JNI and Javascript interop all play nice and
| this project feels a lot like that. Lots of moving parts. I
| suppose this is just the way things are when you are targetting
| such different ecosystems as Android and iOS _natively_, at the
| lowest level.
|
| As a solo-dev, I realize well that this project isn't for me.
| This could be a great tool for experienced folks who know what
| they are doing. I will stick to Tauri and React Native, it does
| 80% of what I care about with 20% of the effort. Or until someone
| builds a nice wrapper around this to make it easy to use (and
| also add targets for x86_64/aarch64 builds).
| 0manrho wrote:
| This is a persistent and pervasive problem that I have with
| nearly any of BigTech's framework/tooling flavor-of-the-month.
|
| Not only are they often overengineered (at least, for the vast
| majority of people's usecases), but adopting them means you're
| adopting a consistently moving target who's priorities are
| chasing whatever trend BigTech has convinced itself is The Next
| Big Thing(TM) - often reinventing the wheel yet again in the
| process - whether you're on board or not. Not to mention
| possibly getting caught up in change-of-licensing issues (eg
| Terraform switching to BSL/BUSL) or cult-of-personality drama
| by the maintainers (Wordpress)
|
| There is a place for these frameworks, even beyond their use in
| the house they were built at and for, but for the vast majority
| of usecases, they're not merely overcomplicated, but
| continually changing in their complexity to boot.
| isaachinman wrote:
| I've worked and researched heavily in this field. If you want to
| write one codebase that hits all platforms with _actual native
| performance_ your only option at the moment is RN/Expo.
| wvlia5 wrote:
| Flutter performs better than RN in my experience (mobile)
___________________________________________________________________
(page generated 2025-11-08 23:00 UTC)