The message it produces in a GitHub issue template is:

I tried to access the page at "/404.html", but landed on 404 page. Could you please look into this?

• Boosts conversion
• Tells more about the author

• the worst issues are those you don’t know how to reproduce
• it takes me about 30 failed workflows in average to figure out what’s wrong
• show the way to debug a remote CI machine using SSH
• advice to tarball a directory and send it over to local machine via scp

https://video.twimg.com/dm_gif/1223630017172774913/jvUQ8s9pJRkI0dZUaClvs0wrY7s9ghkZ7_uZMqtki1uNWZ7zXq.mp4

Configure Gatsby image queries to load proper quality of images.

Says "no matching files found" when staged content/posts/**/index.mdx. Doesn't validate posts for id on pre-push.

• Use optimized images
• Add image embedding support to post detail
• Fix code snippets highlighting in post detail
• Integrate MDX
• Integrate code snippets component with highlighting (Prisma?)
• Add ability to save article to bookmark
• Support adding to homepage (PWA)
• Add Google Analytics
• Add Privacy policy
• Add contact details
• Fix responsive layout of single post meta data (category, date)
• Add "You may also like" section after each post detail
• Add "/legacy-browser" page to discourage IE usage (website will be broken on IE)
• Fix favicon used for PWA on mobile devices - use rect icon instead of a cirle
• Share widget: Make more prominent

Content

• Migrate existing content
• Ensure proper og:image set for social sharing for pages and posts

Seems like a database entry issue.

• Do they have the same post ID?
• What does the database say?

• Explain how TS config actually works.
• Show examples of how you should be using multiple TS configs in a same project to have correct type validation and exports conditions.

When pressing the button to throw a ball the new ball appears on the ground directly.

• People often preach about discouraging certain APIs (don't use for, don't chain .map().filter())
• Those points often miss the context, leading people to believe the API itself is bad.

It's not. All APIs and patterns have a place to be. While this article would state what appears obvious things, "obvious" is relative, and I believe this kind of pragmatic thinking is something people should write more often about.

Appearance

• Support night theme
• Redesign homepage, highlight the latest post, make other posts minified
• Support pagination of posts

They do not lead to the channels if people are not invited.

Expected behavior

• Links should be invitation links with no expiration date

I enjoyed an article on the blog and wanted to subscribe. Consider adding an RSS feed so that others can get updates with their favorite reader.

Showcase practical applications of "test based on usage" approach. I've used this pattern in multiple projects, and I can only say incredible things about it. A few reasons why one should consider adopting this pattern:

• Determines proper concerns and scope of a test.
• Focuses on the usage scenario, ensuring it doesn't have test-related things.
• Effectively, you write both usage scenario (shareable publicly) and a test (confirming that usage actually works).

• Rewrite post tags that include dashes (-) to be properly supported in Twitter.

Motivation:

In the article: "Debounce vs Throttle: Definitive Visual Guide" content in the button: "Reset the machine" is difficult to see.

• What is CircleCI
• How to take advantage of CircleCI workflows and parallel jobs
• Show example of config.yml
• How to boostrap project in one job, and execute the next jobs on already bootstrapped environment (storing cache node_modules)

• Related branch: https://github.com/Redd-Developer/redd.one/tree/dark-theme

In the article about typescript

in the following sentence:

I dare consider myself proficient with the language, having gone thourgh my share of type gymnastics, conditional types, nested generics

You misspelt thourgh through

Nice article by the way!

Painpoints

• How to work with compiler.parser.hooks API?
• How to replace an identifier/expression in the app via the Parser API?
• How to programmatically create an asset from within a plugin? (compiler.assets[n] = { source, length }).

When I press a hard reload button then I see that the bottom "like" button shows that I do not have my "like" even if I did like it on the top "like" button.

I was reading the Debounce Vs Throttle: Definitive Visual Guide article and found out that both examples of "invalid" and "valid" debounce usages in React are actually valid.

Here is a demo: https://codesandbox.io/s/peaceful-water-0iudx?file=/src/App.js

I suppose the intended way for demonstrating an invalid debounce usage is with an inline arrow function:

<button onClick={() => debounce(this.handleButtonClick, 2000)}>

Why

Not as easy as it seems. Webpack doesn't support ESM bundling just yet. Tree shaking is more or less clear when you are a consumer, but what about when you are a producer of packages?

Resources

• Take a look at how Ramda is bundled, it's god-like

Performance concern is essential. However, people often dive into pre-mature performance-based decisions without a) monitoring, b) assessing the problem, c) solving the issue on the proper level.

This topic has been inspired by a Twitter discussion, where the usage of .map().filter() was stated as "harmful". One of the argumentations was performance. I find this statement farfetched and misleading. I generally see a lot of the idea that "X is better than Y" for performance on the Internet. I wish to dispel the myth that one/two/ten small API decisions are crucial for performance. It's not.

First, I'd like to speak about 2 types of performance:

1. Architectural performance.
2. Runtime performance. Affected by infrastructure, caching, CDN, transfer protocol, and then front-end build quality (compression, dead code elimination), and only then if you write the code effectively (and even then it's not about low-level API anyway, but rather about architectural decisions).

Key points I wish to convey:

1. Don't optimize for performance if you don't have an issue.
2. Don't think that for is faster than .map. Don't trust synthetic performance benchmarks. Trust in O(n).
3. Suggestions what does affect performance, and how you can make safe decisions without limiting yourself, or creating pointless obscure guidelines.
4. Choices like for vs map may have an effect when processing huge (and I mean HUGE) data. Be honest with yourself: are you processing such data? Then don't expect that choice to have any effect on your performance.

Quotes

If it's not broken, don't fix it.

Assuming that front-end is the reason for poor performance is like assuming a dash panel to be the cause of a slow vehicle. Just because front-end is the primary surface of experiencing the issue, doesn't mean it is the issue.

Basing your coding style and API choices around performance is, well, bad.