[{"data":1,"prerenderedAt":766},["ShallowReactive",2],{"$f20f40cmdvcitk":3},{"items":4},[5,17,27,50,59,70,78,87,95,104,112,118,129,142,147,169,189,209,219,225,245,266,287,293,313,333,352,358,381,401,421,439,445,457,465,486,507,513,668,689,697,703,723,729,748,753,761],{"id":6,"type":7,"tracks":8,"start":13,"end":14,"heading":15,"programs":16},"reception","schedule",[9,10,11,12],"track1","track2","track3","track4","09:00","10:00","Opening and reception",[],{"id":18,"type":19,"tracks":20,"start":14,"end":21,"heading":22,"programs":23},"opening","session",[9,10],"10:10","Opening",[24],{"id":18,"type":19,"start":14,"end":21,"tracks":25,"title":22,"speakers":26},[9,10],[],{"id":28,"type":19,"tracks":29,"start":21,"end":30,"heading":31,"headingUrl":32,"programs":33},"keynote",[9,10],"10:50","Keynote","",[34],{"id":28,"url":32,"type":19,"start":21,"end":30,"tracks":35,"title":31,"overview":32,"speakers":36},[9,10],[37],{"id":38,"avatarUrl":39,"color":40,"attendedIndex":41,"socialUrls":42,"name":46,"title":47,"affiliation":48,"bio":49},"yyx990803","\u002Fimages\u002Favatars\u002Fevan-you.jpeg","default",1,{"x":43,"bluesky":44,"github":45},"https:\u002F\u002Fx.com\u002Fevanyou","https:\u002F\u002Fbsky.app\u002Fprofile\u002Fevanyou.me","https:\u002F\u002Fgithub.com\u002Fyyx990803","Evan You","CEO","VoidZero","Creator of Vue.js and Vite. As CEO of VoidZero, he works on the JavaScript toolchain.",{"id":51,"type":7,"tracks":52,"start":30,"end":53,"heading":54,"programs":55,"display":56,"isPcOnly":58},"schedule-10:50-10:55-track1-track2",[9,10],"10:55","Break",[],{"startTime":32,"endTime":32,"color":57},"primary",false,{"id":60,"type":19,"tracks":61,"start":53,"end":62,"heading":63,"programs":64},"session-10:55-11:05-track1",[9],"11:05","Platinum Sponsor Session",[65],{"id":66,"type":19,"tracks":67,"start":53,"end":62,"title":68,"speakers":69},"platinum-sponsor-session-1",[9],"TBD",[],{"id":71,"type":19,"tracks":72,"start":53,"end":62,"heading":63,"programs":73},"session-10:55-11:05-track2",[10],[74],{"id":75,"type":19,"tracks":76,"start":53,"end":62,"title":68,"speakers":77},"platinum-sponsor-session-2",[10],[],{"id":79,"type":19,"tracks":80,"start":62,"end":81,"heading":63,"programs":82},"session-11:05-11:15-track1",[9],"11:15",[83],{"id":84,"type":19,"tracks":85,"start":62,"end":81,"title":68,"speakers":86},"platinum-sponsor-session-3",[9],[],{"id":88,"type":19,"tracks":89,"start":62,"end":81,"heading":63,"programs":90},"session-11:05-11:15-track2",[10],[91],{"id":92,"type":19,"tracks":93,"start":62,"end":81,"title":68,"speakers":94},"platinum-sponsor-session-4",[10],[],{"id":96,"type":19,"tracks":97,"start":81,"end":98,"heading":63,"programs":99},"session-11:15-11:25-track1",[9],"11:25",[100],{"id":101,"type":19,"tracks":102,"start":81,"end":98,"title":68,"speakers":103},"platinum-sponsor-session-5",[9],[],{"id":105,"type":19,"tracks":106,"start":81,"end":98,"heading":63,"programs":107},"session-11:15-11:25-track2",[10],[108],{"id":109,"type":19,"tracks":110,"start":81,"end":98,"title":68,"speakers":111},"platinum-sponsor-session-6",[10],[],{"id":113,"type":7,"tracks":114,"start":98,"end":115,"heading":116,"programs":117},"schedule-11:25-12:50-track1-track2",[9,10],"12:50","Lunch Time",[],{"id":119,"type":19,"tracks":120,"start":121,"end":122,"heading":123,"programs":124},"session-11:30-12:00-track4",[12],"11:30","12:00","Student Support Sponsor Session",[125],{"id":126,"type":19,"tracks":127,"start":121,"end":122,"title":68,"speakers":128},"student-support-sponsor-session",[12],[],{"id":130,"type":131,"tracks":132,"start":122,"end":133,"heading":134,"programs":135},"event-12:00-12:30-track4","event",[12],"12:30","Student Support Content",[136],{"id":137,"type":131,"start":122,"end":133,"tracks":138,"url":139,"title":140,"speakers":141},"student-support-contents",[12],"\u002Fevent?session=student-support-contents#student-support-contents","Student Support Lunch Meetup",[],{"id":143,"type":7,"tracks":144,"start":133,"end":115,"heading":54,"programs":145,"display":146,"isPcOnly":58},"schedule-12:30-12:50-track4",[12],[],{"startTime":32,"endTime":32,"color":57},{"id":148,"type":19,"tracks":149,"start":115,"end":150,"programs":151},"session-12:50-13:20-track1",[9],"13:20",[152],{"id":153,"url":154,"type":19,"tracks":155,"start":115,"end":150,"title":68,"overview":32,"speakers":156},"session-1","\u002Fspeaker\u002Fposva",[9],[157],{"id":158,"avatarUrl":159,"color":40,"attendedIndex":160,"socialUrls":161,"name":165,"title":166,"affiliation":167,"bio":168},"posva","\u002Fimages\u002Favatars\u002Feduardo-san-martin-morote.png",2,{"x":162,"bluesky":163,"github":164},"https:\u002F\u002Fx.com\u002Fposva","https:\u002F\u002Fbsky.app\u002Fprofile\u002Fesm.dev","https:\u002F\u002Fgithub.com\u002Fposva","Eduardo San Martin Morote","Vue.js Core Team","Vercel","Frontend nerd with a passion for Open Source, working as part of the Vue.js Core Team.",{"id":170,"type":19,"tracks":171,"start":115,"end":150,"programs":172},"session-12:50-13:20-track2",[10],[173],{"id":174,"url":175,"type":19,"tracks":176,"start":115,"end":150,"title":177,"overview":178,"speakers":179},"session-2","\u002Fspeaker\u002Fjp-knj",[10],"The Present State of the Frontend Toolchain, Seen Through Astro and Rust","Rust is increasingly becoming the default choice in frontend toolchains, with tools like Oxc, Lightning CSS, and Rolldown leading the way. Astro, too, has been moving toward adopting Rust internally, starting with compiler-rs.\n\nBut when you turn to Markdown\u002FMDX processing, you run into problems that \"just switch to Rust and it'll be faster\" doesn't solve. Questions arise around how to connect with the existing JavaScript ecosystem — remark\u002Frehype compatibility, syntax highlighting, Vite plugins, interop with Node.js, and distribution of native binaries.\n\nI want to think through the current state of the frontend toolchain from the vantage point of Astro and Rust.\n\nWhat I plan to cover:\n- The trend toward Rust adoption in Astro\n- The difficulties of porting Markdown\u002FMDX to Rust\n- The boundary with the JavaScript ecosystem, as seen through napi-rs, syntax highlighting, and Vite plugins\n- The reality of implementing, proposing, and overhauling existing mechanisms within OSS\n\nAs for why I'm applying: Vue Fes was the catalyst that led to launching the Astro Japan Community, and through interactions with the Astro core team at Vue Amsterdam, I had the experience of seeing my own implementation connect into a larger context. This is a story only I, as an Astro committer, can tell — one I haven't shared until now.\n\n▼ Astro roadmap discussion\nhttps:\u002F\u002Fgithub.com\u002Fwithastro\u002Froadmap\u002Fdiscussions\u002F1195\n\n▼ Spike implementation of xmdx\nMost of the people who've starred it are actually Astro core members.\nhttps:\u002F\u002Fgithub.com\u002Fjp-knj\u002Fxmdx",[180],{"id":181,"avatarUrl":182,"color":40,"socialUrls":183,"name":181,"title":187,"affiliation":188},"jp-knj","\u002Fimages\u002Favatars\u002Fjp-knj.png",{"x":184,"bluesky":185,"github":186},"https:\u002F\u002Fx.com\u002Fjp_knj","https:\u002F\u002Fbsky.app\u002Fprofile\u002Fjp-knj.bsky.social","https:\u002F\u002Fgithub.com\u002Fjp-knj","Design Engineer","Plaid, Inc.",{"id":190,"type":19,"tracks":191,"start":115,"end":150,"programs":192},"session-12:50-13:20-track3",[11],[193],{"id":194,"url":195,"type":19,"tracks":196,"start":115,"end":150,"title":197,"overview":198,"speakers":199},"session-3","\u002Fspeaker\u002Fics-ikeda",[11],"JS Is Shrinking This Much! The Latest HTML & CSS Techniques for 2026","Parts of the UI that used to rely on JavaScript libraries can now be written in plain HTML and CSS. Using the newer HTML and CSS features, there are more and more situations where you can write simpler code with less of it. This session will introduce the following features:\n\n- dialog, popover, customizable select, CSS carousel\n- the command \u002F commandfor attributes\n- @starting-style, transition-behavior: allow-discrete\n- sibling-index(), attr()\n- the :target-current pseudo-class\n- anchor positioning\n- scroll-driven animation\n\nWhen you build these things yourself in JavaScript, there's a lot to take care of — accessibility, preventing double-clicks, focus management, open\u002Fclose state, and so on. The benefit of using browser-standard features is that you can offload some of that handling to HTML\u002FCSS.\n\n■ Why I chose this topic\nI've been covering the web's latest features and publishing explainer articles on the owned media site ICS MEDIA. While building original demos for these articles, I was struck by how modal UI development — which used to be a real struggle with things like Vue.js's `\u003CTransitionGroup>` back around 2018 — can now be written straightforwardly using the dialog element, the command attribute, @starting-style, and more. That experience is the starting point for this session.\n\n■ Concrete example\nUsing a hamburger menu as the subject, I'll introduce an implementation approach centered on the dialog element.\nhttps:\u002F\u002Fics.media\u002Fentry\u002F260527\u002F\nI'll explain how, even for UI patterns you see all the time, these new technologies can work together to help.\n\n■ What attendees will take away\n- The range of UI you can now build with the latest HTML\u002FCSS\n- How to judge which parts you can skip writing JavaScript for, and which parts you still should\n- Things to watch out for when combining this with state management in Vue.js, React, and similar frameworks",[200],{"id":201,"avatarUrl":202,"color":40,"socialUrls":203,"name":206,"title":207,"affiliation":208},"ics-ikeda","\u002Fimages\u002Favatars\u002Fics-ikeda.png",{"x":204,"github":205},"https:\u002F\u002Fx.com\u002Fclockmaker","https:\u002F\u002Fgithub.com\u002Fics-ikeda","IKEDA Yasunobu","Front-end Engineer","ICS INC.",{"id":210,"type":131,"tracks":211,"start":115,"end":212,"heading":213,"programs":214},"event-12:50-14:50-track4",[12],"14:50","Hands-on Workshop",[215],{"id":216,"type":131,"start":115,"end":212,"tracks":217,"title":68,"speakers":218},"hands-on",[12],[],{"id":220,"type":7,"tracks":221,"start":150,"end":222,"heading":54,"programs":223,"display":224,"isPcOnly":58},"schedule-13:20-13:35-track1-track2-track3",[9,10,11],"13:35",[],{"startTime":32,"endTime":32,"color":57},{"id":226,"type":19,"tracks":227,"start":222,"end":228,"programs":229},"session-13:35-14:05-track1",[9],"14:05",[230],{"id":231,"url":232,"type":19,"tracks":233,"start":222,"end":228,"title":234,"overview":235,"speakers":236},"session-4","\u002Fspeaker\u002Fykoizumi0903",[9],"From Nuxt Content to OxContent: Taking on a Blog Platform Overhaul for 1,000+ Pages","As our blog grew to more than 1,000 pages using Nuxt Content and NuxtHub, increasing build times and declining maintainability became major challenges. In this session, I'll share our hands-on experience migrating to ox-content, a next-generation Rust-based content engine, in Nuxt 4 to address these issues.\nThe migration involved more than simply replacing the content layer. We adopted several new technologies while preserving practical features such as search and image delivery, and optimized the architecture by transitioning from SSR to SSG.\nI'll walk through the technical decisions, migration process, and lessons learned from balancing performance, scalability, and developer experience for a large-scale static content site.",[237],{"id":238,"avatarUrl":239,"color":40,"socialUrls":240,"name":242,"title":243,"affiliation":244},"ykoizumi0903","\u002Fimages\u002Favatars\u002Fykoizumi0903.png",{"x":241},"https:\u002F\u002Fx.com\u002Fykoizumi0903","Yutaro Koizumi","TechLead","ANDPAD Inc.",{"id":246,"type":19,"tracks":247,"start":222,"end":228,"programs":248},"session-13:35-14:05-track2",[10],[249],{"id":250,"url":251,"type":19,"tracks":252,"start":222,"end":228,"title":253,"overview":32,"speakers":254},"session-5","\u002Fspeaker\u002Fwan9chi",[10],"Vite-plus (TBD)",[255],{"id":256,"avatarUrl":257,"color":40,"attendedIndex":258,"socialUrls":259,"name":263,"title":264,"affiliation":48,"bio":265},"wan9chi","\u002Fimages\u002Favatars\u002Fcharles-wang.png",4,{"x":260,"bluesky":261,"github":262},"https:\u002F\u002Fx.com\u002Fwan9chi","https:\u002F\u002Fbsky.app\u002Fprofile\u002Fwan9chi.bsky.social","https:\u002F\u002Fgithub.com\u002Fwan9chi","Charles Wang","Software Engineer","Vite+ core team member. Working on Vite Task.",{"id":267,"type":19,"tracks":268,"start":222,"end":228,"programs":269},"session-13:35-14:05-track3",[11],[270],{"id":271,"url":272,"type":19,"tracks":273,"start":222,"end":228,"title":274,"overview":275,"speakers":276},"session-6","\u002Fspeaker\u002Fktsn",[11],"Why Does That UI Animation Feel So Satisfying?","Have you ever wanted to add animation to a UI, but had no idea how to make it actually feel good?\n\nCompared to mobile apps, which come with polished animations built in as standard, the web requires you to implement much more of the animation yourself, and it's not easy to get the quality up to a high standard. In recent years, convenient APIs like the View Transition API have been added, but \"how\" something should move is still left almost entirely up to the implementer, putting both taste and knowledge to the test.\n\nIn this session, I'll analyze what factors give rise to that \"satisfying\" feeling in UI animation, and present ways to translate that into actual implementation. I'll also show UI patterns commonly seen in mobile apps, implemented in Vue.js, so you can experience firsthand, through real UI, what factors create that sense of satisfaction. My goal is for this to be a catalyst for you to take on animation implementation yourselves, and to give you more tools in hand for when you do.",[277],{"id":278,"avatarUrl":279,"color":40,"socialUrls":280,"name":284,"title":285,"affiliation":286},"ktsn","\u002Fimages\u002Favatars\u002Fktsn.png",{"x":281,"bluesky":282,"github":283},"https:\u002F\u002Fx.com\u002Fktsn","https:\u002F\u002Fbsky.app\u002Fprofile\u002Fktsn.dev","https:\u002F\u002Fgithub.com\u002Fktsn","Katashin","CTO","kinew",{"id":288,"type":7,"tracks":289,"start":228,"end":290,"heading":54,"programs":291,"display":292,"isPcOnly":58},"schedule-14:05-14:20-track1-track2-track3",[9,10,11],"14:20",[],{"startTime":32,"endTime":32,"color":57},{"id":294,"type":19,"tracks":295,"start":290,"end":212,"programs":296},"session-14:20-14:50-track1",[9],[297],{"id":298,"url":299,"type":19,"tracks":300,"start":290,"end":212,"title":301,"overview":302,"speakers":303},"session-7","\u002Fspeaker\u002Fnaokihaba",[9],"Contributing to Vite+, and the View from Becoming a Team Member","Since April 2026, I've been continuing my work as a Team Member of Vite+. Over that time, I've worked on a wide range of improvements, including supporting the migration of Node.js version management, tsdown-related migrations, automatic conversion of TypeScript configurations, and adding type support for Vue and Astro.\n\nIn the day-to-day work, I've deepened my understanding of the project bit by bit through steady, hands-on investigation: reading deeply into the migrator's implementation, and reproducing and tracing the behavior behind each Issue that comes in, one by one. Now, as a Team Member, triaging Issues from users around the world and reviewing Pull Requests has become part of my daily routine.\n\nTaking on this new role has let me feel, firsthand, the particular difficulties and joys of running an OSS project, along with the energy of its community, in ways I never imagined back when I was just an outside contributor.\n\nIn this session, drawing on concrete examples from Vite+, I'll share the journey from being a single contributor to becoming a Team Member, along with what I learned along the way. I'd also like to take a moment to reflect on the value of deliberately pausing to \"understand deeply,\" at a time when AI is lowering the barrier to \"writing code\" itself.\n\nThis talk is for anyone interested in contributing to OSS, as well as those thinking about getting involved in some form going forward. I'll talk about richer ways of engaging with OSS that go beyond simply writing code.",[304],{"id":305,"avatarUrl":306,"color":40,"socialUrls":307,"name":311,"title":312,"affiliation":244},"naokihaba","\u002Fimages\u002Favatars\u002Fnaokihaba.png",{"x":308,"bluesky":309,"github":310},"https:\u002F\u002Fx.com\u002Fnaokihaba","https:\u002F\u002Fbsky.app\u002Fprofile\u002Fnaokihaba.com","https:\u002F\u002Fgithub.com\u002Fnaokihaba","Naoki Haba","Vite+ Team Member",{"id":314,"type":19,"tracks":315,"start":290,"end":212,"programs":316},"session-14:20-14:50-track2",[10],[317],{"id":318,"url":319,"type":19,"tracks":320,"start":290,"end":212,"title":321,"overview":322,"speakers":323},"session-8","\u002Fspeaker\u002Fhiranuma",[10],"Spatial Computing with Vue: Frontend Development for XR Devices Using TresJS and WebXR","Did you know that you can build spatial computing apps that run on devices like the Meta Quest 3 and Samsung Galaxy XR using Vue, TresJS, and WebXR?\nWithout having to learn a whole new framework, you can implement frontends for XR devices using nothing more than your existing knowledge of the Vue Composition API.\n\nApple Vision Pro and Meta Quest 3 have brought spatial computing into the mainstream, and in fall 2026, glasses-type devices like XREAL Project Aura and Snap Specs are also set to launch one after another.\nWith XR device options now ranging from headsets to glasses, spatial computing has entered practical, everyday use.\nIn this session, as a foundation for building spatial computing apps that actually run with Vue + TresJS + WebXR, I'll share implementation patterns for XR device frontend development, including gaze- and gesture-based interaction, declarative scene construction, support for both hand tracking and controllers, and physics engine integration.",[324],{"id":325,"avatarUrl":326,"color":40,"socialUrls":327,"name":331,"title":285,"affiliation":332},"hiranuma","\u002Fimages\u002Favatars\u002Fhiranuma.png",{"x":328,"bluesky":329,"github":330},"https:\u002F\u002Fx.com\u002Fmistorun","https:\u002F\u002Fbsky.app\u002Fprofile\u002Fmistorun.bsky.social","https:\u002F\u002Fgithub.com\u002Fhiranuma","Shingo Hiranuma","GENEROSITY inc.",{"id":334,"type":19,"tracks":335,"start":290,"end":212,"programs":336},"session-14:20-14:50-track3",[11],[337],{"id":338,"url":339,"type":19,"tracks":340,"start":290,"end":212,"title":341,"overview":342,"speakers":343},"session-9","\u002Fspeaker\u002Fyamanoku",[11],"The Right Way to Protect Your HTML, Revisited from Vue SFC","I think it's common knowledge that Vue SFC come with syntax that lets you write HTML in the template block. But can you actually explain how you verify \"HTML correctness\" when developing with Vue.js?\nWithin the template of a Vue SFC, nesting violations between HTML elements will trigger a warning during development, but they won't clearly result in a compile error. Lexical and syntactic HTML rules are detected, but the compiler doesn't concern itself with the correct usage of specific HTML elements.\nIn this session, I'll unpack, from first principles, how the compiler interprets the HTML content written in a Vue SFC's template block, and introduce how the aspects of HTML correctness that a DOM compiler alone can't guarantee are currently being protected by the static analysis ecosystem of linters (ESLint, Markuplint, Biome, OxC, Vize, and others).\nThe HTML spec continues to be updated even now, as a Living Standard. By engaging correctly with HTML in that spirit, this talk aims to give you insights for achieving robust markup and accessible output through HTML in Vue.js.",[344],{"id":345,"avatarUrl":346,"color":40,"socialUrls":347,"name":345,"title":351,"affiliation":32},"yamanoku","\u002Fimages\u002Favatars\u002Fyamanoku.png",{"x":348,"bluesky":349,"github":350},"https:\u002F\u002Fx.com\u002Fyamanoku","https:\u002F\u002Fbsky.app\u002Fprofile\u002Fyamanoku.net","https:\u002F\u002Fgithub.com\u002Fyamanoku","Company Employee",{"id":353,"type":7,"tracks":354,"start":212,"end":355,"heading":54,"programs":356,"display":357,"isPcOnly":58},"schedule-14:50-15:05-track1-track2-track3-track4",[9,10,11,12],"15:05",[],{"startTime":32,"endTime":32,"color":57},{"id":359,"type":19,"tracks":360,"start":355,"end":361,"programs":362},"session-15:05-15:35-track1",[9],"15:35",[363],{"id":364,"url":365,"type":19,"tracks":366,"start":355,"end":361,"title":367,"overview":368,"speakers":369},"session-10","\u002Fspeaker\u002Fubugeeei",[9],"The Vue Toolchain, Reimagined","Vue development is powered by a rich ecosystem of tools.\n\nVize is an open source project that aims to build a blazing-fast Vue toolchain from the ground up. As the project has grown to include compilers, linters, and other developer tools, it has revealed new challenges and opportunities that only become visible when building an entire toolchain.\n\nIn this session, I'll introduce Vize, share the lessons learned from building a Vue toolchain, and explore where Vue tooling could go next.",[370],{"id":371,"avatarUrl":372,"color":40,"attendedIndex":373,"socialUrls":374,"name":371,"title":378,"affiliation":379,"bio":380},"ubugeeei","\u002Fimages\u002Favatars\u002Fubugeeei.jpeg",5,{"x":375,"bluesky":376,"github":377},"https:\u002F\u002Fx.com\u002Fubugeeei","https:\u002F\u002Fbsky.app\u002Fprofile\u002Fubugeeei.dev","https:\u002F\u002Fgithub.com\u002Fubugeeei","Creator of Vize and chibivue","Vite+, Vue.js, Mates Inc.","Tokyo-based software engineer and chief engineer at Mates Inc. working on frontend architecture, developer experience, and performance.\n\nAlso active as a Vue.js Core Team member and Vite+ core contributor, with work around Vue Vapor and the broader Vue community. With Vize, a Rust-based Vue.js toolchain spanning compiler, linter, typechecker, formatter, story system, and LSP, he is exploring what the next foundation for Vue development could look like.",{"id":382,"type":19,"tracks":383,"start":355,"end":361,"programs":384},"session-15:05-15:35-track2",[10],[385],{"id":386,"url":387,"type":19,"tracks":388,"start":355,"end":361,"title":389,"overview":390,"speakers":391},"session-11","\u002Fspeaker\u002FHal-Spidernight",[10],"Building Spatial Analysis Apps with Vue.js, and the Data Bridge for Capacitor Plugins","Have any of you ever built a native app with Vue.js?\nWith the recent emergence of Lynx supporting Vue 3, and Capacitor — which, despite being WebView-based, offers robust native-layer support — the bar for web engineers to get started with mobile app development has dropped significantly, thanks to the advance of native frameworks that let you leverage your existing web app experience.\n\nAt the same time, it's also true that support for accessing certain native APIs, like AVCaptureDevice or ARKit, often isn't sufficient.\n\nSo does that mean we have no choice but to give up and use Flutter or Swift\u002FKotlin?\n\nNo — let's just build a plugin that accesses the native layer ourselves.\n\nThat said, the data handled at the native layer can sometimes be massive. For example, with 3D scan point cloud data collected using LiDAR, the volume of binary data transferred between JavaScript and native is large, and without efficient communication, the whole thing falls short of being practical.\n\nIn this session, centered on spatial analysis apps using AR and LiDAR, I'll talk about making JS↔native transfers more efficient, and about plugin design for handling native APIs efficiently from a web framework.",[392],{"id":393,"avatarUrl":394,"color":40,"socialUrls":395,"name":398,"title":399,"affiliation":400},"Hal-Spidernight","\u002Fimages\u002Favatars\u002FHal-Spidernight.png",{"x":396,"github":397},"https:\u002F\u002Fx.com\u002Fhal_spidernight","https:\u002F\u002Fgithub.com\u002FHal-Spidernight","Hal","Application Expert","LIXIL",{"id":402,"type":19,"tracks":403,"start":355,"end":361,"programs":404},"session-15:05-15:35-track3",[11],[405],{"id":406,"url":407,"type":19,"tracks":408,"start":355,"end":361,"title":409,"overview":410,"speakers":411},"session-12","\u002Fspeaker\u002Fis78-dev",[11],"What TanStack Query Vue and Pinia Colada Teach Us About Typing Async State","TanStack Query Vue and Pinia Colada differ in how their APIs handle the state of asynchronous data fetching. For example, there are cases where, even after checking a query's status, `data` is still typed in TypeScript as potentially `undefined`. In this session, taking the API designs of these two data-fetching libraries as a starting point, I'll organize how the way types appear ends up being determined. Using TanStack Query Vue `useQuery` combined with type narrowing via `reactive`, and Pinia Colada's state design, as concrete examples, I'll look at the relationship between Vue `ref`, `toRefs`, `reactive`, and TypeScript's discriminated unions. Through this library comparison, I'll share design perspectives for handling async state in a type-safe way within Vue composables.",[412],{"id":413,"avatarUrl":414,"color":40,"socialUrls":415,"name":418,"title":419,"affiliation":420},"is78-dev","\u002Fimages\u002Favatars\u002Fis78-dev.png",{"x":416,"github":417},"https:\u002F\u002Fx.com\u002Faoshi_78","https:\u002F\u002Fgithub.com\u002Fis78-dev","aoshi","frontend engineer","Yappli, Inc.",{"id":422,"type":19,"tracks":423,"start":355,"end":361,"programs":424},"session-15:05-15:35-track4",[12],[425],{"id":426,"url":427,"type":19,"tracks":428,"start":355,"end":361,"title":429,"overview":430,"speakers":431},"session-13","\u002Fspeaker\u002Ft0daaay",[12],"Deterministic Frontend Architecture Is the Way to Go","\"Should we put this in the xxx directory?\" \"Should we extract this into utils?\" \"Should we turn this into a composable?\" \"Can we write this with computed instead of watch?\"\nThese are the kinds of design discussions that come up again and again in frontend development.\nAs generative AI keeps accelerating development speed, is it really realistic to keep making these judgment calls one by one?\nIn a new product I'm involved with as a frontend engineer, built on Nuxt, we've decided as deterministically as possible where files and functions should go, how things should be named, and how APIs should be used, and backed all of it with linter guardrails.\nAs a result, we've reached a point where most PRs can be reviewed in just a few minutes, and we've built a setup where people can develop productively even without deep frontend expertise, giving us a development environment that's both robust and fast.\nIn this session, using the architecture of a Nuxt project currently in development as an example, I'll introduce the concrete decision rules we've established in the field to build an architecture that leaves no room for hesitation.",[432],{"id":433,"avatarUrl":434,"color":40,"socialUrls":435,"name":438,"title":264,"affiliation":32},"t0daaay","\u002Fimages\u002Favatars\u002Ft0daaay.png",{"x":436,"github":437},"https:\u002F\u002Fx.com\u002Ft0daaay","https:\u002F\u002Fgithub.com\u002Ft0daaay","Keisuke Tsuji",{"id":440,"type":7,"tracks":441,"start":361,"end":442,"heading":54,"programs":443,"display":444,"isPcOnly":58},"schedule-15:35-15:50-track1-track2-track3-track4",[9,10,11,12],"15:50",[],{"startTime":32,"endTime":32,"color":57},{"id":446,"type":131,"tracks":447,"start":442,"end":448,"heading":449,"headingUrl":450,"programs":451},"panelDiscussion-15:50-16:50-track1",[9],"16:50","Panel Discussion","\u002Fevent?session=panel-discussion#panel-discussion",[452],{"id":453,"type":454,"start":442,"end":448,"tracks":455,"title":68,"speakers":456},"panel-discussion-1","panelDiscussion",[9],[],{"id":458,"type":131,"tracks":459,"start":442,"end":448,"heading":449,"headingUrl":450,"programs":460},"panelDiscussion-15:50-16:50-track2",[10],[461],{"id":462,"type":454,"start":442,"end":448,"tracks":463,"title":68,"speakers":464},"panel-discussion-2",[10],[],{"id":466,"type":19,"tracks":467,"start":442,"end":468,"programs":469},"session-15:50-16:20-track3",[11],"16:20",[470],{"id":471,"url":472,"type":19,"tracks":473,"start":442,"end":468,"title":474,"overview":475,"speakers":476},"session-14","\u002Fspeaker\u002Fthemarcba",[11],"The Backend is Reactive: Vue Beyond the Browser","This is a talk that de-mystifies Vue reactivity by implementing it in the browser. Rather than production-ready, we are going to have some FUN WITH CODE.\n\n\"What if Vue’s reactivity system didn’t stop at the browser? In this talk, I’ll turn the entire audience into a synchronized, reactive lightshow—using @vue\u002Freactivity on the backend to orchestrate hundreds of phones in real time.\n\nFormat:\n        •        First, there will be some light live coding to prove the principle\n        •        Then, a live demo starts, while also showing some code on screen\n        •        Everyone scans a QR and lands on a super-light page (no login). Their screens turn into “lights” controlled by the backend. I’ll make them hold up their phones that hopefully lights up the room (full brightness)        •        A conductor dashboard (on stage) exposes a few reactive controls: color, intensity, BPM, and pattern (solid, strobe, wave, sparkles, letter blocks).        •        The backend holds a small reactive graph:\n        ▪        Source refs: mode, color, brightness, …        ▪        Computeds: beat timing, per-client “bucket,” pattern projections (e.g., wave phase)        ▪        Effects: push updates via WebSockets, log analytics        •        No imperative per-user wiring—just mutate source refs; computed projections and effects fan out changes to every device automatically.\n\nTakeaways\n        •        Vue’s reactivity can orchestrate backend logic, not just UI state.        •        A single reactive source of truth can drive many clients with minimal glue code.        •        Server-Sent Events\u002FWebSockets pair naturally with reactive effects for live fan-out.        •        Computed projections make per-user instructions trivial and consistent.        •        Reactive thinking clarifies side effects, scheduling, and cleanup concern\n\nI already gave this talk successfully at Vue.js Amsterdam:\nhttps:\u002F\u002Fwww.youtube.com\u002Fwatch?v=hFgqGgaHo0U",[477],{"id":478,"avatarUrl":479,"color":40,"socialUrls":480,"name":483,"title":484,"affiliation":485},"themarcba","\u002Fimages\u002Favatars\u002Fthemarcba.png",{"x":481,"github":482},"https:\u002F\u002Fx.com\u002Fmarcba","https:\u002F\u002Fgithub.com\u002Fthemarcba","Marc Backes","Senior Software Engineer","Directus",{"id":487,"type":19,"tracks":488,"start":442,"end":468,"programs":489},"session-15:50-16:20-track4",[12],[490],{"id":491,"url":492,"type":19,"tracks":493,"start":442,"end":468,"title":494,"overview":495,"speakers":496},"session-15","\u002Fspeaker\u002Falvarosabu",[12],"How I recreated Vue Fes Japan 2025 website using TresJS and TSL (WebGPU)","In this talk I’ll share how I recreated the Vue Fes Japan 2025 website hero using Vue, TresJS and Three.js Shading Language (TSL) on top of WebGPU. The original scene runs on raw Three.js r178 and combines a V‑shaped cone (for Vue) with a sphere inspired by the Japanese flag’s Hinomaru, masked with a custom suminagashi shader that simulates Japanese ink‑marbling.\n\nI’ll walk through how I ported that setup into Vue using TresJS components, how I structured the scene declaratively, and how I moved the original GLSL shader logic over to TSL in a way that feels natural inside a Vue app. We’ll look at how the ink‑marbling effect is built from FBM noise flowing through warped vector fields, how the animation cycles through several color palettes over time, and what changes when you take advantage of the WebGPU API instead of the classic WebGL pipeline.\n\nBy the end of the session, participants will understand how to approach porting an existing Three.js scene into Vue with TresJS, how to organize complex shader effects in a component‑driven architecture and how to create beautiful visual experiences using Vue.\n\nLive demo https:\u002F\u002Flab.tresjs.org\u002Fexperiments\u002Fvuefes-japan-2025\nTresJS https:\u002F\u002Ftresjs.org\u002F",[497],{"id":498,"avatarUrl":499,"color":40,"socialUrls":500,"name":504,"title":505,"affiliation":506},"alvarosabu","\u002Fimages\u002Favatars\u002Falvarosabu.png",{"x":501,"bluesky":502,"github":503},"https:\u002F\u002Fx.com\u002Falvarosabu","https:\u002F\u002Fbsky.app\u002Fprofile\u002Falvarosaburido.dev","https:\u002F\u002Fgithub.com\u002Falvarosabu","Alvarosabu","Creative Software Engineer","TresJS",{"id":508,"type":7,"tracks":509,"start":468,"end":510,"heading":54,"programs":511,"display":512,"isPcOnly":58},"schedule-16:20-16:35-track3-track4",[11,12],"16:35",[],{"startTime":32,"endTime":32,"color":57},{"id":514,"type":515,"tracks":516,"start":510,"end":517,"heading":518,"programs":519},"lightningTalk-16:35-17:50-track3","lightningTalk",[11],"17:50","Lightning Talk",[520,535,551,565,579,594,608,624,640,654],{"id":521,"url":522,"type":515,"tracks":523,"start":510,"end":517,"title":524,"overview":525,"speakers":526},"lightning-talk-1","\u002Fspeaker\u002FShigeyuki-fukuda",[11],"Verifying Whether Vapor Mode Breaks Accessibility","Vapor Mode, introduced in Vue 3.6, is a new compilation strategy that manipulates the DOM directly without going through VNodes. But discussion of it has focused almost entirely on performance, and its impact on assistive technology has barely been examined.\nDoes live region announcement, focus management, and dynamic aria attribute updates behave the same way as in the conventional mode? I chose this topic because I see it as an unavoidable question when considering partial adoption of Vapor Mode in an existing app.\nIn this talk, I'll report on results from building the same component under both the conventional mode and Vapor Mode, and verifying them from two angles: comparing differences in the accessibility tree using Playwright's ariaSnapshot, and checking actual screen-reader announcements with VoiceOver.\nI'll present a list of which items showed differences and which didn't, so you can take it home as a checklist of accessibility considerations to check when migrating to Vapor Mode.",[527],{"id":528,"avatarUrl":529,"color":40,"socialUrls":530,"name":528,"title":533,"affiliation":534},"Shigeyuki-fukuda","\u002Fimages\u002Favatars\u002FShigeyuki-fukuda.png",{"x":531,"github":532},"https:\u002F\u002Fx.com\u002Fuqda90","https:\u002F\u002Fgithub.com\u002FShigeyuki-fukuda","Web Developer","mov inc.",{"id":536,"url":537,"type":515,"tracks":538,"start":510,"end":517,"title":539,"overview":540,"speakers":541},"lightning-talk-2","\u002Fspeaker\u002FHasutoSasaki",[11],"Does Your await Actually Reach the OS? Peeking at JavaScript's Async with strace","We write async\u002Fawait as a matter of course, but when asked \"what is the OS actually doing while you're waiting?\", I could only give a vague answer, and it bothered me. So in this lightning talk, I'll dig into Node.js code down to the system call level using strace, to see what await really is under the hood.\nFirst, comparing Promise.resolve() and fetch() reveals that there are two kinds of await: ones that actually descend to the OS, and ones that don't. Next, I'll run multiple fetch calls both \"sequentially\" and via Promise.all, and line up the syscall logs side by side. This reveals that what makes things parallel isn't Promise.all itself — its real effect is in consolidating the round trips of epoll_wait.\nFinally, I'll connect this perspective to cases where Nuxt's useAsyncData\u002FuseFetch end up running sequentially and becoming slow, so that you can walk away able to explain, in the OS's own terms, \"why bundling requests together makes things faster.\"",[542],{"id":543,"avatarUrl":544,"color":40,"socialUrls":545,"name":548,"title":549,"affiliation":550},"HasutoSasaki","\u002Fimages\u002Favatars\u002FHasutoSasaki.png",{"x":546,"github":547},"https:\u002F\u002Fx.com\u002Fhasuto00","https:\u002F\u002Fgithub.com\u002FHasutoSasaki","Hasuto","Back-End Engineer","Classmethod, Inc.",{"id":552,"url":553,"type":515,"tracks":554,"start":510,"end":517,"title":555,"overview":556,"speakers":557},"lightning-talk-3","\u002Fspeaker\u002Fnorthprint",[11],"Escaping v-if and Flag Hell — Building a Screen-Transition State Machine with Pinia","\"The submit button got pressed twice, causing a duplicate registration.\" \"The screen broke because someone interacted with it mid-animation.\" I think bugs like these almost always come down to holding \"what phase the screen is currently in\" as a scattered collection of flags.\nWith N flags, you end up with 2^N possible states, which is a breeding ground for bugs.\n\nWhat this lightning talk proposes is: stop adding more flags, and instead consolidate the screen's state into just one \"where am I right now\" value plus a map of \"where can I go from here.\" In other words, a state machine (not a novel concept — this is an old idea).\nI'll show, with a self-built demo, how this alone solves rapid double-clicking, duplicate submissions, and misfires during async processing. It's nothing more than putting a transition map and a single state-switching function inside a defineStore.\n\nI'll actually trigger rapid clicks on an answer button and a timeout interrupt mid-animation, and show how the state machine blocks them.\nWhat you'll take home applies broadly to any UI involving \"async processing + the user pressing a button\" — wizards, checkout flows, uploads, and the like.\n\nNow, when it comes to state machine libraries, XState (with its official @xstate\u002Fvue) is the standard choice. This talk, however, writes things directly in Pinia without bringing in XState, and shows a way to eliminate unintended behavior during async processing by re-checking state.\n(XState's own creator has said that a library isn't strictly necessary for state machines — this talk is essentially a live demonstration of that \"library-free\" approach.)\nhttps:\u002F\u002Fdev.to\u002Fdavidkpiano\u002Fyou-don-t-need-a-library-for-state-machines-k7h\n\nI'll also address the \"then why not just use XState?\" question head-on: what I'm covering here is just \"single phase + guarded transitions,\" so I won't be using XState's headline features (hierarchical states, parallel states, actors, SCXML, the visualizer). I'll also draw the line showing when you actually do need XState — once your states become hierarchical or parallel, or once you want to handle async work declaratively via actors.",[558],{"id":559,"avatarUrl":560,"color":40,"socialUrls":561,"name":559,"title":207,"affiliation":208},"northprint","\u002Fimages\u002Favatars\u002Fnorthprint.png",{"x":562,"bluesky":563,"github":564},"https:\u002F\u002Fx.com\u002Fnorthprint","https:\u002F\u002Fbsky.app\u002Fprofile\u002Fnorthprint","https:\u002F\u002Fgithub.com\u002Fnorthprint",{"id":566,"url":567,"type":515,"tracks":568,"start":510,"end":517,"title":569,"overview":570,"speakers":571},"lightning-talk-4","\u002Fspeaker\u002FKoutaro-Hanabusa",[11],"We Tried Adopting Vite+ Into Our In-House Design System at Breakneck Speed","In other languages, having an integrated toolchain from day one is taken for granted. In Go and Rust, building, testing, and formatting all live together within a single, unified world. In JavaScript, on the other hand, the test runner, linter, formatter, and task runner have existed as separate tools, and combining and maintaining them has always been our own job.\n\nReleased on March 13, 2026, vite+ is an integrated toolchain aiming to solve that fragmentation. It bundles testing, linting, formatting, task execution, and even Node management, all into a single `vp` command.\n\nWe adopted this vite+, freshly released and still in alpha, into our in-house design system at breakneck speed. Bringing an alpha release into production assets is normally a decision you'd avoid. You might be thinking, \"wait, you already put an alpha release into production?\" Even so, in this talk I'll honestly share why we made that call, and how it actually went once we did.\n\nThere were things that went well with the migration, and things that didn't go so smoothly. How much complexity were we able to fold away, where did we get stuck, and why did we decide to put an alpha release into production? I'll show the specifics on stage.\n\nReference: https:\u002F\u002Fviteplus.dev\u002F",[572],{"id":573,"avatarUrl":574,"color":40,"socialUrls":575,"name":578,"title":419,"affiliation":32},"Koutaro-Hanabusa","\u002Fimages\u002Favatars\u002FKoutaro-Hanabusa.png",{"x":576,"github":577},"https:\u002F\u002Fx.com\u002Fburio_16","https:\u002F\u002Fgithub.com\u002FKoutaro-Hanabusa","burio",{"id":580,"url":581,"type":515,"tracks":582,"start":510,"end":517,"title":583,"overview":584,"speakers":585},"lightning-talk-5","\u002Fspeaker\u002Fhakshu25",[11],"What a Small Improvement to Vite+ Teaches Us About Getting Started with OSS Contribution","Every day, our development relies on the help of the many OSS projects that surround Vue. I'm sure a lot of people feel like \"I want to contribute to OSS, but it seems hard.\"\nBut those little \"I wish this were improved\" moments you notice as a user? You can actually fix them yourself, with your own hands.\nI responded, via a PR, to one user's voice about Vite+'s `vp migrate`: \"it's hard to tell why this file needs to be migrated, because there's so little information.\"\n\nIn this lightning talk, centered on Vite+, and drawing on real examples of PRs I've sent to other OSS projects like Storybook and Oxc as well, I'll introduce how to find things worth contributing to, along with the etiquette of small OSS PRs — keeping each change scoped to one thing, linking it to an issue, and how to write the PR itself. I'll also touch on where to draw the line between what you hand off to an AI agent (like Claude Code) and what you take responsibility for yourself.\n\nAll of this, including making use of AI, isn't any different from your everyday work — no special skills required. Take home a way to take that first step, for the sake of the next person after you.",[586],{"id":587,"avatarUrl":588,"color":40,"socialUrls":589,"name":592,"title":593,"affiliation":32},"hakshu25","\u002Fimages\u002Favatars\u002Fhakshu25.png",{"x":590,"github":591},"https:\u002F\u002Fx.com\u002Fhakshu25","https:\u002F\u002Fgithub.com\u002Fhakshu25","hakshu","Web Engineer",{"id":595,"url":596,"type":515,"tracks":597,"start":510,"end":517,"title":598,"overview":599,"speakers":600},"lightning-talk-6","\u002Fspeaker\u002FEluwing",[11],"How a Foreign Engineer Uses Vue Prototypes to Align on Specs","I've worked as a foreign engineer on a Japanese frontend team for 9 years. Time and again, in spec confirmations and progress updates, we'd both think we \"understood each other,\" only to discover a mismatch later on. As someone who isn't a native Japanese speaker, this was a particularly big wall for me.\n\nRecently, the barrier to building prototypes with AI has come down, and there are more and more situations where, instead of explaining things in writing, we reach agreement by showing a working Vue component. When you make something people can actually touch through screen sharing, misalignments in understanding surface much faster. The act of moving forward while showing something concrete has also helped build trust within the team.\n\nIn this lightning talk, I'll share, from a foreign engineer's perspective, techniques for aligning understanding through \"something that works\" rather than relying on words, in Vue\u002FNuxt development.",[601],{"id":602,"avatarUrl":603,"color":40,"socialUrls":604,"name":606,"title":607,"affiliation":420},"Eluwing","\u002Fimages\u002Favatars\u002FEluwing.png",{"github":605},"https:\u002F\u002Fgithub.com\u002FEluwing","noh wan","Frontend Engineer",{"id":609,"url":610,"type":515,"tracks":611,"start":510,"end":517,"title":612,"overview":613,"speakers":614},"lightning-talk-7","\u002Fspeaker\u002Fdrumath2237",[11],"Understanding How Vue Custom Renderer Works by Building a Web3D Library","Custom Renderer is a powerful feature that lets you use Vue SFC to render things other than the DOM.\nHowever, there isn't much information out there about it, including in the official docs and articles written by the community, so it can seem like a somewhat difficult feature to learn.\n\nIn this session, I'll introduce how I was able to make use of Vue Custom Renderer while developing a wrapper library for Babylon.js, a Web3D library.",[615],{"id":616,"avatarUrl":617,"color":40,"socialUrls":618,"name":622,"title":264,"affiliation":623},"drumath2237","\u002Fimages\u002Favatars\u002Fdrumath2237.png",{"x":619,"bluesky":620,"github":621},"https:\u002F\u002Fx.com\u002Fninisan_drumath","https:\u002F\u002Fbsky.app\u002Fprofile\u002Fdrumath2237.bsky.social","https:\u002F\u002Fgithub.com\u002Fdrumath2237","Ninisan","HoloLab inc.",{"id":625,"url":626,"type":515,"tracks":627,"start":510,"end":517,"title":628,"overview":629,"speakers":630},"lightning-talk-8","\u002Fspeaker\u002Fryuhei373",[11],"At the End of the Day, What Can Nuxt Layers Actually Do, and Why Is It Great?","Nuxt Layers has been available since Nuxt 3, but there isn't much information about it in Japanese, and I think a lot of people's understanding stops at something like \"it's some kind of monorepo-related thing.\" I was actually one of those people myself — I was interested in the Nuxt ecosystem but had never gotten around to trying Layers, so this time I took a fresh look and verified it firsthand.\n\nWhat Layers really is, at its core, is a mechanism for composing the building blocks of a Nuxt project together, wholesale, from separate sources. Beyond just separating concerns within a monorepo, it can also be used to share UI across multiple sites, switch features on and off per environment, and swap out themes. Along with concrete examples from my own investigation, I'll introduce the essential nature of the Layers feature and patterns for putting it to use.",[631],{"id":632,"avatarUrl":633,"color":40,"socialUrls":634,"name":632,"title":638,"affiliation":639},"ryuhei373","\u002Fimages\u002Favatars\u002Fryuhei373.png",{"x":635,"bluesky":636,"github":637},"https:\u002F\u002Fx.com\u002F373_3","https:\u002F\u002Fbsky.app\u002Fprofile\u002Fryuhei373.dev","https:\u002F\u002Fgithub.com\u002Fryuhei373","Engineer","north star Co.,Ltd.",{"id":641,"url":642,"type":515,"tracks":643,"start":510,"end":517,"title":644,"overview":645,"speakers":646},"lightning-talk-9","\u002Fspeaker\u002Fkoki_m",[11],"Dynamic, Composable UI for Hospital and Medical Systems Built with SFC","In hospitals, even when looking at the same patient, the information needed differs by role — doctors, nurses, pharmacists, clinical engineers, and so on. What's needed also shifts depending on the clinical setting: outpatient, ward, ICU, operating room, emergency department. In this lightning talk, I'll introduce a mechanism where the screen is designed as a collection of small Vue components (widgets) that users themselves can freely arrange and save. I'll share the thinking behind UI design specific to hospital and medical systems, along with a live demo of actually rearranging the screen.",[647],{"id":648,"avatarUrl":649,"color":40,"socialUrls":650,"name":652,"title":653,"affiliation":32},"koki_m","\u002Fimages\u002Favatars\u002Fkoki_m.png",{"x":651},"https:\u002F\u002Fx.com\u002Fkoki_m","kouki.miura","Healthcare IT Engineer",{"id":655,"url":656,"type":515,"tracks":657,"start":510,"end":517,"title":658,"overview":659,"speakers":660},"lightning-talk-10","\u002Fspeaker\u002FCrafterKina",[11],"How to Live With Deep Reactivity — Convenient, and Dangerous","Vue uses Proxy to provide reactivity for mutations on ordinary data structures.\nWhile this is convenient, it's also a dangerous feature: things like `defineModel`, writable computed, and even props themselves can become a source of confused data flow through implicit mutation.\nFor example, when you pass an object as a prop, the child component it's passed to can mutate that object without anyone stopping it or raising a complaint.\nIn this lightning talk, drawing on real experience, I'll introduce common patterns of data-flow confusion caused by deep reactivity, and consider what countermeasures are available.",[661],{"id":662,"avatarUrl":663,"color":40,"socialUrls":664,"name":666,"title":667,"affiliation":32},"CrafterKina","\u002Fimages\u002Favatars\u002FCrafterKina.png",{"github":665},"https:\u002F\u002Fgithub.com\u002FCrafterKina","Kina","Programmer",{"id":669,"type":19,"tracks":670,"start":510,"end":671,"programs":672},"session-16:35-17:05-track4",[12],"17:05",[673],{"id":674,"url":675,"type":19,"tracks":676,"start":510,"end":671,"title":677,"overview":678,"speakers":679},"session-16","\u002Fspeaker\u002Fyut0naga1",[12],"Learning Decision-Making from the Vue.js GitHub","Vue.js has continued to evolve for over a decade. Behind that evolution lie countless discussions in Issues, Pull Requests, and RFCs.\n\nIn this session, we'll use AI to comprehensively organize roughly a decade's worth of Issues, PRs, and RFCs accumulated in vuejs\u002Fvue, vuejs\u002Fcore, and vuejs\u002Frfcs, in order to understand what challenges Vue.js has faced and what decisions it has made along the way.\n\nIn this session, I'll be reading through the public records left on GitHub not as a committer, but simply as a Vue user. By tracing discussions that you can't see from release notes or official documentation alone, I aim to understand \"why\" features like the Composition API and \u003Cscript setup> ended up taking the shape they did.\n\nWhat I want to introduce in this session isn't the history of Vue.js itself. It's a new way of learning — learning about OSS design and decision-making by reading through the discussions left on GitHub.\n\nNow that AI lets us work with massive volumes of development history, I believe OSS can be leveraged not just as something to \"use,\" but as something to \"learn from.\"\n\nI hope that those who want to understand Vue.js more deeply, and those who want to learn about design and decision-making from OSS, will walk away with a new perspective.",[680],{"id":681,"avatarUrl":682,"color":40,"socialUrls":683,"name":686,"title":687,"affiliation":688},"yut0naga1","\u002Fimages\u002Favatars\u002Fyut0naga1.png",{"x":684,"github":685},"https:\u002F\u002Fx.com\u002Fyut0naga1","https:\u002F\u002Fgithub.com\u002Fyut0naga1","Yuto NAGAI","Senior Consultant","Future Architect, inc",{"id":690,"type":7,"tracks":691,"start":448,"end":692,"heading":693,"programs":694,"display":695,"isPcOnly":696},"transition-1",[9],"18:00","Transition",[],{"startTime":32,"endTime":32,"color":57},true,{"id":698,"type":7,"tracks":699,"start":448,"end":700,"heading":54,"programs":701,"display":702,"isPcOnly":696},"schedule-16:50-16:55-track2",[10],"16:55",[],{"startTime":32,"endTime":32,"color":57},{"id":704,"type":19,"tracks":705,"start":700,"end":706,"programs":707},"session-16:55-17:25-track2",[10],"17:25",[708],{"id":709,"url":710,"type":19,"tracks":711,"start":700,"end":706,"title":68,"overview":32,"speakers":712},"session-17","\u002Fspeaker\u002Fmnmxmx",[10],[713],{"id":714,"avatarUrl":715,"color":40,"attendedIndex":716,"socialUrls":717,"name":720,"title":721,"affiliation":32,"bio":722},"mnmxmx","\u002Fimages\u002Favatars\u002Fmisaki-nakano.png",6,{"x":718,"github":719},"https:\u002F\u002Fx.com\u002Fmisaki_mofujp","https:\u002F\u002Fgithub.com\u002Fmnmxmx","Misaki Nakano","WebGL Developer","Misaki Nakano has worked as a WebGL developer since 2016, implementing WebGL for corporate branding sites, simulations, and data visualizations. She currently works on GitHub’s brand team.",{"id":724,"type":7,"tracks":725,"start":671,"end":726,"heading":54,"programs":727,"display":728,"isPcOnly":58},"schedule-17:05-17:20-track4",[12],"17:20",[],{"startTime":32,"endTime":32,"color":57},{"id":730,"type":19,"tracks":731,"start":726,"end":517,"programs":732},"session-17:20-17:50-track4",[12],[733],{"id":734,"url":735,"type":19,"tracks":736,"start":726,"end":517,"title":737,"overview":738,"speakers":739},"session-18","\u002Fspeaker\u002Fushironoko",[12],"Migrating 10,000 Lines of Untyped, Untested Domain Logic from Vuex to Pinia","At Studio, we have a decade's worth of accumulated Vue.js code assets from our development history. While this code still supports Studio's hot paths today, every time new code was added, the old code — especially the domain logic held within Vuex — ached like an inflamed wound. Even now, in 2026, in an era where coding agents have become the norm, this problem had gone untouched, and there was a shared understanding that the longer someone's tenure, the less likely they were to be the one to take it on. In this talk, I'll share how I, just three months into the job at the time, confronted this challenge and saw it through to completion. I'll cover the Vuex\u002FPinia migration itself, how to make effective use of coding agents, and the mindset needed to tackle a challenge like this, in roughly a 3:4:3 ratio. I'll also touch on the positive impact the move to Pinia had on broader efforts afterward, including improving module dependencies and domain modeling across a wider scope.",[740],{"id":741,"avatarUrl":742,"color":40,"socialUrls":743,"name":741,"title":607,"affiliation":747},"ushironoko","\u002Fimages\u002Favatars\u002Fushironoko.png",{"x":744,"bluesky":745,"github":746},"https:\u002F\u002Fx.com\u002Fushiro_noko","https:\u002F\u002Fbsky.app\u002Fprofile\u002Fushironoko.work","https:\u002F\u002Fgithub.com\u002Fushironoko","Studio, inc.",{"id":749,"type":7,"tracks":750,"start":706,"end":692,"heading":693,"programs":751,"display":752,"isPcOnly":696},"transition-2",[10],[],{"startTime":32,"endTime":32,"color":57},{"id":754,"type":7,"tracks":755,"start":517,"end":756,"heading":757,"programs":758,"display":759},"close",[11,12],"19:30","CLOSE",[],{"startTime":32,"endTime":32,"color":760},"grey",{"id":762,"type":7,"tracks":763,"start":692,"end":756,"heading":764,"programs":765},"after-party",[9,10],"After Party\nsupported by Link and Motivation Inc.",[],1785765564400]