HN user

why-oh-why

217 karma
Posts1
Comments102
View on HN

I hope you’re being sarcastic.

At heart, Slack is a chat app. Chat apps have existed for 40 years and don’t require a whole lot of data.

The complex part might be displaying the data, but that’s not much different than what an RSS reader does.

Even calling a chat app “complex” sounds absolutely ludicrous. It’s just that devs are now used to shipping 100MB apps in the name of fast development, so Slack is what we get.

The overhead of setting up NPM

What overhead? You don’t run any optimization step on your code? I haven’t seen a single front end project without package.json in years in all the companies I consulted for, and I don’t even deal with fancy frameworks.

It is because if a file is made of a hundred 1-line functions that’s not good code. The separation of concerns is likely not meaningful and it’s detrimental to the reading/understanding of the file.

Why create a function that shortens/clarifies nothing and is used once? If you want to explain some code, use a comment, don’t make spaghetti

Your CI system isn't going to re-run your tests when your dependencies or sub-dependencies get updates.

Yes and no. Your CI system runs when you want it to. If you want to check the latest dependencies,

- with a lockfile you have to delete it, create a new one and commit it;

- without a lock you just press the “rerun tests” on your CI

What’s the point of reproducibility in your team but not with your users (which is by definition the most common use case)?

Libraries should skip lockfiles because they are ignored by the end user and therefore any testing you do based on them helps no one.

I’ve had lockfiles being broken for no reason* so if you can avoid them, do.

* For example, multiple versions of the same package were installed after several install/updates, but nuking the lock would avoid this issue and solve the problems it caused.

Some bad code is hard to lint automatically (e.g. if there’s a single function that all it does is arg.slice(1), no linter will catch that).

I’ve found all kind of bugs just refactoring code because poor code obfuscates them.

Your way of building things will lead to debt and bug reports

If your code has 20 if else in a row I don’t care if it’s performant and has no bugs, you’ll get a change request because I don’t want to maintain that pile of garbage.

There are minor code style preferences and others that affect maintainability. Just because it works now it doesn’t mean the code is done.

You’re right in having no trust in them. Recently I complained about my price increasing by a couple % once I signed up. Nobody could tell me what the problem was. It took them several messages to finally spill up that they were charging me more due to my country’s taxes.

Why is this not clear? Airbnb is so opaque. It would be really easy to list this extra tax but they don’t, so I end up creating a new account.

“Left behind” i.e. this API will work for USA only. Don’t be silly. The point of browser APIs is that they work for all/most, if it’s only Apple Pay and Google Pay they solve nothing.

In fact, if anyone knows an easy solution for that I'd love to hear it.

What’s this? You’re asking for a solution to “things that don’t work” ️

Here's the thing: you can't have 1000 "discoverable" actions, there's no place for it.

Correction: you do have 1000 discoverable actions, but you discover them in the menu bar.

What you found out with this article is that users are bad at knowing things, because there are too many things to know. I know all of those actions and their keyboard shortcuts, but I still have to occasionally "google it."

Either you have iOS 1.0 where everything is clear and easy to do — because there's very little to do — or macOS, where each app has dozens of features but can only surface some of them.

This is non-news.

Oh my god, we should never allow people to have a little fun on their own blog and if they do, let’s call them childish and unworthy of finding work. /s

It’s just a meme, used correctly, what’s the problem? This isn’t the White House’s blog.

I didn’t upgrade: I created a new volume and installed a fresh Catalina on it. Honestly it’s been working great for me and the battery life increased (probably because my old install was… uhm… dusty)

I’m thinking of two situations:

- you tapped the “Siri suggestion” result which completely skips the SERP. I hate that “back” doesn’t bring you back to what I typed in the search/URL bar

- I regularly visit The Verge, open a story and then the back button doesn’t take me to the homepage but to the page before it. I blame their crappy JavaScript but maybe we’re experiencing the same thing.

My FOSS Story 7 years ago

It depends on the phrasing. If you’re just saying “me too” you’re just annoying the maintainer instead of adding a silent +1 reaction.

If you add one more use case that might help the maintainer reconsider the feature, then I’d find it acceptable. Sometimes the issue opener didn’t explain the utility that well or wrote some example that made it sound like it would be a niche feature and not worth it.

It looks like they’re two separate functions merged under a condition. Any 2 functions can generate a “fly straight, dammit” graph. What’s the point of this?

It’s kind of surprising that anyone who works for these services for more than one day keeps working in these conditions. If you made $50 in one day and spent $40 in gas, why work again? Does Doordash pay more initially to “get them hooked?”

It’s definitely predatory practices of people who don’t understand that, after a day of work, you should have more money than what you spent.

Instead of focusing on what TS does not, focus on what it does.

TypeScript is not sound; JavaScript isn’t either. The first one will catch some type errors, the second will catch none.

Syntax highlighting, linting, testing, and now type checking: every step can make you more confident about the code you ship, before it even hits the browser.

You can forgo using any help and probably you’ll code faster, but, again, you lose confidence.