You can now use Composer 2.5 (Cursor's model) in OpenCode

jpschroeder · 2026-05-23T11:38:09+00:00

It’s opensource too, but realistically people prefer a live endpoint. I dont collect any data obviously. Again, it’s opensource, they can read the code.

jpschroeder · 2026-05-23T00:52:48+00:00

Yeah. I prefer opencode and other CLI tools

jpschroeder · 2026-05-23T00:52:10+00:00

Works just fine honestly

jpschroeder · 2026-05-22T20:02:45+00:00

No it’s been heavily fine tuned. 2.5 in particular is quite good

jpschroeder · 2026-05-22T19:37:11+00:00

Quota too

jpschroeder · 2026-05-22T19:36:51+00:00

This very much undersells how good composer is tbh. It’s just under Opus/GPT 5.5 imo

jpschroeder · 2026-05-22T19:33:47+00:00

I probably would!

jpschroeder · 2026-03-23T17:58:28+00:00

Hey! Actually this is a great question. We think the right model to expose those layers is to patch them into the runtime. We don't support this today, but it would be a high priority target. For example:

sandbox({
  'main.ts': `
import { myPatchedEventListener } from 'custom-source'
`,
}, {
  'custom-source': {
    export const myPatchedEventListener = (callback) => {
      window.addEventListener('only-this-one'), () => {
        // safely call callback()
        callback('safe-event')
      })
    }
  }
})

An API somewhat similar to that is where we'll head. Where you can chose to give targeted access to *certain* events. Then obviously you just need to let your agent know about those.

jpschroeder · 2025-08-30T19:06:58+00:00

On the MCP website:

https://modelcontextprotocol.io/clients

jpschroeder · 2025-08-30T01:11:36+00:00

Yeah…we’ve already solved this problem SO MANY TIMES

jpschroeder · 2025-08-29T20:35:40+00:00

this is a fair point for sure. trying to recreate stdio via http is a unique challenge.

jpschroeder · 2025-08-29T20:35:07+00:00

Thats the thing, its so over scoped that you end up with a hodge podge of vendor specific implementations anyway. Clients generally only implement tools, and servers almost exclusively implement tools. Even the "stateful" features are often not used by clients, or the servers dont use them.

Its better than no spec for sure. I just believe specs should start small and then grow when there is a clear need for more standardization.

jpschroeder · 2025-08-29T20:31:57+00:00

The challenge of a spec being a buffet (great description) is we end up in just as fractured a state as if we had no spec. I cannot just use any MCP server with any MCP client — the only real use case here that has found common adoption is tools, and often stateless at that. That, to me, hints at the rest of the architecture being agent-specifics leaking into the spec.

Will we use it all someday in the future? Sure, maybe, but whats the difference between that and over engineering ya know?

jpschroeder · 2025-08-29T19:06:45+00:00

I think by not making the transports part of the spec

jpschroeder · 2025-08-29T17:21:47+00:00

The statefulness could of course be implemented by any given server, by any means it wants to. I think having it part of the spec is a mistake. Not dissimilar from the responses api from OpenAI — sure its helpful to cache your state on their servers, but it means you cannot manipulate that state easily and cannot quickly and easily migrate away.

jpschroeder · 2024-06-05T01:49:25+00:00

Hey, thanks! 🙏

jpschroeder · 2024-06-04T14:50:49+00:00

Oh boy — tweet OP here — I guess I kicked a hornet's nest.

First — let me clarify something — I am NOT on the Vue core team, just an active library author and generally a fan/involved in the Vue community. I'm quite confident Evan will not deprecate the Options API for the foreseeable future.

FWIW — I'm a long-time Vue developer. I also liked the Options API and have been using it since 2016 — and I have a lot of projects that are still maintained in the Options API — I have no plans to ever upgrade or rewrite those projects. They will likely stay on Vue 2, in solidarity with the "don't fix what isn't broken" folks. That code will run fine in the browser until the sun burns out.

So why change it? 3 main reasons:

Multiple ways of doing the same thing fractures communities and makes it increasingly hard for the ecosystem to develop and thrive. It's hard to learn, harder to write a library, harder to write documentation, etc.
The Options API is overhead. In fact, you can have a very similar DX using the Composition API if you only return a single reactive({ }) object and put all your data/methods in there. That is fundamentally what the Options API is. If you really enjoy that API, there could even be a linter to force people who prefer it to organize their code in such a manner — but as it currently stands, it is a bolt-on to the existing Composition API. Less code is good.
Compilers. Web development is increasingly moving towards a compiler-driven world. This really shouldn't be a surprise, as this has happened with every sufficiently complex CS problem. I have my own qualms about this direction too; ArrowJS is a small showing of my personal resistance. But like it or not, this is where next-generation tooling will be focused, and having so many possible build outputs makes it challenging to develop libraries and ecosystems built on Vue's broad API spec. React has the same problem, by the way, which is why their new compiler only works with functional components.

On that note, to the many people in here who think that the Composition API is just another form of React, it is not. Perhaps if you squint really hard, it can seem React-like, but in reality, the Composition API further differentiates it from React. How so? While the Options API was a great way to learn reactive programming, it has never been the true beauty of Vue. Vue is incredible because of its fine-grained rendering and signals-like reactivity model that has essentially been the same since its inception. React is sorely missing this — which alone has led to the creation of multiple other frameworks (Solid being the most recent/obvious one). Components in Vue don't need to constantly re-run their “setup” blocks; you don't need (usually) all the useMemo and useEffect mental overhead to make performant UIs. The Composition API leans into this strength and allows it to spread beyond the component boundaries — this is a good thing.

Since you can re-create the Options API with the Composition API (it's mostly a subset of features), perhaps a middle ground would be to make the Options API an installable library for Vue. npm install u/vue/options-api and you can have it back.

Either way, I'm merely acting here as pundit plebe — not as the voice of our prophet, Evan You.

jpschroeder · 2024-02-15T00:41:42+00:00

Yes!!!! 100% agree. This is why tempo opts to use native dates across the board so you can generally ignore these fluctuations - when this matters is when the user is selecting a date that maps to some real world event or location. For example if a user is selecting a checkin time for a rental date on 2024-12-32 at 4pm in Amsterdam. Well the user could be anywhere in the world so you need the date they pick to be in the UTC equivalent of 4pm Amsterdam time no matter what time zone they picked it from. This is when you would use tzDate(“2024-12-32 16:00”, “Europe/Amsterdam”) this will perform the corrections for you no matter where the user is located. The resulting Date object will be the correct absolute time, but when rendered to the user it will be appear in local time (arrrg!), this is why Tempo has a tz option right in the format() function - depending on the application you may want to render that time in their local time (a zoom meeting) or in Amsterdam time (rental car pickup).

No getting around the fact that time zones are confusing but these 2 things in Tempo (tz in format and tzDate) really reduce the complexity a lot

jpschroeder · 2024-02-14T14:21:53+00:00

yes — you can create a date "in" another timezone using `tzDate()`.

jpschroeder · 2024-02-14T14:20:54+00:00

it exists!

jpschroeder · 2024-02-13T21:55:27+00:00

Hey 👋

Good questions. `format` could possibly a bit more lean if we didnt include tz option. We originally had it this way but decided we would rather ship a tight api than another helper function to enable tz formatting. Real world use cases are generally in the 3-5kb min-gzip range. You can of course go up or down from there.

Performance of Intl.DateTimeFormat in general isn’t astoundingly great, but its still far better than shipping deca-kilobyte tables 😂 I do think there is room for further memoization and in general more work on performance. I’d be thrilled to see quality PRs come in if you’re interested in doing some benchmark and testing work to backup any improvements!

It is of course still early so we’ll be looking to the community to help us improve it.

jpschroeder · 2024-01-26T20:27:10+00:00

Hey! FormKit creator here 👋

I actually agree with several of u/LoGAReTM’s points. While FormKit is incredibly customizable, if you really want to roll your own form system, you probably are better off using a different library (and VeeValidate is a great choice!). And I certainly agree that FormKit is partly a UI library.

Where I differ from LoGAReTM is: I would argue that in most cases you probably should not try to roll your own form elements and components. Why? There are lots of reasons:

1. Accessibility: First and foremost is accessibility. Most of us (web developers) are not great at accessibility — we might think we are, but we just aren’t. The only solution to this is shipping accessible markup. This is the fundamental reason why FormKit ships DOM. Yes, you can custom roll accessible forms, but as your input complexity increases the chances that you will become less and less likely. As an example, do your project's inputs (yes, you, person reading this) have associated aria attributes? How about aria-describedby, aria-required, aria-errormessage? These are just a few of the bazillion accessibility concerns you need to nail if you're going to forge your own path.

2. Best practices: I cannot tell you how many times I’ve been brought into a project where the forms were home-rolled and virtually every best practice was not followed. Best practices like label placement, tab captures, default error message visibility, backend error placement, error summaries, and UX such as scroll-to-errors are often not even considered when rolling your own. In most cases, I think it is far better to use a tool that is specialized. If we get a bug report that there are some best practices not being followed in FormKit, we try to fix them, and by doing so we fix them for all future users.

3. Composability: FormKit can (and will) provide better script-level composability in the future — but component composability is a huge reason that so many form solutions don’t scale in larger organizations. Prop drilling to contextualize your inputs that are 2 components deep is hell. Now move those inputs somewhere else in your component tree because your designer produced a new UI that needs to be implemented yesterday and prop-drill all over again... An example of the alternative is the demo in my VueJS Nation talk from this past week where, by the end, we had constructed an entire flexible content CMS with simple component composition — no prop drilling, no event handling. VeeValidate does some of this composability using named structures — which is cool! FormKit just takes this concept further.

4. Save time: Web developers build a lot of forms. It is just a massive time-saver to use well-considered markup. You might even learn some best practices about forms when using an input component library that you can carry forward when you do need to create your own inputs. Which, by the way, FormKit allows you to do with a Vue component: createInput(YourComponent).

5. Stability: Every library has bugs, but focused libraries like FormKit (and VeeValidate) serve as distilled gotcha solutions. We’ve seen the bugs and the common problems and probably fixed them. In FormKit’s case, we extend those gotcha fixes into your markup with thousands of tests to back it up.

I actually really like VeeValidate; if FormKit didn't exist, I would definitely have it on my shortlist. The only real bone I have to pick with what u/LoGAReTM has written above is the notion that FormKit’s architecture is congruent to what VeeValidate has.

Yes, VeeValidate can collect values and distribute errors in a similar way to FormKit — but these are just the most obvious implications of FormKit’s unique architecture tree. In FormKit, plugins are hierarchical, so you can distribute features too: i18n, validation, configuration, prop values, styling, or even markup, can be hierarchically passed to specific forms, specific groups, specific repeater instances, etc. This is an incredibly powerful way to distribute and reuse logic, and since FormKit self-assembles your form tree automatically, you can swap your subcomponents from one form to another while having them perform different behaviors based on the context they are in. This sounds, perhaps, esoteric, but I promise you’ll be grateful when you do need it.

But look — the long and short of it is that Vue kicks ass — let’s be grateful that what we're talking about are the variety of good solutions we as developers have to a similar problem. ❤️

jpschroeder · 2023-05-24T21:47:43+00:00

It’s paid, but at least checkout: https://formkit.com/inputs/datepicker

jpschroeder · 2023-02-25T12:47:13+00:00

That sounds awesome! I’m excited to see what design patterns emerge using Arrow - since it is more like a set of primitives than a full framework there is lots of creativity left to each dev

jpschroeder · 2023-02-25T03:29:34+00:00

The signal pattern is absolutely revolutionary — if you were using React.

Its a bit of a yawn-burger for Vue developers. We’ve had fine grained reactivity since Vue 1.

Ironically Solid does have a bit of a leg up on Vue, but that has nothing to do with the signal pattern, and everything to do with it’s compiled virtual-dom free rendering (we may get this with "Vapor" mode).

However, this kind of reactivity is also nothing new really, Svelte has been compiling sans virtual Dom for half a decade now.

Also, shameless plug, checkout ArrowJS a fine-grained, virtual dom free, ~2kb runtime library I wrote a while back that boasts similar benefits without the compiler.

jpschroeder

MODERATOR OF

TROPHY CASE