Vue.js Amsterdam - Day 2

This talk covers the significance of attending tech conferences in the age of artificial intelligence. The speaker discusses how AI has become an integral part of software development, emphasizing the importance of continuous learning to leverage AI's capabilities effectively. They explain that as coding becomes easier, the challenge lies in determining what to build, suggesting that AI tools can assist developers in this process. The discussion further touches upon the emergence of new tools and frameworks within the Vue ecosystem, particularly the release of Vue 3.6 and Vite 8, which enhance performance and developer experience. The speaker highlights the collaborative efforts in the community to improve tooling and mentions various initiatives aimed at making application development more efficient. Overall, the session highlights the importance of community interactions and staying updated on technological advancements to maintain relevance in the fast-evolving developer landscape.

Feel like a brand new person. Finally taking flight. I know you don't think it's right. that you think it's fake. Maybe fake's what I like. Long as I have the right. Living life and wide. life. life out of sight. Living life. life this time. Going with always longed >> It's true. Men are all to chase. But baby and so different from And I know it seems wrong

to accept. But she's got your And she's got no it's hard to catch. The real realization is as good as a guess. She's got your demons. regrets. So how will I know that's right? I think you're driving me >> I'm the next step. Waiting in >> So, you probably travel in style again, right? Well, actually I'm just taking like Thank you for your attention. We're at this

conference now, but everybody is using AI to build stuff. Why do you think people would even go to conferences? Well, I think conferences are now more important than ever, but we can find out and ask a few people. Because there's a lot of things you come to a conference for, Tim. I mean, if we get to see cool people, of course. Right? But it's not just that,

it's also this AI can do everything. But the problem is we don't know what AI can do. Cuz we don't know where the limit is. But if you don't maybe go to a conference, you're not going to know what you can do because you're not going to learn about the things. So, it's really important to continue learning so that you can almost teach the AI or bring

the AI in the direction that you need to go in or that your your your company needs to to go into to learn more. Otherwise, it's going to be outdated. What's up, nerds? People are important. It's about the connection. It's about socializing. It's about connecting with everybody in the community, and it always has been. What I would say is that um in an age where code is

free, uh the thing that matters is knowing what to code. And the the the taste, right? What's good? What's not good? >> I think anyone who is reviewing PRs uh extensively is very, very well positioned to use some of these new tools. >> Code quantity was never the the the bottleneck. It's knowing what to build. And that's always the case. Um in a way, LLMs are making

us all product managers. We have to understand our users much more. We have to ask the big questions. Is this the right thing to be doing? And I think that's good. I'm ready. Yesterday in the panel, I found it interesting you talked a lot about AI slop PRs. Can you tell us a little bit more about that? But it's not a problem of the amount of PRs.

It's basically the nature of them. It seems like uh the social media's sloppiness of AI is coming into the open source world as well. The most of this PR when you give them feedback and you say, "Hey, can you change this because this approach is better?" Or you give them feedback about the business logic uh behind that something the agent not grasp by the code base, you

get a response like, "Yes, you're right." Open source already had the of capacity. Again, it doesn't matter if you have the help of AI to create your PR. We want to talk with a human. Good morning. Good morning. Good morning, guys. Yes, now. Okay, good morning, Vue JS Amsterdam. Welcome to day two. Everyone awake? Everyone get some coffee in the system? Getting there? Yeah? Awesome. Did you

guys learn something yesterday? Raise some hands. Did we Did we all learn something yesterday? Amazing. How many of you learned something about new that involved AI? Yes? Okay, almost everyone. What a surprise, right? All right, guys. My name is Alex. I'm an engineer. I've been shipping Vue and Nuxt for years. Love it. And I'm excited to be here just as much as you. And I'll be with

you for the first block today. And honestly, I don't want to keep you waiting. Our first speaker doesn't need introduction. I set up his laptop at Vue Conf, so I guess that makes me a Vue contributor. I don't want to keep you waiting. Please give a big round of applause for Evan You. All right. Happy to be back. How many of you are here for the first

time? Okay, great. So, today's talk So, just a note, I always use state of Vue as kind of the placeholder title, but today's talk is going to be about a lot of stuff. But, let's start with view. Um, I'm going to skip the boring things about view like the stats growing, uh, like we're at like 9 million weekly downloads, or how what percentage of view three usage

is now. I think we can leave view two behind at this point, so I'm going to stop mentioning that. Um, the interesting thing about view going on obviously is Vapor Mode. Um, so we're not releasing Vapor Mode today, but Vapor Mode has been going on. We've been quiet about it, but it has, if you look at the minor branch, it is like 1,200 commits ahead of main

right now. Uh, there's actually been a lot of work going into it, uh, by Edison, and it's almost ready. Some of the main things that's been shipped in the past few months in the beta, uh, in the 3.6 beta including type inference for Vapor components, uh, V DOM teleport suspense in Vapor components, rendering Vapor slots in V DOM components, uh, Vapor Mode support in View Router, JSX

support via View JSX Vapor, and the 3.6, uh, when you create view, run the create view, uh, scaffolder, you now get a 3.6 option that's, uh, scaffolds a Vapor app out of the box. and Vapor Mode will be coming very soon. Uh, and please be patient because I have been working on so many other things that I think the detour is worth it. So, I did, you

know, I took the detour to work on Vit when I was working on View 3, which, you know, dragged on the View 3 release for a very long time. I think this time it'll also be worth it. So, please be patient with us. And, uh, and the interesting thing about the view ecosystem is we are seeing an interesting wave of view tooling renaissance. Um, many of you

have probably been using the official view language tools for a very long time. Um, it's been particularly challenging topic because, uh, language tooling support is has always been this really, you know, specialized field where uh you need to understand how LSP's work, you need to understand how views compiler pipeline work, uh you need to also understand how TypeScript work, you need to, you know, plumb all these

things together. But uh now with AI this whole surface is actually uh collapsing really fast and uh becomes more manageable for people to explore new ideas. So, first of all, the official view language tools has undergone major improvements in the past few months. It actually went from 300 plus open issues down to fewer than 30. So, Johnson and Circle, Circle is here, I believe, um has been

working really really hard on improving view language tools and closing issues. So, I want to give a big shout out to the hard work. Uh on the other fronts, we're seeing a few other community-led initiatives uh trying to reimagine what view tooling could be like. So, one of these is the V's project. Um so, if you're interested, check it out. It's by a Japanese view community member,

now a team member, uh Ubuge, and he's been essentially writing this whole Rust-powered view tool chain including the compiler, linter, formatter, type checker, and everything on top of Oxc. and there is also experimental uh effort in integrating the view specific linting parts back into Oxc lint as a plugin. Um so, definitely check it out. Crazy performance. Um this is currently still unofficial, but obviously uh we're keeping

an eye on it and see how far this could be pushed. And then there's also Further, which is uh made by another team member, Peakax. Um so, interestingly, these are like independent efforts, but kind of have overlapping, you know, fields. Um this is again uh started as a language tools alternative implementation, but now is also evolving into a full compiler plus LSP implementation again, written with Rust.

And then there's also Go lar, which is a TS Go based embedded language support framework inspired by Volar. Volar is the lower level framework that's powering view language tools made by Johnson. Originally, Volar was created to support view language tools and now it's inspiring uh this architecture is inspiring Go lar, which is TS Go based. Um and TS Go uh and Go lar is also framework agnostic.

So, it has view support, which um interestingly you can also try today and it's made by Arved, who is the author of TS Go lint, which is the uh type aware linting engine that OX lint is is using for type aware linting. So, a lot of uh different efforts going on and right, where will be heading for uh say native tooling for view? Honestly, at this moment,

it's a bit early to tell, but it's exciting that these things are happening. So, I would say, let them cook and see how far they can push this and I think the um this little competition between these alternative explorations will end up benefiting all view users in the end. Okay. So, that's it for view. I'm going to save more time for the things that we want to

talk about later. But, big announcement, uh Vite 8 is here. Uh so, we released it yesterday. So, if you have not caught up with the news, uh please go read the the blog post, the announcement. Um Vite 8 is probably the biggest milestone that we've hit for in the history of Vite. It is um the biggest architectural upgrade since Vite 2. So, every major upgrade between 2

and 8 are incremental. There are no fundamental changes. It's just small breaking changes. But, Vite 8, it does not have a lot of breaking changes. The fundamental change is internally we have now completely replaced ESBuild and Rollup with Rolldown. And Rolldown is completely written from the ground up in Rust, powered by Oxc, and has a unified pipeline for both dev and production builds. And um you'll probably

see at least 5 to 30 times faster builds when you upgrade to Vite 8. Uh there shouldn't be any noticeable Uh so there is a migration guide, but for most apps it should just literally be bumping the version and you'll see faster builds. there are also a few notable features, built-in dev tools. Um this is for um build only right now. And then there is built-in TSConfig

path support so you can drop the uh Vite plugin TSConfig paths if you're still using that. Um built-in browser console forwarding for agents. If you use Vite with agents, you can now forward the browser console errors directly to the uh to your terminal so your agents see them. Uh and then there's the experimental bundled dev mode for extremely large projects that are suffering from slow initial page

load if you have just way too many source modules. And there are more. So check out the details in the uh Vite 8 announcement blog post. Um we are really excited to have more people try it and let us know how it works for you. Um it's being in beta for quite a long time so we're pretty confident it's going to be, you know, working well for

most you, your apps. So please upgrade. And another thing I want to mention is uh we are actually approaching the fifth anniversary of the Vite team creation. Vite as a project wouldn't have been where it is today uh thanks to the community and the team that contributed to it, that made it what it is, right? So um Matías, uh aka Patak, the cat, has been a very

uh you know, important force in pushing V to where it is today. So Matthias had took a break from open source due to personal reasons, but he's now back and we want to give him a warm welcome back with this you know, anniversary celebration. So we actually have an event at v.dev/live March 19th at 3:00 p.m. UTC. So we're going to have an online sort of re-premiere

of the documentary and have the team members all together and re-watching it. So feel free to come join us in celebrating this 5-year anniversary. Okay, so outside of Veet a lot of things have been going on at Voi Zero as well. we shipped major improvements to OX Lint and OX Format in the past few months. Note most notably the JS Linting Alpha for OX Lint just landed.

If you've been on the fence about moving to OX Lint because you have that you know, just this ES Lint plugin that you really really need but you couldn't use it in OX Lint. It most likely works now because the JS plugin during this whole process we have managed to reach 100% conformance on ESLint's own built-in rules. 99.9% conformance with like stylistic the ESLint stylistic preset. So

most known plugins should just work out of the box with OX Lint now. Obviously we hope you um, to use JS plugins selectively so that it doesn't completely tank the performance, right? It's still faster than using ES Lint with those plugins, but the fewer JS plugins you use obviously the faster it is. But that said we have worked really hard to make OX Lint as compatible as

possible to make migration easier. So you no longer have excuses now. And uh proper view support is still work in progress. This is the challenging part because the view ESLint plugin is not a typical ESLint plugin. Uh it has its own pipeline in parsing view templates, instantiating the ASTs, and all that. So, um we are exploring proper support for it, and it'll come later this year, but

there is also the and you know, exploration on integrating the V's view linting part into oxlint via as the web assembly plugin. And uh from what I can tell, ubegit already has it working to some extent, so we're excited to see where this goes. oxformat Uh it's it's now in beta. It actually reached beta last month, and we have also proudly reached 100% prettier conformance. In fact,

in this whole process, we found multiple bugs in prettier itself that we had to fix. Um that prettier is like have these tests ignored and just, you know, and we're like, we need to fix these. Uh so, we can We are actually 100% more com- conformant to prettier than prettier itself, in a sense. And additional file format through prettier itself. So, uh oxformat itself, the core, is

focused on JS and TS, but we also can format multiple other things by just invoking prettier, which includes view files. We also ship native Tailwind class sorting, uh if that is something you rely on. Okay? So, oxlint, oxformat, and Vite 8. We also ship Vitest 4.1, which bumps Vite dependency to Vite 8, right? So, we have all these new things that we shipped, which means a new

generation of tooling generally has arrived. So, if this is what you've been using, say, a year or two ago, right? You've probably been using like webpack, TS sub, Jest, ESLint, prettier. Now, we proudly say that void zero is providing you all faster and better alternatives to all of them. You can use V test, TS down, or explain or X format. That's still a lot of configuration files

though, right? Can we do better? Well, you bet. The answer is yes. What if all you need is a single V config TS file? And that is what's possible with V plus, which we are releasing today in public alpha, fully open source under MIT. So, we originally we had this plan to have a commercial license tied to it, we have decided if we want to make JS

developers really as productive as possible, which is the mission of the company, the only way to do it is to make it truly open source. So, V plus is going to be free for everyone to use. Thank you. So, um obviously V plus is more than just combining these things individual pieces we built together. There's something more on top of it, right? So, there is the obvious

things like dev, build, link, format, test, and pack. These are just proxying to these existing tools that we have built. But, there are things like VP create, which is uh scaffolding, self-explanatory. And there is a few things that need probably needs attention. So, first there's VP check. Um this is a sort of a compound command that includes the format, link, and type check all in one command.

So, it's also type checking through TS go. So, you are doing formatting, syntactical linking, type aware linking, and type check all in the same command, in the same pass. And it'll report everything together. So, um you can also add {dash} {dash} fix, which means the format will just be auto formatted out of the go. So, one command to do all the verification actually works really, really great

when you're working with agents, because you no longer need to tell the agent to, say, run format first, then lint, then type check. Just VP check, and there it is. Okay? So, the other thing is VP plus now has the capability of managing your Node.js versions. It has the capability to manage your package managers. It has the capability to run tasks in your mono repos and cache

them. So, which means, oh, it also can set up like Git commit hooks. It can also do, uh, lint staged capabilities, which means you should be able to eliminate Husky, lint staged, Turbo repo, or NX, or, um, FNM. Uh, all these things can be now replaced by just VP, a single binary to do it all. So, for the package manager part, we did not build a package

manager ourselves, because PNPM is excellent. So, the VP install part is more like a Corepack equivalent. It will recommend PNPM by default, and it will delegate the actual package manager tasks to PNPM, in- including workspace setup, etc. Uh, but it will, uh, it you can easily specify the version of PNPM you want to use by just using the same package manager field that Corepack respects, right? Uh,

a note, Node.js 6 is actually removing Corepack support, so good time to just use VP install, uh, if you have gotten used to just, um, not caring about which package manager you're using, right? Um, you can, of course, use NPM or Yarn, or even Volt, if you want. VP install is actually, uh, package manager agnostic, which means you can use it to manage the specific version of

package manager you want. So, if you have multiple projects you're juggling between, one is using PNPM, the other is using yarn, you can just use VP installing all of them and it'll automatically pick the right package manager with the right version to do the installations. VPEnv is a Node.js version management thing. So, the idea here is it respects dot node version files or the engines field in

your package.json. So, when you CD into a directory, it'll just automatically use the right node version. So, this feature is also So, when you install VP, we turn it on by default, but you can easily opt out by just saying VPEnv off and it'll just leave it alone. It won't If you don't want to use it, you don't have to. But, the idea here is when you

have it on, every other command you run is guaranteed to be using the right node version that you have specified with. Also, when you do VP install, for example, VP install G, it'll remember the version of node that you installed something globally with so that when you invoke that global binary, it's always invoked with the right node version that you installed with. And the nice thing is

even when you are switching between old versions locally, between projects, your global installations will still be there and still invoked with the right Node.js versions they were installed with, right? This is my personal pet peeve with FNM is every time I switch node versions, I lose all my global packages, which is really annoying. Um enough talk, let's do some demo. Um I'm going to just run the

VP help, right? So, um VP comes with this global binary, which means you need to install it with curl FSL HTTPS v.plus pipe it into bash. And that's it. So, I'm not going to run it here because I'm not sure about that the network here, but this is how you install it. Once you install it, you will have VP. And if you just run VP, it'll actually

give you this really nice interactive list of commands you can run with. So, I'm just going to say create. I'm going to create a mono repo because that is the best thing to demo things Use everything recommended. It sets up, you know, AI agent integrations, IDE integrations. Set up pre-commit hooks that'll automatically do formatting linting on your staged files. Please ignore this temporary TS down warning. We'll

get rid of it. Um So, VP demo. And if we look at the code, it's a pretty standard uh pretty standard mono repo. So, we have uh directories. One is apps. So, this is a website app. And one is the um the utils, which is a package internally. So, the utils is a right now it's still it's still using TS down, but like actually it's just importing

here. So, uh even So, we will tweak it so that the config is just going to be there and um the idea is this package is a library. You intend to either use it internally or you want to publish it. So, you will use VP pack to package it, generate the DTS files and all that. That's handled by TS down. This apps/website is an app. So, it's

a typical Veet app. All right. So, you will do VP dev, VP build, VP preview. And they're living in the same thing uh living in the same mono repo and they can have dependencies. So, what apps/website can depend on package utils. So, if I do VP uh env, uh I can say VP env which node, it'll tell me which node version I am using right now. This

is the default. So, if I uh come here and say add .node-version. I want to use version 25. Uh hmm, okay. If I reload this, VP which node? Now it's using node 25 inch Why is it still 24? Okay, sorry. But when you run VP run, it will be using node 25 for sure. Okay, so when you do VP run, the nice part here, the DX is

It actually shows you all the scripts that's available in your mono repo. Um so you get a get to see these are root scripts, right? And these are package scripts. So you can selectively run them and there's a fuzzy search, so I can do like uh build. I can see which package build I want to run. I can just run it from here. And notice that there's

something here. Says zero to cache hits because we didn't enable cache at all. So I'm going to go VP run ready, which just runs everything. Type check, build, everything. So it ran six tasks. And nothing is cache hit because I didn't enable cache at all. So now I just do --cache. Still no cache hit because this is the run that actually caches stuff. Now if I do

--cache again, it's immediate. All cache hit, right? So there's VP run, there's VP env, there's uh I think that's most of the things you would probably want to know on top of this, right? So um So this is VP less and we're excited to announce that VP less is going to be open source and uh everyone can start using it. In fact, Vue 3.6, the minor branch,

has fully migrated to VP less. Um so check it out for a real-world case on how it's been working. And it's released today fully open source under Just a single, you know, curls and to install in on your system. So, this is probably the fastest way for you to go from zero to something working on a fresh system. So, you don't even need to install Node.js or

PNPM or anything. It just just install VP and it'll manage all of them for you. And the docs is available at vplus.dev. It's live. Thank you. Okay. So, um still have some time. So, I'm going to do one more thing. Um so, we've built all this tooling. We've built V Plus. We've built, you know, all the things you need from going from a fresh system to having

a running V app. But, there's still a lot of gap between having a V app and all the way having something live in the cloud, right? You still need to pick a framework. You still need to pick a deployment platform. Still need to pick a database, an ORM, authentication. What if you want to do queues, crons, all the stuff? It's, right, the back end is the back

end story has never been part of the V story. So, today we're going to change that. Introducing Void, the V native the acronym, this is just a joke, but the acronym's V optimized isomorphic deploy. So, what is Void? Right? Is it just another deployment platform? So, the idea is Void turns any V app into a truly full stack app. Deploy at the edge on Cloudflare workers with

a single plugin. We actually got the Void package. So, if you install Void, employ uh, import the Void plugin, put it into your vite config, and then, voila, you have void deploy, and it goes live at the edge. No No Cloudflare account required. No Cloudflare infra knowledge required. And you just void deploy, and it goes live at the edge. So, what can you do with it though?

Like, what can you build with it? So, here's how it works. Um, it gives you two back-end full-stack capabilities with auto infra provisioning. So, if you import DB from void/DB, you get a D1 database locally and remotely. Locally, it's simulated through Miniflare. Import KV, you get a KV namespace. Import storage, you get R2 bucket. Import AI, you get Workers AI or bring your own keys. Import auth,

you get full authentication powered by Better Auth. DB schema is default to, uh, Drizzle. So, if you have a Drizzle schema, it powers the end-to-end type safety throughout the entire stack, source of truth. Uh, migrations are auto-generated and auto-applied on deploy. Crons, queues, just create a directory, put the files in there, and they'll go live when you deploy. And everything you do it locally, and then you

void deploy, it goes live in the cloud. You don't even need to sign up for Cloudflare. You don't need to go to the dashboard or anything. It's all through the CLI. We will have a dashboard eventually, but right now, you don't really need a dashboard. it also, all of these things, right? They work with not just plain vite apps, but also vite-based meta frameworks. So, the idea

here is we have a happy path that vite-based meta frameworks will be able to enjoy the, uh, these features as part of void's platform SDK. So, the void plugin composes with vite-based meta frameworks, which means if you use Nuxt, you can put void plug in into the next V config and you get these capabilities as well. If you use other frameworks like spell kid or 10 stack

start or whatever, it as long as feet based, it will likely just compose with void plug in, right? So, um you get to use the meta framework you and enjoy these back end capabilities. So, this SDK turns V base meta frameworks into truly full stack uh things and with a streamlined deployment. Void itself can also be used as framework on its it actually is a pretty capable

meta framework in itself. It has a rendering framework agnostic pages routing system. So, you can use view files as page components or you can use TSX or even solid files, spell files. You can have island components. Uh you can have markdown pages as page components. It has ISR, which means you can just export revalidate uh and it'll just cache your page with a 16 second stale while

revalidate header at the edge on Cloudflare CDN. It has SSG if you want to build locally fully to static. So, mixed rendering models, it gives you the ability to mix and match and choose ideal deployment model. Of course, the platform also supports deploying pure static sites. In fact, the staging documentation, which I can just briefly show you right now, is a V press site that's hosted on

void itself. So, every void app actually gets a void.app domain. Um so, you probably want to grab that really fast if once you're once you're in, um this is what it looks like when you build um an actual app using void space routing system. So, you can have a layout. The index view will go into the layouts component slot. Every page component has a corresponding server.ts file

in which you have actions and uh loaders and actions. Both are fully type end-to-end typed. Loader return values flow into your component automatically as props. And components have typed action and use one helpers on the client to invoke server-side actions. Um everything is driven by your drizzle schema. So, the drizzle schema generate DB types and you can also get uh action validators by inferring your uh validation

schema from your drizzle Any standard schema compatible validators, Zod, Valibot, Arc Type, you name it. Put it into your uh action handler and you get fully typed client and server uh communication mutations and data loading. Um and the navigation model is actually inspired by Inertia. I don't know how many how many of you use Inertia with Laravel? Um but it's actually a pretty pretty cool model that

has never been seen in the JS world. So, I'm pretty excited to um show this to people. And uh let's do some demo. if I go into uh this is a kitchen sink Hm. Okay. So, if you see here, I have a I off. So, this is under pages, right? So, every page every view component is just a page. Uh you you you just write the view

code you already know. So, this is an example of a loader. define handler. This is just a helper to give you context. If you don't need any args, you You even need it. So, here I'm just returning a plain object. So, this is just a list of uh uh AI models that's available. So, this isn't a a model that's available on Cloudflare's Workers AI. And these are

the things you need to provide your own keys with. But, the idea here is you're just returning some value here. And you can infer the return type from this handler. So, infer props type of loader. It'll extract the props type. Uh you just import that props type from your server component and then use it in define props. that value becomes your props here. Fully type safe. And

how do you use AI features? You just use fetch. Um fetch API AI. Um this is not using our type fetch helper. We actually have a fully type fetch helper, too. So, if you use this instead of um import fetch from uh void client. This fetch well, it's hm type is not fully working right now, I think. So, this fetch should also be fully typed. Unfortunately, TSC

is having some issues here, but um it'll actually give you auto complete on the all the available API routes. But, AI server.ts is really just um calling the endpoint. Oh. This one is actually not using the API we designed for, so I will need to pick more interesting demo. So, let's just look at more standard demo. So, here's the database. Right? So, you have a special schema

thing which points just points to the schema TS file in your DB directory. And here we're just using standard drizzle schema for SQLite because D1 is SQLite based. Uh there is some syntax highlighting issues, so if you look at this, we have the notes table, and we can infer a insertion uh using create insert schema from the drizzle validbot integration. And you can pass this insert schema

into your action here, so it automatically do both type and runtime validation on your action calls here. So, on the client side, db.view, we have a use form helper from the void view adapter. And you can use form with named actions, and these are fully typed. and then the form helper, the delete form, the So, the form can be used in normal forms very easily. And everything

is fully typed and integrates with your back-end code with minimal ceremony. Okay, so let's see what else. So, there are queues, revalidate, and et cetera. So, I'm not going to go into all of them, but you get the idea. This is a kitchen sink app. It just shows what is possible, right? So, uh if I invoke the void CLI here, it also has this really nice uh

interactive thing. So, you can it has a built-in MCP. So, if you're using an agent with it, uh the MCP can do things like MCP gives you the full doc search locally. The doc is shipped within the package itself. The MP The MCP is also local. And the MCP also has a code mode endpoint, which talks to the deployment server, so you can say uh what is

the log from my last deployment and why did it fail and it'll fetch that for you. Um and then you have code generation, so you can generate a model which will generate automatically generate a schema for you, so you can say void gen model posts title string content string etc. It'll generate the schema for you. Um the DB you can do reset seed execute migrate etc. DB

studio will actually fire up a local Drizzle Studio instance to for you to look at the SQLite database locally. You can also do um void remote equals one, set the end variable to one and you can actually develop locally with remote databases actually on an already deployed app. And then custom domain is also supported, manage secrets, look at the project status, login logout etc. All the things

you'd expect from a CLI. So, if I say right, so I have a lot of failed deployments because I've been fixing bugs, but this one is live, right? So, local development, so I'm going to start the local development here. oops, why am I stuck in full screen? So, 5136. This is the kitchen sink app, right? Right now that all of this is local. So, hello world. Um

this is running against local SQLite database. There's KV, there's storage, everything is simulated. AI is interesting because actually this is running through a proxy to talk to a real model that's running in the cloud uh even locally there's off fully powered by um fully powered by better off, but it's more than locally, so let's deploy it. I'm going to say void deploy. Let's hope this works. It

was broken this morning and I had to fix it on the spot, but let's see if it works. It runs the migrations for you if it hasn't been applied yet. And it'll atomically abort if finds the migration failed. Oh, okay, it failed. But I have already had a successful deploy early earlier, so It's running in the cloud, so this is actually a live void.app. yeah, so this

is running against real databases. So, hello And if I refresh it, it's there. So, something that you can only demo when you're in the uh So, this is again uh what model are you? Okay, so this is working. Revalidate. So, this is the ISR feature that Next.js uh Vercel I Next.js has, so the idea here is you visit it. It tells you this was last render time

and now it's cached. So, matter So, for the next 60 seconds, it'll give you this stale cache response until but it's already rendered the next one. So, 6 6 60 seconds later uh you'll get a refreshed timestamp. You can also manually revalidate it, so um and you get a new timestamp here. So, It gives you all of these features uh with just a single V plugin. And

yeah, nothing else really. It's just a V plugin and you get all of this running in the cloud. Right now, this is obviously, this is still very early because we started working on this only a short while ago, but uh we believe this is going to change the way you think about going from zero to something working in the cloud and we want to combine this with

V plus. So, V plus with void allows you to go from a fresh machine to working app with all these features in the cloud in under 5 minutes and that is what we define as making JavaScript developers as productive as they can be. And check out V plus V plus dot dev. you can also request to join private beta for void at void.cloud. Amazing. Thank you, Evan.

Awesome, guys. Wasn't that exciting? Honestly, I'm really excited to use all of these tools. I already saw I opened that website like some of you and I saw people already writing some comments on it, but that's how it goes. So, our next speaker is actually talking about something that's really close to what I'm coming from. I learned view as a one-man show and I can went through

a lot of pains trying to get there to actually get it to production. And well, Luella is going to tell you a lot more about that and uh I'm really excited to hear about that. So, big big round of applause for Luella. Trust in mama. >> Well, in a room of engineers there's still tech issues. I mean, like the amount of times that we've had made that

joke how many engineers do you need to set up a printer today or at this yesterday and it's kind of ironic honestly. And I guess in a room of engineers we still can't get screen mirroring to work either. Uh if anyone works at Apple or Microsoft let's have a walk word afterwards cuz I don't know this is like the main problem with every conference isn't it? We're

almost there. Anyway, are you guys excited um to hear about simplifying your pain? I mean I talked about this with Dragon earlier and this is another talk. Like today I feel like is my my day to hear about all these talks in cuz it's just one pain of mine after another. Yesterday was a lot of learning and today is a lot of of yeah that's what exactly

happened to me a month ago. I mean like this is for me perfect. we there? Oh no. Oh no no really. Do you have any more of these? It worked for me like >> All right. I think we almost have it. big round of applause for Louella and for not for Microsoft though. Hi everybody. Sorry for the delay. It's like technical difficult difficulties can always happen. What

a pressure to stand here after Evan just made two huge announcements. It's great to see Vue progress in that kind of way every single year here at Vue JS Amsterdam. Uh I'm not going to pretend that I know so much about Vue as that Evan does because I don't. Uh I'm going to be honest with you, but I am very good at making mistakes. And I want

to tell you a little bit more about that in this upcoming 25 minutes or so. So, let me give you a little bit of backstory. I am Louella Cremers and I'm actually more of a back-end developer. 3 years ago I started working as a back-end developer. In university I only learned about back-end. Front-end didn't really do much for me. Didn't interest me. Um and also my internship

were in done that. So, I just never touched any front-end in general at all. Did a little bit of React, a little bit of Angular just because I had to to help out front-end developers with getting the API endpoints right or changing a color real quick, but that was pretty much it. And then after 3 years I decided I was sick and tired of commuting and I

was going to start freelancing. And through my network I got this opportunity to work with .NET, but to also work on rewriting an application uh from an old code base to Vue 3. And we were a very small team. We still are, about 10 people. And we are pretty much all back-end developers. So, it's kind of like figuring out how to drive without any assistance of a

person that can drive. Uh so, yeah. So, the current application that we had before this was a razor page application. Might not tell you much, but it's a very old technique that Microsoft still uses. Uh and it's not up to par with what uh for example, Vue or React can give you. It's not reusable. It's It's clunky. It's old. Uh I don't like it at all. I

don't like any front-end written in C# to be honest. It is my expertise, but I like the API stuff. I like don't like the front-end stuff. Uh and there was also a little bit still in Vue 2. And because it was a mix of like 80% C# code on the front-end and 20% Vue.js 2 uh on the on on there as well, we decided, "Okay, we are

completely going to start over from scratch." And before I got on or a little bit after that actually, I got a meeting with a senior developer that already created the MVP. And he told me where everything lived, and he look gave me a little bit of code examples, and pretty much the message was, "Good luck. Uh go learn on your own, and if you have any questions,

I'm also back-end developer, so I also don't know it, but I will try my best to help you." Uh so, That also means that I started learning Vue.js pretty quickly. I started shipping very quickly and I made my first PR that I got merged in January 17th of 2025. So, I've been using Vue now more than I'm using C# for about a year. Also, fun fact, maybe

you were here last year. I was here last year as well for the panel and I was sitting next to Alex Daniel and Alex and I had about two year two months of Vue JS experience trying to tell you all what to do. I was very honest last year that I didn't know through meeting all of you, through meeting the speakers, and through having a little bit

of Vue JS experience, I really started to love Vue because you all are an amazing community. Uh I I felt very welcoming and that also made me more interested in learning more about Vue. And what I especially loved about Vue on the technical part is how structured it is. I love C# so much because it's clean code, it's readable, but it's also very structured and Vue JS

had that same kind of architecture. So, Vue JS kind of became my holy grail because I tried a little bit of React and it felt way too hacky, way too loose. I had trouble with learning about hooks. I still teach React at university because it's part of the curriculum, but I really can't stand hooks. Still after 5 years, I do not like it. I don't want to

work with it. I just don't. Uh I've also worked in very small amount of Angular and Angular has too much setup time. It has too much restrictions in my opinion. And Vue JS is kind of the middle ground for that. It's it's awesome and it works great. Uh it's easy to read. It's clean. I love it. And I especially fell in love with the composition API. Just

the way it's structured and how it everything makes sense, but it isn't too structured and I to read docs and docs and docs. It's great. Just a template on the top and then the setup at the bottom and then the styling. It just makes sense to me. I was learning quite quite literally learning uh, in a way that maybe was kind of all over the place, very

much improvising. Uh, and with that also comes making lots of lots of mistakes where I'm looking back now and I was I'm thinking, why did I do this? I I can't go back anymore because it's already in production, but I wish I did it differently. And I am going to tell you a little bit about that and hopefully you don't make the same mistakes as I did.

So, let's talk about, first of all, mistakes that I've made, that I've noticed from either me or a colleague that has been working on Vue, with kind of a back-end point of view. And also, what I would do differently now. The first one is to Vue's reactivity I am a back-end engineer. I've never had to care about states or about reactivity. So, I really had to read

up on that and I didn't really do that. I just tried to Okay, this has to be reactive. Okay, I'm going to go with ref or computed and just hope for the best that it works out. Uh, that's not a great way to go. So, yeah. Uh, it also led to confusing state management and it made uh, components harder to reason about because I really didn't know

what I was doing whether what the difference was between ref reactive I just didn't know and it still takes some time. Nowadays I still have issues with it because it doesn't always click. I hope it comes at some point but that is my experience. And also it slowed down development and debugging because I kept using the wrong properties. So for in case you don't know ref in

a way that I understand this is that there's a singular property that is reactive that needs to be changed once something in the component is changed. Reactive is pretty close but it can have multiple properties. It's an object. Computed is when you want to use reactive uh a component or property and you want to change this somehow with another reactive thing or you want to change it

with a value. And also watch is still a headache for me. It has always been a headache uh to run logic where reactive states are Now what are my solutions? What do I what I recommend to you? Look at the documentation. Please. Please do that. Look at the documentation more. Don't rely on AI AI all the time. It can hallucinate. It doesn't know what it's doing. Please

just look at the documents. Uh Vue School also very good. Those courses helped me a ton. Uh if you don't can't wrap your head around reactivity system completely uh please consider Always use ref for state. I try to stay away from reactive completely because most people are using ref so why would I use reactive? And also the most of the documentation is in ref so I try

to stick with that. Uh use computed for the ref values. Well, it makes sense. And only use watch for side effects because I tended to put watchers on top of watchers on top of watchers on top of watchers. And that way components start to do very strange things when changes are happening. And it's hard to debug and it's going to take hours to fix it and you

don't want that. So, keep your watches simple and only for side effects. So, yeah. Uh, ref, reactive, computed, watch, try to figure that out as you go. I would prefer to do before you actually start writing view, but you know, sometimes that's not an option. Something that I'm also very good at is making my components very, very, very, very big. Yeah, I know. And I still tend

to do this because I just feel like stacking up and then I'm thinking, "Oh, yeah, I need to add that. Oh, yeah, I need to add that. Oh, yeah, I need to add that." And then I forget to split and I just end up with a huge file. I have to be honest, I pushed this file to master last week. So, I still make this mistake very

commonly. I'm trying to learn. I'm trying to not do it, but uh, yeah. Because if you do it, you have too much logic in one file. It's hard to maintain. It's hard to debug. It's hard to test. You have multiple responsibilities in one component. It's it's just a whole mess. Especially if you have to fix this one little thing, no, it's not uh, I would not recommend.

Now, what would I do to fix this after I just pushed this last week and now I have to fix it is, of course, break the UI into smaller components, abstract logic into composables. It took me a very long time to figure out that composables are a thing and what they do. And now I'm very thankful that I do because it makes stuff more more split out.

And also separate business logic from UI. Don't use routes in your components. Use uh a TypeScript file or something like that. So, this navbar that I created last week should be split into I don't know, main navbar links, uh the dropdown separated, the support button separated, the avatar menu separated composables that do all the action logic. So, use navbar active state. Uh use navbar visibility because I

probably have to split on desktop and on phone. Uh and use navbar permissions, for example, for the admin dropdown because you don't want the regular users to see Um so, that's what I would recommend for mistake two. Mistake three, using Pinia for literally everything because it's easy, because I can access it from everywhere. And to be honest, if you see the mascot, I it's it's just shouting,

"Use me. Please use me. Please. Please." and that is also not great because you want to split everything into nice clubs. Uh because stores become too large. Again, just with components, uh it's then hard to test. It's hard to to pretty much do anything with it. And the components depend too much on the stores. It cannot do anything without the stores anymore. And then it's hard to

place it anywhere else. It's just a big headache. so, what would I do to solve that one? I would, for example, only use Pinia for global state, so only if I really need to use it all over the place and not just for one or two components. I would move reusable logic again to composables because it just makes sense to do it that way. I would put

the helpers in TypeScript modules instead because I also tended to put a lot of helper functions in my in my states or my uh global states, which also was a mess, a total mess. And I would also, again, keep the store small and focused because that's easier to maintain, easier to test, and easier to work with. And the last one I have on this list is a

big one. I didn't use Nuxt. And to be honest, this wasn't my decision because somebody already wrote the MVP, so I didn't get to say whether or not I want to use Nuxt or Vue in that matter. I did get a chance to use Nuxt in projects that I'm making for myself, and I'm also, for example, using Twist TS for things that I'm doing myself. Uh, and

I figured out there's more out there than just vanilla Vue TS, and Nuxt is really nice to work with. because we right now have a couple of thousand active paying users, uh about 200 plus Vue files in our code base, and about 200 plus TypeScript files, uh which means that it can be very um ex- uh the extendability kind of is at its peak right now. And

we it's hard to maintain, it's hard to extend even further. Uh, so, I wish we used Nuxt. Because not using it means more manual setup, lots of imports, lots of router stuff that I wouldn't have to deal with if I had Uh more boilerplate code and a harder project structure. So, yeah. If there's one thing I could change, it would be going over to Nuxt. if I

had to restart, I would pick Nuxt in a heartbeat. Uh keep components small uh small and focused. Pretty much would like to keep everything small and focused except for maybe the views. Uh use Pinia only for global state. Use composables a lot more than I did initially because it's it's a great. And also learn Vue reactivity way earlier and spend way more time on reading the documents

and watching course by people that know a lot more than me uh on that track. if you want to find these slides online later on, you can find them on luelladotdev/socials. If you want to reach out to me on social media, you can also do that. And with that, I hope you at least, if you're at the beginning of your Vue JS journey, that you learn something

and you don't make my mistakes because, please, don't. Okay? Thank you. Awesome. Thank you so much, Luella. I'm actually curious, guys, you know, watching this talk, um watching this talk, I was curious, how many people here have started using Vue or Nuxt this year? 2026? 2026? Wow, okay, that's surprising. That's awesome that you're here. >> Awesome. Yeah. Um actually, and how many of you guys have used

it for, let's say, 2 years now? Only 2 years. Okay. Okay. And who's above that? Who's like 2 to 3 years? Okay, that's a lot of you guys. >> Wow. But that's cool. Honestly, I've been since 2020. 2020, 2021? I think. And everything here was like a validation to me. I wish I started sooner. I do. Yeah. It's honestly it saved my life. Actually, my first project

was migrating a ASP.NET Razor app Oh, right. to Vue.js. So, like, I was like, "Okay, yeah." Talking from my exact experience, I had the same thing happening. Uh it was hilarious, except that I don't know C#. It was actually the first programming language I learned. And then I had this client project, and he was like, "So, I have this .NET app. Can you port it to Vue?"

And I'm like, "Sure. Yeah, I know what this is. I can Yes. Microsoft, I have a MacBook." But surprisingly, .NET works pretty good on on macOS. Even better now. And C# is kind of cool. I totally agree with that but I think most of us here are more in the TypeScript corner, right? Is there like people who work with .NET as an API at all? Full stack?

Yeah? >> of hands. >> Okay, that's a couple of people. That's pretty cool. Yeah. but most of you, I guess, let's do Let's do a survey, okay? So, let's do like the the big ones, okay? Who does their APIs in Python? Okay. Okay. Let's say like 10 10 15%. Okay, cool. And who writes their APIs in Node with Express? Classic, old school. Wow, okay. Me too. Okay.

But okay, Next? That's honestly less than I would have expected. I would have expected like a lot more. Okay, uh what else is there? I mean Ruby. Ruby. All right, let's do Go. Go exists. PHP. What? Okay. Okay. So, like Laravel Laravel gang is is alive. I mean, that's I actually had a discussion, right, before this with our next speaker who is almost ready. Um about, you

know, I love Nuxt. He's not the biggest fan, but he's going to talk about why Vue.js will make your life a lot better in your company and why you should really do it. So, even though the agenda is not there anymore, big round of applause for Dragan. Mhm? Yeah, let me just correct this. Yeah, I think it's usually correct. See? Forward, backward, we're looking good. Nice. Excellent.

Good morning, everyone. As the slide shows, my name is Dragan, and having been a visitor of this very many past years, I'm more than honored to be able to share back with the community in this way. Um what I want to talk to you about is how to simplify your pain of scaling. Because in my experience, we all experience a lot of pain when building software. Uh,

not physically, hopefully, but in general, as we grow and scale exponentially, the problems we face get exponentially bigger and bigger. Now, I'm sure you all accept my undying expertise as a middle-aged, bearded, white man, but I try to give it slightly more context than that because for the past 20 years in my career, I've been building software and then later building teams, departments, companies, and products, and

then growing and scaling those across a bunch of different industries. my journey with Vue started in late 2017 at a company called HelloPrint, which is a print-on-demand e-commerce platform. where we did a full re-platforming of the entire tooling because it was running on PrestaShop. Sort of. And that was a bit of a nightmare. And then, you know, went with Vue 2 and with Nuxt, did the whole

shebang back in 2018, 2019 and if wondering, you know, how did that stack look like? Very outdated is the answer by today's standards. And if you're wondering if using Nuxt 1.0 is a good idea in 2018, the answer is no. Sorry, Sebastian. It's a lot Um, moving on from there, I went down to a company called Regional Dossier. Don't worry if you can't pronounce that, but basically

it's a water compliance SaaS platform and they did not use Vue. I have no desire to tell the entire team to delete seven years of work across multiple platform contexts. So, we stuck with React. But, in hindsight, that gave me the perfect testing ground to validate my thesis. And lastly, come to the company where they sort of accelerated a lot more when I joined Storyblok in 2022.

And there we were already using Vue in a more modern stack with Vue 3 using Pinia, using uh, Vite instead of sort of legacy context that was more familiar to me back then. And then, uh, we also used Nuxt, though not as extensively. And obviously the difference in tooling, even just today with Vue 8 and Vue 3 being announced, is is continuously staggering. But compared to 2018,

uh using Vue in 2022 and 2025 was a entirely different universe, and it's only gotten better. And that's the important thing to remember, because even in 2018, the pain of scale was already simpler with Vue. Um and it started when as far as introducing micro front-ends using Quasar as a as a uh sort of meta framework in that. So, from there. Now, my thesis. In these sort

of companies over the last 7, 8 years now, I've grown to think in patterns of pain, and not because I'm getting close to 40, and that's sort of my life at this I've got a thesis. I'm going to try and prove to you today. My thesis is that the Vue ecosystem makes the pain of scaling and building at scale much simpler. Uniquely so compared to almost any

other tech stack I have found, at least in the front-end. It's also a good moment to express my eternal gratitude to the hundreds of engineers I've had the pleasure of working with, learning from, making mistakes with over the last decade or because it is easy for me to stand here and say, "Look how cool this is." when they did all the work across the last decade. So,

I want to have to make sure that it's clear that all the things we gained because of them. And I'm just here to take credit. That's just my job. Um kidding. Okay. What causes pain when scaling up? Three main items. Hiring and onboarding takes time away from your team. If you're hiring people, the people you're usually using hiring with, if you're from start-up to scale-up, is your

most senior engineers, cuz they're the ones you trust, right? That means they're not doing other things, right? And then you have immature teams, because they never had a chance to look ahead beyond sort of let's survive the start-up phase. And lastly, obviously, architectural constraints or tech debt, or also known as if only I had more time to do this right the first time. Okay, so let's explore

these three for a minute because it's important for me that you all understand and get an idea of so the multiplicative compounding of the problems that these three collectively create when you are a startup going to scale up. Cuz when you're hiring new engineers, it's it's a well-established pattern. You hire a few engineers, you spend time on boarding them, and then you sort of bloat the team

until it's too big to be comfortable, you split it up, you have two teams, eventually you add a manager, rinse repeat, pretty stable, pretty sustainable, highly recommend if you are growing at a somewhat sustainable pace, right? If you are already in a scaled organization or you're already in a corporate environment, this is probably pretty comfortable, pretty standard. If you are not that, what happens is that you

are going to lock your most trusted senior engineers in this pattern of they're doing everything except coding or building cool which means that you're going to have senior engineers hating life in a repeating cycle where you keep promising them it's going to get better when we have more people, it never gets better, does it? and the reality is, right, as a startup you've never had the bandwidth

to solve for this and this makes sense. And now that you're scaling, you definitely don't have the bandwidth. And this is something I personally felt very strongly at HelloPrint where our tech stack was already stretched beyond the reasonable limits it could handle. We had a very small team. So, when I joined, my first assignment was, "Please solve our scaling problem." Great, thanks, boss. That's a really nice

easy sort of thing to get into. Um so, imagine how it is for many other scale-ups and startups in that phase. I blatantly stole this image from uh the creators because this pattern from startup to scale-up, growing your team, growing your technology, suddenly having a scale of users, also could refer to as crossing the chasm. And it's a nice way of saying nobody knows what's going on.

You have to have to take a leap of faith cuz you just don't know the answers. And this is where immature teams are sort of forced into a pattern of having to grow, having to solve challenges they have had no hands-on experience navigating. Cuz there's no way to have that chance, right? This also comes to play with leadership where, you know, carving out time to look beyond

the the point of scale is really hard when you're head down trying to solve problems. And you know, again, a nice lovely visual also blatantly stolen off uh Tom Fishburne, so very very much I think resonates with a lot of people that work at startups or scale-ups this path of of pain, so to say. And again, same example just to drive it home, and you could call

this the the trough of sorrow, you call it the valley of death, but what it boils down to is immature leadership, immature teams often through the no fault of their own, but lacking hours in the day to solve problems in a sustainable fashion. And lastly, we come to everyone's favorite problem, architectural constraints. Now, obviously, everybody's familiar with XKCD where the entire internet lives off some person maintaining

some repo on their own uh oh god, please don't die. I like this version slightly more. I think it's a bit more extreme where you're standing at the top of the tower and screaming, "What the actual F is going on here?" And you have no idea what's going on in the rest of the stack. Feel this feels more real to me than than the other one. That

other one felt a bit too too clean and nice, I think. Bit too gentle. Um but I cuz at some point your tech is going to reach limits of scale. And the challenge is knowing where, right? And you've never had time to sit down and say, "Oh, well, if I double the amount of users, I'm going to have this database table explode." You have no Might be

the case, might be fine. Or and you don't make time for that but again, you're trying to survive, right? So, now you're scaling up, now you're going forward, and you compound these three things together, and they result in this feedback loop that just bogs you down until, you know, people get burned out, businesses die. It's called the valley of death for a reason. A death spiral in

many other scenarios. It's well talked about, so you know, it happens. And these are the three reasons why. every step forward, the problems become bigger. Now, we've touched upon the three core causes of pain, right? And I'm sure you're curious, how does Vue solve this? Like this. Awesome, right? Solved. Okay, so if you're an engineer, hiring manager, engineering manager, or anyone leading any context, you might scratch

your head and wonder, "Okay, how does this at all relate to any front-end framework, right?" These are all operational challenges. And you're right, I lied. Uh Vue won't make any of these problems It does look pretty cool though, right? I also didn't promise ease the pain. I said simplify the pain. Uh I know, I'm a cheater. Uh because as I mentioned in my thesis, I think the

Vue.js ecosystem, as we've seen again earlier now with the V, and and in general have seen over the last decade, makes the pain of scaling Because for those of you who have noticed, it's not that these three things are per se the problem you're facing. They're a problem, and compounding together they create a negative feedback loop. But there's a more insidious problem. It's called time, or a

lack thereof. I hope I've painfully demonstrated at this point where moving from a startup to a scale-up is a posing a mountain of challenges that all take away time from your engineering team, from your engineering leadership, in general time to think, look around, and find proper solutions. If you don't have time to solve the simple, easy problems, forget solving the big ones. It's a Vue solved this

for me over the last How? Let's talk about it. Let's talk about some data. Why Vue is the best front-end system. We all know this, we're here at Vue.js, right? But here's some data that that sort of had my hunch when I started using View in the first place. And the ecosystem around it when I said, "Okay, why does this feel like this smoother? Like teams are

able to create space." At Teleprint, where we started using View in 2018, we had the choice of transitioning a team. Never any work in any front-end uh frameworks, never any work with anything more modern than PrestaShop PHP back then. Um and the choice was Angular, React, or Vue. Now, we don't hate ourselves, so we discounted Angular. um we saw that Vue or React. And React was much

bigger at the time, and still is to this day, a much bigger ecosystem across the board, right? So, that would have been the easy choice. Bigger ecosystem, probably the better choice if you don't know what you're doing. We "No, what we actually care about is ease of adoption. We have a team that's unfamiliar with this. They've never done this." Everybody keeps telling us that Vue is easier.

Vue is less of a distance away from writing HTML and CSS. We wanted Vue, and boy am I glad we did. because hiring them become easier. Our complexity of features then suddenly decrease. But instead of an onboarding cycle for somebody preview, before they did their first PR in the company, of 37 days, it was two days. In a greenfield context. Okay, that's cheating. That's greenfield. That's easy,

right? Two years later, that greenfield was no longer greenfield. It had plenty of warts, including refactoring next a bunch of times. Um again, next 1.0. Uh that cycle was four days. And if you look at code churn, also shows the same picture. Just way less code churn. And if you're familiar with that term, if you're familiar with how code churn is looked at, it's sort of like,

"Hey, I've deployed something. How quickly am I changing it?" And a lower number is generally means you have a less thrown away code because you've done that code. Now, you're doing it again, right? It's waste. Let's look one step further. There's also the other part is like, okay, first PR, great stuff, you fix the typo. No. Uh time to velocity. How fast are our engineers that join

the team fully up to speed, running at full power within the context. Um before we had anything, it was 93 days. I'm glad I have these numbers, by the way. It's from 2018, so it's so validating to have this presentation say, "Hey, I have numbers from 8 years of data." It's very nice. Um greenfield, 30 days. And then uh premature was 21 days. Uh which means that

within a month, a new engineer was up and running at full speed. It's okay. I hope uh people that like working in larger corporates never have to say, "Oh, it takes 6 months to get someone up to speed." It doesn't. It really doesn't. So, even when we made really bad decisions, like using Knox 1.0 in 2018, and just clear, Knox 1.0 came out in mid-2018. Like it

was very, very new at that point in time. Um even in that scenario, this looks like a pretty reasonable set of numbers, right? And again, our senior engineers were being locked into hiring and onboarding sessions. So, reducing these onboarding times and reducing this velocity meant they weren't doing that. They were actually building cool code, helping their team, unblocking people, sharing knowledge, like so, sharing their business and

understanding of what's And you could be wondering, okay, Vue doesn't have anything to do with that, right? You could have done that with React. You had the greenfield project, of course it's easy. So, here we go to Legion of Honor Shay. They didn't use Vue. They used React. Same problem, legacy stack. Sort of at I'm a glutton for my own punishment when I join businesses that do

this. Let's refactor everything. We need to scale, we need to go international, we want to grow our team. We just did a series A for many millions of dollars. We have money. Build, build, build, build. Great, I said. Let's do it. 55 days for first PR. I said, "Oh, let's not do that." But I joined. more than 2 and 1/2 years later in 2022, the time to

first PR was 46 days. We've done a lot of work. On the outside service, I couldn't distinguish between the HelloPrint view mature state and the Legion LRF factored React state. Teams were operating well. The processes were similar. I was in charge, so you know, maybe that's me, but there's that. And these businesses were growing about 100% year over year. We were adding multiple engineers every month to

the teams. So, the difference here is pretty damn staggering. Now, I won't worry too much about the velocity here because Legionella Dash is a legal compliance platform. Getting into that context obviously takes a lot longer than e-commerce platform. So, don't worry about that. But these other numbers, they do tell a different story. Okay, you might still say that doesn't make sense. I'm sorry, this is going to

be a bit harder to read cuz I had a lot more data. But then I joined Storytek. And Storytek was already using Vue when I joined. We already were on a modern stack. And then it also got acquired by a new uh company in a in a merger. So, we also gained Angular teams that were already using Angular. Okay, so now we have greenfield Vue from 2018

to 2020, completely different 2020 2022, and then 2022 plus we have Vue and Angular side by side as an organization was converging together. So, same pattern, same process, same management team, same operational things, same product vertical. Pretty much a apples-to-apples comparison you can get without actually having the same app, right? I'll zoom in on some of the numbers 2023, this was in the middle of the merger,

so teams were still trying to figure out how to work together, how to find new patterns of employment. We had gone 5x overnight effectively as a department. So, it it that's a big shift, different cultures, different historical contexts. Vue teams consistently less time to than the Angular teams. I'm not saying the apps are easier or complex, pretty much similar. You can see a big difference already here.

And again, that difference is compounded create that time there. So, again, moving on there, 2025, what will affect this number? That number went down for Vue. The number went up for Angular. These teams have grown from 30 or so people when we first got together to over 100 engineers on these Not even the spread about 70/30 Vue versus Angular, but pretty pretty massive growth, right? And the

numbers went down. And they also had consistently lower code churn and had consistently faster Again, I was in charge, so maybe that's me. I like Vue. Maybe I didn't care about Angular and didn't give those teams resources. You could blame I me. I don't think that's true, but there's that. So, the result can be seen. On the Vue side, across multiple years of ecosystem, side-by-side comparisons of

teams working on the same vertical stack in the same organization, the same rules, compliance context, everything the same, What it means is that Vue teams or teams using Vue, and by say I I say Vue, but like it's Vue, it's not it's Pinia, it's Vit, it's all the collective context of the Vue ecosystem, to create time for the team in the start up to scale up phase.

When everything is strained, when you never know what the next step is, the simplification enabled allowed those teams to take control and create I'm very happy we have these results. And across the last 8 years, I'm so happy to say, "Ha! My hunch got proven. The data says Vue is best for teams. Amazing." Um because it solves the problem. It makes it faster, it makes it better.

I was very happy. I said to myself, "Champagne, let's party. Everybody use Vue. Go out do it. Forget everything else." So, this was supposed to be the conclusion of this talk. and then I was sitting down late last year at Storyblok, which I left in the meantime. I'm now in a new organization, so I was reflecting on, "Okay, these numbers are true, but why?" Why this is

happening with the Vue teams? Clearly it's happening. The data backs it up. Good enough for me. I can use it. I can leverage that. I can sort of start enabling that for my teams, but I'm an engineer at heart. I'm a nerd and it's bothering me. I didn't understand the underlying reasons. The truth is I still don't fully. I don't know if I will find the answer

and this is the second uh part of this this conversation where I'm sort of cheating and and and basically trying to figure out if any of you are insane enough like me to try and figure this out. Because Vue is a The ecosystem there, it doesn't make hiring faster. It doesn't remove tech debt. It doesn't teach my team new skills. It doesn't teach me new skills per

se. Like as of coding, it's just front end. So, why is that teams get these benefits with Vue but not with their closest peer frameworks? It's as if something got baked into the very fabric of Vue and I know Evan is a pretty good baker, but I don't think he did that specifically on purpose, right? so I started digging um a lot. Um and and I have

a newborn baby at home. My wife was not happy with me. Let me say this way, right? Um so I went online and started reading blogs and articles and very smart you know, how does this work? Why is this the case? And all conversations sort of conclude in the vein of, oh, it depends on your use case or oh, they're all great in different ways. Yadadadada. No

real conclusions and I hate that. Clearly the reality of my past decade is that the data is is right there. So, am I taking crazy pills or all online blogs used to slob even when AI did not have that yet trivialized? Maybe both, right? Because unless you're comparing the same exact app with the same exact team in the same exact context, there's you really can't account for

without bias. So, there's always a reason to say ah, this is this thing or this is my preference or this reason this is better, right? And last I checked, I don't know many scale-ups swimming in time for project by slightly obsessed CTO that wants to burn a bunch of weeks of engineering time just to answer a kind of useless question. So, that's exactly what I did. That's

the fun being CTO. Get to pull off some of that So, want to be very clear. Data to now, I'll stand behind. I'll put my hand in the fire of that data. I can verify that data. This it's a little bit fuzzier because again, there's biases I can't take away and I have not had the time or resources of 8 years of trying to figure out the

underlying reasons once I figured out got to be an underlying reason. So, what I found is less of an apples apples comparison once I started digging in the underlying context. It's more sort of take this with a grain of salt, please. And and and please challenge me on this. I would love to hear sort of reasons why this might not be the case and maybe I am

taking crazy pills. I don't think I So, partially to prove I'm not taking crazy pills, but also hopefully to inspire some of you to maybe think about this a little bit. I built a simple application twice in in React and Vue. I didn't do Angular because again, I don't hate myself. the experiment showed something that I was like kind of surprised by and it showed that the

Vue variant all sort of basic configuration, nothing special, V8, not 8, sadly. 22% less lines of code. That in itself doesn't say much, but it means less reading. Less stuff to scroll through, less fluff. I also then took a look at the ecosystem setup. And again, I'm very happy to have heard the talk from Evan earlier because around all the configuration files and all the setup part,

because that's what I noticed as well. On the View side, I did one thing. Just run it. On the Angular side, I had a lot more frameworks to compare, a lot more dependencies to manage, a lot more things to figure out before I got started. And it was much easier to go like I got lost in a maze. even though React size and ecosystem is massively larger

than View, when the reality of those choices comes out at a at best as an equal choice in terms of effective outcome, those choices really don't matter that much then, do they? And again, I'm not saying React doesn't have some great strengths, it definitely does. But in the context of what we're trying to achieve as a startup into a scale up and accelerating and enabling our teams

to move forward, those choices really don't make a difference, it seems. Again, as the data clearly shows. I can't rely on this. So, it's okay. Less lines of code, less complexity in the setup, less noise in the ecosystem, less management of the ecosystem, has to be the reason why teams accelerate, right? So, we I started this out. I had engineers that were new to View, I had

engineers that were familiar with View, and I had a group of engineers that lived and breathed the React and JSX syntax. And the numbers show up. Again and again, they show up. Again and again, the app comparisons are faster, easier to read, more cognitively contextualized. So, somewhere it feels that teams either adopting brand new refactoring to View or otherwise leveraging View over React or Angular in their

front-end provided other things are similar or results in a cleaner, easier to navigate, and more cognitively natural experience for teams. Which means they create they create time to solve structural problems so they can accelerate and become better and better and better at it. So, maybe should just be a little bit true. I hope so. Now, if you want to discuss my thesis or if you disagree with

my conclusions, you can find me on LinkedIn. And if you're curious what Agriplace, where I now am CTO, is doing in the future, I invite you to reach out cuz uh Agriplace currently doesn't use View. Hint, hint. Not yet. Thank you so much, Darko. That was super interesting. So much data. I think we all have a lot to use as arguments the next time we have to

pitch why to use View or Nuxt. That's so interesting. Say again? If somebody wants the slides, by all means, I'll gladly share the contact there. Awesome. Cool. Guys, we're on break now for half an hour. We'll see you back for the next round of talks. >> Mhm. >> Ooh. >> Who sees Santa Claus? Who sees Now my eyes are Show me love. You've got your hand on

the button now. >> Take me underground. Take me away. Lead me to the fire. Lead me away. Look at you I want to be with to be with you. >> It feels like I'VE GOT NOWHERE EVERY PART OF ME SAYS I GOT MY HOPES ON THE AND AGAIN, it feels like I'm going to let you you sound silly when you come But I hear it inside my

head When I realize I'm just holding on to the The feelings don't show feels LIKE I'VE GOT IT FEELS LIKE WE'RE ONLY FALLING See the moments and the decision is on me. Oh, no. Cuz I decided I tried so hard to get the sound Still it knew how CLOSE I WAS TO FALLING TO PIECES. OH, NO. MY HOPES UP AGAIN. feels like we're only falling to pieces.

EVERYBODY WANTS TO FALL IN LOVE. I'VE GOT >> MADAM, THE SHIP IS UNDER ATTACK from pirates. I've been sent to escort you to the lifeboats. Madam? Oh dear. Up on Melancholy Hill there in the plastic tree hear with me just looking out on the day on another dream where you can't get what you want, but you can't get me. So, listen I can't see. Cuz you are

my medicine When you're close to me. The cold and the suffering from the world we know. Does anybody know love? If we're looking out on the day of another dream. If you can't get what you want then come I'm on melancholy hill. The man who came Just looking out for the day when you're close to me. >> Drifting in and the road tears keep rolling down my

cheek the sages watching me and in between it's never as it seems. Help me to navigate. Help me Help me today. If you built yourself a maze, know just what to get. What comes after this? More than daring bliss, consequence of what you do to me. Find yourself in new direction. Every way from the sun. come? Would they come to reach you? Let you know you're not

the only one. Can't keep it long. What is that long? Or Oh, the ashes fall. fly. Help me to name NO. NO. NO. >> Turn the magical diminished it said everything you want to dream of it. legends every day. So what you told me. Under this pressure, under this way we are diamonds and I feel my heart beating. beneath my skin. Oh, you make me feel like

I'm alive again. Set a chemical but in this way I'm a dream and I die by light of day. Going to hold up sky and say Oh, yeah, oh, man. Oh, I can feel my heart Cuz you make me feel Alive again. Turn you magical. And you see it say everything you want to dream away. under this weight, we are diamonds taking shape. We are diamonds taking

shape. this love, this salvation this love, you get me only got this love, I want to share With you. Sing it out. >> It's always all this noise none really is louder voice Let it happen. It's going Just let it All this running around trying to cover my shadow I know it's growing inside. And all the others seem so shallow. bearing down on my shoulders us. can

hear I'm alone. Must be a warning. I heard about a wild wind that's coming around. It's going to carry off all that isn't bound. When it happens, when it happens I must be holding on. So, let it happen. I can't fight it much longer. Something's trying to get out. And it's never been closer. my take a fence make up some other story. never come back tell my

mother I was driven. You and I were asking and driven. Driven. I was thinking >> What's going on? Could this be my understanding? It's not your fault. I was being too demanding. I must admit, it's my pride that made me distant. All because I hoped that you'd be someone different. There's not much I know about you. It will always make you bend. But the answer isn't clear

to you. It's amazing what you'll find face to face. I turned away cuz I thought you were the problem. Tried to forget until I hit the bottom. But when I faced you in my blind confusion, I realized it wasn't wrong. It was a mere illusion. It really didn't make sense just to leave this unresolved. It's not hard to go the distance when you finally get involved face-to-face.

I was the sun on the shore. Give you the world if it was mine. Blow you right through my door. Feels fine. Feels like you're mine. Feels right. So fine. I'm yours. You're mine, like paradise. You rule the world if it was mine. So fine, I washed the sand off the shore. Ooh, what a life. >> I don't want to be your friend. I just want to

be your lover. No matter how it ends, no matter how it starts. Forget about your house, your car, the table. Get swept on. Tonight, tonight, the infrastructure will collapse. long tails by. Throw your keys in a bowl cuz your hearts tonight. And forget about your house and cars and I'll do and I'll do mine. Guess where? Tonight. >> in the end. this night. Where is the the

night fall in wonderland she'll cry in the dark all night make her this wonderland that is scary let it go go go go >> Like the >> Yeah, okay. Awesome. Welcome back, guys. Hope you get some coffee, some water. Everyone's energized for the next three Uh just some organizational things first. Um Stop by the Octa Auth0 booth to win some tickets for Vue.js Amsterdam 2027. Uh if

you're interested, go check it out. Huge thanks to our sponsors, to all of them you see out there on the on the floor. They're a huge part of this, and without them the conference would not have been possible. Another organizational thing you might have seen, our after-party for tonight uh is not here. We're actually going to gather at Moya Bulls, which is here, uh right next to

the building. Uh you can see we're here, and the building is right if you go outside on the left side. Uh yellow building, Moya Bulls. You can find us all there so we can have a nice evening together. Good. Our next talk is going to be super Uh German man who's traveled from Germany to all over Asia, ended up in Australia, and became really passionate about making

the web more accessible. I'm extremely excited about this talk because accessibility is something that we're kind of neglecting a little bit too much. So uh huge round of applause for Julian. All right. Yes, I want to talk about accessibility. And more specifically, I want to talk about how we can use built-in browser features more or how we should use browser built-in features um to build more accessible

web apps more easily. for that I will still dive into a few fundamentals just to get everyone on the same page, but the main point here is really to show some code examples um what you can do with modern browsers uh and what you should be avoiding. To start with, let's start with a why. Like, why does any of this even matter? It's really surprising to me

to see and hear like talking to a lot of product teams uh and engineering teams how often you hear things like uh our user base, we don't really have disabled users, so we don't really need to worry about Um sometimes even followed up with the great uh we have looked at our analytics and no one is using our app with screen readers, so we don't need to

worry about that. And it's like it's extremely frustrating on multiple levels. Um on the first like the first thing is the argument is backwards. Um it's the usual um uh survivorship bias. So, like you say, oh no one is using our app with a screen reader, maybe that's because it's unusable right now. You need to optimize it so more people can actually use it with screen readers.

But even beyond that, it just shows a very narrow view in my opinion on what accessibility is actually about. That is not working. Let's do this. Um Interesting. You might have seen this number thrown around uh a bit when talking about it's usually quoted in the sense of like why you should care about accessibility. Um an estimated 1.3 billion people in the world experience significant disabilities in

one form or another. So, that's 16% of the population that you you don't want any business with, which is crazy to start with. But, even that is not really seeing the full picture, because that 16% is just um describing people with what we would call permanent disabilities. So, that's the visually impaired, the uh hard of hearing, uh motion impairments, uh cognitive impairments like ADHD and dyslexia. Um

that's 16% of the world. And then there's two more categories that we really need to look at when we talk about accessibility, especially on the web. The second category is temporary So, that is usually tied to um injuries or medical treat procedures. And it's very similar to the permanent ones, um but it's like it says, temporary. So, it usually wears off over time. So, if you've broken

your arm, you might be slightly impaired of what you can do with a mouse. Uh if you had eye surgery, um you might have trouble actually seeing properly. If you had too many beers at the Speaker Dinner last night, um you might have like a short attention span for the day. So, I heard. So, temporary disabilities are all the effects of permanent disabilities, but they will wear

off. And then we have situational disabilities. They are usually tied to the environment. So, if I'm outside and the sun glare makes it really hard to see on my screen, see contrast properly. Or if I'm holding a baby, and like I'm in this situation for the moment, I'm impaired in my movement. And if you look at those last two categories, like these affect everyone at some point

in time. So, the whole argument of like the 16% don't really fit our user group, that should be dead when you zoom out a little bit and and uh consider the other types of disabilities and other forms of Um what I found usually helps in that conversation about accessibility, especially with stakeholders, is shifting your language a little bit. I really like this definition um from the Mozilla

documentation from the Mozilla website. Um they define accessibility as the practice of making your website usable by as many as many people as possible. And I like it because it A, it points out that it's a practice. You have to actively do it over and over again. Um it focuses on usability. And it just says as many people as possible. There's no other qualifiers. Um and that

is my tip. If if you're advocating for accessibility at your company or in whatever environment you and you're struggling to get people on that is my tip. Shift the language more to usability. It's sad that we have to do it, but I found it really helps to have those people immediately start thinking about things they usually don't associate with accessibility. Be it performance. We shouldn't just build

for the latest MacBook, the latest iPhone. Uh it could be cross-browser compa- compat- um building cross-browser compatible. Uh it could be just resilience in your application in general. Like when the user has flaky network, the old app shouldn't just crash. Um it's things like that that really showcase accessibility or usability is really for everyone. Benefits everyone. One last thing that I want to kind of explain or

mention as part of this is the concept of affordances and signifiers. in the book The Design of Everyday Things Don Norman, if you haven't read it, I highly recommend it. He basically looks at everyday objects um and analyzes like what well-designed objects what makes them well-designed. And he comes up with like five categories that make good designs, but two of them are affordances and signifiers. And he

describes it as "When affordances are taken care of um or taken advantage of, the user knows what to do just by looking." So, the idea is I see a teapot I just by its shape just by looking I kind of know how to use it. And I think we can translate that to the web to a certain extent and especially to HTML. I think we have essentially

three big categories of affordances in HTML. The first one is landmarks. So, we have HTML tags that really just describe "Where on the page am I?" And these are really useful for assistive technologies. They could be screen readers, but that could be anything else like a browser extension that uses the DOM um to let you do stuff. These technologies can use those landmarks to let the user

navigate around um more efficiently. Then we have call them elements. It's basically what we mean when we say semantic elements. Um so, those are HTML tags that actually have functionality baked into them. And this is what we're going to focus on um for the rest of the talk. And then we have ARIA attributes. sadly, this is what people often jump to immediately when they think about accessibility.

It's like, "Oh, accessibility I have to throw on a bunch of ARIA attributes onto everything." Um instead, I want you to think about it hierarchy of prioritization that you should think about. Is what I'm doing a landmark? Then you should use a landmark. Is what I'm doing has it a functionality that where there's an existing semantic HTML tag? Then use that HTML tag. Only if those two

are not true, look at ARIA tags that you can ARIA attributes that you can use to describe the behavior or functionality that you want your element to have. The reason being that ARIA attributes usually don't come with functionality functionality baked in. So, you use them to describe the behavior, but then you still have to implement that behavior yourself. To showcase that, like, the other thing often hear

and see is, like, people just do it themselves from scratch. Of like, they get the idea of accessibility, but they don't really use the proper built-in functionalities. might be an extreme example, but at the same time, I'm pretty sure most people here in the room have actually seen that It's a div with an on-click handler. So, clearly, we want it to be interactive. but we haven't heard

about a button. So, we use the div um and we have the on-click handler here. All it does is increasing the counter. On first sight, it seems to work, right? I can click on it and it does things. And maybe we even smarter and we say, like, okay, we know this won't be announced as a button by screen readers, so we add a role button, which is

good, but, like, ironically, this role is only going to be announced uh once the element is focused. And right now, you can't focus it because divs can't be focused. But we're smart and we know there's a tab index thing. So, we add a tab index. So, now I can actually tab in there. I don't know if you see it, but it's focused now. Um but I can't

actually trigger it by the keyboard. So, we know that we can add like a key down event listener. And then, in that key down event listener, we can listen for enter and space bar, and either of those should trigger the on-click event. So, now I can tab in, can enter, and it works fine. So, now our project manager, because this button has a project manager, comes and

says, "We need to be able to disable the button in certain situations." Um so, we can't use the disabled attribute because a div doesn't have disabled. But we know aria-disabled is a But like I said, aria-disabled doesn't actually have the functionality baked in. It just tells assistive technology that it is disabled. I can still trigger it. So, now we have to actually go into our handle click

and check if it's disabled. The other thing in the spec is it says when the button is disabled I shouldn't be able to focus it. So, now we have to store the disabled state in a ref and then based on that we set the tab index I could go on and on here. I hope you get the gist of it. We could avoid all of this by

just using the button element. Like this has all of it and then some implemented built-in um and we don't have to worry about it. And baseline widely available since 1997. How great is that? It's older than some people in the room. Just thought. So, the key is again, this might look like an extreme example, but it's like don't reinvent the wheel. If there's built-in functionality that gives

you a lot of the access- accessibility for free, use that and then still build on top of that, but use that as your basis. All right. Let's look at some examples of more modern HTML and CSS that I think um not everyone here might have seen or even if you're seeing it you might not be using it and you might not know all the benefits that they

come with. Um this is my personal selection of what I could fit into 25 minutes. There's plenty more. I highly recommend everyone just checking out MDN docs and and following these things, but these are my personal favorites. probably the most abundant pattern on the web. It's dialogues. And usually when we have dialogues we have them in a modal form, which means whenever the dialog is opened we

want to disable everything in the background. The user shouldn't be able to interact with things in the background. we've had the dialog element for a while So, the dialog element itself allows us to render dialogues and open dialogues without any JavaScript at Um and what you might not be so familiar with is these command and command for attributes on the button. All these do is specify predefined

commands that are available in HTML. So, one of them is show modal. Um and the command for is just a pointer to an ID of the modal that we want to open. This dialog ID in this case. And again, without any JavaScript, we get the base functionality of a functional dialogue for free. And again, it comes with access to accessibility built in. So, it's keyboard accessible. Um

I could close it with escape now. Um when I close it with my keyboard, like if it traps the focus. This is usually like if we build our own dialogue component in like view, you would have to pull in a library, a JavaScript library that traps the focus in the element. And then you have to deal with that. it automatically does that for you. If I close

the dialogue, it automatically resets the focus to the element that was focused last before I entered the dialogue. Which is like the standard go-to, like you should have that for screen readers and stuff. But even for just a power user that uses the keyboard a lot, it's extremely frustrating if you have if your focus gets reset to the top or or to a random spot every time

you close a dialogue. baked in and you don't have to worry about it. You don't even have to know that that's the standard. and it's fully customizable. This is usually the argument against these things. It's like people say, "Ah, I I can't do like the custom styling or like the animations that I want." That's not really true anymore. So, the dialogue itself is fully customizable. You can

style the dialogue via CSS, as you can style the backdrop via CSS. So, in this case, we set it to Um we could set it to green. It's I have full control over this spectrum. Um and we can also animate things in and out now. So, this is more recent. Um I think yeah, 2024. Um we got the starting style at rules. And that in combination with

transitions that allow discrete Um if you haven't seen this before, definitely check it out. Um it allows us animate from display hidden to display visible and even just elements animating in and out of the DOM, which we couldn't really do before. We always had to like escape to JavaScript animations and stuff. And just with these few lines, um it's a little bit redundant here, but basically what

we're describing is the initial state when it's hidden uh it's a bit scaled down, opacity zero, and then we scale it in and we fade it in. Um and it just works in and out. And again, this is all without any JavaScript. The next one is fairly similar. Um it's again a very popular pattern. So, the popover is like a dialogue in the sense that it pops

up with content on top of existing like the um existing content on the page, but it doesn't block the page. Like ideally, you can still interact with everything around it. Um and for that, we have the popover, which is not a tag, not like the dialogue, but you can put the popover prop uh or attribute on any element. So, in this case, we use a div. This

is a container for the popover. And then on the button, we have a popover target attribute, which again just points to an ID, and that tells the browser, "Okay, when the button is clicked, do this action, open the popover." Um and and when you do that, it works, but it's a bit odd because by default, it does the same as the dialogue where it just opens in

the middle of the screen. Um and a popover, we we usually want to position relative to the thing that triggered it. So, to do that, we can use um CSS anchors. Um anchor positioning basically allows us to define an element as an anchor um and then use that anchor to position any other element relative to. And this is again something where we used to have to pull

in like heavy JavaScript libraries like Popper.js or or whatever you use. Um this now comes built in out of the box. And what it does is like it says it's positioning it relative to the And it deals with all the concerns um collision avoidance and detecting like where where's the edge of the document, etc. for you. So, if if I set that to right center, um it's

supposed to position it to the right, but it sees that it would go out of screen, so it automatically pushes it in. And you have control via CSS over the fallback behaviors and what it should do when it doesn't fit into the Um so, it's extremely powerful, um and it's finally baseline available uh newly available this year. I think Firefox um finally shipped it in January. I

could be wrong on that. Um but it's definitely like worth keeping an eye on and worth starting to adopt because it's now in all major browsers. Um once we have popovers, the next logical thing is to think about tooltips because they're very similar. Like you want to interact with something and then you want to show like a little bit of content when you interact with the interaction

is different there. Popovers we usually want to click. With tooltips, um it's more a hover or focus kind of interaction. And uh we have that ability to now. So, instead of popover target, this is experimental. Um so, this is only Chrome, I think, Chrome and Chromium at the moment. Um but the idea is for an interest API that tells the browser that the trigger should actually be

a hover or focus. So, without clicking, you just have to trust me on that. I didn't click. Um I hover over it and it appears and I can just focus in it as well and it appears as well. Um again, this is experimental, so the API might still change. but the idea is that again, you can control a lot of the behavior via CSS. So, you can

control the delay, um for example, that you want the um the tooltip to have. So, it takes a long time or short time or whatever. Um again, I would always start with a built-in defaults, um but if you want to adjust the behavior, you can. All right. Next one, accordions. This one is actually like we've had the details tag for a while now. I don't know if

you can see a show of hands. How many people know about the details tag? That's good. I like that. Okay, a lot of people. Uh it's been around for a while. It basically doesn't really do that accordion. So, you can define like a summary that you always want to show and if you click on the summary, it toggles and shows the collapsed content. And in that content,

you can have anything you want, any HTML. So, it could have tables, it could have whatever. that's already great in itself. It takes care of accessibility, it takes care of state management for you, all of that stuff. Um people used to not really like it for styling reasons. I'll go into that in a second. But one thing that I don't think is talked about enough is discoverability.

So, one thing that it comes built in with is I can search the with just command F and I can go lorem and it will automatically reveal any matches that it finds in accordions, in the accordion details. And that's powerful. Like if you're building um a documentation page and you're using a lot of accordions in your documentation and you don't use the discoverable um accordions, I had

I hold you personally accountable. Like you are the devil. Like this is this is super easy to do. And again, like by CSS, it's super Uh the the whole arrow thing, you can just remove that and use your own image. You can style whatever you want. You have all the style states, whether it's open or not via pseudo selectors. definitely look into that if you're not already

using it. The other thing why people used to not use it so much in the past is because of a pattern that was or that is very common where you have multiple accordions and you only want to show one at a time. And that actually in 2024. Um where we can now use a name attribute on the accordions. If it's the same name, it will basically close

any other accordions when you open them. So again, the functionality kind of caught up with people's common use cases. And the other thing is you can still build on top of that. I'm not saying don't use any JavaScript at all. This is a JavaScript conference. But like start with the base build blocks that you get out of the box. They are accessible and then you can still

add custom behaviors on top. I'm going to rush through the the next couple of ones. Um these are more but this is this is a big one for me. I'm super excited about this. Like selects have been a pain for me for the last 15 years. Um every product that I've built, the designer comes to you and say like, "Ah, this select it looks ugly. Can you

style it and make it different and whatever?" And just using HTML, this is what we had before. It's like just the operating system default selects. Um they work. Um I personally don't mind them too much, but they're they're not pretty. And whenever we try to do something um, adding more complex stuff to the options of like, "Oh, we want to have an icon there." or even a

subtitle or whatever, we can't do it because by default selects don't or options don't allow, um, HTML in them. They will just try to find like the closest inner text. So, in this case it will still find like that I have text here. Um, but it it will ignore everything This is finally changing. And I know we've had promises before, uh, many over the years. And we've

been always disappointed, but this time it it looks like it's it's really going to happen. So, again, it's experimental. It's in Chrome, Chromium. Um, they're experimenting with a new appearance property, um, on your selects. So, you have select appearance base select, and you also have the new pseudo, um, selector for picker, which is cross like the pop up that comes out of the select. And when you

set them to base select, it basically resets all the browser styles and it allows you to have, um, HTML in your options. So, the beauty of this is that it's backwards So, your old browsers that don't support this will still fall back because you're still using a select. But new browsers who who do understand the base select appearance, um, will allow you to render images and and

other stuff. Like you you're you're full control over the HTML within your and everything again is styleable via CSS. I kept the system check because why not? But you could customize that if you wanted to. Um, and we can go even further. We can customize the trigger of the select, like the button element here. Um, basically just by if the first element within your select, like the

first child of your select is a button, it will render that instead of the default button. Um again, older browsers will just ignore it because it's not an option and only options are allowed in the new appearance, it will actually render this button. And we have this new element called selected content, which will just pull the inner HTML of the currently selected option. Um which is cool

because it means we can actually use the icons or whatever. And we can do cool stuff like we can style it via CSS. So, like because it's an element, we can literally just go hide the image. Um and we can we can do our own behaviors here. Like we're in full control over what we want to show and how we want to show it. The next one,

uh is going to be experimental, but I am excited about it because it's it's another pattern that you see all over the web. It's carousels. So, let's imagine we have this movie carousel Um right now it's just a scrollable div. You might see the scroll bar at the Um and I want to improve it. And what we had for a while is scroll snapping. So, I can

already improve it by just say like, okay, always snap to the middle. So, if I scroll, I can still scroll fast, but like it will always snap it to the center. But what I really want is the controls, right? If I build a If I would build a carousel, I would build buttons for left and right, for example. So, Chrome is experimenting with these pseudo elements of

scroll buttons, where you can pass in the direction as an argument, and then we can define a scroll button for left and scroll button for right, and we can style them however we want. So, these are purely defined in CSS. I have no JavaScript here. Um but they A come immediately accessible out of the box. I can again uh tap into them. and you might have noticed

this button is disabled right now. So, it automatically deals with state management for you where it's like if it's scrolled all the way, it automatically disables the button. If I start scrolling, um, it enables it everything for you just out of the box. But, I also want an indicator where you're currently at in your carousel. So, there's a new, again, experimental, this may change, scroll marker group,

um, where if I activate that and I set it to after, it will render in the DOM an actual group that I can style via the scroll marker group pseudo element. So, that's the group of all the markers here. And then, slightly counterintuitive, maybe, the markers themselves are on the individual items in your carousel. Um, but then, for each of those, you can style your marker how

you want. You have access to like whether it's the current active marker or not. And then, you get all of this just with a little bit of CSS for free. Um, again, fully accessible if we tap into it. I can use my arrow keys to navigate around, all that kind of stuff. So, again, warning, this is still experimental, but like seeing all those experimental things, especially the

select stuff, um, makes me really hopeful for cool stuff that we're going to get in the near future. All right. I'm not going to have time for this, but I'm just going to gloss over it. This is mostly HTML that we're going to that we looked at. Uh, CSS has a bunch of other stuff that's definitely worth checking out if you if you're not fully aware yet.

Media queries are really good, um, tool for for building accessible stuff. You might be aware of prefers-reduced-motion, um, for people that get motion sickness very quickly, you can disable or you should disable animations, um, where you can. There's other media queries that are really useful. Prefers-contrast allows you to build multiple versions of your app with higher or lower contrast. Um, prefers-reduced-data, if you're on a mobile plan

and you're like, "I don't want your 4K images or videos downloaded." Um, you can actually listen to that user preference and say like, "Okay, I'm I'm serving this the smaller image." Or or stuff like that. JavaScript itself has heaps of great web APIs and when you see a web API that's that's shipped across multiple browsers, you know that there's a team behind it um that thought about

accessibility. And a lot of these APIs also come with OS level UIs. So, not only do they give you accessible UIs for free, but they give you UIs your users are already familiar with. The navigator share um API, um, not many people know about it. It's amazing. It basically gives you the native share pop-out, um, say on your phone or or whatever. Um, so the user can

share with whatever apps they actually have installed. Um, contact select, um, pops up the native contact picker, um, on your phone. So, if you have like a CRM, th- it's an amazing nice little feature that no effort on your side, you're just using a native API and the built-in browser functionality just does the job. Um, I realized yesterday that it feels like you have to mention AI

in these talks. Um, so I'm going to finish on my thoughts on AI and what it means for the future of accessibility. One of the things you have to think about with that is the landscape of testing your accessibility. And that there's too much to talk about there, like I could do a whole talk on that itself. Um, but one of the things that you need to

be aware of is when it comes to testing your accessibility and testing how accessible your website is, um, there's studies out there that show that you can only really catch um, 30 to 40% with automated tools. That means like roughly 70% of issues you won't catch with those automated tools. It needs manual testing just because accessibility is so nuanced and so it's so tied to the actual

visual keeping that in mind I think that's one of the huge potentials when it comes to AI actually helping us a streamline the automated testing that we can do but also extend it further than we can currently do with things like XPaths and plugins and and stuff like that. So seeing what we can do with the automated testing especially in an era where we start hooking up

our agents to live browsers and let them do stuff in the browser giving them access to the protocol directly allows them to do a lot of the stuff that you can do through the dev tools of like color contrast checking and and and other things. Give your your your agents access to that. I think there's there's huge potential in that. Um other things are like what people

often say like automated generation of captions or like all texts for um for your images or actual captions for your videos. I do think there's potential there. I do also think there's a risk because wrong captions are worse than no captions. So be careful with that. Um but what I would definitely say is it's going to have a huge impact because the more code we generate with

AI important it becomes that we teach it best practices. And if we do that then there's a huge potential of like okay cool we have a good basis the LLMs are well trained the code that we're generating is actually going to be good. Um and for me that's the huge risk because I don't think we're there yet. I think what's currently being fed into LLMs is not

very accessible and that leads to the huge amount of code that we're currently generating being subpar uh to our standards today. The other huge risk that I see is once you have AI tools that promise you companies, especially big companies, will just take that as their check mark and say like, "Okay, that's accessibility done for us." And potentially even get rid or not even hire accessibility experts.

And again, for me, that's that's the danger in general with AI is people misunderstanding um and I think Evan said that in the panel yesterday very well. It's like you still need the expert to steer the AI to do the things right. Um so, I think we all need to be aware of it. And LLMs have biases. That's just a fact. Humans have biases as well, so

it's not inherently a dismissing feature, but it's We just need to be aware of it. We can't treat it as a Oh, the LLM is so smart, it's going to do everything right. No, the LLM has been trained on stuff. That stuff is likely very biased. In this context, ironically, towards the like because the web is not um per se as it is, it's biased against what

we're trying to build here. And this is what I want to kind of leave you with um a little bit of a challenge. Um Think I think the web is fundamentally broken right now. And I think it came to the point where we started accepting that to a certain certain extent. but I don't think we should. And I think we're right now at that cusp where with

AI, if we don't fix it, it will only get worse. So, the challenge that I have for you is the next time that you browse the web, take a piece of paper and take a pen, and every time you see something broken or that feels broken, make a note of it. So, every time you try to tap into like a button and you can't, make a note

of it. Every time you can, but you can't see it because the designer thought that the outline of the focus ring is ugly, so they removed it. Make a note of it. Every time you command click on a link to open it in a new tab, and it doesn't open in a new tab cuz the developers use JavaScript instead of just a an anchor link. I think

you will realize that we're just accepting the broken state of the web as it is. I think the first step out of that is realization. and I think the next step then is to realize that we all as people who are working on the web have a responsibility. I'm not saying you alone should fix the web, but I think if we all start being aware of it

more, and we all start doing our bit piece by piece that we can every day, we will start improving the web slowly over time, and we still we will get to a point um where we hopefully get the web to a standard that AI can take and keep making better. That's it for me. There's a QR code to the slides um with the code examples. Um my

socials that I'm not very active Um and yeah, that's that's it for me. Thank you so much, Julian. Julian, I have a question for you. Okay. Out of all these amazing new features, I mean, the carousel, I don't know how many times I've built a carousel, and I guess you guys too. How much of that is available in Safari? Uh right now, none. Ah. Um but for

example, with this select, I am very hopeful because it it made they made really good progress. They actually work together with groups, so it's not completely just Chrome in isolation. Uh and it's built in such a way that you can see a future for that, so >> Okay. I mean, yeah, Apple is um Safari is the new Internet Explorer. I think we can all agree on that.

Um eventually we'll get there. Thank you so much. It was really interesting to see all of that. Again, curious. How many of you have built accessible websites until now or really put focus on that? That's awesome. Honestly, I should do that, too. Okay. Awesome. Um let me introduce the next speaker. So, uh Alex is has an extremely exciting talk, uh just like all of these, um talking

about how to work locally, how to make sure that we don't have to rely on servers all the time. And uh I'm super curious because it's another thing I should be doing more. And uh without further ado, huge round of applause for Alex. So, hello everyone. I hope you had a good time so far. And now we will talk about something completely different because to be honest,

I'm really bad at CSS and I learned so many new things. I want to introduce you to a new way how we can build applications. And also I introduce you to a completely new community. And I think it's always worth if you give a talk that you think what what what is your goal of the talk? And I know that after these 30 minutes, you won't be

an expert in all the things that I will mention. But my goal is to bring the Vue community together with the LocalFirst community. And also, I always wanted to see this meme in a huge screen. um but but yeah, imagine one of the guys Vue and the other one is the LocalFirst guy. And before we dive deeper into this topic, just a quick introduction from my So,

my name is Alexander Paley, or just I've been now working with Vue for over more than 8 years, and I always try to find a job where they use Vue. And I work at Auto Payments, a company Germany. I live in Bavaria, and I also write blog posts. So, I started 2 or 3 years ago and was writing many blog posts about Vue. Now, also more about

AI coding or LocalFirst. Now, please raise your hand if you ever built an app that works offline. Okay, some of you. Then, also keep it up if you ever heard of LocalFirst before before this talk. And now, last question, does anyone of you has ever built a LocalFirst application? Okay, a bit less than the offline-first part. So, one of my goals is also to explain what the

difference is between offline-first, which is really old, and LocalFirst, which is a bit newer. And the way we will do it is first, I will explain the status quo. And then, we will see how we can convert any Vue application into an offline-first application. Then we dive deeper into sync engines. And after we did understand what offline first is and sync engines, we then talk about local

first. And also the the main idea with local first is it is not only about technology, but also about values. And we also build a simple application and we use an interesting library that helps us that is called Jess. So, what is the status quo? I think most of the applications that we build are always for this three-tier where we have the front end, uh we have

the back end, and we also have the And yeah, but one thing which is really annoying is you always have validation both on the front end and the back end part. And the single source of truth is also always the database. And yeah, this is a bit annoying. So, that's why I like this quote that we are kind of in the jQuery area of data. And what

does this mean? So, before we had view, React, and so on, we used jQuery and we had to write so much code that the DOM is automatically synced. Now, with view, you just update a ref and everything just works. You don't really care how the real DOM gets updated. But what what is with the data layer? But where is the sync engine that also helps us that

we don't have to write so much code always on the back end to do things? Now, you maybe also ask yourself that you already use TanStack Query or Pinia or Pinia Colada. So, with TanStack Query, it's the idea is a bit that we cheat a little bit. So, we we cache data. We also do something optimistic mutations that the application feels faster for the user, but it

still doesn't work without the network. And yeah, with Pinia, we use Pinia for global UI state. But it would be nicer if there would be some magic way where you just update one reactive value and out of the box it will sync all the data both locally and also on the server. That's why on my talk we always look these seven ideals and we always come back

later and then we see how we can achieve each of these ideals. The first one which is important is the app needs to feel fast. And this also means if you have the perfect view code, it doesn't matter so much if the back-end API still is slow. A user sees the spinning loading screen and then he's annoyed. Also, it should be easy that it works on multiple

devices. Works offline is important, especially if you live in Germany. You never know that where you get internet or not. So, it would be nice if I work on something that I can also do something without the internet. Collaboration, so something like Miro would be nice if this works out of the And also interesting, imagine you have a gym tracking app or to-do app and you use

it for 5 years and then yeah, the company doesn't make any money anymore and they decide, yeah, we we stop. Um it would be nice if you're still able to use the application because this is your data. And privacy. Ideally, all the data on the server should be encrypted. Um and you only know how the data looks. And it should also be easy to adjust your data.

I think Obsidian is a good example where it's just markdown files and can you can do whatever you want with that. So, these are the seven principles and I think most of the view applications maybe they score something out of that, but it's really hard to achieve because you have to write so much custom code yourself. And yeah, these seven ideals are from the local-first paper by

Ink & Switch where the name was first introduced. And the idea is a little bit that if you achieve all of these values, then you have a local-first application. And also from the paper, here you see how most applications score and you also see that most of them they don't don't score every thing. Now, how can we convert a view app that it works offline? Of course,

we need a database. So, when you use the server, if you're a backend developer, you maybe use SQLite or Postgres. What can we use on the browser? Maybe session storage, but this won't persist. Also local storage, not ideal for a huge amount of data. Cookies also not. The first interesting idea is IndexedDB, where we can store much more data. Depends on the total storage of your device.

And also more fancier is that you can use even use SQLite in the browser. And the way how this works is that we use WebAssembly. And with WebAssembly, we can even run Rust code in the And you can also even use PHP Lite, so Postgres in the browser. And when you use offline-first or local-first libraries, you see that they always use one of these approaches. And since

I only have 30 minutes for my talk, if you want to dive deeper how SQLite works, there was a really good talk about the SyncOnf last year the TLDR was basically that SQLite works really good in the browser. Now, how would this look? So, when when you're online, the thing which you are doing now differently is you don't make an API request directly to the back end.

You save it to IndexedDB or SQLite. And then when the device is offline, then you kind of save a transaction and into IndexedDB. And then under the hood with a bit of magic, um this data will be then synced. Now, there's one problem if you open any website, even if you use IndexedDB, you still see the famous Chrome dino because it cannot load the JavaScript and HTML

part. That's why with the help of progressive web apps, we can use the web, which is the platform that is really free, to also build apps that can work And if you want to convert your view application to a progressive web app, I wrote a blog post about that. This is part of a series where I wrote many blog posts about the whole whole topic, also how

you can use SQLite in the browser, which was really really Then, uh in summary, we need two things. We need something like IndexedDB or SQLite and a progressive web app, and then our app can work offline. So, when we come back to our scorecard, now we have fast apps that work offline, but still some things are missing. Now, what is the biggest problem? The biggest problem is

how do you even sync data? So, imagine you have a to-do app, cuz everyone loves to-do apps, and you have two devices. now they are all offline. On the one device, you change the title, and then you change it again. And now both devices should come online and now you have a problem. What is the real state of the title? And this is a distributed system And

it needs a sync engine. So what what is a sync engine? So again here we have the free tier And on a sync engine the idea is that most business logic happens on the client and the responsibility for the sync server which maybe is using web sockets syncs the local DB IndexDB maybe to all these devices. And also some work to the cloud to a And with

this approach you can also write less code. Now the biggest problem and now we also go to the most complex thing if you dive deeper into the local first word is how do you resolve conflicts? This why there is something called conflict-free data types which maybe sounds a bit strange but uh simple idea is that it's a kind of a git for JSON. So imagine and this

is also the example how just works. We have a header here and we also have a history of all the things that has happened and we have a state. Our state is a bit like a computer. And again we have a to-do application. So on one device Alice adds a new title. Yes, she wants to buy milk and set it to false. You also see that the

state is buy milk and false because we only have one transaction in the history. Then Bob on another device is changing the title. Now the reason why the title has changed is that we use last right wins approach. So, we use a timestamp and everything has happened before will override if you have the same Then we do it again. And then the last time we set the

to-do to true. So, with this we have data structure and we don't need a server who decides how the merge conflict should be resolved because it's always part of the data itself. That's why I also use the name conflict-free data type. And this is one simpler approach, but there are also more complex ways, especially for text. So, if if you use something like Google Docs, you can't

just use the last right wins approach because you have a multi-collaboration, you would always override things. But the idea is always the same. Now, it's also a spectrum. So, last right wins is probably the easiest one. Then CRDTs with text is more complex. And as always for good UX/UI, you also want to give the user the to decide how the override should And one question is also

where do you want to handle conflicts? So, you can have a server and the server is then always kind of deciding how the real state should be. But for local first, what is more interesting is that the clients itself can do that with the help of CRDTs. Because then with peer-to-peer, also the clients with maybe Bluetooth, they can sync states between each other. And when you come

back to our scorecard with sync engines, we now get collaboration Now, sync engines, I think they're they're starting to really get more and more popular, especially if you build an application and it really needs to feel fast, then something like linear started and in 6 months they created their own sync engine. So, they use IndexedDB and every time you do something in linear, which is a issue

tracker tool, you get fast feedback back. Also for Figma, where multi- collaboration is important, they also use a And also Notion since last year is also that it can be used offline, they also use a sync engine under the hood. Now, but my my question would be are these apps really local-first? Now, let's talk about local-first. So, local-first is more than it just should work offline. It's

a bit more about This why Martin Kleppmann from co-author of the original local-first paper has defined three interesting criterias. The first one is that the app should Also, multi-collaboration should work. And the hardest part is that if you use something like Notion and Notion decides that they want to do something different, you should still be able to use the data that you have in Notion. So, this

is why this is hard to manage. Um there are ideas, so you could say um their sync server is open source and you can just host it yourself, then you would be still able to use Notion, but they they need to do So, offline-first, there the server is the owner, but on a local-first the user is the owner. So, we want to give the user even more

power and control over his own data. Now, let's go to the practical part. How can we build local first applications? So, there are many different libraries. I was also giving a talk about how we can use Dexie JS for that, um but also 2 weeks ago I got deeper into Jazz and what I like about Jazz that is solving many problems for us. So, they have a

sync engine. They also encrypt the data for you. They also handle permission. So, you get many things out of the box. And they have different bindings. They JavaScript vanilla binding, but you can also use it with React and also they binding for view. So, I was not brave enough that I will share if you scan the QR code what you write in the chat, but this is

what we are now trying to build that we have one chat application that works offline and you can type something there, send the images, and so on, and everything is built with Jazz and with view, and there's no server involved. Uh if you want to try it out, you can write something. Uh and yeah, be be nice. So, Jazz they they use conflict-free data types, but they

don't like the name. I also don't like the name, so they just call it co-maps. But but the idea is the same. And what do we need for a chat? We need a co-map for the chat object itself, and then we also need a list. And with these two CRDTs, we are able to build our own chat application. Now, what Jazz is also doing is that the

first time you load the app, you and there may be 30 messages already. We also need to save the messages to the index DB. That's why there's a loading state. But once you have loaded everything on your app, then there will be no loading spinner anymore. And that's why you'll see later in the code that we always have to check the loading state first before we can

display any message. Now, how how do you use Jess? So, if you use use Knox content or drizzle, you always start with the schema. So, you describe how your data structure should look. And then you can import the core values and Z is from Zod. Zod Jess itself is using Zod under the hood. And we define how our core value should look, and for us it's just

a simple text, and the type is string. Then we export that, and then we also import the list core value. And there maybe you see the first interesting part is here. So, Jess also has a permission system out of the box. So, when you create a new chat, the user itself is the admin, but you also have to define how other people can use it. In our

case, everyone has right requests. So, there is no outgoing on And then we export everything. We can also export the type. Maybe you want to display that without a loading state in our view components. And then we have our route app. And then again we import something from Jess. So, the first interesting thing is that we import this here. So, with Jess you can either use their

cloud and create an API key or you can also self-host the sync So, the sync engine itself is using web sockets and there's not so much business logic there. So, the most business logic is always in these CRTs and then the client itself. That's why the sync server is not so complex. we have the route component and then every child has access to all the just stuff.

So, under the hood it's using provide and inject. And for our chat, we don't have you don't need to authorize. It's everyone can can use it, but just also gives you nice ways to use something like passkeys or to use your Google account to create a new account. And then on our main TS file, yeah, we just import the component and mount it. Then here on this

example, I used the file structure from view router. So, we have the index page. So, the idea is the first time you load the application, we will generate a new chat and we will change the URL. And once the chat has the URL, then if you share this link, then you can also collaborate. So, that's why you could also on the um remove the last part and

then you would get a new ID in the URL and then you can share that. Then um yeah, most of the time I I'm a fan if the business logic is too complex that I use composables and put all the main business logic in there and then the component itself can be a bit stupid. So, that's why we have our use chat composable. Yeah, so here it's

just normal declaration how our composable should look. It needs to get the chat ID. And then the first interesting part is this use co-state. So, to explain it really simple, the idea is we have a kind of ref, but it's not only changing the DOM. Under the hood is also saving data into IndexDB. It's syncing the data with the web socket to a database and is also

encrypting that. And yeah, this is what you all get with these few lines of code. And then we also want to know our current user, so we can change our profile name profile name maybe. And yeah, we always only want to show the last uh 30 messages. So, that's why we have a computed. And here is the where all the magic is happening. Here, if you do

dollar just push, this will trigger under the hood all the sync engine part and then just is doing all the things that you normally would to do yourself with writing much code on the back end And yeah, we export this function then. And then we got here everything. And then if we see we don't have so much code with our composable and under the hood is doing

really many many things. And I also like this approach because there as a developer, if you want to create new applications, you have to write less code. And this is also one advantage of this offline first local first thinking beside of the the awesome Now, we have another component. So, here with the view router approach, we get the ID from the URL. And then we import our

composable. And yeah, we just get all the functions and the refs and the computed. And then what we have first need to do is, as I said, we need to check for the loading state. So, the first time you it could be that it would take a little bit of time before all the data is in we have loaded loaded everything, we can just display the data

with normal view code. And yeah, we need also input and when yeah, when you type something, then you press send, and then the whole syncing under the hood on the composable will be triggered. Yeah, and this this was everything. So, with these few lines of code on the composable, we get so many things out of the box, which would take much more time if you write that

yourself. So, if you think if you can't use something like Chess and you need to create a simple chat that works offline, has collaboration, uh also I didn't was not showing you that, but you can also even upload images and Chess will do everything for you, also the that it works offline. And this this what I like about libraries like Chess that I don't have to write

so much code. The only complex part is I need to understand how the code states works, how CRDTs works. But once you play with that, you write your own applications, you can also develop much much faster. That's what I also like. So, if you like local first and you're interested in that, there there is really a huge community. There are so much more interesting libraries. So, I

I would recommend maybe start to write your own gym tracking app and use something like Jazz or Dexie and make it a progressive web app. Also, I think it's always a good idea that a user is able to download its own data and also upload it. So, if you have a to-do app, note app, user should be able to get his data And yeah, also also watch

the the space. See what is happening there. Um because also to be honest, the whole local first thing is new and there's so many new libraries out there and not everything is really 100% ready for for enterprise. So, as a summary for my talk, I I I I also don't know how far we will come with the local first approach, how many applications will be built, but

it's clear that syncing definitely will start to be more mainstream, especially if you want to build applications that are fast. But also, local first is not the best approach for I think especially if the for user sensitive applications, there I think local first makes sense and you also have a selling point, but for banking apps, e-commerce websites, and also where it's important that you have a server,

there it it doesn't make so much sense. And if I also created one, so I need some stars for a GitHub project. So, I created a awesome local first GitHub with all the resources. You can check that out. Um there are also all the papers linked, different libraries. So, I think it will save you a bit of time if you start with your local first journey. And

also this year the Local First Conference in Berlin will happen the third time. So I was there last year and it was really fun. I will be there again. And there were so many interesting talks and so many interesting ideas. And yeah, thank you all. I hope it was interesting. And yeah, if you have any questions, any feedback after that, just come to me and talk. Yes,

now we're all going to build offline first applications so we can make sure that the things actually work and the data is local. Are you going to be speaking at Local First Conf in Berlin? Maybe, I don't know. I I applied but We'll see. Can you give us a teaser about what you're going to talk about if you get there? Yeah, one interesting topic is also Transformer

JS. So with Transformer JS you can run AI models locally in the browser and do fancy things like removing images or doing a summary. This would be one topic I want to talk about. Looking forward to that. >> Yeah. Guys, there has been a little organizational change. The next talk will not be the quiz. It will be Tim who will be talking about his journey of migrating

Need for Speed's website from vanilla JS to Vue JS and everything I learned along the way. I just want to also mention again that if you want to win tickets to Vue JS Amsterdam 2027, stop by Okta or Auth well, Okta's booth on the floor talk to them. That probably would be a really cool thing to do. Right. Our next talk, as I mentioned, is Tim. Please

big round of applause and have >> All righty then. So, I was actually supposed to be the final speaker for tonight. So, a lot of my slides are all about beer time and parties and I'll keep it short for you. However, I have a new timer here. We can go into And so, this talk is about everything's becoming a one-liner and I know you're thinking, "Oh, it's

all about AI." No, that comes a little bit later in the And so, uh my name is Tim Benniks and I work at Contentstack, which is basically a platform that started as a CMS, but it has a whole bunch of other um for hosting, automation, things like that. And so, there I lead developer experience and I'm also an ambassador for Nuxt and Algolia and Superbase and Cloudinary

and I think this is the eighth time I'm speaking here. So, I want to really thank um the organization for letting me do that. This is really really good stuff. Um this is one of the best ones. Like, you saw all the cool things that were like announced today. That's just This is the place to be for us. And so, um my accent might sound a little

strange. To the Dutchies in the audience, you'll know I'm Dutch. You can hear it, right? But, I live in France and I work with people in India and with people in the US. And so, that's when you get this really weird mix. But, actually if you go across the water, that's where I was born. So, I'm really happy to do a talk, you know, in my hometown,

essentially. And so, let's tell a bit of a story. And so, this talk was really meant to be like the last talk, so we're not going to go super deep in code. It's like just let's talk about our history, where we started, right? Because in 2013, it was really the golden age for ad agencies. And so, I worked here in Amsterdam um at AKQA. the golden age

of ad agencies literally means you have all these customers, they throw money in your face and say build me 15 amazing things, we'll pick one, and if it works, we're happy. That's how things like Nike Plus came to me. Like those kind of things we could really innovate and try. And so, the really the money was flowing and like all the things they asked of us were

like it was literally outrageous. And so, we didn't really have that much in terms of frameworks. I know Vue.js kind of started in 2013, maybe, but I didn't know about it. Well, we had one thing, which was essentially this one that we all know and love. And honestly, this changed the game for us. Because before that, I had to do DOM manipulation in five different browsers in

five different ways. So, we did have some help, but we didn't have, you know, what is a single-page app? Or how do we route something? Or how do we do like also isomorphic stuff? That was actually we needed stuff like that back then. And so, today I want to talk about Need for Speed: Rivals, which is a game that came out on the PS3, I think, in

2013. And we had to make the advertising campaign for this project. And so, it had to be a single-page app, but we didn't have the word for that. We just had to build something and make it feel good, but we were not allowed to use Flash. Because if I had that, it would have been amazing. Some of the younger people here might not even know what it

is anymore. But yes, I was pretty happy not to use it, but then we had to invent a bunch of stuff. And so, Need for Speed: Rivals is this game where you're essentially um you're a cop and you have to, you know, make sure people follow the law, but you can follow the law by being nice with the rules or you can just destroy the cars on

the road. And of course, we know what we're all doing, right? And so, um remember this, by the way. Oh, I don't have audio. Okay, we need to fix this though. Cuz that would have been nice. Can we try again because maybe it was quite low. EA Games Yes. When I was making this talk and I found this, I'm like, "Oh, my youth came back to me."

There was just so much fun and you also have like it's the in the it's in the game one, but this was not a FIFA game. We also did those websites, but I couldn't find that source code anymore. Anyways, so let's do a little quiz time. I'm going to go and click on this link because I found the code for Need for Speed: Rivals in an old

Dropbox folder. And I thought, if I remove Sitecore and all the enterprise stuff and all the languages, I can probably rebuild this front end just in the old way and put it on for sale. And you know, that actually worked. So, I'm going to click this and we go through the experience and think about at that time it was inside the Need for Speed website. And the

quiz is, you're all developers here. You know exactly how to build things and when you see something, you're like, "Oh, how would I build this?" So, first think about what do you see animations, audio, things like that. How would you build that back then if you were building? How would you build it with Vue.js? And so, well, let me just click on this and see if it

works if the internet is happy because this is old code. Oh, it works. Okay, I think we can zoom in a little All right, so have a look at like just this screen, right? We have two choices. We can watch the commercial, which we won't do now, or you can actually drive. Like how would you do these animations? How would you tween this? Did you know we

didn't really have a choice of custom fonts? We had to do all that ourselves. did you come here to play fair, or did you come here to win? Let's find out. Consider we didn't have subtitle features yet. Take the curve. Take the bridge. Now take the lead. All right. What is your choice? Are we going to just pass him, or are we going to just destroy this

guy? Let me just click the other one just to see the memes we were trying to do back Congratulations on your epic underachievement. Tell your friends how original you are, or try again. Should I see if the share to Twitter with the little bird still How about that? Oh, I won't share it now, but there you go. Well, we have Facebook. I think this is just going

to die. Well, decent. Sharing on Facebook was always the hardest thing. You remember this. Anyways, let's choose deception then. Impressive. Now explore the aftermath. All right. We didn't have Well, we had WebGL, but it was really cumbersome. So, we had to do something else to get this 3D feeling to happen, right? But we didn't have Flash. And so, it still had to look really smooth, and we

even had like this little, you know, blur thing that didn't exist in CSS. So, this is actually I think it's like an SVG filter or And so the interesting part of this whole thing is that it had to be in 35 languages. And so we didn't want to make 35 videos with a voiceover and a dude. So all the sounds that you hear are actually events and

MP3s and it's all concatenated together on like a timeline. also you couldn't have a video that you control exactly where it would go in the keyframes. So these are actually images that are all loaded. So we had to slow the game down to a thousand percent. So it's going really slowly and then we had all the virtual cameras around the cars to get picture of all of

them. And then we would actually put that together into a video with FFmpeg and I could then cut it out again to choose which frames I wanted and then you can do this stuff. of course I tried to rebuild this whole app in view, right? We'll show that in a sec. That stayed exactly the same because it's so weird. Nobody would make a library to do that.

All right, let's see. Ready to raise the stakes? Get in the Aventador. You write the law. Well, we know the mercy one. Let's just we'll we'll go through. This is basically almost done. Duty calls but so does victory. And you know what's was crazy about this one is that like it slows down, right? But we didn't have the frames. And so if you wanted to do a

video that has slow motion, you have to invent the frames, but there was no AI. So what we had to do, like this is 13 years ago, like these video editors could invent frames. That's why sometimes on the end you can see it's a little bit wobbly. And so we just had to invent that. And then I had to cut that out again. So we had like

this grunt JS. I'm not sure anyone remembers what that was. But like this is like that build system we had before, but we couldn't really configure it. It was more No, we couldn't really code in it. It was just a configuration, but we had FFmpeg to kind of just then extract all these files again. You try value target. Don't stop. Don't think. Just do. You know what

to do. Just look at what you've done. You see the warbling? Those are like fake frames we had to put in. Anyways, we don't have to continue. It's all the same basically. But did you notice it didn't load once? And each of those 360 ones were like 200 images that it had to load, and all the choice ones were also images that are all preloaded. So while

you would see one scene, it would preload the next one that also didn't exist. And like it's just ridiculous the things we had to But if this doesn't look good, everybody who wants to buy this game on his their PS3 or whatever it was, it just needs to be smooth, right? So let's go back to our slides here. let's see. If you were guessing, like I gave

away a little bit. So what are the things we had to build for this that just literally didn't exist or or becoming a little bit like How do you call this? Like community patterns? Just like we have now, right? With MCP we're trying to do things. It's similar here. SBA didn't wasn't a thing, but people were building it. Like we just all had a different way of

putting things together. So, we have to just kind of figure out, "Hey, we have templating, we have routing, we have fuse, we have controllers, right?" And so, all the stuff we take for granted now, like JS template language, like in few it's so nice and easy and it kind of just works. Well, for us that just didn't exist. We just knew John Resig, the guy who built

jQuery, had like this template-y thing that he came up with with variables in it. And so, we just asked him, "How did you do it?" Because the world was so small that I could just ask John Resig, and then we figured it out and put it in And so, then of course had URL routing, history, deep linking. I didn't show you deep linking now, but if we

had to QA a certain thing, you didn't always have to like watch all this stuff. We had to be able to just deep link directly into it. Um then we had state management. We had to know which things you had clicked because we also had like a lot of analytics and events flying, so we needed to know where you were. Then we had internationalization, and it had

to be for 35 languages. And so, initially they thought, "Oh, we'll just render images for the words." Like, that's an insane idea, right? And so, we had to figure out how to plug in one language into it and that's how the whole app would understand it. Um so, the video player was actually completely custom because all the audio and all the subtitles were custom as well. Like,

we didn't have subtitle track, so I had to figure out what are you know, the blocks of time where something needed to happen. So, there's like an event manager essentially. And so, then of course JS audio playing. So, all the audio you hear it like hover the mouse, it's actually an event that plays a an MP3 that's preloaded before. Um then we had canvas animation. So, all

the animations that you saw that looked like videos were actually just 50 frames that we played at 60 frames per second in a canvas over a timeline. Like, why the hell would you recreate how a video works on the web. Well, because otherwise this wouldn't work cuz you would have to render a video with a keyframe on every video to be able to do it and even

now that's a little bit tricky. And so if you go to the Apple website now where you have these lovely animations, they actually use this type of stuff still. Um for that we needed a tweening And we needed to update the images and the videos with grunt like I just said. And then also we didn't have the luxury of a few file where if you have a

piece of JavaScript that it just gets executed. That didn't happen at all. So for us it was based on DOM nodes and we had to find the DOM node and then scan it and then say, "Oh, I want to do this thing with this DOM node." I'll show that in a And so it was really a crazy project because we had 11 months of creative people at

the agency figuring out, "Hey, how do we market this thing?" And we were really trying to think of like Okay, everybody wants to probably torrent this game. Why don't we spread a fake torrent and then when you get it you actually get this website. Things like that. And EA games actually went quite close to saying yes to stuff like this, but in the end it was politically

not good enough. Like that was a little crazy to do that especially in that time when torrenting was sky high. So in the end they spent all this time and we only had 5 weeks to build this, but I was the only front end dev. And so there was just no sleep basically. Luckily we had two back end devs and a curator. They they were great really

great people, but we didn't have full stack. I'm sure I'm not sure we still have full stack now, but that's for another talk. Um so this was basically me all the time. Like I love doing all that stuff and now with AI of course that's different and we can do like five projects at the same time. And so let's think about what we have Right? We have

few GS that does our single page app stuff. It does routing, templating, DOM manipulation, events, all the things that we had to think about you just have. Right? And so internationalization is a really nice plugin, just works. The whole feed infrastructure, especially with feed plus now, super good. We didn't have any of it. I think I had something called uglify.js, which literally just removed the spaces. I

think that's all we had. And then we had this Sitecore backend. I'm not sure if anyone here knows Sitecore, maybe a few. Which is basically it just took all the files we had and then concatenated them all back, you know, together into one JavaScript file and CSS as one, just removed the the white space. That was our infrastructure. That's it. No builds, no tests. Um we have

right now really, really nice animation libraries, of which GSAP is one, but you can do a lot in Vue also with CSS, right? And transforms and transitions. And of course, we have Pinia for incredible state management. I had none of this. why not rebuild this whole project with modern tools and see what's the difference. And so, I honestly really tried to use AI to do this because

it's a lot of work to try and rebuild this. It could not get it. Like these animations and when something moves, where with the DOM connections, it just could not. And I even like this morning I was like, I need to get that new project a little bit closer to the original because I didn't get to finish it. The AI just screwed it up completely, even the

fancy models. So, um I didn't fully finish it, but it's close enough, right? And so, if you look at the differences between 2013 and 2026, it's a lot easier because everything has been abstracted, but it's somewhat similar. I'm surprised how close I got back then with the our community patterns to what modern tooling uses So, let let's have a look. Let's have a look at routing. So,

this is my router. It's simplified because we had a lot more scenes, but NFS was like Need for Speed Rivals. So, that was our namespace. We had that back inside it's a function, and these functions all like start preloader or like scene one setup or start scene two setup. We'd essentially just fire a controller. And the URL in another function would actually it look at it looks

at the URL and then fires a function in the router, which then fires its own controller for preloaders or scene setup or the 360 thing. And then we had to always destroy that controller. So, this is you can see this as mountain unmount. Because unmount all the events get bound to the DOM. Well, we had to then always unmount it first and then do it again because

if you have double events, things get painful very, very quickly. And so, this actually looks kind of close to this, which is our view router, right? Of course, history out of the box. That's so nice. And you have a view file that just does all the things. You just have to you just import it lazily and there you go. And this but it's it's not that different.

This this is just a lot easier and of course it's unit tested, it's typed. We didn't know what TypeScript was, obviously. Um so, then templating. This one was kind of crazy. So, what we did This is what John Resig did back then. So, we have a script with a type X JavaScript template. And in there you would just put your Java or your CSS and your HTML.

And do you recognize those curly that use them before? It kind of looks like view, no? Just a little. And this was actually something they called mustache templating. And I think that still the name still exists. But, there was or mustache, right? And there was this there was this really cool library that would actually grab your variables from JSON or whatever and then replace it. And we

had some simple if statements. we we had some loops here and there, but not really. And so, this kind of just worked because we would just we would have one index.html with all these templates just there, and we would take that DOM, clone it, and put it in the app based on the route and that controller. So, we would then bind the controller to this HTML that

we put together. And this kind of sounds like what Vue does automatically, right? And so, we'll talk about what that data widget means in a sec. And so, we would have this like get template, and you see there's the mustache.render. Luckily, I didn't have to write that myself because that's like a lot of, you know, string parsing, I guess. And so, we could render the template. So,

the target would be the DOM node we put it into. And so, we would get that from the get template, put it in, and then we would scan the DOM to see, "Hey, is there any JavaScript we have to attach to these DOM nodes?" And that's what that NS scanner actually is. And so, what we did is like the new HTML would be in the DOM. And

for that that new DOM node, we had a scanner that just that looped over all the DOM nodes like jQuery used to do. And we would actually say, "Hey, there's data-widget, and the name is video player." So, what that would do, like video player was already loaded in the browser. We just know, "Hey, this DOM node needs this JavaScript, and then it has data options with a

whole bunch of stuff." And this is also how we did all like the localizations and translations. It would just all be rendered in the We would grab it and then fire it off. And then if new HTML would be rendered in that same gap, basically, or that same hole, we would then, you know, destroy all these bindings and then rebind it again. Or back then, if you

did an Ajax call, which we call fetch nowadays, um we would also then, if the HTML was replaced, unscan or destroy the old stuff and put the new stuff on. And I'm so happy I never have to do this But it actually worked pretty well. And now, of course, we have this. And this is the lovely part about what I especially love in Vue. It's just this

force a simplified version, but this is just one file where I have a little bit of my JavaScript stuff. I have a bit of my CSS stuff, if I wanted to. I have a bit of my HTML. And then, this like this the fact that we have this component called Choice Player, like we didn't have components. That was not a thing. So, it's so nice to just

make a file that has its own stuff. You put it in, but it's just one file. And that's the part that I really like uh about Vue.js, where it still feels like my old-school self, where I have everything there, and I can deal with DOM and do stuff like that, but all the complex stuff is being taken care of. Right? So, this is This was a lot

nicer Um let's have a look at state So, this is what we had. I don't know why I called it JSON data, but I guess it was. Right? So, and this was a big big object, because it had all the languages and all that stuff in it, and all these like 360 views that like 200 files that it was preloading. And so, all the file names and

the fact that they were loading and all that stuff was actually in there. And so, you can see the logo animations, subtitles, IDs of, you know, template selectors, DOM nodes. The thing is, this was completely mutable. So, if I had a bug in my code, this would be muted, done. Whole website is dead, cuz we didn't have that concept of a single page app. We couldn't just

reload, because it goes back to the beginning, cuz we didn't, you know, keep the URL state. And so, yeah, that was really challenging, and I had to build like my own kind of little helper functions, like for a certain action, like, for example, load the preloader, to get that part back from the JSON data, and then when it was done, we actually removed it from the memory.

So, it couldn't go And but it was a lot of work. Like this I simplified this, but this was like 600 lines. You don't want that. Like we actually want this, which is Pinia. So, it's a little small, but I guess on this screen it should work. And so, everything is typed. And you get getters, you get actions, state setters. It's so much nicer in Pinia. And

others like our storage stuff like they all have this lovely um you know, it just reacts to everything, right? And we didn't have it, but it still worked. And we had this other thing, which I now built in here because the UI in this app like with these choices and you're going to different places, right? And you can have to reset certain things and then click there

and it goes to the next thing. That UI is fully reactive, but we didn't have that. We just had to click on a DOM node and hope for the best and see if all the events work and fire. Here, I could just make a composable called use choice interaction and then the the UI would be interactive. And so, I could actually then have functions with clicks for

example like a handle enter or handle leave that would change that UI in this little reactive object. And so, it's so easy in Vue JS now to just click a thing. This thing keeps track of the state and it this might update if we needed it, you know, in Pinia. Um let's see, what else do we have? Animations. So, we like everything you saw in that website

like when things moved from side to side, but also like the the images that would play like a video, that all used a tweening engine. But there were some tweening engines, but nothing worked. So, I just made my own crappy tweening engine, but I only had 5 weeks, so you do that in 2 days and hope for the best. And it kind of worked and it had

like staggering things or on complete and things like that. And so, this actually kind of worked, but I looked at it now and it had all sorts of memory leaks. And it had, you know, request animation frame globally running all the time. And then events would just go into it and hope for the best. But if you like I don't know why this website worked, honestly. But

it worked. And so, funnily enough, I just wrapped that old thing into use tween and built it in the new one. yeah, it's not for production, it's Um of course, we could also use transitions, which are so nice in view. You just use transitions and CSS. So, lots of the things are like the moving around is just a transition. However, um Oh, yeah. Well, this tweening engine

sucked. It's fine. However, I looked at it and this morning we were talking about feed plus, right? And I thought, let's make this code modern because it feels like there is something to this because I have no slide for it, but my API looks so much like GSAP right now that I like, "Oh, maybe there is something to this what we came up with back then like

that tween.to and the timeline thing we had." And so, about 20 minutes ago I made it work in feed plus because I thought my talk was like in 3 hours. Um so, now we have turbo tween and it actually works. So, if you want, welcome to the age of AI, right? So, when you go to npm x, you can actually find this. And this library is only

5 kilobytes and has no dependencies and it works on SSR, TypeScript first. It works in view and react because if you have AI, you say, "Make it work in react." It kind of did. I don't care, but it did. And it's very easy to install, lots of docs, and it works on feed plus. And I think I have a little comparison table here. If you think about

it, GSAP is like the market leader almost, right? It's like five times bigger. It doesn't have native TypeScript. Doesn't adapt to just view out of the box. It's kind of crazy. And so, if you're into this kind of feel free to download and play. Um it has all the playwright tests and it kind of just works pretty well. But, of course, like anything you just release quite

quickly, it might not work for everything. But, if you want to and you like stuff like this, feel free to try and let me know. let's step back and see what this whole experience taught us, right? So, over time, all these architectural things that I had to come up with with my colleagues and friends, they kind of now became configuration. You just install Pinia, you install Vit,

and it kind of just works because this is what Vue JS and the Vue JS ecosystem is so good at, right? No config, just Um then, I don't think the magic increased at all. It actually got just got abstracted And so, the magic is still inside, but it's all just much easier now. And so, if we look at 2013 to 2026, it's basically the painful implementation and

the community patterns where I was sitting, right? And so, over time, it becomes libraries Then, it becomes standards. And then, it's boring. But, because it's boring, you get to do the cool stuff that I had to invent. Like, I got bored just doing those things. But, if I did If I had Vue JS then, this experience would have been even better, like a lot better, actually. So,

boring is good. And so, most folks in this room probably didn't write an XML HTTP request or made a tweening engine because they didn't have one. I would say that's progress. Right? I would say use the tools you have now to actually do cooler we see this question evolve a little bit, right? It's kind of like now here's the AI stuff I promised. It becomes a bit

of a command now. So, you basically I would say, "Okay, how do I do this routing thing?" Let's Right now, you just figure out which one fits best. In our case in view, we're good. But sometimes like with Void, it might be file based or stuff like that, right? So, you get to choose. But maybe next year you just say, "I don't care what router it is,

just add it, please." You don't look at it. actually that boring default, if we have that boring default, actually Open Sky net is really quite cool. Oops. Right? Having this AI is going to help you. But it it only can do that if it has this really good like all that below, all the stuff that the people that speak at this conference for example worked on make

this AI so good. Without that it's you have nothing essentially, right? And so, Vue.js is really one of the biggest shoulders we all get to stand on. So, AI gets a lot better because without that it's kind of just it doesn't know what to do. You need libraries and we need like the feet pluses and the voids and the next to be able to know what to

do and make it And so, are you this or are you this in this age of of abstraction, right? I personally say I'm more than happy to just choose whatever we have and stand on the shoulders of all these people that built this cool and just really build the next impossible thing. That's what I want to And so, that's me. Thank you. Wow. Wow. Wow. This was

for after, but oh, oh, my slide is gone, but it says beer time. So, but you can have a beer at lunch, I guess. Well, it's not beer time, it's lunch time. But guys, one quick announcement before you head out, please the doors on both sides are open. Please try to spread out evenly so we don't all clump up. Uh after lunch break, we're back here. Tim,

thank you so much. Time to eat. Yes, food it is. When we were living in squalor, wasn't it heaven? Back when we used to get on it four out of seven. Now we thought that was a time I hated from day one. Eventually, terrible memories turn into great ones. So, if they call If they hold Cuz it might have been you used to say cuz it got

lost in yesterday. And you might have missed And you're still going to have to pay it come someday. You can pick it like groundhog cuz it might have been Glad I said bye cuz it didn't go well. >> If they call you and embrace If they enthrall you and erase Cuz if I don't say something ladders. had it's only one that matters. And if it causes Take

me out Where there's music and people and the young and the alive. Driving in your car, I never never want to go home because I haven't got one Because I want to see people and I want to see lights. please don't drop me home because it's not my home, it's their home and I'm not welcome no more. And if a double-decker crashes into us, to die by

your side is such a heavenly way to die. And if a 10-ton truck kills the both of us, us. To die by your side, well, the pleasure, the privilege is mine. Take me anywhere, don't care, don't care, don't care. And in the darkened underpass, I thought, "Oh God, my chance has come at last." But then a strange fear gripped me, and I just couldn't ask. Oh, take

me anywhere, don't care, don't I never, never want to go home, because I haven't got one, let alone a home. I haven't got one. And then a double-decker bus crashes into us. kills both of us. light that never goes out. There's a light that There's a light that Never mind. >> You sought it slower to find your way. But folding over won't hide your head. Cuz you

waited long enough hesitated over love. Now you're taking over us. I can just believe it. I cannot receive it. The strongest shoulder won't hold you In cold October, won't hold your Cuz you make it dangerous when you're playing the game of love. They're taking over us. >> Yes, this is the moment that needs to come from the change the mentality of the world. After electronic, after computer

for the automatic for the people, This is experience. Yeah. Tomorrow you make another And tomorrow you won't make another forever. This experience is This imagination 20 20 years ago. is automatic. Yeah, already. >> Just as you take my hand, just as you write my number down, just as Jakes arrives, just as they play our favorite song as you're about to disappear. No one wound up like a

spring before you had too much. Come back and focus again. The walls have been this shape. They got a Cheshire cat grin, all blurring into one. This place is on a mission before the night out. Before you had one on, this close to get cameras. Before I come undone. So you run away from me before you lost me between the notes. The beat goes round and round.

I just pretended that I had a brass instrument. Cuz I thought I had shotguns. Come on and let it out. out. Come on and let it out. on and So you all make something. The fire has been set enough. Just try to take the night. dance, dance, dance, dance, dance, dance, dance. You suffer in a place where there is nothing to explain. You eye each other as

pass. She looks bad. You look bad. just once. just twice. Wish you were May you got to find your feeling. I don't give a feeling. Magic suffer into air. In the In the end it's than I know how to be. And I can't just stand my own two feet from wondering. I fell in love at the sound of my heels fall. our footsteps to be silent I

want them to be in the moment. Stone clouds are closing complicated but I've still got work left to do. But I'm still not certain just how I'm going to feel. I only know that I'm And the situation is growing It's getting closer >> It's getting closer. >> Can't tell seeking corners of dark and bedroom dreams keep pouring the candles keep on Alicia couldn't see. Sleeping angels eyes,

careless pictures in every room. upbringing, wild horses in my mind. my heart on fire watching strangers wave goodbye. was a sacred that destroyed silent? I remember. listening to Stronger than we used to break down. Everything happy had accidents. weakness going cold this is a scripture I can hardly down the hallways of our high school and this is left And I could think horses but my heart I

won't wanting strangers I would call my letters on the sky of Tennessee >> Forces from the sidelines for a race against time betting to defeat only to face a certain defeat. it's not random. the cause was known. It's an honest game ignoring all the combined tailored risks. Down with the power complex to quantify the story. No time for the matches a pawn a say, going to win

the race, just win the race, a race to lose control. Now, now, to cause a storm. just to be careful. now, it's not random. It's irrelevant. Oh well. the party. I'm old. I'm young. I burnt my tongue, but isn't that obvious? It's all so obvious. to try. You're out of time, You are so obvious. Yes. needles through my fingers and my thumb. But I don't mind. I

just want to get high. Yeah, I cut through with the back of the knife. You say it's cool. I was good at school, but now it's up to me. I'm floating endlessly. needle runs. I'm burning out young. Yeah, I don't mind. I just wanted to try. Yeah, I cut through life because I cut through life Hold the pulse for me. Take it or leave it. When you

come back dive into the lake. It's never turn into the madness. And hear your heartbeat louder, a way. The turning of a page. way back. When the hope is in your hands. There's no way You can call for me. be at the bottom. I lived long ago when my hands were clean. What a funny thing you find as you get older. Let your heart will show you

how to find your way. The turning of page. >> Motor wasted, what a shame. Could we start this over? Or better still, let the hill we're dying on crumble. This black hole will swallow us whole if you let it. It'll break unless it bends, so let it Let it bend. For the sake of curiosity, entertain the eerie thought with me. Fear balanced the throne. Let it throne.

>> Who am I to rely on a final outcome? Take a beat, let it be, and breathe out. One and chorus, all our souls know the cadence. Simmer down, circle round, common ground. Common ground. Can you hold the thought up to the light? Can you catch the phrase and harmonize? Feel bound to the drum, let it flow. Let it flow. Stay in the knowledge that all of

this will make way. The moth will rush the old moth to the flame. Under the burning bell of fruit and heart to the chamber they make the dusty Feel my bones to drop. Let it drop. Let it drop. Come closer. To me. Come closer to me. >> An orchestral growth a foreign lingering your throat attacking decay the past part of yourself. a part of You're eating a

part of yourself. >> It's hard and slow to find your man. hand. Cuz you waited long enough. As I picked it over love.