People are still using that for NEW projects? 😬

I imagine so, it was just surprising to see it underperform so heavily.

I think it's the take(10) that makes it performant.
I guess things like any() will also short-circuit having to process the entire array through a chain of operators before acting on a subset of the final processed array.
If that makes sense....

But if you are filtering then mapping an array, an iterator won't help. You need to go through every element of the source array (to filter) then every element of the filtered array (to map) anyway. There is no opportunity to short circuit, so an iterator won't help.
Edit: and I bet there is overhead keeping iterators active/alive and context switching as each new iteration gets requested, instead of batch processing an array then moving on to the next batch process.

I did some benchmarks a few months ago on iterator helpers, but unless I used them incorrectly, regular arrays were much more performant, maybe an order of magnitude, than supposedly lazy iterator helpers.

Maybe it's a poor implementation in Firefox? I don't know.

After the first half, content repetition sets in, making me wonder about degree of LLM. I feel like at the end I read two things in particular three times.

Either way, The first half or third was interesting and valuable.

Most of the frameworks may have been needed at one time, but they were crutches. And requiring users to download them wastes time and bandwidth. Vanilla JS these days has largely replaced the need for them. We can fix them by eliminating the need for them.

Sounds like a plan, maybe I can try used FJ again, it does looks nicer than prettier or biome.

No, CI validates that the hooks or formatter ran, and fails if not. in theory it shouldn't ever fail but it's to catch the stuff that couldn't have passed the commit hook.

the hooks are easy to turn off and can be hard to get to reliably run (90% of the time they're fine, but all of the tools that run git commands sometimes do weird things), but they're a best effort kind of thing.

unit tests on precommit are a little annoying, especially when it takes that long. that's better suited to running in ci afterwards since there's no advantage to running before you commit. formatter takes like 200ms max for affected files? you won't notice, and it ends up as part of the one commit

Yeah, but do you really want CI making commits in your git history? Haven't thought too much about it but I'm assuming it could get gnarly. In larger teams I often see stuff that could not possibly have passed the existing pre-commit hook. Actually on one of our projects the unit tests run on precommit and it takes 8 minutes on my machine, so you could call me a git hook skeptic.

pre commit hook and ci task. even with common formatters like prettier I do that on anything somewhat large

My experience using it in a large project is seeing a lot of unformatted PR's, vs more mainstream tools like prettier etc. I think the main issue here is that the vscode extension uses separate config vs the cli/js version, and that there aren't extensions for other popular editors like jetbrains, zed etc. Also if you have a lot of projects that use json, and you want to adopt this in one of them, a lot of engineers are not going to bother setting up their env to handle different auto-formatting across workspaces. And some will say they prefer to run the formatting via cli then frequently forget to.

Hmmm.... babel ? :D

But it only understands JS syntax from 2009, before ES 6 arrived ... so most modern JS doesn't work.

You are probably in a tight deadline but if you ever get the time, and if you haven't yet, the Tutorials and guides in MDN are really really good.

MDN: JavaScript Guide

MDN: Intermediate

MDN: Advanced

Thank you all, I really appreciate your advice. I'm currently doing the odin project and in the last section of the foundation course. I read a bunch of MDN docs of course as part of the course. I think I should read more of it

This is true of other dynamic languages. For example, Python will also allow you to add arbitrary properties to objects without complaining.

As others have mentioned, you need to read MDN, and more specifically, understand the browser APIs and DOM structure. When you have an HTMLElement, you should know that you need to set style properties on .style, and you should know that .style is a CSSStyleProperties object which uses camelCased version of the CSS property names, and each property takes a certain type of value, like the various value types for the width property, which include length values, percentage values and keyword values.

One of the main skills of being a frontend developer is learning this object model. It doesn't make sense to complain about it, because that is the job.

Trial and error is not an efficient way to learn. You should at the very least experiment in the browser with the dev tools open. Have a hypothesis for how something should work (like changing a particular property), try making the change and observe the effect on the webpage and in the dev tool inspector, and if your hypothesis is wrong, understand why and update your mental model. The goal is to avoid using trial and error eventually and build an understanding instead.

MDN is probably the best docs I've seen in my career. Even their translated version is impeccable.

How should I know or figure out things like this?? When there's no error and I don't know why it doesn't working other than trying different syntax until it works!

A) MDN. Never use any JS API you've never used before without reading the docs on MDN first. JS is kind of a massive pain in the ass to work in, but dear lord, the MDN docs are just the absolute gold standard.

B) Set yourself up with a rudimentary TypeScript build process. Not like a full managed project under npm or bun or whatever the latest fad is (unless you've already got a project setup like this, I guess). Just write your source files in TypeScript instead of JavaScript, setup a .tsconfig file, and run a copy of the TypeScript compiler tsc to convert 'em all to JavaScript. That'll eliminate entire classes of errors from your code, like your attempts to write to a non-existent .width property, for example.

If you're not familiar with TypeScript, it's built to be exclusively a superset of JavaScript. I.E. it's just JavaScript with some type annotations. Really, the compiler is less of a compiler, and more of just a static analyzer that trims out the type annotations.

C) You should probably also look for a JS/TS autocompletion tool, of some kind. I'm not sure what's out there in that regard, except for Intellisense within Visual Studio, since VS is what we're given at work. But for someone new to an API, having it be discoverable right in your editor is a DX that can't be beat.

In Javascript width should not default to px considering you can also use em, px and %.

This won't help with your units issue but if you want Javascript to give more errors, try strict mode. Add: "use strict"; as the first line in your file.

MDN: Strict mode

Js is a dynamic language. The first line is not “wrong”, it just isn’t what you want. It does indeed just add a new field in the gridContainer object. Tthis is perfectly valid javascript.

Js doesn’t “know” that it is running in a browser, nor does it care. It doesn’t know what the appropriate value or type is for these fields in a ‘div’ or anything else.

Yes, you pretty much have to use trial and error, unless there exists some other tool that can typecheck your code. I don’t do webdev, so I'm not sure.

What about the standard library though ?

Who in the world would use Javascript on a microcontroller? At that point is it even a microcontroller?

You mean homophobe Brendan Eich?

"in just 10 days"

This explains so much

Seems like biome already won this race.