×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

JavaScript Cookbook

samzenpus posted more than 3 years ago | from the read-all-about-it dept.

Book Reviews 64

r3lody writes "I have enjoyed other cookbooks in the O'Reilly library of computer texts, so when I saw JavaScript Cookbook by Shelley Powers in the catalog, I jumped at it. The description mentioned that the book would cover HTML5 and ECMAScript 5, so I really wanted to learn the new capabilities of both. I did get to learn a lot, but I wonder if these new features are too new." Keep reading for the rest of Ray's review.Like other cookbooks in the O'Reilly library, this one is organized as a series of specific problems, with their solutions neatly presented and grouped into the major chapters. Each solution has a discussion to flesh out the details. The website has downloadable copies of the examples in the book, which I used to test out the various recipes. ECMAScript 5 is fairly new, and HTML5 is still under development, so I made sure I had the latest stable versions of the major browsers (Firefox, Google Chrome, Internet Explorer, Opera, and Safari) to see how they would cope. The HTML5 features are very sparsely supported as of yet, so those portions of the book should be considered more of a sampling of things to come rather than a definitive set of solutions.

The first five chapters of the book are somewhat unremarkable. They start out easily enough with recipes for handling JavaScript strings. The discussion of String objects and literals obviously implies that the reader is already somewhat familiar with Object terminology and functionality. That makes this book unsuitable for beginners. The following chapter contains recipes for handling regular expressions. It starts off with an introduction to the basics, which are nothing that a somewhat savvy shell programmer should be familiar with. The remaining sections cover pretty basic problems. The only interesting ones I noted handled highlighted found phrases on a web page.

Chapter 3 covers dates, time, and timers. Handling dates is shown to be pretty straightforward, and one-shot and recurring timers are presented in a clear, easy-to-understand manner to wrap up the chapter. The next chapter, Working with Number and Math, consists mostly of basic mathematical solutions. The fifth chapter rounds up the basics with recipes for working with arrays and loops. As a Perl programmer, I found this to be familiar territory – especially the discussions of the splice and map method, and using associative arrays.

Chapters 6-10 provide the first real appetizing recipes in the JavaScript Cookbook. Shelley first discusses building reusability using function definitions, anonymous functions, recursion, scopes and memorization. It's starting with this chapter that you really begin to learn how to use JavaScript rather than just playing around with it.

Event Handling is the first major hurdle a procedural programmer needs to overcome to use JavaScript effectively. Various event triggers are discussed in the sections of chapter 7. While most of the code is easy to comprehend, I ran into problems when using the new HTML5 drag and drop was discussed. I had to ask myself could drag-and-drop be any more complicated? This example worked on all but Opera, but the solution is convoluted. Overall, if you really want to know how screwed up code must be to work in all different browsers, chapter 7 (Handling Events) will demonstrate it. Internet Explorer's differences is the reason for most of the odd workarounds in this chapter.

We would all like each browser to work just like another but, unfortunately, each one has its own quirks. Chapter 8 talks about the various ways browsers handle color support and page sizes. The chapter ends by dealing with dynamic pages and bookmarking their state.

The first time I worked with JavaScript was when I was coding some form handling. Chapter 9 covers the ways to handle forms and modify web pages. The most useful recipes (at least, for me) were the last two, which showed how to hide and display form elements on the fly, and how to modify selection lists based on other form element entries.

All programming involves error handling and usually some debugging. Chapter 10 describes the various ways to handle errors, followed by a well-written set of tips on how to use the debuggers and inspectors for the major browsers.

The following three chapters all deal with manipulating web pages. The first of these contained a lot of discussion of namespaces. Namespaces can be confusing, and I didn't really understand them much better after I was finished reading. In addition, you are presented with several boilerplate templates, with little information as to why you would use them. I also had problems with some of the downloaded samples not running correctly on my browsers. Chapter 12 contains lots of fun ways to manipulate page content, with specific instructions on how to handle IE and its different ways of doing things. Finally, chapter 13 provided some good basics of page manipulation, including creating collapsible sections, and creating tab pages.

Accessibility is the major topic of chapter 14, where you are introduced to ARIA (Accessible Rich Internet Applications). Many web pages are not built with accessibility in mind, so this chapter is very important for giving the web designer the tools for well-designed and usable pages. Some ARIA techniques are straightforward, but others (such as creating collapsible form sections) are much more complex to get right. This chapter does a marvelous job, even though it is somewhat hard to read.

The next chapter covers creating media-rich and interactive applications. This chapter was pretty deep, and the examples were not necessarily bad, but the techniques required need the coder to really think clearly about how to accomplish their goal.

Chapters 16 and 17 cover JavaScript Objects and Libraries. In the Objects chapter, there is quite a bit of discussion around ECMAScript 5, which is not yet well supported in the browsers normally available. As one example, Shelley does say regarding the preventExtensions feature "by the time this book hits the streets, I expect (hope) at least a couple of browsers will have implemented this feature". The Libraries chapter was more problematic in that I was not able to follow along and get the supplied samples working correctly. In addition, the coverage of jQuery was only a high-level overview, leaving the reader wanting more. In her defense, Shelley acknowledges the breadth of the jQuery topic and refers you to the jQuery Cookbook for more information. Overall, I found chapter 17 unsatisfying and abrupt in its coverage.

Communication via Ajax is the main topic for the recipes of chapter 18. Without a proper web server at my disposal, I could not properly evaluate the workability of the solutions. I was also somewhat amused that one of the solutions was described with the caveat that it's not a recommended procedure. I would ask why it was included in that case.

The Working with Structured Data chapter starts by covering JSON (JavaScript Object Notation), but then adds in recipes for handling hCalendar Microformat Annotations and RDFa. The transition was a little jarring, and not overly useful, in my opinion.

The penultimate chapter covered the issues around persistent information. While using URLs and cookies to maintain some state are discussed, much of this chapter revolves around new capabilities made available in the new HTML5 specifications. Unfortunately, most browsers either do not support, or only partially support these features, so the information is only useful as a "taste of things to come".

The final chapter covers the use of JavaScript in non-browser environments. Widgets and gadgets are simple JavaScript applications that are easily coded and disseminated. There are discussions of creating applications for the iPhone, Android phones, and Blackberry phones.

As I step back and reflect on this book, I think that many topics are solutions that cannot be implemented because the typically available browsers don't support the new features yet. If a web page designer wants their site to be available to users now, they need to focus on the features that are well entrenched across the internet. Having so many solutions based on features and capabilities that are still being defined is only useful as academic exercises. I would have preferred that the JavaScript Cookbook be more useful for the state of the web right now. That is why I'm rating it only 7 out of 10.

You can purchase JavaScript Cookbook from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

64 comments

first post (-1, Offtopic)

Anonymous Coward | more than 3 years ago | (#33737536)

first post

penultimate post (-1)

Anonymous Coward | more than 3 years ago | (#33737692)

penultimate post

next to last chapter (0)

yagu (721525) | more than 3 years ago | (#33737578)

lost me at "penultimate"

Re:next to last chapter (-1)

Anonymous Coward | more than 3 years ago | (#33737730)

Sounds too much like "penismate"?

Re:next to last chapter (-1, Flamebait)

Anonymous Coward | more than 3 years ago | (#33737804)

Will you be my penismate? I heard your penis is only 3 inches fully erect which is just what I like.

Re:next to last chapter (-1)

Anonymous Coward | more than 3 years ago | (#33737950)

So, practically at the end of the review, then.

Re:next to last chapter (1)

tehcyder (746570) | more than 3 years ago | (#33744732)

This is a site for people with an adult reading age. If English is not your first language, you should be prepared to learn words which are part of a reasonably educated person's vocabulary.

js is a good language (0)

Anonymous Coward | more than 3 years ago | (#33737708)

that gets a bad rap for no good reason.

however, if you are doing DOM manipulation and not using a framework like jQuery then you are an idiot.

Re:js is a good language (0)

Anonymous Coward | more than 3 years ago | (#33738028)

oh, there are good reasons. All numbers are floating point. some of the array indexing rules are nuts (also related to numbers being floats). Some people complain about + string concatenation, but they're retards. And the DOM/IE, but that's not a javascript problem. I think javascript is an awesome language with some warts (see earlier reference to floats).

Re:js is a good language (2, Informative)

tomhudson (43916) | more than 3 years ago | (#33740334)

Why should I use jQuery when I'm comfortable writing the code myself? Really? It doesn't give me anything I need that I don't already have. Maybe if you're new to javascript, sure, but many of us write our own that do what we need, as we need it.

Re:js is a good language (1)

fforw (116415) | more than 3 years ago | (#33748446)

Why use any abstraction at all? you can just arrange some logic gates in the right configuration after all.. Do you enjoy writing boring DOM traversal routines? Why should Javascript be exempted from avoiding the not-invented-here syndrome?

Expecting the wrong thing (5, Insightful)

BadAnalogyGuy (945258) | more than 3 years ago | (#33737790)

A cookbook isn't designed to teach you anything. You don't learn how to boil water or heat up a pan when you buy a cookbook. It isn't a textbook or beginner's manual.

A cookbook provides recipes. It may provide some background and hints on how to adapt recipes to fit your needs, but it is not there to discuss why something works, only the steps to make it work.

So if you were disappointed that the first five chapters were about mundane things like string manipulation, then you've sorely missed the point. These are problems that exist and the book presents the best solutions to solve them. If you think string manipulation is unnecessary to expound upon, then skip those chapters. There's no rule that you have to read a cookbook all the way through.

A cookbook can only be judged on two things. Thoroughsity and correctness. If a cookbook is sufficiently thorough in its coverage of the topic and the recipes it provides are better than adequate, it has done its job. Judging it on standards best reserved for textbooks is ridiculous since the domain is completely different.

Re:Expecting the wrong thing (0)

Anonymous Coward | more than 3 years ago | (#33737872)

Thoroughness. I believe the word you are looking for is thoroughness.

Re:Expecting the wrong thing (1)

seyyah (986027) | more than 3 years ago | (#33738812)

A cookbook can only be judged on two things. Thoroughsity and correctness. If a cookbook is sufficiently thorough in its coverage of the topic and the recipes it provides are better than adequate, it has done its job. Judging it on standards best reserved for textbooks is ridiculous since the domain is completely different.

A dictionary may be judged on two things. Thoroughsity and correctness. If a dictionary is sufficiently thorough in its coverage of the topic and the definitions it provides are better than adequate, it has done its job. Judging it on standards of the words used in this sentence is ridiculous since the domain is completely different.

Re:Expecting the wrong thing (0)

Anonymous Coward | more than 3 years ago | (#33739650)

Thoroughsity is a perfectly cromulent word.

Re:Expecting the wrong thing (1)

tehcyder (746570) | more than 3 years ago | (#33744744)

A cookbook can only be judged on two things. Thoroughsity and correctness.

How can you judge something by a non-existent criterion?

lost me (0)

Anonymous Coward | more than 3 years ago | (#33738008)

lost me at cookbook

You should be kissing the author's feet (3, Insightful)

c0d3g33k (102699) | more than 3 years ago | (#33738040)

As I step back and reflect on this book, I think that many topics are solutions that cannot be implemented because the typically available browsers don't support the new features yet.

Most technical books are partially obsolete before they see print, or rapidly become obsolete. You're complaining because the book might have a longer shelf-life, thus giving a better return-on-investment and greater longevity and usefullness? Take a step back and think. Really.

Re:You should be kissing the author's feet (3, Interesting)

Yvan256 (722131) | more than 3 years ago | (#33738866)

Except that sometimes the new features take another turn and then the book becomes useless.

Look at HTML5 file uploads via XHR2... Firefox went one way, Chrome/Safari went another way. From what I understand Firefox won't be the new standard, but that method could be what is described in the book. I won't help you once Opera supports the Chrome/Safari way and once Firefox switches to that new method.

For YACC - Yet another crap cookbook? (1)

tomhudson (43916) | more than 3 years ago | (#33740120)

Chapter 9 covers the ways to handle forms and modify web pages. The most useful recipes (at least, for me) were the last two, which showed how to hide and display form elements on the fly, and how to modify selection lists based on other form element entries.

If it takes you half the book just to get there, this isn't a cook-book unless it's a "For Dummies."

The C++ Cookbook was equally disappointing. I'm sorry I bought it.

In fact, the ONLY good cookbook was the Perl one.

This book is a dumb idea, when half the stuff written in it can't be used. It's a "let's put out a book out to cover this and hopefully people will bite" rather than "this topic demands coverage - let's get a book out."

Re:For YACC - Yet another crap cookbook? (1)

Sancho (17056) | more than 3 years ago | (#33742436)

I was angry that my cookbook took 7 chapters to get to chicken florentine. What good is that!?

Re:You should be kissing the author's feet (1)

r3lody (800999) | more than 3 years ago | (#33745820)

Yvan256 gave the exact answer I had. Writing a cookbook for solutions using technologies that are not fully-baked and agreed-upon is risking delivering answers that may not work when the real world catches up. I much prefer having solutions that can be implemented now, rather than waiting for years for the various browsers to support the technologies. After all, how many copies of IE6 and IE7 are still operational across the web, compared to how long IE8 has been available (and now IE9)? Writing about these techniques now only creates a vision of a tantalizing future that may be years off (in which case this book will probably be in a new edition) or may never come-to-be as envisioned.

Why pure JS vs a Library? (3, Insightful)

psyclone (187154) | more than 3 years ago | (#33738204)

What I wanted to learn from this review is, why should I do anything in pure JavaScript instead of using a JS library like jQuery? What are some recipes that are simpler in this cookbook than finding a jQuery example on StackOverflow?

I suppose built-in data structures, looping, and math is independent of a library, but why would you ever do form manipulation, DOM manipulation, or ajax without using jQuery (or your favorite js lib)?

Re:Why pure JS vs a Library? (1)

bsDaemon (87307) | more than 3 years ago | (#33738450)

Maybe you don't have a favorite library. Maybe you have an idea for a new library, but because you've only ever used other people's libraries, you're not quite up to speed on how to do things the "pure" way. The people who write the libraries had to start somewhere, and its often times at the bottom.

Re:Why pure JS vs a Library? (1)

marsu_k (701360) | more than 3 years ago | (#33738718)

I wrote a Javascript library to be used internally with our almost-but-not-entirely-unlike CMS - I could have used jQuery (which I use a lot, and really like), but there were two reasons why I didn't. First, Javascript is sadly a very misunderstood language, also by most of our technical staff - while jQuery is very powerful, the syntax is a bit terse (not a bad thing in itself, but might take some time getting used to), and it's very extensive even with no plugins. It was simpler for the others to adapt to a library with a more limited feature set and a more procedural approach. Secondly, and this was the main reason, I wanted to learn the language better. And it certainly was a learning experience, the differences in DOM implementations can be really infuriating. But in the end, it was certainly worth it, and in my opinion it made me much better in Javascript than I would have been should I just have used jQuery.

Having said that though, I'm not certain that cookbook-style books are good for learning Javascript, nor any language for that matter, if one wishes to do more than simply cut'n'paste ready bits of code. For Javascript I personally recommend this book [oreilly.com].

Re:Why pure JS vs a Library? (0)

Anonymous Coward | more than 3 years ago | (#33739062)

you created a non-standard library as a business project for use by colleagues when jQuery would have been fine because you "wanted to learn the language better"? Hope whoever you are working for knows they're paying you to actively compromise the maintainability of their codebase

Re:Why pure JS vs a Library? (1)

marsu_k (701360) | more than 3 years ago | (#33739250)

No, as stated it was also because the limited feature set makes it easier for my colleagues to adapt. And seriously, you should see the codebase (or not)... when it comes to maintainability, I'm the last person to blame.

Re:Why pure JS vs a Library? (0)

Anonymous Coward | more than 3 years ago | (#33740870)

ok snark withdrawn, my point is just that someone saying the "main reason" they did something in a business application context was to learn is a glaring red light. That's what hacking and OSS are for. Also, "easier" is pretty subject, maybe its easier when you're there to provide context, but after you're gone and code drift has set in are you so sure your way is SO much better that someone learning to do it your way the first time is going to find it easier than using a common library with which they've probably already done a similar thing?

Re:Why pure JS vs a Library? (1)

capndan (1911882) | more than 3 years ago | (#33739656)

Any reason not to read the Sixth edition instead of the fifth (the one you linked to)?

Re:Why pure JS vs a Library? (1)

marsu_k (701360) | more than 3 years ago | (#33739800)

No, the fifth edition was just higher in Google (for some reason, the fourth is even higher) and I simply needed a link.

Re:Why pure JS vs a Library? (1, Informative)

Anonymous Coward | more than 3 years ago | (#33738966)

Because javascript libraries have become monstrous beasts loaded down with lots of bloat, and unlike dynamic libraries on the local system there is a performance penalty for loading the parts of the library that you don't need. If you only need 5% of what a library does, it's better to rewrite that 5% than to have to constantly ship around and load that other 95%.

Re:Why pure JS vs a Library? (1)

psyclone (187154) | more than 3 years ago | (#33739392)

Some libraries are monstrous and require loading the full (even if compressed) feature set.

However, MooTools is highly modularized. It lets you pick and choose [mootools.net] which parts of the total library you need. Many MooTools Add-ons [uvumitools.com] will explicitly list the sections of the library needed.

If you feel it is better to re-write parts of a library, then either choose another or contribute your superior code back to the community.

Re:Why pure JS vs a Library? (1)

Bigbutt (65939) | more than 3 years ago | (#33739474)

You want to work in the "metal" for the simple reason that you learn more about how and why things work. Once you have a reasonable understanding of how stuff works, you can look at libraries with the appropriate background to understand which will satisfy the problem you're trying to solve. You can then properly use the library and won't piss and moan when the library doesn't do things the way you expect them to because of an incorrect expectation.

[John]

Re:Why pure JS vs a Library? (1)

Junior J. Junior III (192702) | more than 3 years ago | (#33740260)

Say you wanted to author a js library... you might find pure js handy.

Now whether there's any good reason to write yet another js library, is another thing.

Re:Why pure JS vs a Library? (1)

BigDXLT (1218924) | more than 3 years ago | (#33743064)

Boy, where's Pizza analogy guy when you need him?

(Homemade Pizza vs. frozen deliscio crap)

From TFB: (1)

obender (546976) | more than 3 years ago | (#33738518)

Problem 1.11 (last one in the String chapter):

Left- or Right-Pad a String

Solution:

for (var i = 0; i < diff; i++) {
oldStr=filler + oldStr;
}

For who is written this solution? Loops are as basic as you can go in programming.

Re:From TFB: (1)

tsalmark (1265778) | more than 3 years ago | (#33738762)

The solution is not teaching loops, but showing a (perhaps rather obvious) best practices solution for string padding.

Re:From TFB: (2, Insightful)

tomhudson (43916) | more than 3 years ago | (#33740244)

That's not a "best practices" approach. Strings in javascript are immutable [wikipedia.org]. Every time you add a padding character, you create a new object, point the symbol to the new one, and delete the old.

A more optimal solution is to create an 80-character string, and append a substring of that to the original string.

Whoever wrote this book has no clue as to how javascript works.

Re:From TFB: (1)

tehniobium (1042240) | more than 3 years ago | (#33738802)

Wow, that's really beginners material! But really, if javascript isn't your first language, then you shouldn't try to learn it from a book, as most of what you see will be reduntant information.

I remember learning javascript and html from a book about 10 years ago...the html book told me to use tables for layout, which I soon thereafter found out was stupid, and the javascript book was full of stuff that is "bad practice" - for example lines where NOT ended with a semicolon.

BTW, does previewing of /. comments take 5-10 seconds for everybody?

With Google (1)

Bigbutt (65939) | more than 3 years ago | (#33739500)

...why is a cookbook needed? I do various types of programming (currently with PHP and JavaScript manipulating a MySQL backend) and when I'm stuck on something I want to do, I just bring up Google and search for an answer. So far I have yet to be disappointed.

[John]

JavaScript is ok, DOM is a train wreck (1)

BeforeCoffee (519489) | more than 3 years ago | (#33739862)

I've found the JavaScript language implementations on most browsers to be generally competent and compatible with each other, differing only in memory use and execution speed. The DOM and its flavors and the way the browsers differ or are bugged is the real pain. The DOM is what makes the browser a poor application delivery platform. This is why JQuery is such an important innovation. Of course the DOM is a data structure that should be queried and whose result sets are then manipulated. It just makes so much sense, and that model has enabled me to suffer the travails of cross-browser compatibility. Here is what I suggest to anyone who is thinking of starting any sort of serious application development in JavaScript on the browser:
  • Do your day to day development using tools like Firefox/Firebug. But, if you're planning to support IE, test your code with IE6 every day.
  • Develop a convention you are comfortable with to create JavaScript classes (prototypes) that works reliably on the browsers you want to target. Learn how inheritance works so you can use it if you need it.
  • Learn how to scope your symbols, that local or private functions can be namespaced away in anonymous functions. Decide up front if you can get away with global variables or not in your application, and if not, get used to passing context objects to all static functions and constructors.
  • Discover and rigorously adopt a subset of the JavaScript language that works on all of the browsers you want to target.
  • Watch presentations on how to make your javascript more performant and easier to compress.
  • Pick a JavaScript library and focus your development around it. Try not to mix and match JavaScript libraries in your app that could run at cross purposes. JQuery is my favorite that I've found so far.
    • Your typical experience with the library should be that you write code that runs good in one browser and with little or no changes, it runs on the other browsers.
    • When the opposite occurs, there should be a reasonable workaround that leverages features of the library. The library should have masking browser incompatibilities as a primary concern (because that's where the cost lies, duh!)
    • Addons or plugins should be available to extend the functionality of the library.
  • Write really generic, clean, and compatible CSS and avoid the painful IE hacks as much as you can - instead, have no shame and use your JS library to patch up the DOM and behaviors on IE onLoad.
  • Browser feature detection libraries (like Modernizr) are really helpful in gracefully degrading your user experience when lesser browsers are missing a new, but non-critical feature.
  • "Build" your JavaScript files into some single deployable javascript file. Look into javascript compressors/packers, and gzipping your javascript before its transferred.

Re:JavaScript is ok, DOM is a train wreck (2, Insightful)

tomhudson (43916) | more than 3 years ago | (#33740282)

test your code with IE6 every day.

Why? Let them upgrade. Or let them pay 3x the price for IE6 support (because it's a minimum of 2x, and that's if you can still find a machine that has IE6 to test on that you can boot).

"oh, but business ..." Don't give me that business. Either they pay the price, or they don't get. IE6 support is a messy business, and doesn't give enough returns for the work.

Re:JavaScript is ok, DOM is a train wreck (1)

BeforeCoffee (519489) | more than 3 years ago | (#33740910)

Oh I knew that statement was going to be controversial. Yes, IE is a huge source of pain, but for goodness sakes, butch up! Don't be so whiny and/or smug: usually we do not get a choice about what we must support, and often it is only IE that we must support. Are you doing something custom, and you wanna make a political statement and not support IE? Knock yourself out.

I am myself a huge critic of Microsoft, and I relish in the fact that the market demanded they support the Canvas tag in IE9, for instance. But, I'm not a zealot, and it currently makes a lot of sense to support IE.

And, regarding my assertion about supporting IE6 vs later IE's... Clearly, some issues like security/stability will not be addressed since that browser is EOL. But from a presentational and computational standpoint, you can get IE6 to do most everything IE7 and IE8 can do. In my opinion, if you can show support for IE6, you automatically get support for IE8 - so you might as well take your medicine and support it all and be available to the largest possible market.

Re:JavaScript is ok, DOM is a train wreck (2, Insightful)

tomhudson (43916) | more than 3 years ago | (#33741556)

Every shop I've interviewed at will charge at least double if the customer wants IE6 support, for the simple reason that it involves a LOT of breaking things to make them work. Your argument could have been made about Netscape 4, or even IE3 in Windows for Workgroups. It's not valid.

Businesses had plenty of warning about lock-in. Let them feel the pain. It's the only way they'll correct their behaviour.

IE6 has a very small market - business and government that are stuck not being able to update because of custom apps. Let them install a second browser. It's not like you can't run IE and Firefox/Seamonkey/Opera/Safari at the same time.

Re:JavaScript is ok, DOM is a train wreck (1)

BeforeCoffee (519489) | more than 3 years ago | (#33743882)

A few seconds of googling shows you are uninformed:

http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2 [hitslink.com]

IE6 is browser #3 in total market share with 16% share. IE8 is first with 28% followed by Firefox 3.6 with 16.8%.

You can't make the same argument about Netscape Navigator because its numbers are 1%.

I'll change my tune when IE6 finally drops off in usage, but that's only when XP finally falls out of widespread use, which will be in, what ... 3-5 more years?

Re:JavaScript is ok, DOM is a train wreck (1)

tomhudson (43916) | more than 3 years ago | (#33745836)

That 16% is mostly corporate and governmental users - and you can be sure that their home boxes are more up-to-date. Those are the ones that mostly can't even upgrade XP to the latest service pack because they're locked in to IE6.

Unless you're the one who locked them in in the first place, you're not selling to them anyway, so who cares?

Re:JavaScript is ok, DOM is a train wreck (1)

BeforeCoffee (519489) | more than 3 years ago | (#33749380)

OH! Sounds like you have sixteen percent of the entire online world figured out. I sure am glad you don't run things.

I went to XML Sucks, and surprise surprise: I disagree with practically everything you have written. I disagree generally with your negative attitude.

Re:JavaScript is ok, DOM is a train wreck (1)

tomhudson (43916) | more than 3 years ago | (#33751832)

Actually, my attitude is not negative. I believe that there are solutions that will both increase interoperability and reduce the labour and energy required to actually process and exchange information.

And yes, that 16% figure being mostly corporate and government sites that cant/won't upgrade from IE6 is pretty much the entire IE6 install base.

Re:JavaScript is ok, DOM is a train wreck (1)

BeforeCoffee (519489) | more than 3 years ago | (#33756390)

Yes you are a negative guy! "xml sucks"? Canadian email address? Pat answers? Negativo!! A heck of a lot of poor folks get internet connectivity from public libraries running IE6, you would deny them our collective experience! Neg-a-tive.

Re:JavaScript is ok, DOM is a train wreck (1)

tomhudson (43916) | more than 3 years ago | (#33757366)

Let the libraries install Firefox or Opera or Safari (they could even switch to Macs).

It's not like a library with public computers needs to have ONLY IE6 on it. Next you'll be saying that they should have ONLY one book one each topic!

Re:JavaScript is ok, DOM is a train wreck (1)

BeforeCoffee (519489) | more than 3 years ago | (#33761336)

That's not how the world works, and that's definitely not how public organizations work. You talk as if public institutions are hyper-competent and on the ball or something.

Sometimes the just and right thing to do is also the uncomfortable thing. You don't get to just spy an inequity and say, "it shouldn't be that way!" and then break your arm patting yourself on the back because your work is done here.

If you can actually EFFECT positive change in public libraries, then I would salute you, because foisting IE6 on poor people is such an injustice when, as you say, there are such superior free alternatives! But I suppose that you nor I can effect change, and so we land at the painful reality: justice is not served until the IE6 compatibility battle is won. And quite honestly, that's a modest battle if you consider that IE7 and IE8 are nearly as flawed animals. IE9 is going to be the first passable browser that MS releases.

Finally, IMO, starting any statement off with "let ..." or "let them ..." is elitist because it assumes far too much.

Re:JavaScript is ok, DOM is a train wreck (1)

tomhudson (43916) | more than 3 years ago | (#33761526)

It's not elitist to demand that they fulfill their mandate to serve the public properly.

Re:JavaScript is ok, DOM is a train wreck (1)

BeforeCoffee (519489) | more than 3 years ago | (#33767504)

That's true.

Re:JavaScript is ok, DOM is a train wreck (1)

tomhudson (43916) | more than 3 years ago | (#33770136)

So what can we do?

I don't know about you, but I've still got a couple hundred blank dvds hanging around (dvds are so last decade :-) - if I became aware of a problem in my area (library or school), I'd be happy to make a bunch of bootable browser-centric dvds.

And libraries *are* supposed to be where people learn things.

And working off of read-only media reduces maintenance, saves money, etc. For personal data storage, pretty much anyone can afford a $5 for a one gig thumb drive, or $7 for 4 gigs, or the library can lend them out, same as books, and let people grab stuff from their local mirror of Project Gutenberg. It's a cheaper way to increase the amount of reading material available than buying new books, and returns are easy - just erase the files. No need to return the books to their proper places in the stacks.

This way, anyone who can afford a netbook, or inherits a lower-end pc (hey, you can find p4s in the dumpster nowaydays) but not the ongoing costs of connectivity still has options.

Re:JavaScript is ok, DOM is a train wreck (1)

BeforeCoffee (519489) | more than 3 years ago | (#33773216)

So what can we do?

In my opinion, there is not much we can do, short of running for office ourselves and making it a platform item that we are . This exchange has prompted me to send an email to my local library administrators, and I will probably make a follow-up phone call or two just to register my feelings. Honestly, I don't believe there will be any change in the system here until there absolutely must be change.

You tell me why I should expect anything different when we pay disinterested people to do uninteresting work and there's no consequences for bad behavior or bad performance because there are entrenched interests guarded and fostered by unions whose only mission is to get more gifts for their members ... you tell me, why should I expect anything good to come out of the dumb public system we have setup for ourselves?

I tell you, the only answer is systems run and funded by unpaid volunteers, because state-run [anything] is always just the worst. :(

Eclipse Javascript Engine? (1)

Doc Ruby (173196) | more than 3 years ago | (#33739916)

Is there a good Eclipse IDE plugin that embeds a JavaScript engine in a console? I don't want to develop JavaScript projects with Eclipse (though that's a useful extra); what I want is to use JavaScript as a scripting language to call the Eclipse API, and to do something like what jrunscript does: use JavaScript to call the JDK API and anything else I specify in the classpath. If that's useful, then managing JavaScript projects in the Eclipse IDE would be handy as I'd be creating lots of JavaScripts.

jQuery is your friend. (1)

dannydawg5 (910769) | more than 3 years ago | (#33741000)

I used to hate writing JavaScript until I found jQuery. What used to take me writing a lengthy mess plus patching it with cross-browser hacks has now become elegant one-liners thanks to the wonderful jQuery libraries. I recommend everybody that writes JavaScript take a look at it.

Re:jQuery is your friend. (2, Insightful)

psyclone (187154) | more than 3 years ago | (#33741696)

Absolutely. If you need a cookbook of recipes to copy/paste to solve some JavaScript problems, research jQuery instead.

inaccessible accessibility (1)

ferret4 (459105) | more than 3 years ago | (#33741686)

How ironic that "Accessibility is the major topic of chapter 14" and "it is somewhat hard to read".

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...