Yes, the parent was exaggerating.

I'm blown away by how reasonable and thorough that response was. Thank you.

"In terms of development time, Java gets crushed by much higher level languages."

This is something I've seen over and over. Why do you think it's true?

I don't expect some sort of mathematical proof, but I haven't even seen an *argument*. One day I read some comments on the internet and suddenly it had been declared: developing in Java is slow. What happened? I missed the part where we all figured this out.

I've written web applications in Java and Ruby on Rails, among several other platforms. Ruby on Rails was *beautiful*! I had to type far fewer characters to implement simple web application behaviors in RoR than I had in Java. Its elegance was the cause of several changes in my employer's own internal Java-based web framework.

But although I had to type fewer characters using RoR than in the Java framework I was used to, typing characters had never been the pain point. I know how to define simple value objects that represent rows of a database table. No problem. I know how to do SQL migrations. No problem. I know how to validate form submissions. No problem.

And so on it went for every supposed advantage that Rails gave me. I had already solved that problem; I haven't spent significant development time on that problem for years. The real *meat* of the application (what separates it from CRUD apps) and *maintenance* were the pain points for every application. Rails didn't help me there at all. I've worked with other supposed "higher level" languages, and they didn't help with the meat or maintenance either. They all seem weirdly focused on saving characters.

In the process of saving characters, many "higher level" languages sacrifice things like static typing that an IDE would have been otherwise been able to capitalize on. With a Java IDE I usually type a single character before it figures out what I meant (based on the context, which it could only infer because of static typing) and then I click my mouse or press some key to accept the auto-completion. Or maybe I wanted to define getters and setters for some fields, or do some other mundane task that's supposedly verbose in Java... it's most likely that the IDE has a keyboard shortcut for that.

I'm pretty tired of hearing the "faster development time" argument. Put up some proof, or evidence, or anything.

I don't think Google has to unseat JPEG to make WebP profitable. Their bandwidth usage is so absolutely monstrous that being able to serve smaller image files, if even to only Chrome and Opera users, if only through Google's own web applications, is likely to save them an amount of money that will dwarf WebP's development costs.

Many of the improvements to HTML are bug fixes - changing the spec to reflect what browsers already do, rather than what the spec previously (and incorrectly) said browsers did.

More importantly, very, very, very few (best to think "zero") changes to HTML break backwards compatibility. Browser vendors can't do that because it would break the web, and so the HTML spec can't do that because the spec describes what browser vendors have implemented.

Mozilla wants to offer more frequent updates so that their users can enjoy a better browser on average. No one has to "work around" this. I think you're ascribing features of normal desktop software, where major and minor versions of software have a particular meaning, to software based on or meant for viewing the web, which rightfully flouts all the laws of desktop software design. The web is not static, and it updates without your permission.

No. Instead, they want developers to do the same thing they're doing with Chrome now, which is to develop for the current version of the browser, which adheres to the most accurate specification of HTML. That specification is improved constantly, and you wouldn't want to use a browser that implements HTML incorrectly.

I believe there's also a way to add the HttpOnly flag to your session cookie, but I can't remember what it is. It's not as important as those other configuration settings though--all it does is prevent a certain type of XSS attack from exposing the session cookie, described here: http://www.codinghorror.com/blog/2008/08/protecting-your-cookies-httponly.html

That said, if your website is open to any form of XSS, you have bigger problems.

If you're using Java servlets, you can include the following in your web.xml:

<!-- Redirects all http requests to https. Does not send cookies with the redirect. -->
<security-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
<web-resource-collection>
<url-pattern>/*</url-pattern>
</web-resource-collection>
</security-constraint>

<!-- Prevents the application from appending the session ID to the URL.
Also makes the session cookie secure-only, so that if the user has
an active session then makes a regular http request to your site,
the session cookie won't be sent with that request. -->
<session-config url-rewriting-enabled="false" cookie-secure="true" />

You should buy him a Logitech MX Revolution, if you can find one (they aren't made anymore). Its scroll wheel can be configured to switch upon click between regular grindy scrolling and smooth scrolling, where the wheel spins freely without making noise.

That or teach him where the End key is.

YES. I wish I had mod points.

People running slower browsers don't notice the difference because the websites they visit made concessions to account for them. The developers might have preferred to write a super-special-awesome interactive application, but they saw it took IE8 30 seconds to update the page after a button press. So the developers decided to abandon that version of the application, and to provide a simplistic, less user-friendly version for everyone, or to not write the application at all.

The fact that browser vendors are taking the JavaScript performance war seriously is really, really good news for all of us. It might sound like ridiculous nerd-speak when a vendor brags about an x% performance boost, and you're like "So Facebook loads in 1.02 seconds instead of 1.03?". But that is missing the point by a mile. These improvements are about widening the realm of what's possible in a web app, not making existing web apps faster.

the stubborn insistence upon sticking with Gecko

As opposed to what? Webkit? It would be a shame if suddenly one of the three major rendering engines vanished. I'd much rather they stick with Gecko than toss in their hat. Firefox doesn't have to match Safari or Chrome in everything - they're offering a different browser, and that is good for all of us. Gecko is better in some areas, worse in others, and just plain different in others yet. Mozilla makes huge contributions to the HTML spec, largely because they have their own rendering engine, and therefore are actually implementing HTML. They would have very little to say or contribute if all they were doing was creating the browser chrome.

To be honest, your entire post is offensive. "At this point, Mozilla aren't solving any problems with their browser. What's the motivation behind Firefox?" You should try reading Mozilla's mission statement: http://www.mozilla.org/about/mission.html It's a pretty good mission statement, in my opinion, and it answers your question. "Why is it so bloated, and why are any of its developers okay with that fact?" sounds like something you conjured up for yourself - a question that has no relation to the reality of the browser or its developers.

That would hurt users.

Sorry. You're right, I replied to the wrong comment. :(

Jesus. No one can read analogies. Let me break it down:

"__A__ is like __B__ (<-- unclear, leaves the listener waiting for more). __Explanation__."

Did you ever hear a joke beginning with, "I like my women like I like my coffee..." ?

The first sentence of the analogy was just a lead-in. The second sentence, "It will only work as long as the smart kid sticks around." explained it. I can't believe I'm typing this.