Hey Theo, thanks for the shoutout (and a pleasant surprise to see Vue content here). Small corrections: 1. As many have pointed out around 3:20 - even in the current Virtual-DOM-based render mode, Vue doesn't need explicit memo to skip child component updates. This is because child components will track their own dependencies and only update if parent props have changed. 2. Near the end about Vapor SSR codegen - it is actually a playground bug that it is showing Vapor code in the SSR tab. Vapor doesn't change how Vue components are compiled for SSR, and the current SSR compilation output is performant by turning templates into string concatenations and buffer pushes as much as possible. In the browser, Vapor runtime will be able to hydrate from the same SSR output like we currently have.

@r1konTheAutomator

2 ай бұрын

Evan "The Vue" You in the flesh 😀

@jaymartinez311

2 ай бұрын

is this replacing nuxt?

@sarraju

2 ай бұрын

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

@jaymartinez311

2 ай бұрын

@@sarraju thanks.

@nestorrente

Ай бұрын

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.

Vue mentioned!

@neneodonkor

3 ай бұрын

I am shocked.

@victornpb

3 ай бұрын

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

@AdamFiregate

3 ай бұрын

My view of Vue is positive. 😉💛

@SandraWantsCoke

3 ай бұрын

...aegen!

"Vue RS is similar to React RS": 3:20 No, it's not similar. Vue reactivity system is based on running "chunks" of code (in watch, onMounted and another hooks), while React RS is based on running component from start to the end. You can set console.log at the beginning of Vue component (setup/Composition API), it will run only once, while React will trigger console.log every time when state is changed. "When specific change of the state changes component, other's do not": 3:34 in example will not be updated (rerendered) in Vue 3, if state from the top of tree do not included in props of the Vue does it via Compiler Flags

@CrimsonBlazz

3 ай бұрын

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.

@thisisnotjoshiswear828

3 ай бұрын

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

@tokiorys

3 ай бұрын

@@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

@jonnyso1

3 ай бұрын

Vues lifecycle hooks are really great and easy to work with

@ofmouseandman1316

3 ай бұрын

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

We need more VUE JOBS, everything stuck in React

@gillall4828

2 ай бұрын

Work to create jobs, dont wait for jobs.

Vue was the first framework I learned and worked with. Every time it's mentioned I'm like "yayyyy! Vue!"

@thatpenguin965

3 ай бұрын

For me it's svelte lol

@eng3d

3 ай бұрын

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.

@W1ngSMC

3 ай бұрын

​@@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).

I love how Vapor is a play on the word solid. Solid -> liquid -> vapor. Such a neat callback to the inspiration of Vapor Mode

@h0lyrs422

3 ай бұрын

So now we need a Liquid framework

@steveoc64

3 ай бұрын

And Svelte gets what upgrade ? Porkchops ?

@sania3631

3 ай бұрын

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

@madjunir

3 ай бұрын

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

As others have already pointed out, Vue's (at least vue 3 and as far as I know vue 2 as well) reactivity is not at all similar to React's. Components are not rerendered entirely from top down depending on where the update occurs. The vue compiler makes sure that the resulting JS code only updates the DOM wherever a value is used, similar to how SolidJS works. Vapor mode just removes the need for the Virtual DOM.

@ryansolid

3 ай бұрын

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.

Vue's reactivity system is so far ahead of React's since years, it's absurd :D

@oscarljimenez5717

3 ай бұрын

Why you think that?

@gro967

3 ай бұрын

@@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.

@cristianosoleti489

3 ай бұрын

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

@GoYoops

3 ай бұрын

​@@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.

@oscarljimenez5717

3 ай бұрын

​@@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.

Sorry, but you are _not_ correct at 15:15 Theo. Vue already has fine grained reactivity - I can't link vids here (thx, YT), but see any Vue 3 release talks by Evan or release notes since 3.0. What Vapor changes is the intermediate V-DOM layer on a developer choosen case by case basis. Which is great, because sometimes the V-DOM is actually really helpful, and sometimes it's not necessary. Either way a regular dev shouldn't have to worry about technical details during regular work. Now you can just flick a switch and/or let library authors deal with it! PS: SolidJS is fast, but not much faster than Vue nor the fastest framework out there. Please refer to "frontent framework performance" by Stefan Krause. And also... All FE frameworks are usually more than fast enough nowadays, V-DOM or not.

@yamyam263

3 ай бұрын

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.

@brod515

3 ай бұрын

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.

Can we talk about how gorgeous vue is for a sec

@InternetKilledTV21

3 ай бұрын

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.

@ItsRyanStudios

Ай бұрын

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.

Vue's reactivity system is already signal based. It just doesn't have the same name. refs are signals, which are both just other names for observables. The only thing that is similar to React is the idea of the VDOM

Every time I learn a bit more about how React works I start wondering why people still use it.

@neneodonkor

3 ай бұрын

😂 😂 😂 because it's popular.

@Kris96431

3 ай бұрын

Have you tried using it?

@jonnyso1

3 ай бұрын

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

@jonnyso1

3 ай бұрын

@@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.

@PraiseYeezus

3 ай бұрын

Because, like most frameworks and tools and solutions...it's fine. You could write a blog post or a KZread 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 KZread 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)

A pro Vue video, times really are changing.

"Vue RS is similar to React RS" vue: we are not same bro

Since I learned how Solid implements true reactivity, I left React behind for my own projects, and every time I need to work with some React code I dread it a bit. I think SolidJS got it right from the get go.

@noahwinslow3252

3 ай бұрын

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

Solid, Vue, and Svelte nail the mental model: a setup function where your "init code" only runs once + observable pattern (signals). React dominates the industry by a thousand miles though, so anything they can do to catch up would be very welcome.

@ColinRichardson

3 ай бұрын

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.

@boccobadz

3 ай бұрын

​@@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.

@ColinRichardson

3 ай бұрын

@@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..

Vue already works how you think vapor will make it work from a component writing point of view. Vapor is just an 'under the hood' thing and an optimization. From a DX perspective, nothing really changes if you're already using script setup. Vue already works just like Solid, except there is some under-the-hood VDOM diffing and it's not at a super fine grained level.

My homie talkin bout Vue == insta thumbs up. It's simply just the way.

It's so interesting because when I got into this 7 years ago Vue was still seen as the new kid on the block.

Thank you for the Vue3 Vapor SFC playground.. I couldn't find it anywhere on Google (My fu was bad), but thankfully it was shown in your video.. 👍👍👍👍👍

This is just pure hype man, i love where vue is going in terms of signals, very promising!

I've been primarily doing frontends in Vue for years now. V2 --> V3 was a big leap, especially once I got the composition API down. My goodness this has me excited all over again. It wouldn't surprise me if some amalgamation of Vue + Solid were adopted as the "standard" in a few business years, _especially_ given the flexibility demonstrated with "bring your own signals" functions.

in Vue, we trust

Nuxt is amazing.

@kylerjohnson988

3 ай бұрын

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

@ 1:23 I'd like your font, is it personal asset or a public available ?

Why can't signals work like this in React? I've used and seen demonstrations of preact's signal library which behave like this, or are there still pitfalls and edge cases like you mentioned?

Isn’t Vapor mode similar to what Angular is doing with its OnPush change detection strategy? OnPush changes the usual change detection and only updates components when a signal value is updated

Pretty cool thing. I heard about Vapor mode long time ago and maybe we finally get it this year. Sounds promising

In case of solid, it's like observer and subscription model. In deep down it will store all the dom node where count variable is used, when you set the count it will iterate over all the nodes and set the innerHTML to count (I might be missing something).

Vapor mode is really cool 👀👀👀

The fact that you can easily replicate solid's and angular's signals with a small function is really cool

@justkant

3 ай бұрын

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

@kylerjohnson988

3 ай бұрын

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.

@SigmaTapion

3 ай бұрын

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

My favorite part of Imba is not being tied to react rendering and no needing memoization-like calls

theo talking about vue !! impressive

Good dubbing on the "Google" at the beginning there. 😂

Vue/Nuxt is the best

@TheAlexLichter

3 ай бұрын

🙏

@sania3631

3 ай бұрын

Same here! And I see Alex confirming it too.

AFAIK Solid is also compiling the walks of the dom from the JSX for the reactivity and compiles the rest to templates for cloning it on the client and using string concat for SSR I think Vapor is doing that too, so I don't know if you'll want to call this a fake signal on both sides at 9:30

Great video , now I atleast know what compiler means in context of JS frameworks, and push and subscribe architectural way for components. (VUE is getting much better)

If you think about what a signal is, it intuitively matches up with how you would make reactive elements in raw javascript (using eventListeners and an internal event emitter pattern, setting innerText of elements, etc.) This is why I think Solid is the spiritual successor to the last generation of frameworks. It matches the mental model of state but implements it in a much more precise way that's more in line with the base language it's built in.

@donnacasterr6223

3 ай бұрын

Signals came to Vue3 way before Solid adopted it

@jchantrell

3 ай бұрын

@@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

@ryansolid

3 ай бұрын

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

@donnacasterr6223

3 ай бұрын

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

What website do you use for that whiteboard you always use in your video's?

@yamyam263

3 ай бұрын

Excalidraw.

@InternetKilledTV21

3 ай бұрын

I am pretty sure it's excalidraw

@voyagelove554

3 ай бұрын

Excalidraw

@abdulramonjemil

3 ай бұрын

Excalidraw

@hebestreitfan6973

3 ай бұрын

excalidraw

Ok, so Vue (Vapor) is svelte 5 in green and Svelte 5 is Vue (Vapor) in orange huh, I see. Btw, this is good. I like the path these framework chose.

@kylerjohnson988

3 ай бұрын

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.

@Methapon2001

3 ай бұрын

@@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.

VUE MENTIONED! LESGO VUE

What diagramming software is that looks cool.

@DarkzarichV2

3 ай бұрын

excalidraw

Love too se Vue in here and mostly love all those under th hood explaintions... KZread needs more tech deep dives like this one

Sorry this might be a frequently asked question but what's the name of the note/schema app you're using?

Can someone please tell me what software he uses to draw the diagram? I love it

@fischi9129

3 ай бұрын

excalidraw

@rev4324

3 ай бұрын

excelidraw

So as you said, somewhat like Knockout. I never had an issue understanding Knockout, and sort of miss it.

Need more Vuejs and Nuxtjs content 💚😊

about the .value api for state, you can replicate in react, and I did just for fun, I also added an other slternative. That being said, you don't have the signal optimizations since react doesn't do that anywhays for now at least

Thanks!

more vuejs videos please

Vue doesn't need new ways to do "signals", because its been using event driven data subscriptions since the beginning. They're just giving developers more options they're familiar with, just like they did with the composition api. It's more flexible, which has its pros, but really it was for react devs. It's not an actual need. But that's what's cool about vue. It's a full featured framework that aims to make the developer experience great for a broad audience.

@kylerjohnson988

3 ай бұрын

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.

@TruthAndLoyalty

3 ай бұрын

@@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.

@typoerror177

2 ай бұрын

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

@kylerjohnson988

2 ай бұрын

@@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.

Angular mentioned!

Vue is now 2 years older than jquery was when vue was first released. #timeghost #iamold

@yamyam263

3 ай бұрын

r/BarbaraWaltersForScale

@InternetKilledTV21

3 ай бұрын

Very nice 😂😂

No more hydration node mismatches in ssr mode!

Vue!

vue rocks

Didn't realize the framework I was writing was 'Solid'... nice. good to know.

which app is that @1:07

7:31 -> sorry but solid is using compiler. That's why it is so fast because it already know what will update in your app. From solid tutorial: "A Solid App is composed of functions that we call components. Take a look at the HelloWorld function on the right: it directly returns a div! This mix of HTML and JavaScript is called JSX. Solid ships with a compiler that turns these tags into DOM nodes later on."

Now think about MobX as signals without the additional boilerplate, because it's done automatically through the Proxies mobx creates. And all of that has been available in react for years.

Solid doesn't have a VDOM though. That's the power of signals: you don't really need to diff anything because there is no re-rendering. The (arguable) downside is conditional rendering uses built-ins like Show or Switch.

@samuelmorkbednarzkepler

3 ай бұрын

Vapor also does not have a VDOM

This is the most excited I've been for Vaporware since Duke Nukem Forever. Thankfully, no matter how it turns out, it will surely be better by comparison.

so its moving from interpretation to compilation?=

Second! Exciting!

finnaly!!

I wish Ember got more recognition for its reactivity system (since Ember Octane). You can just mark a property as @tracked if it's on a class or use "const thing = new TrackedObject()' or similar. That's it, reactivity everywhere with minimal template updates. It's so easy to use, you don't need to call the property with () or .value or anything, it just works as you'd expect.

The symmetry in the SSR vs browser code 20:00 is the most exciting aspect of Vapor to me. No more hydration errors with slight vdom mismatches.

Waiting you at Vue conferences now 😏

It's been a while since I heard people talking about Vue

@blubblurb

3 ай бұрын

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.

@sania3631

3 ай бұрын

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

Ура

Babe wake up, Svelte but in green just dropped

I wonder why no one has used a web worker model? Wouldn’t that ensure that each component does its own work on its own dedicated CPU thread? You would just need to figure out how many cores the user CPU has, create a queue in memory the size of the number of cores, and then you could spawn a web worker that uses the queue to handle the component logic in a recursive like manner (similar to how like the event loop works), and as each worker thread ends, the result is finally displayed in the UI. That would scale on the user device and potentially be bad on single threaded or low threaded devices, but most machines now days have more than one thread, and what we have now is still technically single threaded, so this seems like a way to break free of that for people with better computers. But maybe there is something I don’t know about and am not considering /shrug. It would be fun to explore this approach and see though.

@JohnSmith-op7ls

3 ай бұрын

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.

@hebestreitfan6973

3 ай бұрын

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.

@kylerjohnson988

3 ай бұрын

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.

oh look it's an even bridge with extra steps.

Its interesting to me the difference between updating an existing framework to work differently vs creating a new alternative framework that works differently. updating a framework automatically gets adoption. creating a new framework is free from the limitations of wanting to maintain backwards-compatibility or wanting to play it safe I guess. But bigger frameworks do still have ways of adopting the innovations of smaller frameworks, whether that be by making breaking changes, making breaking changes for what it means to write "modern" code, or by making more compatible optimizations such as what vue vapor is doing. But either way bigger frameworks' changes automatically get some level of adoption. it reminds me of that joke that "svelte is just vue but without jobs" or solid is react but without jobs. I wonder if it is better to stick with learning bigger frameworks and just wait for the improvements to eventually come. Of course you can learn both big and small frameworks and learning one will help with learning the other, but maybe its still wasting some time to learn the smaller ones? idk

The more I learn about React, the more I get angry because it's so much more popular than Vue despite being absolute shit. What you explained about re-rendering things and re-running code when some state changes is atrocious! How could anyone prefer that over Vue!?

@andreilucasgoncalves1416

3 ай бұрын

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

@dasten123

3 ай бұрын

@@andreilucasgoncalves1416 really? 16:36

@andreilucasgoncalves1416

3 ай бұрын

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

@gcash49

3 ай бұрын

@@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

@SilversRock

3 ай бұрын

@@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!"

does this make my website vaporware

I see people started looking at Svelte and figured out they could borrow the compiler-centric approach... And yet, all these frameworks will stay the same pain in the back side **cough-react-cough** as to not differ from the previous iterations too much...

@kylerjohnson988

3 ай бұрын

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.

"I use Arc btw" is the "I use Arch btw" of 2024 for Chai Latte-sipping MacBook devs

Vue 4 eva

nice

Yay vue!

03:58 All the right memos in all the right places, so yea, we're goin' down

Vue rules🎉

Finally good words about vue without jealousy

ive been confusing vue and vite this whole time. dont tell anyone tho

@otis3744

3 ай бұрын

Wow

@irumidesu9236

3 ай бұрын

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

@sania3631

3 ай бұрын

Vite was developed by Vue core team.

this going to slaughter swift vapor on google 😢

CanJS figured alllthis out a decade ago using change propagation based rendering with observables

RIP FLOW. RIP JSX. RIP FLOW. RIP JSX. RIP FLOW. RIP JSX.

Vue is rock!

Vapor is already the name of Swift's backend framework, wtf.

A quite different topic, but I wonder... when we're gonna stop using minimized JS as intermediate language? We should already have DOM API for wasm and use wasm similar to Java's bytecode or .NET's CIL. Then we can use browser as a virtual machine (which it is right now, but just for JS). If someone will tell me it won't reduce bundle size or performance - I won't believe him.

So Vapor is petite-vue? 🤔

One thing I admire about Theo is that even though he loves React, he can still talk about how other frameworks do cool things.

Rip though it was the swift vapor

This is roughly how everything worked on jQuery

This is gonna be Elon's favorite Vaporware framework

Vue is something I know a thing about. I've written it for close to 4 years. To see Theo talk about Vue with such confidence, but have glaring misunderstandings is concerning to say the least. What else is he talking about with confidence but is missing key fundamentals? Just something to keep in mind for those that follow him. He's misinformed and confusing many things in this video, but talking with confidence.

... I thought this was a video talking about something else. I though vapor was refering to "vaporware"

I just wonder at which point the React team will concede defeat and add signal primitives and compilation. And before you get me started about SolidJS etc, I am not saying to abandon the whole vDOM. I am saying, much like Evan did, "rework the whole thing so you can have signal based components and classic react components in the same vDOM and have the compiler work its magic". But hey, this effort will not make Meta's applications any more attractive and what with the whole signal/pure-reactivity thing being fast and efficient it may even turn some heads away from SSR, hence away from Vercel. Oops.

Vapor? The backend framework for Swift???

@edism

3 ай бұрын

Naming collision.

@IvanRandomDude

3 ай бұрын

Vapor? Laravel deployment platform???

@sukhmandersingh4306

3 ай бұрын

Vapor, the stuff that builds up during evaporation??

@ark_knight

3 ай бұрын

Vapor? That platform where they publish games and get review bombed???

@edism

3 ай бұрын

@@IvanRandomDude now it's a collision-fest.