Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The client-side mess? I just use MOAI. Lua is a lovely language, and the MOAI engine itself is so well thought out, that I can manage to build our client apps for Windows, Linux, MacOSX, Android, iOS, Chrome NaCL, and even HTML5+JS target platforms. With the exact same code.

At this point I just don't see any point to doing things natively. Actually, the tools that MOAI provides (and some of the other community frameworks that sit on top of MOAI, such as Hanappe or Flower) are decent enough, and contain all the basics, to implement pretty much any of the fancy GUI interactions seen elsewhere. And the appeal of being able to write an application that works - and looks the same - on all of the above platforms is just too great; in spite of the investment in learning a 'non-standard' framework, and in spite of the fact of nobody else knowing much about it (and thus no google'able answers to dodgy questions), I still feel this is the right direction to go. Especially since MOAI is open-source, and you can put the host VM anywhere you are capable (technical competence-wise) of doing it.

So I don't do native development for Apps any more. My ObjC/Java/C/C++ chops are still highly useful, but these chops are being used in a different context now: instead of writing a native app in one of these languages, I just write a host - and then use Lua to do the app logic. This is just so fun, I hope everyone starts doing it soon. ;P



To be frank, except for games (and even then it's not disagreeable to provide a nice, native UI), I disagree with you quite strongly. As is the usual case, language choice is completely arbitrary, but intentionally aiming for constancy across your narrow range of apps, instead of focusing on working to the platforms strengths is a very dangerous, and damaging approach to take imo.

Although i will say, i do not have a huge host of experience to go from, but this is from the perspective of someone who could potentially be your customer. With two apps at rough feature parity, i would pick the native app every single time, regardless of how nicely you've styled your app, at the end of the day the burden of proof lies on you; to prove the value of your app, if you cannot be bothered to create an appearance and functionality which is native, chances are that if you can't be bothered to do so, you've cut corners elsewhere.

I'm sorry if that comes across as presumptuous, perhaps i completely misunderstood what you're saying, or just jumped to conclusions, if so sorry, if not, i hope got my point across.


Its a valid concern to have, but the counter-argument is this: the app looks the same, and works the same, no matter what computer you're using. My users love that.


As an aside: Moai is great, but it has a problem with lack of developer activity, to the point that a cynical person could (especially with the abrupt shutdown of Moai Cloud) consider it to be abandoned.

For example, the current official Moai site's link to the downloadable SDK is broken, and there is currently nowhere to download the SDK; you have to build it yourself. There isn't even a proper official release beyond 1.3. And the current master branch has a bunch of outstanding issues, such as a Lua/C-binding-related segfault and the fact that you can't build the code with XCode 5.0.

Right now there are several unofficial forks that could become the new master. Unfortunately, of all the game companies that use Moai, very few of them seem to be contributing code back. At the very least some of them could get together to coordinate stewardship of the project, something which seems completely lacking right now.


> you have to build it yourself

With great power comes great responsibility.

Also, you are wrong about the lack of developer activity - unless you meant Zipline themselves, but we MOAI heads all know that Zipline are too busy making real products with MOAI at this point. Besides Zipline, the MOAI-using community is flourishing .. there is a de-facto effort to address the issues you mention (Binary SDK releases being one of the most important ones), and there has been a lot of progress in the last 6 months towards merging everyones' branches.

>At the very least some of them could get together to coordinate stewardship of the project, something which seems completely lacking right now.

Pay more attention to the forums at getmoai.com if you think this is the situation at the moment, because actually there is stewardship occurring by some of the core MOAI guys. The effort to pull all requests into a new branch and prepare for a community-release is definitely well under way, and you may indeed see the issues you brought up, addressed properly in a few weeks. MOAI is in the transition stages from being a proprietary (yet open) software stack developed by a single company, towards a proper community-supported effort like we all know and love. This will happen.


I'm glad that things are better than they seem.

I had a bad experience years ago with the Genesis3D engine, which was similar to Moai -- open source, really easy to get productive with, an enthusiastic community. Then the company changed its strategy, abandoned the open source version, and the whole thing just collapsed. I wouldn't want to see the same thing happen with Moai.


What kind of apps are you writing in Moai? Games or something else?

I ask because there's a huge problem with rolling your own UI that you might not be aware of: accessibility for people with disabbilities, especially blind people. All of the major desktop and mobile platforms have accessibility APIs, which their native GUI toolkits (or dominant ones, in the case of desktop GNU/Linux) implement. These APIs are very tricky to get right in custom implementations; I've seen many projects get them wrong, especially on Windows, where I have the most experience with this stuff. If your app isn't something like a game that really can't be accessible to blind people unless it's specifically designed for them, then it pays to use the native UI toolkits.


I work in the Industrial sector - we do not have the requirement of supporting hindered folks. Rather, the GUI has to be operational in extreme conditions ..




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

Search: