bgwhn

Joined 13 years ago

Karma
263
Submissions
98
Member since
Nov 23
Website: https://benjam.info/ Email: hackernews@(website domain)
View on Hacker News

Recent submissions

Comment · 7 months ago
> skip some build steps

There was a change in Next 16, not Turbopack, that removed `ESLint` during `next build`: https://nextjs.org/blog/next-16#breaking-changes-and-other-u...

This behavior is the same whether you use Turbopack or webpack. It doesn't make sense for us to couple ourselves with ESLint when there are many viable alternatives. No other popular frameworks run ESLint automatically during builds. This change in Next 16 brought up closer to parity with other frameworks and bundlers.

> typescript validation

There's no change here with Turbopack. We do still run `tsc` automatically to check your types. That's part of `next build` and not Turbopack. However, we may remove this in the future for similar reasons.

There's no good reason for the bundler to call the typechecker. Bundlers strip types. Historically this was done with Babel in webpack. Modern versions of Next.js use SWC for type stripping in both webpack and Turbopack.

> aggressively cache node modules

We aggressively cache everything. We don't have special-casing for `node_modules`. See our blog post about our caching system: https://nextjs.org/blog/turbopack-incremental-computation

Interestingly vite does actually special-case and cache `node_modules`: https://vite.dev/guide/dep-pre-bundling

There are tradeoffs to both approaches, and I think Vite's choice makes sense in the context of their broader minimal-bundling-in-dev design, but it makes less sense for Turbopack (as well as webpack and Rspack) where we produce bundles in dev.

Comment · 8 months ago
Thank you for sharing your experience with Next.js, even though you eventually ended up moving off.

> Waiting on Turbopack: Our initial local route loads took 10 to 12 seconds under the full weight of the App Router and RSCs.

Out of curiosity, were you on Next 16.0 or 16.1? We shipped file system caching in 16.1 that greatly improves the initial route loads. https://nextjs.org/blog/next-16-1#turbopack-file-system-cach...

> Production memory leaks

If anyone else runs into this, we've got a guide on how to profile your application: https://nextjs.org/docs/app/guides/memory-usage

> The multi-cloud ceiling

Admittedly hosting Next.js can be a bit harder than a SPA if you're using all the features of the framework, but if you're scaling and you don't want to use Vercel, you've got a lot of other options, including those provided by OpenNext. We've got a nice example repository here: https://github.com/leerob/next-self-host

Comment · 5 years ago
Comment · 5 years ago
Comment · 6 years ago
I worked on this while on the Instagram Server Framework team to leverage LibCST and solve some of Instagram's own problems. We took a lot of inspiration from other lint frameworks (notably, Flake8 and ESLint).

I left the team before most of the work to open source it happened. It looks like a lot of work went into the documentation, command line interface, and configuration system. Congrats to the whole team! I hope this can be useful to other projects outside of Facebook.

Comment · 6 years ago
I'm with you, and I prefer "dumb" devices, but you can still buy these blu-ray players and not connect them to the internet.

The internet connectivity is sold as an additional feature so that you can use your blu-ray player to watch Netflix. I agree that I don't want logging on a device like this, but if I was going to connect one of these to the internet, I would at least want regular security updates.

Comment · 6 years ago
Comment · 6 years ago
Comment · 6 years ago
If the data structure has a reference count of one, you can safely mutate the data structure instead. Many persistent immutable data structure libraries use this as an additional optimization.
Comment · 7 years ago
> I'm surprised that smaller companies have not moved away from static pricing yet.

The physical server has a fixed set of resources. If you let customers pick what resource they want to buy, you'll run out of one resource before the rest, leaving the server underutilized and increasing your costs. You can't sell KVM instances with no ram, no disk, or no CPU.

If you have enough physical servers and small enough customers, you can mostly solve this by carefully figuring out which customers to put on which machines. However, you've created a complicated jigsaw puzzle. And what happens if you need to shift customers between servers to balance things out?

I think Google is able to offer custom machine types because they're big enough, and because they're able to perform live migrations between physical hosts (most hosting providers can't do this), so the customer likely won't even notice if they need to be migrated.

Instead, most of these providers offer a few different SKUs to satisfy different use-cases, or they just pick one target market (e.g. lots of disk space for backups or lots of CPU resource for compute) and focus on that. A few offer networked block storage, which gives some more flexibility, but at the (potential) cost of reliability and performance.

> None in Asia though? You need it to be in Taiwan to service the region well!

Bandwidth in Asia is significantly more expensive (https://blog.cloudflare.com/bandwidth-costs-around-the-world...), so most budget hosting providers stay away.

Comment · 8 years ago
The flexbox implementation that react native uses for layout.
Comment · 8 years ago
> What is the alternative to using Virtualbox

Any other hypervisor. QEMU/KVM, Xen, VMWare, and Parallels all have good track records.

Comment · 8 years ago
As others have mentioned, Digital Ocean and Linode would probably be good options here.

If you're looking for something even smaller and cheaper than $5/mo, I've had luck with BuyVM. They've very cheap, have good customer support, a nice panel, and you get an entire /64.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton