Yeah but this seems like a bolt-on and not something they train their model to understand at the token level like how they do tool calls. Maybe Anthropic has a token-level skills support (e.g. <SKILL_START>skill prompt<SKILL_END>).
Long-running tasks are an open topic of discussion, and I think MCP intends to address it in the future.
There are a few proposals floating around, but one issue is that you don't always know whether a task will be long-running, so having separate APIs for long-running tasks vs "regular" tool calls doesn't fully address the problem.
It'd be nice to more closely integrate MCP into something like Airflow, with hints as to expected completion time.
Real world LLM is going to be built on non-negligible (and increasingly complicated) deterministic tools, so might as well integrate with the 'for all possible workflows' use case.
RSC is indeed very cool. It also serves as a superior serialization format compared to JSON. For example, it can roundtrip basic types such as `Date` and `Map` with no extra effort.
One thing I would like to see more focus on in React is returning components from server functions. Right now, using server functions for data fetching is discouraged, but I think it has some compelling use cases. It is especially useful when you have components that need to fetch data dynamically, but you don't want the fetch / data tied to the URL, as it would be with a typical server component. For example, when fetching suggestions for a typeahead text input.
I discussed it with a couple of Next.js maintainers (https://github.com/vercel/next.js/discussions/75930), and they indicated that it's only a problem for "standalone" deployments (i.e. not on Vercel). However, I'm not entirely convinced that is true. I wonder if there are major optimizations that could be made to, for example, the routing system.
I have no particular views on performance but the thing i keep hearing about next of 'this is solved by using one particular hosting provider' really surprises me as something people are ok with.
I think people reasonably expect, say, an aws lambda to be aws specific.
That's a very different story to React, which is supposed to be a library for general application ui development, and the official react documentation recommending Next as the way to use it.
I've been using React on and off since 2017 or so. Back in the day it was typical to bundle your React code and integrate it with the backend framework of your choice. It was stable and cheap. In the 2020s frontend tech took a bizarre turn...
Is he wrong though? Next.js reason of existence is essentially that .json file navigation. The addition of server side compute (ie: middlewares, router, etc...) is mostly a business decision that the framework has nothing to do with as it breaks your back-end/front-end separation (unless your application is very simple to fit in a nextjs function).
> and they indicated that it's only a problem for "standalone" deployments (i.e. not on Vercel)
The fix is clearly to take out your wallet /not.
NextJs is slow. It doesn't have to be. For their swc, turborepo and everything else going on they could have made the actual production usage fast just as well.
Upcoming in Rails 7.1, you can specify a custom compressor for your cache, out of the box. See the `:compressor` option of `ActiveSupport::Cache::Store.new`:
- https://community.openai.com/t/skills-for-codex-experimental...
- https://developers.openai.com/codex/skills/
- https://github.com/openai/skills
- https://x.com/embirico/status/2018415923930206718