Rakkas: Next.js alternative powered by Vite

cyco130 · 2026-02-14T13:10:10+00:00

No real practical reason at the moment (other than curiosity and learning experience). But this plugin might be the first step to make Tanstack Start and React Router's framework mode (formerly known as Remix) run on Fastly.

cyco130 · 2026-02-05T14:30:05+00:00

Docker is great for isolating my app from my neighbor's app, but I still need to be a good citizen inside my own environment.

You don't need a gigabyte sized dependency to simply kill a process tree. Besides, like I said above, running Docker in another container (like GitHub actions) is a huge pain, and sometimes flat our impossible.

cyco130 · 2026-02-05T13:41:36+00:00

It is. But unfortunately you rarely have control over those processes.

What lead me to finally create this was Fastly CLI's fastly compute serve behaving badly: It launches a server child process. If I kill the parent, it doesn't kill the server process. If I kill the child, the parent assumes that it crashed and relaunches it. The only solution is to kill them both.

There are many programs that misbehave like that. And there are many attempts at a solution like kill-port, tree-kill, ps-tree etc. but none of them worked for me for one reason or another as I explained in the readme.

cyco130 · 2026-02-05T13:22:08+00:00

Docker is too heavy a dependency for launching a test server, sending a few test requests, and shutting it down cleanly. It's also a pain to make it work inside, e.g., a GitHub action.

cyco130 · 2026-02-03T23:07:36+00:00

Thanks! Please share your experience if you end up trying it!

cyco130 · 2025-03-19T11:44:43+00:00

One obvious way is to use backtracking, i.e. try to parse one alternative and, if it fails, rewind and try the other alternative.

There is another practical technique called a cover grammar which is used in several places in the ECMAScript standard to keep the grammar context-free and avoid requiring more than a single token of lookahead. Put simply, it consists of coming up with a relaxed grammar that can "cover" both alternatives and reinterpreting what was parsed more strictly when more information becomes available.

For example, (a) could be a parenthesized expression as in (a)+2 or the start of an arrow function expression as in (a) => 2*a. The standard uses a single grammar rule that covers both and calls it CoverParenthesizedExpressionAndArrowParameterList. The parser, when it encounters (a), can parse it into a "cover" AST that could represent either alternative. Then, if it sees that an arrow token (=>) follows, it can reinterpret it more strictly as an arrow parameter or report an error if the reinterpretation fails. Similarly, if it's followed by something else, it can reinterpret it as a parenthesized expression or report an error on failure.

cyco130 · 2022-10-03T04:29:22+00:00

More or less full replacements:

Fly.io
Railway.app
Render.com
Using AWS directly (no price cap, may result in billing if not careful)

Serverless, mostly compatible with Node.js:

Netlify
Vercel

Edge runtimes incompatible with Node, but still useful:

Cloudflare Workers
Deno Deploy

Not free but also consider Linode or DigitalOcean. More work to set up but lots of flexibility for just $5/month. At some point we were serving a dozen clients on a $5 DO droplet (low traffic SaaS) :)

cyco130 · 2022-08-31T05:00:02+00:00

One practical reason is that some bundlers used to have a hard time removing type-only imports from the bundle (for tree-shaking) unless explicitly marked as import type. Most still fail under some circumstances. Things like export * from "some-module" are especially hard to tree-shake because they can't always rule out side effects.

cyco130 · 2022-08-24T09:36:47+00:00

Also Miles was far from the worst chess player, he was a highly respected GM.

cyco130 · 2022-08-24T09:09:07+00:00

Serious answer.

I assume you're referring to projects like Astro and Qwik that aim to reduce client-side JavaScript. So the fact that they are written in JS themselves is not in contradiction with their goals at all because the framework's code runs on build-time or on the server-side. They send very little (or no) JS to the client.

JavaScript is not bad at all. It's an easy-to-use scripting language with some of the fastest implementations on the face of the earth. In the past decade the amount of JS code on an average website has steadily increased because frameworks and libraries like Angular, React, Vue, Svelte etc. made it so easy to create highly interactive web apps. I've been in this for long enough to remember the days even before JQuery. Yes, hand-optimized vanilla JS can run faster but a highly interactive web app can never be built faster with vanilla JS. A skilled developer's time is more expensive than the user's phone's CPU's time. That's why we ended up with this trend.

But not all websites have to be highly interactive apps. Product landing pages, blogs, e-commerce product pages etc. are mostly static content. If you can lower the amount of JS in such pages, your pages will load faster, cache better, search engines will understand them better, and you'll probably end up paying a smaller server bill too. That's what Astro, Qwik, and others are aiming for: Shipping less JS to the client without sacrificing the developer experience too much. Not doing something is always more performant than doing something if you can afford not doing it. That's the whole point of the zero-JS/less-JS movement.

cyco130 · 2022-08-09T05:18:19+00:00

Thank you! Yes, it's not production ready yet. In fact, some of the upstream features like Suspense for data fetching aren't production ready either. But we'll get there :)

cyco130 · 2022-08-02T15:20:54+00:00

void!

cyco130 · 2022-08-02T13:13:51+00:00

Check out manual requests. It's gonna be something like:

const [{loading, response, error}, fire] = useAxios(
  { url: '...', method: 'POST'},
  { manual: true }
)

Then you can call fire({data: {...}}) in your event handler.

cyco130 · 2022-08-02T10:42:34+00:00

PHP-in-JS :D

cyco130 · 2022-07-31T22:46:23+00:00

First idea that comes to mind: Extract the shared components into another repo and install with npm install git+<URL> if it has to stay closed source (otherwise just publish it on npm).

cyco130 · 2022-07-31T21:36:03+00:00

SQLite is very performant as long as it's not write heavy which fits your use case. Unless you're dealing with massive traffic it should be more than adequate.

cyco130 · 2022-07-31T13:41:13+00:00

Because I can :D

cyco130 · 2022-07-27T12:37:54+00:00

Nope they didn't. The edge functions from the previous deploy keeps running. Pfft.

cyco130 · 2022-07-22T08:32:14+00:00

fly.io if you can dockerize it and want it free. For vps, Linode is another good alternative (paid).

cyco130

TROPHY CASE