QuirksBlog - Web thinking

My thinking about the web.

Down with the tool fetish

Permalink | in Web thinking

Sometimes I read a paragraph that makes me wish I had written it. Last Monday that happened again: I became profoundly jealous when I read this:

We know libraries, in fact, we have the best libraries. Our libraries are huuuge

It’s the best part of a hilarious dialogue (that I also wish I’d written) between a newbie web developer who needs a simple REST/Ajax site and an “experienced” front-end engineer who patiently explains the insane amount of tooling this requires nowadays. Read it for yourself. It’s worth it. I’ll wait.

The dialogue pokes fun at what passes for modern web development; especially our infatuation with tools, and it succeeds admirably. The purpose of my post is not to react to the article itself, but to two other reactions I read.

continue reading

Web development as a hack of hacks

Permalink | in Web thinking

Via Bruce I stumbled upon this interesting Hacker News discussion under the ominous title “Is web programming a series of hacks on hacks?” Thingy’s law applies, so the answer is No, but it’s a qualified No, and we need to understand what we should do in order to avoid a future Yes.

Rather to my surprise the discussion was civilised and made good points. I decided to quote it extensively and jot down some of my thoughts as an old-time web developer who is a declared opponent of the framework craze.

continue reading

DRY: Do Repeat Yourself

Permalink | in Web thinking

I am increasingly of the opinion that the general software engineering adage “Don’t Repeat Yourself” does not always apply to web development. Also, I found that web development classes in CS academia are not very realistic.

These two problems turn out to have the same root cause: a lack of appreciation of what browsers do to software development. Browsers, to misquote Douglas Crockford, are the world’s most misunderstood development platforms.

continue reading

Does free make the web cheap?

Permalink | in Web thinking

One more thing about everyone expecting everything on the web to be free: what if that makes web development appear cheap in the eyes of others?

There are very few web tools out there that are for-pay, and everybody expects the latest tool to be free. Also, good advice, browser research, technical tips and tricks, and introductory articles are all for free. It’s possible to become a web developer nearly for free, with your own workstation as the only real cost.

What if that makes people outside the web (say, enterprise Java) believe that web development is not worth much in a technical sense? Something like “if you don’t pay exciting sums of money for this software, how can it be good?”

I’m not saying this is a brilliant argument, but it could be that people actually think like this.

I’m also not saying that this would be a good reason to start paying for web development resources, but it could be one more unintended consequence of the web being free of charge.

Free has a huge upside: it’s free. It also has its drawbacks, and it strikes me we hardly ever think about them.

The web’s original sin

Permalink | in Web thinking

What do a recent A List Apart article, the ad blocker discussion of a few months back, and my browser testing plans have in common?

Free content entitlement, that’s what.

I’m seriously questioning the idea that all content on the web ought to be free. I think it’s an essentially accidental initial state of the web that quietly became the default. By now, consumers (also of web development blogs) feel they have a right to to free content, and producers (including me) do nothing to disabuse them of that notion.

As a result, free content and services have become an entitlement — an unearned privilege. There’s nothing inevitable about content and services being free, although we collectively chose to make free content a cornerstone of the web. That choice, I now think, is the web’s original sin.

I’m wondering if it’s time to significantly revise our thinking on free content and services. In order to explore this problem I wrote this rather long and rambling, but totally FREE, essay. I hope there’s a point hidden somwhere, but you get what you pay for.

continue reading

Stop pushing redux

Permalink | in Web thinking

My Stop pushing the web forward post got quite a few reactions. It’s time for a redux.

Counting Twitter reactions, it struck me that there were far more people who agreed with me than who disagreed. Sure, this is anecdotal data, but I didn’t expect it — I’d hoped for 50% or so agreement at most. There was disagreement as well — some of it dickish, but most quite polite. (At a certain point I had a sad about the dickishness, but looking back it was not all that bad, just the inevitable consequence of saying something that’s — so far — outside the mainstream of web thought.)

The big pushback against my feature moratorium idea came from Jake Archibald with an assist from Bruce Lawson (who also provides a list of other reactions), while Aaron Gustafson tried to find a middle ground. This response mostly focuses on Jake’s piece.

continue reading

Stop pushing the web forward

Permalink | in Web thinking

Fair warning. You’re going to hate this one. I want to stop pushing the web forward for a while. I want a moratorium on new browser features for about a year or so.

Recently I’ve been having serious doubts about the whole push the web forward thing. Why should we push the web forward? And forward to what, exactly? Do we want the web to be at whatever we push it forward to? You never hear those questions.

Pushing the web forward currently means cramming in more copies of native functionality at breakneck speed — interesting stuff, mind you, but there’s just too much of it.

Quick, name all the new features browsers shipped in 2015! You see? You can’t. That’s the problem.

We get ever more features that become ever more complex and need ever more polyfills and other tools to function — tools that are part of the problem, and not of the solution.

I don’t think this is a particularly good place to push the web forward to. Native apps will always be much better at native than a browser. Instead, we should focus on the web’s strengths: simplicity, URLs and reach.

The innovation machine is running at full speed in the wrong direction. We need a break. We need an opportunity to learn to the features we already have responsibly — without tools! Also, we need the time for a fundamental conversation about where we want to push the web forward to. A year-long moratorium on new features would buy us that time.

continue reading

Web vs. native redux

Permalink | in Web thinking

Well, last week’s article generated quite a few hits, and even some useful responses. It’s time to respond to the responses — and note one interesting coincidence.

continue reading

Web vs. native: let’s concede defeat

Permalink | in Web thinking

I feel it’s time to revisit the web vs. native debate, and concede defeat — or, at least, concede that the web cannot, and should not, compete with native when it comes to complex, app-like structures.

I feel we’ve gone too far in emulating native apps. Conceding defeat will force us to rethink the web’s purpose and unique strengths — and that’s long overdue.

I feel that our desire to take on native heads-on has given rise to unnecessarily complex toolchains that slow down what could be simple websites. I’m especially thinking of struggling news sites here, and will argue below that they should go native all the way and forget about the web.

continue reading

Tools don’t solve the web’s problems, they ARE the problem

Permalink | in Web thinking

Seems Facebook (which I don’t use) has put out a new product that allows iPhone users (and only them) to read news articles without leaving Facebook. John Gruber wrote an as-always thought-provoking article about why this could be bad for the web as a whole.

Although I don’t agree that the web is in danger (we hear this story every week, it seems), John makes an important and valid point:

Daring Fireball pages load fast, but the pages I link to often don’t. I worry that the inherent slowness of the web and ill-considered trend toward over-produced web design is going to start hurting traffic to DF.

continue reading

Front end and back end

Permalink | in Web thinking

The difference between back-enders and front-enders is that the first work in only one environment, while the second have to work with myriad of environments that may hold unpleasant surprises.

I feel that the subconscious assumption that a complex JavaScript-driven web site or web app will run in only one monolithic environment is the root cause of many problems front-enders see in back-end-driven web-based projects.

Even worse, where back-enders hold that they’re better in creating complex applications than front-enders — and they may even be right — some show an unwillingness to learn about the front end.

The combination of an insistence on being right about application structuring with a casual dismissal of front-end techniques aimed at catering to myriads of challenging environments makes the archetypical back-ender come across as arrogant. If you want to teach, be prepared to learn.

continue reading

Angular and templating

Permalink | in Web thinking

Well, that was quite a ride. 50K hits on my Angular article (which is a LOT for me), and still people trickling in.

Predictably, trolls came out in the comment threads on Hacker News and Reddit, but also some thoughtful reactions, and even a few who defended my article. It almost seems as if the comment quality is going slightly up. That’s unexpected, and nice. (For the record, I’m not a fan of comments.)

There’s way too much feedback to treat it all — I encourage you to read the comments for yourself — but there’s one particular argument I’d like to point out. It’s about my belief that templating belongs on the server, and it was made in both comment threads:

continue reading

The problem with Angular

Permalink | in Web thinking

In the last six months or so I talked to several prospective clients that had a problem finding front-end consultants in order to help their dev teams get a grip on their Angular projects.

Although there are front-enders that are enthusiastic about Angular, I have the feeling that their number is surprisingly low for a major framework. I expected Angular to gain more traction than it has.

Angular is aimed at corporate IT departments rather than front-enders, many of whom are turned off by its peculiar coding style, its emulation of an HTML templating system that belongs on the server instead of in the browser, and its serious and fundamental performance issues.

I’d say Angular is mostly being used by people from a Java background because its coding style is aimed at them. Unfortunately they aren’t trained to recognise Angular’s performance problems.

I have doubts about Angular 1.x’s suitability for modern web development. If one is uncharitably inclined, one could describe it as a front-end framework by non-front-enders for non-front-enders.

The proposed radical Angular 2.0 rewrite aims to make it more palatable to front-enders, but I doubt they’re interested in yet another MVC framework. In addition, the rewrite will likely alienate Angular’s current target audience.

continue reading

This is the blog of Peter-Paul Koch, mobile platform strategist, consultant, and trainer. You can also follow him on Twitter.
Atom RSS

I’m around at the following conferences:

(Data from Lanyrd)

Categories:

Monthlies: