Vue is the only one of the most popular 3 frameworks that can easily be used on a minimal basis to sort of "spruce up" old applications by selectively adding it here and there in the templates.
Seems like they should try more marketing and community outreach toward that end.
Gradual adoption is a feature / selling point not many web development frameworks can claim.
You can do the same thing with React though, you can arbitrarily render a React root anywhere, and an arbitrary number of times on the same page.
For instance, I work on an app that was originally written in Backbone / Marionette, but I was able to write generic connectors to allow us to drop in React at any point in the tree. Similarly, we can go back to Marionette / Backbone at any point in the tree. It's made gradually migration towards React possible.
Claiming React can't do the same sort of sprucing up as Vue is just a lack of imagination. Show me an old app, and I'll show you how to do it.
> you can arbitrarily render a React root anywhere
I think this exact capability is what led to such strong React adoption. It's almost viral within an application. The main application that I worked on a few years ago was on Backbone / Marionette and we evaluated React by writing several small but complicated nested components, with state controlled by existing mechanisms. After liking both the flux application architecture and the ease of gradual transition, we pulled the trigger on React. It slowly ate our application from the inside out, but never forced our hand.
React isn't "lightweight" (JSX being the primary hurdle), but it is very easy to adopt incrementally!
Why is Jsx a hurdle? Because you need a transpiler?
I find it the other way. Vue has a big learning curve. Learning their special directives and double binding gotchas takes a while.
While jsx is a very thin layer for existing Js. All control flow is good ol js. The tags just translate to createElement/h calls. React (class based React) was easy to pick up.
React is a quite bit more all-in than Vue though. For example, an old app I'm aware of has HTML generated by JSP with its own convoluted maven build process and uses a mix of AngularJS and jQuery to hydrate client-side functionality on top of it. The development workflow is a draconian exercise in acrobatics through remote desktops and VPNs in really old laptops (because "security" and unions).
Vue has similar hydration capabilities as Angular, but with React, you are pretty much forced to describe the view from scratch in JSX. To make things more fun, many islands need to be aware of each other, something that is not super idiomatic in React land.
I don't know if "from scratch" is really a fair statement. React accepts HTML in the render function, so the only thing you'd need to do is modify the variables to match JSX's variable syntax, which is exactly what you'd have to do with Vue.
I think it's all pretty much the same deal. You might argue Vue's template syntax is closer to HTML than JSX is, but that doesn't really feel like the major issue when slowly refactoring a large application.
I'm not talking syntax. I'm saying that vue can be added on top of a third party DOM that may have server-rendered data embedded in it. You cannot hydrate React on top of dynamic HTML that was generated with JSP/PHP/.NET/etc unless you a) give up JSX (a big departure from idiomatic React) and b) interpolate server variables into your JS (a no-no in pretty much every non-SPA framework)
For example, take a rails app, then do the equivalent of $('#foo').toggle() based on some condition. In React, AFAIK you can't unless React knows what the markup being toggled is somehow. Vue can do it without knowing anything about the markup inside, and more importantly, the code will look idiomatic.
> and more importantly, the code will look idiomatic.
That's the kicker.
Whether a thing is possible or not is a far cry from whether it's a good idea. And when you consider what someone who opens up the code 5-7 years later without any frame of reference to start from will think (which can just as well include the original author if the original author has moved on to other things), familiar syntax goes a long way.
Yeah I don't know about all that. We sunset it now but about a year ago we enhanced an AngularJS (1.x) with Typescript and React. It was pretty easy using r2a [1]. It was pretty much an angularjs 1 app for the most part. Then we had like 5 React tags that we built more complex components that used our GraphQL layer natively. It was pretty easy too because all we had to do was typically pass one or two arguments to them, then the r2a'd tag did the rest - all react code from there. There's also a2r [2] for anyone that needs the opposite
>you are pretty much forced to describe the view from scratch in JSX.
That's just not true, I've just finished working on a client project creating a migration scaffold between react and angular-js - like someone mentioned above, there are libraries to support communication and embedding both ways.
This is also just plain false you aren’t shipping jsx and react doesn’t depend on anything but there being a stable host DOM node. It’s literally the other way around, vue uses global registration making it the only one of the three frameworks likely to give you any issue at all https://vuejs.org/v2/guide/components-registration.html
The JSX point boils down to this: you can't say with a straight face that using react without writing JSX is as idiomatic as pulling vue from a CDN, and you can't say that using JSX is as easy to setup on a legacy codebase.
React doesn't depend solely on there being a stable host DOM node. It also generally assumes data is programmatically structured. Try rendering FAQs as HTML with PHP then sprinkling answer toggling functionality with React and you'll see it's not straightforward at all; it would require refactoring backend code into a REST API or similar. With vue, add v-if and you are done.
Nobody's saying vue doesn't have faults; it has plenty of them. Let's not get all fanboyish when someone points out a legit con in react.
Not true. In fact, the first page of the react guide shows setting it up with jsx entirely in the browser. You also include babel via cdn and you‘re done.
Look, I gave a challenge to implement FAQ page answer toggling on top of legacy PHP HTML. Show me that it's possible to do it in react in a not god awful hacky way without refactoring the backend first, then explain how it's comparable to a vue one using v-ifs, then we can knock off ourselves out debating semantics.
You don't have to refactor much I think. You can inject the data into global scope in your PHP template, before you include React script. I'd do something like `window.__PAGE_DATA__ = "<?php echo json_encode($data) ?>";`.
Then, in your React code you'll be able to access it in a pretty idiomatic way for React. Instead of calling `fetch` or something similar, you'll have to call `JSON.parse(window.__PAGE_DATA__)`. You have to use `try`/`catch` block around it as well to handle errors from JSON parsing - just like you have to have the same block around `await` calls. You can treat the data as immutable to a degree as well - accidental local property updates will not get to the global scope, you'll have to set the property in `window` object.
I've used React in a few projects, embedding it into a Wordpress website using this approach. Seems to work well for me, but YMMV.
In vue, you don't even touch the data, you just sprinkle an attribute on the existing html to augment functionality much like you'd do unobtrusive js w/ jquery.
The approach you mentioned sort of works but a) it does require refactoring backend code (which by itself may already be a non-starter depending on whether you're dealing w/ a "old guard" backend tech lead, for example) b) it opens up potential security holes if implemented as you describe, c) you might lose SEO visibility and/or fail more catastrophically (i.e. a js exception might blank out the page entirely, vs merely breaking toggling), etc.
A more nitpicky code reviewer might also question the usage of babel off of a CDN if you went with a no-build JSX approach, the usage of window, etc.
By comparison, the vue snippet would be trivial, "production worthy" and it handles all the things above correctly.
> In vue, you don't even touch the data, you just sprinkle an attribute on the existing html to augment functionality much like you'd do unobtrusive js w/ jquery.
I don't have a lot of experience with Vue, but I don't follow. You include Vue.js from CDN in a `script` tag, and then just add the `v-for` and `v-if` annotations to your HTML? How does Vue get the data, to properly iterate over it in `v-for` or check in `v-if`?
I'm really curious because I feel I'm missing some piece of puzzle here.
I think the idea is that the backend already iterates over the data and spits out for example a ul with a li per faq item. You edit the template the backend uses so that the vue annotations are also produced, which in theory is easier than changing the backend code.
EDIT:
Previous HTML outputted by for loop in backend template:
I think I know how to code a faq I use react to create a tool for humans to help autonomous vehicles with react. Jsx has nothing to do with how easy it is to embed react in a host app. If you want to compare build systems, VueJS is also less practical and robust without its optional build system. This was used as a reason angularJS v1 would kill react and it’s a tired argument IMO
You are shifting goalposts. Obviously every framework is "similar" enough if your baseline is "can I ship something with it". Heck, there are production apps out there written in choo and hyperapp and mithril. They all work just fine.
The argument here is that there is a substantial difference of effort required for a specific subset of project types (migrations from large non-SPA).
And for the record, all the vdom libs I mentioned are on the same boat as react, because it's an inherent trait of vdom based architectures.
I'm the author of one of them, and while I can't speak about others, I can say that I was ok with requiring simultaneous migrations from server rendered templates to REST APIs for scratching my itch, even though I was aware of DOM-first systems (angular 1, knockout, vue and intercooler are examples of those)
Contrary to popular belief, a framework is not required to be perfectly suitable for every scenario under the sun. And that's fine, nobody needs to get all defensive over it.
People will respond saying you "can do this with React, too". But in practice it's not nearly as nice to do as with Vue. You need React and React DOM AND JSX to really make it practical; writing React render functions is not really what you want to do when you are adding some simple functionality to an existing web app (like form validation).
> simple functionality to an existing web app (like form validation)
If all you are doing is adding a simple form validation to an existing web app, then you only need few lines of plain JS. You don't have to use vue either.
Agree with this sentiment. I was in web dev since pre-jQuery/Backbone, but left during the rise of the js-framework wars. I then returned to this area as I needed to add functionality/"spruce up" a web app within my organization and randomly chose Vue for the task. It went smoothly and didn't require re-writing anything.
Meanwhile the web development team are still fighting with the flagship "all-or-nothing" angular app, still stuck on 1.7 because anything else is an entire rewrite.
i'm afraid this is pretty much plain wrong. react and svelte also support incremental adoption, and i dont know angular but i'd hazard there's a way to do it too if you bothered to ask angular devs.
what you're responding to is marketing, which Vue has done an effective job of. thats fine, but it is unfair of you to conclude "Gradual adoption is a feature / selling point not many web development frameworks can claim."
I think the original commenter might have intended to mean without additional build tooling?
While it isn't pretty, you can drop Vue in a <script> tag on a page and define components with template strings.
In React, you can technically do this, but you need to either:
A. Use React.createElement() calls
B. Use something like "htm" also included via a <script> tag, with template literal tags to wrap your component renders
You can technically include Babel in a <script> tag to use JSX, but it only works with <script> blocks that have been tagged as "JSX", not within regular ".js" files you can import using "src="
Jason Miller a-la Preact is the person I see most consistently working on and pushing this sort of React/Preact no-build setup. I definitely get the appeal, for this exact usecase -- you have a simple, mostly-static website (or something old and built with jQuery) and you want to incrementally modernize it/add functionality without rewriting the whole thing.
Look, I've used both Vue and React for this purpose and Vue is just easier to integrate. React can do it too, but Vue places an emphasis on it and it shows.
as someone who has used both Vue and React in a _very_ legacy system, I can say unequivocally that Vue was massively easier to integrate into our system than React was.
For one, it's not the only one. And instead of just talking earnestly about a cool feature of Vue in a Vue thread, to say nothing of other frameworks, you've now anchored the convo to framework comparison with your incorrect premise.
I wouldn't say this is the main selling point of Vue. For me Vue is superior exactly in the opposite scenario: when one has to build a complex SPA. State management, routing, and the like is all well integrated in the Vue ecosystem whereas, for example, in the React world it's a pita. I like React's simplicity, but I cannot deal with any of its complementary libraries for state management.
I'm not sure about React's capability with this, but Vue can very easily run with no build stage. You can load Vue from a CDN and use a couple lines of JS to point it at a DOM element in your app. Then you can write a plain JS Vue object (what goes inside the <script> tags in a .vue file), and all this logic will apply inside the element you pointed it at. You can also write components, although that gets a little clunky without a build stage.
This has allowed me to do things like create Vue-based tools in a locked-down corporate environment where I was not able to install Nodejs on my machine.
React can be run from a single file from a CDN, and used without a build stage. Only catch is you don't get JSX. While by today's standard some people might consider that unacceptable, it was a fairly common way to use it when it was new (because relatively fewer teams used builds for JS back then, and JSX was far from being widely accepted).
My first year of React development was without JSX even though we DID have a build step (I was categorically against it at the time. Things changed, haha).
I mean, using Babel in the browser is essentially a build step. Your code isn't executed as is and has to be preprocessed. It's huge and slow. Not particularly viable. If your goal is just to play around, sure, but the point the Vue folks are making is that they can do the same in a way that is production friendly (maybe not scalable, but still production viable). This isn't.
I find it amusing that you are allowed to run arbitrary Javascript but can't run NodeJS on your machine. Sometimes corporate security can be a theatre.
I wish we couldn't run NodeJS, then the front end devs wouldn't run this monstrosity that takes ages to start, downloads GBs of dependencies, consumes 12 cores for minutes at a time, etc.
I find this attitude towards front-end developers unamuzing. If you have a beef with subset of developers in your workplace that happen to to work on the front-end, you should not take your frustration or generalize their behavior over an entire industry.
I think it's that JS has no standard library, so dependency graphs are an endless fan-out instead of fanning back in after a while. That's how you end up with 900 dependencies after importing a single Node module, because every author of every upstream lib chose a different way of doing the same thing.
To add to this the Node ecosystem seems somehow to encourage outsourcing extremely simple pieces of functionality (leftpad anyone?) so you end up including a bunch of crap that you don't really need, all because someone didn't feel like using 10 lines to reimplement something simple.
Javascript has a standard library... intended for the language's actual use case, which is lightweight scripting and DOM manipulation within the browser. It's not a deficit of the language that some startup decided to pretend JS was the new C++ and that an insane and byzantine ecosystem developed around the attempt to force Javascript to be something it was never intended to be, and make it seem more "enterprise."
Endless dependency graphs and single-function modules and left-pads weren't a problem back in the days of JQuery and sane libraries. None of this madness is necessary. No, not even for front-end frameworks. It's unnecessary in the vast majority of cases.
If they don't trust Google, Microsoft, and Apple to keep Javascript in the browser sandbox-jail then they're gonna be re-inventing an awful lot of wheels ;).
That's cool- but unless you're targeting greenfield browsers only you aren't going to use the syntax in that documentation without a build step or using the babel transpiler directly in the browser which, while cool from a POC standpoint, isn't a good solution. At that point you might as well just add build tools and use JSX or whatever the framework you're trying to use intended or otherwise is well documented.
I suppose it could, but there are annoyances with JSX defaults.
For instance, Vue provides a method to explicitly declare your template variable delimiter syntax. Last time I looked this was requested of React, but not implemented, someone correct me if I'm wrong on that and it has come along in the last year or two. So.. lets say you wanna put some modern Javascript in some Django templates to make them look spiffy. With Vue you can just declare your delimiter to be `[[` instead of `{{`, (because `{{` conflicts with Django's template variable syntax) with a one-liner setting.
I'm sure you could do this in React with a custom parser function (or maybe there's a third party library?) but it's a lot easier when the framework just gives such things to you out of the box.
If I do this all over the place and some other guy comes along years from now with no documentation on what he's getting into, he doesn't need to know too much to figure out what's going on and work on it. Right away he'll see "delimiter = [[" at the top of the script block in a template and can grep double brackets in the whole project to get an overview of what's being done.
React doesn't have templates, so that's a non-issue. JSX is sugar on JavaScript, but it's not a string. So template delimiters don't matter (that is, if you didn't use a build step, then it would be straight javascript functions calls)
That’s the whole point of the discussion: Vue makes it easier to have Django spit out <tr @click=doThing>My data here</tr> and then Vue notices and adds the event listeners. In React, it is very difficult if React has to start with foreign template output because it wants to own the (V)DOM.
For sure! I was just pointing out that discussing how easy Vue made it to change the delimiter ala Mustache isn't exactly a benefit vs React, since the whole concept doesn't reall exist there at all.
React and Vue can both be used directly with script tags, however the biggest difference is that React uses JSX while Vue uses HTML templates (but also supports JSX).
99% of the time, HTML is easier and faster to write, with the built-in directives providing all the functionality you need. More importantly though, HTML can be generated by every single server-side framework, and this makes it very easy to have server-side code from any language stack that becomes interactive using a Vue client-side layer.
That's exactly right and this is a much underrated capability and I think it's the point being missed by those saying "well if you do XXX you can include React with a script tag too!"
Having said that, React is normally used with JSX syntax, which requires a compile step.
You _can_ use it with "raw" `React.createElement()` calls, but that's generally unwieldy and almost no one does that.
However, there's a very neat library called https://github.com/developit/htm , which is an almost-JSX-compatible syntax that uses JS template literal strings, and requires no compile step.
React can also be used with just script tags. It uses a compiler to turn JSX into a render function (the same as Vue which accepts JSX or HTML) and these compilers are written in JS and can run in the browser. Also modern browsers are much better at supporting JS modules which makes it easier to include other libraries.
I already integrated vue-router, and am currently on the process of fully integrating Vue server renderer. I already have a basic usage implemented, where the home page is compiled to a html string, but I still need to make it easy to compile all pages and to implement client-side component hydration.
There is no need to run NodeJS in production with React. In fact, React doesn’t even require a fancy build system (though for anything more than a toy app you’re tempting fate.)
You can do this with Angular. Just create a component, insert the compiled script tag, and then you can reference it in the html like: <my-component />
You may want to look at projects like preact-habitat, stimulus, and web components (a la polymer). Vue isn't the only game in town for this functionality.
Not trying to hurt any feelings here, but as far as I can see as an unbiased person who's looked at far too many frameworks for their own good, the FUD is coming from the React fans.
I'm seeing a bunch of commenters getting defensive and saying "well technically" while conveniently ignoring the difference in effort required to do islands in each framework. You can't say dropping JSX is at all comparable to plopping in v-clicks on existing HTML.
You can certainly adopt react "incrementally", in the sense that you can implement an entire new self-contained feature and plop it into an existing app if it already uses REST APIs, but react is decidedly not as trivial to sprinkle into a non-SPA where data comes mixed with HTML rendered on the server.
Saying React can do it is a fact. So React devs are not spreading any FUD whatsoever.
Saying React can't do it, to paraphrase you, because "technically it's harder than with Vue" is like saying nobody can drive a stick shift because you have to shift gears manually.
Yes, you have to do it manually, no it doesn't make the car undrivable.
I gave some examples downthread where react pretty much falls apart. I'm sure you "technically" could make it work by dropping down to vanilla and cloning nodes or refactoring backend code or whatever, but at that point it's not merely "technically a bit harder", it's a pretty huge stretch.
The car gear analogy is again downplaying magnitude. The examples I gave are not a comparison between auto vs manual, it's more like auto vs getting a different license type to drive a 18 wheeler and having to learn how to turn, back out, park, go under bridges and where you're allowed to drive and not all over again. Yes, it's technically doable, no it's anywhere near similar amounts of effort as just learning stick.
To clarify, again, just because it feels like react vs vue is akin to manual vs auto when you're in a codebase that is amenable to being refactored into react, it doesn't change the fact that there are types of codebases (non-SPAs without HTTP API layers) where migrating to react is a significantly larger investment than vue. That was what the OP was saying.
I very much doubt the original comment mentioning "the most popular 3 frameworks" didn't have React in mind as one of those, even if they didn't spell it out, so that complaint IMHO makes little sense.
I am impressed how they redesigned both internal architecture and a public API while keeping the users happy. Many well written projects fall into the trap of being a great fit for the contemporary practices but become less relevant over time as the ecosystem changes. Well done, Vue!
I am working on this right now on a medium-sized project, and it's deceptively more work than we anticipated. While Vue's component API itself is remaining mostly backwards compatible with Vue 2, most of the "core" supporting libraries have changed their APIs: Vuex, VueRouter and vue-test-utils in particular.
After the package update and some very basic find/replace across our codebase, about half of our 600+ tests had to be significantly updated. If your tests regularly mock a Vuex store or a router, be prepared to be making a lot of updates.
If you're using some of the features being removed (filters, $on/$off/$once, etc) or make heavy use of custom plugins, it's not going to be painless.
Having said that, I love the direction the new API is heading and 95% of the changes we have to make are for the better in the end, so it feels worth it.
to be fair though you are doing this in hard mode. to transition an app you should wait for 2.7 to get all the warnings and guides. so good job to everyone that you didn't find it herculean.
The migration guide [1] lists breaking changes. If you use many Vue 2 libraries you'll want to wait until they're updated to Vue 3. (I reminds me of the Python situation where if you used lots of Python 2 libraries you'd write your new code in Python 2 instead of Python 3, until those libraries migrated to Python 3)
I just updated a 1 day app, it took a couple hours. No Vue.set/this.$set, significant changes to render functions, changes to much of the boilerplate. I was thinking that most of the deprecated behavior could be easily emmulated. The performace improvements are worth the pain, but I have a lot of code to update. Hopefully the migration build will solve it. It would be nice to avoid a python3 situation.
This is a great tradeoff actually. It sucks to break backwards compatibility, but often that's the only way to move forward. If you have to break something, affecting the least number of developers is best.
This also gives a chance for a refresh of the ecosystem: libraries that are no longer relevant (eg, their functionality has been incorporated or otherwise made obsolete) can go away, and they get a nice "out" so no one has to feel bad about shuttering a project.
It also gives a chance for keeping the libraries using newer APIs, or even newer libraries to gain traction.
Very similar to doing a controlled burn in a forest: Worse than no fire at all, but orders of magnitude better than an actual wildfire.
The market also isn't as volatile as people make it out to be. The top most used js frameworks (React, Angular and Vue) have been in the top spots for 5 to 7 years now. I guess the market might as well be settled. Of course there are some new comers every year, but they don't enjoy a large market share. Hell, I've not even seen VueJS used once in any serious project in the industry.
React and Angular are here to stay, and there's no changing that.
I agree that there will be a need for react/angular talent for many years to come. That said, I think engineering orgs are picking up on the fact that rolling web apps this way introduces lots of complexity and requires lots of resources to maintain and extend. I really don't want to think about regularly maintaining a 10-year-old redux-backed react app down the road.
Whether react/angular/vue are able to continue improving enough to justify staying within that world remains to be seen. It's very early days for some of the new frameworks out there, but with web assembly on the horizon, companies will again be motivated to modernize, however that looks.
This is a popular opinion particularly if all someone pays attention to is Twitter and Reddit but I'd argue it is a wrong opinion.
Angular is alive and well, and being used/adopted every day for projects no one hears about. It isn't the "sexy" choice, but it is the one a lot of companies make.
And if you're gonna point to opinion polls, and all kinds of respect to those who put them out, but they have a hard time capturing Angular usage due to selection bias.
Depends where you live and work I suppose. I used to work in a consultancy firm in Norway that was all in on Angular two-three years ago. Angular has been very popular in enterprise here. But Twitter and Reddit reach enterprise too in the end. The consultancy firm has now switched more or less entirely over to React because Angular is so out of vogue.
US consultant here with a similar story. A lot of what we're doing now seems to be moving toward headless CMS and headless ecommerce with NextJS/Gatsby for the integration point.
I'm still a big fan of Angular, but the amount of work we're getting asking for Angular has dropped off a cliff.
I used to work for a big financial analytics company that used Angular 1.5 for everything. Around the time I left, they started migrating to VueJS instead. Obviously this is all anecdotal, and I have no doubt AngularJS is still being used in a lot of places, but I think there's reason to believe its share might be shrinking.
AngularJS is obviously shrinking. It's the 1.x version, and no one should be starting new projects with it. I don't think anyone is referring to AngularJS. When people say Angular, they'd be referring to v2.0+.
Similar story in the old company I worked for. Though I have experienced that there are a few companies that are happy with Angular and see no reason to switch.
Your comment seems to present anecdotal evidence as facts about $framework's popularity. I think that's misleading.
I'm wondering if there's a scraper out there crawling Alexa TOP 1xxx pages for use of specific libraries, frameworks? Maybe that would present a more accurate picture about this.
Also it's often misleading since in any company with more than a few employees there seems to be more than one team of developers which often leads to different frameworks being used in different parts of the company. In $dayJob we use Angular in some legacy internal stuff, React in a rewritten consumer-facing project and preact or jQuery in a different consumer-facing project.
It's not that simple to determine marketshare of frameworks I think. We can just present different numbers and draw different conclusions from it, e.g. number of job postings mentioning specific frameworks, number of downloads in a registry, number of domains using it (assuming one app per domain), number of stars on github or number of people claiming to use it in the stackoverflow survey.
A lot of the web isn't publicly accessible. And most .com marketing sites are built on a much different tech stack than the actual product. Example: landing page is Wordpress, actual site is a SPA (be it React/Angular/Vue etc).
I’ve deployed a number of applications using Ember’s (Octane) and will continue to use that over React, Angular, and Vue for as long as these other frameworks continue to prioritize fp zealotry over getting shut done.
What do you mean 'fp'? Ember was quite literally one of the worst experiences ever. Not having javascript expressions in handlebars is literally excrutiating. I'm so glad I never have to use ember, ever, ever again.
Download the league client if you want to be scared straight about ember. Resource usage gradually ramps up until by the 5th game the client is using more RAM than the game itself.
The closest thing I can see to a contender is Svelte.
I'd be unlikely to start any new project on Angular. React remains dominant and would be a viable option, except Vue feels more lightweight and approachable. I'm sticking with Vue for now.
Patreon income may not be, but Vue-based income should be.
This company focuses on development of Coldbox, a ColdFusion-based framework still in active development. If they can support a team and still continue development, Vue should be good for a while
From what I see, Vue.js has a very healthy commercial ecosystem. Many people seem to be making money off their community work. Be it with blogs, courses, conferences, offering plugins, UI, etc.
I think this decentralized web of incentives is more sustainable in the long run than a single corporate sponsor.
> Vue 3 has demonstrated significant performance improvements over Vue 2 in terms of bundle size (up to 41% lighter with tree-shaking), initial render (up to 55% faster), updates (up to 133% faster), and memory usage (up to 120% less).
The math is like, if it did use 100mb, and now it uses 25mb, that's 300% less, because 25mb is the "100%", and you reduced by that amount 3 times. Odd.
This kind of arithmetic is always very unclear and causes all kinds of confusion / miscommunication. This is why I always prefer to be explicit about the absolute numbers (maybe in addition to the relative percentages): "it used 100 mb and now it uses 25 mb (which is a 300% reduction when looking at the final result / which is a 75% reduction based on the initial result)".
I can only suppose it means 100% less memory consumption by Vue, and then Vue somehow frees 20% of memory from other running processes, which would lead to some pretty interesting results.
120% less of something (problem here!) = 2.2x less = 1 / 2.2 of something = 45% of something
I think the writer meant 2.2x improvement in memory usage rather than 120% less memory usage -- the word "less" used in conjunction with a percentage is confusing.
I think this is how you evaluate X% less: amount * (1 - (x / 100))
So 120% less of 10 rocks is -2 rocks, which obviously doesn’t make sense. Which is good, it shouldn’t make sense to have more than 100% less of something.
The only way this makes sense to me is if memory usage was reduced by a factor of 1.2, but that sounds so much more modest than "120% less" that I'm doubting myself.
On a related note, I tend to avoid expressing changes as percentages entirely, in large part because increasing by X% and then decreasing by that same X% doesn't get you back to where you started.
I was surprised to see an update to a contemporary JavaScript framework to be welcomed rather than boo’d by the average HN reader. That in itself is an accomplishment.
the appetite for a credible alternative to a Facebook project is strong. also the vue team has done a great job dripping out information over the past 2 years and building anticipation. very little surprises in this release, hence mostly celebration left. you need to go back a bit further in time to find the critical HN comments.
My only wish now is for the TSX experience to be rounded out.
From a reactivity standpoint, Vue has a much more ergonomic/easy to use API for handling component state, effects, and computed values (in my opinion) than React.
But in the last 6-8 months, I've leaned away from Single-File Components because when you want to do something like define a bunch of small components, it's a lot more difficult to do than with multiple TSX functions you can chuck in one file.
So I've been using Vue with TSX, and the experience (in the last few months only, before that was pretty bad) is okay, but not as solid as you'd get with React.
I'm not the only one who must feel this way, because this exists and has a lot of stars:
"Reactivue: Use Vue Composition API in React components"
Unfortunately, this is a weird stance to take in the Vue community, almost nobody uses JSX/TSX. Because of this, the development efforts towards it aren't as much a priority.
Overall, I'd rate the experience as "decent" and "totally usable", but I hope to see the DX for Vue's TSX community improve over the coming months.
---
Edit 2: Disregard the below, this already exists apparently
Edit 1: Having to write two type definitions for Component Props: one TS interface/type, and one as the JS object sucks. That's my one big complaint.
I know it's impossible because props need a runtime value but someone should make a plugin/babel transform to decorate the "props" key from the generic argument here:
I just looked at the sample code you provided. Having no experience with Vue (only React and Angular), but heavy TS user, something came to my eye:
Is it correct that `declare const props` will not only get used to type-check stuff but also emit code based on that?
I think thats unintuitive. TS basically means "take away all the static types and you get what the compiler emits". A lot of developers won't be able to distinguish between TS and the magic that some framework does. I've made similar observations when working with Angular devs.
> Unfortunately, this is a weird stance to take in the Vue community, almost nobody uses JSX/TSX.
Typed components is 200% of why I'm writing React these days. Angular has typed components too (they went in on TypeScript early), but the Angular Language Service / IDE integration didn't come to later-- so for a period, no intellisense.
But having intellisense while writing TSX is so wonderful, especially when you're working with complex or deeply nested object structures.
No it totally works, it's not bad. The one big broken thing in August was that the type for components (RenderContext) thought component props should be passed as "props={ myprop: 1 }" instead of "myprop={1}".
"The issue seems to be that the definition for RenderContext<Props> puts the props under the key "props", so when trying to define them on your JSX/TSX element, it expects you to put them under <MyComponent props={ } />. If you do this though, it breaks in another way because it's missing the other properties of RenderContext and it's not a great API =/"
One thing I'm really excited about with this version is Vite (the snowpack type version of Vue that doesn't require webpack). It should make development so much easier.
As someone who includes we pack in my build chain in order to use vue but doesn't truly understand it and has never used Cute, can you explain the advantages?
I was hoping for better Typescript support for typing properties, since that is where 90% of our type errors occur. But it seems like you still have to specify the types manually. The example from the manual:
Quite disappointing. Maybe not that surprising given Evan said he only started using Typescript very recently, and many beginner Javascript developers don't realise that they should really be using Typescript (fortunately Evan isn't one of them). I would recommend still avoiding Vue for this reason alone.
It's not that we can't implement it like that, the real challenge is in minimizing breakage from v2. We decided it's better to not completely alter how props are declared because that would be too much breakage.
But if the prop definitions are generated at runtime that means Typescript can't check them at compile time surely? Better than Vue 2 I guess but still not as good as React.
Fair enough on not wanting to break things, but I still feel like it is Vue's second biggest flaw and worth breaking to fix.
You get to define your components as classes with their methods and properties, and can declare props and watchers via decorators. Overall a good typescript experience.
The announcement talk was nice to watch, however, it was technically void of any of the implementation details.
It's interesting to me that they did not consider the approach of pushing more work to the compiler and less to the runtime in the manner popularized by Svelte. I wonder what the trade-off between their current rendering approach and the Svelte-based approach are?
Guess I missed that. That makes sense, it's an interesting trade-off though. I suspect that including Vue via a script tag is not how the majority of users implement Vue; and therefore clinging to the virtual DOM may be a net-negative for most use cases. Personally, I am using Vue for a data-intensive app where performance really really matters. Although, I understand how broadening access to the framework increases availability and adoption; and for most use cases these performance considerations don't have any real world implications.
It is interesting though looking across benchmarks though and seeing non virtual DOM frameworks crushing their counterparts in terms of speed. I wonder if we'll see more growth in that space in the future.
You may be aware but it's also important to note that everyone is trying to cheat these benchmarks so they don't mean much. The implementations aren't data driven and don't look much like how we'd write real world code. See the discussions here including the linked issues and PRs https://github.com/krausest/js-framework-benchmark/issues/77...
I don't really understand the composition API. Doesn't passing values by reference which can be modified anywhere downward the tree make your app difficult to reason and debug it?
If you meant more from a conceptual standpoint -- the usage patterns with Vue 3 is pretty nearly identical for most people. You just replace "data()" property with some "reactive()" state value in setup (or "ref()" for single values).
You CAN write things like generic hooks/"useXXX()" helpers, but you likely won't wind up with a ton of those.
Also, about the reference passing: it doesn't actually really work like that. If you pass a "ref()" or "reactive()" value as a prop to a child component, and you mutate it there, it doesn't propagate to the parent.
Vue will throw this warning:
[Vue warn]: Avoid mutating a prop directly since the value will be overwritten whenever the parent component re-renders. Instead, use a data or computed property based on the prop's value. Prop being mutated: "someRef"
> I don't really understand [X]. Doesn't [Y] make your app difficult to reason and debug it?
It (passing mutable values around) does make it harder to understand the data-flow, yes.
But we programmers keep assuming our rules & protection & orderliness are helpful & necessary. And those patterns we opt in to keep getting codified, embraced. But along comes someone who breaks those rules, & it keeps turning out, a lot of the things we think we do to be orderly & safe & sensible are actually not that helpful at all, or have impeded really wonderful progress elsewhere.
I think of React. Until React came along, everyone doing web development knew, it was obviously correct, that we needed templating languages. We knew we needed content & code separate. We knew content was obviously a different beast than code & that content should have tools designed for content. As it turns out, mixing code & content actually works really well & that we had ruled out a wide space of possibilities that were really simple, powerful, & direct.
Relatedly, here, with shared-mutable-variables, I'd pitch that hopefully tools compensate for a lot. Hopefully it's possible to run the app & see who is modifying values, see who is being updated when values change. It's nice being able to have the code tell you, up front, easily, but also hopefully watching at runtime is possible, makes it easy to suss out what the connections & causalities are within a system.
I had a similar misunderstanding when I first saw it, but globally declaring reactive variables and passing them around isn't really what it's about. Take, for example: https://github.com/antfu/vueuse/blob/master/packages/core/us.... Any component that wants to use a reactive reference to mouse coordinates can `const { x, y } = useMouse()` in `setup`, but `x` and `y` will refer to different objects in each of those components (since the `ref()` is instantiated inside the call to `useMouse()`). The functionality is what's shared between components, not the state/references.
That said, if you want to use the composition api to share state you can, and you can pretty easily set up some structure to restrict mutability:
// useStore.ts
import { reactive, readonly } from 'vue'
export const useStore = () => {
const state = reactive({ count: 0 })
const increment = (val = 1) => state.count += val
return {
state: readonly(state), // Readonly so state can't be mutated directly...
increment, // ...only through the mutations provided, like Vuex
}
}
// store.ts
import { useStore } from './useStore'
export const store = useStore() // Now components can share this instance
// MyCounter.vue
import { store } from './store'
export default {
setup: () => ({
count: store.state.count,
onClick: () => store.increment(5),
}),
}
Or you can just keep using Vuex for sharing state and use the composition API for sharing self-contained bits of functionality. Or, if nothing else, using the `setup` method instead of the Options API just gives you much more control over how you organize your own code within a component.
Modifications in all JS frameworks are the same. Some interaction causes an event, that event is caught and changes some data, that data then triggers the render functions which show the new UI. This is often coded with event handlers linked to actions/mutations/reducers in some kind of state management library.
Vue (and some other frameworks) use a reactivity approach where the data is wrapped with a proxy that basically automates all this code. I find it much easier to reason about since it greatly reduces the complexity and you can focus on the actual data changes rather than all the plumbing to change the data.
No, because they all happen in the setup function, and when you export them at the bottom of setup you use them 100% identically as you would within mounted() etc,
I like that vue manages dependencies so you dont worry about pure components anymore, but I believe that was fixed recently in react? The biggest thing is I despise writing JSX. To me it just feels absolutely miserable. The upside is that you have incredible fine grained control over the dynamic rendering of components, but so far even in my complex app there's been no need to write a render function yet (similar equivalent in vue to get that same level of control as react).
Also, I really like the data binding which vue took from angular. That was always by far my favorite part of angular, rather than having the binding be written in JS which feels too mechanic to me. I dont feel like I'm writing HTML / front end code, I feel like I'm writing a hybrid mecha mutant of JS + HTML + weird syntax.
For me and my team, it hits the right balance between Angular's structure and React's no-structure. We can use it for small apps within a server-rendered website, or larger SPAs.
I can hand a project to a junior dev and not have to explain project structure or patterns, nor worry about things going off the rails. Generally, after getting a feature working, most of the feedback I'll need to give is "break this 300 line file up into 3-4 smaller ones". Great ESLint rules provided by the Vue team really help with this.
With Vue 3, with the two APIs, I know that I'll be able to hand a feature off to a developer of any level and know they can accomplish it however it makes the most sense.
I can also jump into a legacy Vue app built by another team and have no issues getting oriented. In my experience with React, I haven't seen the same router configuration twice. Most React projects I've inherited feel over engineered
On a more meta level, I think the single-file API its a much better mental model than React's. Your HTML is still just HTML, and your styles are CSS or Sass, or whatever you choose.It's why I preferred AngularJS over the others at the time.
The short version: state in a react app is all over the place and not as easy to reason about as its advertising claims in addition to buggy libs all over the ecosystem, vue has actually achieved sanity by focusing on developer usefulness and how applications change over time.
Sure, you can use HBS (or even vanilla) to render a piece of dynamic HTML. That's not really the problem these libraries are solving.
You could also create your own components with HBS templates and figure out how compose them to render a tree of components. That's not too hard to figure out either.
The problem is really in updating the DOM when state changes somewhere in your application. In the jQuery days we had tons of micro DOM managing code so that when some variable changed then we would update some piece of the DOM by "hand". But as your project grows this becomes a mess pretty quickly.
Another solution could be to simply re-render everything and update all the DOM on every frame with a state change. That would simplify your code but it would probably be extremely inefficient.
The point of libraries like Vue, React, Svelte, etc, is about simplifying the production of sophisticated UIs, as efficiently as possible, so you can focus on the right abstraction instead of the implementation details (eg: managing the DOM).
Every library takes a very different approach. If you're coming from the vanilla/jQuery world the learning curve can be pretty steep. But, as someone who has been doing web frontend for 20 years, I think the price of admission is worth it.
IMO Vue is probably the easiest one to get into. You can get started by simply including it in a script tag as if you were using jQuery.
Honestly, if manually replacing pieces of DOM works for you, then by all means, keep doing that. I have no horse in the race.
In my experience, the approach you're describing doesn't really scale and only works for the most simplistic use cases. In a real world scenario you would have dozens if not hundreds or thousands of arrays/vars that are related to the view.
Even only considering we're talking about rendering blocks of dynamic HTML: How are you going to keep track which state changes affect which parts of the DOM? Are you going to have hundreds/thousands of innerHTML code all over the place? What is going to happen when (not if) you change your template?
Then you need to start considering, event handlers, initialization code for every car view, etc. Imagine those event handlers modify the state of a single car in your array. Are you going to repaint and re-initialize the events of all your cars on every mouse event? Again, that would probably work on very simplistic use cases.
I'm not describing anything new. These problems are what motivated people to create Ember, Backbone, Angular 1 and other frameworks some 10 years ago. But the JS world has moved on from that paradigm into the reactivity+components thing which is a much better abstraction in terms of developer experience, performance, memory consumption, etc [1].
I use this approach too but it fails whenever there's any state in the elements. An example is input elements:
function update() {
let value = document.querySelector("input")?.valueAsNumber;
document.querySelector("main").innerHTML = `
Enter a price: <input type="number" oninput="update()">
<br>
Discounted price is ${value * 0.8}
`;
}
update();
What will happen is each time you enter a character, it will create a new input element, which loses the focus and cursor position.
To solve this we can split it up so that the inputs are created once and the output is updated with innerHTML. No problem, right? But it's hard to scale up because now you have to split the html up into small segments based on whether there's internal state or not. If you want to update the 'max' of an input type=range, you aren't doing it with handlebars anymore but you have to use setAttribute instead.
What react, vue, etc. do for you is handle the updates in a way that reuses the existing elements. If you changed any attributes of the <input type=number>, it will not lose the focus and cursor and any other state. If you change the max of an <input type=range>, it will update the existing element (using setAttribute) without losing any other state. If you change some text, it will update the existing text node using innerText/textContent.
You may not need this type of system. I think React, Vue, etc. are overused. But in some projects it's much cleaner to use a React/Vue/etc. style system rather than splitting it up where some segments use setAttribute, some use innerHtml, etc.
Now let's say your data (cars) changes. Due to some interaction, a car gets added to the list.
What the above code will do is completely replace the HTML for the entire list of cars, when really all that needs to happen is appending one to the end. If the list is big, your app is now slow.
If the user has something focused or edited in that list of cars (let's say they're editing the description of one), not only is focus lost on that field now (its DOM node was completely wiped out and replaced), but the user's text they were editing is also lost.
That's an imperative approach, rather than a declarative one. You can't track where the state is being changed if #cars is being changed in many places. Templates are fine for smaller apps but in larger apps it's more difficult, and there'll be more spaghetti code and bugs due to that.
Ok, now show the cars list in three places, and one of them is a subset of only BLUE cars.
Now you have to update the DOM 3x and remember that the filter you set in that one place over there means you need to only show BLUE cars in this one place over here.
When you start to build things where one piece of data is not just shown in multiple places, but is dependent on other pieces of data, managing your state starts to become more difficult than the methodology you're describing.
Vue and React are more than templating engines. They decouple the state and view of your application. This means your view becomes a function of state, and you only need to worry about state. This solves the problem of trying to keep your view in sync with the application state, which probably everyone who has done some webdev for more than 5 years still has nightmares about.
Which template engine? Then what if you realize you need a router? Then the developer who glued those together leaves, and all you can hire is juniors.
There are benefits to using the industry standard (which today I consider Vue, React, Angular and slowly Svelte), you can learn it quickly, as it has ton of resources and you can hire easily, as you aren't forcing someone to use some obscure, home baked js framework.
One example is building an application like minesweeper. Would you really want to tackle that with jQuery and templating engine? I'd rather break everything into components, have them talk to each other through a state manger like vuex or redux, and only phone home to my API for important things, like the final game score.
I made a minesweeper clone in JS and CSS, it's not as hard as you'd think and just a few hundred lines of code. I still want to attempt a multiplayer minesweeper, which might benefit more from something like Vue.
A dashboard is usually for me the primary use case for one of these reactive frameworks.
It's great you applied your vanilla JS skills to his totally metaphorical example.
I still don't get why it's okay for every other programming language to use the STL or huge dependencies, but doing so with javascript is frowned upon for some people. You wouldn't write a JSON parser yourself in CPP, you'd install something from conan or use the STL or boost for that. Why is it so bad to do the same with js?
What are you talking about? You're just talking about simple class manipulation which has nothing to do with actual reactivity, especially 2-way data binding.
How would you support that with your "templating engines" you keep mentioning, which to me doesn't mean anything at all, in my understanding of what a templating engine is like handlebars.
So when I click a tile you have some code on the onclick handler to go update the counter at the top? Sounds messy if there are multiple things you need to update when some data changes.
You can use vue, because for most web-applications with vue3 you will only add an additional 15kb to it. I'd wager kilobyte counts that low are worth it when you consider how much easier it is to add on additional functionality when you need it. A well-built build system can do so much automatically for you, including but not limited to automatically minifying your code, cleaning up dead code, html and styles or compressing your images in the build step.
For reference: I recently built a really large scale website with react, including a content-management-system, custom fonts, around 50 pictures and a ton of tracking. It weighs 1,1MB total. The first request without lazy-loaded resources only uses around 200KB. Can't really argue against that.
Any code involving a mid- to large sized web application that needs reactivity. Templating engines like handlebars are used on the server side, react and vue belong on the frontend (most of the time, but not exclusively). That's the reason people use them: If you want to, you can have your logic executed on the client-side only, and host whatever else you need on a cloud-provider. Client-Side computing doesn't scale particulary well when your userbase grows fast enough.
This link might contribute to your evaluation. It's a seemingly reasonable overview of the top three frameworks. Author recommends using all three, spoiler?
It's almost a necessity for complicated apps. Right now I'm building an app which involves a reporting screen with all the following features on a single page:
- 10+ breakdowns for report
- 10+ filters for report
- Each filter has an include/exclude dropdown list which then has multiple features within even a single filter (so some filters are EQUALS/NOT EQUALS) others are INCLUDES/DOESNT INCLUDE/EMPTY/NOT EMPTY and all the appropriate options for each filter, not to mention clearing filters, etc
- column sorting
- column hiding
- filtering with search
- pagination on both client and server side (50K rows batching into sub pagination groups which client side takes over on server batches)
- a dropdown at the top which re-initializes EVERY piece of data with a different account and changes quite literally re-initializes 50+ "states" of the UI on the page
Thinks of google analytics
First of all, we can assume doing this on the front end is 100% required. Imagine using google analytics where every single option you change is a backend request. Impossible, so now that weve gotten past that...
Imagine using something like jquery or custom JS where you try to manage the incredibly complicated input/output nature of each component of the page.
Component based design is required because you can keep all your logic for the entire app for a single TINY piece of the app in its own file. So something like a dropdown menu can get its own component called `<DropdownMenu>`, and within that you define all "outer state" that component can use as a prop, or input state (so for example, you want the items that appear in the list to be defined OUTSIDE the component so the component can be re-used). However, that component also has its own internal state, such as whether its open or not, whether its animating or not, what item is selected etc, so if a component has internal state, then you store it IN the component itself. So now the 'state' of EVERY component on the page is defined in 2 places... the originator of the state (such as the component which holds your API calls), or in the component itself. When any change takes place in ANY of those states, all components related to that state "update" automatically to use that new state. This means by simply making a new API call, the outer component state changes, and every single component that relies on that state updates accordingly, even for the most complex UI imaginable its trivial to think about 95% of the logic because all the state is exactly where you expect it to be, and when there are infinite numbers of nuanced side effects, you usually program them IN the component and you dont have to clutter your actual logic (say for instance the api updates your base state, you want the dropdown to reset to zero, so you would code this into the component itself, so that everywhere on the page that uses this component it would all follow suit).
What do you mean by 'templating engine'. Give me a specific example. Templating engines to me are like handlebars... do you have a sample code example?
Yes, you are definitely missing the point of component based frameworks. That strategy is not even remotely scalable when you have nested complex state chains that vary slightly across multiple implementations of the same component, as well as 2-way communication with the original source of the state (from form inputs, and other parts of the UI).
Each UI action in google analytics affects some other part of the UI. If you change a filter in one area, it might disable sorting in another, and simultaneously change the calendar to be only < 1 year. It might also disable some setting portion of the UI, reset the chart, change the input option on the chart axis, and then show a text input you can type in, and when you type in it, ALL THE previously mentioned states now react to the input box that appears.
You want the logic for those components to be IN THE COMPONENT. With your strategy youre putting all NON business logic and trying to account for "every possible scenario" which is the exact purpose of what reactivity does. You're not writing 1000 extra lines of code to account for every single possible combination (which can be hundreds in complex apps). Instead you quite literally write 0 lines of code, because the reactivity is handled (both ways)
Good to see this out. I want to pick a good frontend scheme for future projects but I don't really need most of the fancy SPAs and the complexity coming with it.
Invested a few weeks on Vue a few months back, then the concern about 'React has 80% market share and you can find React developer much more easily in the west" never went away.
Maybe Mithril is the way out? I just need a really light-weight client-side-ajax MVC for some embedded product webUI, in fact jquery+BT might do the job well but again, jQuery is not modern any more.
Not a frontend guy, picking a direction there has always been challenging.
I think what is not mentioned with any of the big SPA frameworks is the amount of time you invest in the churn between versions. After dealing with this in Angular for a number of years, I ended up going with stock JavaScript for my recent projects and could not be happier. Performance is much better. I have a better understanding of what goes into the product. And, I am not constantly dealing with a new version and breaking changes every 3-6 months.
So you suggest switching from one of the Big 3 to Mithril because you are concerned about market share, while Mithril probably has magnitudes less market share?
if i have to invest into one of the Big 3 then market-share becomes a concern, each of them requires quite some time and efforts to master, and you normally don't have enough extra time to switch after a while.
if I pick less known but easier-to-learn-got-job-done option I expect to invest less efforts, thus market-share is less critical for the concerns.
Alpine is great for the niche it fills. All the stuff where I used to say “Vue would be overkill for this, I’ll just throw something together with jQuery”, I now use Alpine for instead, and it’s a much nicer experience. And at 7kb you can’t really grumble.
> allows end users to shave off up to half of the runtime size via tree-shaking
Doesn’t webpack support actual tree-shaking (not just modules) or is that still a Rollup-only feature? There should be little difference in size in importing packages vs files if tree-shaking is on.
Webpack doesn't support actual, statically checked tree shaking for now. There is a parameter called ''sideEffects'' you can employ in your package.json, which if switched to off gives hints to the compiler that your code is side-effect free and can thus be eliminated if not used.
good timing. I'm about to start learning vue.js so I'll start with this. We'll see how long it takes to "unlearn" 40 years of traditional programming and jump into the world of web apps.
First, `$childRef.setData()` appears to be the conceptual equivalent in React of `childClassComponentInstance.setState({someField})`. While that's technically possible, it's _extremely_ non-idiomatic in React and completely discouraged.
Second, "forwarding refs" is a feature specifically designed to allow a component to apply a ref to something _inside_ of itself. For example, the React-Redux `connect` API uses ref forwarding to allow `<ConnectedComponent ref={instanceRef}>` to hand back the inner wrapped component, not the outer wrapper component from the library. It doesn't have anything to do with calling a state setting function on a component in and of itself.
Why is IE11 support still important now? I can't find exact stats on it, but it seems <2%. Surely projects which still want to support IE11 could still stick for a while with Vue2.
IE11 is still heavily used in some industries, such as healthcare. Browser statistics services usually don't pick up on a lot of IE11 use because it's on internal networks.
I wish I could ignore IE11, but the reality is that I can't.
I was surprised that became a feature of Vue 3, as well. I was hoping they would drop it, assuming you could just use Babel + Polyfills to get it to work if you really needed it.
I started playing with Vue in 2015, even wrote an article [1] about Vue which was pretty popular a couple of years ago (it was hosted on Medium then).
These days I'm focused on Svelte. It's faster and lighter, but IMO the best feature is you write a fraction of the code. When I go back to old React or Vue projects I want to cry. Svelte is so much more zen.
OTOH the ecosystem is minuscule so you are on your own. The support for TS and testing is not great either. Svelte is easy to learn but it's not very popular yet. I would understand if someone argued it's a risky bet although I'm building my SaaS with it.
Maybe take both for a brief spin, but my vote would be for svelte. I used vue2 about the same timeframe as you (stumbled upon it while trying to find alternatives to React or whatever) and really liked it a lot.
About a year ago I had to tackle a few new web projects so I decided to give React/Angular/etc another look... and promptly went hunting for alternatives again, and that's how I found svelte. We've got 5-6 svelte-based projects in production now and have really, really enjoyed it.
All that said, I haven't looked at vue3 in depth yet, so maybe it's amazing, I dunno. :)
If you know Vue 2, Vue 3 will be easy to learn, as well. There are some more advanced features you can choose to use if you want, but I guarantee you could pick it up really fast. This isn't an AngularJS -> Angular sorta change.
Also, give it a few more months before building anything non-trivial. Some of the more popular libraries for Vue 2 still need to up updated for Vue 3 (vue-router, vuex, for instance).
Where I live, VueJs isn't even mentioned in any job postings. Large companies still work with older Angular projects, new projects are more often than not done in whatever fits the need.
I find myself using `const state = reactive({...})` exclusively now. It's just way simpler (read:less mental overhead). But, I've only been using the composition API for a short while now.
Do experienced Vue devs actually use both regularly?
According to the vue discord where I asked a lot of composition API questions, pretty much people use ref exclusively. It's much more explicit in your `use*` composition files when you have to call .value. It's rare to me to export a very large object of keys, and I have yet to use it yet.
Out of curiosity, how do you handle data needed by tons of components at different tree depths (info about the current user for example)?
I don’t always reach for Vuex, but when an app reaches a certain size it sure beats passing every bit of common data down through the entire tree, as I find you quickly hit a point where you’re passing data to components solely so it can pass it to it’s children.
It's funny I still have never really understood the case for Vuex. So far I have built decent complexity apps just by having a global reactive object that all components link to directly in their Vue data and I have yet to hit a problem. I see huge writeups and design patterns all suggesting I really need to use a state management library and I'm waiting for the day the penny drops and I realise what a mistake I've made but so far everything just keeps rocking along .... what am I missing?
(I get that there are some nice features like time travel debugging etc but none of them seem outweigh the giant additional complexity of routing every single state change through 1-2 extra layers.)
Not sure about Vue 3, but in Vue 2 you can simply use a Vue instance without a template as a reactive store. You can also share an object between Vue instances.
Seems like they should try more marketing and community outreach toward that end.
Gradual adoption is a feature / selling point not many web development frameworks can claim.