Strong opinions, weakly held

Tag: Web development (page 2 of 4)

Links from May 28th

Quotable: Simon Willison

This is a great definition of a microframework:

Microframeworks let you build an entire web application in a single file, usually with only one import statement.

Links from March 30th

Links from March 23rd

There are a whole ton of links in the backlog today.

Web site CPU usage

Brent Simmons says that developers should profile their Web pages to see how they affect the CPU usage on end user computers. My wife uses an iMac G5, and I can tell which Web sites she’s using based on how loud the fan is. There are plenty of Web sites that keep the fan running all the time, even if she walks away from the computer. This is an area of Web development that has been ignored but should not be.

Filtering versus conditional logic

One aspect of jQuery that I’ve really come to appreciate is its ability to apply filters to elements on a Web page. Let’s say, for example, that you want to disable all of the links on a Web page if the user has not yet logged in.

In most server-side frameworks, this requires you to add conditional logic to every link on the page (or just use a different template entirely). In PHP, you’d have to do something like:

<?php if ($login_page) { ?>
    My stuff
<?php } else { ?>
    <a href="">My stuff</a>
<?php } ?>

You could perhaps shorten that a bit if you were clever, but that’s what you’re up against. And the problem is that you have to repeat it 100 times if you have 100 links on the page. You have to add a lot of code to your page to do something relatively simple.

On the other hand, with a tool like jQuery, you can accomplish something similar with one line of code.

$("a").bind("click", function(e) { return false; });

Needless to say, it’s a much cleaner and simpler approach. This approach won’t work in terms of security since users can just disable JavaScript, but it’s great in terms of clarity and simplicity.

What I’m wondering is why more server-side frameworks don’t have similar selector-based DOM manipulation tools built in. Wouldn’t it be cool if you could attach such filters to views on the server side and manipulate the output page before it’s presented? Why isn’t this more common?

Google on rewriting dynamic URLs

Google says that rewriting dynamic URLs is obsolete as far as they’re concerned. Google has no longer has any problem indexing sites that are built using dynamic URLs.

I prefer frameworks with nice URLs, but if you’re not using one, it’s fine to just go with the standard URLs produced by the application rather than using Web server hacks to make improvements that are no longer needed.

When’s framework overhead justified

The other day we had an interesting discussion at work about when the overhead of using a framework is justified. Incorporating a framework into an application has costs in terms of performance and complexity. In this case, we have a few JavaScript features that we wind up using on most Web sites, and the question was whether or not to use jQuery to reimplement those features, or to just use some simple home grown scripts that we already had.

The argument against was that we already have scripts (even though they need some updates), and that the compressed jQuery file is still over 20 kilobytes. Plus it’s an additional dependency that could introduce conflict with other choices we make later on.

In the end, we wound up choosing to include jQuery, for a couple of reasons. The first is that it makes the framework responsible for most of the code that’s likely to require more maintenance due to browser inconsistencies. When Internet Explorer 8 is released or Firefox 3.1 comes out, jQuery contributors are likely to find most of the bugs and inconsistencies and release an update that fixes them. Even if I have to fix some of those bugs, I’ve found that the frameworks still save time. I had to fix an Internet Explorer 5 bug in Prototype once, and I didn’t find it that difficult, even though most of Prototype’s source looks like magic to me.

The second is that incorporating the framework lowers the bar for adding new features to the Web site. If jQuery is already available, the barrier to writing new features is much lower than it is when writing those features from scratch, and I don’t have to revisit the decision whether or not to add a framework at that point. It becomes a tougher decision when you already have non-framework code in place.

I’ve become a fan of using a framework from the start, especially if the framework adds at least some value to even simple tasks. For example, JavaScript frameworks like jQuery make almost everything you do a little bit simpler, from binding events to altering styles on the page. They may not save you much time in your initial efforts because you’re doing something simpler, but you’ll be prepared to reap more efficiency as you add features to the site in the future. And you’re then not forced to make a tougher decision about when to add the framework later (especially if it would require writing non-framework code).

There’s probably an economic argument to be made here about marginal costs. Adding a framework increases the fixed costs of an application in terms of time and complexity, although the simplest frameworks make these fixed costs almost negligible. There’s a cost involved with setting up the framework and learning enough about how it works to employ it effectively. However, the right framework will lower the marginal cost of new features.

My thought is that it’s almost always worth it to eat the fixed costs of using a well-chosen framework to gain the marginal cost benefits when writing new features.

Adobe is making Flash searchable

Looks like one argument against building Web sites in Flash is going to bite the dust. You still shouldn’t build Web sites in Flash.

Why Firebug is awesome

jQuery creator John Resig explains the advances that FireBug brought to JavaScript development. I’d say that I didn’t really take JavaScript seriously until I started using FireBug.

He also has a list of potential improvements to FireBug, including porting it to work with Internet Explorer. Given the amount of time Web developers spend debugging weird issues in Internet Explorer, a tool like FireBug would literally be life changing.

Older posts Newer posts

© 2024 rc3.org

Theme by Anders NorenUp ↑