I've been using Vue since late 2014 and I'm a huge fan of how it's evolved. My day job is pretty much as a full time Vue consultant at this point, so I owe a lot to the project as a whole.
I think the Vue team are a really great example of how to maintain a widely adopted open source project whilst keeping almost the entire user base happy. Steady improvements with a focus on backwards compatibility, easy migration between versions and a lot of consulting with the community. The new composition API had a little backlash when it was proposed, but it seemed like the benefits were well communicated and the community came round. Personally I love all the changes in version 3 so far.
I'm hoping the new composition API will make adopting Vue an even easier choice for larger projects, I think the benefits are obvious. I admit I do have a slightly vested interest in increased adoption though.
Congrats to the Vue team on getting this to RC stage!
Yes. It's a split really. I was lucky enough that when I quit my job to go solo, some clients I'd worked with previously got in touch directly after my non-compete clause expired. Other work I've found through friends. I also do some contracting if I see a something come up online that's Vue specific. I live relatively frugally so I can usually afford to be picky with the contracts I go for.
> Start by running the migration helper on a current project. We’ve carefully minified and compressed a senior Vue dev into a simple command line interface. Whenever they recognize an obsolete feature, they’ll let you know, offer suggestions, and provide links to more info.
Vue's docs are a masterclass in docs-writing, imho. Clear. Concise. Empathetic. Written for humans.
Although this may be controversial, the composition API feels very derivative of React hooks. I liked having Vue around as an alternative to React, and the declarative and predictable structure of components felt like the main selling point to me.
With this new API, my first impression is “just use React at this point”. I’m having serious trouble understanding why they’d make this change. Of course I may be biased working in React day to day, but... bleh, Vue used to be unique.
It _is_ derivative of React hooks... but that's not a bad thing at all. (And to be clear, I'm deeply involved in the React community myself).
Tools and libraries are always influenced by what's going on in the ecosystem. New features and concepts in Tool A inspire something else in Tool B, etc.
The React team came up with something reasonably novel with the hooks API (but with its own set of prior art [0]). There are several aspects to hooks that folks have expressed concerns about, but overall adoption has been positive and rapid.
The Vue team looked at React hooks, saw something that seemed like it could be useful for Vue's API, but came up with their own spin on the idea that makes them better fit the Vue use cases and design philosophy.
I don't see any of this as a problem - sharing ideas and improving DX is a _good_ thing.
My main problem with Vue 3 was succinctly summarized in the RFC:
"More Flexibility Requires More Discipline
Many users have pointed out that while the Composition API provides more flexibility in code organization, it also requires more discipline from the developer to "do it right". Some worry that the API will lead to spaghetti code in inexperienced hands. In other words, while the Composition API raises the upper bound of code quality, it also lowers the lower bound. We agree with that to a certain extent."
Vue 3 has committed several cardinal sins of software projects:
1) Splitting the API, allowing several different ways of doing the same thing. Call it "basic" and "advanced". Every developer thinks they're smart enough to use the advanced method, and egocentric devs will shame others to do it that way because it's "better" (this is already happening). This is a community killer.
2) Most orgs don't have the discipline required to keep code from turning into a mess if a library or API will let them. Time constraints, miscommunications, refactoring gone wrong, and general ignorance or outright stupidity always rears their ugly heads. If Vue 3 was a gun, it'd be a shotgun fired at your foot in an enclosed space.
3) Fad chasing. Emulating React hooks was a premature decision. Hooks are a hack (and it is a hack, without any question) to help some of React's more painful points. It's not a general solution. Trying to emulate that function-first way of doing things (fighting against JavaScript to do it) isn't something Vue needed to do, and just makes Vue seem like a React-clone instead of a project in its own right.
If you can point to one specific thing you are most interested in, or happy to check out, from vue 3, what would it be? And what's the closest another framework (or vanilla js) has to said feature?
The new Composition API for components is a simpler, more imperative, low-level way of defining components compared to the older Options API that required exporting an object with fields like 'data', 'computed', or 'watch'.
I personally prefer the older API since its more declarative, but I can see how the new API can help to keep reactivity logic in a single function, rather than across computed properties, watchers, etc. (not to mention the annoyance of having to remember what type each property should export -- function returning object? raw object? object with function fields?).
For me, it would be the Composition API. I think it will clean a lot of code I have. I'm not too familiar with other competitive frameworks unfortunately. I chose VueJS for my personal projects because it felt easier to learn.
So, I haven't done front-end work since jQuery was the thing back in ~2007-2011, but I have a new web project coming up. I already know I need to learn all the fancy new JS syntax. I also don't have/use npm (https://medium.com/@mattholt/its-2019-and-i-still-make-websi...).
Should I learn Vue?
(Edit: Thanks for the reply -- to clarify, I'll be working on a web app.)
Depends on the project. I'd recommend it for an app, as opposed to a website, or a large site, like a custom blog meant for multiple authors or a custom wiki.
I use it professionally and due to my involvement with a Javascript meetup, I'm regularly exposed to Angular and React examples and I'm shocked at how convoluted they can be.
Angular team member here. We're working on simplifying the Angular learning journey.
Generally, lots of the examples out there use very expressive APIs coming from RxJS. They could be very powerful, but at the same time may look convoluted to folks unfamiliar with the semantics.
I can recommend you checking out https://angular.io/start. We did a few iterations on the materials and tried to introduce the concepts from the framework gradually.
Something you could notice is that Angular encourages the best practices from the beginning, such as TypeScript, testability, etc. Based on my observations, this may make the learning journey a little steeper at first, but starting with (and learning) good practices is always worth it.
I am well versed with React and have limited experience with Angular.
I reason I got to explore Angular, initially, was because of the following points, hammered around the internet in the myriad of "Angular Vs. React" articles.
1. Angular is a full framework, while React is just the front end library.
2. Eventually you will have to use state management libraries, Routing, etc in React. Angular provides it from the get go.
3. With React, you have an infinite number of choices of libraries for state, routing, etc. Hence, it can become confusing, while Angular is a full framework with preset libraries, and hence is more coherent.
However, In practicality, I experienced the following.
1. Angular is a full framework, implies, there is a lot more to learn. Now, don't get me wrong, when you complete on complex project in Angular and React, at the end of the project, if you count the hours of learning, it will probably be same for both. However, because React is paced out, it's easier to get started and make an MVP.
2. I absolutely hated the NgModule system in Angular. Maybe I am mistaken, but Angular purports to gather related code into Modules, which are not JS modules. The benefit touted is clean separation, better organization, easier to find code, etc. However, I found the Module system to be overly complicated and an additional cognitive overhead, to what is already a cognitive burden of developing in Typescript.
3. The infinite number of libraries, stack choices, etc argument for React does not actually hold much water.
(a) Redux / MobX are two libraries that are popular and complete enough to meet the requirements of 99% of the projects out there.
(b) React-Router is usually the router choice.
(c) Axios for REST communication.
Now, there are other libraries, which may be better. However, if you stick to the stack above, you have just as many tutorials, videos, articles, etc to help you with development.
For all these reasons, I found React to be a better alternative.
Note that the concepts behind these stacks is identical. The implementations are slightly different. However, if you are sound conceptually, these frameworks become a minuscule part of your app. Your focus would squarely be on app architecture than framework stuff.
If it's something that has quite a bit of complexity, then Vue and React will be close, though once you incorporate React's router and state management I think Vue wins soundly. Angular is a distant third.
In addition to having better 1st party coherence, Vue has fewer footguns than React.
However it's a different paradigm than HTML/PHP templates with some Jquery click handlers thrown in.
Angular team member here. I'm curious what's the source of your data that Angular is a distant third?
I understand there are a lot of data points to consider. In terms of usage, based on our metrics this is incorrect, but of course, that highly depends on your dataset that's why I'm curious.
Not a distant third in terms of usage, but how simple it is to use. I'd think Vue is probably the distant third in how much it's used, but it's impossible to truly know these things.
As for my judgement of modern Angular as complex, there's a few things I'd like to point out:
- separation of CSS, JS, and templating into separate files. This makes it harder for the mind to keep everything in place rather than just scrolling
- defining routes in a global file but also in modules.
- providers, services, modules, etc
To be fair, Angular is so much more than React and Vue, which just parse templates and add some features. I feel like I'm not spouting a hot take, I feel like it's earned. If Angular wants to seem more approachable, the team has a way to go.
You should check out vue. You don't need npm. Just one js file. There are many css fw that integrate with it as well as ui component libraries. The learning curve is small, almost non-existent if you've done anything with angular. React and its ecosystem would be the other option. I would skip angular.
Either because of logistical limitations, or programming limitations, or throughput limitations, or user load limitations, or even if the program you want to build is beyond what Vue was designed for.
Say, if I want to build a large website like a Salesforce web application, or a warehouse fulfillment and inventory management system, or something of this nature. Where it has a lot of web pages, and different processes to handle different calculations, and what not. And it ties into some back end database of course.
Can Vue handle such a level of complexity? Or is Vue better suited to handling smaller sized apps, with smaller quantities of users?
There's lots of ways to configure the project but you can setup lazy loading routes, components, and stores so that your user only has loaded what they need. Typescript support is OK, there's some helper libraries that make it better. All of those things make scaling just fine.
does the disparity of react code in the wild vs. vue affect the quality of code produced by GPT-3? unfortunately, i still don't have access so this assumption was made in the hope someone would offer the right answer.
unfortunately, i don't have access to GPT-3 yet so didn't know if the number of react samples in the wild offered an advantage over producing vue code.
GPT-3 is some new neural net or something like that from OpenAI that you can "train" a little. Someone trained it with examples of text descriptions -> react code and then was able to make more complex apps with it. That's about all I know though, not sure why GP cares about it in the context of React vs Vue
I think the Vue team are a really great example of how to maintain a widely adopted open source project whilst keeping almost the entire user base happy. Steady improvements with a focus on backwards compatibility, easy migration between versions and a lot of consulting with the community. The new composition API had a little backlash when it was proposed, but it seemed like the benefits were well communicated and the community came round. Personally I love all the changes in version 3 so far.
I'm hoping the new composition API will make adopting Vue an even easier choice for larger projects, I think the benefits are obvious. I admit I do have a slightly vested interest in increased adoption though.
Congrats to the Vue team on getting this to RC stage!