Hacker News new | past | comments | ask | show | jobs | submit login
Building a Cross-Platform Web and Mobile App from the Ground Up (ambrook.com)
126 points by mfburnett on Feb 1, 2022 | hide | past | favorite | 30 comments



We do something similar across a React and a Next JS app. A little different because they are both web, but same principles of letting the clients do their own thing and having common backend logic.

Also just started looking around your site. This is actually a quality engineering blog! We're actively implementing stylized components in a manner similar to yours.


Yes very similar, thanks for the reminder. So it’s four platforms in the end (Browser, Backend/Node, Android, iOS).


This talk at Nextjs Conf explores cross platform solutions for common issues like routing, styling and animation. Found it to be quite helpful!

https://youtu.be/0lnbdRweJtA


Would also recommended this talk! It highlights some key libraries bridging these two (Next.js/ React Native) opinionated libraries together.


How is this “from the ground up”? It basically uses the same web technologies and back end from the existing web solutions.

Also, I missed the challenges of handling offline usage which was stated as a requirement, but the back end appears to be GraphQL queries to a server?


I guess it's "from the ground up" as in "greenfield", where there's no preexisting code to support or rewrite. I.e. "ground" means "fresh project" (and not e.g. entering bits by hand).


Yeah, I saw the headline and was hoping it was something crazy like Rust compiled for mobile and wasm


Was flutter considered a candidate for the technical solution.


We considered Flutter, React Native, Kotlin Multiplatform Mobile and pure native as solutions. The factors we looked at were size of hiring market, ease of conversion of web codebase and the effectiveness of the current team in that framework.


Too high risk of it being cancelled soon


What risk is that exactly? Dart and Flutter are one of the fastest growing languages and frameworks around.



This is one of the most pathetic answers possible. You give nothing on user bases and adoption of both dart and flutter, internal adoption within google, it's use of Dart and Flutter for the frontend of Fuschia, googles desire to control a widespread language, the open-source nature of Flutter, the list goes on. You just provide a list of PRODUCT's that have been killed off, not an entire language and frameworks. Your idea that google will just kill it off is a meme, and doesn't take into account it's usefulness to google in the wider world.


Firstly, chill out :-)

In terms of user bases, Orkut (RIP) had north of 60 million users when Google killed it. It was the primary social network in multiple countries.

Maybe the biggest user base killed off was Google Reader (RIP), it was the world's foremost RSS aggregator with no forseable competition and no obvious exact replacement for all those users to go to when GReader was turned off.

In terms of languages and frameworks, the Noop language was killed more by Kotlin than by Google but Google App Engine has been crushed even if the name lives on, the old SDKs you relied on are mostly gone. There all alternatives, but not quite as attractive.

Lastly though, that page i linked has a LOT of examples on it. I feel that adds weight.

Hopefully this longer comment goes some way to assuage the idea that my prior comment was a thoughtless throwaway.

All the best,


Again you're predominantly talking products, Orkut was killed off in favour of Google+ which failed for its own reasons. Your example of Noop is weak, at its peak (which you couldn't even really point to) it had a minute fraction of the adoption of what Dart and Flutter has today. It was an experiment with absolutely minor resources put into it as a mostly 20% project, and basically wanted to be what Kotlin already was which had all the resources that came with Jetbrains full backing.

You ignore the points about Google's long term aims of control of a programming language that runs on all platforms. This gives them overall control of multiple ecosystems. Dart is the language that they are using to push Flutter as the framework for controlling whole ecosystems. Fuschia is the project they're going to push for to take over Android.

The webpage doesn't really add weight, because context matters and you are seemingly ignoring the entire context of the a) open-source nature b) business goals c) current adoption d) it's not a product, all to try a push a flippant opinion that doesn't really work when you understand the thought and ideas behind Dart/Flutter.

But you do you, enjoy and all the best.


Main reason I'm replying is you've misspelled Fuchsia as Fuschia and to ramble a bit, maybe this was on purpose and if so that's ok. https://fuchsia.dev/

Some more ramblings -

My understanding with Fuchsia and programming languages,is they ditched Google's GoLang for Rust, they don't like GCs, but they're keeping Flutter due developer productivity, dart's hotreload feature, etc.

If Fuchsia ends up in the phone space, they would want it to run android apps, work is going on with starnic for running unmodified linux apps.

https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0...

Also I watched some of the Fosdem ubuntu stand talks, the Flutter desktop talk had an interesting demo, with the Ubuntu person saying all new ubuntu apps are to be Flutter apps.

Tidbit - The ubuntu team is working on Full Multi-window for Flutter desktop for windows, mac and linux.


For those who have the pleasure and luxury to go green field new dev, i started using the Quasar Framework, which builds on top of Vue. I really love it.

https://quasar.dev/


For those unfamiliar:

> Quasar’s motto is: write code once and simultaneously deploy it as a website, a Mobile App and/or an Electron App. Yes, one codebase for all of them (...)

source: https://quasar.dev/introduction-to-quasar#what-is-quasar


> the opportunity to approach the challenge of supporting multiple platforms without the constraints of legacy engineering decisions

While I am keen on this article, I must pause reading it to come here and plead that people say "prior" instead of "legacy".

Legacy - due to its provenance in Microsoft sales techniques to mean "not Microsoft" - implies "bad". When actually the decisions may have been good, at least at the time.


> On mobile, we generate a QR code that can be scanned by a phone running the Ambrook app to download and run the latest Javascript bundle live on the phone.

This is awesome!


Thanks jrubinovitz! We tried to make it as easy as possible to do the right thing (QA + code review at once).


That's so important when you're shipping at startup speed and it's so tempting to just rush to the next thing. I am going to try this with my next cross platform app.


also possible to share (nearly) 100% of code between mobile+web using react-native-web

(plug: I did this, save a small iOS shim, for my music player https://shelf.fm).


Cool. but I miss a link to the demo ;-)


Loved this


Do farmers really use apps?


Of course, why wouldn't they use the latest stuff? Farming technology is literally the reason you and your (relatively) recent ancestors aren't slaving away in the fields. Doesn't matter if that's combine harvesters or logistics apps.


Farmers are business owners. They definitely use Excel or other computer apps to keep on top of everything.


Hopefully you are joking. Farming was high-tech before a lot of other professions were.


Better than using Excel which is what many currently use.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: