"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.
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.
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.
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.
please at least get a versioning system that allows us to freeze our interface at a certain point
"at least"! Like all those other websites. Man, slashdot really screwed the pooch on this one, updating their website and not preserving the old version for us. That's what every website does except slashdot. I hate new things.
AAAAAAAAAAAAAAH!!!
Sorry, nevermind. I thought I saw something changing in the distance.
Cookies aren't obsolete because they're persistent within the browser despite a changing IP address. A login cookie on your laptop will still work when you bring it into the coffee shop. So will tracking cookies.
So let's compare this situation with the one that existed right before the WHATWG made this announcement. You write a website that is compatible across 99% of browsers. You were writing for HTML5 so you put !DOCTYPE html at the top. After the WHATWG's decision to remove versioning from HTML, you put... !DOCTYPE html at the top.
You write a website and then abandon it for several years. You were writing for HTML5 so you used what actually worked with browsers at the time. After HTML5 became HTML, you... used what actually worked with browsers at the time.
I'm having a hard time coming up with any differences. Can you describe them to me? Are you actually a web developer?
"Without version numbers you would really have no way to tell what you are doing anyways." Oh, crap! Suddenly I've lost all my knowledge of browsers and web development. I should quit my job and go eat worms.
"Next thing you know the browsers will go versionless too and then at that point all you can do is drink heavily." Well, I already drink heavily, but I don't depend on user agent sniffing to make my websites. I'd rather use feature detection. Surely you know what that is, since you're an expert on web standards.
Your "insightful" mod is insulting. Yes, if you write a website and don't attend to it for years, you look like a lazy moron. But that's probably not because browser advances broke your website. Why don't you try out some deprecated tags and see if they work. They do! They all do. If you abandon your website for years, you'll look like a lazy moron because you abandoned your website for years.
I'm still wishing browsers would be faster, and the difference between them is quite striking at times. It's not that noticeable when you're just browsing the web. But as a developer trying to make something interesting, the performance of browsers can limit your options. End users don't perceive much of a difference because the people who made the websites were forced to cater to the lowest common denominator. I run into this constantly. Sometimes it's the case that the code is poor and with optimizations, it becomes usable in all browsers. Other times it's just, "OK, we simply can't do this." It's really disappointing when that happens, even if the end users never hear about it.
I know you were just joking, but he said invisible, not hidden as in type="hidden". There are too many ways to make a form field invisible for a bot to deal with. It's actually a really good idea.
I know Google does that, but are there seriously any search engines that don't understand word stemming, still, at this point? Even I can write an application that understands word stemming because of all the FOSS out there.
Please answer your own questions. There needs to be some punishment, so what should it be? And please clarify what you mean by loss of privacy. Does it mean the doors were unlocked, or that the doors were unlocked and someone came in, or all of the above and plus the intruder used your private information to hurt you? Without answers for these questions, privacy invasion complaints seem meaningless. We need some way of quantifying the damage.
No you don't have to be on google.com. It loads google.com in the content area as soon as you start typing and your typing in the omnibar is reflected on the page. Pages loaded in this manner have a button in the upper left corner that, when you press it, takes away the page and shows you what was "underneath" - whatever you were viewing previously.
It does something else too, and given the general reaction here to Google Instant I think the slashdot crowd is going to HATE it. If the omnibox was going to autocomplete your typing into a full URL, as it does with URLs you've typed in the omnibox previously, it won't show you Google Instant results at all. It will simply load that URL.
I couldn't believe they included that behavior at first. After about 10 minutes of normal browsing I realized it worked incredibly well for me, given my normal browsing behavior. I will definitely make use of it when it's released in a more polished state. I forsee problems with this feature though for people who frequently visit sites that cause strain on their computers or have autoplaying video, modal alert boxes, etc.
Even despite that, it currently has some severe problems. Problem #1 is that google.com flags you as a robot and prevents you from doing further searches after using it for a while. Problem #2 is that it completely spams your history - every character you type is a separate entry in your history. I'm sure those issues will be resolved before the feature makes it into the stable or beta builds though.
Slashdot Mirror
Yes, the parent was exaggerating.
I'm blown away by how reasonable and thorough that response was. Thank you.
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.
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.
When Forrest Gump said, "Life is like a box of chocolates," I imagine you stormed out of the theater.
please at least get a versioning system that allows us to freeze our interface at a certain point
"at least"! Like all those other websites. Man, slashdot really screwed the pooch on this one, updating their website and not preserving the old version for us. That's what every website does except slashdot. I hate new things.
AAAAAAAAAAAAAAH!!!
Sorry, nevermind. I thought I saw something changing in the distance.
Cookies aren't obsolete because they're persistent within the browser despite a changing IP address. A login cookie on your laptop will still work when you bring it into the coffee shop. So will tracking cookies.
So let's compare this situation with the one that existed right before the WHATWG made this announcement. You write a website that is compatible across 99% of browsers. You were writing for HTML5 so you put !DOCTYPE html at the top. After the WHATWG's decision to remove versioning from HTML, you put... !DOCTYPE html at the top.
You write a website and then abandon it for several years. You were writing for HTML5 so you used what actually worked with browsers at the time. After HTML5 became HTML, you... used what actually worked with browsers at the time.
I'm having a hard time coming up with any differences. Can you describe them to me? Are you actually a web developer?
"Without version numbers you would really have no way to tell what you are doing anyways." Oh, crap! Suddenly I've lost all my knowledge of browsers and web development. I should quit my job and go eat worms.
"Next thing you know the browsers will go versionless too and then at that point all you can do is drink heavily." Well, I already drink heavily, but I don't depend on user agent sniffing to make my websites. I'd rather use feature detection. Surely you know what that is, since you're an expert on web standards.
Your "insightful" mod is insulting. Yes, if you write a website and don't attend to it for years, you look like a lazy moron. But that's probably not because browser advances broke your website. Why don't you try out some deprecated tags and see if they work. They do! They all do. If you abandon your website for years, you'll look like a lazy moron because you abandoned your website for years.
I'm still wishing browsers would be faster, and the difference between them is quite striking at times. It's not that noticeable when you're just browsing the web. But as a developer trying to make something interesting, the performance of browsers can limit your options. End users don't perceive much of a difference because the people who made the websites were forced to cater to the lowest common denominator. I run into this constantly. Sometimes it's the case that the code is poor and with optimizations, it becomes usable in all browsers. Other times it's just, "OK, we simply can't do this." It's really disappointing when that happens, even if the end users never hear about it.
Additional functionality often comes with the cost of a more complex UI. "Saving pixels" isn't anyone's goal; the goal is a better user experience.
I know you were just joking, but he said invisible, not hidden as in type="hidden". There are too many ways to make a form field invisible for a bot to deal with. It's actually a really good idea.
I know Google does that, but are there seriously any search engines that don't understand word stemming, still, at this point? Even I can write an application that understands word stemming because of all the FOSS out there.
Please answer your own questions. There needs to be some punishment, so what should it be? And please clarify what you mean by loss of privacy. Does it mean the doors were unlocked, or that the doors were unlocked and someone came in, or all of the above and plus the intruder used your private information to hurt you? Without answers for these questions, privacy invasion complaints seem meaningless. We need some way of quantifying the damage.
What about this MSI-installer for Chrome? http://www.google.com/chrome/eula.html?msi=true
No you don't have to be on google.com. It loads google.com in the content area as soon as you start typing and your typing in the omnibar is reflected on the page. Pages loaded in this manner have a button in the upper left corner that, when you press it, takes away the page and shows you what was "underneath" - whatever you were viewing previously.
It does something else too, and given the general reaction here to Google Instant I think the slashdot crowd is going to HATE it. If the omnibox was going to autocomplete your typing into a full URL, as it does with URLs you've typed in the omnibox previously, it won't show you Google Instant results at all. It will simply load that URL.
I couldn't believe they included that behavior at first. After about 10 minutes of normal browsing I realized it worked incredibly well for me, given my normal browsing behavior. I will definitely make use of it when it's released in a more polished state. I forsee problems with this feature though for people who frequently visit sites that cause strain on their computers or have autoplaying video, modal alert boxes, etc.
Even despite that, it currently has some severe problems. Problem #1 is that google.com flags you as a robot and prevents you from doing further searches after using it for a while. Problem #2 is that it completely spams your history - every character you type is a separate entry in your history. I'm sure those issues will be resolved before the feature makes it into the stable or beta builds though.