HN user
Simply hosting a front-end only app is almost free on several platforms (e.g. Cloudflare). Certainly less than the $99 Apple developer membership fee. It starts getting more expensive once you add back-end servers and databases and whatnot, but you’d be needing those with the App-approach too if your featureset requires that.
What do you mean by runtime? The JavaScript runtimes, like V8? Yeah those are impressively fast for a dynamically typed ”scripting” language, but that has little to do with TS. TypeScript’s work ends at compilation.
For me, the main benefit is deployment bundle/artifact size reduction. Mostly from dropping unneeded files from node_modules. Many packages include both esm and cjs builds, sources, docs, TS types, etc. stuff that you don’t need in prod. This matters for lambdas, for example, because deployed code size has limits there.
It's an interesting discussion, but I think simply outputting text can make the software "malware", even if the output isn't executable. What if the output was
To use jqwik, please login to your Office 365 account:
http://o365login.phishing.xyzReminds me of the back and forth competition between Node.js and io.js that we had to endure back in the day. Worked out for the best in the end.
minimumReleaseAge and lockfiles also pin down transitive dependencies.
Number 1 would only be a win for zero-installs if it happened that registry was up when you made the security hotfix, since you'd need to install the depdencency the first time to get it in VC, but then suddenly down when doing a deploy. Seems like a highly unlikely scenario to me. Also, cases where npm CVEs must be patched with such urgency or bad things will happen are luckily very rare, in my experience.
Most npm CVEs are stuff like DDoS vulnerabilities, and you should have mitigations for those in place for at the infra-level anyway (e.g. request timeouts, rate limits, etc), or you are pretty much guaranteed to be cooked sooner or later anyway. The really dangerous stuff like arbitrary command execution from a library that takes end user input is much much more rare. The most recent big one I remember is React2shell.
Number 2 hasn't been much of an issue for a long time. npm doesn't allow unpublishing package after 72 hours (apart from under certain rare conditions).
Don't know about number 3. Would feel to me that if you have something running that can modify lockfile, they can probably also modify the chekced-in tars.
I can see how zero-installs are useful under some specific constraints where you want to minimize dependencies to external services, e.g. when your CI runs under strict firewalls. But for most, nah, not worth it.
Run Yarn in zero-installs mode (or equivalent for your package manager). Every new or changed dependency gets checked in.
Idk, lockfiles provide almost as good protection without putting the binaries in git. At least with `--frozen-lockfile` option.
- saves infra costs
- saves infra headaches
- devs only need to be experts in one system (or well I guess one and a half, probably there's something to learn about ParadeDB too, but probably less than in learning Lucine)
- no need to worry about keeping data up to date in the separate seach system
- all data is available when you want to do new queries that you handn't thought of when implementing the data transfer/indexingAt TypeScript-level, I think simply disallowing them makes much more sense. You can already replace .push with .concat, .sort with .toSorted, etc. to get the non-mutating behavior so why complicate things.
I don't have much experience in dedicated vector databases, I've only used pgvector, so pardon me if there's an obvious answer to this, but how do people do similarity search combined with other filters and pagination with separate vector DB? It's a pretty common use case at least in my circles.
For example, give me product listings that match the search term (by vector search), and are made by company X (copanies being a separate table). Sort by vector similarity of the search term and give me top 100?.
We have even largely moved away from ElasticSearch to Postgres where we can, because it's just so much easier to implement with new complex filters without needing to add those other tables' data to the index of e.g. "products" every time.
Edit: Ah I guess this is touched a bit in the article with "Pre- vs. Post-Filtering" - I guess you just do the same as with ElasticSearch, predict what you'll want to filter with, add all of that to metadata and keep it up to date.
Ehh what. I would give some merit to arguments like "no one should use lodash in 2025 because you can do most of it with built-ins nowadays" or maybe because it doesn't tree-shake well or maybe even because it doesn't seem to have much active development now.
But stating matter-of-factly that no one should use it because some of its well-documented functions are mutating ones and not functional-style, and should instead use one particular FP library out of the many out there, is not very cool.
The post links to a TS issue [1] that explains
As of TypeScript 5.0, the project's output target was switched from es5 to es2018 as part of a transition to ECMAScript modules. This meant that TypeScript could rely on the emit for native (and often more-succinct) syntax supported between ES2015 and ES2018. One might expect that this would unconditionally make things faster, but surprise we encountered was a slowdown from using let and const natively!
So they don't transpile to ES5, and that is the issue.
I don't think pinning deps will help you much, as these incidents often affect transitive dependencies not listed in package.json. package-lock.json is there to protect against automatic upgrades.
I know there are some reports about the lockfile not always working as expected. Some of those reports are outdated info from like 2018 that is simply not true anymore, some of that is due to edge cases like somebody on team having outdated version of npm or installing a package but not committing the changes to lockfile right away. Whatever the reason, pinned version ranges wouldn't protect against that. Using npm ci instead of npm install would.
The main issue there is that the maintainer lost access to their account. Yanking malicious packages is better, but even just being able to release new patch versions would've stopped the spread, but they were not able to do so for the packages that didn't have a co-publisher. How would crates.io help in this situation?
FWIW npm used to allow unpublishing packages, but AFAIK that feature was removed in the wake of the left-pad incident [1]. Altho now with all the frequent attacks, it might be worth considering if ecosystem disruption via malicious removal of pacakge would be lesser of two evils, compared to actual malware being distributed.
fzf [1] provides the TUI.
According to the description in advisory, this attack was in a postinstall script. So it would've helped in this case with nx. Even if you ran the tool, this particular attack wouldn't have been triggered if you had install scripts ignored.
Periodic reminder to disable npm install scripts.
npm config set ignore-scripts true [--global]
I know this isn't a silver bullet solution to supply chain attakcs, but, so far it has been effective against many attacks through npm.
My guess would be because they affect property ordering, complicating the stringification.
The default object property iteration rules in JS define that numeric properties are traversed first in their numeric order, and only then others in the order they were added to the object. Since the numbers need to be in their numeric, not lexical, order, the engine would also need to parse them to ints before sorting.
> JSON.stringify({b: null, 10: null, 1: null, a: null})
'{"1":null,"10":null,"b":null,"a":null}'SeaQuery looks like a similar dynamic query builder for Rust as Kysely is for JS/TS, so yeah, that'd probably solve the dynamic query problem. But I think parent wasn't so much asking for another library but for patterns.
How do people who choose to use a no-dsl SQL library, like SQLx, handle dynamic queries? Especially with compile-time checking. The readme has this example:
...
WHERE organization = ?
To quote a TV show Community character Jeff Winger:
What makes humans different from other animals? We're the only species on earth that observes Shark Week. Sharks don't even observe Shark Week, but we do. For the same reason I can pick up this pencil, tell you its name is Steve and go like this... [breaks pencil. Abed reacts in shock] Jeff Winger: and part of you dies just a little bit on the inside. Because people can connect with anything.
Yes. And that is what a client should 100% do from the security standpoint. But since you mention caching - from the perf standpoint, it could sometimes be beneficial for the query planner to know the values before coming up with the query plan. Sometimes I have done little optimizations by replacing prepared statement placeholders with baked-in numbers or known enum values.
They seem to be measuring things like how long it takes for the dev server to spin up, and how long HMR updates take. I don't think ESBuild offers these features out of the box. I guess it could be in the "Cold build" chart. AFAIK Vite uses ESBuild at least for some of its building, though. node_modules, dev builds maybe. Not sure if it was used in this benchmark or not.
Does the JSON spec actually say that those objects should be "equal", or does it just leave that detail to implementations?
In JavaScript at least, those two are not exactly "the same", in the sense that you can observe the difference if you want to. If you parse those JSON strings and then iterate the keys (e.g. with Object.keys), the ordering will be different.
It's great that Temporal is coming, and I'm sure there are bunch of other nice things coming up too, but unfortunately I don't share your optimism with the specific proposals that you mention (even though those would be very nice).
Pipelines, pattern matching and records+tuples have all been in the works for 4+ years, and are all still in stages 1-2. I don't think any of them has seen any significant progress in the past year, except maybe pattern matching. According to an issue in the records and tuples repo, there's been pushback on the value semantics of it (i.e. whether === can be made to work). Dropping value semantics would significantly reduce the whole proposal's usefulness.
I think all of them are at least a year or two away from reaching stage 3, if they ever do. But hey at least we now have array grouping functions.
isolatedModules doesn't disable enums in general, only exported const enums (which are arguably the most useful form of enums).
You could embed your web font inline to the stylesheet, as base64 encoded data url.
<style>
@font-face {
src: url(data:application/font-woff2;charset=utf-8;base64,...) format('woff2');
}
To each their own. I can't imagine doing UI development without HMR anymore. Makes it so much faster to iterate.
The people who already know JS/TS and would like to occasionally do something interesting with a piece of data. With Python, most of my time goes into googling how that list filtering / mapping syntax went again or some other basic level stuff that I do every day with JS. I know Python, but I'm not fluent in it. And I will likely never be fluent in it, because my Python use cases are so infrequent.
Then again, why bother with the tokens if you have XSS access as an attacker? I'd simply show the user a login prompt and take their password when they type it in.