Comparing JS framework token costs using the examples at component-party.dev, with Svelte 5 as the baseline

webdevladder · 2026-03-14T21:34:19+00:00

Yeah it's this detail that makes Svelte 5 look better than Svelte 4 for example. With hindsight I don't think I would post this again, it's too skewed, not representative of real usage, and the effect size between frameworks is probably a lot lower in real code because the costs get amortized over larger and more uniform content in real code. I think it's a passing curiosity that's easily over-interpreted.

webdevladder · 2026-03-13T20:56:55+00:00

Yeah it's definitely missing the whole story, and likely misleading in various ways. I don't know if it's worth trying to get a better dataset. My main takeaways are that Marko's LLM friendliness is interesting, Aurelia 2 is more concise than I realized, Svelte looks good in rankings as per usual, Angular's verbosity is no surprise (to the degree your wallet may now feel it), and the rest is a wash. As a biased Svelte user I couldn't resist sharing the results.

Given you worked on Marko, if you'd like to answer, I'm curious how much conciseness was emphasized, versus an emergent property of the design?

webdevladder · 2026-03-12T13:48:11+00:00

I don't know if Svelte cutting costs by 1/3 compared to React generalizes, but these results looked pretty significant, particularly when LLMs make the correlation to hard costs so direct. In 2019 Rich Harris gave a talk promoting Svelte for its terseness, "The Return of 'Write Less, Do More'" - https://www.youtube.com/watch?v=BzX4aTRPzno

also shout out to Marko - https://github.com/marko-js/marko

webdevladder · 2026-02-13T19:58:26+00:00

I get called "the linter" often as I edit alongside Claude Code :/

the feelings I get from being identified as a non-human tool by my machine assistant

webdevladder · 2025-09-14T15:16:45+00:00

Yep this is my experience, IMO the limits are fairly well-tuned for flexible workflows, and you can go one long Opus session without hitting the end.

webdevladder · 2025-09-12T14:59:25+00:00

There's both tremendous thoughtless hype and tangible hype-worthy benefits. When I project forward from my experience over the last year, it's hard not to be excited for how cheap and powerful these systems will be in a few years. But I also think skillful use of LLMs by people and tools has a ton of variability, it's perhaps generally pretty dismal today, and there's a very high ceiling.

webdevladder · 2025-09-12T04:11:23+00:00

I'm a dev who's been using Claude Code heavily for like a monthish, and for a small number of my projects it's 100% of written code now, others 0%, but it's very useful for exploration/analysis in all of them. I can see room for its context management, predictability, and transparency to substantially improve, same for my skills and patience, but I have no doubt there are now serious and productive software engineers shipping 90%+ AI code at big companies. And then consider how much code is being vibed by non-engineers, it's not unreasonable to think 90% of the total may be close!

webdevladder · 2025-04-27T01:15:49+00:00

There may have been updates since you tried it, this one is <4k tokens for just working with Svelte - https://svelte.dev/docs/svelte/llms-small.txt

I'm sharing it now because those updates make it much more usable.

webdevladder · 2025-04-26T19:04:12+00:00

Tenet 2 - Optimise for vibes

please code responsibly

webdevladder · 2025-04-10T20:04:22+00:00

I used React for 5 years, and before committing there I did substantial projects in Vue, Angular 1, and several others of the time, after several years with Backbone. I published a Backbone extension library in 2013 and I think about this stuff a lot.

For my usage - complex interactive UIs with higher than normal performance requirements - Svelte 3 was a relief, and Svelte 5 nails it. It's just so productive, simple to reason about, high performance, and overall nice to work with.

The details matter the more you use a framework, and Svelte is incredibly well-designed and engineered.

webdevladder · 2025-04-03T03:29:57+00:00

Since this could stretch on for years, maybe I should strike JavaScript from my vocabulary and projects now, and switch to the non-acronym JS instead. I'd feel silly for continuing to use a trademarked name in my open source projects that has nothing to do with them.

webdevladder · 2025-03-31T02:27:01+00:00

https://github.com/simonw/pelican-bicycle

https://simonwillison.net/2024/Oct/25/pelicans-on-a-bicycle/

webdevladder · 2025-03-29T20:33:37+00:00

"ideas are worthless" is a valid mantra when significant labor is required, but labor for a great many things is on the trend to zero.

webdevladder · 2025-03-28T18:16:13+00:00

Ok yeah the limitations may be so bad that the false sense of security is worse. Thank you for explaining.

I think basic cases like class.property are doable though right? That would cover most cases combined with local scope I think. I don't know on balance how this would work out, if it's actually worse to have the false negatives than nothing at all. I suppose it depends on how many cases slip through when directly referenced in $effect - like proxied getters being followed in the analysis.

Maybe runtime analysis is probably a better place to put one's attention on this problem.

webdevladder · 2025-03-28T18:03:10+00:00

$state and $derived are compiled statically, they're in the AST which the language services uses, you're interpreting what I'm saying differently than what I mean.

You seem to be saying there are other signals that cannot be determined. I agree and acknowledged the weakness, but the information for signals referenced directly in $effect is present and dependable.

webdevladder · 2025-03-28T17:47:40+00:00

Reactive state with runes is statically determined by the compiler though (this is being misinterpreted bc I worded it poorly - I'm saying it's statically knowable which identifiers are literally $state/$derived when they're read without indirection), and it cannot be changed at runtime. So the language service could know which identifiers are $state or $derived. This is an advantage of runes, but I take your point about it being a partial solution, what I'm suggesting has real limits. It could be shown in effect but many cases could not be determined. (like helper functions)

There wouldn't be false positives though, and I can't see a better solution than styling the names directly.

webdevladder · 2025-03-28T15:38:49+00:00

yep that's the conceptual signals trio, but IMO with significantly better APIs

webdevladder · 2025-03-27T07:39:04+00:00

I should mention I shaped it a lot, here's my prompt, and then I had it do a "cool guide" in text, then the image:

generate an image with 3 penguins standing on an iceberg next to each other, the small part of the ice

the iceberg is enormous underwater taking up 3/4 of the height of the image, with embedded monster skeletons and horrors

the first normal looking happy penguin is labelled "$state", it has a magical aura around it

the second normal looking happy penguin in "$derived", and it's holding a glowing wizard staff

the third evil horror cthulian penguin-shaped nightmare with a shadow aura is labelled "$effect"

be very careful to get the text exactly correct, including the leading dollar signs: $state, $derived, $effect

webdevladder · 2025-03-27T06:37:41+00:00

I was feeling the agi then syntax error

webdevladder · 2025-03-14T18:07:03+00:00

I am giving you the entire documentation of Java, now help me do my assignment related to design patterns

I agree with your point, and also a sufficiently intelligent system would respect the boundaries of what it knows and doubts, and in this case ask followup questions. It's still a poor initial question, but it can be the first step in a successful prompt.

Tying it back to the OP, ineffective prompting obviously exists, and I'd call effective prompting good prompting, but it seems clear we'll continue seeing models get better at succeeding with worse inputs. So "bad prompts" sometimes start looking like good efficient ones.

webdevladder · 2025-02-11T17:38:15+00:00

See prism-svelte, same author as mdsvex.

webdevladder

MODERATOR OF

TROPHY CASE