Live data from Hacker News

The Shape of Mobile Development To Come

clayallsopp.com

21–30 of 45 posts

Re: The Shape of Mobile Development To Come

#22
post #8

One thing all those "let's build our app on top of 1000 layers so we can use our $favourite language"-people tend to forget is that mobile software runs on mobile devices. Which have one remarkable property: they are energy constrained. So you better write some fast, native code or your users will have trouble keeping their devices alive for one day.

I think RubyMotion proves that alternative languages don't need to come at a cost to performance. It's tougher to write a custom compiler like RM uses, but the end result is identical performance to normal Objective-C. "Just" write a similar compiler for Android/Dalvik and you're there ;)

Re: The Shape of Mobile Development To Come

#23
post #4

Until mobile phones become a lot faster and carry more storage and bandwidth becomes a lot cheaper and more ubiquitous, I believe the most successful approaches simply adapts the underlying framework for use with other languages (and abstraction levels), while simultaneously minimizing the excess baggage/payload required to get a small application up and running. Clojure for Android for instance suffers from this pro…

Are there any languages that directly target Dalvik/dex without compiling through Java bytecode?

Re: The Shape of Mobile Development To Come

#24

The problem with write once run anywhere is that it's not desirable to device manufacturers apart from those on the bottom rungs who don't have a big enough developer community to carry the devices on their own. If MS and Apple threw JVMs onto their devices then we would be 90% of the way there already. If any write-once-run-anywhere solution becomes to popular then the likes of MS or Apple will try their best to kil…

> If MS and Apple threw JVMs onto their devices then we would be 90% of the way there already.

As a one-time proponent of write-once-run-anywhere solutions, I would have to say this would probably result in a reduction of UX quality.

Re: The Shape of Mobile Development To Come

#25
post #17

Earlier quoted context omitted.

I agree. Xamarin is closer than anybody else to a viable cross platform solution. They're in just the right place now to start eliminating some of the worst pain points in mobile.

Appcelerator ought to be as well (with the added bonus of using JS, far better known than C#), but their platform isn't on the same level. Yet?

Haven't tried it myself but the reviews on the web seem to be almost universally bad whereas most Monotouch users seem to be pretty happy. I think for larger code bases C# has some important advantages over JS.

Re: The Shape of Mobile Development To Come

#26
post #17

Earlier quoted context omitted.

Appcelerator ought to be as well (with the added bonus of using JS, far better known than C#), but their platform isn't on the same level. Yet?

Haven't tried it myself but the reviews on the web seem to be almost universally bad whereas most Monotouch users seem to be pretty happy. I think for larger code bases C# has some important advantages over JS.

Absolutely. I used Appcelerator a long time ago and it was awful- they've actually made a ton of progress since then, but they don't make fully native apps- there's a JS engine in the middle that parses the code. So it's always going to be a little slower than native- but probably acceptable for a ton of apps.

Re: The Shape of Mobile Development To Come

#27
post #19

Earlier quoted context omitted.

While you wait for the tipping point, I'll be over here shipping.

Shipping slow, bloated software using a framework that is a second class citizen on any platform you decide to compile to.

That doesn't matter. What matters is whether your users care or not. We're all app perfections here, as well we should be, but plenty of people are happy with "good enough".

Re: The Shape of Mobile Development To Come

#28
post #19

Earlier quoted context omitted.

While you wait for the tipping point, I'll be over here shipping.

Shipping slow, bloated software using a framework that is a second class citizen on any platform you decide to compile to.

I write apps native, in the given platform's blessed language and framework.

Re: The Shape of Mobile Development To Come

#29
post #7

Imagine writing code like this and having it build to native apps on both platforms: I think Xamarin are going to be a really interesting company to watch for this stuff. Right now they have MonoTouch and MonoDroid as entirely separate products, allowing you to make apps using C#. But you can already reference libraries across both, and just do the UI plumbing separately, and if they're smart they will work very hard…

I've been doing this for a long time now, probably for the 8-10 months, and I can safely say its awesome. Xamarin is awesome.

Re: The Shape of Mobile Development To Come

#30
Liked your idea and will follow your developments on GitHub with an eye towards how you're going to integrate a CoreData client-side library. Besides the front-end issues you highlight, a key challenge will be synchronization: unless you don't plan to allow your users to work offline?

I agree with your hope that Rails could somehow be extended to cover this mobile use case, wish I had the chops to create a Devise+MobileAPI generator with a iOS native MongoDB-sychro engine. (Can Rails generators synthesize ObjectiveC source code?)

By the way, every time I think about doing something about this I keep an eye on the folks at Parse.com: seems like every week they're solving more and more of the backend part of this problem. And they're working on front-end libraries as well...

Post reply on HN