@Justine Chang I feel like Vue has a more loving and helpful community, while React has way better 3rd party tooling support, which is mostly the result of React being so widely used.
@uziboozy in my experience, for real enterprise the only viable solution is Angular, even if I'm not a fan of it. There are so many moving pieces in a 15+ frontend dev team, and it's a pain if you don't have enough senior experienced devs to move things along. I think that Svelte is great because it brings in new ideas and approaches to the table. If they are sticky enough, the rest of the ecosystem will have no option other than to incorporate them.
I think options is so much easier to learn that it should be supported as the default option. Composition is great but someone who is new(ish) to js would probably have a hard time wrapping their head around things like refs vs reactive objects, when they just want to render some values. And there's more footguns as well, watchers outside components can leak pretty easily when they aren't tied to the component lifecycle. That thing uncle ben said etc.
@Mihkal Jouste you might be right here. I am sold on Composition probably because my React background. Indeed, the options approach is a more clear approach.
@@awesome-coding I'm not a big fan of composition api altho i understand why it exists. I still would pick option api especially for smaller projects like mid size, I'm still using react and not gonna get back to vue, but i love vue for the directives and lifecycle separation, really similiar to angular, but done much better and simpler
VueJS hit the right sport for me coming from AngularJS it feels like Modern AngularJS and the fact I don't have to fuck up all html css javascript in one file like react.
I have a question: I know it's supposed to be single page app, but let's say if I wanted to embed the app to some CMS, is there a way refer to external css of that CMS within the Vue app? Like... if there were 10 different Vue apps, I wouldn't like to copy css 10 times to Vue Apps and modify them 10 times
@Timo Pitkäranta - This is a pretty standard scenario. You can store the shared css somewhere on your server, say "assets/css/shared.css". Then, inside your Vue app, you can add a tag loading the shared css file via an absolute path.
Never understand why the time killed for frameworks and which one is the best. U just need to send commands to the backend and observe changes, and with this two things u have deocoupled microfrontends. But If I choose today, I go with AstroJS and SolidJS combo.
Astro + Solid is something near and dear to my heart as well - I'm actually working on a video about just that. However, I don't think we would have such great libraries / frameworks if there weren't so many library attempts and ideas explored in the past 10 years.
@@awesome-coding I'm old timer when thinking about, if we really need new technologies. If scalable microservices can survive with event streams, why not the frontend? Let's just think how we can decouple two microfrontends? Probably firing some native js events from one micro frontend and the other one listening and subscribing to them. Before we jumped on the bandwagon with SSR, CSR and that jazz, angular already provide that observable pattern, which now solidjs is famous as react but 'fixed'. Now to my point, if service A on the frontend can fire just simple CQRS event, and microservice X do his duty, service B,C,D and every other can subscribe on those events in isolation on the frontend. We need some state? Probably, which is no that as of importance, because we can retry on changes and error in different ways. So in my perspective, the missing part of the JS ecosystem is native rxjs.
Still, React is the king, it's WAY better than any other front framework, very solid primitives that let's you build exactly what you want, I don't have to talk about React server components ^^ million years ahead of its competition, every framework try to break/replace react failed, because react is the best at being simple yet powerful, in react you write JS/TS, in Vue you write Vue, Angular you write Angular.....The only framework worth learning besides react and I believe it's the future is QWIK, why ? because it is different, completely different, no hydration and uses resumability, which they invented, React can pick up the idea but it needs a whole rewrite, but in 5+ years I think a "resumable" framework will be the norm, it is much better in all areas ! but for now it's React
@Aghiles Lounis - Did you get the chance to check out Solid JS? My background is also in React, but I feel like Solid will turn out to be a real alternative to React in the long run.
@@awesome-coding I think Solid is objectively more performant and maybe better overall than React, BUT it’s not sufficient to bypass all the React ecosystem to use Solid, like it’s not necessary for the problem it’s solves, you will only need it for embedded devices where performance need to be maximised, other than that it’s not revolutionary enough to change the state of React, but QWIK framework or similar style with resumability It will change a lot of things and it’s objectively better than what we have now, because you will not hydrate or ship any JavaScript code until you click the thing, then the exact code like a very little portion gets downloaded and executed, with that you will always get 100 score lighthouse, and best performance possible
I like the fact how open and simple react is comparing to others. It has basically 0 learning curve comparing to vue, angular etc until u wont touch react + ts
@Aghiles Lounis - I agree with you. One thing I'd like to see with Qwik though is more concise / clean way of working with the lazy loading resources. The need to wrap various stuff in the $ for QRLs to properly work feels a bit too hackish for me. If they are able to sort out their APIs in next iterations, for certain resumable apps will be a big thing.
@@awesome-coding 100% agree, the api is not very clean, needs a lot of work imo, need to wait future iterations, nether less it’s a good start I would say since they are taking the React style api haha 😁
No it doesn't. It costed me my 1.5 year. After Composition API every library started to fail and they still don't have a fully functioning NuxtJS, 3 years after composition API. Vue community SUCKS, don't touch it. It looks fine from the outside but things start deteriorating once you go deeper.
A: it doesn't matter. B: it's a pretty standard way to present a video and fireship didn't invent it. Maybe just the most popular example of it in the coding community
@Samuel Mork Bednarz thanks for the support! I am really trying to get away from Fireship's format, but the reality of it is that the format, and especially the intros work for getting views and increase retention.
@@darkee03 Its not a copy "AS-IS" though. Its a very general style, which he is clearly mimicking. Its not an exact copy of anything in the sense that its the same slides or the same content or the same text. Its a general style copy. Which is normal and fine. If you dont think so then you dont know anything about design
@@darkee03 ... Dude. How? In what universe? Is it using images and logos while you talk? Does fireship own that now? What the fuck? Also no, I can't believe I have to clarify this but obviously I'm not an alt account. Jesus Christ. Take your drama to Twitter
@uziboozy We use it professionally through www.shopware.com/en/ which is a framework powering a lot of top ecommerce solutions is Europe. So it is used, but clearly it's not as "professional looking" as Angular or React.
I really like Vue, because of the structure. And even more Quasar.
I'm not familiar with Quasar, but I'll look into it.
@@awesome-coding Quasar is amazing. It's by far one of the best component framework based on VueJS.
Quasar is way to awsome, specially since the CLI came out
Quasar is absolutely fantastic. Real evolution of Vue 'ecosystem'.
They will grow and enhance over time, react, vue, solid, etc. I like all of them.
Fair enough!
Vue is ABSOLUTELY awesome. But it doesn't have the love and support like React yet. I want a UI library that's not Quasar or Material UI.
@Justine Chang I feel like Vue has a more loving and helpful community, while React has way better 3rd party tooling support, which is mostly the result of React being so widely used.
Elementplus!
Prime vue maybe
Vuetify? but I wouldnt go anywhere else, quasar has it all bro
@@guillermomazzari4983 quasar looks pretty dated with Material Design 🫤
Svelte! 💪
I got you! - th-cam.com/video/Gwaz3MFKFOY/w-d-xo.html
There's always the svelte guy... Every single time
😅 Good thing that the JS ecosystem has something for everybody.
Svelte is useless for enterprises because it has no template type checking
@uziboozy in my experience, for real enterprise the only viable solution is Angular, even if I'm not a fan of it. There are so many moving pieces in a 15+ frontend dev team, and it's a pain if you don't have enough senior experienced devs to move things along.
I think that Svelte is great because it brings in new ideas and approaches to the table. If they are sticky enough, the rest of the ecosystem will have no option other than to incorporate them.
Vue is just awesome
Vue3 ❤️
Solid js is also a great framework it has ability to fight react and all popular js frameworks
@Amazon Recommendations - you are right! I'm actually a big fan of Solid, and there are a couple of videos on this topic on my channel.
@@awesome-coding Make more videos on it as it is totally awesome as your channel.
@Amazon Recommendations Thank you for the kind words!
Composition should be detault and less of boilerplate.
I feel the same! However, they might keep both options for legacy purposes. I expect that some Vue core fans are not excited about Composition.
I think options is so much easier to learn that it should be supported as the default option. Composition is great but someone who is new(ish) to js would probably have a hard time wrapping their head around things like refs vs reactive objects, when they just want to render some values. And there's more footguns as well, watchers outside components can leak pretty easily when they aren't tied to the component lifecycle. That thing uncle ben said etc.
@Mihkal Jouste you might be right here. I am sold on Composition probably because my React background. Indeed, the options approach is a more clear approach.
@@awesome-coding I'm not a big fan of composition api altho i understand why it exists. I still would pick option api especially for smaller projects like mid size, I'm still using react and not gonna get back to vue, but i love vue for the directives and lifecycle separation, really similiar to angular, but done much better and simpler
VueJS hit the right sport for me coming from AngularJS it feels like Modern AngularJS and the fact I don't have to fuck up all html css javascript in one file like react.
I have a question: I know it's supposed to be single page app, but let's say if I wanted to embed the app to some CMS, is there a way refer to external css of that CMS within the Vue app? Like... if there were 10 different Vue apps, I wouldn't like to copy css 10 times to Vue Apps and modify them 10 times
@Timo Pitkäranta - This is a pretty standard scenario. You can store the shared css somewhere on your server, say "assets/css/shared.css". Then, inside your Vue app, you can add a tag loading the shared css file via an absolute path.
7:48 you dont have to write props.message.type, they are automatically fetched in template.
Thanks!
Never understand why the time killed for frameworks and which one is the best. U just need to send commands to the backend and observe changes, and with this two things u have deocoupled microfrontends. But If I choose today, I go with AstroJS and SolidJS combo.
Astro + Solid is something near and dear to my heart as well - I'm actually working on a video about just that.
However, I don't think we would have such great libraries / frameworks if there weren't so many library attempts and ideas explored in the past 10 years.
@@awesome-coding I'm old timer when thinking about, if we really need new technologies. If scalable microservices can survive with event streams, why not the frontend? Let's just think how we can decouple two microfrontends? Probably firing some native js events from one micro frontend and the other one listening and subscribing to them. Before we jumped on the bandwagon with SSR, CSR and that jazz, angular already provide that observable pattern, which now solidjs is famous as react but 'fixed'. Now to my point, if service A on the frontend can fire just simple CQRS event, and microservice X do his duty, service B,C,D and every other can subscribe on those events in isolation on the frontend. We need some state? Probably, which is no that as of importance, because we can retry on changes and error in different ways. So in my perspective, the missing part of the JS ecosystem is native rxjs.
sadly they have low native presence
I know Ionic integrates nicely with Vue (ionicframework.com/docs/vue/overview) for hybrid solutions. Or you have something else in mind?
@@awesome-coding I was hopeful about vue-nativescript but alas they were dead on arrival, that was the only competitor to react native imo
@@glowiever check Quasar if you can bare with their insistence on Material UI.
@@greendsnow quasar is not native though, they're hybrids.
Still, React is the king, it's WAY better than any other front framework, very solid primitives that let's you build exactly what you want, I don't have to talk about React server components ^^ million years ahead of its competition, every framework try to break/replace react failed, because react is the best at being simple yet powerful, in react you write JS/TS, in Vue you write Vue, Angular you write Angular.....The only framework worth learning besides react and I believe it's the future is QWIK, why ? because it is different, completely different, no hydration and uses resumability, which they invented, React can pick up the idea but it needs a whole rewrite, but in 5+ years I think a "resumable" framework will be the norm, it is much better in all areas ! but for now it's React
@Aghiles Lounis - Did you get the chance to check out Solid JS? My background is also in React, but I feel like Solid will turn out to be a real alternative to React in the long run.
@@awesome-coding I think Solid is objectively more performant and maybe better overall than React, BUT it’s not sufficient to bypass all the React ecosystem to use Solid, like it’s not necessary for the problem it’s solves, you will only need it for embedded devices where performance need to be maximised, other than that it’s not revolutionary enough to change the state of React, but QWIK framework or similar style with resumability It will change a lot of things and it’s objectively better than what we have now, because you will not hydrate or ship any JavaScript code until you click the thing, then the exact code like a very little portion gets downloaded and executed, with that you will always get 100 score lighthouse, and best performance possible
I like the fact how open and simple react is comparing to others. It has basically 0 learning curve comparing to vue, angular etc until u wont touch react + ts
@Aghiles Lounis - I agree with you. One thing I'd like to see with Qwik though is more concise / clean way of working with the lazy loading resources. The need to wrap various stuff in the $ for QRLs to properly work feels a bit too hackish for me. If they are able to sort out their APIs in next iterations, for certain resumable apps will be a big thing.
@@awesome-coding 100% agree, the api is not very clean, needs a lot of work imo, need to wait future iterations, nether less it’s a good start I would say since they are taking the React style api haha 😁
No it doesn't. It costed me my 1.5 year. After Composition API every library started to fail and they still don't have a fully functioning NuxtJS, 3 years after composition API.
Vue community SUCKS, don't touch it. It looks fine from the outside but things start deteriorating once you go deeper.
Thank you for your input on this - I think it is very valuable.
u just copied a style of "Fireship" TH-cam channel presentation lol.
A: it doesn't matter. B: it's a pretty standard way to present a video and fireship didn't invent it. Maybe just the most popular example of it in the coding community
@Samuel Mork Bednarz thanks for the support! I am really trying to get away from Fireship's format, but the reality of it is that the format, and especially the intros work for getting views and increase retention.
@@darkee03 Its not a copy "AS-IS" though. Its a very general style, which he is clearly mimicking. Its not an exact copy of anything in the sense that its the same slides or the same content or the same text. Its a general style copy. Which is normal and fine. If you dont think so then you dont know anything about design
@@darkee03 ... Dude. How? In what universe? Is it using images and logos while you talk? Does fireship own that now? What the fuck? Also no, I can't believe I have to clarify this but obviously I'm not an alt account. Jesus Christ. Take your drama to Twitter
Fireship doesn't own a patent over a style of presentation. Instead you might have a lack of diversity in your tech news subscriptions.
Vue is pretty much dead nowadays 😂
@uziboozy why do you say that?
Vue is more alive today than it ever has been. So no. You're just wrong
@@samuelmorkbednarzkepler depends on how you interpret "dead". Almost nobody is using Vue professionally. It has become stale 🤣
@uziboozy We use it professionally through www.shopware.com/en/ which is a framework powering a lot of top ecommerce solutions is Europe. So it is used, but clearly it's not as "professional looking" as Angular or React.
@@awesome-coding sure, but nobody in their right mind would choose Vue for a new project, unless it'd be your own project of course.