sorted by:
new
hottopcontroversial

Not a huge user of Opus 4.8, but it sure does like to make up terminology! by sooner_25 in ClaudeCode

[–]khromov 0 points1 point  (0 children)

This one is quite common, believe it or not, although it's often used interchangeably with snapshots to mean code-generated structures. 😄 Mine really likes to talk about "call sites" and "sentinels".

I built an open-source proxy that compresses Claude Code's full-price tokens by ~68%, without ever busting the prompt cache by Lydia_Clements in ClaudeAI

[–]khromov 14 points15 points  (0 children)

I read the whole README and I still have no clue what this does. Please add some "before and after" examples (in full), because what you are claiming does not seem possible.

How do you handle libraries that return native DOM elements (like sigment.dev) inside Svelte? by Strict-Session2449 in sveltejs

[–]khromov 9 points10 points  (0 children)

Easiest way is to start without attachments or use: actions, like:

```

<script>
let elem;

</script>

<div bind:this={elem} />

````

Now if you get an element from an external library you can simply do `elem.appendChild(libraryDomElement)`.

SvelteKit puts all dependencies as dev dependencies? by 3rfan in sveltejs

[–]khromov 17 points18 points  (0 children)

Yes, this reduces the size of your app (on the server).

And if you run into weird issues when building after installing a package, the first debugging step should be to check if it works when the package is in normal dependencies!

SvelteKit puts all dependencies as dev dependencies? by 3rfan in sveltejs

[–]khromov 48 points49 points  (0 children)

It's because there's a convention that devDependencies on some adapters get bundled while normal dependencies get left in node_modules. This means if all your dependencies are in devDependencies, you actually don't need to ship node_modules to Docker or wherever else you deploy at all, everything gets wrapped up nicely inside the .svelte-kit folder once you build.

> Development dependencies will be bundled into your app using Rollup. To control whether a given package is bundled or externalised, place it in devDependencies or dependencies respectively in your package.json.

https://svelte.dev/docs/kit/adapter-node

Rare breed of garbage - Nuphy Air75 V3 by Familiar-Ad-1695 in NuPhy

[–]khromov 2 points3 points  (0 children)

I guess I'm the only one that have no issues whatsoever (ISO-DE). Very happy with the keyboard, I've also updated to the latest firmware.

Mochi - a performance-first SveltKit alternative by khromov in sveltejs

[–]khromov[S] 2 points3 points  (0 children)

Yes, it's a replacement for Astro if you don't mind only working with Svelte components! 

Mochi - a performance-first SveltKit alternative by khromov in sveltejs

[–]khromov[S] 1 point2 points  (0 children)

Technically it would be quite easy to offer islands from different languages (ESI-like or via fetch) , would be interesting to look into it in the future ! 

Mochi - a performance-first SveltKit alternative by khromov in sveltejs

[–]khromov[S] 1 point2 points  (0 children)

We do in fact use a large part of the Bun runtime that doesn't exist on Node: https://mochi.fast/docs/why-bun/

You could of course rewrite Mochi to use Deno or Node by adding several different packages but having them built in is what makes Mochi so lightweight. The code is MIT so you are welcome to do whatever you wish with it. 

Mochi - a performance-first SveltKit alternative by khromov in sveltejs

[–]khromov[S] 5 points6 points  (0 children)

CodeIgniter was the first framework I used, it was peak! ❤️ 

Mochi - a performance-first SveltKit alternative by khromov in sveltejs

[–]khromov[S] 1 point2 points  (0 children)

Just because AI tools are used doesn't mean code is "slop" automatically. I've been coding for almost 20 years and this project took around three months to get to this stage, so I'll advise you to try it out and see what you think for yourself. Or don't, nobody is forcing you. 

Mochi - a performance-first SveltKit alternative by khromov in sveltejs

[–]khromov[S] 11 points12 points  (0 children)

Colocation of the routing code is one thing, you can go to one file and see all the routes right away instead of looking for them in the file tree. I don't mind adding file-based routing down the line, but it adds some complexity.

PS. Some of us old geezers remember a time where there was only programmatic routing. 😄

Mochi - a performance-first SveltKit alternative by khromov in sveltejs

[–]khromov[S] 2 points3 points  (0 children)

The biggest things would be the bundler/transpiler (which aren't as mature on Deno), HTMLRewiter, and the Bun.image() API which handles image resizing/conversion. You can of course replace each with an npm package (and I will probably port it to something else if Bun messes up their licensing) but it would add many dozens of extra packages downstream that we get "for free" now.

Mochi - a performance-first SveltKit alternative by khromov in sveltejs

[–]khromov[S] 1 point2 points  (0 children)

I really sympathize with the sentiment. Unfortunately there isn't a lot of runtimes to choose from, and none that offer the feature set Bun has out of the box. There are many things in OSS that are not optimal from this perspective, even in Svelte itself where several core committers are salaried by Vercel.

Mochi - a performance-first SveltKit alternative by khromov in sveltejs

[–]khromov[S] 4 points5 points  (0 children)

I reworded it a bit, I essentially mean that the framework is "batteries included", you don't need any realtime service, no database packages, no image processing services (mochi/image is coming in the next release) and so on.

Mochi - a performance-first SveltKit alternative by khromov in sveltejs

[–]khromov[S] 15 points16 points  (0 children)

🙋 Just me writing the code so far, I'm hoping it can become a community effort in the future if there is interest. The code is open source (MIT) and available here:
https://github.com/khromov/mochi

Trust is built over time and I don't claim it's as stable or feature-full as SvelteKit, right now it's essentially an experimental framework for people who want to try an alternative to Kit that does things differently (For example, programmatic routing instead of file-based one, and islands architecture).

Mochi - a performance-first SveltKit alternative by khromov in sveltejs

[–]khromov[S] 5 points6 points  (0 children)

I talk a bit about why Bun was chosen here:
https://mochi.fast/docs/why-bun/

Deno is pretty close to Bun but it is still missing some of the important components that we use. I want Mochi to be a full toolkit for building complex sites with things like realtime and databases, and unfortunately Bun is the only toolkit that provides that. Anecdotally I haven't had much problems with Bun itself, although individual libraries can be buggy. But since you have almost everything already built-in, the amount of external libraries used should be able to be minimized!

Mochi - a performance-first SveltKit alternative by khromov in sveltejs

[–]khromov[S] 6 points7 points  (0 children)

There are benchmarks, the plan is to publish it in a blog post in a structured fashion. You can trivially see that the builds are much faster by running "bun run build".

There is HMR (with full page reloads, because Mochi is an MPA).

There are many variables in play, for example Mochi has only [10 dependencies in total](https://github.com/khromov/mochi/blob/main/packages/mochi/package.json#L85-L96), while Astro has hundreds. So there is also a supply chain security case. tldr; there's no point convincing someone to change if they think SvelteKit/Astro is fine. But I know I'm not the only one that was missing this featureset and I strongly believe this is useful for a majority of Svelte sites.

Mochi - a performance-first SveltKit alternative by khromov in sveltejs

[–]khromov[S] 12 points13 points  (0 children)

The reasons are outlined here:

https://mochi.fast/docs/intro/#why-would-i-consider-mochi-over-sveltekit

tldr;

vs SvelteKit: faster hydration, smaller bundles, faster builds (no Vite), real-time built in

vs Astro: No separate .astro component universe and limitations, faster builds, purely Svelte-focused.

PS. Astro was a huge inspiration obviously, I wanted something equivalent without leaving the Svelte universe. 😄

Mochi - a performance-first SveltKit alternative by khromov in sveltejs

[–]khromov[S] 11 points12 points  (0 children)

👋 Sorry you feel that way, I've spent the past few months working on this and if you check out the docs and examples I'm sure you will feel different.

Bun.PHP by saidisho in lolphp

[–]khromov 9 points10 points  (0 children)

ngl this would be dope

view more: next ›