16 ms·
Vue RFC: Expose logic-related component options via function-based APIs instead
- c487bd62 7y agoI 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.
- intothemild 7y agoI 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.
- HatchedLake721 7y agoTry Ember :-) like a breathe of fresh air in the ever changing JavaScript ecosystem
- BigJono 7y agoI'm almost done with it as well. I can actually handle the churn and the random rewrites, a lot of them have been marked improvements, that doesn't bother me. What bothers me is when things change in ways that make them more complex than they were before, which also happens constantly. Not only that but I'm sick and tired of tool developers pandering to noobs. Nobody should ever be learning to use a library like React before understanding the programming language they're working with. For the React team to come out and say something as stupid as 'classes are too hard', in the context of the sheer wall of accidental complexity around the front end space, is a joke. All the problems with PHP back in the day are going to come back with a vengeance when our new generation of coders that don't understand basic language constructs all graduate to tool making.
- Tade0 7y agoI'm trying to focus on the good parts of it, like: at least our jobs are safe. Anyway do you have a minute to talk about our lord and saviour Rich Harris? https://svelte.dev/ https://svelte.dev/
- lwansbrough 7y agoThis was literally the exact same pitch Vue made when it came out. The developers get bored and add complexity. Don't get your hopes up.
- Tade0 7y agoI'm aware of that - hence the form of my previous comment. "This time it's different" though. The difference being: this here is radically less complex and unlikely to become much more. All this complexity in frameworks was always added in a vicious cycle, namely: 1. Developer looks at a component - they see complexity. 2. They don't know how much of it is due to the business logic being complex and how much is introduced by the framework, which has to deal with the limitations of the platform, so they assume it's the latter. 3. To deal with this they create yet another abstraction and an associated convention, which makes one problem better and a good few others worse. 4. Other developers see the examples and figure that this new method indeed solves that one problem, so they adopt it. 5. The result is ever increasing complexity. Enter Svelte(and similar technologies): it's not a framework, but a compiler - it doesn't have to play by the same rules, so it (eventually) avoids framework-related complexity. It's noticeable in the way how Svelte 3 ditched setState() altogether and replaced it with simple variable assignment.
- Can_Not 7y agoAre there any svelte tutorials/examples that specifically target vuejs users?
- Tade0 7y agoI haven't seen any, but as a relatively early proponent of Vue(as in: I was there when v2 came out), I found Svelte even easier to get into than Vue. Anyway Rich Harris' presentation is a good starting point: https://youtu.be/AdNJ3fydeao https://youtu.be/AdNJ3fydeao
- asark 7y agoIf 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)
- dham 7y agoI don't quite understand this. Since 2013 React has remained a JS framework and introduced 1 new concept(hooks). iOS programming on the other hand(since 2013) has introduced a new language(Swift) and a new paradigm (Swift UI) for writing interfaces. All to target around 25% of the mobile market.
- root_axis 7y agoYeah. It's so annoying how developers open source so much of their work. It's as if they just throw things up on the internet and expect people to use it only if it solves their specific problems. What they fail to consider is how inconvenient it is for their fellow developers who are dazzled by everything that hits front page of HN.
- Romanulus 7y agoI'm glad I've held off for this long... almost time to jump in!
- tannhaeuser 7y agoYou're making the assumption JavaScript frameworks are iterating towards perfection when in reality it's just generational churn. We're still talking about mostly trivial business form apps. Yet they need to be thrown away after 3-5 years because nobody can maintain them, and nobody wants to. Much better to lure young developers with "exciting" (immature) tech.
- mvgmvg 7y agoThat.
- chupa-chups 7y ago@Vue team if anyone should read this: I'd recommend to rename vue in the process (for example vueNG or whatever) in order to reduce the amount of false/outdated information when searching for a topic.
- stesch 7y agoIsn't this half the fun of using JavaScript frameworks?
- jspash 7y agoNo, this is the OTHER half of using them. :/
- IggleSniggle 7y agoAngularJS/Angular split community still have this problem, although less so this year than last.
- julvo 7y agoThis. I like that the Vue team thinks of ways to improve on the current state of the art and welcome new ideas, but please under a different name. It needs to be succinct enough so that search engines can distinguish the two. Otherwise, there is a big risk of things becoming confusing and frustrating quickly.
- pier25 7y agoYes, that's what the React team should have done when they implemented hooks.
- lucidone 7y agoI haven't done front end work for about one year. Looks like I'll be re-learning everything at some point, because this looks like a fairly major change. I'd strongly prefer backwards compatibility over a breaking change.
- noir_lord 7y agoThis change is large enough that’ll be looking at the alternatives after more than two years of defaulting to vue, I mean I may still pick vue but I’ll be looking now where before I wouldn’t have. Change isn’t a bad thing but nor is change for changes sake.
- Vinnl 7y ago> Change isn’t a bad thing but nor is change for changes sake. I can understand that the changes here might not be worth it to some, but to call them "for change's sake" is disingenuous and unfair to the Vue team, I think. The linked page clearly motivates the changes. Whether those motivations weigh strong enough for you is a different matter.
- Vinnl 7y agoI feel like I'm shilling a bit for React over here, but they are nearing two years without major breaking changes, and has been the de facto framework to go to for quite a while now.
- jeremyjh 7y agoIt seems inevitable that hooks will be the only API 3 years from now though, and its already the case that all the new literature and examples are only going to teach hooks. Vue might maintain compatibility just as long but they've totally hosed their messaging on this judging from all the comments in this thread.
- Vinnl 7y agoTrue, though as I said elsewhere: relegating the "old" syntax to a "compatibility build" is giving a strong signal that they will be deprecated soon. But yeah, for now it appears they'll maintain compatibility well enough.
- ng12 7y agoThe more they change Vue the more I wonder why I'm not just using React.
- treelovinhippie 7y agoWell that's enough to reinforce my switch to https://svelte.dev https://svelte.dev I want a JS framework simple enough that even hobbyist devs can understand in an afternoon. React syntax is an overly complicated mess; like reactivity forcing itself onto HTML. Current Vue syntax is neat, simple and clear; like HTML with added reactivity.
- mlevental 7y agobut isn't it likely that svelte will undergo the same scope creep eventually?
- treelovinhippie 7y agoHopefully they recognise their niche and stick to it. I'm particularly interested in Svelte for compiling down to vanilla WebComponents to be used in P2P apps (eg Holochain) where you want the end users to be able to modify components themselves.
- ergo14 7y agoSorry, but seems Rich is not too happy with WC', if you want to do use a compiler to vanilla WC's I think stenciljs might be your best option. LitElement is also good - but it is not a compiler. Svelte V3 doesn't even have custom element section documented at all at the time of the writing.
- TehShrike 7y agoSvelte has supported compiling to custom elements for over a year.
- neximo64 7y agoOh well, Angular is a safer bet.
- Vinnl 7y agoIt's amazing to me that after so many years of being the leading framework due to being the first to introduce a new paradigm (the virtual DOM), React is still "the framework to follow", i.e. again being the first to come up with an innovation (hooks) that spreads like wildfire. And even more amazing that they managed to do so in a backwards-compatible way. (And also: with not that much pressure to adopt it. Having a "Standard" and a "Compatibility" build does result in that pressure.)
- Sir_Cmpwn 7y agoQuick reminder that you can still write complex and useful form-driven web applications with no JavaScript at all.
- tannhaeuser 7y agoThis. I've used React and to my surprise even liked it, but if you have to start all over every 3 years, you've got to ask whether pulling your model ... whatever over to the client is actually worth it in the vast majority of cases. What was wrong with SSR and a bit of jquery and Ajax again?
- Sir_Cmpwn 7y agoNote that I said "no JavaScript at all", not "a bit of jquery and ajax"
- wishinghand 7y agoHow would you get data to change reactively?
- Sir_Cmpwn 7y agoSubmit a form, display updated data on the new page.
- wishinghand 7y agoSo if there's unrelated data on the page that one would want to preserve after getting more data, what are the options? Send it in as a "preservationObject" or something similar and it gets returned and re-interpolated on the new page render? LocalStore? Query Params?
- Sir_Cmpwn 7y agoDon't store state on the client, store it on the server. Or use cookies.
- KukicAdnan 7y agoI always saw VueJS as a successor to AngularJS in that it followed a lot of the same concepts/syntax/etc. that made it really easy to jump into. Now Vue is maturing and becoming more Angular/React like...so it's only a matter of time before another framework comes out that replicates VueJS2/AngularJS in being super easy to jump into and just write code and the cycle repeats.
- iteriteratedone 7y agoAnd nothing new changes. Frontend webdev is musical chairs. This is not engineering, its marketing
- pier25 7y agoSvelte?
- quickthrower2 7y agoEven better avoid using a framework if you can. Vanilla JS is reasonable for a lot of things.
- preommr 7y agoExcept it isn't and it can't. Doing things in vanilla js just means I end up duplicating a lot of the framework code. Vue really was very simple and minimalist. Just pass it your object and it's reactive and very easy to get started. Fairly unobtrusive as well.
- davnicwil 7y agoThis is completely true, but in my opinion there's no overlap of usecases where either one of these frameworks or vanilla js are both reasonable solutions. If you have a usecase that vanilla js is reasonable for, using a framework in the first place was just a plain bad choice, most likely.
- quickthrower2 7y ago
- fopen64 7y agoPlease don't
- avolcano 7y agoI've been following the Vue + TypeScript progress on and off for the past couple years (ever since I converted a React project to Vue and threw out TS in the process, since it was just so fundamentally incompatible with Vue's APIs). This is a pretty wild change compared to the now-abandoned class proposal, and I'm somewhat bummed by it, but I'll admit that's mostly due to my continued skepticism of hooks (as someone who hasn't yet adopted them in my React projects, either). This will require one hell of a migration path to support and I imagine lots of people will be on that "Compatibility Build" for a long time. I'm very, very curious whether folks who have large-scale Vue apps have had a look at this proposal, and if they've had any input on it.
- dmix 7y agoI’m curious what it means for people using single page components and how the default exported module would be structured with the new API. All the examples use the inline template strings. The primary change seems to just be merging most of the keys/options (data, computed, watchers, etc) of the module into various functions within setup() which itself may require from coding best-practice guidelines since setup() is going to get pretty big. I’d love to see a largish component converted to be able to compare the two instead of the small examples with one or two functions within it.
- marcagba 7y agoI've noticed this example of converted component on the RFC discussion: https://gist.github.com/Akryum/6eff23ae9f7483d6b5151c26d18842c2 https://gist.github.com/Akryum/6eff23ae9f7483d6b5151c26d1884...
- Rapzid 7y agoI really disliked the function API and felt the class API with decorators was much easier to read and work on.. I'm pretty sad they are doubling down on function API and, apparently, ditching the class API?
- gustojs 7y ago
- hkt 7y agoChurn in the JavaScript ecosystem you say? What what tally ho pip pip!
- tuesdayrain 7y agoNo one is forced to upgrade. An ecosystem with optional churn is better than an ecosystem that has no churn just because people aren't creating new things for it.
- quickthrower2 7y agoYes I love the Windows 2000 UI, but I guess I'm not forced to update.
- tnolet 7y agoI might be totally and completely wrong, but changing everything does not help anyone except scratch the itch of the framework's designers. I'm pretty sure this is all with the best intentions, but this would be a disaster similar to how Angular suddenly changed everything. Not against change, but the API is fine. Just iterate and evolve it. disclaimer: Big fan of Vue, early user and conference attender..
- evo_9 7y agoCouldn’t agree more, this is the reason I bailed on Angular. Not smart.
- hinkley 7y ago“Yes but I’m only considering Vue because Angular already screwed the last project I used it on” What the hell.
- flukus 7y agoIf I remember correctly it wasn't just that angular broke stuff but also that they no longer supported older versions and the wanted to bump major versions multiple times a year. Breaks are one thing, promising constant instability is quite another.
- cooperadymas 7y agoAngularJS had it's last major release in 2018 and is in LTS from Google until 2021.
- Vinnl 7y ago> this would be a disaster similar to how Angular suddenly changed everything. To be fair to Angular, if they'd stuck with what they had, it'd have faded into obscurity far more than the current version has. Angular.js was great for its time, but lost most of its advantages as the web caught up, and what used to be its advantages started to become kludges.
- tqkxzugoaupvwqr 7y agoMan, this is quite a bummer. It’s basically a new framework to learn. Edit: Might as well give it a completely new name.
- tuesdayrain 7y agoI switched from React to Vue because I didn't like the direction they were going with hooks. Now it looks like Vue is heavily borrowing from the same approach. Slightly upset about that but I guess I'll have to learn the new style. Maybe it will be better in the long run.
- davnicwil 7y ago> the direction they were going with hooks I'd be really interested in your thoughts on this. What about hooks don't you like so much that it made you abandon React?
- boatman_ 7y agoHooks brought me back to react. Everyone is different I guess.
- pier25 7y agoYou could look into other options like Svelte.
- NewsAware 7y agoOr just go with hooks. Obviously there are quite a few pros and cons but for us the reduction in boilerplate led to a net increase in cognitive understandability of our code base so to say.
- mdanger007 7y agoSvelte is really nice because it makes the mundane easy (some say magic) and the tough stuff like reactivity and animation manageable.
- dmix 7y ago> Function-based APIs are exposed as named ES exports and imported on demand. This makes them tree-shakable, and leaves more room for future API additions. Code written with function-based APIs also compresses better than object-or-class-based code, since (with standard minification) function and variable names can be shortened while object/class methods and properties cannot. I don’t yet have an opinion on the wider changes but this is great. Tree-shaking really helps bring down file sizes and I’m not in the camp of “it only loads once and caches” group that disregard file size these days. And not just because that’s no longer true with async component loading depending on the route/page.
- frenchman99 7y agoI hope Vue.js gets some kind of automatic migration tool. Otherwise, I'm not sure how migration would be possible, given the amount of code certain projects have (sometimes without proper testing).
- enlyth 7y agoThe 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.
- draw_down 7y agoCode gets parsed too!
- inopinatus 7y agoVue 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.
- akhilcacharya 7y agoI prefer this because it doesn’t require a build step.
- root_axis 7y agoTrue, but realistically you need some kind of build pipeline for production quality JS anyway so adding it in is pretty painless.
- bfrog 7y agoI'm happy they provide a way of migrating incrementally at least. But I really don't see us migrating any time soon, like possibly years. To give a timeframe, this is the first major rework of this web based UI in nearly a decade. I wish these JS libraries had longer support timelines.
- Philipp__ 7y agoIt's Angular all over again.
- mharroun 7y agoWhy don't they just call it a new framework if its undergoing such a major overhaul. This only makes me feel better about picking react at my current company as now I view this framework as dangerous for building anything long lasting.
- elwayman02 7y agoThe React ecosystem introduces huge breaking changes and paradigm shifts literally all the time... coughreactroutercough
- mharroun 7y agoReactrouter is a 3rd party npm package... the core react framework has been very stable and backwards compatible.
- choward 7y agoThis is one of the things that made me dislike angular. If your are changing the entire API and syntax then it's a new framework. Don't steal the name of an existing framework just to steal the SEO. It's dishonest and makes it harder for users of both frameworks to search.
- drenvuk 7y agoWelp, it's dead to me then. There's a lot of thought seems like it went into the redesign and he(they?) have my respect but I'll be damned if I spend more time learning another js framework, I've already gone through react, angular 1 -> ∞ and vue. This is tiring.
- LastZactionHero 7y agoFINALLY. What took so long? Seemed like we're long overdo for a big syntax change to take up engineering time with no real gain. I should have never left C.
- samhh 7y ago> with no real gain Did you read the linked motivations?
- lwansbrough 7y agoNobody cares what the motivations are if they can’t update their code base without thousands of hours of work.
- samhh 7y agoThis new API is additive and not a breaking change, much like React's addition of hooks.
- wolco 7y agoI did but with no mentions of tradeoffs.
- pier25 7y agoI get your sarcasm, and agree for the most part, but there are some benefits like TS support.
- lone_haxx0r 7y agoThere is a theory which states that if ever anyone discovers exactly what a JavaScript framework is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable.
- hohohmm 7y agoadams is a visionary :P
- pier25 7y agoI used to be a huge Vue proponent for about 3 years and stopped using it at the end of 2018. I moved to Inferno + MobX because the cognitive overhead is practically nil. You can architecture your application and specially your state in any way you wish since your reactive data is made of objects, classes, or whatever you want to use. MobX also makes your React/Inferno components much more enjoyable. No need to use setState() anymore since your component state is reactive much like Vue or Svelte do. After using that for a while and coming back to an old Vue/Vuex project I realized how many conventions and ad-hoc abstractions it has which was quite oppressive. A couple of weeks ago I discovered mobx-jsx[1] which is pretty interesting. It's a very thin rendering library that compiles JSX to imperative DOM instructions and relies on MobX for tracking state changes which makes the virtual dom irrelevant. It adds loops and conditionals which IMO are the biggest annoyances of using JSX. This is probably what I'll be moving on in future projects. (Actually what converts JSX to DOM instructions is a babel plugin from the same author) [1] https://github.com/ryansolid/mobx-jsx https://github.com/ryansolid/mobx-jsx
- simonw 7y agoClasses really seem to have gone out of fashion in JavaScript land these days.
- ehutch79 7y agoIt's important to note that this is an RFC for 3.x, and they seem to want to provide it for a 2.x revision, and provide a compatibility build, so it's not like angular 2+ where there's no real migration path. If you have comments, this is where to tell the vue team: https://github.com/vuejs/rfcs/pull/42 https://github.com/vuejs/rfcs/pull/42
- lwansbrough 7y agoPython 3 vibes. Terrible decision. Our team has decided after seeing this to use Vue 2.x until we can move away from Vue. Extremely disappointed. Simplicity was Vue’s bread and butter. Literally the only reason to use it over React. Now what’s the point? We get it, you’re a smart guy who likes FP, quit punishing the rest of us.
- AngeloAnolin 7y agoBreaking 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 products faster yet being simple enough to allow for easy scalability & enhancements. With these upcoming enhancements, I hope that it wouldn’t introduce major changes that would require for me to rewrite large portions of my applications. I have a lot of trust and confidence with Evan and the Vue Community and I guess all these changes are in line with best practices and better productivity rather than following a path because another framework is doing things like that.
- Androider 7y agoI 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.
- scns 7y agoI think Abramov said they habe over 38000 components at facebook, which is enough reason for Thema to keep backwards compatibility.
- acemarke 7y agoA lot more than that - roughly 100K now. Shawn Wang collected comments from the React team over time showing the growth of React's usage inside Facebook: https://www.reddit.com/r/reactjs/comments/btx9nq/reacts_growth_rate_in_facebook_some_datapoints/ https://www.reddit.com/r/reactjs/comments/btx9nq/reacts_grow...
- tohagan 7y ago
- superasn 7y agoHopefully 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)
- k__ 7y agoYes, this sounds like Vue admits defeat by React :/
- Can_Not 7y agoI think it's inevitable that if EvanYou does betray us, we really could just have a community fork of 2 and 3. You can see the support exists in this thread, and let's be honest here, VueJS seems pretty good and complete as is anyways.
- ehutch79 7y agoEvan You is responding to comments on twitter https://twitter.com/youyuxi/status/1137567675356291072 https://twitter.com/youyuxi/status/1137567675356291072
- mrieck 7y agoWhy not release a completely different framework if things are changing so much? Here's a rule for framework creators... if your framework is changing more than jQuery has in its entire 13 years of existence, save everybody the pain/frustration and just start a new framework.
- Androider 7y agoNot 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.
- Roboprog 7y agoOutput encoding Js template strings insert any text as is, rather than encoding HTML special characters to avoid injection exploits
- Can_Not 7y agoSingle File Components are converted to functions at build time (not run time) and that's the syntax for "string interpolation, but the variable is not trusted html". This protects against html injection.
- karmakaze 7y agoIf it's going to break compatibility anyway, go big. I would welcome something like what Svelte did for v3.
- seancoleman 7y agoIt seems like a distant dream where Evan You promised 99% syntax backwards compatibility: https://medium.com/the-vue-point/plans-for-the-next-iteration-of-vue-js-777ffea6fabf https://medium.com/the-vue-point/plans-for-the-next-iteratio.... About a year ago, my team rebuilt a large solar power plant prediction modeling Angular 1 application with Vue.js 2.0. It was the only big bang rewrite I've heard of that was a massive success. I work in Vue.js everyday and swear by it. Mr. Evan You, don't do this to us.
- hjvedvik 7y agoThe new Function-based API is not replacing the current syntax. You will still be able to use your components in v3.
- numbsafari 7y agoI personally feel like I need some time to play with this in the context of my own projects before truly passing judgement. My initial reaction “seriously, wtf?” Personally, for me, if Vue can remain the simple, compact, non-dependency hell that is React, I’ll take whatever they do. My big question is how does this approach scale, and does it need a more fleshed out set of helpers, a la the mappers they have in the current API. Won’t really know until I work with it. Would also love to see how this approach works into, for example, Vuex.
- numbsafari 7y agoAlso, this seems like the kind of change that would greatly benefit from some automatic code rewriting tools a la go.
- Roboprog 7y agoSorry about the breaking changes, but glad “this” will be going away. Thinking about transitioning (from AngularJS) to Vue, but prefer FP to OOP, and I’m glad that these new value wrapper things can be passed or used as partially applied arguments, as well as the other functional composition support changes.
- deleted 7y ago[deleted]
- agronick 7y agoThis isn't what I signed up for. I wanted the class api. This is spaghetti garbage. One god function that returns 47 variable wrappers because we can't make the number 4 reactive. And we'll put .value after everything.
- mekoka 7y agoMixed feelings. I decided to pick up front-end JavaScript a year ago and chose Vue. Although I'm a fan of that specific framework, one thing that I found annoying about the ecosystem (and the great JavaScript family in general) is the "unsteadiness". When I go on StackOverflow and look at questions related to, say, Flask and I see answers dated 2012, I have a sense that although Python has mostly migrated to version 3 now, the answers that I get are likely still relevant today. It's not because Flask has always made the right design choices. But the maintainers stick to their decisions, because people have already invested time to learn to do stuff that way. It's not the best approach, it's not the worst either. You just learn it like this and when you have a problem, you ask on StackOverflow and someone will tell you what hoops to jump through. You'll scratch your head for a minute, but then be on your way to get shit done. When I look for an answers related to Vue, everything seems to have an expiry date attached to it. Anything dated 2017 raises flags in my mind. Things seem in a constant state of flux. It's like trying to learn to walk on quicksand. I saw the list of improvements/simplifications/deprecation. Not bad. If Vue was a fresh new framework these changes might have had more value, but it's not. A lot of time and efforts have already been invested to learn to do things the Vue 1 way and the Vue 2 way (not to count the accessory libraries and tooling). So I don't know if after tallying up all the pros and cons (which go beyond the technical concerns listed in the specs) whether this change might actually be more costly than helpful.
- deleted 7y ago[deleted]
- rk06 7y agothis is a javascript problem, not vue problem. Because of libraries are working around javascript's limitation, it is inevitable that they will be as fast and ever-changing as js and js ecosystem is
- avinium 7y agoTo be honest, I don't actually mind these changes. Grouping all exposed members together makes for a cleaner API and the functional style makes reuse a lot easier, so that should trim down code length. But.....that's not a sufficiently compelling reason to change. Even with backwards compatibility, it still adds confusion to the mix, requires a huge effort in new/updating documentation, etc. I can't really see how the benefits justify the effort.
- hardwaresofton 7y agoBefore you lament this move (and it's similarity to hooks/increase in complexity for questionable gain), check out John Lindquist's talk on Proxies: https://www.youtube.com/watch?v=95haj8RqR5o https://www.youtube.com/watch?v=95haj8RqR5o This is what Vue 3 is using -- Proxy support enables really easy and natively supported observables (as well as enabling a bunch of other crazy stuff), and it's actually pretty impressive. I think the reactivity system is Vue's biggest wart -- I've been surprised by it way more than I would expect. I strongly dislike the complexity react seems to encourage, I'm not a fan of hooks, but I am coming around to seeing this as a way that Vue gets closer to KnockoutJS -- not as a way that it gets closer to react. Knockout had the simplest reactivity model you could ask for -- make an observable object and you're done -- it's observable, no surprises, very predictable interactions/behavior. I'm choosing to think of this as Vue going in this direction, although by more complicated means (Proxy vs a simple souped up observable wrapper). That said, at this point I feel it's up to Vue to bungle my high opinion of the project -- they made it this far by being the simplest component frontend library with the best features, and the day they stop being that I'll be moving on. Already warming up to MithrilJS in my own projects, it's wonderfully minimal, performant, and light.
- jcadam 7y agoAs a "full-stack" developer I just don't have the time to follow the JS circus as closely as a dedicated front-end dev would. I switched from Backbone to Mithril a few years back (major improvement to my productivity) and I see no reason to go through the effort of learning a new framework again. But if I had to find a new framework for some reason, I'd probably go with Vue.
- hardwaresofton 7y agoA very reasonable stance -- congratulations on getting lucky (unless it was the result of tons of research) and picking Mithril after jumping from Backbone (+Marionette I assume). There were a lot of wrong, but good-looking choices to make there. In case it wasn't clear, I still think Vue is the best minimal component library all things considered -- simple syntax, simple and mostly clear usage, support for typescript, not too much overbearing tooling (they're trying to "fix" this with vue-cli though), and a large community & ecosystem. I'm just scared they're going to blow it and start putting in , but I'm well aware I'm just a hanger-on to the project (I don't contribute to it). Mithril[0], on the other hand is almost allergic to change, in the linux kernel way, which is great until you have a problem with how it works or think it should work differently. Mithril is also the most complete though -- it has routing, AJAX, all that stuff built in (context: normally when people say "vue/react" they mean "vue/react + vue/react-router + vuex/flux"). I also particularly like how Mithril uses the hyperscript syntax and just calls it a day -- full "single file components" without the transpilation hassle. Mithril also passes one of the key indicators for high quality software, a comparisons page[1]. Shameless plug -- I wrote a short guide[2] on how to get started with mithril & parcelJS (ignore the link URL, I started with rollup and then quit because it was too inconvenient to use, I write about it in Step 5): [0]: https://mithril.js.org/ https://mithril.js.org/ [1]: https://mithril.js.org/framework-comparison.html https://mithril.js.org/framework-comparison.html [2]: https://vadosware.io/post/mithril-systemjs-and-rollup-getting-started-guide/ https://vadosware.io/post/mithril-systemjs-and-rollup-gettin...
- jstewartmobile 7y agoThat everyone on HN seems to be unanimously shitting on it, I am now certain that Evan is going 100% THE right way with this, and am super-stoked about trying it out!
- EvanYou 7y agoVue team lead here. There is a lot of FUD in this thread so we need to clarify a bit: - This API is purely additive to 2.x and doesn't break anything. - 3.0 will have a standard build which adds this API on top of 2.x API, and an opt-in "lean build" which drops a number of 2.x APIs for a smaller and faster runtime. - This is an open RFC, which means it's not set in stone. The whole point of having an RFC is so that users can voice their opinions. It's not like we are shipping this tomorrow. For more details, we added a Q&A section at the top of the RFC to avoid further confusions: https://github.com/vuejs/rfcs/blob/function-apis/active-rfcs/0000-function-api.md#high-level-qa https://github.com/vuejs/rfcs/blob/function-apis/active-rfcs...
- karaokeyoga 7y agoI just wanted to point out a significant change made to the above document today. Earlier today, there was a "Standard" build and a "Compatibility" build. The "Standard" build excluded support for "data", "computed", "methods", "watch", "provide/inject", "mixins", "extends", and all lifecycle hooks. In the updated document, the old "Compatibility" build became the "Standard" build, and the old "Standard" build became the "Lean" build.
- dessant 7y ago> Compatibility That's a clue for where the Vue team's mind is regarding the current API. Compatibility to me reads like legacy. That's in contrast with the claims above that this is just a new optional API to serve a broader range of use cases.
- gustojs 7y agoThis is a phrasing issue. In the team we use the compatibility word all the time in the "it's a good feature proposal but what about compatibility" context. For us this word had a positive conotation and we missed the fact that it can be treated in a different way. That's a good lesson for the future.
- swyx 7y ago
- abacadaba 7y agoEh, it was either this or wait till everyone switched to another implementation of 'vue with hooks' or react.
- lwansbrough 7y agoEvan, although the proposal as it stands indicates that these changes are slated as optional for Vue 3, the longer term focus is unclear. It looks like the set up to a bait and switch in Vue 4. Here's the problem: when Vue was released, people jumped on board because its design was incredibly simple when compared to React, which at the time was heavily focused on the functional, performance based approach to UI development (and to this day, still is.) If you've got a team that's super focused on performance and loves FP, React is always going to be the better choice. Facebook continues to invest heavily into performance improvements. I can appreciate that you guys care about performance too, but you're now stepping on the toes of the guys who really only care about that one thing. Performance is not the selling point of Vue, nor is functional programming or any of the other weird changes that have been introduced in this RFC. Nobody looked at Vue and was like, "wow, thank god Vue is 2ms faster than React when you render this benchmark component a thousand times." The people who adopted Vue are the ones who had first rejected the complexity introduced by React. And now your team is saying "well, this approach is for more advanced users" -- what an insult, honestly. Many of us had the foresight to recognize that the complexity introduced in React was not worth it for our teams, or we had already experienced the problems that such complexity introduces, and we chose Vue because it managed in general to be as effective as React without the fuss. What Vue 3 seems to be is an answer to the question: how can we beat React at its own game? And congratulations if you've done it, but that's not what your users are here for. That's not what we pitched to our teams, our bosses, our stakeholders, etc. My question to you is: honestly, how am I supposed to manage this? The long term answer seems to be that I have to change my code base to this new syntax (beyond or during Vue 3), at which point I'll be right back where I started when I decided to leave React for Vue. Do you think this is fair to ask of your users? Are you sure this is what we want?
- EvanYou 7y agoFirst of all, this new API has relatively little to do with performance. The main performance gain in Vue 3 comes from a new template compilation strategy invisible to users. Second, I think it is over-simplifying the issue by equaling the new API with Complexity. The RFC can be tough to grok because it is dense; but actually looking at some examples will probably show you that the new API really isn't about "complexity": https://gist.github.com/yyx990803/762ec427882a61be3e4affe02f8af555 https://gist.github.com/yyx990803/762ec427882a61be3e4affe02f... Vue has a wide range of users. I honestly don't quite get how introducing an optional API can be an insult - because we clearly see some use cases we ran into can be more elegantly solved with the new API. Maybe you haven't run into them personally, but that doesn't mean your use case is "inferior" - we are all dealing with different types of applications. However, I think it would be a real insult if you think Vue will never have a use case that is complex enough to warrant these advanced APIs. Regarding your question: feel free to stay with the current API for as long as you wish. As long as the community feels there's a need for the old API to stay, it will stay. The only one that can make the decision to switch to the new API is yourself.
- DigitalSea 7y agoIt's moves like this which make me feel good about doubling down on Aurelia - https://aurelia.io https://aurelia.io and forgoing the latest trend frameworks and libraries that many seem to jump on and use because they're popular. I was disappointed when I saw Evan and Vue jumping on the "classes are bad, functions are good" bandwagon. There is a lot of misinformation out there about classes in Javascript. If you use them without inheritance (like Aurelia promotes) they're really useful and great. I also admire the fact that Aurelia itself has never had a major breaking change in syntax, I've got Aurelia apps that have been running since 2015 without issue. I think this undoubtedly means that Vue's private prototype they've been working on will be thrown out and they'll be starting from scratch again, which means Vue 3 probably won't be out for at least another year or more. If Evan and the team proceed with these proposed changes, it'll be the end of Vue.
- luismartinezs 7y agoI welcome the added flexibility of this new syntax. This eases encapsulation of related logic within the same block of code, instead of having it spread over different Vue directives. Plus, at a glance, it seems very easy to pick up and very intuitive. I also appreciate that you stay away from "javascript classes"
- hinkley 7y ago// expose bindings on render context return { count, plusOne, increment } No, this here is why you want classes. On a large project you are going to have multiple people touching contiguous code. This block is going to have several pages of code between it and half of the declarations and that kind of ping pong is no big deal for a limited percentage of the Dev population but is NOT trivial for everyone else. There’s a difference between having a problem and admitting you have a problem and lots of devs trip up on code constructs like this on a regular basis. It’s double data entry and that is bad. It also hamstrings editors, adding friction to discoverability. All things I shouldn’t have to explain to a framework writer but constantly find myself having to soapbox.
- Devasta 7y agoWhile I can appreciate its their project and they can do what ye want, at least have the fortitude to admit the 2.x API is depreciated. Please, no nonsense about compatibility builds, anyone who uses one of those might as well accept becoming this generations VB6 devs. We don't all work as freelance webdevs or in some startup. I work in a bloated, slow, soulless financial services firm; depreciating now or depreciating in 3-4 years as part of Vue 4 time might as well mean you're depreciating next week; it'd be the height of irresponsibility for me to use Vue for a new project knowing I would need to refactor everything, I'm going to have enough code to rewrite as a result of this as it is.
- okso 7y agoOne of the best features of Vue 2 is how declarative components are. The syntax proposed here is much more imperative, making it more difficult to read and understand components.
- lewisjoe 7y agoThese API improvements (aka potential situation to refactor code within the next 3 - 4 years max) is why I think compile-time frameworks are going to win eventually. People want to build UI. They don't want to migrate from function components to class components. They don't want to migrate from mixins to HOC. They don't want to migrate from Hooks, to whatever comes next. They just want to build UI by writing code once such that it stays performant and maintainable for as long as possible. Now is a good time to switch to Svelte / Elm / Whatever. Something that helps me declare my UI layout and behavior with a minimal API, but has a deeper understanding of my intentions. Such that, whatever that is better is eventually a compiler advancement - not an userland API change.
- moogly 7y agoWe have a (currently) 50-60KLOC SPA that, in the past 8 years, has survived migrations from a homegrown backbone+jquery-based MVC framework into angularjs (starting from v0.9), then to componentised angularjs v1.5 with webpack and TypeScript, to a heavily deangularised (but still based on v1.7) app where we've removed all useless DI (it didn't even help testing) and made all angular services into pure ES6 (well, in TypeScript) classes imported as modules, with Jest and TS transpilation via Babel. We also have our own Redux/Vuex-inspired uni-directional state management solution that uses immer under the hood. The next step, largely motivated by the fact it's hard to find developers who want to work with older frameworks, is to convert the app into Vue from the inside-out using ng-vue as glue, and when all components are Vue, remove the outer angular shell. So we have been tracking these proposals. The original class-based RFC looked perfect for us, since that was 95% matching how our current (class-based) components look like. Seeing it get abandoned was a cold shower, but okay, not the biggest problem. Our components are as dumb as possible anyway, and we have all business logic in services. It'll just be some additional manual text-wrangling work. The new proposal looks okay. I guess, just as React hooks made classes unusable in React, they had to go from Vue as well (though honestly, I don't really see the fascination with hooks, but maybe that's because we don't do anything like the Hooks examples I've seen in our app). I do really like the idea of the reactivity system being completely separate from the rest of the framework. I personally never liked the original JS-only API either, with the { props:, methods:, computed:, } etc. "separation" (commenters here call it "simple", but I think it's far from that), so in my Vue 2.x projects I used vue-class-component. Overall, the motivations and reasoning in this RFC seem sound to me. However, here I come to my three biggest problems I have with this API: 1) The fact that you have to return the render props from the setup() function. It's annoying repetition, and I foresee people forgetting to add a newly added prop here. It also makes the definition of the component feel procedural instead of declarative. You have to read/mentally run the setup function to know the shape of the component. Hopefully maybe you can notate the setup() function return type to match a TS interface without breaking editor support? 2) The fact that they couldn't come up with a better-looking way to declare a prop with a complex TS type other than `prop: (null as any) as PropType<SomeComplexType>`. I guess I could make a noop generic helper function for this, though. 3) props are optional per default. I feel this is the completely wrong default for a TS project (mentioned as a consideration in the RFC though)
- adevx 7y agoThis is painful. I am finalizing a 4 month migration to Typescript using the now abandoned Vue class based decorator approach (including Vuex Decorators) Even though the migration probably is a 50% split between frontend and backend, it looks like a lot of time has been wasted.
- gustojs 7y agoI'm sorry to hear that. The class API will still stay with us though, even the current plugin solution will work better thanks to Vue internals rewritten to TypeScript. It won't be as good as the function API, but during the works on a native class API we realized there are problems with classes API that even a native solution wouldn't solve.
- adevx 7y agoThanks, I guess it's a bit early for me to jump to conclusions. I'll just have to wait and see what you guys come up with :-)
- gustojs 7y agoOne of the biggest advantages of the function API is the flexibility it gives for the library authors, making them more powerful and much easier to maintain, so instead of fighting against the API they will be able to focus on new fancy features, better documentation or community support. This gain will be visible for all Vue developers regardless of which API they use because we all want to have the best quality libraries in our ecosystem.
- tohagan 7y ago[I have no affiliation with the Vue team .. just a happy user] IMHO, composition functions are an elegantly simple and well thought through addition to Vue brought about by a good consultative process. I think this demonstrates that Vue is in good hands with intelligent and wise counsel steering the ship. This small change is nothing like the Angular v1 => V2 experience! No one is breaking backward compatibility!! Vue is all about coding simplicity ... and although reading through this RFC is at times heavier reading (meaning Evan's team thought through this addition very thoroughly), the final outcome is not! It's uses syntax that is very similar to existing Vue components so if you needed to refactor existing larger components into smaller composition functions, the coding experience is fast and would feel very natural and familiar with minimal to learn. No one is forcing this additional on you ... its just there if you needed it. So please before getting spun up on any further misinformation in this thread please read the RFC from Evan You or this very thorough explanation of the RFC which has some nice coding examples. - https://dev.to/danielelkington/vue-s-darkest-day-3fgh https://dev.to/danielelkington/vue-s-darkest-day-3fgh Is it just React Hooks? ... here's a Comparison - https://github.com/vuejs/rfcs/blob/function-apis/active-rfcs/0000-function-api.md#comparison-with-react-hooks https://github.com/vuejs/rfcs/blob/function-apis/active-rfcs... My personal journey I've coded Angular/Ionic, ExtJS & Sencha Touch, Knockout/jQuery in the past. Learning Vue was nothing like learning and keeping up with these! I was highly productive in Vue in 3 days and the learning curve and documentation was much simpler and lighter so more time to stay focused on the code. I've refactored a legacy boostrap/jQuery web site into nice Vue components in a few hours (impossible with the others!). I'm absolutely loving the super productive Quasar Framework built on Vue 2.x/3.x which now delivers 130 components, directives and boot plugins with builders for ALL platforms: Web or SPAs (Desktop & Mobile), PWAs, SSR, SSR + PWA, Cordova iOS/Android mobile, Desktop/Electron and dream documentation. - Check it out: https://quasar.dev https://quasar.dev
- lukaszkups 7y agoI've written a blog post with my own feelings about it (hopes and fears included ;) ) - feel free to check it out: https://lukaszkups.net/notes/do-we-have-to-be-afraid-because-of-latest-vuejs-rfc/ https://lukaszkups.net/notes/do-we-have-to-be-afraid-because...
- malvikus 7y agoI proposed new Scoped Mixins API (only basic draft ideas), could you looks at this and give feedback - https://github.com/vuejs/rfcs/issues/60 https://github.com/vuejs/rfcs/issues/60