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.
Not sure why Evan is not being more transparent regarding this renaming.
It would be easy to just say "yes, I got a bit carried away with the naming and my big future plans, but the community reaction made me realise perhaps it was not a great idea"
Insead he's like: "what? it was the plan all along :)"
That's partly my fault. Evan focuses on more technical sides of things but there are people in the team that focus more on the community aspect and we didn't catch that potential naming issue and the whole message that the RFC gives away.
We're all still learning how to work with the RFC documents. We want them to be an important tool for the community but initially, the response from the community was very low. Paradoxically this whole situation made the wider community aware of those RFC documents so hopefully it will go in a good direction. But that initial low response made us believe "oh we have time to sort out things like the phrasing". Turned out it was wrong.
The advice to change the names came from the community and it was a good one. It got support in the core team internal channels and got implemented.
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.
This 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.
With Vue 3 we're introducing tree-shaking of individual Vue features which will get rid of unwanted
The "production" build will ship with the stuff that particular project uses. That means both what they use in their codebase and what Vue uses internally to handle that code.
But there also has to be a way for Vue to understand what the user wants to be in the bundle. This is easier for the users who use the new syntax, where the individual features are explicitly imported.
"This API is so different, shouldn't you rename the project?"
Scroll down in the comment threads here and you'll see this question raised over and over again; I think it's fair to say that it is "frequently asked" and belongs in a FAQ.
Evan I think this is a great experiment. React hooks was an interesting idea and I like how Vue’s approach feels even more reactive (a la observable.com)
There seems to be an overall trend towards more reactivity and I applaud Vue for taking a creative approach to that. Will it stay, and become the da facto paradigm to do webdev? Only time will tell, but I don’t think we should be afraid to experiment with it.
The Vue team have always been excellent stewards of the project. I’m sad to see so much negativity here :(
It kind of reminds me of Meteor's Tracker reactivity system more than react hooks. Since you used to work for Meteor for a short while, how would the 2 compare?
Evan, 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?
First 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/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.
I also appreciate Vue's simple elegance. It is a breath of fresh air, amidst all the dust and commotion of the JavaScript ecosystem's tooling bloat and constant reinvention, that Vue can just be dropped in to ant standard HTML page.
Meteor.js, another project with which you are familiar, started with a similar promise of developer simplicity, but it was subsumed and abandoned in favor of the "Facebook-level scalability for all apps and at all costs" mantra that has swept through the JS community.
Regardless of the nuances of this RFC, please remember the value of simplicity as Vue evolves.
Another article, currently trending on HN, describes how we should strive to reduce cognitive load and simplify the development process:
> A good platform acts as a force multiplier for [development] teams, helping them to focus on core domain functionality through attention to the developer experience, ease of use, simplicity of tooling, and richness of documentation.
> https://techbeacon.com/app-dev-testing/forget-monoliths-vs-m...
In my opinion the old API looks significantly better in every every example here. I really hope you guys figure out a way to better preserve that original simplicity. It was what drew me to Vue as a clear winner in the sea of JS frameworks.
> The people who adopted Vue are the ones who had first rejected the complexity introduced by React
I dont know if that's true, I think react is super easy, but I prefer the template approach of vue. I think a lot of people are just searching for a modern angularjs that's not the monstrosity angular 2+ is.
@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.
This. 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.
Since the majority of the community will probably be using hooks from now on it will be assumed that is the default React methodology which will break books, talks, blog posts, SO answers, etc.
You can mix-and-match. If you want to write an individual component as a class you can, and if you want to later convert it to using hooks there's nothing stopping you.
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?
The point is that you don't have to use it. If you can't be bothered to learn a simple new feature then just keep doing it the old way; your code will still work. I don't even understand the complaint; are they never supposed to change anything? It's totally optional; even if most of the community goes down that direction you don't have to.
Beyond that, hooks are super simple and the complainers are just making a big deal out of nothing. They are just callback functions that you implement outside of a class instead of overloading arbitrary method identifiers like "componentDidUpdate".
That's quite hyperbolic. Functional components have existed in React for a long time, hooks are just adding existing concepts (state and lifecycle operations) to them.
This is what I don't get about hooks. Remembering Markbages great talk on 'Minimal API Surface Area'? How is having multiple ways of doing the same thing minimal API surface area?
React is losing sight of what made it great when it came out. Do one thing, do it well, and do it the simplest way possible.
That sort of absolutist logic will never allow a framework to progress and become better. Sometimes good ideas come around (IMO like hooks) that are worth increasing the API surface area for.
I for one loathe using class components now and not being able to share logic compositionally via hooks when I work with them. I feel more productive and I feel like my components are smaller and more focused, and I don’t repeat myself as much. It’s been a net win for me, and I think it’s well worth having two supported APIs that do roughly the same thing.. because despite this, React is still a small and focused library API-wise.
No rewriting needed. Hooks are just another way to do what was already possible in a more well-defined way. All the content written is still applicable. Now there is just a new way to do things too.
The developers and documentation even advises against rewriting old components with hooks unless you need to.
You're gonna have to learn it eventually to work with other code bases and so on. But the point was it doesn't change existing knowledge, just something new to learn.
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.
As 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.
A 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):
I 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)
I 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.
Yeah. 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.
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.
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.
I'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.
I don't think it's just because the devs get bored. It's because the users crack the shits if their specific use cases aren't handled, and when it comes to 'frameworks' nobody wants to switch or use anything that's not the most popular, so over time they just get more and more bloated trying to handle more use cases.
It's twice as bad if there's financial incentives for having a userbase (see all the tools not owned by FB/Google etc where the contributors sell training etc) because then it literally pays to add as much crap into your library as possible to try and get as many people using it as you can, regardless of the effect it has on quality. Even if something would make more sense as a fork or alternative, it's getting added in, whether it's good for the library and ecosystem or not.
I'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.
I 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?
The class API will remain the current status of an add-on. The idea was that if we make the class API built in to the core, it will somehow be better than now and remove all the issues with it. More and more into the game it was turning out that's not that easy.
Even the decorator thing was problematic. Remember that the core Vue library is supposed to work both with and without build tools, but in case of TypeScript it's not possible. There is a decorator proposal for JavaScript but it works differently than the TypeScript one so there would be a clash.
In the meanwhile we found out a new solution that not only solves these but also some other problems (composability).
I’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.
There 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.
I 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.
Scope creep. It's really hard to say "no" to feature requests, especially if hundreds of people give it thumbs up, but it's a necessity if you want to keep your project from bloating over time.
Yeah I'm not saying it's a positive or negative change. Just an observation. Personally, I'd rename the next version to something else and let Vue be Vue, where Vue was founded as a replacement for the bloated SPA frameworks and super easy to just drop in and use.
This 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.
I'm not sure everyone makes that consideration. I reckon many developers would chuck a JQuery or React dependency in without thinking about whether it is the right thing to do, because they are used to it.
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.
> 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.
The problem with Angular 1 is that it was slow and bloated, relatively speaking. Google could have improved on that instead of starting from scratch, or ok, start from scratch but use a different name.
I don't know. I prototyped with Angular and it just seemed like one of those approaches that sorta made sense verbally but not at all on paper.
Like trying to take jQuery and make it a framework like React. But in their attempt to make it "simple" they made it useless. And then the next generation of frameworks like React came out and basically killed it.
Im still om angularjs. Cant bother to learn new frameworks every other month. Also using Angularjs in recent projects i never ever thought I was hobbled. Angularjs,jquery,vue - doesnt matter which tool one use. If you know any of these at advanced level you can create anything
The initial release was 8 years ago. Surely, you've had at least an ounce of curiosity about how the front-end ecosystem has changed since then? Even if you didn't adopt it, just to maybe poke around and look at what React, Vue, et. al. are up to?
It's not be dismissive of what you currently do. But perhaps you might see new efficiencies that allow you to do more with less, with these newer solutions.
Absolutely; I was a very satisfied user of Angular.js, and if you have a project in it currently, I'm sure it works just fine. But you're also missing out on a whole lot if you're restricted to their now-clumsy module system, their now-clumsy unit testing setup, their custom syntax with no editor support, its limited ability to work with type checking...
All those are fine not to have for an existing project, but they're what make people choose other frameworks (such as Angular 2+) for new projects. Angular.js wouldn't have been as big as regular Angular is today if they'd have kept focusing on that - let alone as big as React.
The page mentions providing a compatibility build:
> “The proposed APIs are all new additions and can theoretically be introduced in a completely backwards compatible way.”
One thing they want to avoid is the whole Python 2 vs 3 distinction that went on forever. I’m not entirely sure these differences are that significant but having to merge in all of the data/computed/watch etc options into a single setup() function would require quite a bit of refactoring.
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.
Making it two separate project means the library authors have to write two separate libraries using two separate API - the more flexible and easier to maintain (written among others with library authors in mind) function API and the object API that they often have to fight against right now.
That would be a huge problem. Right now they can just use the API they want and it will work for all the users regardless if they use objects, functions or classes.
That was overplayed in my opinion by Python 3.2 or so a large percentage of Python 2 code could be made Python 3 code with the addition of: from __future__ import print_function at the top of the file (provided your libraries also went to 3 that is) most people didn't use any of the stuff that was removed.
A few months ago I had to decide between Vue and React/Redux for porting over a very large Angular 1.x app at work (I decided against Angular2+ - mostly because I feel pretty burned by Angular). Seeing this headline made me very glad that I picked React.
Edit: Because my comment will probably age poorly, the old headline used to be: "Vue 3 set to change in a big way – Current Syntax to be deprecated"
While I don't disagree about the fact it will likely cause a split similar to Angular, they seem quite explicit about the reasons (not to scratch the itch of the framework's designers).
For me, working in a large project with TypeScript vs one in vanilla JavaScript makes all the difference in terms of how maintainable it is. The number and the nature of the tests I need to write for such project changes, the IDE tooling available makes development much more pleasant, and I generally feel like it is harder to write code that is buggy, because a large amount of potential errors are avoided through use of the type system.
Whether or not they've made the right decision with this split is a different question that I can't answer.
My quip about scratching the designer’s itch is mostly about the following.
99% of people that got into Vue.js use it because it felt like an anti of the ever changing, dragon chasing JS world.
Changing the syntax will almost certainly yield zero benefits to the folks out in the field running apps for their businesses. They will end up with the same app, with the same functionality, just $100k lighter due to hours burnt on refactoring to the “function based” API.
Everyone roles their eyes and the bad wrap Javascript has continues.
> 99% of people that got into Vue.js use it because it felt like an anti of the ever changing, dragon chasing JS world.
Can't say I agree. Lots of people became aware of vue/seriously evaluated it around the time of the 1.0/2.0 breakage, myself included. Vue IME has caused more breakage than react has, though I would note that React best/common practices have evolved somewhat more radically; it's just that backwards compat has (mostly) been maintained.
I think a better/more common reason why people use it is that vue does a better job than react of forcing a separation of logic/styling/rendering, which react components have a tendency to intermix eventually.
If 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.
I think it cuts both ways. As a sole developer he can push Vue quickly into new directions. It has been part of Vue's success and will be the cause of its downfall.
Vue has a history of rough upgrades, version 1 to 2 wasn't fun.
I 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.
This 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.
> 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.
I 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.
The internal politics at Facebook seem really smart here - the React team have said they’re responsible for keeping all the React code there working and updated when things change with the library. So it’s basically infeasible to make breaking changes that can’t be fixed automatically.
It 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.
Well, I mean, sure; if you're using something now, keep using that. I was mostly responding to the use case of coming to front-end after a year of not doing that. If you're going to "relearn everything", consider React; then that'll hopefully be the last time in the foreseeable future that you'll have to do that.
This 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.
I 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)
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.
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
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.
I've been meaning to start a project with Svelte 3, but I'm not sure what tools to use. Is Sapper ready for v3 or is it still mostly on v2?
I've also somewhat been hoping that Svelte 3 will get TypeScript support so I can have a typed interface between my Svelte frontend and my Rust backend...
Far, far less likely. Svelte has undergone some changes, and will continue to do so, but the latest round of change swung heavily in favor of USING THE LANGUAGE. Most of what you write in Svelte, with some notable exceptions, is vanilla JavaScript.
We in the Svelte world love it so much, it seems highly unlikely there will be any drastic switch from what we've all grown to love. (It's truly fantastic, give it a whirl: https://svelte.dev/repl/hello-world?version=3.5.3)
(Side note: I actually clicked on this link hoping Vue was learning a similar lesson, only to be disappointed.)
Hopefully 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.
Sorry, 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.
There is also, Custom element API section that is "TODO". Yes I saw those options the first time, but woulnd't you say the documentation is limited ;) if such is the case.
So far I see 2 sentences related to the subject, compare that to V2 docs.
I will try to see how svelte performs for this, but so far Vue wc-wrapper seems to be the most promising option out of "non-wc first" ecosystems.
Why 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.
This 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.
I 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.
Hopefully 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
I 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.
Why 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.
This. 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?
So 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?
Breaking 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.
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.
A 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:
Meaning you didn't read the RFC which specially states:
"Is this like Python 3 / Do I have to rewrite all my code?
No. The new API is 100% compatible with current syntax and purely additive. All new additions are contained within the new setup() function. 3.0 standard build will support 2.x options plus the new APIs, but you can optionally use the lean build which drops a number of options while providing a smaller and faster runtime. Details
2.x options compatibility will be kept through the entire 3.x lifecycle."
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.
Single 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.
These 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.
It'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.
Welp, 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.
It'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.)
I 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.
Or 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.
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.
It's moves like this which make me feel good about doubling down on Aurelia - 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.
While 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.
To 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.
I 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"
This 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.
I'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.
> 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.
You'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.
One 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.
Sorry 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.
[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.
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.
I 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).
We 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)
That 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!
No 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.
Python 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.
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.
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...