Pewpewarrows

If my salary depended on the Twitter API right now I'd be scared shitless.

I have yet to see a single viable example of a Knockout app that's been progressively enhanced. Until then, I'm not even going to consider touching it.

I'm in the same boat as you. I absolutely _love_ developing sites JavaScript-free on the first pass. It really makes you realize how much of a crutch it's been that you've depended on, and how much you can get away with these days without it, especially with the rise of newer CSS features in the last couple of years.

At the end of the day you're left with a very fast and clean site that you can, after careful consideration, add very tiny JS snippets to in order to improve UX in places.

As someone who works in the security industry, I can tell you that we really get a kick out of every coffeeshop Rails or JavaScript developer who throws together a quick demo over a weekend and calls it "hacking."

I'm well aware of the history of the subculture and that the term precedes infiltration of computer systems. But that doesn't make every night that you stay up late programming a "hacking" session.

Very good summary of what to look out for. Here are a few others that I ran into back when I was still entertaining the idea of using Mongo in production:

1. The keys in Mongo documents get repeated over and over again for every record in your collection (which makes sense when you remember that collections don't have a db-enforced schema). When you have millions of documents this really adds up. Consider adding an abstraction mapping layer of short 1-2 character keys to real keys in your business logic.

2. Mongo lies about being ready after an initial install. If you're trying to automate bringing mongo boxes up and down, you're going to run into the case where the mongo service says that it's ready, but in reality it's still preparing its preallocated journal. During this time, which can take up to 5-10 minutes based on your system specs, all of your connections will just hang and timeout. Either build the preallocated journal yourself and drop it in place before installing mongo, or touch the file locations if you don't mind the slight initial performance hit on that machine. (Note: not all installs will create a preallocated journal. Mongo tries to do a mini performance test on install to determine at runtime whether preallocating is better for your hardware or not. There's no way to force it one way or the other.)

I don't care what the argument is about: this is not the way to get people to take your "side" seriously or to consider the points you're attempting to make.

I'm a Python/Django guy so I'm not intimately familiar, but is that really the case? I was under the assumption that the handler wouldn't pass any POST vars not in attr_accessible to the model. In which case additional, unexpected ones would become silently dropped.

I hope you realize that this is the identical argument PHP developers made whenever someone brought up how insecure the base language, libraries, and configuration were.

Users of a framework should have to go out of their way to make themselves insecure. It shouldn't be insecure by default.

Blanket accepting POST data to insert into your database is a terrible idea.

Rails gives you attr_accessible and attr_protected to alleviate this problem. Protip: the one from those two that you suggested to use is just as terrible an idea as allowing blind POST into your database. Blacklisting is always the wrong approach to security. I don't care if you have to repeat yourself and type more characters: use the whitelisting of attr_accessible.

The point isn't to have exact same gender ratios in the tech industry.

There are women out there who would make great programmers / sysadmins / etc, but never finish the process of becoming one, are dissuaded from ever starting, or flat-out quit the industry after N number of years, simply because of the barriers put in place by men assuming that the field is only for men.

It's typically faster than any Wifi I can connect to. So yeah, absolutely.

Not to bring up the idiotic semicolon debate again: but if you write your JavaScript without semicolons, you're forcing everyone else that wants to use your library to conform to your style guide's rule if they want their code to work:

https://gist.github.com/2399955

The build process will concatenate those two files and your semicolonless JS will cause a bug in my script. That's not being pragmatic, that's just being a jerk to the consumers of your library. I shouldn't have to add unnecessary safeguards to my code because you want to abuse an error-correction feature of the language to avoid typing semicolons. You want to type fewer semicolons, so you force everyone else to add more.

/rant

Except that, once you're done developing a hybrid app, you now have a giant chunk of reusable code. Facebook simultaneously supports several different platforms (normal website, mobile website, iOS app, Android app, Windows Phone app, Blackberry app, etc). Any amount of code reuse is a huge win when you're trying to maintain feature parity in many different directions.

As others have been pointing out feverishly on Twitter: the problem wasn't them betting too much on HTML5. Their problem was developing piece of shit apps that happened to use HTML5. They tasked amateurs who didn't know what they were doing into building a hybrid native app container which in turn embedded HTML5 content. Plenty of other developers (Instagram and LinkedIn come to mind) have figured out how to do that right, and in a way where it is seamless to the end user and for all intents and purposes feels exactly the same as a native app.

I'm not saying that it's an easy problem. You have to find the right balance between which components should be native or not. It's clear from the other problems that Facebook's been able to solve that they know how to hire top-notch developers. They just failed to do so for their mobile efforts, which just reinforces the stereotype that they don't "get" mobile.

Just to play Devil's Advocate, this is what I'd imagine the average Libertarian response to this would be:

In a free market the consumers hold the power. An ISP that didn't restrict Internet usage or tier what it offered would become in-demand, and would profit and succeed more than the others. In other words, the market would correct itself towards those ISPs that espoused the principles of staying neutral. If that didn't happen, then net neutrality isn't a big enough concern to drive the average consumer's purchase.

It's a simplified generalization, but take from it what you will.

His HN profile immediately talks about running Reddit's servers. And he's using the same recognizable username. I don't know how more obvious it could have been.

If you're going to write an article going after Jeff Atwood for criticizing PHP, you probably shouldn't host it on a poorly-written PHP website that can't establish a database connection. You're not helping your case.

Besides the blatant sexism that's ripe throughout this woman's interaction with various staff members at E3: there's another underlying problem.

You shouldn't have to hold someone's hand through a game demo. And you certainly shouldn't need a PR person there to sell the game to your members of the press. The game should be as inviting and enticing to veterans who have been resting their fingers on WASD since they learned to walk as it is to someone who is just picking up a controller for the very first time.

Draw me in, let me lose myself in your entertainment, and don't make me think. A shining example of this is when first-person shooters stopped hiding the "inverse look" option in the deep recesses of a menu, and instead just asked you to "look up" when you first start a new game. Whatever direction you choose (up for up, or down for up (inverse)), the game then immediately flips the option for you behind the scenes. That's the level of UX and approachability that should be applied to every control and game mechanic in your title. A fact sheet shouldn't even be available. Make me fall in love in the first 5 minutes, like a well-crafted movie or book.

Games get away with so much because they can become addictive and time-consuming. And they'll still sell by the millions.

And again, you're completely missing the point. One user's UI clutter is another user's essential UI component. Doing actual UX studies on your interface is essential (which I assume Disqus has done thoroughly).

Your original comments claimed that a mythical "the user" doesn't care about the Reactions, Community, or star buttons, citing "common sense." That's not a UX study. That's you trying to spin your personal opinion as fact. Which is cute, but is not useful criticism in the slightest.

I've found that the best solution is to _not_ make your website "just another client" of your API. On the initial page load, render the page normally using your server-side templating. Then have your JavaScript introspect the existing DOM and enhance it into a very interactive close to single-page app, using client-side rendering from that point forward. Yes, there's code duplication with templates, and you have to deal with certain peculiarities like implementing a user event queue between the time the page loads and the JavaScript is done hooking into everything so you don't lose user interaction. But those are pains I'm willing to deal with.

Now you're just jumping through hoops to avoid linking to anything concrete. It's a shame, I was looking forward to hearing real arguments from you, instead of a fabricated "common sense."

How is formal UX research out of the picture? I asked you for some, you refused. If you're not going to even bother backing up your claim I'm not going to bother discussing it any more.

If it's not a community then it shouldn't have usernames, a comments section, or trackable karma. Just reduce it to submitting and voting on links.

I really hope you see the irony at some point that you're complaining about social elements in an inherently social page element: the comments section.

And I didn't downvote your original comment, so I have no idea what you're talking about. Then again, I don't understand why people are sensitive about fake internet points to begin with.

> By the common-sense criteria.

Stopped reading right here. Either provide UX research to back up your claims, or stop pretending that they apply to your mythical invention of "the user."

Self-destruct codes and patching up the hole you came in through are both pretty par for the course when it comes to non-trivial malware.

As a Python guy I never had any reason to need to learn Ruby. And even now that I'm playing around with it it's purely out of professional curiosity.

People tend to conveniently forget that it's the consumers in an economy who define a monopoly. There's nothing inherently wrong with it. If a monopoly occurs because the majority of consumers are giving that product/service their money, then it must be deserving of it. If enough people are dissatisfied with the quality, they'll turn to new business, and the monopoly will cease to exist.

The market has and will continue to regulate itself without legislative interference. I see no reason for the government to get involved with Apple's private marketplace.

Edit: I'll put it this way: You don't like Apple's closed market because they can define arbitrary rules that makes it hard to compete. How is that any different than a Government defining arbitrary rules on the national marketplace?

To be fair, you need to know the entire left-hand side of that graphic with PHP. The bottom-right quadrant is stuff you _should_ be doing (formalized methodology, version control, and testing). And the top-right quadrant is language-specific, in that you can replace it all with PHP and your PHP framework of choice (if necessary).

How exactly does PHP make it easier again?

It's no use debating with someone that absolutely refuses to admit the possibility that their tools are sub-par.

If your feelings get hurt: good. Maybe if it happens enough times you'll move on to better tools and technologies, you'll have an easier time building better products, and your customers will be more happy.