I think it's really great to see a project like this coming out, as someone who loves writing Go on the server side, but has been grinding my teeth through learning JS to be able to do client-side work. That said, I would love to hear more about how a compiled Go app will handle three of what I see as being RN's biggest advantages:
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...
Yeah unfortunately, those are downsides that I don't think will change unless we get Go on wasm or something similar. Go brings its own advantages though. Fast, static typing, goroutines, theres no need for JSX, etc. And personally the JS ecosystem doesn't appeal to me at all.
I'm the author of this framework. I think Matcha has a really cool approach to building UIs. Everything is built on top of interfaces, so its very easy to reuse and customize components and layouts. Its not quite production ready but I can any answer any questions.
I really like using go for writing e.g. the logic part of an Android/iOS/Desktop app. Would not it make more sense architecture wise to write UI real native and do the interfaces really well to the logic binary go parts? Are there good examples/libs for this approach?
Thanks overcyn great framework. How you are bridging between iOS and Android. Can you provide simple example code that make me understand how you make things working and internal details.
It will help me to understand better. Any future plans to write blog.
The thing with frameworks like this is that the time invested could be lost if the framework looses traction. I am very hesitant to use a framework like this for anything serious and business-oriented.
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.
Exactly. I wonder if in the future we will more demand API stability of our host platforms so we aren't rewriting the same framework on every API change. I feel like I'm always building on sinking sand, that my programs have half-lives shorter then radioactive elements. Say what we want about Microsoft but they have always valued API stability.
I just saw a tweet this morning reminding React Native people about three20, the previous Facebook framework that they abandoned.
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).
Yes, and there is not big company behind this one as far as I can see, Google's Flutter and Facebook's React Native will for sure have support from these companies cause they have projects written with their frameworks but this one, I'm hessitant.
The biggest problem with these frameworks is that they ignore the elephant in the room.
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.
Thats true, however in the long term, we need a react like framework that solves cross platform development. React Native has lots of problems with navigation, the AirBnB team even stopped using it seriously.
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.
Cool! This might make it a lot easier to get IPFS going on Mobile platforms .. there is already a shim for getting IPFS built and running alongside a native iOS app but it'll be much more interesting to do the whole thing in Golang ..
I would love to use this at some point. I would also contribute towards the development of this framework. I love Go and I don't want to switch to JavaScript when I want to write a iOS/Android application. Everything has to begin somewhere. This is probably a first step to something fine.
I amazed by seeing this type of frameworks and code written by a single person. How can one person write this type of framework. I want to learn this. Anyone please provide suggestion how to make myself better like this.
How much time and dedication he devoted in this is really amazing.
Thank you, I appreciate that! I was just lucky to have saved enough money to take some time off and work on something I find interesting and think has a lot of potential.
> 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 the examples for calling ObjC from Go, it looks like you still need a native piece of code to register the ObjC function being called and act as a shim (so same as RN I think).
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.
The reflection is limited to calling methods on objects. So it would be difficult to directly interface with Apple frameworks. You couldn't build closures or respond to delegate callbacks for example.
I’m curious about something. Asking as someone who doesn’t make a living slinging code, and who is kind of terrified of mobile development because of all the UI stuff (xcode makes me want to cry), in case any pro mobile devs want to answer: is the UI part the real pain point here?
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.
UI is the difficult part in my opinion. iOS and Android take different approaches to building apps so even if you had a language that perfectly compiled to both Swift and Java, the code to build your views would end up diverging significantly without some sort of component library.
This is actually based on top of gomobile. Gomobile provides language bindings and Matcha adds a usable component library on top of that. It serializes Go data structures into protobuf, passes it through to iOS/Android and creates the necessary views. Matcha also does all the layout, event handling etc.
Wasn't there a proposal to expose native functionality in browsers on iOS and Android? If that were to be finished it could make things like this and react native less necessary.
Why would Apple ever implement that? They’ve made their point of view on preferring native development (and being very cautious about what’s exposed to the browser) very clear.
For me one of the showstopper for webapps on iOS was that there is no immediate, synchronous way to communicate data between the native part and the visualisation part. Since the only way is to communicate via messages which are painfully slow.
can someone explains how this is different from ReactNative, Phonegap, etc.
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
You can definitely mix native and dynamic views. Theres an interface for registering custom views with the framework. It doesn't need to take over your entire app either. Matcha gives you a view controller, which displays the Go stuff, but that can be presented however you like.
[+] [-] jd20|8 years ago|reply
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...
[+] [-] ASinclair|8 years ago|reply
[+] [-] overcyn|8 years ago|reply
[+] [-] megawatthours|8 years ago|reply
Please do! Genuinely curious what you don't like about it.
[+] [-] O_H_E|8 years ago|reply
[+] [-] pjmlp|8 years ago|reply
As someone with experience in Delphi, C++ Builder, Smalltalk having younger developers rediscovering this looks funny.
Have a look at Flutter and Xamarin.
[+] [-] solidr53|8 years ago|reply
[+] [-] Gonzih|8 years ago|reply
[+] [-] overcyn|8 years ago|reply
[+] [-] therealmarv|8 years ago|reply
[+] [-] codesternews|8 years ago|reply
It will help me to understand better. Any future plans to write blog.
[+] [-] dcu|8 years ago|reply
[+] [-] tobiaswk|8 years ago|reply
[+] [-] ship_it|8 years ago|reply
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.
[1] https://www.fusetools.com/
[+] [-] RubenSandwich|8 years ago|reply
[+] [-] MBCook|8 years ago|reply
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).
[+] [-] cgomezmendez|8 years ago|reply
[+] [-] jd20|8 years ago|reply
[+] [-] pbreit|8 years ago|reply
[+] [-] disconnected|8 years ago|reply
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.
[+] [-] TeeWEE|8 years ago|reply
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.
[+] [-] mmjaa|8 years ago|reply
[+] [-] KirinDave|8 years ago|reply
Why would we voluntarily choose an inferior 3rd party tool when superior first party tool exists?
[+] [-] srameshc|8 years ago|reply
[+] [-] codesternews|8 years ago|reply
How much time and dedication he devoted in this is really amazing.
[+] [-] overcyn|8 years ago|reply
[+] [-] alfonsodev|8 years ago|reply
> 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.
[+] [-] jd20|8 years ago|reply
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.
[+] [-] overcyn|8 years ago|reply
[+] [-] paultopia|8 years ago|reply
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.
[+] [-] overcyn|8 years ago|reply
[+] [-] cweagans|8 years ago|reply
[+] [-] overcyn|8 years ago|reply
[+] [-] _m8fo|8 years ago|reply
[+] [-] MBCook|8 years ago|reply
[+] [-] yoz-y|8 years ago|reply
[+] [-] abhas9|8 years ago|reply
[+] [-] bedros|8 years ago|reply
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
[+] [-] anindha|8 years ago|reply
[+] [-] overcyn|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] tkubacki|8 years ago|reply
[+] [-] thedonkeycometh|8 years ago|reply
[deleted]
[+] [-] lcfcjs2|8 years ago|reply
[deleted]