-
-
zig
General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
node-esbuild-executable
A demonstration of how to build a single file executable from a node program using esbuild
-
-
deno-cliffy
Command line framework for deno 🦕 Including Commandline-Interfaces, Prompts, CLI-Table, Arguments Parser and more...
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
awesome-tagged-templates
A list of libraries and learning resources for ES2015 tagged template literals
I was quite curious about the .bunx file format. I think this could be a quite a useful thing, a universal binary format. Some tech companies have internal implementations of this sort of system. Then I see the shim DLL:
https://github.com/oven-sh/bun/blob/801e475c72b3573a91e0fb4c...
Even before this past week's XZ backdoor revelation, checking binaries into source control rather than building from source seems quite questionable. In fairness to the Bun developer's, they have a comment in their build.zig file acknowledging that this shim should be built more normally rather than being checked in.
Then I look into the source for it:
https://github.com/oven-sh/bun/blob/801e475c72b3573a91e0fb4c...
For no discernible reason, it is using a bunch of undocumented Windows APIs. The source cites this Zig issue as one reason for why they think it is OK to use undocumented APIs:
https://github.com/ziglang/zig/issues/1840
I don't see any good reasons here cited for using undocumented, unstable interfaces. For Zig's part, there seems to be some poorly-explained interest in linking against "lower level" libraries without any motivating use case (just some hand waving about security and drivers, neither of which makes much sense. Onecore.lib is a thing if you wanted a documented way of linking an executable that run on a diverse set of Windows form factors. And compiling drivers may as well be treated as a seperate target, since function names are different). For Bun, I assume they are trying to have low binary size. But targeting NTDLL vs. Kernel32 should not make a big difference, especially when the shim is just doing basic file IO. For an example of making small executable with standard API, you can make hello world 4kb using MSVC just by using /NODEFAULTLIB and /ENTRY:main with link.exe and this program :
#include
I was quite curious about the .bunx file format. I think this could be a quite a useful thing, a universal binary format. Some tech companies have internal implementations of this sort of system. Then I see the shim DLL:
https://github.com/oven-sh/bun/blob/801e475c72b3573a91e0fb4c...
Even before this past week's XZ backdoor revelation, checking binaries into source control rather than building from source seems quite questionable. In fairness to the Bun developer's, they have a comment in their build.zig file acknowledging that this shim should be built more normally rather than being checked in.
Then I look into the source for it:
https://github.com/oven-sh/bun/blob/801e475c72b3573a91e0fb4c...
For no discernible reason, it is using a bunch of undocumented Windows APIs. The source cites this Zig issue as one reason for why they think it is OK to use undocumented APIs:
https://github.com/ziglang/zig/issues/1840
I don't see any good reasons here cited for using undocumented, unstable interfaces. For Zig's part, there seems to be some poorly-explained interest in linking against "lower level" libraries without any motivating use case (just some hand waving about security and drivers, neither of which makes much sense. Onecore.lib is a thing if you wanted a documented way of linking an executable that run on a diverse set of Windows form factors. And compiling drivers may as well be treated as a seperate target, since function names are different). For Bun, I assume they are trying to have low binary size. But targeting NTDLL vs. Kernel32 should not make a big difference, especially when the shim is just doing basic file IO. For an example of making small executable with standard API, you can make hello world 4kb using MSVC just by using /NODEFAULTLIB and /ENTRY:main with link.exe and this program :
#include
See my answer "what's cool about deno" https://gitlab.com/brlewis/brlewis-aoc/-/blob/main/README.md...
Also with Deno, it become very easy to write typed cli. .ts file can be run as script very easily with permission access defined on top of the script such as:
#!/usr/bin/env -S deno run --allow-net
Then one can just run ./test.ts if the script has +x permission.
Also project such as https://cliffy.io has made writing cli way more enjoyable than node.
It is a good idea to beware of the VC. So it is good idea to support project such as Hono (projects conform to modern web standard, and is runtime agnostic for JS).
That proposal is not fully compatible with Typescript: https://github.com/tc39/proposal-type-annotations?tab=readme...
https://github.com/denoland/deno/issues is the ideal place -- we try to triage all incoming issues, the more specific the repro the easier it is to address but we will take a look at everything that comes in.
> Also with Deno, it become very easy to write typed cli. .ts file can be run as script very easily with permission access defined on top of the script such as:
I do this all the time. I used to use npx in my hashbang line to run TS scripts with node, but I've started using Deno more because of the permissions. Another great package for shell scripting with Deno is Dax, which is like the Deno version of Bun shell: https://github.com/dsherret/dax
> Also project such as https://cliffy.io has made writing cli way more enjoyable than node.
This looks cool. I've always used the npm package inquirer (which also works with Deno), but I'll have to compare cliffy to that and see how it stacks up.
> Hono (projects conform to modern web standard, and is runtime agnostic for JS)
Hono is awesome. It's fast, very well typed, runs on all JS runtimes, and has zero dependencies.
Tagged templates[0], the language feature that enables this, were introduced in ECMAScript 2015 apparently – arguably at least somewhat new in the lifespan of JavaScript. :)
Java is getting a similar feature with template processors[1]. It would be nice to have it in Python as well – i.e. not just f-strings, but something that (like tagged templates) allows a template function process the interpolated values to properly encode them for whatever language is appropriate (e.g. shell, SQL, HTML, etc.).
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[1] https://openjdk.org/jeps/459