QuirksBlog

Syndicate content
Updated: 12 hours 9 min ago

Linkbait 41

Tue, 06/12/2018 - 5:28am

Friends edition. Lots of articles by people I’ve known for ages. Not sure why; probably just a coincidence.

  • The Big Z deplores the cult of the complex.

    in a field where young straight white dudes take an overwhelming majority of the jobs (including most of the management jobs) it’s perhaps to be expected that web making has lately become something of a dick measuring competition.

    Before you diss him (and me) as an old fart who isn’t keeping up with the times, please consider the following question: At which time can we start to safely say that people who just cram frameworks into everything they make are too set in their ways and can’t keep up with the latest trends? Two years? Three? Five?
  • Brad takes a middle position between those who applaud the shiny new and those who deplore it, by asking (rather testily? or is that just my imagination?) why both sides treat a simple “I don’t understand X” as fodder for their view of web development. (I am guilty as charged, I’m afraid.)
  • Jeremy hopes AMP will drive itself to extinction.

    If anything, I’ve noticed publishers using the existence of their AMP pages as a justification for just letting their “regular” pages put on weight.

    and

    I wish that AMP were being marketed more like a temporary polyfill. And as with any polyfill, I look forward to the day when AMP is no longer necesssary.

  • Rachel wrote a massive guide to CSS layout. I’ll have to study it closely if I ever write the CSS book for JavaScripters. I did not know about display: flow-root.
  • Ethan is a little excited about Safari (or, at least, WebKit) coming to the Apple Watch. So am I. It’ll be interesting to see how they solved the low-memory and small-screen issues. Ethan’s article contains a lot of useful links.
  • I’m not excited about yet another meta tag, though — see Erik Runyon’s article for the details. I wish we could have left it at the existing one, but of course web designers didn’t make their old sites fit for 272px, which appears to be the ideal layout viewport width of the smallest watch.
  • Tim adds some performance notes:

    The median site sends about 351kb of compressed JavaScript to “mobile” devices according to HTTP Archive. That’s roughly 1.7-2.4MB of uncompressed JavaScript the browser has to parse, compile, and execute. That little S3 processor is going to struggle if we try to serve anything close to the amount of JavaScript that we serve to everything else.

    Use AMP? (Just kidding)
    We can hope that this will drastically drop average JS usage, but it probably won’t.
  • The inimitable Lin Clark wrote cartoon introductions to DNS over HTTPS and ES modules.
  • A very useful overview of current VR sets, including their browsers and WebVR support.
  • Speaking of which, Tesla updated its browser. It’s not a cutting-edge one, judging by the HTML5 Tests screenshots, but I can see why disabling video in a car browser might be a good idea.
  • Have a tip for the next Linkbait? Or a comment on this one? Let me know (or here or here).

performance.now() conference,8/9 November, Amsterdam

Tue, 06/05/2018 - 12:23am

It’s always a nail-bitingly tense few months after you decide to create a new conference hoping it’s going to be a success. We decided to inflict this tension on ourselves once again with our latest venture: performance.now().

Conceived during a dinner with Tim Kadlec over a year ago, nurtured by Tim’s good graces as well as Steve Souders’s, its every whim served by Krijn and me, performance.now() is a two-day one-track front-end performance conference in Amsterdam on 8th and 9th of November.

(And no, we don’t have the obvious domain name. We’d love to get it, but .now domain sales haven’t started yet.)

Our speakers will treat topics including JavaScript, CSS, PWAs & AMP, responsive design, image optimization, performance budgets, frameworks, monitoring, browsers, mobile devices, custom fonts, and perceived performance.

Who are our speakers? Glad you asked. Harry Roberts, Tammy Everts, Anna Migas, and Zach Leatherman. Not convinced? Andrew Betts, Paul Irish, and Natasha Rooney. Need more? Yoav Weiss and Katie Sylor-Miller. And of course Steve Souders and Tim Kadlec — why let them go to waste when they’re involved anyway? And there are five more speakers as yet to be announced. The speaker page will be updated as soon as we’ve got something to share.

We would not be able to put on this show without support from our sponsors, currently SpeedCurve, Catchpoint, Filament Group, and Varnish Software. We hope to be able to announce more sponsors shortly.

Tickets are €550 + VAT (early birds have already sold out). Lunch and post-conference drinks included. Nice weather not included; this is November in Amsterdam, after all. But we’ll survive.

Will we see you at performance.now()?

Linkbait 40

Tue, 05/29/2018 - 1:38am

A CSS-heavy edition. I’m doing research for my possible new book, and I need to know more about what people don’t like about CSS. So there’s a lot on that topic.

  • The Front-End Tooling Survey 2018 - Results. Which front-end tools are used most, and are best-known? Personally I’m most interested in the CSS tools the article opens with, but there’s also JavaScript, where Vue overtook Angular.
  • CSS: the bad bits. Starts with the global scope, of course. Joe’s solution of choice is BEM. Agree or disagree with him on the solution, CSS global scope is not always good.
    Continues with many more useful notes. Very useful for understanding what JavaScript developers dislike about CSS.
  • Very interesting article by Adam Wathan, where he starts doubting the separation of structure and presentation. Money quote:

    My markup wasn't concerned with styling decisions, but my CSS was very concerned with my markup structure.

    There is some truth here, and I must admit I’ve started doubting the strict separation of structure, presentation, and behaviour we made popular in web development all those many years ago. I need some time to assimilate all of this, since I spent most of 2000-2004 telling web developers to strictly separate their concerns. Now ... maybe it’s time to revisit that.
    Food for thought.
  • A lengthy guide to using CSS custom properties, either in a Sass context or not. I especially like the heading “Don’t Be Too Clever.” You can do amazingly complex things with custom properties, but it’s not always a good idea. For instance, you can calculate font sizes and widths and such at runtime, but that might eat up too much valuable processor time. So calculate the values beforehand and let the browser switch between them.
  • Brad Frost on CSS architecture for design systems. He, too, inserts BEM into his solution, so I guess there must be something good there.
  • And while we’re on this topic, here’s Harry Roberts’s CSS guidelines. Not exactly new, but still important.
  • How browsers position floats. A technical breakdown of what happens when you float elements. With interactive example.
  • A breakdown of CSS !important and what we can use it for.
    Doesn’t really treat my favourite use case: figuring out if you have a cascade problem. If styles mysteriously don’t show up, I add !important. If they do show up now, I have a cascade problem. If they still don’t, something else is going on. Useful debugging information. Afterwards I remove the !important and fix my code.
  • Interesting breakdown of how Microsoft CEO Nadella shifted from a Windows Everywhere strategy to a Services, Not Devices strategy. It took him five years because in the short term Windows mattered a lot to Microsoft clients.

    [Office for iPad was] an easy win that symbolized the exact shift in mindset Microsoft needed: non-Windows platforms would be targets for Microsoft services, not competitors for Windows.

    True. Right now, what Microsoft could do to target non-Windows platforms is porting Edge to Android and creating a competitor for Google Services. Now that would be interesting. Still, it’s a huge investment and so far it doesn’t appear to be forthcoming.
  • We always assumed that smartphones would entirely replace feature phones in the long run. This report, however, finds that feature phone traffic is actually going up in India, where both iOS and Android lose market share. This share is picked up by the new FirefoxOS-based KaiOS feature phone system, which, according to this report, has already overtaken iOS in India.
    Interesting times are here again? In any case I badly need a Nokia 8110, which runs KaiOS.
  • GDRP and ads. According to this article, the new European GDPR (you know, the reason you got so many mails last week) is going to pop the adtech bubble. Doc Searls distinguishes between the ads themselves, which are not necessarily evil or bad, and adtech, which purports to connect the right ads to the right people, but mysteriously doesn’t and (my interpretation!) is so in awe of its own cleverness that it ignores the ad-blocker writing on the wall.
  • null >= 0 evaluates to true in JavaScript. Why? Abinav Seelan explains.
  • Brian Rinaldi argues against the job title “full-stack developer” by giving a lengthy list of things these developers are supposed to know. No one can be a specialist in all of these areas, and I’m not sure we need a lot of generalists who know a little bit about everything.
    So don’t call yourself a full-stack developer. You can’t be.
  • Dave Winer on why the Internet is going the wrong way.
  • Have a tip for the next Linkbait? Or a comment on this one? Let me know (or here or here).

New speakers, devrels, and videos

Tue, 05/08/2018 - 2:54am

When selecting speakers for our conferences we always hunt for a video of a prospective speaker, unless we’ve seen them for ourselves in the flesh. If we cannot find a video, we do not invite the speaker, since we cannot guarantee to our audience that they are excellent presenters. Not all conferences do so, but we do.

For some new speakers this is a bit of a hurdle. Not an insurmountable one — some local meet-ups and most conferences record their sessions — but it’s still an extra step. Local meet-up organisers take note: recording the sessions would be a huge service for your speakers — if you have the budget.

That was not what I wanted to talk about today, though. In the past months we conferred with quite a few developer relations departments about CSS Day and performance.now(), and they all proposed a speaker that they didn’t have a video of. So we said No.

For developer relations departments, whose job it is to get their people to speak at conferences, this is a far more serious oversight than for individuals.

So my advice to developer relations departments is to organise a local meet-up, get all their unknown speakers to speak, record all sessions, and put them online. I mean, they must have the budget to do that once, right? It would be a great gift to conference organisers around the world, even to those that do not require videos.

And while you’re at it, hey, also invite that one local speaker that you think should get more conference invitations.

Why is not using the CSS cascade a problem?

Tue, 04/17/2018 - 3:45am

When I announced I was going to write something for JavaScript developers who don't understand CSS, plenty of people (including Jeremy) said that the Cascading & Inheritance chapter would be crucial, since so many JS developers didn’t seem to understand it.

At first I agreed, but later I started to harbour some doubts, which is the reason I’m writing this piece.

As far as I can see, the problem is not that JavaScript developers do not understand the cascade, the problem is that they do not desire to use it. But is this really a problem?

Global scope

CSS only has a global scope. A button.primary rule affects all buttons with that class on the entire page. This is the strength of the cascade. In a recent project I spent half an hour with the designer defining a primary, secondary, and tertiary button/link class. That was time well-spent: both of us could drop buttons into the code from that time on, and their styles would just work.

JavaScripters have learned to dislike and distrust the global scope, however. Although this is an excellent idea in JavaScript, so the theory goes, it makes a lot less sense in CSS, since part of the strength of CSS is exactly its cascade-induced global scope. Therefore JavaScripters do not like CSS; see, for instance, CSS: the bad bits, which opens prominently with complaints about the global scope.

But don’t JavaScripters see the advantages of the CSS cascade? Aren’t they ignoring part of what makes CSS so powerful?

Local scope

Well, yes and no. To return to my earlier primary button example, it makes excellent sense in a relatively simple site like the one we were making. It starts making less sense when you want to drop not a single button, but an entire component, which might include a button, but needs the button style to conform to the component style. In that case you want to make sure that general styles don’t influence the component’s button. You want your CSS to be local in scope.

None of this is particularly surprising, and I have no doubt that my readers have figured this out for themselves and hit on the remarkable solution of using both global and local styles, depending on the exact nature of their project. As Charlie Owen said:

I hear people making out that scoped and cascade are incompatible. But using the cascade just means (to me) making use of the global aspects of CSS. Set your default block level margins, your typography, etc high up. Then each component can scope anything extra.

So far so good. This, as far as I can see, is the correct solution to the problem.

What’s the problem?

But what am I to make of the complaints about JavaScripters not understanding the cascade? I think they understand it perfectly fine; they just decide not to use it.

So I don’t think there’s really a problem here. Still, I decided to write this piece and ask this question because I might overlook something.

So what’s the problem with JavaScript developers and the cascade beyond them overlooking some use cases for global styles, wrapped up as they are in making everything local? Could someone please explain?

Thanks.

Know JS online event

Mon, 04/02/2018 - 5:24am

On 13th of April the inaugural Know JS online conference takes place. I’m tangentially involved, though I will not speak. The conference is online, and runs from 9am to 6pm Eastern on 13th of April. You can attend from the comforts of your own house.

Know JS is a fairly special type of online conference. Four speakers, Kyle Simpson, Bianca Gandolfo, Kent C. Dodds, and Jem Young, will give not a conference talk, but a full two-hour workshop about a topic of their choice. By buying a ticket you get access to all four of these workshops.

In addition, all four speakers will release a pre-recorded short presentation that sets the tone for their workshops, and these presentations will be available for anyone, not just for ticket holders. They will be published as they come in, starting today.

Tickets are $299, and we decided to cap their number at 50, so that some sort of live interaction between the attendee (that’s you!) and the teacher is possible.

This is a fairly unique type of conference, and credit wholly goes to Kyle, who came up with the idea. His fellow organisers, Brian Rinaldi and me, thought this was a very interesting take that we should try. So here we are, trying it.

This project started with Brian and me meeting in Sofia, and since we’re both conference organisers the conversation quickly turned to conference organising. We found that both of us would like to run a JavaScript event that was not focused on one or more of the popular framenworks, but instead on the language itself. We feel this topic is somewhat underrepresented in today’s conference cycle.

We decided to get Kyle Simpson on board, and our thoughts started to run toward an online event. Although all three of us would prefer a real conference, we weren’t sure how well the topic would be received. So we’re testing the waters, as it were, and if this event is a success, we’ll probably make the jump to an offline conference, ideally with editions in the States and in Europe.

We’ll see what happens next. But if you’re interested in JavaScript the language, please take a good look at what we’re offering.

Linkbait 39

Tue, 03/20/2018 - 1:31am

More like a link-late, but here it finally is.

  • Tim Kadlec takes a look at how fast AMP really is, spurred on by Ferdy Christiant’s research that we featured earlier. Tim concludes that the main performance benefit comes from AMP pages being served from Google’s CDN. Other than that AMP pages are mildly more performant than non-AMP pages, mostly because it arranges some optimizations and resource loading for you. The cost, however, is a slightly slower Start Render time, because the scripts that arrange all those optimizations and loading have to run before the AMP page is ready to be shown.

    Right now, the incentives being placed on AMP content seem to be accomplishing exactly what you would think: they’re incentivizing AMP, not performance.

  • Steve Yegge shares his thoughts on the current state of Android. While Google still retains control over Android itself, it may be losing its grip on important auxiliaries:

    We’ve seen that there are at least three coordinated types of attack happening in different dimensions: The developer ecosystem (React Native and friends), the store (Amazon’s app store and Cyanogen’s rumored successor), and the lightweight in-app marketplaces (Facebook and WeChat, so far). Google’s reactions to each of these threats so far have been… well, let’s just say they’re still on top. For now.

    Does that matter? Yes, for tech shops it does.

    If you think there’s any risk at all that Google might lose control of Android, then your best bet is to use a cross-platform framework, because it hedges your bet via improved portability.

    React Native, in other words. If it can survive the current storm aimed against Facebook — but it probably can, because it can always be spun off.
  • Why I quit Google is an interesting article about self-defeating “objective” promotion criteria at Google.
  • Steve Faulkner clarifies how the HTML/CSS DOM, which can be changed by, among others, the flexbox order property, isn’t reflected in the browser’s accessibility tree. This is a reaction to last time’s discussion about CSS variable use for table sorting.
  • Chris Coyier shows how to make notched boxes in kind-of Battlestar Galactica style. Nice.
  • Excellent article on dealing with huge collections of DOM nodes — think tables with 1,000 rows. Vanilla JavaScript remains by far the best option performance-wise. Also, don’t bother optimising your core JavaScript loops and stuff — instead, optimise DOM handling. Clear DOM subtrees through innerHTML. On the other hand, don’t destroy nodes you may need later on — re-building them is way more expensive than keeping them around in memory.
    And no, this is nothing new. Ten years ago I would have given the same advice. But it’s good to know that the old rules are still being supported by the current data.
  • Food for thought:

    I’m beginning to think JS may be bifurcating into two largely disjoint communities. The “sw engineers” comfortable with pre-deployment tool chains and the “explorers” who want "live programming" tools

    I’m not 100% sure what Allen means by live programmers, and when I wanted to ask them I hit on my own definition and tweeted that instead.
    I think that the big split in JavaScript land is between those who firmly keep their eyes on browsers as our development platforms, and those who want to abstract away browsers.
    And yes, I think the first group is right and the second one is wrong, and that the second one will run into problems due to not understanding the platforms it’s creating software for.
  • This article calls the front-end/back-end division an antipattern. While I disagree with that premise, most of the article treats how back-enders look down on front-enders, and why that attitude should end — which is something I agree with.

    Frontend engineers now solve the same kinds of problems as their backend counterparts, using the same kinds of solutions, and it is harmful to continue arbitrarily dividing us.

    To be clear, I’m not saying that we all need to be experts in everything. [...] While it is perfectly valid to dislike a particular technology, such as CSS, the industry's culture of contempt for frontend work feeds into the outdated divide between frontend and backend, and detracts from building fast-moving, competitive teams and companies.

    Such as CSS. Thar’s a problem I’ll have to get back to one of these days.
    Pointing out that front-end can be as complex as back-end, and doing so in a back-ender-friendly way, is a good idea. Still, the article manages to ignore browsers as a developer platform entirely, despite the fact that mentioning them would have made its point even stronger. But maybe back-enders don’t want to hear about browsers because they’re terrified of them.
  • According to Tobie Langel contributing to OSS has ROI roughly equal to using OSS. Twenty years ago large companies were leery of using it; now they're leery of contributing to open source. So we have to convince them.
  • Insights and data, baby! The StackOverflow developer survey and the Design Census have been released. These surveys always yield interesting data.
  • Seems like an awful place to work for the health-unconscious such as myself.
  • Chronicles of Crime is a board game that incorporates an app, VR, and QR codes. Apps and VR have been done before in board games — the wonderful Alchemists was the poster child for apps in games — but as far as I know nobody yet combined them (i.e. let the app do more than just show VR), and nobody yet added QR codes, which are supposed to be a dying technology.
  • Have a tip for the next Linkbait? Or a comment on this one? Let me know (or here or here).

Linkbait 38

Tue, 02/27/2018 - 6:16am

The missing links.

  • Elegant and simple solution by Mr. M. that shows breakpoint information during website development. So simple that it surprises me this isn’t being used widely yet.
    Emil Björklund adds a slight twist and a few notes.
  • VERY cute animated avatar. Simple, subtle, efficient animations FTW!
  • Excellent article about designing with grids. Not exactly a tutorial; more like a showcase of how to bring all those grid elements together to form a nice, and above all non-standard site design.
  • Lea has a new talk: an introduction to web development for CS students. It contains a JavaScript context quiz (I had only two errors), and highlights CSS Grid Garden, where you can learn grid, and a CSS Selector challenge with plates, bento boxes, apples, and more.
  • Good piece by Ronald Méndez on ALA about earning a seat at the table as a front-end engineer. His early steps mirror the ones I made about ten years earlier: the biggest change was me just sitting down with graphic designers to go over their work before showing it to clients. This worked amazingly, as Ronald also found.
    Anyway, worth a read if you feel under-appreciated as a web developer.
  • Stuart muses about collecting data, and shows that it’s possible to collect meaningful data without compromising individual users’ privacy. The trick is that users should lie. Not all the time, and not all the users, but you should ask a certain percentage of your users to lie.
    If, say, 10% of Chrome users say they use Firefox and 10% of Firefox users say they use Chrome, the aggregate browser use statistics remain roughly the same, but you cannot say with certainty which browser an individual is using.
  • Roman Koramov published a truly eye-opening use of CSS variables for making a sortable table. No JavaScript needed.
    Unfortunately, the technique causes accessibility issues because screen readers cannot follow CSS order — just DOM order. So they ignore the sorting.
    It seems to me we can invoke progressive enhancement for some problems. Table isn’t sorted? Pity; it works OK enough without being sorted. Patrick Lauke disagreed, but I feel he’s arguing strictly from a worst-case scenario.
    Anyway, make up your own mind — as long as you remember CSS variables are awesome.
  • Frank Chimero defines spaghetti toolchains. I wish I thought of that term.

    simply npm your webpack via grunt with vue babel or bower to react asdfjkl;lkdhgxdlciuhw

    [...] Last month, I had to install a package manager to install a package manager. That’s when I closed my laptop and slowly backed away from it. We’re a long way from the CSS Zen Garden where I started.

    If you go talk to a senior software developer, you’ll probably hear them complain about spaghetti code. [...] while I can’t identify spaghetti code as a designer, I sure as hell know about spaghetti workflows and spaghetti toolchains. It feels like we’re there now on the web.

  • Chris Coyier reacts to that article. He doesn’t exactly disagree, but points out that the web is a big place, and while some sites don’t need complexity, others do.

    Developers generally aren't asked to innovate on the business and product side. They build what they are told to, so they use their smarts to innovate on their own tools.

    And

    We talk about complexity, but it's all opt-in. A wonderfully useful (and simple) website of a decade ago remains wonderfully useful and simple. Fortunately for all involved, the web, thus far, has taken compatibility quite seriously. Old websites don't just break.

    What I’m afraid of, though, is that today a simple website is regarded as a sub-optimal solution. A website has to opt into everything the web has to offer, or ... well, I’m not sure why, but there must be a huge downside to not making it complex.
  • An inside look at Facebook in the 2016 campaign, and more in general the way it sells ads, with controversial ads getting a discount.

    The Trump and Clinton campaigns bid ruthlessly for the same online real estate in front of the same swing-state voters. But because Trump used provocative content to stoke social media buzz, and he was better able to drive likes, comments, and shares than Clinton, his bids received a boost from Facebook’s click model, effectively winning him more media for less money.

    No Russians necessary. The Russian involvement existed, but it was hyped up by the tech caste in order to show that technology was still magic, and was gratefully accepted by “moderate” right-wing voters wishing to be absolved from Trump — and possibly hardcore Clinton supporters wanting to shift blame away from her.
    As Matt Yglesias said:

    Given that Trump’s strongest support is among the least-online generation we should be a little skeptical of attributing anything to digital wizardry.

  • Jeremy continues last week’s AMP discussion with the fundamental question: should we countenance companies’ power over the web, even if they mostly use their power for good?

    One of my greatest fears for the web is that building it becomes the domain of a professional priesthood. Anything that raises the bar to writing some HTML or CSS makes me very worried. Usually it’s toolchains that make things more complex, but in this case the barrier to entry is being brought right into the browser itself.

    [...] some CSS will be off-limits until they meet the entry requirements of HTTPS …even though CSS and HTTPS have literally nothing to do with one another. [...]

    No doubt Mozilla (and the W3C Technical Architecture Group) believe that they are doing the right thing. [...] They believe that, in this particular case, the ends justify the means.

    I strongly disagree.

  • Interesting examples of AR by Luke Wroblewski.
  • Samsung puts on its first own web conference, Samsung Create. I approve of browser makers setting up their own conferences. It makes the engineers accessible to web developers, and allows both sides to find out what the other is thinking. Also, I approve of more browser vendors, since it helps diversity. Pity the conference is in San Francisco; let’s hope for a European edition. Also a pity there’s not much more information yet.
  • And Tomi gives us the definitive 2017 smartphone stats.
    1. Samsung
    2. BBK
    3. Apple
    WTF is BBK? Read the article; was new for me, too.
  • Have a tip for the next Linkbait? Or a comment on this one? Let me know (or here or here).
©2003 - Present Akamai Design & Development.