Posts tagged “web”, page 6

Jeremy Keith:

Very soon, the vast majority of browsers will have an engine that’s either Blink or its cousin, WebKit. That may seem like good news for developers when it comes to testing, but trust me, it’s a sucky situation of innovation and agreement. Instead of a diverse browser ecosystem, we’re going to end up with incest and inbreeding.

Dave Rupert:

But in the past we had browser disparity as a mechanism for delaying bad ideas from becoming ubiquitous so they could be hashed out in a Web Standards body. Some of the best ideas we have today, like CSS Grid, were pioneered in one browser (IE10) and then polished in a Working Group. If V1 of -ms-grid was now the de facto standard, we’d have some regrets.

Brad Frost:

I’m confident developers will get their heads around it. They’ll figure out their swim lanes and understand which JavaScript does what. I’m more concerned about other team members who are now staring at a Big Ol’ Intimidating Ball O’ JavaScript. And I’m concerned for those recruiters and hiring managers who are even further removed from the day to day. Those job listings with a giant spray of buzzwords and technologies can now be winnowed down to a single word: JavaScript. Those recruiters have a hard enough time separating Java from JavaScript, so best of luck to them making sense of the complex JavaScript ecosystem.

Jeremy Keith:

It’s not that CSS in inherently incapable of executing complex conditions. Quite the opposite. It’s precisely because CSS selectors (and the cascade) are so powerful that we choose to put guard rails in place.

On the news of Edge switching to the Chromium engine, Tim Kadlec writes:

We need Google to keep pushing the web forward. But it’s critical that we have other voices, with different viewpoints, to maintain some sense of balance. Monocultures don’t benefit anyone.

Hear, hear.

I’ve been taking a lot of interest in this topic ever since I started working on my own reset/boilerplate — Cobalt.

Heydon Pickering:

By assuming the role of the Full Stack Developer (which is, in practice, a computer scientist who also writes HTML and CSS), one takes responsibility for all the code, in spite of its radical variance in syntax and purpose, and becomes the gatekeeper of at least some kinds of code one simply doesn’t care about writing well. This has two adverse effects:

1. Poor quality code
2. A bunch of people who can (and would enjoy!) expertly writing that code, standing unemployed on the sidelines muttering “WTF”

I so very much agree with everything Heydon says here. And that agreement comes from the experience of trying to become a full stack dev myself (though going at it from an HTML/CSS-first perspective).

Ethan Marcotte:

Let me start by saying I generally avoid terms like “mobile,” “tablet,” and “desktop” in my work. It’s not that they’re bad; it’s because they’re broad. In my experience, terms like these confuse more than they clarify. Ask a roomful of clients or stakeholders to define “mobile,” and you’ll get a roomful of slightly different responses.

What I think is helpful, though, is breaking down the specific conditions or features that’ll cause our designs to adapt.

Paul Robert Lloyd:

Such notions of craftsmanship can soon lead us down a dangerous path, raising questions around elitism and discrimination. These are accusations you could level towards the IndieWeb. For all its promise of giving people the tools to regain ownership of their online identity and content, to do so fully and effectively requires a proficiency for coding and familiarity with an endless barrage of acronyms. Encouraging participants to selfdogfood only exacerbates the near-impenetrability and narrowness of this movement.

Rob Weychert chimes in and gets a strong +1 from me:

I’ve been making websites for 20 years. I read a bunch about how to set up webmentions and gave up before I started. 🤷🏻‍♂️ https://t.co/iIv1BgQXlY

— Rob Weychert (@robweychert) November 27, 2018

If even web people find it difficult, how can we ever manage to empower non-web people to produce web-like content?

Ben Callahan:

When you strip away all the stuff we do to try to control the experience of a website, it turns out the web is pretty darn accessible. It only breaks when we break it.

Dave Rupert:

Let’s say we have a site with ~300 third-party scripts all responsibly loaded as async, what would be the User Experience costs and risks?

Ben Frain gives some very useful and pragmatic advice on how to build web front-end prototypes.

Producing something of high fidelity, perfectly matching any flat designs, runs counter to the notion of creating something quickly. The challenge for the prototyper is therefore how to cut corners that don’t impact the fidelity of the prototype.

Jeremy Keith adds:

In my experience, it’s vital that the prototype does not morph into the final product …no matter how tempting it sometimes seems.

Prototypes are made to be discarded (having validated or invalidated an idea). Making a prototype and making something for production require very different mindsets: with prototyping it’s all about speed of creation; with production work, it’s all about quality of execution.

Max Böck:

Text-only sites like these are usually treated as a MVP of sorts. A slimmed-down version of the real site, specifically for emergencies.

I’d argue though that in some aspects, they are actually better than the original.

This is the web as it was originally designed. Pure information, with zero overhead. Beautiful in a way.

Jeremy Keith:

I really like this design pattern. Cover 80% of the use cases with a declarative solution in HTML, but also provide an imperative alternative in JavaScript that gives more power. HTML5 has plenty of examples of this pattern. But I feel like the history of web standards has a few missed opportunities too.

In recent years there’s been a push to expose low-level browser features to developers. They’re inevitably exposed as JavaScript APIs. In most cases, that makes total sense. I can’t really imagine a declarative way of accessing the fetch or cache APIs, for example. But I think we should be careful that it doesn’t become the only way of exposing new browser features. I think that, wherever possible, the design pattern of exposing new features declaratively and imperatively offers the best of the both worlds—ease of use for the simple use cases, and power for the more complex use cases.