15 ms·

Vue.js 3

768 points by simulo 6y ago

hugi 6y ago
Live release announcement with Evan You going on right now: https://www.youtube.com/watch?v=Vp5ANvd88x0 https://www.youtube.com/watch?v=Vp5ANvd88x0
- x87678r 6y ago
  I didn't expect him to say "Enjoy the Vue" ha.
  - hugi 6y ago
    Programmer and dad-level humor can be a pretty deadly combination.
    - kbenson 6y ago
      The combination of the two is so dangerous you could say it's dadly.
      - phist_mcgee 6y ago
        He took the joke father than he really should have.
- agumonkey 6y ago
  in case people wonder, still live as I type ps: 5min later it's over
awinter-py 6y ago
hooray <Suspense>
lykahb 6y ago
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!
- diminish 6y ago
  curious how easy it will be to move from vue 2 to vue 3
  - Exuma 6y ago
    Its very easy for users, quite difficult for library maintainers
    - gregmac 6y ago
      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.
  - deleted 6y ago
    [deleted]
  - amitp 6y ago
    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) [1]: https://v3.vuejs.org/guide/migration/introduction.html#breaking-changes https://v3.vuejs.org/guide/migration/introduction.html#break...
bewareandaware 6y ago
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?
- gavinray 6y ago
  I have a fairly large/complex SaaS platform built with Vue 3 composition API. Can maybe shed some light. 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/components/Vue2.vue https://codesandbox.io/s/bold-shamir-uqm0b?file=/src/compone... https://codesandbox.io/s/bold-shamir-uqm0b?file=/src/components/Vue3 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"
- manigandham 6y ago
  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.
- rektide 6y ago
  > 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.
fyrmio 6y ago
> 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). What does 120% less memory usage mean, really?
- dboreham 6y ago
  Means writer isn't mathematically literate?
  - hugi 6y ago
    120% less mathematically literate than the last writer.
  - enraged_camel 6y ago
    What's with the harsh attitude? It may have been a simple typo.
  - addicted 6y ago
    It means the writer isnt great at English. There are other languages which would use similar constructs where it wouldn’t be wrong.
    - azangru 6y ago
      Do other languages math differently?
- ru552 6y ago
  It doesn't need memory anymore. Writes raw to spinning disk. 2% faster -50% of the time
  - ric2b 6y ago
    It also goes ahead and downloads some extra RAM for you.
- 6y ago
gavinray 6y ago
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" https://github.com/antfu/reactivue https://github.com/antfu/reactivue 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: const MyComponent = defineComponent<MyComponentProps> Use reflection on "MyComponentProps" to set "props" key. There's another comment below discussing this drawback too.
- lloydatkinson 6y ago
  They have improved TSX support in Vue 3. Did you try it? What does or does not work? I'm planning on switching to TSX.
  - gavinray 6y ago
    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}". See: https://cdn.discordapp.com/attachments/568037134968160256/730811100815163452/unknown.png https://cdn.discordapp.com/attachments/568037134968160256/73... Comment I made about this I dug up: "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 =/" This is fixed now though I am pretty sure.
jaequery 6y ago
if this means no more Vuex, i'm all for that. that extra abstraction layer never proved useful to me.
- gorbypark 6y ago
  Vuex is still around. They just haven't finished integrating it into Vue Dev Tools, yet.
- deergomoo 6y ago
  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.
  - pier25 6y ago
    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. See: https://vuejs.org/v2/guide/state-management.html https://vuejs.org/v2/guide/state-management.html
  - jbjorge 6y ago
    Since the reactivity api is exposed it's very easy to write a file to hold whatever state you want. Benefits: easy to create, type safety is simple. Drawbacks: you don't get a serializable state log for free (that can be recorded and replayed when hitting bugs).
  - zmmmmm 6y ago
    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.)
therealmarv 6y ago
anybody know the status of Nuxt and vue 3 support?
- gavinray 6y ago
  It's meant to be released sometime within the coming weeks from contributor comments IIRC. 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.
- wishinghand 6y ago
  It's coming. This is just the slides, but some details were gone over by a main Nuxt contributor: https://nuxtjs.slides.com/atinux/state-of-nuxt-2020 https://nuxtjs.slides.com/atinux/state-of-nuxt-2020
IshKebab 6y ago
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: const Component = defineComponent({ props: { name: String, success: { type: String }, callback: { type: Function as PropType<() => void> }, message: { type: Object as PropType<ComplexMessage>, required: true, validator(message: ComplexMessage) { return !!message.title } } } }) Contrast this with React where this would be something like this (I think; I've never used React): interface Props { name: string; success: string; callback: () => void; message: ComplexMessage; } export default class Component extends React.Component<Props> { ... 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.
- EvanYou 6y ago
  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. Instead, there's the compiler-based approach with `<script setup lang="ts">`: https://docs.google.com/presentation/d/1VjBM6ae-fuawK1TltYLXtcXGaxJw1y8ncT6wnbjaBGo/edit#slide=id.g86a2c92822_0_168 https://docs.google.com/presentation/d/1VjBM6ae-fuawK1TltYLX... (runtime props definitions auto-generated from TS interface)
  - mthoms 6y ago
    FYI Evan, that doc is currently private.
  - solarmist 6y ago
    The google doc is restricted.
  - IshKebab 6y ago
    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.
ausjke 6y ago
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.
- ahpearce 6y ago
  AlpineJS? A bit polarizing, but definitely lightweight...
  - deergomoo 6y ago
    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.
- lloydatkinson 6y ago
  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?
  - ausjke 6y ago
    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.
- madoublet 6y ago
  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.
jaequery 6y ago
is reactive() just a mere wrapper around ref() ?
- gavinray 6y ago
  Kind of -- reactive() lets you declare multiple values at once, and you can read the property directly. 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" Though when you use ref()'s in templates, it will bind to .value for you.
  - mthoms 6y ago
    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?
    - gavinray 6y ago
      Personally, I rarely use refs. I think they have more use when creating general-purpose libraries for Vue. You can also just call "toRefs()" on a "reactive()" object though. Refs are also useful if you want to destructure a reactive object without breaking the reactivity, scroll down just below this: https://composition-api.vuejs.org/api.html#torefs https://composition-api.vuejs.org/api.html#torefs
    - Exuma 6y ago
      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.
- likeclockwork 6y ago
  Other way around I think. ref is a single value reactive.
Exuma 6y ago
I just started vue 3 and its incredible compared to my experience with react. Way to go Vue team!!!
- azangru 6y ago
  > and its incredible compared to my experience with react Could you expand on this a little more? What is it specifically that makes it incredible compared to React, in your opinion?
  - Exuma 6y ago
    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.
  - duhi88 6y ago
    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.
TekMol 6y ago
I still don't see a reason why one would use Vue or React. I agree that templating of data is something you should use a library for. But there are great templating libraries. Handlebars for example. Can someone give a short example of code that would be more elegant using Vue then just a simple template engine?
- serial_dev 6y ago
  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. That's my take at least.
  - azangru 6y ago
    > all you can hire is juniors Then you are in trouble regardless of what you use :-)
- cjohnson318 6y ago
  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.
  - TekMol 6y ago
    I would neither need jQuery nor a templating engine to write Minesweeper.
    - j-krieger 6y ago
      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?
badhabit 6y ago
i learned vue2 3-4 years ago. should i learn vue3 or svelte instead?
- k__ 6y ago
  Depends on what you want. I researched tech required in job offers and React was first, running circles around Angular and Vue. Nobody spoke of Svelte
  - j-krieger 6y ago
    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.
- phaedryx 6y ago
  Honestly, this https://svelte.dev/faq#how-do-i-test-svelte-apps https://svelte.dev/faq#how-do-i-test-svelte-apps made the decision to choose Vue over Svelte pretty easy for me.
- deergomoo 6y ago
  You could do both tbh, there’s not much to Svelte (as the name suggests).
- davidwparker 6y ago
  Honestly, it takes 1/2 a day to read through all the svelte docs and go through the tutorial. It's incredibly easy to use and I've (personally) liked it a lot more than Vue(2).
- pier25 6y ago
  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. [1] https://www.pierbover.com/posts/vuejs-good-meh-ugly/ https://www.pierbover.com/posts/vuejs-good-meh-ugly/
didip 6y ago
I am impressed with the amount of energy Evan is pouring in this open source project. I am curious if he ever experience boredom working on Vue. I am also curious if Patreon based income is sustainable for the long run. What if there's another new sexy JS framework in the future?
- mushufasa 6y ago
  > What if there's another new sexy JS framework in the future? That's how a market works. It's a strong incentive to keep Vue sexy.
  - j-krieger 6y ago
    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.
    - ccday 6y ago
      GitLab uses Vue, that qualifies as a serious product.
    - Exuma 6y ago
      WTF are you talking about... so you don't consider any of these to be serious? sentry.io, Gitlab, Grammarly, Codeship, Behance
      - franklampard 6y ago
        React is winning in U.S. Vue is winning in China
        solarkraft 6y ago
TravelPiglet 6y ago
Can I use it by including it with a script-tag? Vue 2 was kind of possible to get up and running with a script-tag to get components in a pre-existing app.
- Exuma 6y ago
  Yes its possible
jiofih 6y ago
> 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.
- j-krieger 6y ago
  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.
- wishinghand 6y ago
  It will on or after October 10th, which is when the next version of Webpack is slated to release.
  - httgp 6y ago
    Wait they’ve announced a date? The Webpack 5 project board on GitHub still has a bunch of items not done yet.
    - wishinghand 6y ago
      https://github.com/webpack/webpack/issues/11406 https://github.com/webpack/webpack/issues/11406
quaffapint 6y ago
Anyone know if Vue 3 is isolated? Like can you use it to make 3rd party widgets and not worry about version conflict like you would with Vue 2?
zwieback 6y ago
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.
RNCTX 6y ago
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.
- goodoldneon 6y ago
  Why can't React do the same?
  - RNCTX 6y ago
    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.
    - shados 6y ago
      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)
filipsch 6y ago
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.
- swyx 6y ago
  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.
umvi 6y ago
So it looks like Vue releases are all named after anime? For anyone curious, here's the full list: https://en.wikipedia.org/wiki/Vue.js#Versions https://en.wikipedia.org/wiki/Vue.js#Versions
- dane-pgp 6y ago
  Is that a JoJo reference?
  - andrewflnr 6y ago
    It's my understanding that anything can be a JoJo reference if you want it to be.
NanoWar 6y ago
Nice, but does it have material?
- uncle_iroh 6y ago
  https://vuetifyjs.com/en/ https://vuetifyjs.com/en/
  - NanoWar 6y ago
    I dont think this is available for vue 3. Sadly.
superasn 6y ago
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.
- mcherm 6y ago
  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?
  - superasn 6y ago
    This is straight out of the horses mouth: - Lightning-fast cold server start - Instant hot module replacement (HMR) - True on-demand compilation This part should be of particular interest to you: https://github.com/vitejs/vite#how-is-this-different-from-vue-cli-or-other-bundler-based-solutions https://github.com/vitejs/vite#how-is-this-different-from-vu...
    - mcherm 6y ago
      Thank you.
mariushn 6y ago
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.
- reaperducer 6y ago
  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.
  - valueprop 6y ago
    Thanks for sharing
  - ramses0 6y ago
    IE11 is also frequently represented as `mshtml.dll` in windows programs that embed a browser (eg: https://en.wikipedia.org/wiki/Trident_(software)#Use_cases https://en.wikipedia.org/wiki/Trident_(software)#Use_cases )
  - dbbk 6y ago
    The point is that Vue 2 can continue to be used though. There's no need to upgrade.
- duhi88 6y ago
  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.
  - rk06 6y ago
    Because vue3 depends on proxies which can't be polyfilled. They need to add the vue2 logic for reactivity. And use polyfill for any other advance features
winrid 6y ago
Ha, I literally just built my first Vue 2.0 project yesterday. I'm already behind! :) (just a Chrome extension) https://github.com/FastComments/fastcomments-debug/blob/master/chrome/src/popup/App.vue https://github.com/FastComments/fastcomments-debug/blob/mast...
nikkwong 6y ago
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?
- swyx 6y ago
  > they did not consider the approach they certainly did, lol. the tradeoff is the same it's been; they want all of vue available in a script tag.
  - nikkwong 6y ago
    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.
    - korm 6y ago
      Which benchmarks? In the js-framework-benchmark Svelte is slower than Inferno or Ivi and only slightly faster than Preact or Vue. https://krausest.github.io/js-framework-benchmark/2020/table_chrome_85.0.4183.83.html https://krausest.github.io/js-framework-benchmark/2020/table... 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/772 https://github.com/krausest/js-framework-benchmark/issues/77...
brylie 6y ago
I've been confused by some of Evan's presentations about performance gains and other statistics. For example, the release notes say > updates (up to 133% faster) How can something be > 100% faster?
- Roboprog 6y ago
  By doing twice as much in the same time, I guess.
- wenc 6y ago
  If you take 100% faster to mean 2x faster (takes 1/2 the orig time), 200% faster to mean 3x faster (takes 1/3 the orig time)... Then 133% faster means 2.33x faster (takes 1 / 2.33 = 0.42 the orig time).
  - brylie 6y ago
    Thanks for clarifying :-)
revskill 6y ago
I don't know if React could allow set children's data via parent, like $childRef.setData({ data }) When i see this code in a Vue codebase, my mind got hurt. I still prefer React due to its consistent reasoning about data flow in the app.
- onion2k 6y ago
  That sounds like the equivalent to React's forward refs. https://reactjs.org/docs/forwarding-refs.html https://reactjs.org/docs/forwarding-refs.html
  - acemarke 6y ago
    No, that's very different, in two ways. 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.
tor291674 6y ago
No Nuxt 3 yet.

768 points by simulo 6y ago

hugi 6y ago

Live release announcement with Evan You going on right now: https://www.youtube.com/watch?v=Vp5ANvd88x0 https://www.youtube.com/watch?v=Vp5ANvd88x0

x87678r 6y ago
I didn't expect him to say "Enjoy the Vue" ha.
- hugi 6y ago
  Programmer and dad-level humor can be a pretty deadly combination.
  - kbenson 6y ago
    The combination of the two is so dangerous you could say it's dadly.
    - phist_mcgee 6y ago
      He took the joke father than he really should have.
agumonkey 6y ago
in case people wonder, still live as I type ps: 5min later it's over

awinter-py 6y ago

hooray <Suspense>

lykahb 6y ago

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!

diminish 6y ago
curious how easy it will be to move from vue 2 to vue 3
- Exuma 6y ago
  Its very easy for users, quite difficult for library maintainers
  - gregmac 6y ago
    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.
- deleted 6y ago
  [deleted]
- amitp 6y ago
  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) [1]: https://v3.vuejs.org/guide/migration/introduction.html#breaking-changes https://v3.vuejs.org/guide/migration/introduction.html#break...

bewareandaware 6y ago

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?

gavinray 6y ago
I have a fairly large/complex SaaS platform built with Vue 3 composition API. Can maybe shed some light. 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/components/Vue2.vue https://codesandbox.io/s/bold-shamir-uqm0b?file=/src/compone... https://codesandbox.io/s/bold-shamir-uqm0b?file=/src/components/Vue3 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"
manigandham 6y ago
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.
rektide 6y ago
> 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.

fyrmio 6y ago

> 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). What does 120% less memory usage mean, really?

dboreham 6y ago
Means writer isn't mathematically literate?
- hugi 6y ago
  120% less mathematically literate than the last writer.
- enraged_camel 6y ago
  What's with the harsh attitude? It may have been a simple typo.
- addicted 6y ago
  It means the writer isnt great at English. There are other languages which would use similar constructs where it wouldn’t be wrong.
  - azangru 6y ago
    Do other languages math differently?
ru552 6y ago
It doesn't need memory anymore. Writes raw to spinning disk. 2% faster -50% of the time
- ric2b 6y ago
  It also goes ahead and downloads some extra RAM for you.
6y ago

gavinray 6y ago

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" https://github.com/antfu/reactivue https://github.com/antfu/reactivue 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: const MyComponent = defineComponent<MyComponentProps> Use reflection on "MyComponentProps" to set "props" key. There's another comment below discussing this drawback too.

lloydatkinson 6y ago
They have improved TSX support in Vue 3. Did you try it? What does or does not work? I'm planning on switching to TSX.
- gavinray 6y ago
  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}". See: https://cdn.discordapp.com/attachments/568037134968160256/730811100815163452/unknown.png https://cdn.discordapp.com/attachments/568037134968160256/73... Comment I made about this I dug up: "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 =/" This is fixed now though I am pretty sure.

jaequery 6y ago

if this means no more Vuex, i'm all for that. that extra abstraction layer never proved useful to me.

gorbypark 6y ago
Vuex is still around. They just haven't finished integrating it into Vue Dev Tools, yet.
deergomoo 6y ago
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.
- pier25 6y ago
  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. See: https://vuejs.org/v2/guide/state-management.html https://vuejs.org/v2/guide/state-management.html
- jbjorge 6y ago
  Since the reactivity api is exposed it's very easy to write a file to hold whatever state you want. Benefits: easy to create, type safety is simple. Drawbacks: you don't get a serializable state log for free (that can be recorded and replayed when hitting bugs).
- zmmmmm 6y ago
  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.)

therealmarv 6y ago

anybody know the status of Nuxt and vue 3 support?

gavinray 6y ago
It's meant to be released sometime within the coming weeks from contributor comments IIRC. 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.
wishinghand 6y ago
It's coming. This is just the slides, but some details were gone over by a main Nuxt contributor: https://nuxtjs.slides.com/atinux/state-of-nuxt-2020 https://nuxtjs.slides.com/atinux/state-of-nuxt-2020

IshKebab 6y ago

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: const Component = defineComponent({ props: { name: String, success: { type: String }, callback: { type: Function as PropType<() => void> }, message: { type: Object as PropType<ComplexMessage>, required: true, validator(message: ComplexMessage) { return !!message.title } } } }) Contrast this with React where this would be something like this (I think; I've never used React): interface Props { name: string; success: string; callback: () => void; message: ComplexMessage; } export default class Component extends React.Component<Props> { ... 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.

EvanYou 6y ago
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. Instead, there's the compiler-based approach with `<script setup lang="ts">`: https://docs.google.com/presentation/d/1VjBM6ae-fuawK1TltYLXtcXGaxJw1y8ncT6wnbjaBGo/edit#slide=id.g86a2c92822_0_168 https://docs.google.com/presentation/d/1VjBM6ae-fuawK1TltYLX... (runtime props definitions auto-generated from TS interface)
- mthoms 6y ago
  FYI Evan, that doc is currently private.
- solarmist 6y ago
  The google doc is restricted.
- IshKebab 6y ago
  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.

ausjke 6y ago

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.

ahpearce 6y ago
AlpineJS? A bit polarizing, but definitely lightweight...
- deergomoo 6y ago
  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.
lloydatkinson 6y ago
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?
- ausjke 6y ago
  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.
madoublet 6y ago
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.

jaequery 6y ago

is reactive() just a mere wrapper around ref() ?

gavinray 6y ago
Kind of -- reactive() lets you declare multiple values at once, and you can read the property directly. 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" Though when you use ref()'s in templates, it will bind to .value for you.
- mthoms 6y ago
  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?
  - gavinray 6y ago
    Personally, I rarely use refs. I think they have more use when creating general-purpose libraries for Vue. You can also just call "toRefs()" on a "reactive()" object though. Refs are also useful if you want to destructure a reactive object without breaking the reactivity, scroll down just below this: https://composition-api.vuejs.org/api.html#torefs https://composition-api.vuejs.org/api.html#torefs
  - Exuma 6y ago
    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.
likeclockwork 6y ago
Other way around I think. ref is a single value reactive.

Exuma 6y ago

I just started vue 3 and its incredible compared to my experience with react. Way to go Vue team!!!

azangru 6y ago
> and its incredible compared to my experience with react Could you expand on this a little more? What is it specifically that makes it incredible compared to React, in your opinion?
- Exuma 6y ago
  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.
- duhi88 6y ago
  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.

TekMol 6y ago

I still don't see a reason why one would use Vue or React. I agree that templating of data is something you should use a library for. But there are great templating libraries. Handlebars for example. Can someone give a short example of code that would be more elegant using Vue then just a simple template engine?

serial_dev 6y ago
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. That's my take at least.
- azangru 6y ago
  > all you can hire is juniors Then you are in trouble regardless of what you use :-)
cjohnson318 6y ago
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.
- TekMol 6y ago
  I would neither need jQuery nor a templating engine to write Minesweeper.
  - j-krieger 6y ago
    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?

badhabit 6y ago

i learned vue2 3-4 years ago. should i learn vue3 or svelte instead?

k__ 6y ago
Depends on what you want. I researched tech required in job offers and React was first, running circles around Angular and Vue. Nobody spoke of Svelte
- j-krieger 6y ago
  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.
phaedryx 6y ago
Honestly, this https://svelte.dev/faq#how-do-i-test-svelte-apps https://svelte.dev/faq#how-do-i-test-svelte-apps made the decision to choose Vue over Svelte pretty easy for me.
deergomoo 6y ago
You could do both tbh, there’s not much to Svelte (as the name suggests).
davidwparker 6y ago
Honestly, it takes 1/2 a day to read through all the svelte docs and go through the tutorial. It's incredibly easy to use and I've (personally) liked it a lot more than Vue(2).
pier25 6y ago
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. [1] https://www.pierbover.com/posts/vuejs-good-meh-ugly/ https://www.pierbover.com/posts/vuejs-good-meh-ugly/

didip 6y ago

I am impressed with the amount of energy Evan is pouring in this open source project. I am curious if he ever experience boredom working on Vue. I am also curious if Patreon based income is sustainable for the long run. What if there's another new sexy JS framework in the future?

mushufasa 6y ago
> What if there's another new sexy JS framework in the future? That's how a market works. It's a strong incentive to keep Vue sexy.
- j-krieger 6y ago
  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.
  - ccday 6y ago
    GitLab uses Vue, that qualifies as a serious product.
  - Exuma 6y ago
    WTF are you talking about... so you don't consider any of these to be serious? sentry.io, Gitlab, Grammarly, Codeship, Behance
    - franklampard 6y ago
      React is winning in U.S. Vue is winning in China
      - solarkraft 6y ago

TravelPiglet 6y ago

Can I use it by including it with a script-tag? Vue 2 was kind of possible to get up and running with a script-tag to get components in a pre-existing app.

Exuma 6y ago
Yes its possible

jiofih 6y ago

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

j-krieger 6y ago
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.
wishinghand 6y ago
It will on or after October 10th, which is when the next version of Webpack is slated to release.
- httgp 6y ago
  Wait they’ve announced a date? The Webpack 5 project board on GitHub still has a bunch of items not done yet.
  - wishinghand 6y ago
    https://github.com/webpack/webpack/issues/11406 https://github.com/webpack/webpack/issues/11406

quaffapint 6y ago

Anyone know if Vue 3 is isolated? Like can you use it to make 3rd party widgets and not worry about version conflict like you would with Vue 2?

zwieback 6y ago

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.

RNCTX 6y ago

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.

goodoldneon 6y ago
Why can't React do the same?
- RNCTX 6y ago
  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.
  - shados 6y ago
    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)

filipsch 6y ago

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.

swyx 6y ago
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.

umvi 6y ago

So it looks like Vue releases are all named after anime? For anyone curious, here's the full list: https://en.wikipedia.org/wiki/Vue.js#Versions https://en.wikipedia.org/wiki/Vue.js#Versions

dane-pgp 6y ago
Is that a JoJo reference?
- andrewflnr 6y ago
  It's my understanding that anything can be a JoJo reference if you want it to be.

NanoWar 6y ago

Nice, but does it have material?

uncle_iroh 6y ago
https://vuetifyjs.com/en/ https://vuetifyjs.com/en/
- NanoWar 6y ago
  I dont think this is available for vue 3. Sadly.

superasn 6y ago

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.

mcherm 6y ago
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?
- superasn 6y ago
  This is straight out of the horses mouth: - Lightning-fast cold server start - Instant hot module replacement (HMR) - True on-demand compilation This part should be of particular interest to you: https://github.com/vitejs/vite#how-is-this-different-from-vue-cli-or-other-bundler-based-solutions https://github.com/vitejs/vite#how-is-this-different-from-vu...
  - mcherm 6y ago
    Thank you.

mariushn 6y ago

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.

reaperducer 6y ago
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.
- valueprop 6y ago
  Thanks for sharing
- ramses0 6y ago
  IE11 is also frequently represented as `mshtml.dll` in windows programs that embed a browser (eg: https://en.wikipedia.org/wiki/Trident_(software)#Use_cases https://en.wikipedia.org/wiki/Trident_(software)#Use_cases )
- dbbk 6y ago
  The point is that Vue 2 can continue to be used though. There's no need to upgrade.
duhi88 6y ago
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.
- rk06 6y ago
  Because vue3 depends on proxies which can't be polyfilled. They need to add the vue2 logic for reactivity. And use polyfill for any other advance features

winrid 6y ago

Ha, I literally just built my first Vue 2.0 project yesterday. I'm already behind! :) (just a Chrome extension) https://github.com/FastComments/fastcomments-debug/blob/master/chrome/src/popup/App.vue https://github.com/FastComments/fastcomments-debug/blob/mast...

nikkwong 6y ago

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?

swyx 6y ago
> they did not consider the approach they certainly did, lol. the tradeoff is the same it's been; they want all of vue available in a script tag.
- nikkwong 6y ago
  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.
  - korm 6y ago
    Which benchmarks? In the js-framework-benchmark Svelte is slower than Inferno or Ivi and only slightly faster than Preact or Vue. https://krausest.github.io/js-framework-benchmark/2020/table_chrome_85.0.4183.83.html https://krausest.github.io/js-framework-benchmark/2020/table... 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/772 https://github.com/krausest/js-framework-benchmark/issues/77...

brylie 6y ago

I've been confused by some of Evan's presentations about performance gains and other statistics. For example, the release notes say > updates (up to 133% faster) How can something be > 100% faster?

Roboprog 6y ago
By doing twice as much in the same time, I guess.
wenc 6y ago
If you take 100% faster to mean 2x faster (takes 1/2 the orig time), 200% faster to mean 3x faster (takes 1/3 the orig time)... Then 133% faster means 2.33x faster (takes 1 / 2.33 = 0.42 the orig time).
- brylie 6y ago
  Thanks for clarifying :-)

revskill 6y ago

I don't know if React could allow set children's data via parent, like $childRef.setData({ data }) When i see this code in a Vue codebase, my mind got hurt. I still prefer React due to its consistent reasoning about data flow in the app.

onion2k 6y ago
That sounds like the equivalent to React's forward refs. https://reactjs.org/docs/forwarding-refs.html https://reactjs.org/docs/forwarding-refs.html
- acemarke 6y ago
  No, that's very different, in two ways. 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.

tor291674 6y ago

No Nuxt 3 yet.