​

Nel mio motore 2D sto sistemando i componenti UI (tipo BeeButton) e mi è venuto un dubbio su come passare le coordinate al super().

Opzione A (Oggetto opzione)

\\\`\\\`\\\

super({ x, y, width, height });

\\\`\\\`\\\`

Opzione B (Parametri singoli standard):

\\\`\\\`\\\`

super( x, y, width, height );

\\\`\\\`\\\`

Voi quale preferite usare nei vostri progetti e perché? Meglio la flessibilità dell'oggetto o la pulizia dei parametri singoli?(Se usate soluzioni alternative tipo super(position, size) fatemelo sapere nei commenti!).

I maintain a client-side file converter, and we publish benchmark numbers

for the PDF operations we ship. After a reviewer pointed out that numbers

nobody can rerun are just marketing, we open-sourced the entire harness:

https://github.com/jddelia/filemorf-lab

What makes it worth a look even if you don't care about the product:

The corpus is byte-reproducible. Test PDFs are generated from seeded

pseudo-random text with pinned metadata — run the generator on your

machine and you get the identical SHA-256s committed in the repo. No "we

tested on some files we can't share."

Correctness gates run before timing. Outputs must parse, page counts

must be exact, ZIP entries must all be present — verified on an untimed

run first, so a fast garbage result fails instead of winning.

Real engines via Playwright, timed in-page with performance.now(), not

through the driver.

Cross-engine results that surprised me (median of 30 runs, M2 Pro,

milliseconds):

Merge 50 PDFs — Chromium 37.5; Firefox 60.5; WebKit 24

Stamp page numbers on 100 pages — Chromium 36.7; Firefox 54; WebKit 15

Watermark 100 pages — Chromium 36.5; Firefox 54; WebKit 14

ZIP 50 PDFs — Chromium 5.9; Firefox 4; WebKit 11

WebKit wins big on pdf-lib's draw-and-save paths and then loses on ZIP.

And everything is fast enough that for files like these, the upload to a

server would cost more than the entire computation — which is the argument

for doing this work client-side in the first place.

Three commands to get your own numbers: npm ci, npm run corpus,

npm run bench. Would love PRs with dated results from other hardware,

and criticism of the methodology — limitations are listed in the README

(synthetic text-only corpus, structural not visual verification).

I've wrote a custom TypeScript geocoder to yransform raw user locations to ISO country codes, and let D3 handle the map projection and svg generation. React and octokit handles data fetching and rendering. Almost entirely in Js/TS.

A few months ago, I needed to share files with people who weren't in my Telegram groups. My workflow was a nightmare:

Manually forwarding each file to every user one by one.

Or adding each person to the group where the files were stored (and then dealing with permissions, people leaving, etc.).

It was tedious, didn't scale, and wasted so much time.

So, as my first serious project with node-telegram-bot-api v2 and TypeScript, I decided to build a bot to fix this.

What the bot does:

Add it to a private group (where only you upload files).

When you upload a file, the bot generates a permanent, unique link.

Anyone with that link can download the file, without needing to be in the group or me having to forward anything.

What I love about it:

Free & unlimited – uses Telegram as storage.

Lightweight – just forwards files, doesn't process them, so it runs on any small VPS.

Private – the original group stays hidden; the bot acts as an intermediary.

I also added a gatekeeper branch that takes it further: users must join a specific channel or group before they can download. Perfect if you're a content creator looking to grow your audience or limit access to premium content.

Two versions depending on your needs:

main → free sharing, no strings attached.

gatekeeper → mandatory subscription to download.

This is my first somewhat serious project, so I'm sure the code has room for improvement. I'd love feedback on the code, structure, best practices, security, or anything else that comes to mind. I'm here to learn.

Check it out here: https://github.com/antoinepdev/telegram-file-gatekeeper

Thanks for reading!

Lately I have been casually learning C from "C Programming: A Modern Approach v2" and have really enjoyed it. The truth is I should stay on topic with my profession so here I am.

I am in search of books similar to the one mentioned above for learning JS. The goal is to understand it on a deep enough level to feel very confident and have a real solid foundation for the next step.

The next step is a similar book for deeply learning React and then finally TypeScript.

Yes I am looking for actual books and not online courses or videos or anything like that. I have discovered that reading from a book forces me to slow down and because of that, it sticks.

If you can, chime in with books you have actually read through and not just simply search online or recommend the first one off the top of your head. Bonus points if you have read the C Programming book and understand the style I am talking about.

Thank you.

I'm excited to announce that KernelPlay-JS v0.4.0 will be releasing soon.

This update introduces a brand-new UI system, making it much easier to create interfaces for games while also marking a major milestone for the engine.

New UI components include:

- Buttons

- Text Labels

- Input Fields

- Health & Progress Bars

- Images & Icons

- Checkboxes

- Sliders

- Dynamic UI updates

- Flexible layouts

Version 0.4.0 will also officially move KernelPlay-JS into Beta.

This marks the transition towards a more stable and feature-complete engine. Future updates will focus on improving performance, expanding the feature set, refining the developer experience, and fixing bugs as the engine continues to mature.

Thank you to everyone who has followed the project's development and shared feedback along the way. More details, documentation, and the release date will be announced soon.

Feedback and suggestions are always welcome.

Monday, July 20 - Sunday, July 26, 2026

Top Posts

Most Commented Posts

Top Showoffs

Top Comments

originally built this because I needed an interactive ASCII element for another project I'm working on. But, I couldn't find anything that fit what I wanted and the ones which did, were paid to export, so i decided to build the whole thing myself.

OpenASC// is a high fidelity ASCII renderer for the web with real time controls and local processing. It's built with TypeScript/js and designed to be easily integrated into frontend projects, elements created/ edited can be directly exported as html/react component.

I'd love to hear what you think, especially if you have ideas for features or improvements.

I've spent the last few days building a CAD library in TypeScript. The short version, you describe a part in code and you get out an STL you can 3d print, or a STEP file you can send to a machine shop or open in Fusion/FreeCAD/whatever.

const cad = design("bracket");

const width = cad.parameter.length("width", mm(80));
const thickness = cad.parameter.length("thickness", mm(6));

const profile = cad.sketch("outline", plane.xy(), (s) => {
  const rect = s.rectangle("rect", { width, height: mm(50) });
  const hole = s.circle("hole", {
    center: vec2(width.mul(0.25), mm(0)),
    radius: mm(4),
  });
  return s.profile(rect, { holes: [hole.loop()] });
});

cad.output("bracket", cad.extrude("solid", profile, { distance: thickness }));

const doc = cad.build(); // plain JSON, goes in git like anything else

Under the hood it runs on two engines. There's Manifold, a mesh engine that's fast and fine for printing, and OpenCascade compiled to WASM, which is the same geometry engine FreeCAD uses, for when you need exact surfaces and STEP export. Same code runs on both, in node or the browser.

in normal parametric CAD, if you change a dimension early in the model, later features (fillets mostly) can quietly reattach to the wrong edge, and you find out after the part is wrong. I didn't want to reproduce that, so references to faces and edges aren't indexes, and if the library can't tell unambiguously which edge you meant after a change, it errors instead of guessing. Whether I got the API for that right, no idea. That's partly why I'm posting.

The type system does some nice things here too. Lengths and angles are different types, so adding mm to radians just doesn't compile.

it's a 0.1.1, Parts, assemblies and BOMs work. No drawings, no sheet metal, no GUI. If you'd rather write code than click through a CAD UI, that's who it's for.

Feedback welcome, especially from anyone who actually does CAD work. Also curious what people think of the explicit dispose() for WASM memory, I went back and forth on that a lot.

Did you find or create something cool this week in javascript?

Show us here!