As a beginner to Vue.js development I doubt I'd really need to worry about following best practices, but it was good to skim through that information just to see what lies down the road. Likewise, I didn't expect to get very much out of the "Extra Topics" section of Vue.js documentation but I skimmed through it anyway to see what I can pick up. More than I thought I would, actually!

I haven't done enough web development to understand all of the scenarios outlined in "Ways of Using Vue" but I do understand several of them. And I think I understood enough of the rest to recognize situations if they should come up in a "Ah, that's what document was talking about" way. The overarching lesson is that: Vue is happy to work in several different shapes and sizes.

I enjoyed getting a look under the hood with "Reactivity in Depth". I don't understand enough about JavaScript proxies to use it in my own code, but it was good to see some of the benefits and pitfalls of working within Vue's usage of the mechanism. It mostly boils down to the fact a proxy is one level of indirection from the real object. Unfortunately, one of the downsides appears to be that additional effort must be made to make sure TypeScript understands data types through this layer of indirection.

Coming from a background of strongly-typed languages like C, I was not a fan of the free-form chaos freedom of JavaScript. Using TypeScript imposes some order to the madness, and I appreciate that. Vue.js itself was written with TypeScript and supports TypeScript Vue.js application code, but doing so wasn't as straightforward as I had thought it might be. This is especially true of the simpler Options API, partly because JavaScript usage was so simple that additional effort to be TypeScript-friendly seems like a huge imposition. In contrast, Composition API takes more effort to write but it also resembles "normal" code more so TypeScript was a better fit. After reading through TypeScript sections and "Composition API FAQ" I wonder if I'd be better off focusing on the more powerful and TypeScript-friendly Composition API for my own Vue.js projects. I'll push that decision off to later.

The "Rendering Mechanism" and "Render Functions and JSX" sections were a look under a hood of a different part of Vue.js: outputting Vue.js component data into HTML markup for the browser. I'm not as familiar with this problem space, so I didn't understand all the problems solved by these approaches. I don't foresee myself writing custom rendering functions, and hopefully I won't have to debug standard rendering functions.

I enjoyed seeing some of the fun things possible with CSS animations in "Animation Techniques" but that's further off in the future. I would want to get a functional understanding of building Vue.js applications before I worry about visual polish, and I would lean on libraries before I start fiddling with details for myself.

Speaking of the future, I appreciated "Vue and Web Components" because it addressed one of my open questions: how much of frameworks like Angular or Vue will remain relevant in the future as web standards evolve? Many of web development frameworks arose to solve problems people had with browser-supported standards. These fed into evolution of web standards and eventually, browsers incorporated those lessons rendering many web tools no longer relevant. This "Vue and Web Components" section explained how it's not a conflict, at least today. Vue has features not yet on the roadmap for standardized web components. Furthermore: peaceful coexistance is possible: Vue components can be self-contained into a standard web component for use elsewhere, and Vue applications can consume standard web components. This is encouraging, and it'll be interesting to see this situation evolve in the future. For now, I'm going to wrap up this Vue.js learning session.