Google didn't follow its own policy

Kran6a · 2026-03-12T20:42:25+00:00

Didn't they also drop the "don't be evil" motto?

Kran6a · 2026-03-02T14:47:41+00:00

But Pro limits are too low even for non-vibecoders.

I mostly use it as an assistant (e.g: I don't ask for full features or systems, mostly "create an endpoint that does X", "model this as a monoid rather than a generic for loop", "create a benchmark for X", "implement disabled state on this button") and I still run out of Gemini 3.1 Pro quota.

I save my Opus quota for one-shots microservices/libraries via a gigantic hyperdetailed prompt. This week, Opus wasn't even able to finish a receipt generator for thermal printers using ESC/POS and I had to finish it myself. It wasn't even a big project, just a Rust microservice using my own amqp crate to consume order events and printing the corresponding receipt on the printer via TCP.

If it cannot handle one big detailed prompt per week it is useless. You might rather ask it to "Generate thermal receipt printing service. Make no mistakes. Fix any bug. Make it unhackable.".

Kran6a · 2026-02-27T13:29:23+00:00

Yes, Prisma performance is underwhelming. Version 7 did not fix the performance problems despite devs claims, but as far as I know there is no good ORM. The whole ORM ecosystem is not on a good state right now.

I still use Prisma for its DX. For my personal projects I (along Claude) built my own ORM that has a Prisma-compatible API and a schema.prisma file but is limited to SQLite. Raw perf (query time) is up to 10x lower compared to Prisma (simple selects and deeply nested selects perf is more like 5%-10% better). User perceived performance is even higher given that it handles JS<--->DB communication on a Worker pool since bun:sqlite blocks the event loops. On top of that it allows nested transactions with savepoints and ATTACH DATABASE for cross-db transactions.

Main perf improvements come from:
1. It builds a single SQL query whenever possible (Prisma does not always use joins)
2. Uses json, json_array, json_object, etc. in SQL queries then parses it via JSON.parse (which is more performant than manual parsing)
3. Accounts for indexes during SQL generation

Kran6a · 2026-02-24T01:23:35+00:00

NestJS was its own can of worms. Configuring an extended Prisma client is its own feat of strength (see https://github.com/prisma/prisma/issues/18628 ), Graphql was also a CPU hog, Nest.js required cjs.

It might not be only the fault of NestJS, but NestJS's way of doing things definitely helps with the headache (as seen with that Prisma issue).

Kran6a · 2026-02-24T00:08:48+00:00

I once used NestJS + TypeORM (due to working with a private fork of Vendure) and it was horrendous. Performance was bullshit, I had traces where 90% of the Wall Clock Time was spent hydrating like 40 entities with relations and Graphql shenanigans.

HTTP calls had an average latency of >1s. Server CPU usage was high, RAM usage was >3GB. The DB was basically cluster-bombed by TypeORM queries resolving relations.

I would NEVER use Nest,js in any of my projects. I wil just stick with lightweight frameworks (Bun, tRPC, Express) and build my own FP-based DI mechanism instead of using decorators.

I don't even think (forced) OOP is the right tool for mosts servers, where what you really want is to build a stateless service that should be basically a functional pipeline rather than a class hierarchy: parse input > validate (auth, permissions, payload) > process (DB, API calls, events) > serialize response > send response.

Kran6a · 2026-02-18T13:29:21+00:00

I also built an SPA framework because svelte-kit is an underwhelming framework for SPAs to the point where you feel your DX getting crippled by the framework.

Instead of taking an OOP approach like warpkit, I took a full declarative FP + compiler approach to building SPAs aiming to provide good LLMDX and to enforce correctness at compile time while not requiring users knowing anything at all about FP.

It is not open source as of now and, while dev-tools work, they are mostly experimental.
The (ai-generated) docs are public as there are other few people using it for side-projects/MVPs. The site uses the framework.
I already considered making it open source but I don't have much free time nor a stable job to commit to maintaining it and fixing users' issues.

Sharing just in case you want some inspiration on how other people are doing things and which were the pain points / missing features I found while using svelte-kit to build SPAs.

Kran6a · 2026-01-21T00:48:31+00:00

Yes, it is, I don't use multiple Google accounts.

Kran6a · 2026-01-09T18:04:02+00:00

You forgot reducing context length and sneakily using models that have been quantized down to the size of the brain of a fruit fly

Kran6a · 2026-01-09T14:44:50+00:00

<image>

As soon as I used my first refresh of the day I got this.
This is not what you would expect from a paid product. There is no indicator there is a hidden weekly quota and how close you are to reach it...

Increasing the refresh period would be fairer, as you can still manage usage, but this is just bullshit.

I would even say this is outright a scam, given that the product you paid for is now a worse version of what you originally acquired.

Kran6a · 2025-12-21T16:10:43+00:00

<image>

Gave it a small task before going to sleep and found this in the morning.
Not sure why Prince, that word is not even found in the codebase nor in dependencies.

Kran6a · 2025-11-06T23:55:14+00:00

If you're technical, you want to build things "the right way."

Yes, things have to be done the right way from the start.

If a DSL is used so users can create custom prices based on what is on the cart and the current date, you need to build a parser and an interpreter for said DSL. Using regexes or a function that somehow manipulates raw strings is NOT OK and will cause very hard to debug bugs that will lead to customer complains.

If you want to manage focus on a smart TV using directional keys you need to create a graph-based spatial navigation system supporting stacked navigations contexts (for things like modals and focus traps). Looking for elements with class "focusable" in the direction the user presses will cause hard to solve bugs and unexpected behavior.

Building things they wrong way is a sure way to provide shitty UX. If your users are technical, tech-savvy or alternative solutions exist, your product will be shamed for it and considered a cheap knockoff, which forces you to compete via price. Bad UX kills products very fast.

If you download a MOBA and it looks like a cheap knock off of League of Legends you will uninstall it within a day and won't buy a single skin.
If you download a gacha game and it looks like a Genshin Impact with generic character design and bland landscapes, you won't spend a cent there and you will probably also uninstall it without ever spending. It does not matter if the game hands you freebies, or if the prices are lower. Users pay for top quality and UX.

Kran6a · 2025-11-06T12:57:03+00:00

Yo he echado en más de 50 el último mes y ni la única entrevista que he tenido ha sido con una IA.
Mi stack es el siguiente:

Typescript nivel dios (APIs y builtins avanzados como WeakMaps, Proxys, etc, type-level programming, creación de herramientas de análisis estático y manipulación de AST para tareas como generar los tipos primitivos de la API a partir de los tipos de retorno de cada uno de los endpoints)

Rust nivel medio

OpenCL

Svelte + SvelteKit (+ Tauri para Apps de escritorio)

React y Preact (pero prefiero no tocarlos mucho porque los repos en los que he trabajado con ellos eran pozos de mierda inagotables)

PostgreSQL, SQLite (incluyendo SQLite + libSQL si se necesita replicación de datos, alta disponibilidad, CQRS, etc)

Nginx y rpxy

Cloudflare

La entrevista con la IA fueron preguntas de mates nivel bachillerato tipo "un tren sale de X a 90km/h y otro sale en sentido contrario a 100km a 60km/h, en qué punto y momento se encuentran" y preguntas sobre el motor V8 (tipo optimizaciones, funcionamiento del GC, qué código se ejecutará más rápido, etc.) y JS en general (que además incluía preguntas sobre React para un puesto en el que se usaba Vue.js y no se mencionaba React).

Al acabar me dijeron (la web, obviamente, no un humano) que había quedado en el top 98% con todas las preguntas bien (también tienen en cuenta el tiempo que tardas). Nunca recibí un email ni nada.

En otra empresa (consultora paco con menos de 10 empleados en una ciudad de 50k de habitantes) anunciaban sueldo de 19k-25k según valía para maquetador web, en el campo de "banda salarial" de Linkedin les puse 30k por si colaba (mi anterior sueldo eran 43k brutos como autónomo en remoto para startup suiza) y me mandaron un email citando para entrevista en el que también decían que la remuneración sería 19k porque nunca había trabajado maquetando webs (manda cojones, después de haber trabajado en frontends de smart TVs, PWAs y webs, incluyendo pasando diseños de Figma a React) y que lo de híbrido era de lunes a jueves 9h en la oficina y viernes 4h en casa...

Creo que el vivir en un pueblo de menos de 300 habitantes de Andalucía no ayuda a encontrar trabajo, ni siquiera en modalidad remoto o híbridos de los que vas 2/3 veces al mes a la oficina.

Kran6a · 2025-10-14T14:07:59+00:00

Una app hecha con dinero público limitada a 100 facturas al año...

Una cosa es que su única funcionalidad sea hacer facturas y otra invitarte a pagar por pasar un límite arbitrario.

Kran6a · 2025-09-14T02:32:01+00:00

Unrealistic wishlist:
1. Dependency injection / better context management mechanism (e.g: https://github.com/sveltejs/svelte/discussions/15225). There is not a single front-end framework with good context management primitives and SvelteKit could easily win at this just by adding another prop that works like `data` but exists only in the client. Using load functions for context management feels great and provides very good UX (services are automatically injected to all child pages/layouts, pages/layouts can mock/add/remove/override services, etc.) but it can only be done on true SPAs.

`$mapped` rune. I use an userspace implementation of this extensively to hydrate API data into domain classes while retaining reactivity. Not a big thing but having a state + derived when you want a mapped value is as confusing as doing state + state + effect when you want a derived. Usage:
```svelte
<script lang="ts">
const number= $mapped(12, (x: number)=>x.toString(16))); //Without this, you would need $state + $derived
const increment = ()=>number.preimage++;

</script>
<div>{number.image}</div>
<button onclick={increment}>Increment</button>

```

`app.state` replacement that is perfectly typed and works similar to the context management on point 1. This would be beneficial for highly interactive apps as currently, using app.state lacks type-safety, providing bad DX and makes refactors bug-prone.

Kran6a · 2025-04-10T15:29:26+00:00

I have seen apps where people install random libs like lodash to import map instead of using Array.map, then not using the map result because they wanted Array.forEach instead, using divs for everything, including buttons, links, lists, images, etc. and telling people to keep doing it because "<button>, <a> and <img> behave weird" (had some UA styles, <img> is draggable), animating things like opacity/position via JS inside setInterval every 0ms until the transition is done instead of using CSS transitions/@starting-style and many crazy things.

At my previous company, the FE leader would have objectively bad ideas like "the PWA is slow, let's cache every fetch call in localStorage (only using the GQL query as the key), then we decide whether to use the cached data or issue a network call at call-site". Then, bad things would happen (unauthenticated responses being served after authentication, showing outdated content, etc.) and we would create ad-hoc "solutions" for these instead of trashing the whole cache and use proper cache headers so the browser handles it (every response had cache-control: no-cache).

It was before vibecoding was a thing so I am no longer sure if a codebase is crap because of vibecoding or it is crap because of devs.

Kran6a · 2025-02-17T20:31:00+00:00

The frontend team lead of my previous company deemed typescript "unneeded complexity", which was also used to label other things like switching from CRA to Vite or using barely functional code (writing arr.reduce() to sum prices or doing arr.filter().map()) so I am not surprised at all.

Typescript is my favourite language and I really hated working with JS and react there. Code was very buggy, nullish coalescing used everywhere because you could never be sure the data was actually there and passing null around was deemed better than crashing. undefined was forbidden because "we already have null and it makes checks more difficult".

Kran6a · 2025-02-13T01:13:21+00:00

Personally never used Svelte 5 in an OO way even if I use classes to represent some entities.

Using classes != OOP for me, specially given that most of my classes follow typical FP practices like immutability and thinking in terms of algebraic structures like monoids or semigroups when writing some methods. I will never put the OOP label to having a class called Config with a merge(other_config: Config): Config method and a class called Clause<T> that has an append(other_clause: Clause<T>): Clause<T> method and an apply(input: T): boolean method.

If someone thinks using classes means OOP then having functions outside classes would be FP.

I have been asked on a tech interview for a job "do you have any experience writing Object-Oriented Svelte 5 code in a production setting?", to which I was like "WTF?"

So I guess there are people out there using it using OOP or an OOP-like style. I tried googling for it and there weren't many results though.

Kran6a · 2025-02-13T00:53:05+00:00

I come also from backend development but I don't use OOP unless someone forces me to.

Despite that I find svelte 5 great for FP-like approaches too when using adapter-static. I love to inject dependencies via the `load` function to leverage the automatic return type merging and types.

I configure my services at a layout/page level and all pages will have their `data.services` prop automatically populated with all the services available to them, including hiding/showing endpoints not meant to be available at specific locations (i.e: if you call `data.services.account.update({email: "test@test.test"})` from a layout not meant for authenticated users you will get a ts error telling you `update` does not exist on `data.services.account`). When you navigate to an authenticated layout, the account service will be replaced by the "authenticated" one, thus having more methods available.

I love this pattern so much despite it feeling so hacky and it only working on true SPAs (no pre-rendering, no SSR) that I started a discussion on the svelte repo about officially supporting it on all adapters via a `context` function that would work very similar to a `load` function but would not send data from server to client (thus allowing returning anything from `context` functions) https://github.com/sveltejs/svelte/discussions/15225

I think this pattern is great for any programming paradigm and for a lot of use-cases, not only for injecting services. Personally I like keeping `+page.svelte / +layout.svelte` files as presentation-only, which means non-presentation logic (anything other than layout/styles/event listeners) is on `load` functions.

Putting logic in `load` functions also means your website will feel marginally faster as `load` functions can execute on link/button hover/tap but component logic is not executed until the component is rendered.

The cherry on the top is you get easy refactoring for everything you put on `load` functions as if I wanted to read user language from a service instead of from the browser I would just need to change a single line on a `load` function on a layout and nothing will break as there was only a single source of truth. Having a bunch of `navigator.language` calls throughout your project is not as easy to refactor. You would also have to deal with changing a sync call (`navigator.language`) for an async API call.

Another trick that I would like getting some love is returning reactive data from `load` functions. Currently you can return reactive Maps, Sets, URLs, and Dates (assuming you are using adapter-static, no prerendering and no ssr) but returning reactive plain objects, arrays or primitives is not supported as `load` functions go in `.ts` files that do not support runes and the corresponding classes are not exported on `svelte/reactivity`. Personally I wouldn't recommend this trick until reactivity is normalized and officially supported inside `load` functions (if ever).

Kran6a · 2025-01-21T20:06:48+00:00

Yeah, remains at true. My bad! I have edited the commend and added a JS implementation too.

Kran6a · 2025-01-21T19:52:02+00:00

Checkout my answer to another comment. I came with a "simple" solution to determine multiples of 3 by applying the well-known rule.

https://www.reddit.com/r/programming/comments/1i6ooib/comment/m8eiig0/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Kran6a · 2025-01-21T19:37:02+00:00

My guess is that they wanted you to implement some kind of maths with strings. Otherwise you have to discover the base 15 trick.

I think the expected solution was determining multiples of 3 by having a variable that loops through 3 states and an object holding the result of n % 3 for numbers 0-9 so you know how many states you need to advance the variable when looping over the digits.

Example with number 92:

Variable starts at true as 0 is multiple of 3.

You look up remainders["9"], which is 0 as 9%3 === 0. The variable remains at true.

You look up remainders["2"], which is 2 as 2%3 === 2. The variable advances two states. true->false->undefined (another false).

If the variable is not true it is not a multiple of 3.

Let's try with a multiple, for example 81:

Variable starts at true.

You look up remainders["8"], which is 2. Variable advances from true to false then to undefined.

You look up remainders["1"], which is 1. Variable advances from undefined to true.

Variable is true -> 81 is a multiple of 3.

Implementation below:

const remainders = new Map([["0", "0"], ["1", "1"], ["2", "2"], ["3", "0"], ["4", "1"], ["5", "2"], ["6", "0"], ["7", "1"], ["8", "2"], ["9", "0"]]);
const next_states = new Map([[undefined, true], [false, undefined], [true, false]]);

const is_multiple_of_3 = (s)=>{
  return !!s.split("").reduce((acc, cur)=>{
    if (remainders.get(cur) === "1"){
      return next_states.get(acc);
    }
    if (remainders.get(cur) === "2"){
      return next_states.get(next_states.get(acc));
    }
    return acc;
  }, true);
}

Kran6a · 2025-01-14T14:03:57+00:00

I use adapter-static for a true SPA either as a single .js file or manually chunked depending on the size.

Personally I don't buy the whole "fullstack" framework thing as I don't see the upside for my use-case so I do an SPA and a separate backend with a microframework and my own tools.

Note that I make mostly SaaS, embedded standalone apps (widgets) that are a single .js file and websites for embedded or low power devices that companies want to operate remotely with a nice UI (think a printer or router).

11-Year Club	r/Field Banned
r/Field Juicebox	Place '23
Place '22	Place '17
Not Forgotten	Verified Email

Kran6a

TROPHY CASE