Matcha – A framework for building iOS and Android apps in Go
github.com
github.com
1) Ability to quickly see changes in the simulator as you're modifying code (one of the main reasons I went with RN over ObjC/Swift, is I can just Cmd+R and boom, my changes are live in a second).
2) Pushing new updates remotely, without having to resubmit your app. Would Go being statically compiled, mean we can't ship bits of executable code for minor updates / bug fixes as we see fit?
3) Debugging is really nice on RN, because you get to leverage awesome JS debugging environments like Chrome DevTools. While I've not yet had a need for a fancy debugger with Go, I could see that as a big sticking point for teams trying to choose.
Nonetheless, really applaud this effort so far, and look forward to seeing more. Go's concept of goroutines seems much better suited to UI event handling, then stringing together a ton of promises and callbacks. And don't even get me started on the async keyword...
Please do! Genuinely curious what you don't like about it.
That is, why be explicit about async when implicit style code is much easier to read. That said, the answer in this case is simply backwards compatibility - JS already had a concurrency model before async/await came around.
You can also make a explicit is better than implicit argument; it’s mostly personal preference/ideology though. That said, Python has been in a fun land of “rewrite the world” because the async model they chose (async/await) was not backwards compatible to any existing libraries. So now in Python which library you use for e.g. http varies with which concurrency model you use in the rest of your app.
While I'm generally an explicit sort of guy in these contexts, there isn't much that being explicit buys you here, except the ability to write bugs. There's really only one right answer and the compiler is perfectly capable of handling it. In the exceedingly rare cases where you need to override it, you can. Given how exceedingly rare those cases are we're easily in the realm of "use another language" or "fork & hack the runtime" sorts of things.
Perhaps ironically, when I worked on the iTunes Store (which is mostly all HTML and JavaScript) there was hardly a week went by that new code didn't get pushed (mostly bug fixes and under-the-hood updates). Yet Apple only really announced new iTunes Store features several times a year. So, one would hope they understand the need for continuously updating a complex piece of software, versus shipping major pieces of new functionality.
Even if you do manage to hack it in to something that wasn't designed with it in mind, it's always hacky, quirky, and unreliable, and you never quite know whether you're looking at a bug in your own code or in the state management hackery.
It isn't impossible. You are technically correct. But it's certainly taking impossible out for drinks, followed by long strolls on the beach, and a lot of meaningful staring.
As someone with experience in Delphi, C++ Builder, Smalltalk having younger developers rediscovering this looks funny.
Have a look at Flutter and Xamarin.
Flutter looks very promising btw, I probably can't use it yet though for the same reasons as Matcha, which is my current project depends on too many external libraries (for which React Native and the larger JavaScript community has been great).
It will help me to understand better. Any future plans to write blog.
Maybe we shouldn’t be building frameworks on top of frameworks on top of other languages?
Maybe officially supported tools/languages are often a good choice.
Edit: Going by https://en.wikipedia.org/wiki/List_of_radioactive_isotopes_b..., it seems that most of the halflives fall in the 10^(n where n <= 6) seconds category which is smaller than a human lifetime.
I guess Kotlin and Kotlin Native (which runs on ios) could be a good started for building a KotlinReactNative, which allows creating an UI in a DSL based syntax that works on multiple platforms.
Do you have any info on why Airbnb stopped using React Native? Would love a good read on why.
Right now, the only thing I'm currently aware of is that their navigation library (native-navigation [1]) is pretty much unmaintained and they are trying to plan out a transition to move it under react-community.[2] The only thing that hints at their slowing use of React Navigation is the mention of conversion to React Native's navigation getting a much lower priority to the point that the native-navigation library has essentially become unmaintained.[3] But when I initially read that, it didn't come off as Airbnb deciding to stop using React Native.
[1] https://github.com/airbnb/native-navigation
[2] https://github.com/airbnb/native-navigation/issues/145
[3] https://github.com/airbnb/native-navigation/issues/145#issue...
Is this true? I'd be interested to see a citation on AirBnB stopping using it, last I heard they were going all-in.
As for the issues with navigation, isn't it just that there isn't a great navigation library yet?
And one of the main persons behind ReactNative at AirBnB seems to be less enthousiastic in his latest interview.. However i cant find the interview anymore
Like Leland said above, we're still working hard and making exciting progress on React Native but we continue to invest in native platforms as well and product teams make a case by case decision on which one to use.
Hope that clarifies things a bit :)
I don't think Airbnb has ever been "completely going all-in on React Native" or "completely dropping React Native", but people always seem to want it to be one or the other. The truth is it's almost always something in the middle.
You wouldn't have this problem if you start a React Native project from scratch.
They seem to be still using React Native. Have you heard otherwise?
A lot will depend on why you need cross-platform support at launch. For most direct to consumer apps, your intended user base should skew to one platform or the other and should be large enough to support a beta and launch on a single platform. Not launching with both platforms supported won't make or break your app and launching with both without much mobile experience to begin with could even prove to be a distraction while you try to iterate on you're app's design.
If you're selling an app to businesses, then not supporting both iOS and Android at launch would be a real roadblock. In that case starting and maybe even staying with Ionic could make sense.
This just isn't true. Airbnb is actively using React Native a lot and has not "stopped using it seriously". I'm not sure where you got this impression. Some people responding to this are mentioning the transition of the potential native-navigation library to react-community. This is a library that we never actually used in production, though the plan was to move off of our internal library to this one shortly after open sourcing it. Priorities shifted internally (to other, more pressing react-native related things that aren't OSS), and we have not yet been able to do that. Since the community really wanted to work on the library despite us not actively maintaining it, transitioning it to react-community seemed like a better thing to do than further fragment the community by having people fork it. I'm still hopeful that we will be able to migrate to it in the future.
Source: I am the tech lead of React Native infrastructure at Airbnb and the primary author of native-navigation.
Where does AirBnB actually use ReactNative, and where is it purely native? I was in the understanding the move to ReactNative was not going "the way you preferred".
I can imagine there are some roadblocks using it everywhere. Or some hesitation from Native Developers.
For me also: Using JavaScript as a language run inside a interpreter inside my app doesn't seem like a smart move. Also native like navigation, activity lifecycle, animation etc are probably hard to get right with React Native.
We already have a widely adopted, widely compatible, highly developed and open framework for cross platform development: webpages.
My confidence that Mr. J. Random Hacker - or even J. Random Company Inc. - can do better than this - and support it for over 2 decades - is close to 0.
In my application I needed to display data incoming from a sensor. I can only access this data using the native functions and it comes at around 500Hz from 16 sensors.
For comparison, in Electron, when you call a function defined in a module written in C++, you can get the answer in under 1 ms. When using something like Cordova, you have to serialize the data which can take a seriously long time and then you have to wait for the callback to execute. On Android I suppose it is quite possible to write a V8 native plugin and achieve this performance, but not on iOS where you are limited to included webkit.
As for the Android responsiveness, the problem lies with the single threaded nature of JavaScript. CPUs on android phones _suck_ in single core performance. When I was looking for a good solution for multi platform development, I have found of a tech meeting that was supposed to present solutions taken by several different companies. It turned to be a huge complaint-fest about Android javascript performance and the only happy people were those using Xamarin (which is native).
Edit: Note that I think that using web views for applications like banking or chat and so on is perfectly fine. My issue is with apps that eat a lot of incoming data and/or have to change what is displayed very often.
Perhaps systems that automatically build out to iOS have not been updated to use these features, or there is something else going on in Cordova to introduce latency? Because for at least 2 years now there is no reason to have the problem you describe.
You clearly haven’t used WKWebView. It renders off-process, so actually data passi gbetween your native code and the JS contained in it is even slower. This is in addition to the many many many limitations due to the off-process nature of the system.
What good does it do to make a webpage using technologies that will have support two decades from now (by the way, that isn't happening either), if what you need is people using your webpage/app now?
RN came from a giant company that uses it in its core product. Big difference.
cf https://talks.golang.org/2012/splash.article
(Agree with parent but not wanting Go to be left out of the "giant company" bucket.)
The framework is a nice idea, and will definitely help into diversifying some of the mobile frontend stuff.
On the other hand you can't compare RN to this framework.
As the person you commented on, facebook has been using RN on its main products like instagram, so it has proven that the framework can be placed on production ready apps with a massive userbase.
Yeah the kids nowadays are terrible.
Large codebases have never been particularly welcoming to newcomers.
At least React Native has been around for a while and has a good sized community.
This is a neat little project but I would treat it like a toy unless you were willing to step up and take over maintence before usi it for a production app.
(This wasn’t meant as a stab at React Native, it was meant as a warning about picking up frameworks that don’t have much history. RN is a few years old. I don’t think it will disappear next year).
RN is an entirely different beast...
I've started working on a side-project developing a mobile application when Fuse[1] got "traction". I remember the bashing on HN regarding the name (since well libfuse). I'm usually all sys/backend, but I've got into it. You start digging through their board and see a lot of examples, catch around stuff on their channel and so on. Kind of joy sometimes.
The thing is, I've been planning to support both iOS and Android from the early start. So that was really a great choice, it looked promising. Or so was I thinking.
After fine 7 months, my new shiny mobile app. was behind somehow manageable code and one developer - me. Stay still, I never worked on mobile before. So I went for market and hit few clients at an early stage. Good news everyone, we got this. As a co-founder with other two, designer and marketing manager, we went out as a `free` and rent the magical space. The hype was there and -. Clients started requesting features, which meant another success. The ideas presented were fine with us and I started working furiously on it. Pressure and all, inb4 start digging for more developers. Few remote devs and features are ready, users love them. Now it gets to more advanced features, UI, code starts to get abstract, and devs aren't sure if they web, script or compile. We somehow managed to stay on ball.
After five such months, we ditched the Fuse and rewrote to native. Since devs where remote, they understood the cards. Some of them are still here. Now we are all happy, codebase is eh.. fine, stuff are supported, you know.
The story speaks I think. These tools, at early stage, should be took as a grant of salt. I do however appreciate work given towards creating xp stuff. Some of these tools are great for prototyping.
Why would we voluntarily choose an inferior 3rd party tool when superior first party tool exists?
No, write it thrice (need mobile web version as well).
This inevitably leads to a copy of your settings and account management page ion the web. At that point, why NOT get people into a decent experience as fast as possible?
I get that you like Go, logically (although emotionally, I can only feel confusion from such an idea). But no one has even remotely offered an idea what advantages Go brings to this table other than "I like it!"
Which is cool, but I loathe it. So unless there are compelling things in this framework (hence my question) this seems like a great way to use worse tooling and an awkwardly shoehorned language to fail to accomplish exactly what other frameworks have failed to do.
On the basis of language, Go is a regressive and under-performant pile that people seem to love largely because of its nostalgia factor.
What about this framework helps to offset how awful Go is?
How much time and dedication he devoted in this is really amazing.
> The gomatcha.io/bridge package handles the interface between Objective-C and Go. Go values become MatchaGoValue in Objective-C, and Objective-C values become *bridge.Value in Go. Methods and functions can then be called on these objects using reflection.
Does this mean that you can call any of the Objective-c frameworks from Go lang side? if so, and if working well that would be a huge improvement compared with react-native.
Looking at it from another perspective, there's a practical difficulty to being able to dynamically invoke any ObjC function from Go: the ObjC compiler would still need to know what libraries to link, and header files to include.
It seems to me like it must be, rather than the cross-platform thing, because what people are producing seems heavily weighted toward “here are UI components you can use” (or even in the react native case “here’s an entirely different way of doing UI, yanked straight from webland”). Whereas if it were just a matter of sharing a codebase across platforms, it seems like it would be easier to work on a compiler-side, e.g. by extending clojure, scala, etc. to compile to swift.
But maybe that’s just my bias because I look at any ui code from anything and my eyeballs start to bleed.
I've never done production mobile app, just played with examples on iOS and Android, wondering if this is a good framework to play with and eventually use for production mobile apps