サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
災害への備え
infrequently.org
The global device and network situation continues to evolve, and this series is an effort to provide an an up-to-date understanding for working web developers. So what's changed since last year? And how much HTML, CSS, and (particularly) JavaScript can a new project afford? The Budget, 2024 JavaScript-Heavy Markup-Heavy Calculate Your Own Situation Report Mobile Desktop Takeaways The Great Branch
Update: This post was turned into a talk for State of The Browser in October 2021; you can watch the recording here. Update, The Second: Welp, I was wrong. I assumed that Facebook PMs and engineers were smart. Of course they were going to get found out modifying content via In-App Browsers, just as this post warned they could. It's long past time for Google and Apple to act to curb this abuse via
Alex Russell on browsers, standards, and the process of progress. Joining a new team has surfaced just how much I've relied on a few lenses to explain the incredible opportunities and challenges of platform work. This post is the second in an emergent series towards a broader model for organisational and manager maturity in platform work, the first being last year's Platform Adjacency Theory. That
Alex Russell on browsers, standards, and the process of progress. Update: After further investigation, an even better solution has presented itself, which is documented in the next post. The new content-visibility CSS property finally allows browsers to intelligently decide to defer layout and rendering work for content that isn't on-screen. For pages with large DOMs, this can be transformative. I
Alex Russell on browsers, standards, and the process of progress. TL;DR: Does it matter if the web platform adds new capabilities? And if it should, which ones? The web is a meta-platform. Like other meta-platforms the web thrives or declines to the extent it can accomplish the lion's share of the things we expect most computers to do. Adjacency to the current set of capabilities provides a discip
Alex Russell on browsers, standards, and the process of progress. TL;DR: we cannot continue to use as much JavaScript as is now normal and expect the web to flourish. At the same time, most developers experience no constraint on their use of JS...until it's too late. Lightweight, effective tools are here, but we're stuck in a rhetorical rut. We need to reset our conversation about "developer exper
Alex Russell on browsers, standards, and the process of progress. TL;DR: performance budgets are an essential but under-appreciated part of product success and team health. Most partners we work with are not aware of the real-world operating environment and make inappropriate technology choices as a result. We set a budget in time of <= 5 seconds first-load Time-to-Interactive and <= 2s for subseq
Alex Russell on browsers, standards, and the process of progress. Mikeal Rogers reached out last week to talk about Web Components, which surprised me, but his follow-up blog post is essential, timely reading. Dimitri Glazkov, Alex Komoroske, and I started the project that designed and (for many years) iterated on Web Components with a few primary goals in mind: Enhance component portability Shrin
Alex Russell on browsers, standards, and the process of progress. Since Frances and I published a blog post last year introducing Progressive Web Apps, a healthy conversation has started about what is and isn't a PWA. There are a lot of opinions and many shades of gray. What are the hard requirements? Which requirements are marginal? What's aspirational? This article outlines these requirements, a
Alex Russell on browsers, standards, and the process of progress. A lot of smart folks keep asking me why AppCache isn't a good enough solution for "offline" and why it was necessary to invent Service Workers. It's a great question! Motivated by the regrettably uneven browser support landscape for Service Workers, there's a real incentive to "just make something work offline" on iOS or old-IE. Thi
Cross-posted at Medium This post is about vendor prefixes, why they didn’t work, and why it's toxic not to be able to launch experimental features. Also, what to do about it. Premature Compatibility # Vendor prefixes are a very sore topic, and one where I’ve disagreed with the overwhelming consensus. In the heat of the ‘11–12 debate ("prefixpocalypse") I tried to outline a hierarchy of the web pla
Alex Russell on browsers, standards, and the process of progress. It happens on the web from time to time that powerful technologies come to exist without the benefit of marketing departments or slick packaging. They linger and grow at the peripheries, becoming old-hat to a tiny group while remaining nearly invisible to everyone else. Until someone names them. This may be the inevitable consequenc
Alex Russell on browsers, standards, and the process of progress. One strain of objection I often hear about the project of making the web more extensible is that it implies travelling further down the JavaScript rabbit hole. The arguments often include: No other successful platform is so limited to a single language (in semantics if not syntax). Better languages exist and, surely, could be hooked
Alex Russell on browsers, standards, and the process of progress. One of the things I've poured myself into this year -- with a merry band of contributors including Domenic Denicola, Anne van Kesteren, Jake Archibald, Mark Miller, Erik Arvidsson, and many others -- has been a design for Promises that DOM and JS can both adopt. There's a (very) long history of Promises, Deferreds, and various other
Alex Russell on browsers, standards, and the process of progress. By now you've seen the news about Blink on HN or Techmeme or wherever. At this moment, every pundit and sage is attempting to write their angle into the annoucement and tell you "what it means". The worst of these will try to link-bait some "hot" business or tech phrase into the title. True hacks will weave a Google X and Glass refe
Alex Russell on browsers, standards, and the process of progress. Jetlag has me in its throes which is as good an excuse as any to share what has been keeping me up many nights over the past couple of years; a theory of the web as a platform. I had a chance last week to share some of my thinking here to an unlikely audience at EclipseCon, a wonderful experience for which my thanks go to Mike Milin
Alex Russell on browsers, standards, and the process of progress. This is a quick thought as I'm working on something much longer (and hopefully more interesting) to be published in the next week or so. Also, I just want to re-iterate that what's said here are my own thoughts and not those of Google unless expressly stated otherwise. I've been arguing -- mostly over beers -- for the last year or s
このページを最初にブックマークしてみませんか?
『Infrequently Noted』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く