Vue.js 3

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.

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).

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.

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 don't know if you intended it this way, but the start of this comment makes it automatically flamebait.

Discussion around release announcements can quickly turn into a flame war. Please use caution.

All this FUD spread by the Vue fans is getting ridiculous...

That's how a market works. It's a strong incentive to keep Vue sexy.

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

https://www.ortussolutions.com/

I am sure he can save a lot, with that income.

I am sure he could find a normal job, with those skills.

I am sure he could be a freelancer, with "created vue.js" as reference.

His Patreon based income would slowly die with the decline of Vue.js and he'd have enough time to look for something else.

I was curious about this too when Vue 3 overshot its release estimate and then he started working on Vite, which is a build tool.

I think this decentralized web of incentives is more sustainable in the long run than a single corporate sponsor.

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.

100% more of something = 2x more

120% more of something = 2.2x more

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.

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.

Perf is on par with Preact.

RC4 is not the final release though, we'll see how it goes with 3.0.0

[1] https://krausest.github.io/js-framework-benchmark/current.ht...

ps: 5min later it's over

Uh, you don't have to? TS inference works with the JS objects. There's no need to provide the generic argument here.

Also check out this: https://github.com/vuejs/rfcs/blob/sfc-improvements/active-r... (auto-generating runtime types from TS interface)

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.

Instead, there's the compiler-based approach with `<script setup lang="ts">`: https://docs.google.com/presentation/d/1VjBM6ae-fuawK1TltYLX... (runtime props definitions auto-generated from TS interface)

https://class-component.vuejs.org/

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.

they certainly did, lol. the tradeoff is the same it's been; they want all of vue available in a script tag.

A while ago I wrote the same component in Vue 2 and Vue 3 as an example of one versus the other:

https://codesandbox.io/s/bold-shamir-uqm0b?file=/src/compone...

https://codesandbox.io/s/bold-shamir-uqm0b?file=/src/compone...

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"

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.

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),
      }),
    }

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.

Could you expand on this a little more? What is it specifically that makes it incredible compared to React, in your opinion?

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.

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.

That's my take at least.

If you're building complex user interfaces or a large-scale web app, then hell yeah, you want to use React or Vue.

This link might contribute to your evaluation. It's a seemingly reasonable overview of the top three frameworks. Author recommends using all three, spoiler?

- 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).

It works well with the Composition API plugin for Vue 2 though. They have a dedicated package for this.

With the Nuxt VCA + Nuxt TS plugin, the experience is solid IMO.

I wish I could ignore IE11, but the reality is that I can't.

Then 133% faster means 2.33x faster (takes 1 / 2.33 = 0.42 the orig time).

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.

[1] https://www.pierbover.com/posts/vuejs-good-meh-ugly/

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. :)

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).

It's incredibly easy to use and I've (personally) liked it a lot more than Vue(2).

I researched tech required in job offers and React was first, running circles around Angular and Vue. Nobody spoke of Svelte

ref() is for single values, and to get at the actual VALUE, you need to use "myRef.value"

   const state = reactive({ msg: "hello", count: 1 })
   state.msg // "hello"
   
   const msg = ref("hello")
   msg.value // "hello"

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.