Asking for Help: Give Details!

There’s absolutely nothing more infuriating than someone not providing enough detail about a given issue. Before you approach anyone for help, provide any or all of the following pieces of information:

• What are you expecting to happen?
• What are you seeing happening?
• What are you seeing within the console? Any error messages firing?
• What browser, browser version, and OS are you using?
• What version of Moo / jQuery / or any external library are you using?
• What’s different between a working example and your test page?
• What have you tried to adjust to fix the issue?
• Is there a URL available so others can see the issue and debug it?
• Where else have you searched for an answer? Google? IRC? Forms? Documentation? MDN?

These pieces of information are absolutely invaluable to anyone you’d like to help you.

Asking for Help: Research First!

How often have you had someone ask you a question which the first search result of Google could tell you? Consistently asking others a question that Google can answer in the first result will brand you as an annoyance. The urgency with which you ask a question is relative to the urgency of the situation, but if you can take the time to do research yourself, do it and a lot of it.

Echo: Don’t Ask The Same Questions Twice

Asking the same questions repeatedly will make you invisible; i.e., no one will pay attention to your questions. One of the reasons I started this blog was to keep it as a reference for running into the same issues in the future. I’m not saying you need to start a blog, but I am saying that you need to find a method for archiving questions you’ve asked and answers to receive.

Giving Help: Be Patient

If every time you ask a question you act as though it’s a “code red” situation, you’ll again find yourself to be an annoyance. Also realize that doing so is unfair to your colleagues. If you can ask for help with plenty of time to spare, you’re more likely to be greeted with a positive attitude from those you’re asking to help you. Also realize that your colleagues have their own problems and they may not get back to you right away.

Give Back: You Get What You Give

Help should be very much like BitTorrent peers: the desired 1:1 ratio. Simply sponging off of others isn’t acceptable; in order to receive help, you should also be actively helping others, be it you colleagues, IRC users, forum posters, etc. Building relationships in the community is the best way to build a consistent help pipeline.

THE GOLDEN F’IN RULE OF HELP!

Before you send the message asking for help, re-read your message and ask your self this: can the person I’m asking for help from respond with more questions? If they can, answer them before you send the message. Why? Because of this: the secret to effectively asking for help is giving the other person so much information about the problem and how you’ve tried to resolve it that they cannot possibly ask a question you could have answered before you sent the help request! Why? Because that’s a wasted interaction, and wasted interactions increase the time in problem resolution for both parties.

Those are my rules and advice for asking for help. As you can probably imagine, I’m asked for help on IRC and email almost hourly. I’ve also led projects where many parties were involved, and knowing the golden f’in rule above has lead to quicker answers and less stress for everyone. If you have rules to add, please share them, as better help requesting and providing will make us all better developers!

Asking for and Giving Help is a post from: David Walsh :: Legendary scribbles about JavaScript, HTML5, AJAX, PHP, CSS, and ∞.

How did you get so good at everything you do? How did you practice without feeling like you wasted time?

I’m the first one to say that I’m not good at everything; I’m definitely not. One thing I am, however, is persistent when I really love something. I love working with HTML, CSS, JavaScript, XHR, etc. so I spend loads of free time experimenting and trying to master the best techniques. I love every minute of it, and you can only improve that way. I’m not particularly interested in PHP anymore, so I tend to not enjoy spending time with the language, and thus have a hard time improving. My advice at getting good at something is to love it; when you love it, you do whatever you can to be great!

The only time I feel like effort has been wasted is when I wasn’t interested in the topic enough to begin with; over the years, I’ve learned to stop working on a blog post when I stop caring right away. If I think others will find it interesting, I usually put forth the effort to complete it. I also keep the mindset of “if it will save another developer time and hassle, complete it for the common good.” That’s what this blog was founded on: paying it back.

What technology stack do you use for unit testing JavaScript?

Since I spend 40-50 hours per week work on enterprise-level Dojo applications, I work a lot with DOH, the Dojo Toolkit’s unit testing framework. DOH allows for basic functional tests, performance tests, and even synthetic event testing with the DOH robot (which is essentially a Java Applet controlled by a JavaScript API). And since the Dojo Toolkit itself is tested with DOH unit tests, the API is very similar and writing unit tests can be fairly quick. Since Dojo relies largely on Deferred, a special doh.Deferred resource is available for easy testing of those.

Recently, however, my colleague Bryan Forbes created eventd, a synthetic event testing framework for use with Dojo. What I like most about eventd is that it creates synthetic events without the need of the DOH robot, so you don’t need to worry about Java quirkiness. Bryan’s working hard to remove eventd’s Dojo dependency, and if eventd becomes fully library agnostic, eventd should be used by everyone.

One thing to point out quick: you can use DOH with any library, and I recommend you try it!

In what situations would you use Dojo, Mootools, or jQuery (if at all?); in what environment do they shine most?

I get this question all the time. Here’s the quick answer:

I recommend using the Dojo Toolkit if you’re building an advanced or enterprise level web application, or you think your application could become enterprise level. I also recommend using Dojo if your application will be UI-heavy (because the Dijit UI framework is amazing!), uses advanced IO (data stores, lots of XHR, JSONP, etc.), or charts or vector graphics will be used. Dojo will of course work on any size website, but the toolkit really shines when it comes to large scale websites.

I recommend using MooTools if you have a small to medium-sized website (…a non-Dojo site). MooTools packs a ton of power into a small Core package and is supported by many top-class More classes. These resources serve to empower the JavaScript language. Beyond the resources provided by the MooTools team, there are thousands quality plugins within the MooTools Forge, so if your application suddenly needs a new feature, there’s a central location to get that plugin.

Both are extremely modular and teach great coding practices. They’re both efficient, extendable, and written by brilliant JavaScript developers.

As for jQuery, I don’t have a recommendation for when to use it. Nothing against jQuery, but I’ve never needed to go outside of MooTools and Dojo. No need. #MoojoFTW

Which PHP framework do you prefer?

To be completely honest, I tend to hate PHP frameworks. Why? They’re usually over-abstracted, slow as hell, and difficult to debug. I’ve always found creating my own “mini-framework” as the best option, and then modify and add functionality as the situations come up. That way I have complete control over everything that’s being loaded.

PHP frameworks are nice in that there’s usually a community behind them, loads of plugins are available, and they have sexy names. I’ve recently used the Yii PHP framework and if you really need some, I recommend giving it a try. It seems much more lightweight that other PHP frameworks I’ve tried.

Where do you find the time to blog?

Most of my posts are written on weekends while I watch European football (not Arsenal games, where I pace around my living room for 90 minutes). Weekends provide me time to experiment without being interrupted. On the rare occasions that I’m compelled to write during the week, I grab a bottle of wine and my wife is much more understanding.

December 2011 Mailbag is a post from: David Walsh :: Legendary scribbles about JavaScript, HTML5, AJAX, PHP, CSS, and ∞.

It’s been quite a while since I’ve gotten a few things off of my chest and since I’m always full of peeves and annoyances I thought it was time to unleash:

• I really bollocked Facebook during their F8 event last month. Saying Zuckerburg was awkward. Saying they shouldn’t show past Facebook designs because people would long for the good old days. Saying that Zuckerberg also stole the idea for MySpace too because of “Timeline’s” huge banner image and cluttered interface. Saying that “Timeline” was rubbish. Those are judgments on Facebook’s decision-making. In the end, I think Facebook’s engineers are world class and should be recognized as such.
• Steve Jobs was an absolute legend. His innovations have shaped how we both code and access the web today. The iPhone and iPad became synonyms for the “mobile web” and iTunes is synonymous with “online music”; both are markets you’d never believe could be so heavily dominated by one entity. RIP Steve.
• I’m a bit underwhelmed by the new CSS selectors provided by the CSS4 spec…but I don’t know what I’d add, besides variables, so I’m telling myself to STFU. Variables would be nice at some point.
• I’ve also been guilty of talking smack about Firefox over the past year. Mozilla’s doing wonderful things with Firefox; text-overflow support, memory improvements, WebSocket upgrades…Firefox is improving exponentially with each release.
• How long will people use JavaScript frameworks that aren’t modular? Haven’t we all matured to the point where we realize that loading more than we need is ridiculous? How long can lump JS files last? /me looks at jQuery
• If someone would write a definitive “File Size vs. Number of Requests” essay, they would become an instant web legend. Something I’ve always struggled understanding.
• I love how the simplicity that AMD provides to us. define, require, and returning one object. Dojo has adopted it, MooTools 2 will use it; study up, it’s the near future of JavaScript.
• My next redesign will include a made-for-mobile version. I apologize for neglecting the iPad and similar devices for so long; this next version will be optimized for mobile.
• The thought of Google looking to replace JavaScript with Dart is enough to make me want to cry. JavaScript is so immense in potential and flexibility that the thought of it being yesterday’s news is almost unfathomable.
• I always check the version details when I upgrade an iPad or iPhone app. Not because I want to know the new features, but because I want to know when the app devs are screwing up. Nerd Alert!
• If I were an HTML tag, I’d probably be LEGEND. Maybe SUP on the weekends.
• My wife recently signed up for Twitter…and I’ve never been so terrified of getting in trouble for saying something in my life. If you ever see me with a black eye, check my Twitter timeline to see why…
• One of the unsung heroes of the MooTools team is Darren Waddell. His work with the impending website redesign and European hackathons has brought the project to a new level. Thank him when you get a chance.
• The quest for ultimate optimization is a never-ending. Sprites, async JS requests, compressed PNGs, YUI-compressed scripts, cache headers, all those Y-Slow tips; there’s no limit to what we hope to achieve. When is enough enough?
• I’m hooked on Angry Birds again, and I have more stars than Hollywood. Deal with it.

As usual, don’t sing it, bring it. Where am I wrong?

Confessions of a Web Developer XI is a post from: David Walsh :: Legendary scribbles about JavaScript, HTML5, AJAX, PHP, CSS, and ∞.

It’s been quite a while since I’ve gotten a few things off of my chest and since I’m always full of peeves and annoyances I thought it was time to unleash:

• The more I work with advanced JavaScript-based web applications, the more I wish all web browsers used WebKit.  Fast, progressive, flexible.  The world would be a much better place.
• When I switched from Firefox I chose Safari.  With all the cool shit Chrome’s got, I fear I made the wrong choice.
• dojox.mobile is fucking amazing. If you haven’t taken a look yet, you should.  It will be the standard within a few years.
• The amount of time it takes Firefox to close sometimes is nothing short of criminal.
• Fact:  I don’t mind being criticized about something on this blog.  I’m always open to different ways of doing things.  But if you’re going to insult me along the way, you better fucking have a better solution or idea to provide or I will light you up.  (Sponsored by the David Walsh “Don’t Be a Douche” Campaign)
• Titanium by Appacelator looks like a beast. Can’t wait to play with it some more.
• Whoever started the “put your logo in the H1 tag” revolution deserves to lose every client they ever had.  What an SEO killer.
• If you plan to ever make enterprise-level websites and widgets, start learning Dojo now.
• In most cases, removing the dotted outline via CSS from a focused element  is a horrible, horrible idea.  It’s a usability nightmare.  That outline is there for a reason.
• I think my dream job would be to work on websites for soccer teams or publications.  I mean, then, technically, it would be my job to watch the games and create sweet features for them.  GET IN!
• I hope that my dojox.mobile web application and tutorials are well-received when published.  I had a lot of fun making them and I think they could be incredibly useful for developers looking to get into mobile-centric developing.
• You know what I do when the JavaScript toolkit I’m using doesn’t have a feature?  I find another toolkit one that does, port it to the given toolkit, and share it.  You know what I don’t do?  Bitch.
• Is it just me or do non-developers simply not understand the complexity that comes with creating secure, reliable web forms with PHP?  Especially the form processing part?!  Someone please confirm that I’m not crazy.
• I hope the browser vendors iron out their self-prefixing CSS animation stuff quickly.  All these self-prefixed CSS properties are getting out of hand, and it seems to only be getting worse.
• Imagine all the awesome web apps we could create with a true XBOX/game API. Would be epic.
• Google claims that ~44 posts/demos reference Christina Ricci.  That’s far too few.  I apologize — I’ll try to step up in that regard.

Am I wrong?  Am I right?  Bring it.

Confessions of a Web Developer X is a post from: David Walsh :: Legendary scribbles about JavaScript, HTML5, AJAX, PHP, CSS, and ∞.

Whether I’m smug enough to admit it or not, I’m living the iLife.  Over the past two years, I’ve been rocking both the iPhone and MacBook Pro.  I was recently gifted an iPad and a Samsung Galaxy Tab, only increasing my ever-growing smugness level.  After playing with these new toys for a month, I thought I’d share my thoughts on these mobile devices;  the good, the bad, and the ugly.

• Mobile devices like the iPad and Tab seem like the first device that had seemingly everything in front of it:  knowledge of what users want on mobile devices, a platform to support those applications, and high demand for them.
• The iPad seems very, very much refined.  The Galaxy Tab, and other Android-powered devices seem very rough around the edges.
• At this point, I very much approve of the regulation of iPad and Droid apps via their respective stores;  they’re extremely convenient to those non-developer types…
• …although I wouldn’t mind an easier way for us developer-types to have easier access to non-supported applications.
• I’ve not suffered once from not having Flash support on my iPad or iPhone.
• I don’t know a ton about application development, but it would be nice if Apple would allow the frameworks they’ve been banning.
• Having an iPhone makes going shopping with my wife 100 times more bearable…as long as my phone is charged before we go…
• I cannot believe that Facebook does not have an iPad app.  Sure, Facebook’s website is iPad compatible, but an iPad application is desperately needed.
• I do quite like the Tab’s pull-down notification pane — it’s a great way to get mass updates at a glance.
• It was extremely easy to figure out how to delete iPad and iPhone apps…yet I’ve not figured out how to delete apps on the Tab yet.
• Switching between the screen and the home / back / search tabs on the tab hardware seems slightly awkward.
• I desperately want to learn how to quickly make an iPad app.
• I am hopelessly addicted to Words With Friends.
• ATT is robbing people with their mobile usage plans.
• NetFlix is too awesome on iPad — quality is top notch.
• CNN, CNBC, New York Times, Twitter, and the Weather Channel have created outstanding iPad apps.
• With a bit of work, I think Android has a chance at matching Apple’s product.   Well, by “bit”, I mean “a ton.”

Those are my initial thoughts.  Let me know if you have anything to add or if I’m dead wrong!

Thoughts on Mobile Devices is a post from: David Walsh :: Legendary scribbles about JavaScript, HTML5, AJAX, PHP, CSS, and ∞.

Now it’s time to confess your web development sins. Get it out there. You used a <b> tag.  You took an image from Google instead of creating it yourself.  You copy/pasted without proper testing, and committed it to the repository.  Let out my friend.  Let it out!

Confessions Friday II is a post from: David Walsh :: Legendary scribbles about JavaScript, HTML5, AJAX, PHP, CSS, and ∞.

Piotr, please share who you are, your areas of development focus, and who you are employed by.

I am a happy father, an aquarist and a web developer and I would like it to be in that order.

I have started my first commercial web development in 1996 in Poland, and now I am working for Mozilla on Add-ons Builder. The tool of choice is a mix of Django and MooTools.

For those who haven’t heard of jsFiddle, explain what jsFiddle is, how it’s used, and where the idea came from.

JsFiddle is a playground for web developers, a tool which may be used in many ways. One can use it as an online editor for snippets build from HTML, CSS and JavaScript.

The code can then be shared with others, embedded on a blog, etc. Using this approach, JavaScript developers can very easily isolate bugs. We aim to support all actively developed frameworks – it helps with testing compatibility.

The idea came while I was chatting with MooTools developers on IRC #mootools. We were helping new people with JavaScript issues, using code which would fit in one line. Soon there was a question which was too complicated for a “one-liner”. Answering it would involve opening an editor, creating an HTML file with all necessary tags and in the end opening it in the browser. I thought there’s too much burden and the question remained unanswered. From that moment I knew it should be done on the web and the next day the prototype was ready.

You’ve chose to create the jsFiddle interface with the MooTools JavaScript framework. Why did you choose MooTools?

At the time I was already using MooTools on a daily basis, it was natural to choose this framework. I think it is simply the best and I still hold it.

What were some of the early difficulties you ran into when you began coding the website?

The worst was stability – there was no caching and my old server was quickly running out of memory. The other thing was the URL naming convention, jsFiddle still suffers from some of the choices made on day one.

What was the succession / timeline of features you added to jsFiddle?

There were lots of ideas from the MooTools community, but adding new features is always a lot of fun. We are simply trying not to overcomplicate the UI. I think that new interesting features came in following order: ability to save versions, testing Ajax requests, framework dependencies, adding external resources, discussing fiddles.

How long did the first release of jsFiddle take? What problems did you encounter shortly thereafter?

The functional prototype was done in 4 hours, it was written in spaghetti PHP, allowed to save HTML/JS/CSS and was opening the result in a separate browser window. Naturally, I have changed the code since then. There was so much hype I hardly remember the problems I’ve encountered. The one that I remember (and which was hard to solve) was the Cookie security bug. Early versions allowed to steal Cookies from jsFiddle. Someone could steal my administrator password by writing a simple fiddle and asking me to take a look. But this is no longer the case. jsFiddle is in alpha stage, so it’s still before the “first release”.

What pieces of jSFiddle were easier than you thought they’d be? What turned out to be more difficult?

Adding custom caching was something which took two hours – I thought it will take few days. The most difficult was (and still is) planning, the way people use jsFiddle changes and we should predict it in the code, urls and design.

What difficulties did you run into when you opened jsFiddle to more JavaScript frameworks?

One problem is management, I am always late with adding new versions. Recently I upgraded 3 of them in one day YUI, Raphael and Dojo. The other is onDomReady event – I don’t know all of the frameworks and finding a default usage of onDomReady command per framework happened to be not as easy as I thought.

What affect on performance did the website experience when your added the EMBED feature?

To be honest I don’t see any effect, I need to log it properly though.

How many fiddles have been saved to date?

There is over 40,000 fiddles in 160,000 versions

What features do you see adding to jsFiddle in the near future? How about the far future?

Big things – search, user registering, dashboards and social features. That’s something which will change jsFiddle for good. Ephemeral fiddles as default for guests – there is no need to have a fiddle solving an issue on IRC to have an eternal live. We have some ideas for the far future, these however depend on the way people will use jsFiddle.

The Beta release will generally be a big step forward, apart from the aforementioned features, jsFiddle will get a refined interface – this is being worked on very heavily, and it already looks amazing! http://tiny.cc/d290k

Who has been influential in helping you get the website coded, designed, etc.?

Oskar Krawczyk of http://nouincolor.com. He asked me once on IRC if I’d like him to design the UI. I think the next day I knew he is the right person to do it. Since then we are working closely together (not only on jsFiddle, but also on Mozilla Add-ons Builder and some minor projects). Every now and again Oskar adds little functionally enhancements to jsFiddle – discussions, sharing, etc.

On behalf of the MooTools team and everyone that uses jsFiddle, I’d like to thank you for your work!

You are very welcome. It’s great to develop for such a responsive community.

A big thanks to Piotr for his time. If you have more questions, feel free to ask him within these comments and he’ll answer them as soon as he has a moment!

An Interview with jsFiddle Creator Piotr Zalewa is a post from: David Walsh :: Legendary scribbles about JavaScript, HTML5, AJAX, PHP, CSS, and ∞.

It’s been quite a while since I’ve gotten a few things off of my chest and since I’m always full of peeves and annoyances I thought it was time to unleash:

• There are a lot of great new CSS demos being created every day.  I’m just pissed that I always have to switch to Safari to see them.  (Update:  I’ve officially switched my default browser from Firefox to Safari.)
• Is it just me or does Firefox 4.0 seem like a “make or break” release?  With the memory and Firebug issues facing that browser, and with Chrome and Webkit increasing their FTW factor each month, Mozilla really needs to work to gain back the trust of hardcore web developers.
• The 10k Apart contest turned itself into a joke by only allowing jQuery and Prototype.  Dojo and MooTools are the two of the most modular frameworks available — why not allow them?  How can you have a contest based on page size and say “it doesn’t matter how much JS you use as long as it’s one of these two that isn’t nearly as modular as a few others (or modular at all)?”  What’s worse is that, even after all the buzz about it on Twitter, none of the contests judges will even address it.   Pathetic;  nothing but a joke.
• I was afraid people would think I was a traitor to the MooTools cloth when I started writng Dojo Toolkit posts.  No negative reaction has been great.  Plus, you all know I’m MooTools (FTW) through and through.
• Safari’s method of re-opening closed tabs is shit.  It’s a ticking timebomb for the application and you lose the tab’s history.  Why the hell even try?
• I love that HTML5′s philosophy is more of a relaxed, common sense outlook.  Seems to be the right direction.
• Working with the creators of Dojo gives me a completely different perspective on JavaScript development.  It’s welcomed and hopefully they get something out of my opinion as well.
• At age 27 it’s difficult to know if I’m behind, ahead, or right at where I should be as a Web Developer.  I’m learning so much every day that I feel like I’m a decade behind where I should be.
• After working with Dijit for close to 4 months now, I’m still amazed at how easy it makes developing widgets.  And when you can create your widgets declaratively…oh dear.  Amazing how quickly you can put together a functional, enhanced UI.
• I’ve been very pleased to read Rebecca Murphey’s recent jQuery / Dojo / Scalability articles lately.  It’s been something I’ve thought for a while but was afraid to say as I would get pummeled for doing so.
• The MooTools team schedule an upcoming hackathon during my wedding.  Are they trying to tell me something?
• My colleagues at SitePen are all incredibly intelligent, helpful, and funny.  I’m proud to be a SitePenner and work with all of them.
• Speaking of SitePen, I’m working with a great new piece of programming that will put a smile on a lot of peoples’ faces.  Can’t spill the beans yet though…
• I was initially concerned about switching to working from my home office but I’ve found it allows me to be more productive and more relaxed.  If I need a midday nap because I don’t feel well, I can do it.  If I have to get laundry done, I can do it.  And since I’m allowed these privileges, I’m more than happy to go the extra mile whenever necessary.

As usual, don’t sing it, bring it.

Confessions of a Web Developer IX is a post from: David Walsh :: Legendary scribbles about JavaScript, HTML5, AJAX, PHP, CSS, and ∞.

One of the downsides of being around developers of varying skill levels, from noob to Open Source legend, is that everyone has an opinion…and they’re all wrong.  Every one of them.  Of course, me being a developer, I’m wrong too.  There are a few things, however, that I hear frequently and want nothing more than to scream.  Listen here developers:  get over it.

Get Over It!  Valid Mark Isn’t THAT Important!

I’m not saying that it’s OK to not close elements, not properly quote attributes, etc.  What I am saying is that effectiveness is much more important than picture perfect markup.  HTML Validator:  go to hell.  There’s absolutely nothing wrong with using custom attributes.  Dojo uses custom attributes within the Dijit library so that developers can create widgets directly from HTML.  And you know what?  It’s fast, convenient, and allows the developer to move on with their lives. Get over it.

Look at Google, a company that employs some of the most intelligent developers in the world.  At publish time, Google’s homepage has 37 markup errors and 3 warnings.  I detailed markup errors on popular websites a while back.  They all work perfectly.  And have for a while.  And will for a while. Get over it.

Get Over It!  CSS Hacks are OK!

Of course CSS hacks aren’t ideal.  Of course we’d like browser support to be consistent.  Well, it isn’t, so we as developers can only react to the browser vendors’ differences.  And sometimes a CSS hack is the best (or only) way to do it.  I personally choose to add my IE6, IE7, etc. hacks within my main stylesheet instead of conditional statements. Why?  Because I want to cut down on requests and when I think of editing CSS, I don’t want to be jumping from stylesheet to style to find something.  Get over it.

Get Over It!  Open Source Projects Owe You NOTHING!

It wasn’t until I joined the MooTools (ftw) team that I realized how entitled people who use a given library (JavaScript, PHP, etc.) or open source project feel.  Even I was THAT GUY for a while.  Want your opinion to matter?  Want a feature added to the given library?  Want a method within the library modified?  There’s an easy way to do it:  do it.  Take the time to code it and donate it to the library.  Otherwise hear this:  you are owed NOTHING.  Zero.  Nil.  Thousands of hours of other people’s time created the toolkit; pitch in and stop whining. Get over it.

Get Over It!  Your Opinion Is (Almost) WORTHLESS!

Sometimes open source projects can become the equivalent to the WWE.  Everyone’s got a strong opinion and everyone else is wrong.  Egos, egos, egos.  I see it in all of the JavaScript libs (jQuery, MooTools, etc.), JS lib haters (comp.lang.javascript), and libs of every language.  You know how you make your opinion worth something?  Present it professionally and, most importantly, make it work!   Code it, test it, and test it again.  Realize that your opinion is worthless if you don’t make it happen. Get over it.

Get Over It!  Your JavaScript Library’s 3ms ISN’T Leaps Ahead of My Lib’s 4ms

Selector query times are the biggest pissing contests in the history of the web.  While query selector times are certainly important, a 1ms difference isn’t enough to spout your mouth off about.  Save it.  That type of difference is important when you’re dealing with hundreds of elements…and if that’s the case, you may be doing it wrong. Get over it.

Get Over It!  Object Prototype Extension is OK!

As a MooTools team member, I get a lot of grief for MooTools’ philosophy on extending prototypes of Natives like Array, String, Function, Object, etc.  Extending the prototype makes the object (and all instances of the object type) much more powerful and relieves the need to constantly refer to a single namespace and method to do something.  If your library of choice doesn’t extend prototypes, that fine — don’t bitch about those that do though. Get over it.

There you have it.  Mark today as the day you officially got over it.  If you’re offended by this post, you’re exactly the person that I’m trying to target.  Take a step back, think about the big picture, and realize it’s time to grow up.  I did a while ago — and my development life is much better.

GET OVER IT! 6 Things Web Developers Need to Get Over is a post from: David Walsh :: Legendary scribbles about JavaScript, HTML5, AJAX, PHP, CSS, and ∞.

Using AJAX Because You Can

If using AJAX doesn’t improve the user experience, there’s a good chance that using it will cause more harm that good. There are many behaviors and functionalities you’ll need to account for (paging, scroll position, “back button”, etc.) that the browser traditionally handles. Add to that things like browser bookmarking and there’s a good chance that using AJAX may not be the best bet, especially if you don’t want to put in the development and testing time to ensure that your users wont be led down an unreliable path.

Forgetting Scroll Position/Paging

A lot of websites now use a cute paging technique that loads more content once you’ve scrolled down near the bottom of a parent element. That’s great and all but if I click a link, click my browser’s “Back” button, and only the first “page” of content loads, I’ll hunt down the site’s webmaster and shank him. I’d rather wait for a full page load than continually need to scroll to the bottom of an element to get back to where I was.

Providing No “Feedback” Imagery/Message

There’s nothing worse than clicking on a button and …seeing…nothing…happen…Oh, there it is! Communicating effectively with your user is paramount to a good user experience. At least with a new page load the user would see the progress bar light up, the address bar change, and possibly even a different cursor. If you plan on creating an effective AJAX-powered site, use something like Dotter or another visual effect to communicate to the user that something is happening.

Too Many Things Happening at Once

Too frequently do I see AJAX-driven websites that have 100 things happening at once. If there are a hundred things happening at once, how can you effectively communicate that to the user? That’s quite a task. It may be best to try to chunk requests together to better show your users “progress-by-volume.”

Have More?

I know I’m missing a few annoyances — share them! If brave enough, cite websites that are currently making these mistakes!

AJAX Annoyances to Avoid is a post from: David Walsh :: Legendary scribbles about JavaScript, HTML5, AJAX, PHP, CSS, and ∞.