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

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

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

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

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

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

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

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