Not a Vue programmer, but looking at the code, why is the example code using {{ count }} instead of standard JS interpolation like ${count}, and using an App.template block instead of just returning the template with the count and other params. E.g. why not just make it plain JS, and minimize framework surface? I could rewrite that example removing almost all of the "Vueisms", and it wouldn't be a single line longer.
Vue RFC: Expose logic-related component options via function-based APIs instead
101–110 of 253 posts
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#102Hopefully history will repeat itself and some clever dev will fork Vue 2.0 and create a new framework which has all the good parts of Vue 2 and nothing from this react inspired Vue 3 and all would be good again (just like Evan did when Angular went rogue)
Yes, this sounds like Vue admits defeat by React :/
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#103Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#104Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#105Earlier quoted context omitted.
How? It's still perfectly valid, usable, idiomatic React.
If you learned React with hooks the class notation won't make sense, and viceversa.
So they should have renamed the whole framework when they added a single a new feature so people know they need to learn it before reading the examples?
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#106The whole html template is one long string literal. I prefer JSX, where the XML is treated as code rather than a long string that needs to be parsed.
Vue already supports templates written in JSX/functional style. I very much doubt this goes away. Template syntax is not the topic of this RFC, and where it does touch rendering, it retains the option of render functions.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#107Earlier quoted context omitted.
Maybe just call it Nue.js or something
I don’t see how changing the name helps over a version number. This is changing the syntax for setting up components, somewhat similar to the class API difference, but it’s still fundamentally the same library. It’s largely just moving functions store on the root object into the setup() function while using a more function-y tree-shaking supporting style. It’d probably cause as much confusion as it helps.
Because it's essentially a different project at that point. All stackoverflow answers become confusing instead of helpful for example.
Rust went through that around version 1 where a massive number of answers were updated to match new release and many got "this is not how it works anymore" comments.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#108Breaking changes such as this makes me rethink what could be the best approach with regards to front end development. I can recall the time when I moved past Angular when they introduced so many breaking change on their next version. I started using React but was not comfortable enough to keep pace with its progression. Then I found Vue which was a breath of fresh air as this framework has allowed me to deliver end p…
I have a 100K+ LOC project in React started in 2015 that's going strong, and I imagine Facebook has much, much bigger projects than that using React. I can't recall a single time during all these years that something would have broken in a non-backwards compatible way. We're on the latest version of React, writing class-based components (with zero intent to move to hooks) and feeling very good about it.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#109I guess that's my cue to leave front-end programming forever, and my current job (I'm not joking). I've been through too many cycles and it will never end. There's no way I'm staying for whatever crazy migration my company is going to go through again. And we have apps written in every single JS framework ever conceived. Time to learn COBOL.
I just left frontend, and I’m the maintainer for express-vue. Vue is great in its current iteration. But the whole JS ecosystem is just horrible right now. Looking at these changes, it’s not for the better.
Re: Vue RFC: Expose logic-related component options via function-based APIs instead
#110I guess that's my cue to leave front-end programming forever, and my current job (I'm not joking). I've been through too many cycles and it will never end. There's no way I'm staying for whatever crazy migration my company is going to go through again. And we have apps written in every single JS framework ever conceived. Time to learn COBOL.
If you don't hate front-end period now, mobile's a hell of a lot easier and I think it still pays better than front-end webdev for some reason. As long as you stay away from the web-tech-on-mobile crap and write actual native code. It's especially easier if you specialize in one of the Big Two, but even working on both isn't that bad. I mean, it's not JS "culture" bad.
iOS is far and away the saner of the two if you wanna pick just one, plus it's an easy gateway to the whole Apple family of devices (watch, TV) including, soon, macOS itself. Android's broadly less pleasant and any devices outside phones that happen to be running it are likely to be batshit insane to work on, but it's still way better than the web, and a ton better than it was back in the 4.x days (let alone the 2.x/3.x split days—oof, it was hot garbage back then)