HTML+JS libraries -- such as jquery -- are just fine for interactive document publishing, but are no replacement for Cocoa, Android, or Qt. The lack of common re-usable and extensible UI components is a travesty.
I don't want to dismiss these out-of-hand, but they're really not a replacement for a modern application development framework.
Beyond functionality (of which these can and do provide considerably less), part of what makes a platform like Cocoa/UIKit so valuable -- it is used by every application on the device. The applications will interoperate both with each other and with the OS (background services/tasks, quicklook, spotlight, etc, etc, etc). The interaction model will already be familiar to the user, visual cues will be understood, the speed and inertia of animations (such as scrolling) will be expected. There is an enormous value to being able to leverage user expectation, and this is where too many choices falls down.
I have seen many apps (on all platforms -- iPhone, Android, OS X, Windows, etc.) that deviate from user expectations. Ultimately, meeting user expectations is the responsibility of the developer not the framework.
HTML has its own set of visual cues that you and millions of others easily interact with every single day. I would argue that the interaction model of HTML/JS apps may be as familiar or more familiar to users.
I don't disagree that HTML/JS apps can be difficult to develop, but I do not think they are going to "lose". (I don't think they are going to win either. It's not a win/lose situation.)
Since it seems that your background is in native applications, I just wanted to provide you with some references to frameworks that provide something a little more advanced than jQuery and interactive documents.
Obviously, each team needs to look at its project and goals and choose whether a native app, an HTML/JS app, or both is appropriate.
I'd like to point out a couple of things about these choices for examples of rich UI libraries: All three of them throw most of the DOM, and reimplement almost everything from scratch: structure, layout, and most behavior (outside of that provided by input elements that can't realistically be implemented by hand). I don't think you can ask for a stronger indictment of the DOM and related APIs with respect to implementing applications.
And that's the problem. It's not [p]NaCl vs. Javascript. It's whether the core APIs are designed for the task, which in the case of web applications they clearly aren't. The most egregious failings of web applications stem directly from bad APIs, and if you look at their counterparts (for example) in iOS and Android, there's absolutely no comparison. A better script engine (and yes, almost anything would be better than Javascript) would be nice, but would do very little to solve the API problem (don't forget that NaCl can't call anything not provided by the browser, so it can't serve as an "escape hatch").
There are those who suggest that the browser APIs are close to "good enough" and just need to be tweaked a bit to make it possible to create good, efficient web apps on par with modern native apps. I'd like that to be the case (my day job is working on browser application tooling and infrastructure), but so far it's not happening where it matters most -- on mobile devices. On the desktop you can usually get away with murder because the machines are so fast (and have so much memory), but on more limited mobile platforms (and by limited I mean ~1GHz ARM with ~0.5G of memory) web apps aren't even close to their native counterparts. There are some laudable attempts out there (e.g. Gmail mobile, the Sencha Touch demos), but if you poke on them a bit you start to notice obvious performance and memory issues (e.g., when Safari Mobile crashes on the iPad it's usually out of memory).
Does this mean native apps in app stores will "win", and the web will "lose"? The web "won" on the desktop (for most kinds of apps, anyway), in spite of its severe limitations, because it provided a reasonably stable platform and super-simple deployment. App stores solve the deployment part of this problem reasonably well, but fail badly at the cross-platform part. Can the web be made "good enough" in time to win again? I don't think anyone can accurately predict the outcome at this point.
I wouldn't exactly call them un-targeted; the recipients have asked to receive them. Also, this is an audience that is open to using the offers as a way to get ideas for new experiences.
I'd be interested to know why a contrary opinion honestly held and expressed deserves your downvote (or the 2+ it did get), or your pointless comment.
There is an HN Two Minutes Hate aspect to the steady march of "MS platforms stagnant / not supercool like the flavour of the week we're putting into production" posts getting voted into the front page. News about actual open source projects and cool stuff on C#/F#/.NET/Mono tends to languish / fail to hit front page, consistently. It's fair to call this out.
I'm not saying that open source is staggeringly vibrant and healthy on .NET, though it is making steady progress. I simply try to keep in mind that there is a whole wide world of workaday devs who punch a clock out there, and .NET has big reach into that world.
Sure, it is fair to call this out and I am glad people are doing so. What I find off-putting is the way in which the commenter did so. There is clearly no interest in a civil discussion when someone suggests that the opposing side needs to "Grow up" and that their opinions are the result of a mid-life crisis.
As for my comment being pointless, I agree. Shame on me. Won't happen again.
EDIT: Upvoting you for busting me on my hypocrisy.
I've honestly never understood why startups want to be acquired (besides the monetary gain for individual employees). Doesn't acquisition often destroy or dilute the very successes they've worked so hard to build? (I worked for an acquisitive company that worsened nearly every product/company it acquired.) Why not just focus on making your business better?
Heroku will now be subject to all kinds of pressures and asinine ideas that may not relate to their core offering. As a Heroku user I am concerned and saddened.
Can anyone offer any perspective? I'm puzzled by the acquisition mindset.
Despite what gets repeated in the echo chamber that surrounds hackernews that money isn't the main motivator for entrepreneurs and hackers, it is in fact all about the money.
Of course, day-to-day it has to be about much more than money otherwise it would be impossible to stay motivated. But the end goal is almost always about making a boatload of cash.
I currently design new products for an established company. When I finish a product, there's a trained staff of production, sales and support people that make the product successful. (Just speculating but) it's quite possible that the Heroku folks think they can't grow as fast without some additional business infrastructure. If this accelerates their trajectory, then they'll quickly get some distance between themselves and the zoo of other (not as slick) app hosting platforms. Just having someone else to take care of the legal side of HR so that you can go back to product development, while at the same time putting enough in the bank to live on the beach forever, may have looked attractive. Lots of possibilities, but a billion dollar cash-out is not the only way to make yourself happy in life.
- Freedom to move on to the next project. I bet most entrepreneurs are more interested in creating than maintaining.
- Money/security. The trend toward payouts when raising major rounds is helping with this issue, but still the resources available change significantly with a big payout, plus you can diversify your income stream to hedge against contingencies.
Why would you want to work on the same thing forever? Sure if you found a Google or a Facebook then you may have an ample playground, but most small companies do not have opportunities that interesting. You can try to force a round peg into a square hole or just take your cash and start something new.
Playing or winning the lottery involves nothing but money. An acquisition involves major changes to an organization's structure, its products or services, and the lives of all its employees.
We are probably in a similar program, but our developer contact was basically of no use whatsoever. Probably not his fault - it seems to be a cultural thing as observed above.
Even after last week's developer meeting and subsequent rollout of changes, my request for documentation was met with - not paraphrasing - "We'll get back to you."
Maybe treating any ad network component as a "sub-app" with separate permissions would make it more obvious when a request for network access is unwarranted. As to how something like that might be implemented... I have no idea.
If you search the market for "Jackeey" you'll get several dozen wallpaper apps. I think the article is treating all of them as a single app, which explains the "1.1 to 4.6 million" downloads: they just added up the lower and upper bounds of the ranges for each individual app. And as I said above, they don't appear to be requesting permissions that would let them do most of the nasty things described.
Cappuccino http://cappuccino.org/
SproutCore http://www.sproutcore.com/
Ext JS http://www.sencha.com/products/js/