That’s cool if people can agree on what maintainability is, which changes improve it and which changes hurt it.

You can get two people arguing for the exact opposite thing, while both of them use maintainability as an argument.

The vibe reminds me of https://youtu.be/Jml7NVYm8cs

It’s not nitpicking, stuff like this is far more impactful than choosing between 5 lines vs 10 lines long methods, or whether the hasExtraCommissions “if” belongs inside or outside of calculateExtraCommissions. This kind of thing should immediately jump out at you as a red flag when you’re reading code, it’s not something to handwave away as a detail.

Why is it a void method? This only tells me that some state is mutated somewhere, but the effect is neither visible nor documented.

I would expect a function called “calculate” to just return a number and not have any side effects.

Self host with backups set up?

Well you don’t have to place it in a separate function, nothing stops you from inlining that part and writing li or whatever directly there.

It’s up to you how you organize your components.

But why bother with creating a new language, and duplicating all the features your language already has, in a weird way?

If I want a list of UI items based on an array of some data, I can just do items.map(item => 〈Item key={item.id} item={item} /〉), using the normal map function that’s already part of the language.

Or I can use a function, e.g. items.map(item => renderItem(item, otherData)) etc.

JSX itself is a very thin layer that translates to normal function calls.

Still better than whatever the hell this is

https://vuejs.org/guide/essentials/template-syntax

The more you scroll down, the worse it gets.

And this too: https://vuejs.org/guide/essentials/list

A new separate language with features that already existed in the original language (and worked with all its tooling, etc.)

Custom template language and custom DOM attributes are way weirder than just using language-native constructs (ternary operator, map/filter, variables, functions, etc.) directly like you can in JSX.

On one hand, this is definitely a gap, on the other hand, you are very unlikely to run into it in practice.

The whole “pass an array/object into some function that will mutate it for you” pattern is not very popular in JS , you are much more likely to encounter code that just gives you a new array as a return value and treats its arguments as read-only.

If you validate your data at the boundaries where it enters your system (e.g. incoming JSON from HTTP responses), TypeScript is plenty good enough for almost all practical uses.

Clickbait title.

The packages were collectively downloaded 963 times before they were removed. The rogue packages include names like “noblox.js-vps,” “noblox.js-ssh,” and “noblox.js-secure,” and they were distributed across specific version ranges

Is there any indication that anyone actually installed these, other than some bots that auto download all packages and such?

You would have to really go out of your way to get infected by stuff like this.

That being said, there are things npm could do to try to auto-detect “risky” packages (new, similar name to existing projects, few downloads, etc.) and require an additional layer of confirmation, or something like that.

This is exactly the point made in this 2010 article that’s probably one of the things I link to most often in online discussions.

https://whatheco.de/2010/12/07/function-hell/

Also, the real problem with code on the right in OP is all the state mutations made to the arguments passed into the functions.

Not too familiar with golang, but this really could use some sort of builder pattern or something, if you’re going to mutate the object. Or a more functional style with just a pure function mapping an input “order” to output “toppings”, etc.

There are plenty of ways to make the bad design on the right better without stuffing everything into a single function, so the whole premise is a bit of a false dichotomy.

https://github.com/GoogleContainerTools/distroless

That sounds like spending a lot of extra effort just to avoid a little up-front effort.

I normally avoid that too, I find it hurts readability more than helps, plus a proper IDE will separate it with color anyway.

But yeah, the newline comment doesn’t apply to this.

Not like that, lol

Just saying, instead of this monstrosity

CreateOrderRequest(user,
                   productDetails,
                   pricingCalculator,
                   order => order.internalNumber)

Just use

CreateOrderRequest(
    user,
    ...

Putting the first argument on a separate line.

Same if you have an if using a bunch of and (one condition per line, first one on a new line instead of same line as the if) and similar situations.

Anything for indent (barely matters, as long as the editor forces it to stay consistent), and fuck alignment, just put things on a new line.

This may not be a popular opinion, but if the app is large enough, just use Electron.

The main pitch is that you don’t have to spend time and effort with installing and configuring a project for development when onboarding new people to it, or when you want to contribute to someone else’s project etc.

You get a proven, up-to-date “works on my machine” kind of environment that others also use, and you don’t need to “pollute” your host system by installing additional tools necessary for each individual project. Compilation (and other build steps), running the project, running the tests, debugging, IDE configuration (e.g. language servers, linter plugins), etc. all happen inside the container.

I personally don’t find it all that useful for projects I’m working on long-term myself, but it’s nice if you need to check something in someone else’s project which you’re not that familiar with.

I think it was created by the same people as VS Code, and definitely designed around its needs (at least initially), kind of like the Language Server Protocol.

There is some preliminary support in IntelliJ - https://blog.jetbrains.com/idea/2023/06/intellij-idea-2023-2-eap-6/#SupportforDevContainers, but then it wasn’t mentioned in the normal 2023.2 release notes, not sure if they pushed it to a future release or what. Either way, it’s a work in progress there.

Then there are tools like https://devpod.sh/ that also use devcontainters.

Regarding how it’s different from just using compose directly, I think the idea is that you “connect” your IDE to it and it specifies things like extensions (obviously IDE-specific), debuggers and debug configurations, language servers setup, environment to use when you open a terminal into it, etc.