been told that the push for Composition API is the biggest blunder of maintainers so far, and quite a good reason to leave the framework, albeit with some tears
@mnjammnjamm would you agree to what you’ve been told? 👀 IMO the CAPI was a good decision even though „adding it“ was a major change for the ecosystem and users (and still is)
Amazing video! And I totally agree with your opinion. Composition API is the way to go, for all the reasons, though it's less intuitive design wise compared to options api. That's why I'd like some more videos about some design patterns and architectures, like the one you made about inline composables, that was really helpful.
Thanks for your feedback Ali! Then I can definitely recommend one of the latest DejaVue episodes where Michael and I talk about more Design Patterns in Vue! ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-nxb_cthLg1k.html
Thank you so much 🙏🏻 The best way to avoid that is sharing the video with your peers of course! 🙊 And comments like these + becoming a member also keep me going as well as paying the bills 🔥
Hello Alex, I never comment you RU-vid except it really helped me. Your videos are great! Even after 4 years of Nuxt development, especially in Nuxt 3 I learned some things from you. Great video and well structured, you come to the point and I do not need to skip a hundred times to get to the important part. I love your work here!
Thank you so much Maurice 🙏🏻 I highly appreciated that you took the time and effort to comment and am really glad that my videos help you and are "on point" 👏🏻💚 If you have a specific topic request, please let me know! ☺️
@@TheAlexLichter Indeed I would have 2 cool or interesting topics. What I see often people struggling with (new Nuxt.js programmers) is the distinction between client and server side authentication and authorization. Maybe a video to that and how to handle the Nuxt client, as well the server middleware to make your API calls secure and not only rely on client based auth and permission check. A real deep dive. The 2nd: A short overview of an example app of Nuxt 3 + Supabase, with Self Hosting Coolify on a server your choise (gcl, aws or digitalocean). This is mighty and I am gonna use that on a big production project soon, as Netlify was sadly not an option anymore for us on this specific project. Cheers, Maurice
Thanks for the requests! Auth is definitely on the list but needs a bit more research/work. Example app with that stack might be the case for a future project 👍🏻 First have to finish my association manager though
I appreciate very much the argument, and I believe I must be wrong since everyone in authority in the Vue and Nuxt communities is gung-ho on Composition API, but the important part of the argument here regarding structure seems unpersuasive. Why should having a big stonking app mean that you have big stonking components? Doesn't this gainsay the very notion of components? If a component gets too big and stonking then I break it down into smaller child components and pass and emit values. Another non-argument seems to be composables being better than mixins, but composables work fine in Options API (in Nuxt at least, that's what I use). The annoyance that is "this." in OAPI is a strong point, though I'd argue it comes up less often than ".value" does in CAPI (though is harder to reason about). The community momentum is obviously with CAPI (Nuxt 3 docs don't even mention OAPI) but I really don't want that to be why I go for it - I want to want it, otherwise I'm fighting a headwind day-to-day instead of enjoying a tailwind. My one hope re converting to CAPI is that components I do make using it feel shockingly concise, even if I can't understand them when I look at them...
I get to know vue directly with the composition API and love it easy to understand and follow, and after I get work in a project using options API and although I did understand how it works it just didn't feel right i5 was like something was missing😅 So I keep with composition API and if I need to use something that is options then just adapt it if possible😊
Brother, I have been working with vue since version 2.1.17 and the truth is that this API composition is great, it helps me to modulate my applications better, so I do have a doubt because nuxt did think about modules because its folders are not modular but well the framewrok I think it's great, greetings and success.
Have a look at Nuxt layers! That’s the modularity you want for Nuxt ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-fr5yo3aVkfA.htmlsi=D3aqItMg-0IFAhuj
Even if there is no customer value added, I think it is still a smart move to rewrite your components to composition. First of all because you learn something, removing some potential technical depth and you help your future colleagues/self. With Copilot it's done very quickly anyway ;).
From a dev perspective definitely a good thing to learn. But from a business-perspective, there are often more important tasks. And new components can always be started in CAPI 😊
I switched to Composition API when it was possible. The Options API was ok as a start and my first Vue / Nuxt projects were also quite small. But when you work on larger projects that you maintain and expand for a long time, you need a flexible API. I mean, who wants to work with mixins or renderless components to share logic these days? Nuxt layers are the logical further development of the flexible concept.
Mixins were the straw that broke the camel's back for me. I was happy with options api until I had to start using a few mixins around the place. The torture that are mixins is what drove me to composition api.
Недавно смотрела сериал "Во все тяжкие" (Breaking Bad). В нем были серии под названием "Полумера" и "Полная мера". Попытки документации усидеть на двух стульях, в начале предлагать изучить "Options Api" и отказываться признавать его устаревшим, по моему мнению, вредят vue. --------- I recently watched the TV series Breaking Bad. It had series called "Half Measure" and "Full Measure". Attempts by the documentation to sit on two chairs, at the beginning to offer to study the "Options Api" and refuse to recognize it as outdated, in my opinion, harm vue.
hey, can You make a guide on how to create a full stack application with a database (e.g. mySQL) using Nuxt and Nitro? I would like to start using Nitro, but it is not very popular and it is difficult to find good guides
Not planning a full guide but definitely looking into db0 in an upcoming video! Until then, I am *building* a project on stream / via VOD which is a real-life one using NuxtHub (SQLite DB, Storage etc. etc.) @ ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-mPYIgr95mQw.html
I was actually surprised how many people still prefer the Options API! The Reddit posts are really interesting to read on that note. And I still think for learning/getting into Vue it is the best way (but you need both APIs in any case IMO)
@@TheAlexLichter Hmm that is pretty interesting! I started in Vue2 with options before moving to composition so maybe I am bias haha. Although, I feel like if I learned Vue today the composition API would be way more intuitive than the options API.
