Vapor: The Future Of Vue 

Evan "The Vue" You in the flesh 😀

is this replacing nuxt?

@@jaymartinez311​​⁠​​⁠​⁠​⁠No, it’s not a framework, just a compiler that compiles vue code to js, without virtual dom

@@sarraju thanks.

Point 1 is why I love Vue so much. It's the same with computed refs or watchEffect: you just write your logic and let Vue do all the work. Memoized and performant by default ❤ And in case you need something more specific, you can always set a watcher over concrete refs or values, but you are not forced to do that all the time.

I am shocked.

It's disappointing that Theo made a lot of assumptions, but wrong assumptions coming from react thinking world.

My view of Vue is positive. 😉💛

...aegen!

Which is also why signals work so well in Vue. Because the behaviour is already similar. Basically, non-vapor Vue behaves like Solid but renders using React's v-dom strategy.

idk but getting something like this wrong when the whole video is about vue makes me feel like eh

@@CrimsonBlazz You're right, but partially) The reactive system in Vue is indeed similar to Signal from Solid/Preact, however, it is not at all similar to the reactive system from React Theo was just talking about how components will be updated in React, but components in react updates every time and re-rendering full component

Vues lifecycle hooks are really great and easy to work with

IMO: Vue behave more like React used to work with Class Component (with a render function)... but in a sense this is right, we are far from a observer pattern such as Solid and still rely on a vDom Vue and React (and vDOM in general) => the render function keep track of what to change Solid => The Signal keep track of what to change

For me it's svelte lol

Senior here: Vue wasn't my first framework but it is a framework that makes sense. IMHO, both Angular and React don't make any sense.

​@@eng3d Lead engineer here, my first ever framework was angular.JS (so old), but the first framework I learned willingly was vue and it was so much fun compared to the previously mentioned crap. Recently I worked a lot with angular 17 and I must confess it's almost vue-like at this point. It's not completely horrendous to work with (and I really like the dependency injection, although most of the time it feels a bit too much for the scope). Svelte is easy to pick up but it does get messy when you make a huge enterprise application. It is still a favourite of mine. React is just a mess (subjective).

Work to create jobs, dont wait for jobs.

So now we need a Liquid framework

And Svelte gets what upgrade ? Porkchops ?

And now we also have this... Vue -> Vapor -> Vite (quick)

The word steam was taken so now the only word available was Vapor. Hopefully won't become Vapor(ware)

Why you think that?

@@oscarljimenez5717 I don't think that, it's just how it is. React is just now migrating away from the useEffect and memo madness and needs a completely new compiler to achieve what Vue already does as a core feature (like only refreshing component parts that need to be refreshed) for years.

just try it. the sole fact you can share reactivity across non-vue files it's a winner@@oscarljimenez5717

​@@oscarljimenez5717 It's because Vue's reactivity is more modular than Reacts which hands more control over to the developer and makes managing side-effects easier. In React, the entire component re-renders. In Vue, it's more precise in what it chooses to update in the DOM. Not only is Vue more efficient, it's easier to debug.

​@@GoYoops But that's a total lie. I think a lof of people are miss informed in this subject. Is not that the React team can't make React work with signals like features, is that they don't want. And the reason is "graphs". In a granular reactivity system like Vue, Solid, etc. Every variable is a graph you have to think about it and track in your mind, that's easy at first, but it can become a nigthmare if you don't have careful. In React everything is a single graph, a graph of componentes that you follow. That's why the React team don't want to use Signals. So from my point of view, Vue is not "better" than React, neither the other way. Is just different solution of a problem. Vue is faster so is better for Client Side Apps, React work better for Server Side Apps. React currently have worst Client Side DX than Vue because useMemo, useCallback use cases, but better Server Side Code DX. I think a lot of people are miss informed reading random stuff in the internet without knowing the real reasons of stuff, and just following the hype of Signals without asking the disavantages.

Vue has some optimization with it's V-DOM but it is really Vapor where it starts to work similar to Solid. Before hand there were some template/control flow level optimizations but true granularity is only coming now. Before you had to rely on things like the `v-memo` directive to try to reduce template rendering overhead.

All FE frameworks might be more than fast enough, but some require you to write more or perform mental gymnastics to get to that performance level. I'm excited about the future of React with the upcoming compiler, so I can free up the mental space previously occupied by useMemo and useCallback.

I was constantly perplexed throughout this video how the assumption was Vue wasn't already working the same EXACT way Solid does. I'm sure he doesn't use Vue that's why the was a bit of a misconception. but Vue literally is already this forget about Vapor even.

😂 😂 😂 because it's popular.

Have you tried using it?

@@Kris96431 Yep. Didn't go far because I don't like JSX and the whole rerender everything situation.

@@Kris96431 Yes, but didn't go very far to be honest. The whole rerender everything is a pain, also I don't really like JSX which ruled out Solid for me. I'm traumatized by Angular from years ago so I'm never touching that again unless I'm forced to. Tried Svelte for a bit but it was a bit too hacky for my liking, also at the time none of the above were nowhere near Vue in terms of documentation, don't know if that's still the case. All this of course because I had the luxury to choose what I to use for a change.

Because, like most frameworks and tools and solutions...it's fine. You could write a blog post or a RU-vid video about any tech under the sun, and have a dozen reasons why it sucks. But at the end of the day...most things in general are fine, when it comes to software dev. Is React an example of perfect engineering and airtight design philosophy? No, but as the popular phrase goes, the only programming solutions people don't complain about are a) the ones no one uses b) the ones that don't have a popular following on RU-vid so making fun of them isn't as supported in internet comments where going against the mainstream is seen as a signal of intelligence (I might have amended the phrase slightly there)

It's exactly why I landed on Vue as my default. My code is just... simple. Everything feels tidy, or at least as tidy as it can be.

Been using it in production for a complex financial app, for over a year now. I love working with it every single day. Nothing against react, used it before this project, but love Vue so much.

I really want to switch but every time I think about it, I feel limited by the ecosystem, how have you felt about this?

There has been mentions of us downgrading from Vue to React.. because they want access to a bigger developer pool.. I have already told them I will leave if they make us change. Others have not made similar threats, but I believe that is because they don't know the how much worse React is to Vue.

​@@ColinRichardson Most people in the tech industry know how "good" is your average react dev. And they're really bad. People using different tech are usually much better at software development than copy-pasting kids after react bootcamps. Same thing with hedge fund hirings - it's much easier to turn physicist/mathematician into proficient cpp dev (even though they mostly work on models and the other people implement them) than the other way around.

@@boccobadz Yeah, the problem I think management have, is we just purchased another company, who have REALLY good developers.. and they use React.. and then they see how many people have React in their CV.. and make the false assumption this is the the direction to go.. Though, I may take your comment and re-word it to (if you don't mind me doing so) changing it "There are many developers, but few GOOD developers, There are many React developers, but few VUE developers".. Try to get them to draw their own lines..

It really is and the Nuxt dev tools are the best I've ever seen in any tech and it isn't even remotely close

Well you can replicate almost any API by wrapping a lower level one, but you won't replicate the actual runtime (order of updates, push/pull model, sync or not, etc..) That's also why you want to focus on primitives like Solid is doing, because a well thought out primitive can allow you to build almost anything on top of it

Yeah, the concept of using a graph structure to track dependencies is the backbone of the signal implementation so there are similarities. Different frameworks use different rendering engines and detect changes differently so their signal implementations vary. Solid's signal graph is a Directed Acyclic Graph (DAG) while Angular's implementation uses a bidirected graph and the difference between the two as a result is significant. The implementations are fundamentally different as far as which edges they track and how they notify the framework which component needs to be rerendered. So this isn't really a replication, but it is similar because they are all using signals as a reactive primitive.

Bad choice of words I guess, then. Maybe replicating some of the DX is a better choice of words?

Not at all. Not even close. They both use signals, but their signal implementation differs in how and when they track edges between nodes on the dependency graph, how the framework is notified of a change, how they handle "glitches" for computed/derived signals, how they schedule effects, and the role the compiler plays.

@@kylerjohnson988 of course, I know that even if it use the same pattern doesn't mean it is exactly the same in how these framework implemented. I mean overall it still uses the same pattern which is signal and without virtual dom.

It's not the same. Signals aren't just about reactivity - they're about change detection and that's really the more interesting part. Vue has already had a reactive primitive, but it doesn't have the dependency graph a signal implementation provides. The dependency graph facilitates a more efficient change detection algorithm while preserving the DX, which is ultimately why Evan and the Vue team are pursuing it. It's 100% NOT for the react devs... React doesn't have a signal implementation and the react team has not indicated in anyway that they are moving in that direction.

@@kylerjohnson988 reactive primitives are signals. They're proxy objects that emit changes to subscribers. From the vue docs: "Fundamentally, signals are the same kind of reactivity primitive as Vue refs. It's a value container that provides dependency tracking on access, and side-effect triggering on mutation." What they're pursuing is not relying on the virtual dom. So you aren't wrong about that part. However, you already have computed properties that are relying on those subscriptions to rerender, so it's effectively the same idea. I was saying the composition API was for react devs, not signals. Although, it's not too hard to implement them in react. I hate react state management so much I made a library for react at work which uses useSyncExternalStore or useEffect to subscribe to event buses and vue-like proxies so we get communication between disparate components and minimal rerendering for free. We don't have to use context wrapping or prop drilling. Everything lives in modules outside of components. And react just templates. I was suggesting the wrappers mimicking other frameworks are for adoption, not signals. Signals are a core concept in vue.

@@kylerjohnson988lol really? Vue’s reactivity IS indeed a reactivity graph. Get your facts right.

@@typoerror177 my facts are correct. Probably more than you realize given that I’ve read the source code of Vue’s implementation and I personally know members of the Vue team. They do have a a dependency graph implementation, but it’s not the same type of graph you see in signal implementations like Solid, Angular, or the upcoming Svelte Runes. The type of graph matters because the implementation differs greatly in what edges are captured on the graph and how the values of nodes are updated.

Excalidraw.

I am pretty sure it's excalidraw

Excalidraw

Excalidraw

excalidraw

Signals came to Vue3 way before Solid adopted it

@@donnacasterr6223 You're right, Vue (and many other frameworks) did it earlier. Solid didn't even have a 1.0 release until 2020. I am just saying that it got to take all the learnings of the prior generations and make something that's comprehensively built around them

@@donnacasterr6223 This is incorrect. Solid came out years before Vue 3.

Solid was using signals before Vue3? Do you have any source on that?@@ryansolid

🙏

Same here! And I see Alex confirming it too.

r/BarbaraWaltersForScale

Very nice 😂😂

excalidraw

excalidraw

excelidraw

Well theres not much to talk about Vue as it just works. People get things done with it. i know React and Vue obviously I prefer Vue by a lot.

Vue and Nuxt devs need less videos about their frameworks.... because they are easy and work well.

Very simple to answer that, people who like React like JSX and to use other people libraries Most people who uses React write very unoptimized code without any memo at all and don't care about it when they care they move to other framework So if you write this way React will usually have better DX than pretty much every other frontend framework And another thing is React is bad for things like forms, but if you keep the form logic in the backend and make a dumb frontend form a not optimized React code do the job

@@andreilucasgoncalves1416 really? 16:36

Most React devs I know personally don't care about other frameworks and don't get triggered like he said in the video I am not a React dev, but I know many of them and they can make the job quickly and that is what matters the most of the time

@@andreilucasgoncalves1416 right on, that's why despite the hate you hear online, it never transpires in the real world. react has not even fallen a bit within the job market or in greenfield projects

@@andreilucasgoncalves1416 Most react devs I know see react as the holy grail - they got angry as soon as I mentioned stuff other frameworks are doing soo much better. I once got the opportunity to showcase some of these devs some shallow comparsion between react, angular, vue and svelte (I work with all of them in different enterprise setups) - ou man, I will never forget the looks on their faces when their holy bible melted more and more in their bare hands :D Funny thing is: Some of them turned their back on react and started looking into alternatives. Best quote so far: "React gets the money - but the fun is somewhere else!"

To give credit where it's due, Angular 2 was the first to implement a truly compiler-centric approach. Rich Harris even talked about it as the inspiration in several of his videos over the years, but he thought he could take that further, and he did in a major way. Dude is a genius. I can't wait for Svelte 5 to drop.

Vapor also does not have a VDOM

Wow

Vue is a progressive JavaScript framework used for building user interfaces, primarily for web applications. Vite, on the other hand, is a build tool that aims to provide a faster and leaner development experience for modern web projects, and it can work with frameworks like Vue

Vite was developed by Vue core team.

It’s pretty rare to be doing long running processes in a web front end which doesn’t need to be constantly manipulating the DOM. Doesn’t seem worth it to run components in their own threads by default when the overhead won’t give you any gains in most cases. Running code in a worker will let it run on its own thread, and you can get the number of logical cores in JS, but once it needs to do something to the DOM, you’re back in the main thread/process, and those workers are competing. So you’ve still got the UI bottleneck but now you’ve added the overhead of the web workers and managing them.

Why don't we throw in WASM and Kubernetes as well? Your proposal introduces a wild amount of overhead which is (almost) certainly not worth the performance benefit.

Web workers don't have direct access to the DOM so there would have to be an abstraction layer that acts as an "orchestrator" between the two responsible for asynchronously scheduling DOM updates in batches to prevent "glitches" (or intermediate states that aren't representative of the actual state). The orchestrator would require as much memory or more than the actual logic and dependency graph of the signal implementation, which would defeat the purpose. Even if there was some gain in speed, it would be likely be marginal and not worth the cost in terms of memory and complexity.