My thinking about the web.
Safari is holding back the web. It is the new IE, after all. In contrast, Chrome is pushing the web forward so hard that it’s starting to break. Meanwhile web developers do nothing except moan and complain. The only thing left to do is to pick our poison.
The tools vs knowledge argument goes something like this:
Over the past ten years I have heard this drive a car analogy more often than I care to remember. Superficially, it’s an interesting one, but I found I disagree with it.
Although there’s a lot of heated discussion around diversity, I feel many of us ignore the elephant in the web development diversity room. We tend to forget about users of older or non-standard devices and browsers, instead focusing on people with modern browsers, which nowadays means the latest versions of Chrome and Safari.
This is nothing new — see “works only in IE” ten years ago, or “works only in Chrome” right now — but as long as we’re addressing other diversity issues in web development we should address this one as well.
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.
I’m not saying you should give up your tools and only work in raw CSS and JavaScript. Instead, I’m saying that you should be able to do so. That’s my definition of a web developer, and it’s what I fundamentally believe in and will stand up for — repeatedly, if necessary.
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.
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.
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.
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.
This is the blog of Peter-Paul Koch, web developer, consultant, and trainer.
You can also follow
him on Twitter or Mastodon.
Atom
RSS
If you like this blog, why not donate a little bit of money to help me pay my bills?
Categories:
