
Vue.js v3 released (pre alpha) - lichtenberger
https://github.com/vuejs/vue-next
======
rolleiflex
I’m using Vue as a UI for a desktop app for developer collaboration
([https://aether.app](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.

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

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

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

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

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

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

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

[https://github.com/vuejs/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.

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

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

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

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

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

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

------
htamas
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?

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

Like

import { stateData } from ...

...

stateData.redux = this.redux

...

Somewhere else:

stateData.redux.store ...

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

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

~~~
ratww
> 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](https://www.youtube.com/watch?v=E43SqPADf3k)

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

~~~
lowincome
Vetur has experimental typed template support

~~~
seanwilson
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?

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

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

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

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

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

~~~
earthboundkid
[https://github.com/dgraham/delegated-
events](https://github.com/dgraham/delegated-events)

------
dsissitka
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?

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

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

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

[https://github.com/sirixdb/sirix-web-
frontend](https://github.com/sirixdb/sirix-web-frontend)

[https://dev.to/johanneslichtenberger/working-on-a-
versioned-...](https://dev.to/johanneslichtenberger/working-on-a-versioned-
temporal-nosql-document-store-during-hacktoberfest-pp4)

[https://dev.to/johanneslichtenberger/building-a-web-
frontend...](https://dev.to/johanneslichtenberger/building-a-web-frontend-
with-vue-js-v3-typescript-and-d3-js-during-hacktoberfest-1hbi)

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

~~~
STRiDEX
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](https://www.npmjs.com/package/@vue/composition-api)

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

