While I’d rather this feature not exist, it’s not as dangerous as it might sound. The Topics API does not give advertisers any powers they don’t currently have with third-party cookies.
Normal users who don’t modify their browser settings will be tracked the same amount as before.
Expert users who already configured blocking of third-party cookies now have to remember to turn off one more setting in chrome://settings/adPrivacy. It’s merely an annoyance.
You might assume that Chrome sends to advertisers topics derived from your entire browsing history, but it does not. Chrome sends only topics derived from your history on pages that used that advertiser. So if a user with default settings visits a porn website with its own ad network, then visits a blog that uses Google Ads, Chrome will (still) not tell Google Ads that that user is interested in porn.
The biggest risk of this change is that it makes it easier for Google to later remove the Chrome setting that allows the user to not send topics. Would they really do that? Even today, Chrome supports blocking of third-party cookies both natively at chrome://settings/cookies and using browser extensions. Then again, Google is in the process of crippling Chrome extensions’ ad-blocking capabilities with Chrome Extension Manifest V3, so they have shown a desire to reduce the browser’s privacy protections when they think they can get away with it.
The page you linked recommends using the higher-level font-variant or font-variant-* properties instead of font-feature-settings. In this case, the appropriate property is font-variant-numeric:
Oven will provide incredibly fast serverless hosting & continuous integration for backend & frontend JavaScript apps — and it will be powered by Bun.
…
The plan is to run our own servers on the edge in datacenters around the world. Oven will leverage end-to-end integration of the entire JavaScript stack (down to the hardware) to make new things possible.
As far as I can tell, Bun tooling is to Oven as Deno tooling is to Deno Deploy: a free platform that advertises a paid service.
Hmm. I think serverless in the heroku sense is great (you provide code, and they worry about deployment, logs, servers, backups, etc), but serverless in the lambda or cloudflare workers sense has been kind of a flop for everything but glue code and hacks.
I don’t write a ton of go but I feel like using [os.DirFS] to open the uploadsDirectory beforehand would be less error prone than cleaning the path each time?
The order of object members in an I-JSON message does not change the meaning of an I-JSON message. A receiving implementation MAY treat two I-JSON messages as equivalent if they differ only in the order of the object members.
Otherwise it’s not bad at all. (Limited integer range notwithstanding…) I mean, considering. If you have to deal with JSON, this helps.
I see the contradiction. Despite the first quoted sentence, the second quoted sentence permits an implementation where the “order of object members in an I-JSON message” does “change the meaning of an I-JSON message”. The second sentence would be consistent with the first sentence if it said “MUST” instead of “MAY”.
Yes, if the whole site is RTL, then the individual inputs are RTL as well. The recommendation to set dir="auto" is aimed at authors of LTR websites with some users who write in RTL languages, or, conversely, authors of RTL websites with LTR users.
For example, a site for managing a library of books might have its navigation and documentation written in LTR English, but might accept book titles in RTL Arabic. If the field to enter a book title is just an <input>, the typed Arabic book title will be LTR in the input field. <input dir="auto"> allows the field to display either English or Arabic book titles with correct directionality.
Even if the site shows text with the correct directionality in the input field, it would still need to show the rendered book title correctly everywhere else it is used (such as an h1 or a li). I don’t know much about what, if any, extra work is needed for most usages. The one thing I know is that when quoting an arbitrary book title in the same sentence as LTR text, the site should use the <bdi> element, but I think most sites insert user content in their own block elements, where <bdi> is unnecessary.
I’m confused. Why is that not the default? Do web browsers for people configured to use RTL languages really default to LTR text input?
I honestly don’t know how people in these locales use computers. I had fun recently when someone from Israel sent me a PowerPoint template. First, it turns out the PowerPoint hides the button to toggle the writing direction unless you have both RTL and LTR locales installed (so I couldn’t change it without installing extra system-wide components but they could). Then it turned out that the keyboard shortcuts for text navigation actually did work but they moved the visual indicator to the wrong end until you started typing (and then it flickered between the two locations). And that’s in one of the flagship applications from the dominant desktop OS vendor, I have no idea how much worse it is in more niche things.
If I worked on mass-market GUI applications I think that I’d live in perpetual fear of some nice folks from Mossad dropping by for a friendly 3am chat.
To solve this problem, that spec would need a rule that the directionality of text-type input elements whose dir attribute is not in a defined state should use the algorithm for dir="auto".
I don’t know why the spec has no such rule. The spec already says the directionality of <input type="telephone"> will default to LTR even on RTL pages, so some edge cases were considered. Perhaps when the spec was written, there were concerns about performance of scanning each string for a directionality-indicating character?
Firefox is enormously configurable, so I expected to see a toggle somewhere in about.config, but there doesn’t seem to be an option to do this exactly.
Other terminal file managers include nnn and ranger. Their user interfaces are more complex, but they have more features. They, too, can be configured to cd on exit (nnn’s docs, ranger examples 1 and 2).
Medium has always handled sites with their own domains with this crazy redirect path. I don’t know why but I suspect it’s so they can cookie you on their main domain before you read on the custom domain.
IMO the point of a config format is that it is language neutral. One of the reasons JSON won over XML was the simplicity of the type system as values are easy to coerce regardless of the language processing the results.
A gradually typed config format would let the functional programmers specify heterohomogenously typed lists without ignoring the needs of the vast majority of its potential user base.
…Or just have primitives for Tuples if you want short heterogeneous lists, or using ADTs to cover the variants makes sense. I don’t mind forcing software makers to think smartly about their choice of types rather than willy-nilly ∀ stuff. List stuff. Even with good design, the reason we end up with heterogeneous lists is because there’s a lack of good primitives so you have to create JSON like [{ "foo": {…} }, { "bar": {…} }] with type List 🤷 instead of what you mean data T = Foo … | Bar … & type List T.
One thing that Nickel lacks as far as I know is support for env variable. I quite like having a default value coming from the environment defined in dhall.
I asked about this in their community this week. I understand that it’s great to not have side effects, but this is a useful one. I used a Bash solution (heredoc importing my file, then merge in env var as a string). They mentioned a possible future solution of allowing an argument you can pass into the CLI.
Wouldn’t that just be an env variable? It seems like a dumb pendantic argument to reject env because some labels it a side effect. Not supporting a nearly universal need will certainly cripple uptake.
Isn’t that what a config is for, state? env seems to be the concensus on how to handle runtime specific variables. How is that different than parameters passed via the command line arguments?
Arguments are passed once on init instead of retrieving a value at runtime where values can change in the middle of execution leading to results that ruin the reproducibility. It may be a more annoying than export FOO="bar" since often you set it without intent of changing, but it makes sense to limit the side effects.
Oh, I totally agree with that! I guess I just assumed env variables would be immutable. But I can see non-functional programmers making such variables mutable by default.
This is just a general tip for ASCII art diagrams in general and not specific to the OP, but it’s much easier to edit and maintain diagrams if you can go into a mode in your text editor where when you type it overwrites the existing characters in the buffer, instead of inserting them (which is a big headache in ASCII art because it shifts everything to the right and you’re constantly needing to delete).
In vim this is typing R in normal mode to enter Replace mode. Emacs has a similar ASCII-art mode IIRC.
It’s at least a decade old, but there is JavE Java Ascii Versatile Editor, which is a paint-like editor for ASCII art with brushes, fill, rectangles, everything.
I don’t think it makes sense for the Content field to have size “8b min.”. That prevents this format from describing the deletion of all the data. If the Content field could have size 0 bits, one could describe deletion of all the data with this single subdiff:
Difference Type: Overwrite
Index: one 7-bit chainlet that is all 0s, evaluating to a 0 index
Difference End: a chain evaluating to the index of the last byte in the original data
Content: empty; 0 bits
I’m assuming that the first subdiff’s index is relative to the start of the data. It would be nice to make that explicit.
I’m not surprised that they would largely ignore the work that’s gone into tiling window managers elsewhere over the last 20 years, but I am surprised that there’s no mention of paper wm, a popular tiling extension (with some novel ideas) for today’s gnome, because it’s right in their wheelhouse.
PaperWM is extremely creative, and I agree that it should have gotten more recognition. It’s very good at solving window positioning on a single screen, especially on a fairly small laptop screen. I don’t actually use it, because the actual implementation is a bit hacky (not their fault; comes mostly from having to keep up with Gnome releases), and it doesn’t really handle multiple screens very well.
When I use Gnome, I’m pretty much always using the PopShell extension. It does very basic, conventional auto-tiling (spiral), but it’s very well integrated with mouse use and fully controllable and discoverable through the GUI. That’s kind of essential for easing new users into tiling.
yeah, not to say raku isn’t a great language too, but ruby has a significant perl/bash influence (in fact in the early perl6 days one of the perl regulars used to joke about a “ruby-o-meter” that kept increasing as perl6 added rubyish features)
Doesn’t the article say that GitHub considered hijacking the search hotkey, but decided to use the browser’s native search in the end? What’s wrong with their current solution?
Is it just me, or was the first example hard to understand because of poor naming rather than cleverness? While understanding it, I mentally renamed over half of the identifiers and ended up with something that I am pretty sure I’d have understood from the start (in spite of having less JavaScript experience than a junior engineer working on a JavaScript project).
It’s fairly contrived example because you get in an object that might have the attributes Component and prop and then you output an object that might have the same attributes, so the whole function should just be const identity = (input) => output;. The only work it does is to turn null, 0, and false values into undefined values, but that’s unlikely to be a useful transformation.
the whole function should just be const identity = (input) => output;
The function does more useful work than that. The response parameter is not an object that might have the attributes Component and props; response is an Array, as shown by the use of square brackets in its destructuring. The whole function converts each of the first two array elements, if present, to a named field in the returned object, and it ignores any other array elements.
My bad. I noticed that at one point, but then I lost it as I was working through all the convolutions. Anyway, it’s still a sort of useless adaptor. const adapt = ([ Component, props]) => ({ Component, props }); is not quite the same, but close enough for most purposes.
I was first confused by ‘truthy’, which is used in a way that almost makes sense but implies (at least to me) a different meaning until I understood what it was doing (and then it was too late). Using single letter identifiers was not great, and key and value are not really informative as names here even when expanded.
“Truthy” is the standard term for values that activate the true branch of an if test in JavaScript. In JavaScript, objects and numbers besides 0 are truthy. In Python, an empty list is not truthy but in JavaScript, an empty Array is truthy. It’s just one of those things you learn about a dynamically typed language.
I agree – the first example was not a good formulation of the “clever”, generic solution. It could be expressed much more simply by calling filter on the entries instead of defining an inline function assignIfValueTruthy:
I still agree with the article that its rewritten version with more duplication is better, but the decision is closer.
Edit:gcmeplz on Hacker News suggests an even simpler “clever” alternative. It inlines variables and uses _.pickBy from the Lodash library, which many projects already depend on:
Is it possible to use IDEs like IDEA with Mill?
Theoretically yes, via BSP, but I haven’t tried it:
https://www.jetbrains.com/help/idea/bsp-support.html
Mill Documentation – IDE Support says yes.
Why am I passing x and y to that rectangle at all? They’re never used.
The “
// Getters omitted” line implies there will be agetX()andgetY()that readxandy.While I’d rather this feature not exist, it’s not as dangerous as it might sound. The Topics API does not give advertisers any powers they don’t currently have with third-party cookies.
You might assume that Chrome sends to advertisers topics derived from your entire browsing history, but it does not. Chrome sends only topics derived from your history on pages that used that advertiser. So if a user with default settings visits a porn website with its own ad network, then visits a blog that uses Google Ads, Chrome will (still) not tell Google Ads that that user is interested in porn.
The biggest risk of this change is that it makes it easier for Google to later remove the Chrome setting that allows the user to not send topics. Would they really do that? Even today, Chrome supports blocking of third-party cookies both natively at chrome://settings/cookies and using browser extensions. Then again, Google is in the process of crippling Chrome extensions’ ad-blocking capabilities with Chrome Extension Manifest V3, so they have shown a desire to reduce the browser’s privacy protections when they think they can get away with it.
Tabular figures are can also be accessed on the web with the CSS property value
font-feature-settings: 'tnum'.The page you linked recommends using the higher-level
font-variantorfont-variant-*properties instead offont-feature-settings. In this case, the appropriate property isfont-variant-numeric:Also
font-variant-numeric: tabular-numsWhat‘s their (planned) business model?
Per https://oven.sh/:
As far as I can tell, Bun tooling is to Oven as Deno tooling is to Deno Deploy: a free platform that advertises a paid service.
Hmm. I think serverless in the heroku sense is great (you provide code, and they worry about deployment, logs, servers, backups, etc), but serverless in the lambda or cloudflare workers sense has been kind of a flop for everything but glue code and hacks.
I don’t write a ton of go but I feel like using [
os.DirFS] to open theuploadsDirectorybeforehand would be less error prone than cleaning the path each time?Your comment’s link is missing:
os.DirFSIt’s self-contradictory re map key ordering:
Otherwise it’s not bad at all. (Limited integer range notwithstanding…) I mean, considering. If you have to deal with JSON, this helps.
I don’t see any contradiction here
I see the contradiction. Despite the first quoted sentence, the second quoted sentence permits an implementation where the “order of object members in an I-JSON message” does “change the meaning of an I-JSON message”. The second sentence would be consistent with the first sentence if it said “MUST” instead of “MAY”.
I’m using, e.g.:
All elements seem totally fine for RTL? If I add
dir="auto"to an<input>field, it makes it LTR again. What am I missing?Edit: I was surprised how easy it was to fix this, but of course it wouldn’t be the first time that the easy solution is the wrong solution.
Yes, if the whole site is RTL, then the individual inputs are RTL as well. The recommendation to set
dir="auto"is aimed at authors of LTR websites with some users who write in RTL languages, or, conversely, authors of RTL websites with LTR users.For example, a site for managing a library of books might have its navigation and documentation written in LTR English, but might accept book titles in RTL Arabic. If the field to enter a book title is just an
<input>, the typed Arabic book title will be LTR in theinputfield.<input dir="auto">allows the field to display either English or Arabic book titles with correct directionality.Even if the site shows text with the correct directionality in the
inputfield, it would still need to show the rendered book title correctly everywhere else it is used (such as anh1or ali). I don’t know much about what, if any, extra work is needed for most usages. The one thing I know is that when quoting an arbitrary book title in the same sentence as LTR text, the site should use the<bdi>element, but I think most sites insert user content in their own block elements, where<bdi>is unnecessary.Thanks for the extensive explanation! Makes sense now :)
I’m confused. Why is that not the default? Do web browsers for people configured to use RTL languages really default to LTR text input?
I honestly don’t know how people in these locales use computers. I had fun recently when someone from Israel sent me a PowerPoint template. First, it turns out the PowerPoint hides the button to toggle the writing direction unless you have both RTL and LTR locales installed (so I couldn’t change it without installing extra system-wide components but they could). Then it turned out that the keyboard shortcuts for text navigation actually did work but they moved the visual indicator to the wrong end until you started typing (and then it flickered between the two locations). And that’s in one of the flagship applications from the dominant desktop OS vendor, I have no idea how much worse it is in more niche things.
If I worked on mass-market GUI applications I think that I’d live in perpetual fear of some nice folks from Mossad dropping by for a friendly 3am chat.
I can at least confirm that this browser behavior matches the HTML spec:
dirattribute inherits its parents directionality.htmlelement is LTR by default.To solve this problem, that spec would need a rule that the directionality of text-type
inputelements whosedirattribute is not in a defined state should use the algorithm fordir="auto".I don’t know why the spec has no such rule. The spec already says the directionality of
<input type="telephone">will default to LTR even on RTL pages, so some edge cases were considered. Perhaps when the spec was written, there were concerns about performance of scanning each string for a directionality-indicating character?Firefox is enormously configurable, so I expected to see a toggle somewhere in about.config, but there doesn’t seem to be an option to do this exactly.
Other terminal file managers include nnn and ranger. Their user interfaces are more complex, but they have more features. They, too, can be configured to
cdon exit (nnn’s docs, ranger examples 1 and 2).Two more for the list:
Links: broot, xplr
Shameless plug for Elvish (https://elv.sh), a shell with a built in file system navigation UI (it’s demo 5 on the homepage).
Any one else getting errors with Skip Redirect add-on installed? Why are we going thru medium.com?
Medium has always handled sites with their own domains with this crazy redirect path. I don’t know why but I suspect it’s so they can cookie you on their main domain before you read on the custom domain.
Well, I never got to read it because the writer chose Medium over hosting a blog themselves
I recommend the https://scribe.rip/ front-end, which can proxy any Medium-powered article. https://scribe.rip/software-component-names-should-be-whimsical-and-cryptic-ca260b013de0 loads fine for me even with cookies cleared and JavaScript disabled.
Dhall is great. I think Nickel might be a better sell tho.
About Nickel: home page, README.md > Comparison, Comparison with alternatives
Dhall doesn’t support lists with mixed types? That’s insane, especially for a language trying to compete with JSON.
In functional languages heterogeneous lists are not the norm. Competing with a format doesn’t imply compatibility with its ideas.
IMO the point of a config format is that it is language neutral. One of the reasons JSON won over XML was the simplicity of the type system as values are easy to coerce regardless of the language processing the results.
A gradually typed config format would let the functional programmers specify
heterohomogenously typed lists without ignoring the needs of the vast majority of its potential user base.…Or just have primitives for Tuples if you want short heterogeneous lists, or using ADTs to cover the variants makes sense. I don’t mind forcing software makers to think smartly about their choice of types rather than willy-nilly
∀ stuff. List stuff. Even with good design, the reason we end up with heterogeneous lists is because there’s a lack of good primitives so you have to create JSON like[{ "foo": {…} }, { "bar": {…} }]with typeList 🤷instead of what you meandata T = Foo … | Bar …& typeList T.OMG I’m so embarrassed I posted that. I’ve been doing web programming for too long and the brain rot is near terminal apparently :P
One thing that Nickel lacks as far as I know is support for env variable. I quite like having a default value coming from the environment defined in dhall.
I asked about this in their community this week. I understand that it’s great to not have side effects, but this is a useful one. I used a Bash solution (heredoc importing my file, then merge in env var as a string). They mentioned a possible future solution of allowing an argument you can pass into the CLI.
Wouldn’t that just be an
envvariable? It seems like a dumb pendantic argument to rejectenvbecause some labels it a side effect. Not supporting a nearly universal need will certainly cripple uptake.Reaching out to stateful environment variables ruins reproducibility & caching. It makes sense as a design decision even if it is inconvenient.
Isn’t that what a config is for, state?
envseems to be the concensus on how to handle runtime specific variables. How is that different than parameters passed via the command line arguments?Arguments are passed once on init instead of retrieving a value at runtime where values can change in the middle of execution leading to results that ruin the reproducibility. It may be a more annoying than
export FOO="bar"since often you set it without intent of changing, but it makes sense to limit the side effects.Oh, I totally agree with that! I guess I just assumed
envvariables would be immutable. But I can see non-functional programmers making such variables mutable by default.We prefer to call them “dysfunctional programmers”
This is just a general tip for ASCII art diagrams in general and not specific to the OP, but it’s much easier to edit and maintain diagrams if you can go into a mode in your text editor where when you type it overwrites the existing characters in the buffer, instead of inserting them (which is a big headache in ASCII art because it shifts everything to the right and you’re constantly needing to delete).
In vim this is typing
Rin normal mode to enter Replace mode. Emacs has a similar ASCII-art mode IIRC.It’s at least a decade old, but there is JavE Java Ascii Versatile Editor, which is a paint-like editor for ASCII art with brushes, fill, rectangles, everything.
Well if you’re already in vim there’s also a script to draw these with arrow keys: https://www.vim.org/scripts/script.php?script_id=40
Looks like we lobster-clawed the server
Can you share the script here?
The link works fine for me now. There’s also a mirror of that script at https://github.com/vim-scripts/drawit.
The vim-scripts GitHub organization mirrors – or rather, used to mirror – every script on https://www.vim.org/scripts/. It’s handy not just when vim.org shows errors but also when you want to install a package using a Git-based Vim plugin manager such as vim-plug.
I don’t think it makes sense for the Content field to have size “8b min.”. That prevents this format from describing the deletion of all the data. If the Content field could have size 0 bits, one could describe deletion of all the data with this single subdiff:
I’m assuming that the first subdiff’s index is relative to the start of the data. It would be nice to make that explicit.
ty for da note! i fixed it:
replaced difference end with content length. now you can make the content length 0 to denote full deletionEDIT: i removed content length and specified that the content is a nullable chain
I’m not surprised that they would largely ignore the work that’s gone into tiling window managers elsewhere over the last 20 years, but I am surprised that there’s no mention of paper wm, a popular tiling extension (with some novel ideas) for today’s gnome, because it’s right in their wheelhouse.
PaperWM is extremely creative, and I agree that it should have gotten more recognition. It’s very good at solving window positioning on a single screen, especially on a fairly small laptop screen. I don’t actually use it, because the actual implementation is a bit hacky (not their fault; comes mostly from having to keep up with Gnome releases), and it doesn’t really handle multiple screens very well.
When I use Gnome, I’m pretty much always using the PopShell extension. It does very basic, conventional auto-tiling (spiral), but it’s very well integrated with mouse use and fully controllable and discoverable through the GUI. That’s kind of essential for easing new users into tiling.
Link: PaperWM. As the screenshots in the Usage docs show, PaperWM’s window management and navigation is based around the three following concepts:
Typos I noticed that you may want to fix:
These languages had similar features before Raku:
qwsyntax. The “qw” stands for “quoted words”.qw(foo bar baz)is equivalent to("foo", "bar", "baz")%wand%Wstring-array literals.%w[foo bar baz]is equivalent to["foo", "bar", "baz"]%W[foo #{"bar" * 3} baz]is equivalent to["foo", "barbarbar", "baz"]Elixir also has
~w(unquoted words)I believeI forgot to highlight in the latest Oils release notes that we changed the syntax to
There is a rough analogy to
:symbolwhich is like an unquoted/interned string in Ruby, Elixir, Clojure.It used to be
%( unquoted words )in Oils, but I felt that was too similar toThose forms have full commands in them, not just words.
The old syntax is still valid, and I will remove it at some point …
Yep, it does. I came here to mention elixir ~w(…)
It also has my favorite multiple dispatch system and can be used with no imports.
which did make me wonder how much of a try they gave ruby before dismissing it as too python-like
Honestly, not too much. Not enough to discover ~w. I’m sorry, Ruby
yeah, not to say raku isn’t a great language too, but ruby has a significant perl/bash influence (in fact in the early perl6 days one of the perl regulars used to joke about a “ruby-o-meter” that kept increasing as perl6 added rubyish features)
i hate when github hijack my firefox search functionality. and moreover when it doesn’t do it consistently.
Doesn’t the article say that GitHub considered hijacking the search hotkey, but decided to use the browser’s native search in the end? What’s wrong with their current solution?
Do they still do it for you? They very recently stopped doing it for me in the non-edit view (even when logged in).
They also fixed the mismatched tab width issue I had with the new view, so I might have been reverted to the old view.
They broke ctrl-clicking links in source repos as part of this too. Gotta love it.
See also the similar project
rush, which was last updated in 2012.Is it just me, or was the first example hard to understand because of poor naming rather than cleverness? While understanding it, I mentally renamed over half of the identifiers and ended up with something that I am pretty sure I’d have understood from the start (in spite of having less JavaScript experience than a junior engineer working on a JavaScript project).
Do you mean this example? The names in it are totally normal, k for key, v for value, o for object.
It’s fairly contrived example because you get in an object that might have the attributes Component and prop and then you output an object that might have the same attributes, so the whole function should just be
const identity = (input) => output;. The only work it does is to turnnull,0, andfalsevalues intoundefinedvalues, but that’s unlikely to be a useful transformation.The function does more useful work than that. The
responseparameter is not an object that might have the attributesComponentandprops;responseis anArray, as shown by the use of square brackets in its destructuring. The whole function converts each of the first two array elements, if present, to a named field in the returned object, and it ignores any other array elements.My bad. I noticed that at one point, but then I lost it as I was working through all the convolutions. Anyway, it’s still a sort of useless adaptor.
const adapt = ([ Component, props]) => ({ Component, props });is not quite the same, but close enough for most purposes.I was first confused by ‘truthy’, which is used in a way that almost makes sense but implies (at least to me) a different meaning until I understood what it was doing (and then it was too late). Using single letter identifiers was not great, and key and value are not really informative as names here even when expanded.
“Truthy” is the standard term for values that activate the true branch of an if test in JavaScript. In JavaScript, objects and numbers besides 0 are truthy. In Python, an empty list is not truthy but in JavaScript, an empty Array is truthy. It’s just one of those things you learn about a dynamically typed language.
I agree – the first example was not a good formulation of the “clever”, generic solution. It could be expressed much more simply by calling
filteron the entries instead of defining an inline functionassignIfValueTruthy:I still agree with the article that its rewritten version with more duplication is better, but the decision is closer.
Edit: gcmeplz on Hacker News suggests an even simpler “clever” alternative. It inlines variables and uses
_.pickByfrom the Lodash library, which many projects already depend on: