Introducing relationships between issues will considerably increase the complexity of GitLab. That is not a reason not to do it. But it is a reason for us to be strategic in when we do it, and ensure we have a good design that is scalable and aligns with our other initiatives.

When building the Droplet Console, we had a few options to support SSH keys-based authentication. The most straightforward way would be to directly allow the customer to specify a private key that is already set up for accessing the Droplet. However, there are some problems with this solution:

Auto-update aside, you might also have found it hard to find a Chrome binary with a specific version. Google intentionally doesn’t make versioned Chrome downloads available, since users shouldn’t have to care about version numbers—they should always get updated to the latest version as soon as possible. This is great for users, but painful for developers needing to reproduce a bug report in an older Chrome version.

Calling a software convention "pretty 90s" somewhat undermines your position. Quite a lot of well-designed software components are older than that. If something is problematic, it would be more useful to argue its faults. When someone cites age to justify change, I usually find that they're inexperienced and don't fully understand the issues or how their proposed change would impact other people.

If you dig into the details, you will see that the TypeScript team take breaking changes very seriously and with consideration.

There are many projects that does not use the master branch as default. For example, Next.js uses the canary branch, the npm CLI and many more other projects uses stuff like prod, production, dev, develop, release, beta, head.

I've been thinking more about how to best do this. The preferred way might be to use the same domain and have an application load balancer like nginx split traffic on the URL path (e.g. /api). This is for two reasons. Firstly, you might not necessarily want to cookie the primary/apex domain and have the cookie shared across all subdomains. You also might not want to do CORS because preflight requests add latency and CORS adds complication.

Prettier intentionally doesn’t support any kind of global configuration. This is to make sure that when a project is copied to another computer, Prettier’s behavior stays the same. Otherwise, Prettier wouldn’t be able to guarantee that everybody in a team gets the same consistent results.

“Who cares? Let’s just go with the style-guide” — to which my response is that caring about the details is in the heart of much of our doings. Yes, this is not a major issue; def self.method is not even a code smell. Actually, that whole debate is on the verge of being incidental. Yet the learning process and the gained knowledge involved in understanding each choice is alone worth the discussion. Furthermore, I believe that the class << self notation echoes a better, more stable understanding of Ruby and Object Orientation in Ruby. Lastly, remember that style-guides may change or be altered (carefully, though!).

But so far everything brought up has just been about the relative advantages of checked exceptions, and that issue is closed. We won't do it.

provide interfaces so you don’t have to think about them

Consequently, you act irresponsibly when you adopt any programming practice simply because "that's the way you're supposed to do things."

My point is that you should not program blindly. You must understand the havoc a feature or idiom can wreak. In doing so, you're in a much better position to decide whether you should use that feature or idiom. Your choices should be both informed and pragmatic.

It makes me happy to see people actually think about things and not just accept a shitty API.

Trust me, I thought a lot about #validate and its semantics, and I am gonna make it even more "SRP" by making Form#errors and #valid? semi-public. All that happens via #validate reducing the possible wrong usage for users.

I use <b>s for the decorative portions of the layout because they’re purely decorative elements. There’s no content to strongly emphasize or to boldface, and semantically a <b> isn’t any better or worse than a <span>. It’s just a hook on which to hang some visual effects. And it’s shorter, so it minimizes page bloat (not that a few characters will make all that much of a difference). More to the point, the <b>’s complete lack of semantic meaning instantly flags it in the markup as being intentionally non-semantic. It is, in that meta sense, self-documenting.

Think first: why do you want to use it in the browser? Remember, servers must never trust browsers. You can't sanitize HTML for saving on the server anywhere else but on the server.

But this post is in part a plea to consider what you’re invoking visually and the expectations surrounding it.

Some of these are absent-by-design

Like most frameworks that abstract the DOM, Svelte has incompatibilities like the inability to name a prop class because it’s a reserved keyword in JS, and you’ll use on:click not onclick, but these quirks are few in number and reflect carefully chosen tradeoffs. Svelte does its best to harmonize with the web platform, welcoming both experienced developers and newcomers with whatever web knowledge they have.

It is intentionally very minimal

I think a casual look at the game could be quick to take fault that some moves are scripted, and perhaps they are.  If play passes to you and there is a stock to be had for free…why _not_ take it? For me, it’s a distraction. The player before you likely considered the options and found the game state to be worth tempting you with that. Those free, or even cheap, stocks won’t gain you the influence in any companies that can make your personal cache more valuable.

To ensure there is enough space for both content and navigation, Reply uses different navigation patterns for desktop, tablet, and mobile.

There are a few intentional behavioral differences between Dart Sass and Ruby Sass. These are generally places where Ruby Sass has an undesired behavior, and it's substantially easier to implement the correct behavior than it would be to implement compatible behavior. These should all have tracking bugs against Ruby Sass to update the reference behavior.

Doing a HOC properly, as a library should, with hoisted statics and displayName and ref, etc., is a hassle and would add unnecessary bulk.

Adding checks for bracket[3] syntax as opposed to dot.3 syntax adds a lot of complexity, and has consciously been avoided.

While react hooks were one of the catalysts for v3 we don't agree with with the APIs or the model and won't be emulating it.

There are tools in Svelte that break this expectation to a degree, but they are a bit annoying to use, which makes it an active decision on the part of the developer. The API hints at the way we want you to do things because we feel that this will give the better experience.

by practicing data minimalism and actively considering your data decisions