Hacker News new | past | comments | ask | show | jobs | submit login

And that brings us back again to the fact that JS, CSS, HTML5 and Canvas make up a horrendously bad development platform for the kind of apps you see on the iPhone, or even Flash. It's not impossible, if you have brilliant developers and many millions of dollars of resources like Google does, but it's much much more difficult.

Ironically, a main disadvantage it has is extreme dependence and incompatibility among different browsers, and dealing with this can easily swamp the development cycle. Even performance differences across different versions of JS can make massive differences to an application. This situation shows not even a hint that it could improve in the future. Developing for iPhone, you write the app once and it will work the same on everyone's hardware.

I've been modded down on forums for a couple of years consistently for pointing this out, yet you sure don't see many developers actually building complex apps using JavaScript platforms, despite the lip service given to it.




Disclaimer: I'm a co-founder of NOLOH (http://www.noloh.com)

I'm sorry but this isn't true. Platforms such as NOLOH, Cappuccino and many others allows you to develop sophisticated web applications without having to worry about JS, CSS, HTML5, or browser differences, among many other things.

You say Developing for iPhone, you write the app once and it will work the same on everyone's hardware, similarly developing with NOLOH or Cappuccino for example allows you to write your code once and have it work automatically on all browsers, and operating systems.

Furthermore, you definitely wouldn't have to spend millions of dollars to develop products like Google's with these technologies.

As a matter of fact we've had complete novices use NOLOH and create applications significantly more advanced than their counterparts applications from Google, Microsoft, and others.

The problem is that as you say developers aren't using the tools that are available, it's not that these tools don't exist. In my interactions with developers the problem usually stems from not wanting to use these tools that are available. For whatever reason when it comes to the web many developers don't feel like they should be using frameworks, but rather deal with the hell that is the current web themselves.

However, when it comes to building applications for iPhone, iPad, and similar devices they have no problems using the frameworks provided to them.

You can have the best tools around but if nobody uses them it doesn't matter, but saying that the web is a bad development platform or that it takes many millions of dollars of resources just isn't true any more. All it takes is an open mind.


I call BS, even if you build an application for a single browser on a single OS trying to get any sort of complex application running with the range of screen sizes and interfaces (keyboard/touch/PS3 controllers/crappy cellphones), and processing power is just not happening without serious compromises. So while the browser wars are part of the problem you still need to pick your target audiences and develop for several platforms.


What does easing of delivering applications over the web have to with the fact that you have to separately design separate UX for different devices. You are talking about different two problems as they are one.


So you'd allow it would be possible to bring out a kick-ass JS app framework targeted only at the iPad?


Relative to a native application no. Relative to strait JS with a minor cost of performance, yes.


Btw, in developer zone on your website, I get a weird alert: ReferenceError: _NFindX is not defined.


Thank you for notifying us. We'll post a fix shortly.


Developing for iPhone, you write the app once and it will work the same on everyone's hardware.

I think you meant, "it will work the same on everyone's iPhones".


Are the browser differences really worse than differences between OS and dev environments? That is, rather than even out browser kinks, you'd prefer to port from Java to Objective-C or vice versa?

Also so far most mobile browsers seem to be based on WebKit, and you can assume a specific browser, so it should be easier than on the open www.


That's why the article argues that Google should be releasing tools to make this development easier - a framework can deal with a lot of the inconsistencies between browsers.


A framework would be a start, but overall a very incomplete solution that's nowhere near as nice as the well-defined playground that is the iPhone/iPad and their corresponding app stores. JQuery and friends brought cross-browser web development, with animations, ajax, etc., into the realm of possibility for many people where it would have been completely impractical to do before. Even still, getting cross-browser apps to run when everything is written cleanly results in a lot of piled-on hacks.

The biggest problem though is a lack of a well-organized app store: centralized distribution, the arguable benefits of a review process, and most significantly the monetization framework that it provides.


BTW - great idea for startup. Create a framework to monetize web apps/software as a service similar to the one provided by the AppStore and Apple ecosystem...


This is the vision we have for Cloudomatic.


I was on your website but all I can see is the SaaS directory. Do you plan on introducing some kind of payment framework?


:-)


Google did release Closure, a cross-browser javascript kit. http://code.google.com/closure/library/

Also, GWT.

Probably doesn't go far enough for "easily make user interfaces" though.


To play Devil's Advocate, why would Google want you to create stuff that works across browsers? They have their own browser and are creating an operating system based on that browser. It's in their interests to reward you to develop on Chrome, in the hopes of causing a similar app-driven fanboy rush for Chrome OS.


Because Google makes money on browsing, not selling web browsers. The faster and more functional everybody's websites are with all browsers, the more page views result, and the more money Google ultimately makes. Its in Google's best interest that all browsers can navigate the web effectively.


Even if such a thing could cope with rendering differences, there's not a damn thing it could do about performance differences (unless it artificially slowed down everything to run as fast as the worst browser).


I didn't intend to say anything stupid here...why the downvotes? I don't care about the karma, just want to understand why I was wrong.


".why the downvotes? I don't care about the karma, just want to understand why I was wrong."

Voting on HN has gone to the dogs a bit recently with thoughtless (and often mass) downvoting. There is often no real "reason" except some dumb fellow got up oon the wrong side of the bed today.

My suggestion, don't worry about it, just say what you want to. By and large, good comments are upvoted sooner or later. (upvoted you btw)


Thanks (and I agree with you), but like I said, really not concerned about the karma. Just wanted to know if I'd said something foolish or incorrect.


Computers have different speeds, and the same software still runs on them. (Unless the computer's too slow or the program is sloppily coded, but then that's the fault of the manufacturer or programmer.) Why do you think a framework should iron out performance differences?


I specifically don't think that. My comment's grandparent mentioned performance differences between browsers, and my comment's parent suggested that a JS framework could smooth out differences between browsers. I was pointing out precisely that a JS framework wouldn't be able to compensate for that.


Add to that the effort it would take to support credit card processing to sell your web app, then compare whatever you'll build to the two-taps buying process in the App Store. For a large class of applications [1], there's little doubt that developing for the App Store still has an enormous advantage over a web-based counterpart.

1. Luckily for Apple, it's precisely the class of applications that makes them money. I can't imagine Steve cares very much if GMail is a native or web application.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: