Tagged “javascript”

Bookmark

Newsletters, by Robin Rendle

A fantastic so-called “Scroll Story” from Robin Rendle. In his own words it’s “an elaborate blog post where I rant about a thing” however given the beautiful typography, layout and illustrations on show I think he’s selling it a little short!

Read my notes / Visit original

Entry

Sets in JavaScript

I don’t often store things in a Set in JavaScript, but maybe I should. The fact it will only store unique values makes it pretty handy.

Read entry »

Entry

How to manage JavaScript Dependencies

It can pay to add tried-and-tested functionality to your application via third-party NPM packages. That way, you can concentrate on your application’s unique features rather than reinventing the wheel for lower-level requirements.

  • https://classic.yarnpkg.com/en/docs/yarn-workflow/
  • And here’s a good explanation of the purpose of lock files (it’s to lock down the exact version to be used (rather than a range like package.json) https://www.robertcooper.me/how-yarn-lock-files-work-and-upgrading-dependencies)
  • Getting started
    • If blank slate, yarn (or npm) init
    • If established project, “yarn” (or “npm i”)
  • Adding
    • yarn add <package…> (or …)
    • can add specific version or semver range, and it can be a good idea to do so, e.g. yarn add <package…>@^1.3.1
  • Removing
    • yarn remove <package…>
    • use this rather than manually deleting because this way it will update yarn.lock, too.
  • Updating
    • npm i (same command as to add/install)
    • yarn upgrade, or “yarn upgrade-interactive”
  • Maintaining
    • Security vulnerabilities

      • Note that this might be in:
        • a sub-dependency i.e. not one you explicitly installed.
        • a package which appears several times in your lock file / dependency tree
      • Often you need to upgrade to a patch version. (To minimise risk you usually want to update to update to the closest non-vulnerable version)
      • This may not require a change to package.json
      • Automated
        • Dependabot https://github.blog/2020-06-01-keep-all-your-packages-up-to-date-with-dependabot/
        • You can configure Github Dependabot to send automated security updates (NB this is not just for JS, i.e. in a Rails project it might suggest a bump to your Gemfile)
        • dependabot will often automatically open a PR in your repo, updating the relevant dependency (thus addressing the vulnerability) with PR title e.g. “Bump lodash from 4.17.11 to 4.17.19”
        • (note however that if you work on a (corporate) repo that is not set up to automatically open PRs, you can still often take advantage of this on each individual dependabot security alert, at the push of a button.
          • Hopefully you also get a round-up email for all affected repos “A new security advisory on lodash affects 8 of your repositories” with links to the alert for each repo
        • You generally just need to follow the link in the email then merge the PR and delete the branch from the PR page
      • Manual
        • Sometimes dependabot cannot automatically suggest a fix for you
          • Not sure why, but perhaps because:
            • your package A which depends on vulnerable package B hasn’t yet released an update which bumps its package B dependency to package’s B patch update
            • the required update requires moving to a version that is beyond that specified in your dependency settings
      • Case Study
        • dot-prop < 4.2.1 “Prototype pollution vulnerability in dot-prop npm package before versions 4.2.1 and 5.1.1 allows an attacker to add arbitrary properties to JavaScript language constructs such as objects.“
          • Affected repos including node-weather-app
            • dot-prop only appears in the package-lock.json; nowhere else.
            • It’s not a dependency that I explicitly installed so I’m guessing it’s a sub dependency of express, hbs, request or nodemon.
              • But checking in package-lock.json:
                • it‘s not under dependencies for any of those I listed above; it’s within the top level “dependencies” object.
                • interestingly it has “dev: true”
                • I think I’ve sussed it. The actual locked-down/installed version of each subdependency (no matter how deep) is listed in the top level “dependencies” section. It can also be found specified as a semver range by the higher-level dependency (say, nodemon) that requires it. But the top-level “dependencies” lists the actual installed version.
                  • So I was able to work backwards and find that dot-prop is required by configstore which is required by update-notifier which is required by nodemon.
                  • So nodemon would need updated. I then googled “nodemon dot-prop” and found https://github.com/remy/nodemon/issues/1682 and various argumentative PR threads!
                  • I looked at https://github.com/remy/nodemon/releases and ascertained that I need v2.0.3 (a new major version) but since the latest is just a patch version away (2.0.4) I’ll go for that.
                  • This is a major version update but it’s just a devDependency so I don’t really care.
                  • I checked package.json and changed devDependencies { "nodemon": "^1.19.4" } to "nodemon": "^2.0.4" then ran npm i nodemon to update. (Followed by npm audit fix)
                  • Then pushed, checked my Github repo security section and that alert (and a few others) disappeared! Job’s a goodun.
                  • PS in the real world I should have tested that nodemon and everything else still works.
              • So its difficult to know which of my top-level dependencies it is a sub-dependency of and therefore what to update.
              • I guess I could manually update the entry
    • Version updates (not just security vulnerabilities)

  • semver
  • Files
    • package.json; and yarn.lock or (package.lock or package-lock.json)
    • You don’t really want to be manually maintaining the lock files. And you don’t necessarily need to manually update package.json either, since you can use “yarn upgrade-interactive”
Bookmark

Cheating Entropy with Native Web Technologies (on Jim Nielsen’s Weblog)

This is why, over years of building for the web, I have learned that I can significantly cut down on the entropy my future self will have to face by authoring web projects in vanilla HTML, CSS, and JS. I like to ask myself questions like:

  • Could this be done with native ES modules instead of using a bundler?
  • Could I do this with DOM scripting instead of using a JS framework?
  • Could I author this in CSS instead of choosing a preprocessor?

Read my notes / Visit original

Bookmark

Introducing Rome

We’re excited to announce the first beta release and general availability of the Rome linter for JavaScript and TypeScript. This is the beginning of an entire suite of tools. Rome is not only a linter, but also a compiler, bundler, test runner, and more, for JavaScript, TypeScript, HTML, JSON, Markdown, and CSS. We aim to unify the entire frontend development toolchain.

Read my notes / Visit original

Bookmark

Three CSS Alternatives to JavaScript Navigation (on CSS-Tricks)

In general this is a decent article on non-JavaScript-based mobile navigation options, but what I found most interesting is the idea of having a separate page for your navigation menu (at the URL /menu, for example).

Who said navigation has to be in the header of every page? If your front end is extremely lightweight or if you have a long list of menu items to display in your navigation, the most practical method might be to create a separate page to list them all.

Read my notes / Visit original

Bookmark

Color Theme Switcher (on mxb.dev)

Max shows us how to build a colour theme switcher to let users customise your website. He uses a combination of Eleventy, JSON, Nunjucks with macros, a data attribute on the html element, CSS custom properties and a JavaScript based switcher.

Read my notes / Visit original

Bookmark

Debouncing vs. throttling with vanilla JS (on Go Make Things)

Chris explains how debouncing and throttling are two related but different techniques for improving performance and user experience when working with frequently invoked JavaScript event handlers.

With throttling, you run a function immediately, then wait a specified amount of time before running it again. Any additional attempts to run it before that time period is over are ignored.

With debouncing, after the relevant event fires a specified time period must pass uninterrupted in order for your function to run. When the time period has passed uninterrupted, that last attempt to run the function is the one that runs, with any previous attempts ignored.

Read my notes / Visit original

Bookmark

We’ve ruined the Web. Here’s how we fix it. (This is HCD podcast)

During the COVID situation, people have an urgent need to access critical information online. But in 2020, the average webpage is rammed full of large JavaScript files, huge images etc, and as a result is slow to load. This problem is likely to be most keenly felt by those who don’t have the luxury of fast internet – potentially the same people who need access to that critical information the most.

Here’s a brilliant discussion between Gerry McGovern and Jeremy Keith on that problem, suggesting tactics to help fix things such as performance budgets, introducing tactics at the design stage to mimic slow connections and other access constraints, optimising for return visits, progressive enhancement and more.

Read my notes / Visit original

Note · 10:10 AM · Glasgow

I have to reluctanctly agree on this one. I’ve interviewed quite a few candidates for “front-end developer” (or similarly named) positions over recent years and the recurring pattern is that they are strong on JavaScript (though not necessarily the right time to use it) and weak on HTML, CSS and the “bigger picture”.

Note · 2:11 PM · Glasgow

In the same vein as Jeremy Keith’s recent blog post, Hydration, which calls out some of the performance and user experience problems associated with current Server Side Rendering approaches, I think Jake Archibald is absolutely bang on the money here.

Bookmark

BBC GEL Inclusive Components Technical Guide

The BBC Global Experience Language (GEL) Technical Guides are a series of framework-agnostic, code-centric recommendations and examples for building GEL design patterns in websites. They illustrate how to create websites that comply with all BBC guidelines and industry best practice, giving special emphasis to accessibility.

Read my notes / Visit original

Bookmark

You Don't Need

A nice list of tips and tools on how to use simpler browser standards and APIs to avoid the added weight of unnecessary JavaScript and libraries.

Read my notes / Visit original

Bookmark

Hydration (Adactio: Journal)

The situation we have now is the worst of both worlds: server-side rendering followed by a tsunami of hydration. It has a whiff of progressive enhancement to it (because there’s a cosmetic separation of concerns) but it has none of the user benefits.

Read my notes / Visit original

Bookmark

When should you add the defer attribute to the script element? (on Go Make Things)

For many years I’ve placed script elements just before the closing body tag rather than in the <head>. Since a standard <script> element is render-blocking, the theory is that by putting it at the end of the document – after the main content of the page has loaded – it’s no longer blocking anything, and there’s no need to wrap it in a DOMContentLoaded event listener.

It turns out that my time-honoured default is OK, but there is a better approach.

Read my notes / Visit original

Bookmark

Modest JS Works

Pascal Laliberté has written a short, free, web-based book which advocates a modest and layered approach to using JavaScript.

I make the case for The JS Gradient, a principle whereby your app can have multiple coexisting modern JS approaches, starting from the global sprinkles to spot view-models to, yes, an SPA if that’s really necessary. At each point in the gradient, you’ll see when it’s a good idea to go a step further toward heavier JavaScript, or not.

Read my notes / Visit original

Entry

JavaScript Promises explained

A brief explainer (for future-me and anyone else it helps) on what promises are and how to use them. Note: this is not an _official_ definition, but rather something that works for me. #

In the normal run of things, JavaScript code is _synchronous_. When code line 1 has run (perhaps defining a new variable) and the operation has completed, code line 2 runs. However sometimes we need to do something which will take longer – maybe an unknown amount of time, for example an API call to a third party server – and we don’t want it

See all tags.

External Link Bookmark Note Entry Search