[HN Gopher] Hyperview - Native mobile apps, as easy as creating ...
___________________________________________________________________
Hyperview - Native mobile apps, as easy as creating a website
Author : brickers
Score : 216 points
Date : 2025-01-07 08:43 UTC (1 days ago)
(HTM) web link (hyperview.org)
(TXT) w3m dump (hyperview.org)
| gnabgib wrote:
| Popular in 2022 (252 points, 74 comments)
| https://news.ycombinator.com/item?id=34137381
| dbbk wrote:
| Surely this will be redundant with React Server Components on
| RN/Expo?
| benpacker wrote:
| This is more of an HTMX native
| mrbluecoat wrote:
| Yeah, the moment I read "Serve your app as XML" my brain
| instinctively began to move on but it's really just HTML-like
| semantic snippets that remind me of WebComponents. Example:
|
| https://github.com/Instawork/hyperview/blob/master/demo/back.
| ..
|
| However, this warning statement should be in bold at the top:
| "If your app relies on offline data or local computations,
| Hyperview won't be the right choice."
|
| For that reason, I lean toward https://volt.build/
| giwook wrote:
| A key distinction here is that Hyperview is free, which
| makes the offline capabilities or lack thereof a more than
| reasonable tradeoff IMO.
|
| Volt looks great, but $15/mo. for the basic plan, $37/mo.
| for the pro plan that you likely need for the ad hoc builds
| alone (unless you test in prod).
| dbbk wrote:
| If it doesn't do offline data or local computations what is
| the point?
| sibeliuss wrote:
| Server components + RN + Expo.... Could it get any more
| pointlessly complicated?
| satvikpendem wrote:
| Just because there are multiple technologies does not make it
| complicated _per se._ Indeed, something could evolve to a
| simpler model, which it seems RSC on RN is.
| sibeliuss wrote:
| Keep dreaming man. Just look at what Next has become... It
| has taken "render component on the screen" and turned that
| into an experts domain. It's a nightmare for anyone who
| isn't the most skilled, for projects that are more than
| just toy apps and AI one-offs.
| satvikpendem wrote:
| Not sure about that, it's gotten easier as time goes on,
| especially with server actions. Previously we used
| something like OpenAPI to map types on the frontend and
| backend and had to make separate HTTP endpoints for
| everything. Now I just write a function and it's all
| taken care of automatically, I can put types and
| functions in any folder I want and it just works.
| 52-6F-62 wrote:
| Doesn't it require Expo's servers for a development
| environment?
|
| All these companies have given up on the gold rush long ago
| and are just slinging fancy shovels.
| satvikpendem wrote:
| No, they can run locally.
| netghost wrote:
| This is a ReactNative app that consumes XML and maps it to
| ReactNative components, so you're still using those
| pointlessly complicated technologies, but through a proxy
| application that abstracts some of the complexity away
| (https://github.com/instawork/hyperview?tab=readme-ov-
| file#hy...).
|
| When you hit the boundaries of what Hyperview can do, you're
| going to need to dig into some of the details, but mayhaps
| you don't need those features. Either way, it's an
| interesting project, but like everything else it's going to
| have _some_ drawbacks
| j45 wrote:
| Less time spent building a stack temple to venerate
| oneself.
| dbbk wrote:
| Well if you want to remotely update a mobile app UI from your
| server backend, it seems like the simplest option...
| tjmtjmtjm wrote:
| I'm more of a Floral Green person.
| latortuga wrote:
| Underrated joke, did not expect a Title Fight reference when I
| opened this thread!
| recursivedoubts wrote:
| Hyperview is a very interesting mobile-oriented hypermedia system
| created by Adam Stepinski.
|
| He talks about is in the third part of our book, hypermedia
| systems:
|
| https://hypermedia.systems/part/hyperview/
|
| I have said before that I regard his work as much more innovative
| than htmx in that he developed an entire hypermedia client and
| format for his system.
| toddmorey wrote:
| I'm curious about the limitations that prevent these apps from
| writing / caching local data. It doesn't seem like the paradigm
| would have to change entirely to support that.
| recursivedoubts wrote:
| There aren't any, with hyperview you actually own the
| hypermedia client as well as the server and you can write and
| cache local data in the form of custom extensions you make to
| it.
|
| I think that needs better documentation though.
| smackeyacky wrote:
| So, basically it's like every other non-native development
| environment for mobile: basically useless when you want to
| use any feature of the phone.
|
| These things always implement the easiest bit of mobile
| development (the UI) and then make everything else harder,
| so it's useless for anything non-trivial.
| sirjaz wrote:
| I'm wondering if they could get that to work with React Native
| for desktop apps
| openrisk wrote:
| You'd have to run a server in the background which complicates
| things but otherwise it would seem to be feasible.
| ipnon wrote:
| Not even a day after the post about HTMX not living up to its
| promise! There are only two certainties in life, death and
| frontend churn.
| JodieBenitez wrote:
| > the post about HTMX not living up to its promise
|
| You read that wrong.
| birdgoose wrote:
| I'm fairly certain the tone of the HTMX post
| (https://htmx.org/essays/future/) was positive about its future
| of becoming "stable" (as opposed to "stale").
| Cthulhu_ wrote:
| > frontend churn.
|
| Frontend churn hasn't been as much of a thing for years now,
| see e.g. https://2022.stateofjs.com/en-US/libraries/front-end-
| framewo.... If you stuck with Angular or React 10 years ago,
| you're still good today. jQuery is even older but still on 75%
| of websites
| (https://w3techs.com/technologies/overview/javascript_library),
| and Bootstrap is on nearly a quarter.
|
| Frontend churn is only a thing if you try to stay on the left
| side of the Gartner Hype Cycle.
| owebmaster wrote:
| React churned itself.
| ricardobeat wrote:
| That's only true on the surface: if you chose React, you had
| to rebuild and relearn everything about once every two years.
| Averages out to about the same workload as following the
| latest fad. Maybe more, since refactoring legacy code is 10x
| harder than building from scratch.
| agos wrote:
| this is just not true. even the worst offenders (looking at
| you, react-router) do not require to "rebuild and relearn
| everything". What an unnecessary hyperbole.
| ricardobeat wrote:
| Maybe not React itself, but the ecosystem as a whole. I
| can list some of these changes that generated a lot of
| work from memory:
|
| - the move from in-browser JSX compilation to build tools
| / webpack
|
| - the move from class components to functional components
| and hooks
|
| - all the changes related to ES6 classes and modules +
| build system
|
| - server-side components
|
| - Flux -> Redux
|
| - Redux -> MobX -> Relay -> Redux Toolkit -> Context API
| -> Zustand / Jotai / Recoil -> react-query (next: zero?)
|
| - Next.js and Remix, 7 react-router versions (latest with
| major breaking API changes again)
|
| - Signals and more SSR stuff (I stopped looking at this
| point)
|
| And this is ignoring all the React Native churn over the
| years as I imagine not everyone is involved with that.
|
| Even if your particular project didn't go through all of
| these migrations, you had to relearn things to be able to
| work in other/newer projects.
|
| It's impossible to measure, but having written and used a
| ton of different frameworks, I really do feel like the
| overhead of keeping up with the changes was equal to or
| larger than learning a new one every couple years.
| gr4vityWall wrote:
| From that list, I believe Server-Side Components is a big
| offender in terms of complexity.
|
| React Router changing its API so often felt unnecessary
| too.
|
| I wouldn't call all of that churn though, as I believe
| most devs only had to deal with a subset of those. Some
| who got into React in 2019 could be writing the same kind
| of code today.
|
| Frontend as whole, on the other hand...
| iforgot22 wrote:
| Also Typescript, if your team started using it.
| iforgot22 wrote:
| I really do have to relearn react-router every time I use
| it, then I pin it to that version so it doesn't break
| later. Last time was v6, now there's v7 since Nov '24.
|
| Besides that, React churn isn't too bad. I have to fix
| builds, but I don't have to relearn everything about
| React. Unlike Angular.
| flamwenco wrote:
| Angular of 10 years ago... you mean the 1.0 framework that's
| wholly incompatible with 2+ because it was a ground up re-
| write?
| iforgot22 wrote:
| React didn't have hooks 10 years ago, but at least they're
| compatible with classes
| mpweiher wrote:
| Which post was that?
| paradite wrote:
| Ah finally the Western tech ecosystem has caught up with
| WeChat/Alipay mini programs.
|
| https://developers.weixin.qq.com/miniprogram/en/dev/framewor...
|
| China had this DSL for building mobile apps for years. Those
| these apps are initially embedded inside WeChat/Alipay, there are
| now frameworks that allow it to run outside, like uniapp.
|
| https://en.uniapp.dcloud.io/
| klausa wrote:
| I've had very limited exposure to Alipay mini-programs (took a
| daytrip to Shenzhen from HK); but anything I had to touch
| (couples of restaurant menus; buying tickets for metro) was
| _screaming_ "this is poorly constructed webpage", not native-
| like experience.
|
| Are there some you would recommend to see as an example of it
| being done right?
| paradite wrote:
| You can buy plane tickets, railway tickets, book hotels on
| wechat via popular 3rd party booking platforms.
|
| I think there are first party integrations in wechat app, go
| to Me - Pay and Services, you can see a bunch of them.
| klausa wrote:
| Sorry, just to clarify -- I meant examples of services that
| "feel" nice to interact with in the app; not examples of
| what they can be used for.
| scotty79 wrote:
| It's a bit like asking which power company has pretty
| technicians.
| klausa wrote:
| We're in a thread talking about a technology that
| purports to make creating "native mobile apps, as easy as
| creating a website"; and the parent claimed that the
| Alipay/WeChats mini-app stacks are similar.
|
| I don't think asking for examples of this resulting in an
| experience that's pleasant is unreasonable?
| afavour wrote:
| I _think_ the point OP is making is that the relative
| pleasantry of the experience isn 't as important for end
| users as it is for us developers. My anecdotal experience
| bears that out: I shudder when I see a web-heavy native
| app, my non-tech friends don't bat an eyelid. People
| learn UIs, no matter how janky, very quickly if the end
| goal is important to them.
| scotty79 wrote:
| I think my point was that an application that exists, is
| up to date and works is a better application than the one
| that doesn't exist or is stale because it's harder to
| write and maintain but feels (or would feel if it
| existed) nice and polished.
|
| For practical purposes like buying stuff or accessing
| information I want practical applications that can be
| quickly iterated on.
| gadflyinyoureye wrote:
| FPL. Tone bodies with good tans. Don't see that with
| IP&L.
| 1shooner wrote:
| Well, do those WeChat services have competition? That's
| where I've seen the push for better UX: it's a signal to
| users that your product is overall higher quality. So not
| so much 'pretty power company technicians' and more 'Is
| the lobby of the hotel clean?'.
| paradite wrote:
| I mean those 1st party integrations directly listed in
| WeChat services page are probably good examples of
| services that "feel" nice to interact, because they are
| used by millions of people everyday and they are need to
| optimized and polished to be able to serve millions of
| users.
|
| Here's a screenshot of the list, if you want to Google
| and check out some of them: https://imgur.com/a/KKEdliE
| mathverse wrote:
| Minions of people use SAP daily that does not mean it's a
| nice thing to interact with.
| paradite wrote:
| I agree that numbers alone might not mean much, but I do
| think B2C apps with millions of users have a higher bar
| in terms of design and polish compared to B2B/ERP apps.
|
| Also, fixed typo!
| mathverse wrote:
| But it's not like you can choose in China either :)
| TeMPOraL wrote:
| It's not like you can choose in the West either, either
| :).
|
| Number one goal of any software service today is to make
| its offering exclusive in some way - exclusive content,
| exclusive deals, exclusive integrations, exclusive set of
| participants (network effects), going super-broad super
| fast because infinite VC money lets you keep operating at
| a loss indefinitely, etc.
| YuukiRey wrote:
| You're making it sound as if the difference in choice
| between China and western countries is negligible. Surely
| that's not the case? If every VC company tries to pull
| you into their walled garden, I can still choose from
| among a variety of said walled gardens.
|
| I could be wrong of course, since I don't know how many
| AliPay and WeChat competitors there are.
| z2 wrote:
| The competitors at the consumer-facing super app level
| (with mini programs of varying awkwardness) include
| Meituan, XiaoHongShu, and to an extent, Toutiao, JD.com,
| and Baidu. But you don't need those gardens as a
| publisher if you're on Android--ironically because Google
| services are banned, there are over a dozen app stores to
| competing to fill the void. Compare that with the western
| duopoly of Apple App Store and Google Play.
| TeMPOraL wrote:
| > _If every VC company tries to pull you into their
| walled garden, I can still choose from among a variety of
| said walled gardens._
|
| When they play it right, you're forced to choose _all of
| them_ , or at least a significant subset of them, so that
| their partially overlapping offering add up to the actual
| thing you need.
| HWR_14 wrote:
| It's probably easier to switch jobs to avoid B2B apps you
| don't like than to avoid WeChat in China.
| InsideOutSanta wrote:
| There's a pretty big difference in what UX "feels nice"
| to East Asian audiences vs Western audiences. This video
| provides some insight into why this might be:
| https://www.youtube.com/watch?v=WSMFnJnY7EA
| sgoschi wrote:
| The comments make it seem like it's more a case of users
| tolerating it due to the apps usefulness. Interesting
| video though, haven't had any contact with Chinese apps,
| so that was enlightening.
| iforgot22 wrote:
| That's all fine if the particular customers you want to
| reach are among the millions used to WeChat services.
| lolpanda wrote:
| Those mini apps are built on the same web stack. I believe the
| main advantages of creating mini apps are that the platform
| provides identity (allowing you to know who the users are upon
| permission approval) and payment APIs.
| aquariusDue wrote:
| I believe Telegram has something similar too.
| paradite wrote:
| They use a mixture of web rendering stack and native
| rendering stack. See my other comment.
|
| There are also more architectural diagrams thst illustrate
| the layers in the links I posted in my original comment.
| flohofwoe wrote:
| Aren't those just web apps running inside a webview widget?
| What's "native" about that? (but tbh, at first glance this
| Hyperview thing looks like it's just re-inventing web browsers
| too).
| anonzzzies wrote:
| When I was still using wechat (and in china); it was a mix;
| native buttons and payment integrations mixed with webviews
| for content.
| paradite wrote:
| I think the key idea is not the renderer layer, but the
| concept of DSL so that it can run on multiple platforms
| natively.
|
| To go back to your question. WeChat actually has two sets of
| renderers for mini programs, one based on webview, and one
| based on native iOS / Android components. But you are right
| that most mini programs are using mostly webview to render,
| with only a few things being natively rendered.
| aa-jv wrote:
| The "Western" (whatever that is) tech ecosystem has long had
| this technology out there .. its the "Western" marketing
| ecosystem that has been squashing it - for example, Apple
| quashing any and all use of JITs and VMs in order to keep their
| native platform relevant ..
| jsiepkes wrote:
| "Serve your app as XML"
|
| As someone who started his professional career in 2005: All the
| old is new again.
| revskill wrote:
| JSON is same as XML.
| beagle3 wrote:
| And XML is essentially lobotomized and extra verbose Lisp
| S-expressions, going back to the 1960's
| xarope wrote:
| don't talk about my thesis, written in LaTeX, like that...
|
| /j
| magic_smoke_ee wrote:
| _Back in my day, real cowboys wrote their papers in
| PostScript, making their papers as inaccessible as
| possible for user of consumer-grade devices._ /s
|
| PS won on human readability and editability but lost on
| portability to Adobe's own internal competitor, PDF, and
| because it fought and lost to (La)TeX -> PDF & (La)TeX ->
| DVI -> PS.
|
| PS: I once printed out and bound the PDF 1.3 spec[0] on
| 24 lbs. bleached dead trees on an HP LaserJet IIIP with
| over a million page count. Some of the nuclear engineers
| and scientists an office containing <50 people routinely
| printed thousand page documents _every week._
|
| 0. https://opensource.adobe.com/dc-acrobat-sdk-
| docs/pdfstandard...
| Cthulhu_ wrote:
| No it isn't, XML is an ecosystem with things like dedicated
| transfer protocols (EXI), schemas (XSD), transformers (XSLT)
| that JSON still doesn't have standardized/normalised even
| though JSON has been the norm for nearly 20 years. There's
| some projects of course (JSON Schema, OpenAPI), but they're
| separate and not part of the same standardization committee.
| mathgeek wrote:
| As someone who works with JSON every day and almost never
| deals with XML directly, it's important to realize saying
| they are the same is like saying a pocket knife and a Swiss
| army knife are the same because they both have an extremely
| useful tool (and why would anyone ever use the thing with all
| that extra stuff I never use?). Not a perfect analogy but the
| one I think of for simplicity.
| j45 wrote:
| JSON is great in it's own regards but the features are not
| comparable.
| withinboredom wrote:
| At least with XML, you can have custom datatypes, not just
| strings and numbers and booleans.
|
| In all seriousness, everything in JSON can be expressed as
| XML; but not necessarily the other way around.
| baxtr wrote:
| Text is the same as JSON.
| openrisk wrote:
| It sort of proves the point that certain technology choices are
| not the result of some monotonic "progress" towards a
| theoretical optimal but rather a random walk under stochastic
| influences in what we might call "conventions space".
|
| Serious randomness is induced by the decisions of whatever
| entities happen to be influential, typically (but not
| exclusively) by having the most successful economic model.
| Causally that earnings model need not be at all related with
| the tech. After all, most 'big tech' is not actually selling
| the tech itself.
|
| People mostly code for money so they are attracted and
| incentivized to use the more visible money-making conventions
| (be part of wining teams) irrespective of particular technical
| merit.
|
| But there are additional more objective dimensions that
| complicate things. E.g. SPA conventions _did_ solve a user
| experience problem at the time. It was not pure lemming
| behavior. In retrospect we know that it could have been solved
| otherwise but at that time we didn 't.
| scotty79 wrote:
| I think webapps should be xml (with all the data to display)
| transformed into html on the client side with XSLT generated by
| framework templating system).
|
| There's a really nice binary XML format that browsers haven't
| implemented yet:
| https://en.m.wikipedia.org/wiki/Efficient_XML_Interchange
| ricardobeat wrote:
| Symphony CMS [1] was based on this idea over a decade ago.
|
| The developer experience was amazing, you could easily
| inspect the data backing any page. XSLT was hard but probably
| easier than React these days.
|
| [1] https://getsymphony.com
| baggachipz wrote:
| What a blast from the past. We did exactly this in '99-2000
| (yes), and it was ridiculed as being over-engineered. At the
| time, it was the future because "XML will underpin all data
| transfer everywhere", and therefore we would be set up to run
| on any device, should any other device begin to exist.
| Needless to say, the winds changed way sooner than that
| became a real use case.
| scotty79 wrote:
| I originally had this idea about 20 years ago. I still
| think it's good. At least better than brotli compressed
| json loaded with JavaScript.
| j45 wrote:
| I wonder what going back to the 90's will bring up.
| Devasta wrote:
| The web is, was, and forever will be stuck reinventing shitty
| versions of things that they could have had decades earlier if
| they stuck with XML.
|
| Custom elements, client side templating, form validation
| against schemas, they had it all and threw it away.
| donatj wrote:
| Literally. I wrote a fair number of Konfabulator widgets in the
| early aughts this way. I did a bit of Adobe Air like this as
| well, everyone insisted it was THE FUTURE, it wasn't.
| magic_smoke_ee wrote:
| Someone will inevitably create an app to create apps using
| Brainfuck encoded in Morse code running on a 16-QAM wireless
| protocol... just beam your app with your data.
| globular-toast wrote:
| Any "app" framework that isn't offline-first seems broken by
| default to me. It seems ridiculous to me that client-server
| architecture is considered the easy thing now. Where did it all
| go wrong?
| vincnetas wrote:
| When companies decided that they need to know as much as
| possible about the end user, and don't want to care about
| backwards compatibility (old version apps, all users are using
| latest)
| mihaaly wrote:
| And consequently when they started to give no f about if
| users like or not the new version of the app forced on them.
| So before the Enterprise Oriented Design.
| Hilift wrote:
| Making mobile platforms second class citizens was wrong.
| SillyUsername wrote:
| How does this improve on w3c standard of xforms + CSS?
| bplaat wrote:
| Ah I've seen this before but then with JSON
| https://github.com/Jasonette
| donatj wrote:
| I am very unclear reading the documentation and clicking around,
| how do you actually implement the logic? Some sort of JavaScript
| runtime?
| VagabundoP wrote:
| Its a client/server system. So the logic is done by the server
| and snippets of HXML are served:
|
| https://hypermedia.systems/building-a-contacts-app-with-hype...
|
| That's an example using Flask. There's a demo client bundled
| with the repo, but I assume you can customise and deploy it.
| I'm not familar with Expo.
| trey-jones wrote:
| Using web technology to build "native" mobile apps has been
| around almost as long as mobile apps themselves. I used
| Appcelerator Titanium and Phonegap to do this beginning in 2012
| (maybe even 2011) before eventually trying Native development
| later after finding these options underwhelming.
|
| I have a reasonable amount of experience doing both, and my
| opinion is that development tools aren't really the problem. The
| biggest pain point is the platform specific deployment and
| maintenance requirements (including legal and technical
| documentation) that will be needed regardless of what technology
| you use to actually build the product. Because of this I always
| advise clients that they don't really need a mobile app. Just
| build it on the web.
|
| If you absolutely must have a mobile app, you need to fully
| commit and hire an internal development team and be prepared to
| keep paying them as long as the app is going to be in use.
| giancarlostoro wrote:
| > Just build it on the web.
|
| It takes a very insignificantly small amount of JavaScript to
| make a website a Progressive Web App, which iirc can be listed
| on app stores.
|
| If you dont use React or any fancy frameworks, I believe last
| time I ever did such a project our JS was under 50 lines of
| code to have our PWA working fully offline. There were some odd
| hacks, like detecting network connectivity.
| sebmellen wrote:
| Not on iOS. You gave to use this WebKit hack
| https://blog.pwabuilder.com/posts/publish-your-pwa-to-the-
| io....
| giancarlostoro wrote:
| That's specifically to be listed right? I mean I guess
| that's fair. Thanks for the link, saving that.
| Lerc wrote:
| Is there a super simple tool for turning statically served
| websites into PWAs?
|
| Last time I looked all of the simple tools had been
| deprecated in favour of complex tools that do way more than I
| need.
|
| If I had a site in a directory that works fine from
| >cd MyWebApp >python3 -m http.server
|
| I would like a command line tool That worked like
| >becomepwa MyWebApp
|
| Which produced a PWA that downloaded everything on install
| and could be run henceforth offline.
|
| I thought this would be a common use case, but I failed to
| find anything that supported it without intruding on my
| workflow.
| giancarlostoro wrote:
| Three things you need:
|
| * Manifest file
|
| * HTTPS - for localhost I dont remember the workaround,
| browsers have made this increasingly more complicated from
| recent experiences
|
| * Service Worker - This is where I said I had maybe 60
| lines of JavaScript.
|
| If you have these three things, a browser should pick up
| that your sites a PWA and server running it should be
| irrelevant... So you MUST have a minimal amount of
| JavaScript, but I did it using pure vanilla JS, you dont
| need a fancy framework.
|
| On that same note, there might be a tool that could inject
| the bare JS necessary for this, but I dont think it exists,
| certainly could be built.
| iforgot22 wrote:
| The service worker thing is a weird amount of
| boilerplate. Every time I go back to making a PWA, I skip
| through 10 search results explaining what a service
| worker is (idc) until I just find whatever .js code I
| have to copy. And it's not some trivial one-liner.
|
| I get that in theory a PWA can do offline stuff and
| whatever, but 99% of the time someone is only making a
| PWA to make the app installable on a phone home screen.
| giancarlostoro wrote:
| It is not a trivial one liner no, but you need 3 events
| implemented in your service-worker file, then in your
| main.js file you register it.
|
| Service workers are just JavaScript that runs in the
| background in their own process in a browser. Could think
| of them as separate threads. Anyway, all of that can be
| done in less than 20 lines of JS?
|
| I consider it simple compared to people building React
| apps and making the process more complicated than it
| needs to be just to build a PWA.
|
| I was able to build a PWA out of a bootstrap HTML5 web
| app, with minimal JS for REST calls and ag-grid
| population.
| Lerc wrote:
| HTTPS isn't an issue, dropping whatever the command
| generates onto a HTTPS supporting server isn't an issue.
|
| I want the manifest to be automatically generated from
| whatever is in the directory. The service worker should
| download everything from the manifest at first launch.
| I'm ok with a download-on-demand build option, but by
| default it should grab everything needed. If a user
| installs something, it should be assumed that they can
| use it offline.
|
| I feel like the tool should already exist. If it does not
| yet exist, it seems like there must be a reason for that
| that I am not aware of.
| pjmlp wrote:
| What I have learned after all these years, is either do a Web
| site that is mobile friendly, or go native, anything else is a
| kludge in the search of holy grail of cross platform
| development without costs.
|
| However this is a lie, because after going after the dream of
| cross platform, one lands on the (N + 1) reality, with team
| having anyway to master the leaky abstractions of the
| underlying platforms.
| etothet wrote:
| This * 100. I have a lot of experience with these types of apps
| and the biggest issue I've encountered is the platform keeping
| up with native technologies and OS updates.
| captainepoch wrote:
| For the love of God, stop putting "Native" in web frameworks. No,
| React will never be native.
| dbbk wrote:
| What does this mean? There are plenty of big, native apps using
| React.
| captainepoch wrote:
| React is a web framework. You can put Native behind React,
| it'll never be.
| nipponese wrote:
| It's "native" in that the wrapper is a native binary, but
| it's still a webpage.
| agsnu wrote:
| React Native actually constructs a view hierarchy in the
| platform's UI toolkit, so I'm curious what you mean by
| "still a webpage"?
| happytoexplain wrote:
| >as easy as creating a website
|
| This strikes me as odd - I have a much easier time making a well-
| functioning native app (iOS or Android) than the equivalent
| website. That's not typically a checkmark in the web column for
| web vs app pros and cons.
|
| Unless we're including distribution when we say "creating".
| LVB wrote:
| >Unless we're including distribution when we say "creating".
|
| I think it has to be included given how much traffic I see from
| mobile devs I follow about getting stuck in some review
| blackhole, running afoul of a TOS or payment rule, etc. Getting
| the app built is in your control, but getting it to end users
| has a big dependency on others, potentially. The idea of being
| able to push code to a server you control and deliver instant
| updates is appealing.
| YuukiRey wrote:
| I overlooked it at first even though it's right there on the
| landing page but this is ultimately still React Native with all
| the baggage that entails.
| strogonoff wrote:
| I briefly investigated using React Native on a project. Obscure
| installation and linking process which no one seems to
| understand exactly, no SPM support on iOS, incomplete
| documentation that from the start pushes to adopt yet another
| layer on top (such as Expo, and I suppose Hyperview is now
| another option)... It felt like I am adopting some rusty legacy
| software, and not in a good way (more full of quirks than
| mature, well-documented and time-tested). Judging by
| discussions, most people would somehow get it working and then
| not touch it again until it breaks. My intuition was to stay
| away and to recommend, if PWA is not an option and resources
| are limited, to go with a native app for one platform
| (whichever more familiar) & later pay someone to port it for
| the other.
| tarentel wrote:
| If resources are limited and you plan on charging any type of
| money for the app, either one time or as a subscription, it's
| almost always better to go iOS first and port to Android
| later. I obviously can't speak for the ecosystems as a whole
| but anecdotally of the last few companies I've worked for a
| strong majority of paying users came from iOS.
| mijkal wrote:
| In my xp, React Native was far more fragile a few years ago,
| but it has improved immensely since then. I quite enjoy
| working with it these days.
| iforgot22 wrote:
| Probably has changed since then, but I remember the RN docs
| telling me to use Expo. I was wondering the whole time, do
| people actually use Expo or no. And why is it uploading my
| code to some website? Soon I had a clear answer; I had to
| "eject" from Expo to do a prod build or just add any native
| components. Not a good first impression.
|
| That said, RN was a win in the long run. It was a lot less
| baffling than the notorious Xcode/Swift/ObjC/UIKit ecosystem
| I'd used for years.
| biosboiii wrote:
| As a reverse-engineer tinkering with iOS this reminded me of some
| system apps.
|
| E.g. in the app store you click a button, send a request, receive
| the response which contains a xml-like structure describing the
| UI mutation to your action.
|
| <Alert> <Header>iTunes Login</Header>
| <Body>We could not find a user with those credentials.</Body>
|
| </Alert>
|
| type stuff.
| LudwigNagasena wrote:
| Server-Driven UI is a very common architectural pattern.
___________________________________________________________________
(page generated 2025-01-08 23:01 UTC)