Isomorphic JS/TS Functions Orchestrator

https://github.com/damianofalcioni/js-functions-orchestrator

#HackerNews #Isomorphic #JS/TS #Functions #Orchestrator #open-source #JavaScript #TypeScript #functions

Some images from earlier this year, edited with https://demo.thi.ng/umbrella/webgl-channel-mixer/ (made with my #ThingUmbrella tools)...

#LandscapePhotography #Photography #Color #TypeScript #FalseColor

"Scala 3 / Match Types"

Scala has a neat new feature, resembling TypeScript's "conditional types", but more powerful.

https://alexn.org/blog/2025/10/25/scala-3-match-types/

#Languages #Programming #Scala #Scala3 #TypeScript

Some images from earlier this year, edited with https://demo.thi.ng/umbrella/webgl-channel-mixer/ (made with my #ThingUmbrella tools)...

#LandscapePhotography #Photography #Color #TypeScript #FalseColor

@nolan even the DOM isn't too bad if you have #TypeScript 's `lib` set as expected: https://www.typescriptlang.org/tsconfig/#lib

The default annotations for `JSON.parse()`, `fetch()` say they return `any`, and really any place marked as `any` (or using human-thinks-they-know-best `as MyType` coercions) tends to me what trips me up in practice

I'd love a "greenfield" setting that removes `any` and untyped JavaScript support from TypeScript completely, forcing me to do runtime type-checks instead of making false assumptions

I remain unsatisfied with most Django setups, including my own, that try to incorporate a reasonable JavaScript build pipeline. The JS build is inevitably a separate build step and a local dev server for hot reloading. Sure, deployment is fairly straightforward: compile JS, then collectstatic. It's the development story that suffers for its complexity imo.

I paired Django with AlpineJS for webauthn.io and in general it's fine to make updates to. But I just crested 575 lines of AlpineJS in a single HTML component and it's left me with a sense of dread about ongoing maintainability as I gradually add "just one more feature".

I miss my components-based, TypeScript-checked dev flow when I work with Django. Maybe it's time to look to vanilla Web Components to break some of this up, but then that won't get me the static type checking of TypeScript.

Anyone got any stories of how they wire up at least a TypeScript JS codebase for light front end interactivity, while still leveraging Django views for SSR?

#django #python #typescript #javascript

@antfu Thanks for your work to explore #pnpm catalogs. I agree that this is especially useful to document how and when to update certain dependencies.

Some are safe to change (testing and dev deps), and others require careful review (runtime production dependencies with access to sensitive data).

Looking forward to how this develops over time. This could create big improvements for #JavaScript and #TypeScript projects.

https://antfu.me/posts/categorize-deps

#web #webdev #frontend #npm

🤔 TypeScript is Like C#

｢ the language design of both C# and TypeScript (JavaScript as well) have converged more than other languages. The two languages are now remarkably similar in their core syntax such that developers that know one can typically pick up the other fairly easily ｣

https://typescript-is-like-csharp.chrlschn.dev/pages/intro-and-motivation.html

#csharp #typescript #programming

Ω🪬Ω
#FediAlgo (the customizable timeline algorithm / filtering system for your Mastodon feed) v1.2.2 is deployed now. Has a switch that makes sure any #hashtags / users / etc. that you follow are displayed as filter options even if they don't meet the minimum number of recent toots threshold.

Also a bunch of bug fixes and small improvements.

* Try it here: https://michelcrypt4d4mus.github.io/fedialgo_demo_app_foryoufeed/
* Code: https://github.com/michelcrypt4d4mus/fedialgo_demo_app_foryoufeed
* Video of FediAlgo in action (slightly outdated): https://universeodon.com/@cryptadamist/114395249311910522

#activitypub #algorithm #algorithmicFeed #algorithmicTimeline #Fedi #FediTips #FediTools #Fediverse #Feed #FOSS #GoToSocial #hashtag #hashtags #javascript #MastoAdmin #Mastodon #MastodonApi #mastohelp #mastojs #node #nodejs #opensource #socialmedia #SocialWeb #timeline #TL #typescript #webdev

Finally got around documenting a little more the small CLI app "framework" I've been using for almost a dozen projects now (incl. several work projects). The package in question is now already 3 years old (https://thi.ng/args), but I've only just managed now to add a basic, commented usage example for this `cliApp()` feature to the readme:

Defining a multi-command CLI app (incl. two sub-commands):
https://github.com/thi-ng/umbrella/blob/develop/packages/args/README.md#declarative-multi-command-cli-application

Also part of this: I've refactored a few other projects to simplify their CLI handling using this `cliApp()` wrapper (project links are in the above readme, in case you'd like to see more advanced/realworld uses...) One of the (non-public) work projects ended up consisting of up to a dozen sub-commands and I found this declarative and modular setup to be very, very helpful (and elegant)...

#ThingUmbrella #TypeScript #JavaScript #CLI #OpenSource

Finally got around documenting a little more the small CLI app "framework" I've been using for almost a dozen projects now (incl. several work projects). The package in question is now already 3 years old (https://thi.ng/args), but I've only just managed now to add a basic, commented usage example for this `cliApp()` feature to the readme:

Defining a multi-command CLI app (incl. two sub-commands):
https://github.com/thi-ng/umbrella/blob/develop/packages/args/README.md#declarative-multi-command-cli-application

Also part of this: I've refactored a few other projects to simplify their CLI handling using this `cliApp()` wrapper (project links are in the above readme, in case you'd like to see more advanced/realworld uses...) One of the (non-public) work projects ended up consisting of up to a dozen sub-commands and I found this declarative and modular setup to be very, very helpful (and elegant)...

#ThingUmbrella #TypeScript #JavaScript #CLI #OpenSource

Ω🪬Ω
#FediAlgo (the customizable timeline algorithm / filtering system for your Mastodon feed) v1.2.2 is deployed now. Has a switch that makes sure any #hashtags / users / etc. that you follow are displayed as filter options even if they don't meet the minimum number of recent toots threshold.

Also a bunch of bug fixes and small improvements.

* Try it here: https://michelcrypt4d4mus.github.io/fedialgo_demo_app_foryoufeed/
* Code: https://github.com/michelcrypt4d4mus/fedialgo_demo_app_foryoufeed
* Video of FediAlgo in action (slightly outdated): https://universeodon.com/@cryptadamist/114395249311910522

#activitypub #algorithm #algorithmicFeed #algorithmicTimeline #Fedi #FediTips #FediTools #Fediverse #Feed #FOSS #GoToSocial #hashtag #hashtags #javascript #MastoAdmin #Mastodon #MastodonApi #mastohelp #mastojs #node #nodejs #opensource #socialmedia #SocialWeb #timeline #TL #typescript #webdev

Seriously, there's no Result<T, E> or Either<T, E> in #typescript out of the box? 😱

#Vite plugins sometimes need to run expensive tasks. By controlling when your plugin runs these tasks, you can make both the #Dev server and production builds faster. Here's a quick solution:

What's your best tip for developing Vite plugins?

https://samuelplumppu.se/blog/detect-vite-plugin-restarts-to-avoid-rerunning-expensive-tasks

#TypeScript #JavaScript #WebDev #SvelteKit

cross-posting my little rant about #npm #npmattack #javascript #typescript stuff here:

Random NPM thoughts of the day:

1. The primary NPM registry should be obsoleted entirely ASAP
2. JSR does not do anywhere near as much as it should, and it's probably too late to fix.
3. A proper successor must only support "standard" JS, though temporarily accepting "strippable types" is ok rn
4. All packages MUST be ESM (JSR ok here)
5. MUST include docstrings on all publicly-reachable interfaces.
6. MUST NOT include any type of dependency other than a named registry dependency with a semver version (no git deps etc)
7. MUST have a non-trivial README.
8. MUST be tied to a PUBLIC repo.
9. MUST NOT have install scripts (yeah sorry, the fight's over)
10. MUST clearly include a license, even if the license is "source available, not open source". This restriction MUST NOT limit to OSI's ridiculous list.
11. MUST have a name that is scoped to its publishing user/org (@foo/bar)All of the above constraints MUST be checked at publish time.

Furthermore, the registry MUST provide the following, based on this:

1. Full browsable (published) package sources, right on the site. With linkable paths. None of this absolute trash NPM decided to do.
2. Autogenerated API docs.
3. Lower-traffic packages that have not had a new version in 6 months should be completely delisted. They can be installed, with a warning printed.
4. Usernames/org names and package names must employ a suitably-aggressive levenshtein distance for potential conflicts. This should be aggressive.
5. Packages cannot be transferred between accounts, and it's against policy to allow others access to your personal account. Orgs can work around this.
6. Top 1000 packages (maybe more) have all new publishes put on hold for 7 days, and placed into a public review queue, overridden by [tbd?staff?]
7. Y'all aren't gonna like this but: package installation should be reasonably throttled. Both to keep costs down, and to encourage people to do something less lazy than "I'm just going to install all 2k dependencies on CI every time I push a docs change". It's wasteful and harmful for many reasons.

I think that's all I got off the top of my head for now.

There's honestly a lot of stuff that could be done on the client side to make life better, too, and y'all know I have a ton of thoughts on that, but I wanted to rant about registries for a bit, esp now that the NPM registry is crumbling.

cross-posting my little rant about #npm #npmattack #javascript #typescript stuff here:

Random NPM thoughts of the day:

1. The primary NPM registry should be obsoleted entirely ASAP
2. JSR does not do anywhere near as much as it should, and it's probably too late to fix.
3. A proper successor must only support "standard" JS, though temporarily accepting "strippable types" is ok rn
4. All packages MUST be ESM (JSR ok here)
5. MUST include docstrings on all publicly-reachable interfaces.
6. MUST NOT include any type of dependency other than a named registry dependency with a semver version (no git deps etc)
7. MUST have a non-trivial README.
8. MUST be tied to a PUBLIC repo.
9. MUST NOT have install scripts (yeah sorry, the fight's over)
10. MUST clearly include a license, even if the license is "source available, not open source". This restriction MUST NOT limit to OSI's ridiculous list.
11. MUST have a name that is scoped to its publishing user/org (@foo/bar)All of the above constraints MUST be checked at publish time.

Furthermore, the registry MUST provide the following, based on this:

1. Full browsable (published) package sources, right on the site. With linkable paths. None of this absolute trash NPM decided to do.
2. Autogenerated API docs.
3. Lower-traffic packages that have not had a new version in 6 months should be completely delisted. They can be installed, with a warning printed.
4. Usernames/org names and package names must employ a suitably-aggressive levenshtein distance for potential conflicts. This should be aggressive.
5. Packages cannot be transferred between accounts, and it's against policy to allow others access to your personal account. Orgs can work around this.
6. Top 1000 packages (maybe more) have all new publishes put on hold for 7 days, and placed into a public review queue, overridden by [tbd?staff?]
7. Y'all aren't gonna like this but: package installation should be reasonably throttled. Both to keep costs down, and to encourage people to do something less lazy than "I'm just going to install all 2k dependencies on CI every time I push a docs change". It's wasteful and harmful for many reasons.

I think that's all I got off the top of my head for now.

There's honestly a lot of stuff that could be done on the client side to make life better, too, and y'all know I have a ton of thoughts on that, but I wanted to rant about registries for a bit, esp now that the NPM registry is crumbling.

Ω🪬Ω
#FediAlgo v1.1.19 is deployed. Minor bugfixes and improvements to the customizable timeline algorithm / filtering system for your Mastodon feed.

* Link: https://michelcrypt4d4mus.github.io/fedialgo_demo_app_foryoufeed/
* Code: https://github.com/michelcrypt4d4mus/fedialgo_demo_app_foryoufeed
* Video of FediAlgo in action (slightly out of date): https://universeodon.com/@cryptadamist/114395249311910522

#activitypub #algorithm #algorithmicFeed #algorithmicTimeline#Fedi#FediTips#FediTools #Fediverse#Feed#FOSS#GoToSocial #hashtag #hashtags #MastoAdmin #Mastodon #MastodonApi #mastohelp #mastojs #nodejs #nod #opensource #socialmedia#SocialWeb #timeline#TL #typescript#webdev