QuirksBlog - Web thinking
My thinking about the web.
Last week I was the target of a good old-fashioned internet witch hunt when I dared to propose that you should be able to work without tools (frameworks, libraries, and so on) in order to be a web developer.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.