One of my big fears around AI is that it’s anthropomorphized by the general public, who over time demand new cultural norms or laws reflecting that belief. I can’t believe the frontier itself is now pushing that view.
I think it's inevitable because it passes the Turning Test as far as our psyches are concerned. It interacts in a way that can influence us like another person. Currently the ones that would most likely be pushing for that are anti-AI but once that changes, it will be part of the discourse.
Sort of. It knows a lot about places, say, Paris. But it's not a person so it's never actually been there. A person who's been there can tell you about their trip. What they saw, what they ate. An LLM can't tell you those things because it hasn't. I'm sure one could be instructed to lie and make up a believable story about it, but as currently configured, ChatGPT doesn't default to lying about it and thus fails the Turing test.
Yes, obviously. How about your home town last or the last trip you took? What were your parents like? What was your childhood like? What did you do last week? AI could certainly generate convincing sounding answers to that, but ChatGPT isn't set up like that and would thus fail the Turing test.
I love the hands-on developer experience of programming in Svelte. But since we're in October of 2026 I have to ask, is the vibe-coding experience in Svelte any different than in React? Can anyone with experience in both comment?
Yes. We open sourced an SSG based off SvelteKit about a year ago and were starting building AI tooling and product workflows around it, https://statue.dev but have since mothballed it.
For most of 2024-2025 frontier models really struggled with Svelte 4 vs 5 compatibility issues. Some of the main contributors, to their credit, really put in a lot of work to create benchmarks/MCP/other tools to make AI better at using Svelte. Personally I am just not a fan of MCP and other tools like that at all, and decided I'd rather just use vanilla css/js for new projects.
Look at this; it's literally multiple times more expensive to have a model sifting through all this stuff in every context use them with a tool: https://svelte.dev/docs/ai/prompts/llms.txt All of these are input tokens and turns to gather context.
The "too niche to be a major training priority" dilemma is actually a really big problem that almost all new or emerging dev tools have now. Incumbents and category leaders are priorities and show up in major benchmarks, so models develop excellent tacit knowledge and capabilities with them and expose it everywhere all the time for "free" in their weights. Everything else is at a major disadvantage because models don't know about them, how to use them, how they work, what they're for/why, and every time you use them you pay a big capability and token hit because models only learn about them in-context.
I don't blame the Svelte team for this at all. There should be a better way for devtool projects to contribute to frontier labs training pipelines or properly posttrain their own agent coding models.
We had an existing sveltekit application and its components, tooling, etc and used statue to develop the landing page/legals/docs/marketing portion of our site as an SSG, deployed separately but with shared logic.
Our application was behind a proxy that requires auth, and we could host our SSG on Cloudflare pages, so we didn’t have to expose any application server/compute (besides auth) to the public Internet. To me this was very desirable for security and devex: we could develop the two applications independently and be pretty lax with the static site.
> and decided I'd rather just use vanilla css/js for new projects.
So is the rise of AI coding, the end of frameworks?
Frameworks were created to reduce boiler plate ( at the expense of new abstractions which occasionally leak ) - boiler generation is less of an issue for AI, and the underlying platform is very well specified?
I guess the only problem with vanilla is if the sheer volume of text overwhelms the context?
Vanilla css/js are not really that voluminous. Actually, they tend to be smaller than the compiled targets you get from conventional web dev builds.
I’m not really sure that most web frameworks reduce boilerplate. There is a lot of boilerplate involved in setting up routes, and builds, and so on. As far as I can tell they only really make sense for very large teams (who need a uniform shared data model, design language, processes, etc.) and people who really want to run server side js/do a lot of SSR.
The thing about web “frameworks” is that they’re not that different in structure from what you’d build to do SSR and a repeatable way to add pages/dirs and shared assets, in any language. You can build a minimal version of something that does that in less than an hour, at least in Go. go:embed and a factory method for handlers :)
I think we’ll all end up with more bespoke “frameworks” (specialized web servers) with less gravitational pull towards dysfunctional (IMO, the node ecosystem) tooling, and still have many people using the best major frameworks. Truly large projects will still need to use react and svelte and co unless they can train a model on their own framework. But that’s really hard
I insist on certain ways to use CSS (this, I realized, is where most of the untapped "alpha" is. There are a lot of patterns, like the css checkbox trick and using selectors/tags to pull data from html element attrs, that can introduce a lot of interactivity and generality without JS) and specific design+page contents. Then I typically look at the output visually and make sure the structure doesn't do anything stupid. To fix things I often will just start editing the html and css manually until the page looks exactly like I want it, then save the temp state and pass it back into the model to make the code changes.
Basically I invested a lot of time in learning how CSS, browser apis, and modern html work and figuring out how to do tricks with them that eliminate or greatly reduce the need for SSR and JS. Even though this took several months and a LOT of specs/docs and tedious design work, it was worth it because now I actually understand the foundational abstractions that all these web UIs actually are implemented against, and which don't change. Now I only need LLMs and a way to communicate those tricks (and I know the right language and terms to use to get them build on the right foundations).
But I'm working towards training my own preference set and training pipeline/tools so that I can get models to output things the way I like without all the process/styling/etc. steering that I still need between and across sessions. This is why I think coding agents are long-term only going to be used for vibe coding or to replace less skilled SWEs. You can't get them to consistently do things the way you want or build new devtools/abstractions that get fully internalized and baked into the weights unless you trian them. And a very useful thing about vanilla css/html is that they are much more easily verifiable and something you can generated/search synthetically vs SSR-npm style output.
Even more fundamentally, frameworks were created to reduce the developer time and skill required to build applications. This has been a pipe dream many have chased since COBOL replaced assembly language.
LLMs are probably the first technology that actually approaches doing that. And yes, they don't need frameworks, they're indifferent to the amount of code or boilerplate needed, don't care about the developer "experience," and will write vanilla JS and HTML just as well as anything else you ask them to do, maybe better.
This is why I switched to Astro/React in 2024. I wonder where I would be now if I had stuck things out. Svelte is very fast and elegant. I found that I can use Astro for anything I thought I might need NextJS for though.
I strongly recommend vanilla html, js, and css. For me the benefits of having no npm and related ecosystem tools and no dependencies far outweigh any benefits you get from switching to specific framework. It took me just as long to learn modern css, html, and basically all the browser APIs as it did to learn how to setup+build+modify+deploy my svelte-vscodeextension-webview project without getting bogged down in the tooling.
All those tools and packages are constantly making breaking changes or introducing incompatibility issues or becoming obsolete, and there is so much maintenance. I went pretty deep on CSR/SSG/browser automation over the past two years and realized that everything you get out of these tools is probably 20-400 lines of javascript you could just ask an LLM to implement when you need it. I’ve seen people waste so many hours, days, and weeks on tailwind ui crap (solvable in minutes with css), vitest and object lifecycle crap (use the browser debugger, do e2e tests) and major version upgrades (there’s about 95% less of this in the browser and >99% less outside experimental APIs).
I think for Facebook/Github sized web applications, with really big teams and lots of custom tooling (eg React) these frameworks make sense. Most websites just need basic file serving/rendering, to send and respond to http requests, and some javascript to run on the client (but html and css can actually handle many core UI patterns). I’ve been much happier not using frameworks because my projects just work and the knowledge I build doesn’t constantly churn.
I still use Svelte but I switched to Astro too. I think the best thing about it is that its devs are focused on building primarily a good ssg.
The Svelte people are primarily building a frontend framework and added sveltekit as an addition. Using Svelte in astro even feels nicer to me.
I would have said no different. I've always loved Svelte and the amazing dev-experience and perf was worth the smaller ecosystem. Models were very good at it, I was happy.
Then I got a model to one-shot a React+Shadcn project. It just knew what to do. Every detail was perfect. I couldn't find a single thing to complain about, I didn't chase any bugs.
I still think svelte is the better technology and developer experience (if you're coding by hand). But the React+LLM experience was amazing. Hoping models close the gap fully so I can stay w Svelte -- I do still like reading and tweaking the code.
In early 2026 I struggled a lot with models messing Svelte 4 and Svelte 5. I'm sure same thing will occur with load function vs remote functions, once they will be released
i'd expect the fact that svelte doesn't have a shadow dom that gets recomputed all the time that it would be a significant performance and memory benefit for most apps. i'm not an expert though so idk if that's 100% accurate
Exact same. I was a huge user of SvelteKit from 2022 to early 2025. But ever since LLMs got good enough I went back to React, because the ecosystem size matters a lot more once the coding experience is automated away. And early models were much much better at React than they were at Svelte – I suspect that difference may be gone now but is there a good reason to switch back to Svelte?
A good reason to use svelte instead of React is performance. LLMs not only got us more convenient development but also users that use their hardware for longer since the prices are so high.
I’ve used both in vibe coded side projects, so the caveat is that it’s entirely personal use.
Opus 4.8+ did fine with SvelteKit and I didn’t notice much difference with token usage vs. React.
I will say that I have heavily prompted my agents to read current docs for all libraries, whether in their training set or not. So my agents read React docs even if their training set is full of React code.
I think that strictness will be the most important feature going forward. Whichever framework creates the safest boundaries for agents to work within will gain traction. That's why I think Effect has a bright future.
- very strange indeed, i think every link worked for me when i opened it but it is possible because i have an autoridrect to archive sites when a link does not work extension
User: "In other words you did not sign off on the chad IDE?"
Gary: "Sorry, YC is a pretty big place and I can't be all places at all times"
User: "I'm confused. why did you fund it then?"
Gary: "We're a partnership of 15 general partners"
Seemed to me like he was apoligizing for admitting them. However I see now he also added "I wouldn't count them out, one questionable video does not mean someone is bad". Maybe I misread it.
Since this got so much attention, I feel the need to add that the CEO of Substack is now saying that even accounting for fake views, their traffic from X has gone up substantially.
OP here. This might be a classic Hacker News sentiment that's not shared by normal users. Being able to instantly return to where you were without having to navigate apps is probably appreciated by a lot of people. (As would be preloading in this instance).
FWIW when I first started browsing HN a common complaint was websites being mobile sized. The sentiment here was they should be rendered in full desktop and require pinch-zooming and scrolling in all directions.
That's right. Several times they sneakily reverted my preference, and I reset it. The most recent time I went to do that again and learned it's no longer possible.
> This might be a classic Hacker News sentiment that's not shared by normal users.
My wife just didn't know what a web view was (she still doesn't), but she prefers using the browser after I showed her how to "escape" Facebook's web view and open pages in Safari where the content blocker and ad blocker extensions could do their work. You probably have a point about preloading pages, but until content and ad blockers start working in all web views, then I agree with the person you're replying to: nobody wants a damn web view.
FWIW apps can use a SafariWebView IIRC to basically pass off a link to a separate Safari instance that can use autofill, content blockers, Javascript JIT, etc. but which the app doesn't have access to.
Meanwhile a WebView will show whatever HTML you throw at it, but it won't do any of that other fun stuff because the app that created it can access and manipulate the content (e.g. stealing your passwords) and the OS doesn't know if content filtering is relevant in that webview (since it's just the "show some HTML in a browser-type view" control and maybe it's important to see everything as-is). Being able to access the WebView also means the app can watch where you browse, what URLs, etc. so it can see what you're looking at even once you leave the page it opened to.
So yeah, apps can have a user-friendly experience; Telegram for the longest time used a SafariWebView so that everything was nice and neat. Then they decided to change their UI to a regular WebView and suddenly everything was full of trash again and I had to set it to "open in Safari" instead.
Well, Twitter/X gets this wrong too. Pretty often jumps away from what you're viewing, especially on the nav-in to a thread or nav-out from a thread actions.
Something I see relatives do sometimes is they get a link to a facebook event over meta's messenger, and then they click the link and it opens in messenger's web view, which inexplicably isn't signed into facebook, so they can't view the event, and they don't understand why, as they are signed into facebook in their web browser.
They're also often very confused why they can't find links they've opened in web views in their browser's tabs or history.
In-app webviews are a usability disaster for normal users, I need to help a relative out of one at least once every few weeks.
The webviews don't have adblock so they fall for ads and scams, sometimes they don't properly follow UI scaling, they don't have the cookies or saved passwords needed to, for example, read a paywalled newspaper article that someone linked...
> The sentiment here was they should be rendered in full desktop and require pinch-zooming and scrolling in all directions.
I think you misunderstood. The problem wasn't/isn't that sites were mobile sized on mobile devices. The problem was/is sites that optimize for mobile, and look terrible or are hard to use on a desktop or laptop screen.
That's just asinine. Just because any user would like fast navigation doesn't mean privacy only matters if you know what a violation it is to ping every server in sight on user's device, with absolutely no way to prevent it.
reply