Comment by h2s | Hacker News Reader

Comment by h2s | Hacker News Reader

You could set your watch by the HN response to a story like this. Pure doom, gloom and naysaying.

Smartphones these days live and die by their app ecosystem. I would love to be working on mobile apps, but for the expense of buying an iPhone, an Android phone and a Windows phone, plus licenses for software to develop for all three. Not to mention the daunting prospect of dealing with Objective C, Java and C# simultaneously. This is a ludicrous prospect for a lone developer.

Give me a platform that costs nothing to develop for and lets me use my existing skills. If there's a website version of my application, let me share components between the two versions instead of locking my mobile version up in your platform's chosen systems programming language and development environment. Firefox OS ticks all these boxes.

I just might be the most average developer out there these days: a web developer. If you enable people like me to develop applications for your device without any bullshit, then you automatically have a bigger set of possible contributors than the competition.

That is why I am cautiously optimistic about Firefox OS. If you build it, we will come.

I'm confused by your statement about "the daunting prospect of dealing with Objective C, Java and C# simultaneously. This is a ludicrous prospect for a lone developer."

Perhaps that's true for a hobbyist. But any professional software developer should already be familiar with at least one (if not all) of those languages, and should be able to pick up the others with very little work.

Once you know C#, for instance, you'll quickly see that Java is essentially a subset of it these days. Sure, there are differences, but they're quite minor. The same goes for Objective-C, to some extent. The syntax is a bit different, but most of the concepts are similar enough. Even the most commonly-used libraries for each don't actually differ that much in practice.

In fact, many developers with experience in industry will have already had to use multiple languages at the same time throughout their careers. They'll already know how to work on several projects simultaneously, using several languages, and many more libraries.

In fact, I'd suspect that most of these professionals would feel very handicapped if they were forced to use JavaScript for all development. JavaScript has proven time and time again to not be a good language for anything but short scripts. Languages like C++, Java, C#, and Objective-C have core features that make large-scale, distributed software development possible. JavaScript lacks these, and anyone working on a large JavaScript code base will know the pains that arise.

It won't be good for Firefox OS if only the most inept developers are attracted to it. That's not the kind of ecosystem that produces useful applications.

Everything this person said is the truth.

I mostly agree with your points, although I personally think that the JavaScript ecosystem is maturing quite rapidly through node and amd.

The point is not that the these three languages are hard or obscure or that using all three is hard. The point is that maintaining the same code in parallel in three languages is a Wrong thing to do. DRY. Big companies can get away with it because they can throw manpower but it's still wrong.

It depends, if your app is just a dumb UI that calls out to services then all the logic etc should be in the server, the UI code should just be displaying and a bit of caching.

Once you have built it in one framework it will be much faster porting it to the others. I know it requires 3 updates when you add a new feature but it's not a major pain and you get native apps running very fast.

I'd also add that I don't think it necessarily violates "DRY".

I think "doing it wrong" would be _porting_ the same code to 3 platforms. A blind port to three different mobile platforms is going to look out of place on at least 2/3 of them.

Unless you're talking game development (where you pretty much invent the UI and UX from scratch), each OS has very well established human interface guidelines.

I largely agree with you, but I think GP is incorrect in assuming it's 3 parallel branches of the same code.

The three ports should all be different, in some cases _drastically_ different, or they're bad ports. The business logic may be the same, but the presentation should not.

Also you point out a very good way to separate the business logic without rewriting it three times. Though I wonder if you could write the business logic in C as well?

I know it could be used as a lowest common denominator between iOS and Android. Android does provide the NDK and JNI so you could bind to C libraries, and Objective-C (IIRC) would allow you to link C libraries as well. Not sure what the Windows Phone toolkit looks like these days, though, so I can't comment on that.

It's not a function of knowledge. It's a function of time.

Couldn't Agree more. A professional dev should know one of these languages well. They should be judicious enough with their time to know that it doesn't make sense to "just pick up" a language for job-related work.

"JavaScript has proven time and time again to not be a good language for anything but short scripts." Perhaps this is just troll bait...

define short. Yeah, maybe javascript isn't good when building a large app with > 100K LOC that uses a bunch of existing code built in C. However, you sure as shit can built a very sophisticated product with javascript. Learn how to use prototypes and you have OO (or avoid that if you don't like it). Use modules (many ways to do this). geez.

Maybe this just struck a cord with me because I am in the middle of a huge project that uses a metric shit-ton of configure scripts that seem screwed up six ways to sunday. I feel handicaped by all the BS that you have to do to get stuff working C++/java that is so trivial elsewhere.

Could they have used Firefox OS as an opportunity to bring another language to the browser, rather than javascript to native? ie. if you could write [Objective C/Java/C#/etc] libraries for Firefox OS and they could be compiled and served to a browser client.

Perhaps not entirely what you're after, but Mozilla's Emscripten project will allow that: https://github.com/kripken/emscripten

You'd be surprised at what JavaScript can do nowadays… https://developer.mozilla.org/en-US/demos/detail/bananabread

Also HexGL: http://hexgl.bkcore.com/

There is nothing surprising in it. 3D rendering is done mostly by hardware (OpenGL), not JS. But try to code something more sophisticated computationally for CPU, not a one function long microbenchmark where the JIT can guess all the types because code is simple. Something like simulating a complex mechanical or electrical system or some discrete optimisation stuff. Then it quickly turns out carefully hand crafted JS even on Chrome is more than order of magnitude slower than naive Java code.

The JIT should very easily be able to guess all the types in a complex mechanical or electrical system, or in discrete optimization. Matrices are fairly consistently typed.

I don't think that JS would do much worse than "naive C" in such a situation. To do well on these sorts of problems, you need to pull in a library that properly uses the CPU's vector unit or the GPU, no matter whether you're using C or JS.

If it did whole-program optimization, it theoretically could. But it is probably too costly. You don't have that much time and resources to optimize JIT, as you have doing static compilation. That's why, contrary to common beliefs on static vs dynamic compilation, still static compilers win in most cases, compared to even very mature things like JVM or .NET CLR, even though they have much easier task than JS.

I haven't counted how many times I've read "magnitude" in this discussion … Does anyone actually have some numbers to back up the claims?

It's not about languages. With a certain level of experience languages can be learned to a useful point in a weekend. The problem is the knowledge of the platform, the APIs, the problems each platform has, which parts you should use, which parts you should avoid, what performs better, what hangs your app, what renders things poorly. All those things require a lot more time to learn.

You're right, the difficulty isn't the language in use. Languages are easy. But learning each of the platform-specific APIs is a much more daunting task. Learning web-based APIs are no less daunting, but given that a huge proportion of new developers are starting out with web dev, being able to leverage their existing knowledge is a powerful advantage.

I would love to be working on mobile apps, but for the expense of buying an iPhone, an Android phone and a Windows phone, plus licenses for software to develop for all three.

Well, do you really need to develop on all three?

Among the reasons I got into Android development was because the upfront cost was $0. I just needed any laptop or desktop made in the past ~5 years, which I think all of us have already.

After several weeks -- when I decided I didn't hate it completely, and I got tired of using the emulator -- I got an old phone off of eBay, and I actually spent less on that than I did on a book from O'Reilly.

It's very easy to start programming for Android.

> Made in the past ~5 years.

I'm dubious unless they've made serious improvements to the emulator since I last used it. (I haven't updated my SDK in probably 3-6 months.)

I ran it on a fairly beefy laptop (although ~1.5-2 years at the time) and it was not an environment I'd consider "fun" to program in.

They have ways to image the emulator for faster load-times, but that's not that much of an improvement, and it only affects the emulator boot-up time, not the application speed.

I should try it again on my new desktop, complete with SSD and gobs of RAM.

But honestly I would not develop for Android [relying solely on the emulator] on a machine much older than a year or two.

I guess your mileage varied, but my experience developing for Android [w/o physical hardware] on fairly recent hardware was not pleasant. Had it been a hobby, and not my career, I would've been entirely put off with the experience. I probably wouldn't have gotten a phone, and I would've moved on to developing for another platform.

Possibly WebOS, I remember it caught my eye back when the Pre launched; and I think it had the whole $0-up-front aspect in its favor.

Oh, I did have issues with the emulator. When I was just starting, I thought my hello-world program was broken because nothing was happening, but that was just the emulator taking so long to start up. Once I learned to keep it running I could iterate much faster, although I still had to be careful.

Still, I got a decent-enough Android phone off of eBay for less than $30. Now I only pull up the emulator as the last part of testing before sending the app off to Amazon.

Not to mention the daunting prospect of dealing with Objective C, Java and C# simultaneously.

Who does this? The vast majority of mobile developers I know specialize on one platform. A small handful are competent on two. Most companies that care enough to be on more than one platform will hire out to specialists for that platform.

You can use C# for all three with monotouch. But honestly it doesn't matter much. Objective C is very similar to C# which is very similar to Java. It is really just slightly different syntax.

And you can always just embed a webview and use html + js if you really want, though that is much harder to work with and less versatile imo.

That is the reason I am not cheering for firefox OS. Why on earth would I want to be limited by html and javascript. Show me a high end game that is written in html 5, or really even a mid tier one. This does not include webgl.

There are loadds of high-end games written in JS: Cut The Rope. Bejeweled. Angry Birds. As well as many more lesser known ones that push things as far as possible.

You say "doesn't include WebGL", but WebGL is just the visual output… a game like BananaBread requires epic performance from JavaScript aside from WebGL: https://developer.mozilla.org/en-US/demos/detail/bananabread

WebGL is one of the main reasons why we can do so much more with JavaScript games so it's silly to cast it aside. Canvas is more than capable for most things, but WebGL is the future of the high-end that you're talking about.

Those are not high end games. Those are casual games that look like they would run better and would work in a wider array of browsers in flash. Also I am mistaken, you can include webgl.

I meant NaCl and other kinds of techs that are really just a bridge that lets code written in C++ or with XNA or Unity run in a browser.

Also that link doesn't work.

I mean, it just doesn't really seem like html 5 is a serious option yet for game development. I'm not saying you can't make a casual kind of game in it. I'm just not sure why you would vs flash for a simple game, or the many much more powerful options which let you deploy to a wider audience(like Unity, Unreal, XNA, even Source).

The only reason I can think of is because it is in javascript, but no one should pick an engine based on the programming language it is written in.

Angry Birds is JavaScript? Are you sure?

http://lmgtfy.com/?q=angry+birds+html5

Angry Birds is written in Lua.

"Smartphones live and die by their app ecosystem"

Have you got a source on this? I am just curious. I love my smartphone, but I basically use whatsapp and the internetm, mp3, video, and fbreader 99.5% of the time.

a) Your set of 99.5% apps are going to be different from those of other people. You need a lot more coverage than that to make a substantial percentage of people happy.

b) It's often not enough to just have an app for a specific task, it needs to also tie into a specific ecosystem. For example I don't need generic VoIP software on my phone, but I absolutely must have access to Skype. For somebody else it might be WebEX instead.

c) Even when there's no ecosystem lock-in like that, there are very difficult categories of apps for new platforms to get access to. Maps would be a prime example. It's absolutely core to the smartphone experience, and perhaps the second most important function of the device.

The existing mobile web experience for maps is rubbish compared to the native apps even for basic things. But it'll get worse once you get into things like off-line use or turn by turn navigation. So who is going to fix that? Unlikely to be Nokia or Google unless Firefox OS becomes wildly successful. Nobody else really has cost-effective access to good data.

Erm, but have you got a source for that? As fun as my anecdotal evidence versus yours is...

No. Do you seriously dispute any of the claims I made, or are you just being argumentative? It was mostly reasoning from common knowledge, not generalizing from my own anecdotal experience.

Of course there's never going to be a totally authoritative source for this kind of thing. You're not going to be able to do a double blind trial of the market success of two smartphone platforms with everything being equal except the app availability.

Yes, I seriously dispute the claims you make, but purely based on my own sample of, say, ten users that I have discussed this with. Hence, I have a completely different opinion, but I don't have a large sample.

I'm trying not to be argumentative, but you're tempting me :).

Ok. Given the depth of your argumentation, I still have no idea of what exactly you don't believe or find convincing. But I'll try to expand on these:

a) The list of the apps you use basically exclusively is completely missing most of the most used categories of apps. No games (used by 67% of smartphone users), weather (65%), social networking (60%), maps (55%), and news (42%). You do have music (45%) there, so that's fine. These numbers are from Nielsen Social Media Report Q3 2011 (I have no reason to trust these number particularly, it's just the first non-anecdotal data I found with a search).

Both the lack of overlap with your list, and the the low usage numbers for even the most popular categories of apps (let alone specific apps), should make it completely obvious that people's usage scenarios are completely different.

b) If you seriously dispute the presence of ecosystem lock-in that means apps in the same category are not fungible, there's no point in having a discussion. Even your own list has WhatsApp that can't be substituted to by any other instant messaging app. Its utility depends purely on your contacts using the app too. Something like iMessage, or BBM, or Google Voice might be in a similar category of usage, but they can't replace WhatsApp for you.

Another example you had was an ebook reader. Again, for a lot of people a generic ebook reader is of little use, since they're already tied into the Kindle ecosystem. While presumably for you the Kindle app is of no use as well.

The prime example of this is InstaGram. Yes, anyone could build a camera app with a fake polaroid filter. But 50 million people wouldn't install it. All of the value of the app was in the ecosystem.

And the list here is seemingly endless.

The harsh reality is that these apps are not getting ported over to every single platform. Can FxOS become an important enough platform that it warrants porting to? Maybe. But it almost certainly needs to become an important platform first. And becoming a major platform without having the apps is tough. Hell, even getting a good review for a device without the apps is going to be tough. See e.g. reviews for the Nokia N9, Lumia 900 (and we're talking WP7 here!), any Android tablet.

c) Let me turn this around. Where do you think a good mapping solution for FxOS is going to come from?

Reply on news.ycombinator.com