Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Shape of Mobile Development To Come

clayallsopp.com

Post reply on HN
Print view View original

1–10 of 45 posts

Re: The Shape of Mobile Development To Come

#2

Post by yesimahuman »

I agree with your true write-once-run-everywhere dream, but I disagree with the conclusion that we build an abstraction over existing frameworks. This is essentially what wxWidgets or QT is for desktop.

While these things were great, in the end what most of us wanted was actually HTML/CSS/JS and the freedom to create beautiful things that it gives us. I would argue that default looking iOS apps are already stale and we want more control (which CSS is great at giving). I am banking my business on the same thing happening long term in mobile.

I agree that webview apps can't compete with native in certain situations, but devices are becoming more powerful every day and web technologies have already proven themselves with a large developer audience.

Also, I think there is low-hanging fruit just in the mobile web space: making more websites work well on mobile devices.

Re: The Shape of Mobile Development To Come

#4

Post by Kjeldahl »

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 problem (1.7 MB payload), while Scala, Mirah (Ruby-like) and Kawa (Lisp/Scheme) seems to do a decent job on providing thinner wrappers on the host platform. I see the same thing on the web as well, with a multitude of languages targeting javascript as the platform. I did a small writeup on "Android development without Java" on http://kjeldahl.net/d7/node/32 if you want more details than I wrote here.

Re: The Shape of Mobile Development To Come

#5

Post by zachwill »

I disagree with the conclusion, but whole-heartedly agree with this quote:

I think there's far more low-hanging fruit in making native development easier than in making web/hybrid apps feel "right". I've seen two just good hybrid implementations (Quora and Pocket), and yet I still run into defects using both.

I think the "write-once-run-everywhere" benefit of web views is disingenuous; the phrase should really go "write-once-optimize-everywhere".

Re: The Shape of Mobile Development To Come

#6

Post by 10char »

ecspike wrote: post #3

He lost me with his "Objective-C ...has evolved over the past two years to become an "easier" language ... " I would argue that it has less to do with the ease of the language and instead the market effects of iOS.

I think you might've misinterpreted what I meant? I didn't mean to imply anything about the growth of iOS or that ObjC being just perceived as an easier language because of the growth. I trying to say that Objective-C was really criticized for its verbosity and forcing manual memory management, and Apple has made changes in direct response to those with ARC and more concise literals, which IMO makes it "easier" (espc. wrt ARC)

Re: The Shape of Mobile Development To Come

#7

Post by untog »

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 on what the author is describing.

Re: The Shape of Mobile Development To Come

#8

Post by franzus »

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.
Post reply on HN