4 ms·

I don't want to be that person but there are hundreds of other similar frameworks doing more or less the same thing. Do you know why? Because writing a framewor

by _pdp_ 2y ago

I don't want to be that person but there are hundreds of other similar frameworks doing more or less the same thing. Do you know why? Because writing a framework that orchestrates a number of tools with a model is the easy part. In fact, most of the time you don't even need a framework. All of these framework focus on the trivial and you can tell that simply by browsing the examples section. This is like 5% of the work. The developer needs to fill the other 95% which involves a lot more things that are strictly outside of scope of the framework.

cpursley 2y ago
I agree, and it feels like JS is just the wrong runtime for agents. Really languages that can model state in sane ways and have a good concurrency story like Elixir make much more sense. And here’s a fun exercise: ask Claude via Cursor or Perplexity with R1 to create a basic agentic framework for you in your language of choice on top of Instructor.
- CharlieDigital 2y ago
  > Really languages that can model state in sane ways and have a good concurrency story like Elixir make much more sense. Can you expand on this? Curious why JS state modelling falls short here and what's wrong with the concurrency model in JS for agents.
  - dartos 2y ago
    For one, NodeJS doesn’t have concurrency. It’s a single threaded event loop.
    - CharlieDigital 2y ago
      It has concurrency with Promise; it doesn't have parallelism.
      - cjonas 2y ago
        And these agents are all network I/O bound by the model services so a lot of use cases don't need threading. I would argue that python is the overrated language when it comes to building agents. Just because it's the language of choice for training models doesn't mean it should be for building apps against them. The dx typescript brings to these types of applications is nice.
        CharlieDigital 2y ago
        > The dx typescript brings to these types of applications is nice. Ironically, it only gets halfways there. What I've found is that teams that want TS probably should just move up to C#; they are close enough [0]. The main thing is that once you start to get serious with your backend API, then data integrity matters. TS types disappear at runtime and it's just JS. So you need a Zod or Valibot to validate the incoming data. Then your API starts getting bigger and you want to generate OpenAPI for your frontend. Now your fast and easy Node/Express app is looking a lot like Spring or .NET...without the headway and perf...the irony. [0] https://github.com/CharlieDigital/js-ts-csharp https://github.com/CharlieDigital/js-ts-csharp
      - holoduke 2y ago
        No real concurrency. No scheduling. If you are not working with a lot of IO then js would be a poor choice. But in this case we talk about network calls, so definitely IO. The settimout, promise, request methods will do their job.
- mikehostetler 2y ago
  > good concurrency story like Elixir make much more sense Agree, that's why I've been building this: https://github.com/agentjido/jido https://github.com/agentjido/jido
  - MattDaEskimo 2y ago
    Call me an elixir virgin until 5 minutes ago. This language from a quick glance seems perfect for agent orchestration. Project looks great, will follow & learn.
    - cpursley 2y ago
      It's less about the language syntax and more about the capabilities of the underlying Erlang runtime. There's also Gleam on top of Erlang if you like stronger typing (gleam.run).
fullstackwife 2y ago
You could describe all frontend JS frameworks the same way: you spend 95% of time on content and mechanics of your webapp, while the framework provides the easy 5%.
- chipgap98 2y ago
  I think most JS frameworks save more than 5% of the effort for developers compared to writing raw JS. Especially when you include the ecosystem around those frameworks
fsndz 2y ago
True. That's the reason I see a lot of people dropping similar frameworks like LangChain recently: https://medium.com/thoughts-on-machine-learning/drop-langchain-and-instructor-use-this-alternative-for-structured-output-generation-30f0b503c6d0 https://medium.com/thoughts-on-machine-learning/drop-langcha...
- jerrygoyal 2y ago
  i was using vercel ai sdk for my production app and it was such a bad experience that I eventually went with native implementation and tbh it was not much of work thanks to cursor. problems i faced: too many bugs (just browse their github repo to get an idea), the UI side also had suboptimal performance based on how they implemented hooks.
  - ilrwbwrkhv 2y ago
    vercel's whole shtick is to make money off of dumb js devs who do not know better. i think they pay far too much attention on how things look compared to how things work. but hey, they made millions, possibly billions off of those js devs so who is to blame them.
calcsam 2y ago
Some people don't like frameworks. Some people do. We have a little bit of experience building frameworks, so we figured we'd build a good one.
- santa_boy 2y ago
  I love frameworks :)
incanspyder 2y ago
Couldn't agree more. This also looks mostly like a Typescript "port" of Langgraph, and I say "port" because Langgraph has a TS framework already.

by _pdp_ 2y ago

cpursley 2y ago

I agree, and it feels like JS is just the wrong runtime for agents. Really languages that can model state in sane ways and have a good concurrency story like Elixir make much more sense. And here’s a fun exercise: ask Claude via Cursor or Perplexity with R1 to create a basic agentic framework for you in your language of choice on top of Instructor.

CharlieDigital 2y ago
> Really languages that can model state in sane ways and have a good concurrency story like Elixir make much more sense. Can you expand on this? Curious why JS state modelling falls short here and what's wrong with the concurrency model in JS for agents.
- dartos 2y ago
  For one, NodeJS doesn’t have concurrency. It’s a single threaded event loop.
  - CharlieDigital 2y ago
    It has concurrency with Promise; it doesn't have parallelism.
    - cjonas 2y ago
      And these agents are all network I/O bound by the model services so a lot of use cases don't need threading. I would argue that python is the overrated language when it comes to building agents. Just because it's the language of choice for training models doesn't mean it should be for building apps against them. The dx typescript brings to these types of applications is nice.
      - CharlieDigital 2y ago
        > The dx typescript brings to these types of applications is nice. Ironically, it only gets halfways there. What I've found is that teams that want TS probably should just move up to C#; they are close enough [0]. The main thing is that once you start to get serious with your backend API, then data integrity matters. TS types disappear at runtime and it's just JS. So you need a Zod or Valibot to validate the incoming data. Then your API starts getting bigger and you want to generate OpenAPI for your frontend. Now your fast and easy Node/Express app is looking a lot like Spring or .NET...without the headway and perf...the irony. [0] https://github.com/CharlieDigital/js-ts-csharp https://github.com/CharlieDigital/js-ts-csharp
    - holoduke 2y ago
      No real concurrency. No scheduling. If you are not working with a lot of IO then js would be a poor choice. But in this case we talk about network calls, so definitely IO. The settimout, promise, request methods will do their job.
mikehostetler 2y ago
> good concurrency story like Elixir make much more sense Agree, that's why I've been building this: https://github.com/agentjido/jido https://github.com/agentjido/jido
- MattDaEskimo 2y ago
  Call me an elixir virgin until 5 minutes ago. This language from a quick glance seems perfect for agent orchestration. Project looks great, will follow & learn.
  - cpursley 2y ago
    It's less about the language syntax and more about the capabilities of the underlying Erlang runtime. There's also Gleam on top of Erlang if you like stronger typing (gleam.run).

fullstackwife 2y ago

You could describe all frontend JS frameworks the same way: you spend 95% of time on content and mechanics of your webapp, while the framework provides the easy 5%.

chipgap98 2y ago
I think most JS frameworks save more than 5% of the effort for developers compared to writing raw JS. Especially when you include the ecosystem around those frameworks

fsndz 2y ago

True. That's the reason I see a lot of people dropping similar frameworks like LangChain recently: https://medium.com/thoughts-on-machine-learning/drop-langchain-and-instructor-use-this-alternative-for-structured-output-generation-30f0b503c6d0 https://medium.com/thoughts-on-machine-learning/drop-langcha...

jerrygoyal 2y ago
i was using vercel ai sdk for my production app and it was such a bad experience that I eventually went with native implementation and tbh it was not much of work thanks to cursor. problems i faced: too many bugs (just browse their github repo to get an idea), the UI side also had suboptimal performance based on how they implemented hooks.
- ilrwbwrkhv 2y ago
  vercel's whole shtick is to make money off of dumb js devs who do not know better. i think they pay far too much attention on how things look compared to how things work. but hey, they made millions, possibly billions off of those js devs so who is to blame them.

calcsam 2y ago

Some people don't like frameworks. Some people do. We have a little bit of experience building frameworks, so we figured we'd build a good one.

santa_boy 2y ago
I love frameworks :)

incanspyder 2y ago

Couldn't agree more. This also looks mostly like a Typescript "port" of Langgraph, and I say "port" because Langgraph has a TS framework already.