captbaritone

Rule author here. Would love to see some examples! I think the closest I’ve (knowingly) done to this is to add an empty else clause that contains a comment.

This is correct. The post is from 2022. New default rules are a breaking change and version 9, the first major relates since it was added, is coming soon and will include it by default.

This is the approach I take as well. But it's not necessarily best of both worlds. Removing (or not inserting) technically useless parens can obscure bugs if you are not perfectly fluent in the precedence rules of the language. Their doubly easy to miss if there's a lot going on on one line.

Here's one example that the rule caught: https://github.com/captbaritone/vscode/blob/ab86e0229d6b4d0c...

I've been writing JS for over 10 years now, and I'm not sure I would have caught that in code review.

Author of the post/rule here. I'd be very curious to see this rule ported/translated to Python! While the gotcha's would probably be different, I suspect it would uncover real bugs. One interesting challenge with JavaScript is that its so ubiquitous that _everyone_ ends up needing to write it at some point. Even those for whom it is a second or third language. I suspect this makes its gotchas all the more common to encounter. Conversely, it makes the value of tools to guide around those gotchas that much more valuable.

Author or the rule and post here. ESLint version 9, which is going to enable this rule as part of the set of "recommended" rules, is also removing all of the formatting rules. I'm pleased to see that. In the era of pretty printers (which ESLint predates) I think it makes sense to encourage linters to focus on correctness and other conventions aimed at improving code quality rather than just style.

Hey, author of the rule/post here. I'd encourage you to click through to the actual examples linked from the post. Seeing the issues in context, as opposed to the minimal example, can help show how quickly these issues can get lost. It might also be interesting to click "blame" on the line and look at it in the context of the PR that added it.

Overall, my point with the examples was to highlight that these are mistakes that even make their way into high visibility projects built by highly competent engineering teams.

That said, looking at the issues few were in really critical paths of these projects. Often they cropped up in auxiliary areas like test harnesses or more off-the-beaten-path features. One can assume the same bugs may have existed at some point in the development cycle in other areas of the code base, but they got caught by more rigorous testing/review of those areas, or bug reports. But it's surely a time saver to identify them _as the developer saves the file_ rather than later in the process. The sooner you catch the bug, the more engineering energy you save.

Author of the rule and post here. I reread the post this morning, and I agree that I should have been less definitive in that sentence. But I stand by the broader point: Useless code is generally not something developers intend to write. When we do, it's generally something exceptional, so a lint suppression is a reasonable way to clarify "I meant to do that". And in the common case where it was an error, the lint rule proves quite helpful.

I hope the take away for the reader is: If you can think of other rules that will detect useless code, you should pursue them, because they are likely more valuable than just enabling dead code elimination. They have a high probability of being able to uncover interesting bugs/mistakes as well, which is much more valuable.

Author of the rule and blog post here. I agree that, for me, I appreciate the extra clarity of explicit parens. This lead me to explore a VSCode plugin which visually show the implicit parens even if they are not present in the code: https://jordaneldredge.com/blog/a-vs-code-extension-to-comba...

I like the idea that different readers of the same code base could opt for differing levels of explicitness when it comes to operator precedence. One thing that working on the project helped demonstrate for me is that adding parens around _every_ subexpression is _way_ too noisy. So, you need to draw the line somewhere. But for me, I prefer drawing that line on the noisier side.

Author of the rule/post here. It's planned to be included in the set of recommend rules in version 9. https://eslint.org/blog/2023/11/whats-coming-in-eslint-9.0.0...

User defined themes place a meaningful restriction on how the UI can evolve. My theory is that as software has moved to the web, and thus a more iterative/continuous deployment model, this restriction has felt relatively more expensive to commit to.

Other discussion of this elsewhere in the thread: https://news.ycombinator.com/item?id=32865926

This is a custom UI I built to showcase the collection we started on the Internet Archive as part of that collaboration. The collection has grown considerably since that time, but it’s the same set of files.

My writeup of the Winamp Skin Museum can be found here if anyone wants to learn more: https://jordaneldredge.com/blog/winamp-skin-musuem/

The main challenge is CORS. For EQ/Balance/Visualization, Webamp needs access to the actual byte-stream which requires special permissions be granted in the HTTP headers by whoever is running the stream.

The Milkdrop Visualizer does use Wasm, but it's a custom in-browser compiler. You can read more here: https://jordaneldredge.com/blog/speeding-up-winamps-music-vi...

Drag and drop also works.

Blog post from when we did the integration: https://blog.archive.org/2018/10/02/dont-click-on-the-llama/

And classic skins! Just drag them in.

Hey! Author of the project here (not op). Happy to answer any questions. The code, and instructions for using it on your own site, can be found here on GitHub: https://github.com/captbaritone/webamp

We do have Dropbox support, but it’s currently disabled while we sort out some theoretical security concerns.

Specifically, we let you load Milkdrop visualizer plugins via a query param, but that involves arbitrary js execution. We have a solution that we've built and shipped, we just haven't yet disabled the old system.

More info on the Wasm compiler we built as part of that solution can be found at my blog: https://jordaneldredge.com/blog/speeding-up-winamps-music-vi...

Looks similar to Mermaid-js's Gantt chart support: https://mermaid-js.github.io/mermaid/#/gantt

Once nice thing about Mermaid is it's built into [GitHub's markdown](https://github.blog/2022-02-14-include-diagrams-markdown-fil...) and has support in Notion

The web audio api code is mostly in this directory: https://github.com/captbaritone/webamp/tree/master/packages/...

Webamp has been used to do something like this: https://winampify.io/

(Required paid Spotify account)

Me too!

Extracted config files are also useful for quickly testing/validating the various parsers that I had to write as part of the Webamp project.

Contains all the text content extracted from each skin. Readme text, config files, as well as metadata about how the skins performed on social media (likes/retweets from the @winampskins Twitter bot) and also NSFW stats (as reported by users and confirmed by me) and if the skin is approved by users in Discord to be tweeted by the bot.

All of these are used for search (text is indexed into Algolia) and ranking:

Most likes/retweets are shown first, then approved, then rejected. NSFW skins are deprioritized as well.

Correct

Speaking specifically about Webamp, it is a manual reimplementation in JavaScript. But we did use Wasm as a tool for the music visualizer: https://jordaneldredge.com/blog/speeding-up-winamps-music-vi...

Tweet author here (not op). I'll repost here:

The Winamp Skin Museum is powered by a sqlite3 database containing 1.2gb of metadata about 86,000 Winamp skins.

It's all exposed in this explorable GraphQL endpoint

https://api.webamp.org/graphql

A bit about the data...

It includes:

* Original filenames and md5 hashes of each skins

* Names/metadata of all files compressed WITHIN the skins (file size, date, filename)

* Text content of all text files found within the skins

* URL/likes/retweets if the skin was share by @winampskins (or on Instagram)

* Full metadata/info about each skin's @internetarchive page

* Info about manual reviews (good to tweet? NSFW?)

* URLs to download skin files or screenshots

Kind [of] fun data to comb though (if you're like me).

If anyone is interested in getting the raw DB to play with, or has ideas for extra stuff to expose in the graph, get in touch.

For anyone wanting to dip back into the nostalgia of Winamp and Milkdrop without installing any software, I made https://webamp.org for that exact purpose.

It can render real Milkdrop presets and real classic winamp skins directly in the browser.

Also, it’s open source: https://github.com/captbaritone/webamp

Author of the Skin Museum here. The Internet Archive search API supports JSONP, so you should (in theory) be able to use that to avoid the need for a CORs proxy.