Vue: We no longer have any plan of deprecating the Object API (opens in new tab)

> After reading deeper it looks like the "lean" version of the library with full tree-shaking stuff is taking a backseat and they hope to provide some better library reduction in the future :/

That's a bit of a shame. I know it's a bit more work, but I wonder if they could have added in a switch where the compiler knows whether its object syntax vs function component syntax where the tree shaking is expected.

I also am. I love the simplicity of vue api, but I hate vue-cli, webpack(it is good because it's configurable and extensible, but it's overwhelmingly complex, all the output formats are a pain to debug, I have never seen sourcemaps work in chrome developer tools) and single file components.

That led me to create my own architecture to scaffold vue apps, which Evan You seems to hate.

https://github.com/vuejs/vue/issues/8106

In this comment, I showcased some production apps running with this:

https://github.com/vuejs/vue/issues/8106#issuecomment-386064...

https://github.com/vuejs/vue/pull/8807

I have improved this architecture even further in new apps, but I hadn't time yet to update the "vue-generator" boilerplate.

I am. I wrote a bang-simple extensible blogging system several months ago using Vue.

I started very, very simple. I ended up with multi-component files. No vue-cli. Three files. A few hundred lines of code.

Works fine. Never had to touch it again.

I am on a reasonably sized project (which I didn't start but took over).

It's just an easier better way to enhance existing server rendered pages to include responsive elements without needing all the single page/routing stuff nor dealing with mass of jQuery binds and hand rolled data stores.

And best part is, Vue plays quite nicely with jQuery so can still use existing libraries and elements.

I am using it that way an app I wrote for our company. I do have a custom bundler that will make a minified file for production environment but it just runs the source files through “terser”.

Sometimes all I need is data binding.

And Rivets.js seems to be defunct.

I started writing a huge post with examples from the RFC and how I'd like things to look, but it became too involved and large, and no one wants to read that crap. I'll just summarise it with that props are problematic, both the old-school ones (which don't use TypeScript types at all, instead uses its own ad-hoc type system `{type: ..., required: ..., defaultValue: ...})` and the rather horrible `(null as any) as PropType<{ msg: string }>` type annotations for complex types and the "TypeScript-only Props Typing" which is better but does not have a way to set default values that I can see. Oh, also all props are optional per default which is not what you want in a `--strict` TypeScript project (which should be any new project).

Generally it's relying strictly on type inference instead of interface declarations, which might make edit-time type safety work OK, but lack in error messages (spewing out complex inferred type definitions) and overall readability (much more easier to reason about an interface you wrote yourself).

Also, everything inside the setup function are just variables and functions, so your editor will colour/highlight everything the same, whereas in the class proposal, you have clearer separation between properties (props/data), getters (computeds), methods and even static methods. It's just less messy. Now, I get that classes don't work with React hooks, and the other reasons for dropping classes are rather sound, but I really think that whole setup "God" function is a massive eyesore. TypeScript isn't only about correct type inference, it's also about improved ergonomics, readability, and, pardon the pun, less typing (on a keyboard).

I guess I wrote too much again...