The --self-extracting flag in deno compile --self-extracting looks awesome.
I could compile my 11ty stack into a single executable that I could send anywhere, but it would still be able to read external markdowns so semi-technical coworkers can make content changes without the maintenance overhead of a CMS and without the coworkers needing to learn modern web dev.
It would also be super awesome for all the internal tools I’ve built that need to run offline.
CSS has been considered turing complete for a long time.
So this isn’t a shocking revelation, but it is cool.
It’s a garbage article.
It’s not checking other’s claims, it’s not saying anything new, it’s not even listening to the majority of the parties.
For each of the parties (node, deno, bun): they are incentivised to only release benchmarks that make themselves look good, and are disincentivised to release benchmarks that make themselves look bad.
This article only uses benchmarks from one party then declares it the winner.
So, it’s garbage.
I don’t see any products or services being promoted in this article.
That’s kind of the point. You’re not supposed to.
They’re farming links so search engines see their domain as more important. That way, their entry will appear higher up on search results against competitors for their paid products.
Bro, how are generators going to be faster?
This is an AI article.
My results:
Firefox:
Loop: 44ms - timer ended
Generator: 4580ms - timer ended
Node (uses same engine as deno, chrome, edge):
Loop: 30.577ms
Generator: 1.533s
Safari (uses same engine as bun):
Loop: 605.222ms
Generator: 2804.669ms
Bun (same engine as Safari but without needing to apologise for Safari):
[17.52ms] Loop
[297.17ms] Generator
Generators are going to be slow because:
Until generators don’t rely on stack switching, they’re always going to be super slow.
This benchmark is pretty useless.
There’s no benchmark code shown to see if they’re doing something wrong or cherrypicking.
Also, they only tested on arm64? Why weren’t they testing on x86-64?
And what the hell is this test?
Common data transformation pattern, map then aggregate with reduce.
People who care about performance are using loops, not map(). Why are you even testing the slow path?
I’m usually programming, but I’ve got a few bits and pieces that can be shared:
The rest are too experimental, or are released commercial projects.
Let me load HTTP without the S if I want to.
No, that let’s companies man-in-the-middle you.
ISPs literally couldn’t help themselves inject ads and other scripts that lagged and broke everything on every website all to chase a few bucks.
HTTPS prevents them from doing that.
Nah, it’s triggering the same mental pathways as in gambling disorders (which is the same as other disorders, which is the same… etc), but we’re not going to lump it in with gambling because that wouldn’t help gamblers or people who’ve deluded themselves with AI.
Best to give it its own name.
Or if you need something smaller, simpler and more modular: purecss.io
(Yes it’s weird that they called a framework “pure” css, but it’s been a solid go to for a long time)
Yeah, I’m the lead on a bunch of websites that all have to be localised.
There’s a lot of weird footguns to watch out for, and a lot of retraining devs when they’re used to only working on a single language/locale.
Two biggest head scratchers I’ve had to deal with are computers treating “fr-FR” different from “fr-fr” (due to file system case-sensitivity differences between developers), and having to undo the coded assumption that languages and locales follow an [a-z]{2}-[a-z]{2} pattern (e.g. “en-gb”) once we stumbled upon Latino Americano: “es-419”.
EDIT: My left ear really loves the Erlang talk.
This fixes it:
const audioContext = new AudioContext();
const audioElement = audioContext.createMediaElementSource(document.querySelector("video"));
audioContext.destination.channelCount = 1;
audioElement.connect(audioContext.destination);
Ooh, I didn’t know about that site.
-4 votes?
Is someone sockpuppetting?
This was and still is a classic talk, right up there with wat, juice it or lose it, fuck you pay me, the art of code, and pwned by the owner: what happens when you steal a hackers computer
I’m a:
So I have a lot of machines
Machine 1
Machine 2
Machine 3:
Machine 4:
Also:
Future:
I’m literally slower with AI, because I have to waste my time review slop generated code that looks convincing rather than actually works.
If they tried at least to write the code themselves they would get better over time
Pretty sure Deno had that first though.
Deno launched with an all-tools-in-one approach and then you could use deno bundle to compile everything into a single binary that you could run on another machine.
Then they briefly broke deno bundle in their 2.0 release when they added node/npm compatibility then brought it back in 2.4.
Serious question for anyone who actually uses Bun:
Why are you using Bun instead of Deno or Node?
If you would have asked me 10 years ago, what were the biggest problems with JS as a whole, I would have stated:
Poor type safety
No standard library which leads people into dependency hell
Poor security (installing a project should not even allow the possibility of key stealing or ransomware)
No runtime ergonomic immutable data structures with fast equality checks (looked like it was going to be resolved with the Records and Tuples proposal, but it was withdrawn and discussions are continuing in the composites proposal)
Today I consider point 1 mostly resolved and point 4 a problem for TC39 and engine implementers, and not resolvable by runtimes themselves.
That leaves us with problems 2 and 3.
I see Node having poor solutions for 2 and 3.
I see Bun having poor solutions for 2 and 3.
I see Deno having great solutions for 2 and 3.
As far as I can tell, people have chosen Bun for either hype or speed reasons.
Hype doesn’t seem like an important reason to choose Bun since it’s always fleeting and there’s enough investment in the industry to keep each runtime going for a long time.
I do see speed being a moderate issue with JS, but that’s mainly due to:
dependency install times which should be a one time cost, and which can be reduced anyway by using a standard library
slow framework slop, which isn’t really a runtime issue.
So I’m not sure speed fits as a reason for choosing Bun.
I’m not sure what the other reasons are, but I’m genuinely curious.
If you’re using Bun in projects today, why have you chosen bun?
Bruh, deno’s great!
I haven’t used Hugo.
I went with 11ty a few years ago because I wanted to stay as close to the actual web standards as possible (so, HTML/CSS/JS).
The main reason why is that every additional abstraction layer and every invocation of “magic”, is just extra hidden complexity which makes things harder to debug, extend, and maintain.
Having a SSG in go/python/rust would have been an extra layer.
The “maintain” point above is something most others don’t think about until it comes back to bite them. Nothing is more frustrating than reopening a project that worked fine a few years ago, and even though you haven’t changed anything, nothing works, and when trying to update it you end up with Frankenstein’s monster.
11ty went out of it’s way to remain as simple as possible. Here’s your input directory, and here’s your output directory. That makes the maintenance and backwards compatibility really easy.
Then you can add the minimum required complexity/abstraction layers only when you need them.
In my case, I use:
I’ll say the one thing I don’t like about 11ty is that it’s written in js, not ts. The author is all about simplicity and reducing layers of complexity. But now typescript has a typescript-lite version with the erasableSyntaxOnly flag, which basically allows it to run on node (deno and bun already ran typescript), so the next version (or one after), may be migrated to typescript.