MatthewPhillips

We unfortunately released Astro 6 only a few weeks before Vite 8 / Rolldown came out, which is why we did Astro 7 so soon. But there are very few breaking changes compared to Astro 6. That being said, some of these performance improvements (the Sätteri processor) are available in Astro 6 too.

How many pages is it? The performance improvements are mostly for larger sites (thousands of pages) and especially when using a lot of MDX.

We're working on incremental builds which should help as well: https://github.com/withastro/roadmap/issues/1388

Can someone explain the whole thing about wanting to attach it to your phone? Why? What does this provide over just putting it in your pocket?

Ok sure, the "never" was a bit strong here. Running CLIs on phones is not a normal thing and not as simple as it is on desktop. Apple prohibits apps from downloading and executing code, so some sort of new Apple-approved thing would be required here. That's a very heavy lift.

Of course anything is possible, I just don't think that people advocating for MCP's death have really thought through these problems, and are mostly focused on the desktop productivity use-cases.

Ok, I can see there's a new (to me) Customize section where you can install skills. You have been able to connect MCP servers for quite a while.

The UX here isn't great, but let's assume it can be improved. How would auth work with this alternative method? I want to connect to Puma store and that's done using a skill with a CLI. Can the CLI launch your web browser to do oauth from the skill (on a phone)? And then the credentials are saved where?

Not challenging you, I'm open to alternatives to MCP for sure. But MCP seems way more mature especially for non-programming use-cases.

Walk me through how a user installs and then uses these CLIs from their mobile phone.

How is the user installing the CLIs? Proprietary app store for each chat app?

Please keep in mind that CLIs do not run on mobile and never will. This is the elephant in the room that nearly everypne seems to be ignoring. This "debate" is built around the assumption that AI is only for at-your-desk work. It's obviously not. Having the ability to mix/match the services you use for everything in your life, whether that's email or social networks or managing your book collection, is going to be a normal thing everyone does in the future. It's just not today, because AI companies are almost exclusively focused on the programming use-case (and related desk job stuff).

Every new generation thinks things were better when they were young. Personally I liked the internet of the mid to late 90s, just as the web was overtaking AOL. By the mid 2010s, which this article calls the golden age, the internet was already very commercial; personal sites barely existed, most activity took place in walled social media gardens.

I bet people older than me disliked the 90s web and preferred the days of gopher and newsgroups. No one is wrong and everyone is wrong.

Part of the reason things felt better when you were young is because it was; for you. Fewer responsibilities. Less understanding of the nuances and intricacies of the world. More room for idealism. Another part of the reason is that time tends to fade away the bad parts of life while retaining the things you enjoyed. This is good.

Nostalgia is great for reconnecting yourself to a simpler time in your life. Nothing wrong with that. But when you start making comparisons you're only fooling yourself.

This limits AI usage to desktops, and mostly technical oriented tasks. MCP let's you connect to your email, shop, etc, from phone chat apps.

Yeah, I didn't take it that way, just thought it was worth clarifying that this isn't a case of AI hitting a wall or anything like that, I just went down other rabbit holes.

The reason it's only 73% is because I prioritized fun stuff like self hosting and platform binaries. I think finishing off the standards would only take a few more hours (except eval which I don't plan to do).

I have a preview release ready, if you scroll down you'll see the instructions. If you're able to try it out and leave a comment on whether it fixes your issue it'd be a big help.

Sorry we haven't fixed this issue sooner. In this case it's a complicated CSS issue, but nevertheless I've got a fix I'm working on here:

https://github.com/withastro/astro/pull/15227

I think this really undervalues what Linux provides. The Android software is Linux software.

This looks amazing. Well done.

Hey, I'm the author of this doc. The reason for the pattern is to make it so you always can find why a mutation occured. So combining state variables and dom changes is ok as long as that's the only place that does the mutation. If not, now you've made it harder to debug. I keep the strict separation so that I can always stick a debugger and see a stack trace of what happened.

Writing a language, even a DSL is a lot of work. It's not enough to just make a good language, there's also a whole world of tooling support that people expect nowadays.

Also ultimately it was hard to sell the idea of living in a different file format from the rest of your code. This is always a tough sell for DSLs. Even languages as good as CSS and SQL struggle with this for a lot of devs.

First, we have just launched and are still figuring out pricing, this is a great point of feedback that we'll consider, thank you.

What differentiates Astro DB is the deep integration with the Astro framework and providing an easy path for common scenarios. Astro DB is a higher-level product than using a database service directly. For example, Astro DB handles migrations transparently for you and guides you when manual intervention is needed, just from running `astro db push`.

Astro DB also includes a local story, by default you use a local SQLite database that you can seed (using db/seed.ts) for local development. You can even use it for a purely static site, although we're still working on making SSG use-cases more seamless. For now though, this gives you a great local workflow for development that you can think easily connect to production with `astro build --remote`.

This is a very good question! One of the big reasons we partnered with Turso was for their edge network, so replicas are available close to your origin server. Being able to host anywhere is something that's important to Astro, so this felt like the right balance. Turso is known for its speed and one of the main thing that attracts people to use it.

It does use libSQL, yes!

Hey, I'm one of Astro's co-creators, happy to take any questions on Astro DB you may have!

Thank you!

Updated the site, sorry about that. I copy pasted from Twitter which automatically added the http. This is just regular SSH.

I don't think that was the plan from the start. There definitely was talk that it would eventually replace Gecko, not just be used for parts.

I am, thank you. : - )

If you expect to be able to develop with the file protocol you're going to be disappointed. Essentially all modern features don't work with it; not just ESM. You can't use Service Workers with the file protocol either.

I'm not sure what you mean by all or nothing thinking here.

I mean this:

Want to do the supremely simple task of importing a JSON file?

Surely you realize that "importing JSON" is not something every project or page needs. By "all or nothing thinking" I mean the idea, which you expand in this response, that unless it supports everything it's not worth ever using. But that's a false dichotomy. A lot of projects are simple. A lot don't need all of these advanced bundler features. Those projects can (and do) use bare ESM in the browser. And that's ok.

To answer your question more directly, the reason they do it this way is because bundling dozens of features into a spec and then releasing them all at once has never worked in the history of web standards. For better or worse, doing one small thing at a time is what works.

You really don't have to worry about these things until your module graph is > 100 modules. You are falling into "all or nothing" thinking here, because you need tools in some use-cases doesn't mean that a feature is worthless. Not needing tools for small projects and then needing them for large projects is pretty good tradeoff.

I'm very curious what their business strategy is.