Or you can click on the categories to filter by topic
Bun 1.1.30 came out last week. What got me intrigued is this new option to bun build which is --bytecode. With it you can create an executable, supposedly compiled partially to bytecode which means it can start even faster.
I tried it on my hylite CLI which is a CLI, built with Bun, but works in all versions of Node, that can syntax highlight code to HTML on the command line. Here's what I did:
Truncated! Read the rest by clicking the link below.
This isn't a comprehensive in-depth analysis but I have this SPA which is built with Vite + React.
When you run npm run build it produces:
vite v5.4.8 building for production... ✓ 8210 modules transformed. dist/index.html 0.76 kB │ gzip: 0.43 kB dist/assets/images-xTxpPavl.css 2.02 kB │ gzip: 0.55 kB dist/assets/index-IHK6QBxo.css 200.12 kB │ gzip: 29.85 kB dist/assets/index-jgmGYYS9.js 0.79 kB │ gzip: 0.51 kB dist/assets/open-graph-image-Ca6hLYnz.js 1.47 kB │ gzip: 0.82 kB dist/assets/images-CwbhV2EW.js 28.75 kB │ gzip: 10.37 kB dist/assets/pageviews-C6NSq649.js 378.67 kB │ gzip: 106.42 kB dist/assets/index-HpyQl1NK.js 490.15 kB │ gzip: 154.11 kB ✓ built in 4.46s
Truncated! Read the rest by clicking the link below.
Last time I uploaded a video was only a few months ago but one thing that I've improved, since that video, is the wrist alignment at the top of the swing. Neither video does a perfect job of showing this but it's a least a bit better now.
I think what I still have to work on to slow down, and find a smooth and slow tempo, as the club travels up in the back swing.
pg_stat_statements is a contributed extension for PostgreSQL that logs all queries and how long they took. If you aggregate on this, you can determine where your PostgreSQL spends the most time and what to optimize.
How it works and how you install it is for another blog post.
SELECT
(total_time / 1000 / 60) AS total,
(total_time/calls) AS avg, calls,
SUBSTRING(query FROM 0 FOR 250)
FROM pg_stat_statements
WHERE calls > 100
ORDER BY 1 DESC
LIMIT 25;
This one is important because you could have some terribly slow query that uses lots of sequential scans, but perhaps it's only used once a week, so who cares?
Truncated! Read the rest by clicking the link below.
What @tanstack/react-query is is a fancy way of fetching data, on the client, in a React app.
Simplified primer by example; instead of...
function MyComponent() {
const [userInfo, setUserInfo] = useState(null)
useEffect(() => {
fetch('/api/user/info')
.then(response => response.json())
.then(data => {
setUserInfo(data)
})
}, [])
return <div>Username: {userInfo ? userInfo.user_name : <em>not yet known</em>}</div>
}
Truncated! Read the rest by clicking the link below.
I have a single-page-app built with React and Vite. It fetches data entirely on the client-side after it has started up. So there's no server at play other than the server that hosts the static assets.
Until yesterday, the app was use swr to fetch data, now it's using @tanstack/react-query instead. Why? Because I'm curious. This blog post attempts to jot down some of the difference and contrasts.
If you want to jump straight to the port diff, look at this commit: https://github.com/peterbe/analytics-peterbecom/pull/47/commits/eac4f873303bfb493320b0b4aa0f5f6ba133001a
When @tanstack/react-query first came out, back in the day when it was called React Query, I looked into it and immediately got scared how large it was. I think they've done some great work to remedy that because it's now not much larger than swr. Perhaps it's because swr, since wayback when, has grown too.
When I run npm run build it spits this out:
Truncated! Read the rest by clicking the link below.
Did you know you can attach a key to a JavaScript object that is actually a callable?
For example:
const data = await response.json()
Object.defineProperty(data, 'magic', {
get: () => {
return Math.random()
},
})
console.log({magic: data.magic})
will print:
{ magic: 0.6778944803790492 }
Truncated! Read the rest by clicking the link below.
If you've done React for a while, you most likely remember Create React App. It was/is a prepared config that combines React with webpack, and eslint. Essentially, you get immediate access to making apps with React in a local dev server and it produces a complete build artefact that you can upload to a web server and host your SPA (Single Page App). I loved it and blogged much about it in distant past.
The create-react-app project died, and what came onto the scene was tools that solved React rendering configs with SSR (Server Side Rendering). In particular, we now have great frameworks like Gatsby, Next.js, Remix, and Astro. They're great, especially if you want to use server-side rendering with code-splitting by route and that sweet TypeScript integration between your server (fs, databases, secrets) and your rendering components.
However, I still think there is a place for a super light and simple SPA tool that only adds routing, hot module reloading, and build artefacts. For that, I love Vite + Wouter. At least for now :)
What's so great about it? Speed
Truncated! Read the rest by clicking the link below.
So many of you, this is so basic that it's embarrassing. Any maybe to me too. But the truth is, I often forget the syntax. By mentioning it here, hopefully, I'll memorize it better.
To set a default environment variables, consider this example Bash program:
#!/bin/bash
: "${PORT:=8000}"
echo "Port number: $PORT"
When you run it, it defaults to the value 8000 (a string)
❯ bash dummy.sh
HOSTNAME:8000
And if you override the default:
Truncated! Read the rest by clicking the link below.
This is an unscientific comparison update from previous blog posts that compared Node and Bun, but didn't compare with Deno.
From Converting Celsius to Fahrenheit round-up it compared a super simple script that just prints a couple of lines of text after some basic computation. If you include Deno on that run you get:
❯ hyperfine --shell=none --warmup 3 "bun run conversion.js" "node conversion.js" "deno run conversion.js"
Benchmark 1: bun run conversion.js
Time (mean ± σ): 22.2 ms ± 2.1 ms [User: 12.4 ms, System: 8.6 ms]
Range (min … max): 20.6 ms … 36.0 ms 136 runs
Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.
...
Summary
bun run conversion.js ran
1.97 ± 0.35 times faster than deno run conversion.js
2.41 ± 0.39 times faster than node conversion.js
Truncated! Read the rest by clicking the link below.