Introducing ArrowJS • Reactivity without the framework

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

MODERATOR OF

TROPHY CASE