papertiger

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.

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.

Cappuccino http://cappuccino.org/

SproutCore http://www.sproutcore.com/

Ext JS http://www.sencha.com/products/js/

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.

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.

No, it's not like saying that at all.

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.

EDIT: Removed snarkiness.

I wish I could downvote you.

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.

This is a truly horrifying prospect.

Something similar occurred once for me as well.

This is much more than screenshots and jQuery does not eliminate the need for interactive cross-browser testing in any way.

The company I work for has email and phone access to a Facebook developer for questions, but we are part of a beta program.

When I browsed the API on my own it was an utter disaster on par with the article's description.

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.

I suspect people would ignore it anyway.

It would be nice if the article actually named the app rather than just the developer.

Does anyone know the app name?

To each their own. "Great" is subjective.

I find the frequent major changes in the Ruby ecosystem to be quite frustrating. That's not to say that I wish this progress wouldn't occur... I just wish it would occur in a more controlled manner. Documentation seems to suffer the most and I have definitely come across a few libraries that don't "just work". I love Ruby and the Ruby community, but I long for the day when things move at a less frenzied pace... I know it would put my managers at ease, too.

Thanks for posting this update.

Well said. As soon as an application hits ~100 routes everyone would be writing their own routing layer just to be able to flexibly manage it all.

Convention born of common usage is a strength of Rails.

Agreed. As I see it, this actually limits the power of JavaScript rather than extending it.

Edit: I like to see people pushing and extending a language so I appreciate the author's effort... but I think it is misguided in this case.

Not so smooth on Chrome/Ubuntu (on Mac hardware) either.

Cool experiment.

I use rackspace hosted email as well. Very happy with it.

There are many reasons to pay for a dating service beyond the number of users, such as a preference in any of these categories: 1) communication process / privacy controls 2) interface features (filtering options, etc.) 3) advertised or implied goal of the service (marriage, hook-ups, etc.) 4) strong concentration of users in your demographic

Also, some of the things that the article discussed, like the "desperation feedback loop", apply equally to paid and free dating services.

I normally love to read OK Cupid's blog posts, but this one struck me as a little vicious and disingenuous.

Great video.

Just a warning to any viewers: I think it might be a bit out of date now. I don't think node has promises anymore and I think they also have blocking and non-blocking versions for most operations (meaning callbacks are optional).

I don't think open source makes that consideration irrelevant. It is an important factor when choosing a framework. I would bet that most of the users and probably a good portion of the contributors are using a framework precisely because it saves them from spending the time to develop/maintain those features on their own.

Cappuccino would go on, but one must acknowledge that it could certainly flounder without the solid direction, organization, and vision that brought it into the world in the first place.

Looks nice, but I'm not sure why JavaScript needs to be like Ruby.