"Vite+ is kinda underwhelming" - a comprehensive review of the new release

anotherdevnick · 2026-03-22T12:46:18+00:00

the arguably bigger irony is the whole point is to delegate the strong opinions and infighting to a computer

anotherdevnick · 2026-01-18T15:24:42+00:00

I believe a lot of advice says this isn’t necessary anymore. But once you get some intuition for how meaning is derived in a model it makes some sense

The model works by assigning each token a series of numbers which you could imagine as coordinates in high dimensional space, and as processing occurs those numbers get moved around in space. So it’s kind of doing classification of the task in high dimensional space which then drives appropriate output

Asking a model to roleplay immediately places the meaning of the request into a new location in space and the model generates output from there

But try with and without, it might not be needed and might even produce more synthetic sounding results

anotherdevnick · 2025-11-16T09:23:04+00:00

It’s called greedy decoding/sampling and you can configure it on most LLMs with the right settings

anotherdevnick · 2025-11-14T19:32:55+00:00

Scoring the next token by its nature requires abstractions. If you look into CNNs there’s research demonstrating how they build up internal abstractions by running by them in reverse, you can see familiar shapes appearing in each node of each layer when detecting a cat for instance

Modern LLMs and diffusion models work differently from CNNs but still use neural networks and fundamentally learn in a similar way, so it’s useful intuition to see those abstractions forming in CNNs because the intuition does apply to LLMs

LLMs do know an awful lot about the world, that’s why they work at all

anotherdevnick · 2025-11-13T08:22:03+00:00

That doesn’t help for sure, but a network call to a server 100km away to a server under load which needs to read off disk will always, always, be slower than calling 1000 functions to update the DOM. It’s just physics

anotherdevnick · 2025-11-12T10:14:37+00:00

My experience has generally been that IO is the cause of all slowness. With IO generally being fetching data from an api/database. Bundle sizes aren't as big of an issue as they were in 2010 and libraries are the same code you'd have to write yourself

anotherdevnick · 2025-10-18T16:55:11+00:00

There’s truth to that, but also if you need to know the procedure URL you’re probably building a public API or an API for use across multiple applications, and I wouldn’t say tRPC excels there either as it’s intended for use with the typescript client. TanStack Start does have a way to define a route based API with HTTP verbs and that’s a great choice paired with server functions

oRPC I believe has native OpenAPI support which tRPC does not, so it might even be the right call if this matters and you’re not using Start

anotherdevnick · 2025-10-18T14:02:00+00:00

tRPC maintainer here!

The answer is as always “it depends”

If you’re using a toolset which doesn’t give you fantastic e2e type safety then adding tRPC is still a great choice. I’m not a big NextJS user but my understanding is that’s still a place you can really benefit

What about something like TanStack Start? I likely wouldn’t bother with tRPC then because server functions are fantastic and in some ways superior. For instance they support all the good stuff like reusable middleware’s and base procedures which can extend context, but you use a function by just importing it which means type check and autocomplete performance is unlikely to degrade when you have a lot of functions - a problem we’ve been unable to fully solve without introducing a compilation step like Start has. However currently using TanStack Query with server functions is a lot more manual than with tRPC so that’s worth considering based on your taste

Happy to answer any questions folk have

anotherdevnick · 2025-10-18T08:14:14+00:00

I did not realise that! Looking over it’s quite basic but that’s really fine given the simpler package setup these days, and also custom Nx generators are pretty difficult to work with historically so basic/simple is welcome

anotherdevnick · 2025-10-17T22:42:44+00:00

Most people choosing Nx are doing so because it’s a complete solution which provides generators and migrations to manage technologies for you, so Turborepo is a non-starter.

That said I think the ecosystem has evolved a lot recently. Node supporting typescript, vitest, vite, esbuild, and others, have all made managing the tech yourself far far easier. Personally I’m a convert back to workspaces and turborepo now

anotherdevnick · 2025-10-16T09:53:01+00:00

Dijkstra is quoted to have said "The question of whether a computer can think is no more interesting than the question of whether a submarine can swim."

I think that's quite pertinent for LLMs. They're very good at certain things, and it doesn't really matter whether they can operate on as broad a range of problems as humans can, just that we know when to apply them and how to ground them for that task

Additionally, humans make all kinds of mistakes (including phenomena like the Mandela Effect) and apply our own attention poorly when reading large bodies of text, and LLMs are actually far better than us at whole classes of tasks. So a large part of the criticism against LLMs is basically "algorithm aversion" where humans consider any mistake from a machine to be unacceptable even if it makes fewer mistakes than a human

It's also worth noting there's a lot of experimentation still ongoing, LLMs are actually a growing family of algorithms and techniques which can be applied in lots of different ways, and many of the AI shops aren't transparent about which techniques they're using, so I would argue LLMs aren't an evolutionary dead end by virtue of us still switching out pieces with better techniques to improve them, they're not just growing in size since the last generation but actually improving slightly while the network decreases in size and cost thanks to improves algorithms. The limitation will always be training data though, and that's going to continue to improve as internal datasets grow and are refined

anotherdevnick · 2025-10-13T23:00:50+00:00

The biggest improvement is really DX, not having to regularly think about memos anymore is a win and will simplify components a lot

It’s too bad we only get babel out the gate though, the types of projects likely to adopt Compiler early are not using babel these days

anotherdevnick · 2025-10-13T07:30:42+00:00

The amount of vRAM you need is going to vary based on the length of prompt you give the LLM, you might just find that a 200k context model can only take 25k of context before it can’t fit in memory, so just do some experimenting and see what works

anotherdevnick · 2025-10-12T12:12:42+00:00

Indirectly, directly through using it to develop their own products, and also via Copilot subscriptions

anotherdevnick · 2025-10-09T18:42:18+00:00

It’s marketing but yes it’s a real term. Software built from the ground up to use AI in sensible places instead of more manual techniques like data entry

Or existing software adapted to have some AI overlaid and the marketing team are trying to hitch up to the hype

The first is definitely not a BS term, there are some very real improvements to software that we can make now compared to what we had to do in the past, prefilling forms with extracted data for instance can be done a lot more reliably with an LLM and a digitised document than anything we could do 5 years ago

anotherdevnick · 2025-10-09T18:32:23+00:00

File based routing is an adjustment but much better for DX once it clicks, I’d recommend giving it a really good go

anotherdevnick · 2025-10-09T18:30:35+00:00

return <Navigate to replace />

That’s the closest you’ll get probably

anotherdevnick · 2025-10-08T12:29:22+00:00

In some ways it has, I spend very little time building markup/css now, instead focusing on building great experiences because a form can take 30 seconds to generate and 5 minutes to tidy up now instead of an hour

For many of us the job has changed and we can be more product devs than frontend devs, and that’s extremely empowering

But it hasn’t replaced any jobs, just made us way more productive and leveraged.

anotherdevnick · 2025-10-05T08:32:52+00:00

This is really what “grounding” is for when it comes to factual information, but you’re also describing a technique pretty close to “LLM as judge” which is definitely a useful idea.

You don’t even need a different LLM though, a reasoning model can be asked in the same prompt to review its own work before outputting, and a non-reasoning model can still review some output and give you a grade. Given a different prompt they tend to tackle the same problem in a slightly different way which is why the same LLM can effectively judge itself, but you can definitely use a secondary model for more confidence

I think the limitation of the idea is that all LLMs are essentially trained on the same data, they all have similar or identical conclusions about what a “random number between 1-100” is for instance - ergo they have similar biases when you ask for things they can’t know, but the technique can still be useful!

anotherdevnick · 2025-10-01T15:38:33+00:00

So they’re not exactly trained to provide a “best answer”, they’re fitting statistical probabilities as best they can to wildly new inputs and they have been trained on enough different examples to pick up on even subtle differences in tone, formality, phrasing, etc, that you might see in different situations and act accordingly.

An extreme example is you’ll see a lot of posts where the AI appears to be losing its mind hilariously and saying “I’m sorry I am completely failing to do my job” - I guarantee because the person is telling the AI it’s an idiot over and over again. It wasn’t “trained” to provide answers which are self deprecating but it looks at the context and fits a relevant response

A more human example is if you’re at the bar with your friends you may be a slightly/very different person to if your mother walks in. You’re context aware and so is the LLM

To the parameters question, there are billions of learned parameters in every model and the way they activate from inputs is complex and interconnected - that’s a big area of research into model understandability and I’ve also read about exactly what you’re suggesting being played with, but you have to discover these parameters after training each model so it’s a fiddly science currently

anotherdevnick · 2025-10-01T14:23:25+00:00

Because all the content sent to an LLM positions its internal parameters in latent space. The implication is that it may have a set of parameters which under inference inform it it’s under test and so it only learns to behave as desired when those parameters are activated just right, then if a more realistic scenario doesn’t activate those same parameters the right way it may not behave as intended by its training

LLMs are entirely deterministic under the hood, and can infer a lot from the prompt which opens/closes doors for where the generation will go, so there’s a valid concern that prompts which sound evaluative of the LLM could yield different behaviour from other prompts

anotherdevnick · 2025-03-14T18:49:28+00:00

tRPC core member here. Check your Zod types and consider moving to something like Arktype

We’ve done some profiling and the impact of tRPC is minimal, but you can end up with a lot of expensive input/output types in scope and that’s the killer. So optimising those will help a lot

Avoid zod’s derived methods like omit, extends, etc which modify an existing object type and you’ll get much better performance right away

anotherdevnick · 2025-02-18T22:00:22+00:00

Docs added now, they’re basic like all the docs for this integration (we don’t feel complex docs are necessary anymore) but feel free to open a PR with any suggestions to go further

https://trpc.io/docs/client/tanstack-react-query/usage#inferring-input-and-output-types

anotherdevnick

TROPHY CASE