This sentiment only really applies if you’re coming from
Vue 1/2 to Vue 3. The Composition API is definitely more like React but makes some better design decisions that make it easier to work with than React. Such as implicit reactivity.
If anything, composition API has taken the good parts from React. Once you get the hang of it, it’s amazing. Everything clicks together, is easily composable, and fully typed-safe.
Yup I'd sign this. We use Vue2 in a old codebase with options API and composition API in new projects. Both feel way better than anything I ever had to do with React (how many Hooks do you have to learn by now? 13?)
Vue just has a very simple lifecycle and combined with a simple store like Pinia it's just really fun to work with.
I definitely sympathize with the feelings about the Composition API. Though I’ve moved past it because looking at React’s visible complexity (useMemo, useEffect - which apparently have changed names again since I last looked) - Vue has clearly chosen a superior API design.
Yeah you’re actually right I was looking at the API section instead of the Hooks section. Perhaps another demonstration of React’s verbose API surface.
It does, if you care about ergonomics. The reactivity model is simpler and arguably less error prone.
It does have its own templating syntax, which is trivial to learn. No more cumbersome to learn than JSX, which is a templating language designed by the React team. Not sure why you chose to make the distinction between JSX and Vue’s DSL as if JSX wasn’t developed for the sole purpose of facilitating React’s virtual DOM.
JSX is <div>abc</div> turns into createElement('div', null, 'abc') and you can use that instead of JSX if you like or you can use something like hyperscript. Everything else like mapping or if statements is pure JS and works just like JS anywhere else in your app.
Vue templates mean learning Vue's custom syntax for if statements, loops, dynamic attribute syntax (with its own gotcha), binding dot modifiers, data binding, and whatever else. It requires learning its entire custom directive system. It uses custom syntax for stuff like events too.
I don't see this as remotely comparable with Vue being much closer to something like my time working with Angular 1 (a time I'd rather not repeat).
It is a massive difference. I do not like magic compilers. The JSX transform is trivial and not even necessary, just create a factory function and React.createElement becomes arguably more readable, just not HTML like.
Is it a massive difference, or is it a small difference? At the end of the day 99% of React projects have a transpilation step and utilize some form of “magic compiler” somewhere along the line.
The simplicity of JSX is overvalued. It just means more code, and typically uglier code, to achieve the same behaviour as Vue. Which is basically the theme of React when you compare the two libraries.
It is more explicit code. Something only changes when I tell it to rather than being magical like in Vue, not to again mention its proprietary DSL and API.
JSX is a very thin layer of templating logic inside JS. Meaning you have all the language features available while templating. Some arbitrary JS can result in templating.
Vue's DSL is whatever language the developer implemented. Which is probably not enough, depends how much effort they put into it and how good they are in language design. Given that they cargo cult HTML tags to organize components in a pseudo-familiar but not-valid-HTML way, I don't have much confidence in their language design skills.
While I understand the advantage of using the built-in language features (and I know why it is required to be done that way), I still think using
{enable && <Form />}
for conditional rendering, or
{collection.map(x => <Item x={x} /> }
for looping are not the most obvious choices. If you ask people how conditionals and loops are written in JS, you will get 'if' and 'for' or variants of 'while'. So I get where the v-if and v-for are coming from.
Me personally, I prefer these more functional (and more succinct) expressions. For loops are overly verbose, and not as composable. But then again, I'm a Lisp programmer.
Had a couple thoughts in this realm, and am working them into my own harness. Curious to see what others think. I'm not sure if this is generalizable, as my harness is fairly specialized:
- Breaking down a problem into a planned execution, with executing agent providing the initial plan which includes explicit objectives such as which tools it calls and what it would consider to be a successful execution.
- The harness then executes the plan in order
- Each step that involves a tool call will be executed by breaking down the tool call into component parts: the harness interrogates the agent for a valid parameter value for the current tool argument. The tool definition contains validators for each argument. If the validator fails, the harness rewinds the conversation and injects the failure reason into the next try.
- Once the agent produces a valid response for the argument, the harness proceeds to the next argument.
- Once all the arguments have been filled, the harness calls the tool. It passes the agent's initial expected value along with the actual value, along with any errors that may have been produced and asks the agent if it is satisfied with the result. If it isn't, the agent provides a reason and the harness then retries the tool call process from the beginning rewinding the conversation and inserting the reasoning for the retry.
- The agent may request to re-plan if it discovers a flaw in its initial plan. The harness will also attempt to re-plan if the agent produces too many failures in a row.
This proves to be quite effective at reducing tool call failures. One benefit is that the sub-agent gets a perfect conversation history where it makes no mistakes. I'm not sure if it's actually better at completing tasks though, I haven't tried to benchmark it.
I went through a similar (in philosophy) exercise with my small-model agentic coding harness - built on forge.
A few things I noticed related to your points:
- on conversation rewind, I implemented a similar tool call collapse on the main agent (the one you chat with). Once it was done with a task, the tool call history was collapsed to keep the context clean - it was more about hygiene than size.
- the harness interrogating the model bit is a bit different, I haven't tried that approach. Forge relies on model self-correction in a bid to avoid having bespoke error modes, but I guess if you can abstract and automate the interrogation based on schema or something that could work!
Overall I like the clean conversation history aspect, but I suspect that you might be doing a lot of round trips for tools with many args, versus "letting it fail and giving it one nudge". That being said, it's an interesting idea for harder scenarios/tasks!
Yes, I was thinking about the same approach because I have Strix Halo and it slows down with longer context so context with less than <10k tokens would be achievable this way. If this could be done with small model that have >50tk/s that would be huge.
Unfortunately I am caught up right now in other projects at work and otherwise and just tried few dozens of prompts to see if this is even achievable.
Same. I switched my efforts to a larger Gemma 4 MoE model (26B-A4B) and llama.cpp and started getting meaningful results. I also implemented subagents for querying, determining which object/action to execute, and composing a short title. This is all running on an M4 in approximately 16 gb of ram. Also using Google's native tool calling channels.
The people working at the leading edge of this stuff seem to believe that there is a need for parallel models that solve different problems.
A crow exhibits some degree of intelligence in what is a very small brain compared to humans. There is overlap in the problem solving skills of the dumbest humans and the smartest crows.
So the question is: what is that? Yann LeCun seems to think it’s what we now call world models. World models predict behaviour as opposed to predicting structured data (like language.)
If your model can predict how some world works (how you define world largely depends on the size of your training data), then in theory it is able to reason about cause and effect.
If you can combine cause and effect reasoning with language, you might get something truly intelligent.
That’s where things seem to be going. Once we have a prototype of that system, there will be many questions about how much data you really need. We’ve seen how even shrinking LLMs with 1-bit quantization can lead to models that exhibit a fairly strong understanding of language.
I don’t think it’s unreasonable to expect to see some very intelligent low (relatively) memory AI systems in the next couple years.
Decentralized cooperation and associated protocols is a lot harder than just inserting messages into a MySQL database and then displaying those messages.
The future of air superiority, particularly with respect to sovereign defence is passive or quantum radar, autonomous A2/AD and directed energy.
reply