Vue.js v3 released (pre alpha) | Hacker News Reader

Vue.js v3 released (pre alpha)

github.com

130 pointslichtenberger90 comments

I’m using Vue as a UI for a desktop app for developer collaboration (https://aether.app), whose Vue part is about 60,000-70,000 lines of code. I guess this makes me a large, advanced user.

I don’t get it. Seriously, Vue 2 is great, so much fire and forget. There’s a bunch of problems that I am supposed to have, which justifies these changes, but I really don’t have them. Single file components solve it all for me.

This feels like Vue is trying to become React, but ... I’m using Vue because I think it’s much more valuable than React. I also get that it’s said that none of the things I like will change and I could just keep using it as is, but when was that ever really true - the new features always take more of the mindshare than keeping existing users.

This might be the curse of us all: the people who build successful things tend to be the most extreme users of their own thing. It helps you by making you have high standards at the beginning, but later on, if you keep serving yourself, you’ll end up with something like Angular where it eclipses past the sweet spot where most of the users are and goes for ever more advanced things with not so much of an audience, just because you’ve been solving your own problem and that has even a good metric thus far.

I hear you, we use this at work and this rings true to our experience as well. One thing though is recently we've started experimenting with typescript? Have you used that? I find that you have to jump through hoops to get typescript and Vue to work together. Looking forward to a form of Vue with better support there.

Yes, I'm using Typescript with Vue. As long as you accept that Typescript is an addition to JS, that is, most of the things you work on will not have Typescript on their own, you can 'gate' it to your parts (i.e. enforce and assert types on your boundaries) and have no problems with it.

It's only when people think of Typescript as a new language where everything must have types things start to go wrong — Javascript won't ever be that. There'll always be a tiny but super useful library from 2004 which has its jQuery dependency removed just 6 months ago, and won't ever get Typescript support, and you have to use it — and if you're a purist that's going to spoil your lunch.

Don't be a purist — a project using Typescript at 50% of its codebase is vastly better than one that uses it at 0%, even if all its asserts are :any's.

Vue is the backbone of our apps, not a small jquery library, good prop types and such is key to day to day work IMO.

I've been using vue, nuxt and typescript without any issues so far (6 months with TS though). It's not vue that's at fault for troubles with TS.

I'm curious, I'm maintaining a similarly sized React app. What are the benefits of Vue (2) over React?

It has a sane model for dealing with reactivity and doesn't insist on always using immediate mode. React runs into all these weird issues like stale closures because everything is always rendered every time. Vue just makes it all much simpler to grok because the setup function is only run once.

I couldn't agree more! I too use Vue.js 2 as what i would call an advanced user. I use it daily as my primary front-end framework.

I currently love Vue.js as it is. I have followed along with the fixes, improvements, and changes, and continue to think the same thing... "Am i just lucky that I never run into ANY of these problems? Am I using the framework wrong because I am NOT running into these issues?"

Like you, i mainly use single-file components. But to me, that is the best way to use Vue in an advanced project. So I have been wondering the same thing during this whole launch, "does anyone actually care about these changes or are we starting to make this beautiful framework into something that is unnecessarily complicated?"

I can't understand how this cycle of unnecessary complexity addition repeats over and over again. Indeed I find Vue 2 perfect as it is, and cannot see the motivation beyond these changes.

What changes are you talking about? Are you aware that Single File Components won't be removed? Asking because a lot of people on Twitter and Reddit seem to be under this impression that it's going away...

If you're talking about changing from the current v2 object syntax to v3 composition api might be hard indeed, then I agree with you... but I'm hoping we'll get some compatibility layer soon enough.

EDIT: According to Evan we'll get a "compat build" in the RC phase [1]

[1] https://medium.com/the-vue-point/plans-for-the-next-iteratio...

v2 object syntax is supoosed to be staying

I disagree. Making renderless components in Vue 2 is sort of a pain. It can be done, but it doesn't feel natural. I'll be happy to have it simplified. And if you don't want to use it, the options API will still be around.

I just love Vue. Maybe I never gave react enough of a chance, but I've almost never had any issues with learning or developing using Vue. React has always felt like chore. I'm still probably technically a junior dev, so I haven't gotten too far into the weeds. But I was able to put together a fully functioning point of sale web app with dotnet core and vue, and I'm still not totally sure how it came together so beautifully.

Holy crap, you wrote what I was thinking, except I've done web development since 2000. I've ditched all other javascript frameworks and am now all Vue, all the time (with a little vanilla js thrown in when needed).

Coincidentally, I've built a .NET core web app as well, with Vue.js handling nearly the entire UI. It's lightening fast since I'm letting .NET handle the backend and Vue handle the frontend. I built the entire thing on my little Macbook Air. Hit me up if you want to talk shop sometime.

I'm sure the ruby, python, rust folks are snickering...but .NET Core + Vue.js is an A-List webdev stack as fas as I'm concerned.

Our teams at my work have recently adopted this stack. We're now building 4-5 apps this way and I couldn't be happier.

What makes .NET core particularly notable in this pairing? I don't think any Ruby/Python/etc folks will be snickering, but if all we're talking about is a REST API (or similar) connecting to a Vue frontend then the idea is pretty backend agnostic.

I have written a few .NET Core web apps, some with React frontends and one with a Vue frontend.

I am using Blazor for the first time in a .NET Core 3 app and I don't think I can ever go back to a JS Framework. If you like Vue then give Blazor a try, it's similar component-wise except Razor components functions are C# instead of JavaScript.

Only downside is browser support as client-side Blazor is experimental and compiled to WebAssembly. Server-side Blazor streaming is GA though, and it is widly supported if your consumers generally have fast connections, such as Enterprise uses.

I can’t seem to find messaging on here. My email is shanemkunz@gmail. I send you what I’ve been working on.

Vue lands in the human-centric tool bag. It feels pleasurable enough to write for you. It's probably not as solid as react but it doesn't feel like a chore.

I'm assuming this is the wider full framework release, not just the new functional/composition api?

https://github.com/vuejs/composition-api

I've been using the above for the last month and it's a far superior way of building components IMO. I've been able to reduce the amount of unneeded observer watchers and tracked properties by about 50%.

The distinction between simple raw JS objects and functions and what are Vue-tracked/computed properties makes the whole thing feel cleaner.

Typescript integration is also much better and doesn't feel like a hack like the Class component approach did.

Plus the eventual tree-shaking benefits of importing only the parts you need is great.

Agreed. I'm in the middle of moving our code base over to the plugin above. I figured the Typescript + Decorators Component API was a dead end, so it'd be easier to transition from the plugin to Vue 3 when it eventually came out.

It's been a breath of fresh air when working with typescript.

It integrates just fine with old Vue 2 components. So the transition is very simple, much like Typescript.

I don’t think most people critiquing the new composition API have really tried it. This is not something you can get a good sense for just by looking at RFC API style docs.

It encourages better modern JS and simpler code which really matters in large projects. This brings Vue closer to simple JS functions instead of giant magic-y options interfaces, while still being fundamentally the same with templates/computed props/lifecycle/etc.

I just can't get on board with any of these front-end frameworks. Vue, Angular, and React all seem like they're trying to lock you into their toolset such that migrating away if they die in the future (or you just wanna switch) is impossible. Not just that, they lock your knowledge to those frameworks too, so you won't have a general knowledge of fundamental pieces of web design unless you study on your own time. It seems like a new take on embrace, extend, extinguish.

Don't all frameworks do this, even on the back-end? None of them are API compatible with each other.

Yes, they do, but for backend there is no common denominator, for the front end the end result is HTML, JS and CSS on the browser and it all comes to these three. THe only loose commonality on the backend that I can think of is the SQL to some point, but even that is a stretch. For front-end a framework or no-framework but manual HTML-JS-CSS will build you the same result in the end, just the amount of work is different.

Aren’t you building pyramids with grains of sand if you don’t use a framework? I can’t imagine how much manual work it would take to drop Vue.

Well you start with grains of sand, then a month in you build your own framework, which is clearly better than anything else out there. A year goes by, new devs start, and everyone hates the monstrosity that has emerged. Such is the software circle of life.

I still prefer that method. With frameworks I'm always worried if it's me or the framework when something goes wrong. You also don't have to worry about build tools or if npm update will suddenly break your application.

I have a personal project that's about 30k lines of jQuery on one page - if you want to see an example of what that looks like:

https://www.superanimo.com/editor

I would be really interested, but it just gives me a page not found...

Is it still 404 for you if you don't mind me asking? From what location?

Over the weekend AWS reported my instance health went to Bad for a bit not sure why.

Western Canada, but I don't think that's the problem. I'm on my phone, and just noticed it looks like it loads, then redirects to /mobile which is where the 404 actually appears. Switch my phone's browser to Desktop mode send to load fine, although a little awkward to use :)

Why do you comment out chunks of code? Aren't you using Git? :-/

Hah - yes I do. The project is just a mess. The main thing that makes this project work is this great scene-graph based animation library:

https://github.com/hyperandroid/CAAT

If it wasn't for that I would have never been able to stitch together a project as difficult as this.

The conclusion i reached is to build your website into multiple independant SAP. Keep the general flow on the server, have it load a different html page for sections that are independant, within which you’ll use whatever JS framework you want. This way you’ll be able to slowly build new components with new frameworks while migrating the old ones when you have the time.

This could be the argument against any framework (frontend, backend, animation, graphing, or anything else). At this point, I think you could back any of the major 3 frontend frameworks and feel confident that your project is safe.

I am not saying that something better isn't going to come along in the future. It almost certainly will... but React isn't going to disappear overnight. Just as jQuery is still being used and supported despite the fact that there is very little reason to use it anymore (most of it is natively supported with ES6/7/8 now) other than to support legacy projects.

No one got screwed over by using jQuery. It made life a lot easier for developers for many years until many of its' features were developed into newer versions of Javascript. Many corporations have converted jQuery codebases to using React/Angular/Vue. It serves a far less valuable purpose now, but no one is worse off for having used it during those years.

You really should be using one of these frameworks. If you aren't then you are doing A LOT of extra work that doesn't need to be recreated. There are mature frameworks that have figured it out for you and to not take advantage of that is only hurting yourself. They are most likely doing a better job at things like databinding than you will ever do yourself because they have teams of people all around the world contributing to it.

Part of being a developer is knowing that you can't do it all yourself. The expectations we have make it impossible to sit down and write every line of code yourself and get a project done to the expectations of our employers, clients, or ourselves in a reasonable timeframe. I understand the fear of spending time learning something like Vue or React and then needing to learn something else in 2-3 years. But then that thing that replaces Vue/Angular/React in 3 years will only last itself for another 3 years. If you keep waiting for the permanent framework to come around then you will die waiting for it to happen. Part of being a developer is constantly learning and adapting to this ever-changing landscape. Right now React/Vue/Angular are pretty important in any front-end project on the web now and not learning them is only hurting yourself and your career.

Leaning assembler, Cobol and Turbo Pascal as my first languages, the "React isn't going to disappear overnight" made me smile: not overnight, but in the current times the fragmentation and short lifespan of every language or framework makes things worse, not better. There are bank systems still running on very old platforms and languages and these companies saved billions of dollars not changing every 3-5 years to the "framework of the day with free soda and a pancake".

Btw, I kind of like Vue, just confirming the idea that frameworks may not be the best thing since sliced bread. They can be great with some conditions that are not met. Now, they are throwaway, like jQuery you correctly mentioned.

There is a great book from 1991 called "Programming as if People Mattered." What I took from it is that UI programming has always been a mess compared to backend, in part because the domain about people, which is just an intrinsically more complicated thing to deal with. Knuth created the Knuth shuffle and now no one needs to do that again. But every UI has to recreate what Fitt's Law means for their paradigm. It's a different kind of thing.

The other point I would add to what you wrote is that five to ten years ago, we were all going crazy watching new JS frameworks come out every other week, like Ember and Knockout (to say nothing of the Grunt vs. Webpack war). It was impossible to keep up with everything going on in JS. AMD → Require → Import. Callbacks → Promises → Async. There were a ton of language evolution changes going on.

Today, things are much more stable. The big choice is React or Not React, and then Not React breaks down into the clones (Preact) and improvements (Vue, Svelte) over standard React. It's not the Wild West anymore. Similar concepts apply everywhere, and you're not taking the same kind of gamble by using a particular component framework that you were back then. The only old browser we still care about is IE11, and that's on a death clock. We're very close to entering the module JS Promise land. If web components ever gets sorted out, we'll even have compatibility of the different frameworks. It's becoming saner.

Haven't embrace, extend, extinguish always been used in a malicious way? I can't for the life of me figure out why any front-end framework would want to maliciously kill of javascript / web-design...

Also, I don't know if I'm just not understanding your full complaint properly, but personally I have not found your claims to be accurate, at least in my situation.

I use Vue and I feel like I've only gotten better with JS & general web-dev since. I occasionally startup smaller projects where I don't use any frameworks & I have not experienced any negative repercussions from my framework usage.

I'm mostly a backend dev, but I have sort of an app idea that I'd like to work on the side. It would be a website on top of Firebase.

I was looking at Vue the other day but it seem to have the same issue for me as the other major frameworks: they need a lot of ceremony to start working with it and has a quite steep learning curve at the beginning.

Since I don't plan to scale my app to a global level, can anyone recommend Vue to pick up or should I look elsewhere?

You don't have to go all in on the insane build toolchain/component template memes. Vue can be used standalone just like Angular 1.

I think it's doable (I'm also a backend dev and started a frontend a few days ago). But I guess it would be great if you also get some help to begin.

However, maybe we should use https://www.npmjs.com/package/@vue/composition-api instead of giving Vue.js 3 a try if some things are simply not implemented as of now.

I have used Vue to simplify some enterprise pages of unholy jquery. Vue is added as a single js file in the header, and I call 'new Vue' on a div element. I do not get .vue files, i can't use fancy vue compenents i see online, and a few other things, but it worked really well for my use case. I used vue to replace ~400 lines of jquery with 80 lines of very clean code. Use what you need, and leave the rest.

Even doing it that way you still can use the fancy components you see online.

> I used vue to replace ~400 lines of jquery with 80 lines of very clean code. Use what you need, and leave the rest.

I tried using Vue, and started by trying to replace a small 100 line Jquery component and it quickly turned into 300 lines of Vue code. Like eating broccoli, I know that using Vue over Jquery is good for you, but it's still hard to swallow that first bite.

I highly recommend vue. Bare minimum is to stick the js file in your html and you can start writing vue code. You technically don't need the whole node/npm ecosystem. In fact, even for more advanced Single File Components in vue (.vue files), I found this excellent library that does not require npm/node stuff :

https://github.com/FranckFreiburger/http-vue-loader

- @vue/cli to set up your project and make development a breeze. The only add-on you probably need during set-up is vue-router.

- SFC (single file components) are your friend

- Skip vuex until you need it

Everything else (what makes up a component: props, data, getters; v-if, @click, etc.) should probably take a day to get familiar with.

I'm also a mostly backend dev (C#) and Vue didn't take too long to get started. Outside of getting node/yarn set up on my machine, I was able to create a project and start fiddling with Vue pretty quickly.

I found https://www.taniarascia.com/getting-started-with-vue/ as a better initial starting point compared to the Vue website.

I've been using Vue for the past few weeks on a for-fun project and have been loving it once I grasped the basic concepts.

I need to check this out, I've had such trouble making the jump from the official tutorial.

Disclaimer: these are highly debated things and there's no definitive answer except "what works best for you". So I'll just tell you what worked best for me.

If you know typescript I'd recommend angular (v. 7 or up). It's most likely the one with the steepest learning curve, but at the same time it offers an out-of-the-box solution, with a very complete CLI, so you can actually start right away with a full front end app that has everything you need. You can bother understanding the underlying layers well past you release your app. To accomplish the same with react and Vue you need to add libs or frameworks, so you need to be more aware of all the tech involved. So in the end there's a learning curve here as well.

Another good reason to pick angular IMHO is that you actually can ignore it. This is rarely discussed. You can basically write your app as you would do in nodejs (with TS of course) and rely on angular only for the UI. I import my non angular code in the components TS files and handle the logic of the app without nearly any angular service. The only angular services I use are those for routing and state management (redux), and to use them in non angular code (e.g. Classes) I refer the object of the service on a property of a custom constant object, and thanks to the fact that JS references objects, I simply import in my classes my custom constant.

import { stateData } from ...

...

stateData.redux = this.redux

...

Somewhere else:

stateData.redux.store ...

Agree with above, Angular even published a way to deploy your app to firebase just by typing a simple cli command.

I learned Vue first because I didn't want to have to learn a reactive framework and Typescript at the same time. I've made several 'complete' apps with Vue / ES6 and .Net Core.

For a new job possibility I have now been learning Angular and Typescript and I am really liking how much Typescript simplifies the boilerplate of components etc. My angular components are much more readable than my deeply nested Vue components.

There are some class component plugins for Vue 2.x but it seems that this is being dropped now for 3.x in favor of composition functions. Looking at code samples it seems to mix the worst of both worlds to me.

I'm liking how much less cognitive load I've had with just going the 'angular way' whereas with Vue I had to make a lot of decisions for your basic needs (HTTP data access, form validation etc.)

Yeah, I'd recommend it. Although you CAN do all the ceremony you referred to and setup a complicated build environment, etc... Vue doesn't require it and can be used fairly effectively using a simple setup.

I made a little jsFiddle for you to demonstrate. This is just including the Vue.js library on the page and using it to do stuff. No build environment or anything.

https://jsfiddle.net/mjbvn0ts/4/

Yeah the nice thing about Vue is you can basically add it to existing HTML and import it via CDN, you can skip the build step entirely. This makes it really easy to get started.

If you're not planning on building a large app, I'd say it's a better choice than React for that alone. React excels at scale versus its rivals, but Vue is much easier to jump into and be immediately productive with.

I'm a sysadmin with a mixed knowledge in C, PHP and Javascript

my first time both with Vue and the whole webpack & npm world went like this:

Day 1 I didn't understand anything

Day 6 I started getting confortable with the stack

Day 30 had working prototypes for a multilanguage site

One year later I have made three websites with about 1K visitors a month, and two vue-electron 'apps', one of them being a Digital Signage client for large videowalls at work. It is strange in the beginning, but if you have programmed before, it gets easier as you work with it quite fast

As a fellow backend developer, I found Vue to be the absolute perfect entry-point to the world of frontend frameworks. If you set up your project with Vue CLI v3 then it automates all the setup and even offers a web interface called "Vue UI" for managing your app, it's plugins, and NPM packages. It's a dream.

Suddenly, I don't hate JavaScript anymore.

My issue has been going from the tiny little examples in the official tutorial to a medium-size app, I always get hung up on how to structure my files and code what belongs where yadda yadda.

The most common way I see on the wild is by separating in categories:

  - package.json
  - src
    |- main.js
    |- components
       |- pages
       \- widgets
    |- directives
    |- helpers
    |- mixins
    |- router
    \- store

This works for both small projects (but you might not have directives/mixins/router/store) and larger projects (but you might have to add more subfolders inside components/pages because you will start breaking down components).

Svelte is a better choice IMHO. There is little to no ceremony or learning to get started (and you don't need a ton of files). I could never get into React or Vue (the "right" way) because of this.

Right. I tried to like Vue, but learned about Svelte around the same time. The idea that it compiles the javascript application resonates with me.

I'm not up enough on the differences/advantages with the approach that Svelte takes. But as a backend developer myself, this seems more intuitive and probably has some advantages in terms of performance.

I just wish there was TypeScript support.

Of all the three major frontend frameworks, Vue has the easiest and quickest setup time.

On the simple end you can pull the framework from NPM or a CDN and insert it into your HTML. Then insert a script tag with your data and methods to use for Vue. That is really it. 2-way databinding is as simple as adding a `v-model` to your html tags like your inputs.

Of all three, you will find Vue has the least amount of "ceremony" to get started.

Of course as you get into advanced projects you probably want to start working with something like Nuxt.js (for Vue) or Next.js (for React). These have a lot more setup and learning.

But on a simple level Vue is pretty dead-simple to use. Far easier to use than React in my opinion.

Have you tried Gridsome? I found it more intuitive than Nuxt and it produces much faster sites out of the box.

Just throwing my $0.02 into the ring - Vue struck me as incredibly easy to use. That was after learning AngularJS and some basic React stuff, and none of it felt natural or made sense.

Something about Vue is just.. simple. I picked up on it lightning quick and it reignited a fire I'd lost for development. I even did a bunch of side projects because of _just how quickly_ you can crank out code.

React I was writing all sorts of bogus looking JSX and it made me want to throw myself off a cliff, AngularJS was so.. verbose.. (granted it's very outdated by today's standards and of course modern Angular), but Vue actually made me spend my free time writing code again.

It really is excellent - download vue-cli and give it a shot. The HelloWorld app it'll generate is crazy simple, you literally need to mess with like 2 files right off the bat, and both are super self-explanatory.

And single-file components are crazy convenient and powerful.

Current Vue does a great job of separating templates, script and styles in a way that gives it a beautiful developer interface.

This is in contrast to React which squishes the three into one monolithic class in it's .jsx (versus .vue's deeper seperation which leads to easier debugging).

Vue3 will release a monolithic syntax where you can combine script, styles and HTML all into a class - I don't think this is the correct direction for the framework to go.

Developer interface is just as important as internal functionality and performance. Let's not forget that.

Yes, this is my concern as well. From day 1 though, I considered Vue to be a tech-debt investment as a trade off for fast development. (looks like that day is here already, time to prepare to update code in the next couple years for v3)

Maybe in the next few years browsers will add some kind of reactivity to the DOM by default? And Vue/Angular/React will be less required to get up and running quickly with something small. And I think this would hit Vue 2.x the hardest.

This is pure FUD.

You can already write a render method. In vue 3 the use case will be the same and most people will be using template tags in their single file components same as today.

The big change is that the availability of a new js api for the component. This is optional, and seen as an advanced use case, or for people who need better typescript support, etc.

How do you do when you have tightly coupled CSS, HTML and JS/TS?

You didn't see this coming considering how long they've been pushing the "Single File Component" narrative?

https://vuejs.org/v2/guide/single-file-components.html

Why separate something from state, just to mix the view with pseudo code and injected state again. That isn't what separation of concern meant. React separates state from the view, because both should be apart, but the view and the code that forms it belong to the same logical layer, called the view layer.

It never did squish styles into a monolith. Strangely, that is exactly what Vue does with SFC, do you use Vue without?

>This is in contrast to React which squishes the three into one monolithic class in it's .jsx

What exactly are you talking about here?

First, React is (largely) no longer class-based.

Second, it's completely unopinionated about styles. You can write your own classes, use CSS-in-JS, whatever. Nothing about React components is concerned with styles at all, let alone forcing you to structure them a certain way. Vue is, if anything, way more opinionated about styles.

> Vue3 will release a monolithic syntax where you can combine script, styles and HTML all into a class.

Nope.

This was already possible in Vue 2, and Vue 3 is not dropping Single File Components at all. In fact most recent demos showed Single File Components [1].

And Evan You announced that the Class API is cancelled btw [1]

[1] https://www.youtube.com/watch?v=E43SqPADf3k

Does it have typed templates?

I use Vue with Vue HTML templates + TypeScript, and all my bugs collect around the layer between the TypeScript code and the templates because the templates aren't typed.

You can use JSX to get typing but you run into hurdles going against the grain of how Vue is normally used.

Vetur has experimental typed template support

I don't get the point of the HTML style templates to be honest. JSX already works, can be typed, hooks in with existing JavaScript refactoring tools, can make use of existing JavaScript features like variables and functions etc.

Why reinvent it all so you can write something that looks a bit more like regular HTML? Is there some benefit I'm missing?

I am being lazy but does anyone know if this will be backward compatible ? We are quite happy with vue 2.x and want to ensure that upgrading to 3.x won't break anything.

I think the goal is feature parity. It is going from 2-3 so I would expect some backwards incompatibility. I know they plan on shipping a separate compiler just for IE11 if you need support for that browser. The new reactivity model is driving that decision.

Yes, Vue.js 3 will fully support all 2 syntax.

Is Vue gaining or at least maintaining momentum? Do you think it will fade against React? Asking as an outsider (still using plain JS and some jQuery here and there)

I do get a lot of job offers, especially from European companies, just because the word "Vue" appears a lot in my LinkedIn resume. Some friends are getting good offers too.

I guess it's more popular in Europe and China than in the US.

I've also seen a lot of new startups that use Laravel or .NET using it too.

Npmtrends is a pretty good source: https://www.npmtrends.com/react-vs-vue-vs-@angular/core-vs-@... Vue has carved out a huge piece of the browser market, but it appears to have reached its peak.

React is hard to stop at this point as it swept over to other platforms. If it really gets to drive platforms with a single component standard and a unified events system, on the web, ios, android, windows, mac, linux, then i don't think a web framework will hold against this much longer tbh.

I'm hoping that the event listeners on dom elements can be improved slightly so that if I have an element with an @click listener, it will just create one listener for the whole site, rather than one for each instance of that component. I tend to fall back to jQuery event listeners on the document and listen for clicks on elements with a specific class if I know there will be a lot of instances.

Does it even improve performance when you include jquery?

https://github.com/dgraham/delegated-events

If I'm reading this right it looks like v-model, v-on, and the like aren't implemented yet. Is there something new that replaces it?

This is pre-alpha. They just finally opened the repo to the public for contributions. I don't believe they are replacing any of that, just not implemented yet.

What's the support for hot-reloading in Vue 3? (as in Fighweel for example), i.e. state survives re-loading of component code, so you can see your changes right away without any navigation action.

This used to kinda work with Vue 2 by passing down all your state through props.

If we get some documentation I'd love to use it for a brand new front-end (idea) for https://sirix.io:

https://github.com/sirixdb/sirix-web-frontend

https://dev.to/johanneslichtenberger/working-on-a-versioned-...

https://dev.to/johanneslichtenberger/building-a-web-frontend...

However, I'm in need of some help, as I'm completely new to web front-end development :-)

probably better off using the latest stable version with the composition api package if you're looking to start using the vue 3 syntax. https://www.npmjs.com/package/@vue/composition-api

Probably better, hm. But as SirixDB itself is in a kind of pre alpha state I think if we encounter a few bugs it would be okay or even slight API changes.

Reply on news.ycombinator.com