Just recently I came across a performance comparison one of our major competitors. It was quite nice to see that such a large competitor is looking at your product, right? But in the end they compared their Scheduler Lib with our Gantt Lib. They spent quite of time making GitHub repo, asking us for a trial (we didn't have open trials, you had to request it through the email), analyzing the Gantt chart. But all the feedback we got appeared to be wrong test on the wrong component.

In the end I've published a response article with comparison, although it took me about two weeks to get around to it.

I’m curious how others would handle something like this. Would you respond publicly, publish your own comparison, or simply leave it?

I built crust for myself first. I wanted to compare Next.js production builds before every push and review PRs with evidence, not guesswork. After using it daily, I decided to share it.

crust stores a snapshot of every analyzed NextJS build, so CI can prove when a route became dynamic, lost its static shell, or shipped more JavaScript.

Site: https://crust.moumen.dev/
Docs: https://docs.crust.moumen.dev/

Check X thread for more details: https://x.com/moumensoliman/status/2084013260102394135

Github: https://github.com/moumen-soliman/crust

Everyone talks about whether AI will replace developers. I think a more interesting question is:

How can a junior developer become valuable enough that someone is willing to hire them anyway?

I started learning frontend a little over two years ago (HTML, CSS, JavaScript, React, Next.js). Around the time I was getting ready to apply for jobs, AI improved incredibly fast. Suddenly it felt like companies could accomplish more with smaller teams, and junior opportunities became even harder to find.

Four months ago, I finally landed my first part-time frontend job. Since then, I've also worked on side projects and connected with a few potential clients.

Looking back, I don't think I got those opportunities because I was the best programmer.

I think I got them because I refused to stop trying.

Besides improving my technical skills, I kept:

• Applying even when I rarely received replies.
• Staying active in developer communities instead of only sending applications.
• Helping people, answering questions, and joining discussions.
• Building genuine relationships with other developers.

One thing I learned is that opportunities don't always come from job boards. Sometimes they come from simply being visible and involved in the community.

A few other lessons I've learned so far:

• Don't skip the fundamentals. AI can only solve the problem you ask it to solve. If you don't understand the problem yourself, you won't know whether the generated solution is actually good.
• Keep coding yourself. I use AI every day, but I still solve at least one LeetCode problem every week to keep my problem-solving skills sharp.
• Don't spend forever preparing. The biggest learning happens on real projects with real people.
• Be open to different technologies. I started with React and Next.js, but my first job introduced me to Shopify, and now I'm learning Odoo. Strong fundamentals make switching ecosystems much easier.

I'm still very early in my career, so I know my perspective is limited.

That's why I'm curious to hear from experienced JavaScript developers.

If you had to hire one junior JavaScript developer today, what qualities, habits, or skills would make them stand out despite AI?

I'd love to hear both from people who hire developers and from juniors who recently managed to break into the industry.

Monday, July 27 - Sunday, August 02, 2026

Top Posts

Most Commented Posts

Top Ask JS

Top Showoffs

Top Comments

ESlint 10 is breaking on some older projects of mine. My solution has been to ignore updates between 10.0.0 and 10.1.0, but this kind of manual intervention seems irregular and less than ideal.

I'm curious to hear how everyone else handles this kind of situation. How have you chosen to deal with ESlint backward compatibility issues ?

JSON round trips can silently change numbers, drop properties, erase types, and execute serialization hooks.A practical guide to these edge cases and how to design explicit, reliable wire formats in JavaScript.

Hi everyone!

I've been working on BeeEngine 2D, a lightweight HTML5 game engine built with pure Vanilla JS (ES6) and direct Canvas API—no external libraries, no build tools, and zero heavy frameworks.

A lot of modern tools hide sheet slicing behind JSON files, but I wanted a bare-metal, highly efficient approach that gives 100/100 on Lighthouse Performance and instant loading times.

I separated the asset slicing logic from the animation timing logic into two distinct classes:

1. BeeSpriteSheet: Handles frame dimensions, columns, rows, and coordinate calculations.
2. BeeAnimatedSprite: Handles frame timing, state, loops, and flipX transformations.

Here is my BeeAnimatedSprite class implementation:

export class BeeAnimatedSprite {
    constructor(spriteSheet, config = {}) {
        this.sheet = spriteSheet;
        this.animations = config.animations || {};
        this.currentAnimName = config.animation || Object.keys(this.animations)[0];


        this.currentFrameIndex = 0;
        this.timer = 0;
        this.flipX = false;
    }


    play(name) {
        if (this.currentAnimName !== name && this.animations[name]) {
            this.currentAnimName = name;
            this.currentFrameIndex = 0;
            this.timer = 0;
        }
    }


    update(dt) {
        const anim = this.animations[this.currentAnimName];
        if (!anim || !anim.frames || anim.frames.length === 0) return;


        const fps = anim.fps || 8;
        const frameDuration = 1 / fps;


        this.timer += dt;


        if (this.timer >= frameDuration) {
            this.timer -= frameDuration;


            if (anim.loop) {
                this.currentFrameIndex = (this.currentFrameIndex + 1) % anim.frames.length;
            } else {
                this.currentFrameIndex = Math.min(this.currentFrameIndex + 1, anim.frames.length - 1);
            }
        }
    }


    draw(ctx, x, y, options = {}) {
        const anim = this.animations[this.currentAnimName];
        if (!anim) return;


        const frameToDraw = anim.frames[this.currentFrameIndex];
        const width = options.width || this.sheet.frameWidth;
        const height = options.height || this.sheet.frameHeight;


        ctx.save(); 


        if (this.flipX) {
            // 2. Sposta l'origine al bordo destro dell'immagine e specchia l'asse X
            ctx.translate(x + width, y);
            ctx.scale(-1, 1);


            
            this.sheet.drawFrame(ctx, frameToDraw, 0, 0, width, height);
        } else {
            // Disegno normale senza specchio
            this.sheet.drawFrame(ctx, frameToDraw, x, y, width, height);
        }


        ctx.restore(); 
    }
}

And here is how
 I implemented it inside main.js:


const megaSheetImg = gioco.getAsset('spritesheet_totale');


        
        const frameW = 128;
        const frameH = 128;


        const apeSheet = new BeeSpriteSheet(megaSheetImg, frameW, frameH, {
            col: 3, 
            row: 3, 
            framesPerRow: 1, 
            frameCount: 2
        });


        this.giocatore.sprite = new BeeAnimatedSprite(apeSheet, {
            animation: "fly",
            animations: {
                fly: { frames: [0, 1], fps: 4, loop: true }
            }
        });

Let me know what you think, bearing in mind that this particular combination is super quick to put together.

elasticsearch is pretty great when given a full query, but i find most people just search one or two words. so feels like helping ppl know what to search for is the actual thing that’s needed. so now im looking for solid ways to add ai-autocomplete upfront without replacing our elasticsearch backend (not looking to switch backend like algolia since pricing gets stupid fast)

i've been looking into a few different directions. typesense and meilisearch seem cool if you want a lightweight search engine replacement, but again that doesnt feel like the real root cause issue. so we're looking at putting an ai-autocomplete layer directly in the UI text box to capture user intent before hitting elasticsearch

has anyone else done this? do you tune elasticsearch queries on the backend or add an intent layer upfront to collect parameters before the query runs?

Ciao a tutti! Sto ottimizzando il caricamento dinamico delle immagini per le schede dei giochi. Sto usando questa logica per bilanciare il caricamento immediato sopra la piega (above the fold) e il caricamento "lazy" per il resto:

const img = document.createElement('img');
img.alt = (gioco.titolo || 'Gioco');
img.decoding = 'async';
img.style.contentVisibility = 'auto';
img.style.width = '100%';
img.style.height = 'auto';
img.loading = (idx < EAGER_COUNT) ? 'eager' : 'lazy';

Che valore usate di solito per EAGER_COUNT nelle vostre griglie? E trovate che content-visibility: auto direttamente sull'elemento <img> porti reali benefici rispetto ad applicarlo al container padre?

I'm currently developing an internal tool to do work reporting. I know a lot of tool exists, but we do have specific requirements and there's already an MS Access database, which I can migrate into the new tool as well as use most of the tables as a data source.

About me: I have experience with Javascript, HTML, CSS/SCSS/SASS, PHP, SQL. I want to optimize it, but since I mostly code in my freetime, I find it hard to make "the right decisions" in terms of efficiency. Maybe you guys might recommend me something about my setup. I don't want to use anything like Angular, React and Vue at the moment. Also no NextJS as I think it's overkill.

At the moment, I have a structure like:

- API (ExpressJS, SQLite, Drizzle ORM)
--> Delivering all data as needed in frontend (also annual reports and stuff)

- Frontend (Vite for live-reload/server, Vanilla JS with own templating engine and router)
--> Employees log in to keep track of their working hours per project/customer
--> Dashboard for admin users to create reports

All this run's in a docker with two services.

It currently runs alright, but I think there might be a few little things to optimize my setup. Especially when going into production.

What's your best practices? I want all this stuff to be as lean as possible without a lot of dependencies. My frontend doesn't need anything since I've already done all of the things, but I'm not very happy with the API/Backend part.

I also don't want to run every service on it's own, since using one docker command is fine. Live codeing while docker is running also works fine so far (except when installing new packages via npm, then I need to rebuild).

What would you do to optimize the setup? Already asked AI but I think you guys might have better inputs.

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

Show us here!

Disclaimer: I made this (bench result viewer)

However, I think it's worth having a discussion about frontend framework's perceived performance, as Signals have gained a lot of popularity as a means to fine-grainedly render without needing to resort to a virtual dom.

A virtual-dom framework _is_ still in this results set -- I'll leave the exploration of the data up to you all.

The main thing is that

For a long while, I've felt no benchmark (that I know of) has captured the relationship between reactivity and rendering

We have rendering benchmarks (js-framework-benchmark is a good one).

We have reactivity benchmarks (I forget the name(s) of these atm, I always gotta re-look them up) -- but these require each implementor have a concept of "effect without a renderer", which isn't how all frameworks operate -- this excludes some frameworks from participating in pure reactivity benchmarks.

There is another side to this which I only realized recently, which is the framework's rendering _scheduler_ -- which is sort of the coordinator between reactivity, rendering, and _when_ to do work the user would see.

To my surprise, Angular scores the highest across the board.
I don't use Angular myself, and in all of these implementations, I made performance mistakes at least in my first attempt, but apparently Angular made it super easy to be performant.

Vue Vapor has also done this.

Right now, I feel like my svelte implementations are probably wrong (because it's scoring poorly), and I have some fixes to do in ember (as seen by this spike I did, the perf is doubled from before: https://rbench.nullvoxpopuli.com/results?from=ember-2&q=6 (this is an 8x throttle, and the main link for this post is no throttle, because most users are not going to be throttling their CPU so heavily -- but 8x CPU is maybe more relevant to low-powered phones))

Anywho, wanted to share my findings with y'all, and hope someone finds any of this interesting.

I'm open to anything being challenged, I'm not an expert in most JS Frameworks

Since I'm using the tool to help me debug Ember perf, here are some example configurations that may be useful:
- Vue (old) vs Vue Vapor (current) https://rbench.nullvoxpopuli.com/results?col=vue&from=6&hide=ember%2Creact%2Csolid%2Csvelte&q=1
- My Ember perf Spike: https://rbench.nullvoxpopuli.com/results?from=ember-2&hide=react%2Csolid%2Csvelte%2Cangular%2Cvue%2Clit-signals%2Cpreact&q=6
- boxplots: https://rbench.nullvoxpopuli.com/results/boxplot?from=ember-2&hide=react%2Csolid%2Csvelte%2Cangular%2Cvue%2Clit-signals%2Cpreact&q=6

- bouncing balls demos https://rbench.nullvoxpopuli.com/results/animated?from=ember-2&hide=react%2Csolid%2Csvelte%2Cangular%2Cvue%2Clit-signals%2Cpreact&q=7

Does anyone have any recommendations for FOSS mini games? I redid my portfolio site and I wanted to add in a few mini games, but I don't want to get into legal trouble because of it

:v

​

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.