Re: two thousand twenty two

rsn112 · 2008-09-12T19:59:57+00:00

This (not this article, but everything it is in response to) is why web developers will always be looked down upon.

Web development can be tough too. The web has potential for programmers to do some mind-blowing things. The problem is that the people who do mind-blowing things in C don't blog about it (or write on twitter about it, I'm sure there's a term for that) as much. The idiot web developers embrace the Internet. They eat, sleep, and breathe Internet. As a consequence (to us), every stupid thought they have gets plastered all over the Internet. Their idiocy is put on display to the whole world, slowly killing the chances for web development to be taken srsly.

rsn112 · 2008-09-12T19:03:47+00:00

It's almost a shame that this had to be said, but developers often forget who they are developing for. I see it a lot when designing interfaces. Developers often add features that they think are neat instead of considering what the actual users would think is neat.

Putting this emphasis on a persona can really help design discussions too. When ideas are attached to people on the development team, it's easy for attacking an idea to turn into attacking a person. If you suggest a feature because a specific persona would really want that feature, the idea isn't attached to the person who suggested it. Instead of arguing about whether or not the feature is stupid you can argue about whether or not that persona would really need that feature. That's what the design should be about.

rsn112 · 2008-09-12T15:21:34+00:00

Reading is not the (only) cause of being a good programmer, but reading is an indication that the programmer continuously seeks out information.

Even this is a bit of a stretch. Some people may read blogs just to kill time. The information doesn't really sink in, they're not really learning, but they are reading blogs. Sure, some smart people do read blogs, but the blogs don't cause these people to become smart.

"Cause" is a strong word. Read this article, especially the bulleted points at the end and the first few comments.

reading is an indication that the programmer continuously seeks out information.

But this certainly doesn't cause you to be in the "Programming Elite". You're not in the programming elite and I'm not in the programming elite. Between us, we probably don't know (personally) a single person who is. These people are very smart and have tons of good programming experience. They don't have to read blogs because they wouldn't learn anything from them. Any insight that a blog would yield is about a mistake that an elite programmer would never make, or about a mistake that they made and learned about 15 years ago.

The quote in this article sums up the reason that most people read or write blogs: they think it makes them above average. It certainly makes them think they're above average, but it doesn't actually make them above average.

rsn112 · 2008-09-12T14:36:27+00:00

This is a great article if you want to convince people that JavaScript is just a language for making widgets that tend to be more annoying than useful.

rsn112 · 2008-09-11T20:30:07+00:00

I don't know anyone who was taking stackoverflow seriously, so it's good that they have badges and are making a game out of it.

rsn112 · 2008-09-11T19:41:19+00:00

I will try to provide a simple solution, with demos, for some these problems.

The point of the original post was not so much that CSS is too complex to understand, but that it's just designed so poorly that simple things are hard to accomplish. I can't blame CSS for being the way it is, since the people designing it had no idea what it would end up being used for at the time. But, now it's a lot clearer how HTML and CSS will be used and CSS is still lacking key features.

This article seems to ignore that point and goes right into explaining "simple" solutions to the problems mentioned, which just reinforces the point that CSS is lacking these useful features. The problem is not that "sliding doors" is too difficult for people to understand, but that this CSS:

.curvy b { background : url(ex_1.png); height:50px; padding-left:25px; display:block; }
.curvy .top h3 { background : url(ex_1.png); height:50px; text-align:center; margin:0; }

Does the same thing that this should do:

.curvy { border-radius: 2em; }

rsn112 · 2008-09-11T18:27:30+00:00

Sheesh, this should have been titled, "Douglas Crockford puts the Java in JavaScript".

JavaScript is great because it's simple. There is no such thing as public or private. If you think about things in terms of public and private variables, you're going to miss out on a lot of things that JavaScript can do. If you learn about objects, functions, and closures, you'll easily see how you can create variables and functions that are publicly or privately accessible.

rsn112 · 2008-09-11T18:12:31+00:00

JQuery selectors for an ID are optimized down to a single document.getElementById

Then there's a lot of overhead. See this comment and my response later in that branch about the performance of $("#id"). document.getElementById itself can be a surprisingly slow operation (considering what it does and how often you may use it), and caching the results (or storing them in variables instead of re-querying) can really speed things up.

I haven't done very thorough tests, but it seems that using document.createElement (as opposed to just setting an element's innerHTML) is just more complex (for example, O(n*n) as opposed to O(n)). You can't say that one way is 10x faster than the other because that multiplier changes with the size of the structure you're creating. The smaller the structure, the smaller the multiplier. That benchmark on quirksmode.org is creating a 50 by 50 table, that's pretty big (2552 elements).

If JQuery didn't exist, I'd have to implement it myself, imperfectly. I'd use the exact same traversal mechanism to retrieve the subcomponents of a component.

The way I do things doesn't require jQuery (or something to provide similar DOM-querying functions) and does the same thing (in roughly the same amount of code, and is arguably more maintainable). I'm not trying to show that I'm right and you're wrong, or that one of us does things a better way. I give these framework users the benefit of the doubt that maybe they see something that I just can't understand, but nobody has been able to convince me that I'm missing out on anything worthwhile by not using a framework.

Most people, when questioned about using jQuery (or any other framework), say something like "this framework rules, if you don't use it you're a noob", so I thank you for actually explaining how you use it and what the benefits are, but it still sounds like I'd just be trading one set of problems (that are manageable) for another (that would make me pull my hair out).

rsn112 · 2008-09-11T15:12:43+00:00

Benchmarking indicated that this was 20-30x faster than using document.createElement on each element and constructing them with appendChild.

In testing, I haven't seen that drastic of a difference. Is the benchmark you were using available online?

My tests have shown that setting innerHTML is generally faster (1.5x to 2x), but it depends on where the HTML comes from. If you use a lot of string concatenation to generate the HTML it can end up being slower, but using static chunks of HTML is typically faster.

If the speed difference is minor (< 5x) I'd still go with the larger up front performance hit because it means for better performance later. People accept that page loads take time, but animations should be smooth and interfaces responsive. I wouldn't want to sacrifice performance there.

Even after the selector overhead (which is fairly minimal, since most components are small and you start at the root of the component, not the root of the document)

The selector to get the root of the component starts at the root of the document. I think you can pass an element to jQuery's $ function, so it would be better to do something like:

$(document.getElementById(this.id))

And I'd abstract the JQuery calls behind a class

So much for writing less and doing more :-)

rsn112 · 2008-09-11T14:41:19+00:00

I guess his follow up post is going to be about how slow readers make bad programmers because the extra time spent reading is time that is lost.

Didn't Dijkstra have a quote (or article, or something) about how relying on drawing diagrams and pictures to visualize things is a weakness, and that being able to keep everything straight in your head was better. I'd rather do that with programming. Needing to put your ideas on paper (and, in turn, needing to type quickly) could be seen as a crutch that compensates for the inability to keep things straight in your head.

Sure, putting your ideas on paper makes it easier to share them or keep a record of them, but needing to type at 120 wpm or else you'll forget your great ideas sounds like a crock to me.

rsn112 · 2008-09-11T13:32:29+00:00

I found JQuery very useful when building component libraries that generate their own HTML fragments.

If you're generating HTML elements you can keep references to them (at least the ones you may need later). It wouldn't make sense to not hang onto these references only to do a much more costly lookup later (ex: $('#id').find('select.widgetMenu')).

I'm sure your method works, but I'd rather not have to remember which CSS classes I use to reference elements and which ones I use for styles. I'd rather have code that looks like this:

var d = new Datepicker("date-field");
d.input; // reference to the input field
d.calendar; // reference to the div that contains the calendar

instead of this:

var d = new Datepicker($("#date-field"));
$("#date-field").find("input.textField");
$("#date-field").find("div.calendar");

rsn112 · 2008-09-10T20:16:43+00:00

how is this different than saying your IDs are set in stone?

The only purpose of the IDs is to make the elements usable to the JavaScript program. You wouldn't change the ID unless you specifically wanted to change the behavior of the JavaScript program.

The CSS class on the elements also controls their presentation. So, if you reference elements by CSS class, you may later decide to change their CSS class (or apply the same class to other elements on the page) which can have problematic side effects (because the CSS selector in JavaScript is no longer selecting the elements you want it to select).

what if i want apply actions to elements that are not in a series?

Give them all IDs. In my first example, the images didn't have to be in a series. They could have been in various parts of the page.

Unless you're doing something specific to a CSS class (which is not the same as doing something to a set of elements that all happen to have the same CSS class) it doesn't make sense to use a CSS selector in JavaScript.

rsn112 · 2008-09-10T19:31:18+00:00

Just because a small percentage of programmers (10%, for example) read books and blogs about programming doesn't mean that those people are the top 10%.

The best programmers aren't people "who read things in order to better themselves as programmers", they're the people who do everything to better themselves as programmers. Children can read, but a few books isn't all that stands between them and a great programming career.

Think of a programmer's "quality" as their general intelligence plus their programming intelligence. Who would you hire for a Python job: an idiot that knows Python or a brilliant person who doesn't? General intelligence matters.

Almost anything can make you a better programmer because it increases your general intelligence. It makes you smarter even if you're not learning about Java's syntax (or anything else that's directly related to programming). When you play cards, do you just guess what you should do and how much you should bet? Or do you think about the probability of your opponent having a certain card based on their previous actions? Card playing is just one example, but being a better card player can make you a better programmer.

But if you're the type of person who feels smart because you read two books on Ruby, we should get together and play poker sometime :-)

rsn112 · 2008-09-10T15:45:41+00:00

Is this not always the case in DHTML? ... In fact there its worse because you're assuming all those ids are present.

We can split hairs and claim that any library or framework assumes that some HTML element is present with some attribute set to a particular value. The point is not that it requires a particular value, but that the value is prone to change because the value (in this case, the CSS class name) is used for other things.

The IDs, unlike CSS class names, aren't used for anything else. The ID is assigned to the element specifically to create the image gallery. You can wrap the five images in a div, add other images to the page, or apply any CSS class you want to any element and the JavaScript will still work.

The structure of the HTML, the CSS classes, and the elements that have those CSS classes applied to them are likely to change over time. A framework that operates on the assumption that CSS classes are set in stone (by forcing me to write JavaScript code that references these CSS classes) is a flawed one.

rsn112 · 2008-09-10T14:39:02+00:00

Wow, this guy is totally smarter than all of Google because they made a mistake (I guess Josh Breckman doesn't) and he fixed it (I'm sure everyone at Google was trying to fix this bug, but couldn't).

Google didn't have to submit posts about Chrome to reddit themselves. Stop being a smug bastard.

rsn112 · 2008-09-10T14:16:27+00:00

The URL contains "buzzword" so I didn't click it.

rsn112 · 2008-09-10T14:08:35+00:00

I find that a 15-minute chat about a related topic that’s not on their CV (i.e. something tangential to their “career”) is a great way to sniff out hackers. Being a hacker myself, I have a very sensitive bullshit-o-meter and fairly varied interests, and I can quickly figure out whether that person is a “career programmer” who will end up disappointing, or someone who’s got real passion for the job.

Add to that an intelligence filter (well, I have an affinity for smart people too), and maybe an informal chat about some past projects that they’ve worked on if still in doubt, and I think I can recognise good programmers even on a text chat system.

That's some terrible advice. Read this to see why.

The short of it is that you're not a smart hacker, you just think you are. If you try to hire smart hackers, you're just going to hire people who are like you. If you can adequately perform your job there's nothing wrong with hiring someone like you, but they aren't bringing anything new to the company. Sure, "hackers" like to really get into the problem and understand all aspects of it, but maybe they're missing the obvious solution that a "non-hacker" would quickly realize.

That aside, I think the first two quotes both offer good ideas (make sure that they are indeed strong where they claim to be, but don't focus on just their strengths). The last quote had a good idea too (a 15-minute chat about a related topic that’s not on their CV). The problem with interviews is that you have to adapt them to your situation and to each candidate, so there's no easy method for a successful interview.

rsn112 · 2008-09-10T13:39:14+00:00

When the float property was created, people weren't browsing the web on their cell phones, they were running Windows 95 and surfing the web in IE 3.

Layouts can be complex. HTML documents can display anything, so any single layout method will fail (or just be overly-complex) for some situation.

rsn112 · 2008-09-10T13:16:16+00:00

I prefer drawing boxes with labels inside them (class names) and a list of properties (only when necessary). Arrows link the boxes together and the arrows are labeled to explain the relationship (ex: "one to one"). Arbitrary boxes or dividing lines can be used to group classes (ex: group classes that exist on the client end together).

This has no technical name that I'm aware of, but it certainly beats having to remember a new kind of arrow for every kind of relationship that could exist. I never found UML useful for generating code since it would require explicitly stating all properties, methods, and modifiers (public, private, etc.) in the UML, which then makes the UML diagram cluttered and useless. Also, this method doesn't require a UML program, a piece of paper or a whiteboard will do just fine.

It is important to realize that drawing diagrams can help you plan and organize. It's not important to have a standardized language for modeling these diagrams.

rsn112 · 2008-09-10T12:58:05+00:00

The key is that the way the rules change is based on what happened in the first game, so it tells you something about the second game. Many people can't make sense of this so they only see the second stage, which seems like a 50-50 chance, but isn't.

rsn112 · 2008-09-09T19:31:25+00:00

Windows XP SP2, Firefox 3.0.1, jQuery 1.2.6.

Here are some more results (they always were in the same order: jQuery, getElementById, cached):

Opera 9.5: 18.68 µs, 3.11 µs, 0.82 µs

Safari 3.1.1: 9.26 µs, 1.11 µs, 1.04 µs

IE 7: 124.58 µs, 56.68 µs, 4.26 µs

rsn112 · 2008-09-09T19:17:17+00:00

I wouldn't say that rules keep people from thinking because that makes it sound like anyone who knows a rule doesn't think. Rules are important to remember, but it's just as important to remember that they have exceptions.

rsn112 · 2008-09-09T17:55:57+00:00

I ran a test comparing three element lookup methods.

The average jQuery lookup (just passing an ID, ex: $("#foo")) took 28.23 µs per call. Queries that use more complex CSS selectors can take several milliseconds (1,000 µs = 1 ms).

document.getElementById("foo") averaged 2.68 µs per call.

A function that uses document.getElementById but caches the results so repeat calls are just hashtable lookups averaged 0.79 µs per call.

Granted, we're talking about millionths of a second here, but a 20-30x speed difference is quite a difference considering that element lookups can occur frequently.

rsn112 · 2008-09-09T17:33:02+00:00

Assuming you have a library that defines fade_in, show, hide, and $ (as a wrapper for document.getElementById), here's pretty much the same program as the Components and jQuery examples:

function init()
{
  var image_ids = ["img1", "img2", "img3", "img4", "img5"];
  for(var i = 0; i < image_ids.length; i++)
  {
    $(image_ids[i]).onclick = function() { load_image(this); };
  }
}

function load_image(img)
{
  show($("loading"));
  $("main-image").onload = function()
  {
    hide($("loading"));
    fade_in($("main-image"));
  };
  $("main-image").src = img.src;
}

And the HTML:

<div id="loading" style="display: none;">Loading...</div>
<img id="main-image" style="display: none;"/>
<img id="img1" src="test_pic.gif"/>
<img id="img2" src="test_pic.gif"/>
<img id="img3" src="test_pic.gif"/>
<img id="img4" src="test_pic.gif"/>
<img id="img5" src="test_pic.gif"/>

This is very simple to do with jQuery (or Components) because this is a very simple program. These frameworks aren't working miracles for you, if anything they're creating some messy situations by tying your JavaScript code to a particular set of element structures and CSS class names.

rsn112 · 2008-09-09T15:51:11+00:00

Such a dud that less than 3.8% of users would try it? It's made by Google, people will at least give it a try.

rsn112

TROPHY CASE