Browser elitism benefits no one. The user is left insulted, and the developer strokes their own ego.
129 karma · joined March 5, 2012
I disagree. The onus is on those peddling the product (i.e. marketers) to sell its worth to users.
> Believe me when I say that I understand the frustrations that come from having to support outdated browsers
I read about “frustration” when referring to older browsers a lot. That has led me to question just how much people learn about supporting those browsers. Shouldn't supporting browser X become trivial once a certain amount of experience is accrued? Or do we just hunt and peck until a page ostensibly works?
> There isn't enough information in the original post to determine if the last one (auto-update occurring despite being turned off) is what happened here - I'd like to learn more. It would be worrying (and I'd argue an insecure design) if the software were even capable of self-updating with that setting turned off.
As someone who tests every whole number version of Firefox (1-14), I have experience with the force-fed updates. Imagine my frustration when viewing the version information (via Help > About) led to the browser paving over my existing installation. I really don't want to have to tinker with the settings for fourteen separate programs.
Conversely, Opera 8+ will ask before updating. Though this happens every time I open the program, I can easily decline and continue with my business. This is how to respect users.
Chrome is far worse, as it forbids the existence of an older build, even after the newer build is uninstalled.
Your browser is your choice, and we as developers need to respect that.
This sniffing in particular will fail for Opera 6-8, therefore excluding perfectly capable browsers by a very shallow criterion.
The sniff serves no purpose, and is furthermore based upon a thoroughly disproved anti-pattern.
I've found that collecting the Text nodes and returning them in an Array is preferable. All it requires is some simple traversal. The developer (that should know what text goes where) can then map text to nodes.
I don't. I use descriptive names for functions and short, concise words for variables (sometimes clear abbreviations).
> Another nit, Google Style guides disallow formatting for readability except for comments?!?!
> Allowed
> [regularly formatted variable declarations]
> Not allowed
> ["pretty" formatted variable declarations with indentation]
Code Complete 2 explicitly discourages the latter style, and I tend to agree. It's too difficult to maintain.
I stick to 72 columns for width and 20 lines per function body. The result has been very concise code that's easy to follow. Only exceptional cases such as heavy recursion have eluded the line limit.
If popular JavaScript projects wrote code with cleanliness in mind, maybe more people would take the language seriously.
Nonetheless, we're probably both guilty of selection bias.
Yep.
The client-side environment is far too unstable to build a "native app". There's a reason why monumental frameworks like ExtJS barely work in IE 9.
David Mark's My Library[0] is the best DOM library available by a wide margin. It has supreme browser support, and it's "modular" with a custom builder. The code is so solid that many people have borrowed from it, including the jQuery project and myself.
I've also created a DOM library, but with a more limited feature set (it's only a few months old). See my submissions for details.
jQuery is a very invasive API. Its goal is to steal all the work from the developer, and to "guarantee" what it deems to be "correct" input for a certain subset of browsers. This approach may ostensibly work, but inevitably falls apart, which leads to thousands of "bugs" being reported.
Because the API has grown to be so massive, goalposts "must" be moved in order to create a lighter API. Once again, this is because of a design flaw. Goalposts will continue to be moved in cyclical fashion unless an alternative design is used. Fellow developers may denigrate me for it, but I will explain how this problem can be avoided.
An API that tries to cater to everyone cannot and will not succeed. This is evidenced by the upcoming "fork". Conversely, an API that provides a set of tools to developers without catering can work in many environments. The burden is then placed upon the developer to choose which environments matter. As has been outlined by mobile developers, object inferences for IE 6 really are unnecessary for mobile Webkit environments. I have written here on this concept before, mostly on the topic of "graceful degradation". Browser specificity can and will kill a client-side API.
Furthermore, the following snippets are simply false:
> But Internet Explorer is the black sheep of the browser world. If your tests fail in just one browser, well, you get the picture.
Funny how older versions of browsers such as Opera are never mentioned. IE versions 6-8 seem to be the only "old" browsers that exist. Which of course is because they're still in use. Myopia reigns supreme.
I've often found that IE versions 4-9 will point out errors I've made in my code, as the IE platform is far more strict than browsers such as Firefox, which scramble to protect bad code.
> Accordingly, automating testing in Internet Explorer is much more involved than any other browser.
As someone that tests in 20+ browsers, I spend a lot more time on Firefox versions 1-13 than I do with IE versions 4-9, especially with scripting. Nevermind Google Chrome, which makes testing incremental versions nearly impossible (and no, auto-upgrades are no guarantee).
> Getting automatic cross-browser JavaScript testing working is a complex affair, and bound to involve some amount of trial and error.
Conclusion: test manually. There are no guarantees.
I'll try to field every response.
Try loading a page without script bloat and you'll see a noticeable difference.
The C vs. Assembly argument is such a silly non-point; apples and artichokes.
I am interested, though, that the team has finally noticed that optional code should be the norm. Resig himself has been quoted as wanting nothing to do with it[0].
However, omitting every single "module" only truncates 2484 lines, which leaves the 1.8.1b source at a staggering 6763 lines of code. There is still a great deal of work to be done before "modular" is a fair term to apply to the API.
We have a winner. Want browsers to play nice? Write good code.
That's an indictment on Twitter's shoddy front-end code. The clean-up has already begun, but I don't know how much progress has been made at Twitter.
As was outlined earlier, reliance on scripting is going to bite an author inevitably.
Hypothetical: CDN X is having problems, and your scripts don't load. Errors pop up everywhere. Do you:
a) realize that scripting can and will fail for anyone, and tailor a page to work without it;
or
b) continue to plug your ears and point to statistics?
I have scripting enabled, but block Google Analytics and various advertising hosts. Do I count as someone to be supported? Or am I irrelevant because I'm a minute statistic?
And yet three separate libraries with DOM abstractions are required.
Why should I trust your opinion of the DOM if you require so much third-party code?
> Backbone UI depends on Backbone, Underscore, jQuery, and laconic.
That's a disaster waiting to happen.
I wanted GitHub to absorb most of the page hits since I'm only on shared hosting.
Graceful degradation is the proper description. In short, scripts can degrade by testing for the existence of a property (e.g. `Array.prototype.push`) and ignoring the property if it does not exist.
I'll be posting a large project here soon that should clarify the strategy. Stay tuned.
We really don't work hard enough because we decry the DOM and blame Microsoft for problems research can and will solve.
[0]: http://peter.michaux.ca/articles/feature-detection-state-of-...