It's pretty slick looking which is worth something to me. Not $750, but something. But even though some of the UX choices of Jellyfin didn't make sense to me, it's an amazing piece of software, so I'm sticking with that, and using Wholphin [1] as a frontend.
> The vite plus idea is that you'll pay for visual tools.
From what I understand, Vite+ seems like an all-in-one toolchain. Instead of maintaining multiple configurations with various degrees of intercompatibility, you maintain only one.
This has the added benefit that linters and such can share information about your dependency graph, and even ASTs, so your tools doesn't have to compute them individually. Which has a very decent potential of improving your overall pre-merge pipeline. Then, on top of that, caching.
The focus here is of course enterprise customers and looks like it is supposed to compete with the likes of Nx/Moonrepo/Turborepo/Rush. Nx and Rush are big beasts and can be somewhat unwieldy and quirky. Nx lost some trust with its community by retracting some open-source features and took a very long time to (partially) address the backlash.
Vite+ has a good chance to be a contender on the market with clearer positioning if it manages to nail monorepo support.
Oxc is not the first Rust-based product on the market that handles JS, there is also SWC which is now reasonably mature. I maintain a reasonably large frontend project (in the 10s of thousands of components) and SWC has been our default for years. SWC has made sure that there is actually a very decent support for JS in the Rust ecosystem.
I'd say my biggest concern is that the same engineers who use JS as their main language are usually not as adept with Rust and may experience difficulties maintaining and extending their toolchain, e.g. writing custom linting rules. But most engineers seem to be interested in learning so I haven't seen my concern materialize.
I had the chance to finish reading and it looks like Trigger were using an older version of PNPM which didn't do any of the above, and have since implemented everything I've mentioned in my post, plus some additional Git security.
So a slight amendment there on the human error side of things.
> you have no appetite for a better security model
For what it's worth, there are some advancements. PNPM - the packager used in this case - doesn't automatically run postinstall scripts. In this case, either the engineer allowed it explicitly, or a transitive dependency was previously considered safe, and allowed by default, but stopped being safe.
PNPM also lets you specify a minimum package age, so you cannot install packages younger than X.
The combination of these would stop most attacks, but becomes less effective if everyone specifies a minimum package age, so no one would fall victim.
It's a bit grotesque because the system relies on either the package author noticing on time, or someone falling victim and reporting it.
NPM now supports publishing signed packages, and PNPM has a trustPolicy flag. This is a step in a good direction, but is still not enough, because it relies on publishers to know and care about signing packages, and it relies on consumers to require it.
There _is_ appetite for a better security model, but a lot of old, ubiquitous packages, are unmaintained and won't adopt it. The ecosystem is evolving, but very slowly, and breaking changes seem needed.
37 Signals [0] famously uses their own Stimulus [1] framework on most of their products. Their CEO is a proponent of the whole no-build approach because of the additional complexity it adds, and because it makes it difficult for people to pop your code and learn from it.
The repository introduces it as indeed based on Helium [0].
The cool part about Helium is that it's based on patches, rather than forking the full source code. I don't know how sustainable this is in the long term, but it's an interesting approach for sure.
Same here. A few years ago I thought maybe the ringing isn't normal. It hadn't occurred to me before that.
I found a YouTube video of a "tinnitus demo" with the right sound and frequency. I could only start hearing it at about 80% volume. I gave my headphones to my partner and she said it was unbearable. I guess I'm used to my normal.
I slightly regret knowing about it, I seem to be paying more attention to it now.
One is impulsive, the other requires structure. The two are not mutually exclusive though, because both conditions are pretty diverse. AuDHD is a term used to describe people with both.
I'm really not a fan of CSS in JS, however it does have it's use-cases. Class mangling is very convenient with it and allows you to be prescriptive about how you're doing theming support, which is great when building libraries that 3rd parties embed on their websites.
The trade-off is that of course your customers can't style things you haven't anticipated, but it means you can control what changes are breaking.
And you can always add an extra variable in a new version if a customer wants to change a border color.
Not a package manager, but Renovate bot has a setting like that (minimumReleaseAge). Dependabot does not (Edit: does now).
So while your package manager will install whatever is newest, there are free solutions to keep your dependencies up to date in a reasonable manner.
Also, the javascript ecosystem seems to slowly be going in the direction of consolidation, and supply chain attacks are (again, slowly) getting tools to get addressed.
Additionally, current versions of all major package managers (NPM, PNPM, Bun, I don't know about Yarn) don't automatically run postinstall scripts - although you are likely to run them anyway because they will be suggested to you - and ultimately you're running someone else's code, postinstall scripts or not.
I use it to shorten common requests I have for my colleagues, e.g. to not forget their code reviews, or alias phrases I commonly use to a :command. It's handy as a form filler too.
I've seen people using it to insert emojis, lorem ipsum text, or fixing common typos. It's quite powerful because you can even do HTTP requests and mash them with your text.
I'm now thinking about writing an expansion to help me reference tickets, e.g. expand :searchticket <string> to a list of up to 5 URLs. Since it happens inline, I don't have to "submit" the list to anything/anyone until I've cleaned up the message.
I can think of three things: serving as a guide, serving to raise awareness, and entertainment.
On the "serving as a guide" part, some people are activists and subscribe to the idea that if they are wasting a scammer's time, this means the scammer has one victim fewer.
On the raising awareness side, there are absolutely plenty of YouTube videos, but it's always good to educate people before they become targets. The psychological and financial impact of getting scammed can be devastating. Raised awareness could also prompt the authorities to crack down on scam centers.
On the entertainment side - some people just get a kick out of it.
Additionally, this particular article breaks down the various tactics used and teaches the reader to identify them.
[1] https://github.com/damontecres/Wholphin