skip to main content

Posts tagged “code”

  1. Simplicity (II)
    bastianallgeier.com

    Bastian Allgeier:

    I have a simple rule of thumb when it comes to programming:

    less code === less potential issues

    This rule of thumb controls my own feelings towards a solution. It shouldn’t take 120 MB of code to uglify some JS. But maybe I’m wrong.

    In practice, this dependency hell has bitten me so often already that my life expectancy probably sank by 2-3 years. You want to build a JS file? Please update Webpack first. Oh, that new version of Webpack is no longer compatible with your Node version. Oh, your new Node version is no longer compatible with that other dependency. Oh, now you have 233 detected security issues in all your node_modules but you can’t fix them because that would break something completely unrelated.

  2. 5G Will Definitely Make the Web Slower, Maybe
    filamentgroup.com

    Scott Jehl:

    Faster networks should fix our performance problems, but so far, they have had an interesting if unintentional impact on the web. This is because historically, faster network speed has enabled developers to deliver more code to users—in particular, more JavaScript code.

    Ugh. Jeremy Keith comments:

    The longer I spend in this field, the more convinced I am that web performance is not a technical problem; it’s a people problem.

  3. The Myth of the Pixel Perfect Grid
    shkspr.mobi

    Terence Eden explains how different screen technologies, human biology, and fingerprint grease make “pixel perfection” a pointless goal:

    There is no grid. There never has been. You can align to theoretical pixels - but as soon as the image hits a physical screen, it will be adjusted to best fit reality.

    An obsession with pixel perfect rendering is futile.

    Every Layout expands on this idea, specifically as it pertains to CSS:

    Suffice it to say that, while screens are indeed made up of pixels, pixels are not regular, immutable, or constant. A 400px box viewed by a user browsing zoomed in is simply not 400px in CSS pixels. It may not have been 400px in device pixels even before they activated zoom.

    See also: Ian Mallett’s Subpixel Zoo: A Catalog of Subpixel Geometry.

  4. Styling Links with Real Underlines
    css-tricks.com

    Ollie Williams welcomes the new CSS properties for styling underlines:

    Finally we can demarcate links without sacrificing style thanks to two new CSS properties.

    • text-underline-offset controls the position of the underline.
    • text-decoration-thickness controls the thickness of underlines, as well as overlines, and line-throughs.

    I’ve been working on a blog post about this topic, and Ollie does a good job of covering some of the points I want to make. But I want to go further and explore implementation quirks, the details where the new properties don’t quite go far enough, and make a case for why underlines shouldn’t be pixel-aligned.

  5. Introducing caniemail.com
    caniemail.com

    Rémi Parmentier:

    Last march, I wrote a proposal for Can I email, a website similar to caniuse.com dedicated to support in email clients.

    Today, barely six months after, I am really happy and pleased to announce that with the help of my colleagues and members of the email geeks community, we’re officially launching caniemail.com.

    Wow, this was sorely needed.

  6. Less Data Doesn’t Mean a Lesser Experience
    timkadlec.com

    Tim Kadlec explores strategies for dealing with the Save-Data header without degrading the experience, because not every user that enables it will be aware of the potential consequences:

    The possibilities are endless. If you treat data as a constraint in your design and development process, you’ll likely be able to brainstorm a large number of different ways to keep data usage to a minimum while still providing an excellent experience. Doing less doesn’t mean it has to feel broken.

  7. What I Like About Eleventy
    daverupert.com

    Dave Rupert is, like me, a longtime Jekyll user. He’s trying out Eleventy — which I’m super curious about — and getting good results. The massive performance difference when compared to Jekyll is very compelling to me, but so is the flexibility to write little bits of code to extend functionality without much fuss:

    On the Cathedral vs. Bazaar spectrum, Eleventy operates more on the bazaar end. By that I mean it doesn’t prescribe much. You want a bunch of filters? Write your own, Eleventy only comes with two. You want multiple layouts? Write a bit of JS to get those registered. Did you remember to setup an .eleventyignore? Even the Sass and JS pipelines are BYO.

  8. IndieWeb Link Sharing
    mxb.dev

    Max Böck:

    Posting a new short “note” on my site currently requires me to commit a new markdown file to the repository on Github. That’s doable (for a developer), but not really convenient, especially when you’re on the go and just want to share a quick link.

    It me.

    The new link sharing basically has three main parts:

    • a small Javascript bookmarklet to act as a “share button”
    • a form that collects and sends the shared link data, and
    • a serverless function to process it and create a new file.

    Gotta get on this train! I’m already working on it, though my solution will be based on the Micropub spec. But that live preview is sweet and now I want it too.

  9. Ooops, I guess we’re full-stack developers now.
    full-stack.netlify.com

    Chris Coyier’s latest talk puts all the complexity of modern front-end development in perspective:

    All the very huge responsibilities front-end developers already have:

    • Pulling of the design
    • Making the design part of a system
    • Making sure it is accessible
    • Worrying about the performance
    • Testing things across browsers
    • Testing things across devices
    • Sweating the UX

    Oh hello, big pile of new responsibilities

    • Component-driven design, designing our own abstractions
    • Site-level architecture
    • Routing
    • Fetching our own data
    • Talking to APIs
    • Mutating data
    • State management

    Oof.

  10. Intrinsically Responsive CSS Grid with minmax() and min()
    evanminto.com

    Evan Minto:

    min() accepts one or more values and returns the smallest value. The magic of the function is that, just like calc(), the arguments can use different units, which allows us to return values that change dynamically based on context.

    min() is one of three new comparison functions introduced as part of the CSS Values and Units Module Level 4. There’s also max(), which naturally does the inverse of min(). Finally clamp() is a convenience function that applies both a minimum and a maximum to a single value.

    This is brilliant and I can’t wait until I can change my @supports queries from display: grid to min().

  11. What I Like About Vue
    daverupert.com

    Dave Rupert:

    Upgrading legacy applications was one of the usecases Vue was designed around. It means that developers can piecemeal upgrade bits of an application as necessary.

    In my experience Angular, React, and a lot of other frameworks ultimately require you to go all in early and establish a large toolchain around these frameworks. Angular prescribes a lot with its amazing CLI. React on the other hand doesn’t prescribe anything, but requires you to self-assemble and wield a somewhat complex toolchain. But as Evan put it in his JSConf Asia talk, Vue sits in the middle of the “Cathedral and the Bazaar”. Vue has useful tooling, but it’s all optional and you can use only what you need. In some ways, Vue’s grafting capabilities really does make it seem like a jQuery replacement you can drop in to give your components superpowers as needed.