10 ms·

Vue.js v3 released (pre alpha)

130 points by lichtenberger 7y ago

lichtenberger 7y ago
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-temporal-nosql-document-store-during-hacktoberfest-pp4 https://dev.to/johanneslichtenberger/working-on-a-versioned-... https://dev.to/johanneslichtenberger/building-a-web-frontend-with-vue-js-v3-typescript-and-d3-js-during-hacktoberfest-1hbi 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 :-)
- STRiDEX 7y ago
  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 7y ago
    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.
dmix 7y ago
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 7y ago
  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 7y ago
    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.
CryoLogic 7y ago
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.
- Vanderson 7y ago
  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.
- ehutch79 7y ago
  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.
- The_rationalist 7y ago
  How do you do when you have tightly coupled CSS, HTML and JS/TS?
- plausibilities 7y ago
  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 https://vuejs.org/v2/guide/single-file-components.html
- 7y ago
dsissitka 7y ago
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 7y ago
  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.
codegeek 7y ago
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.
- nek4life 7y ago
  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.
- nwsm 7y ago
  Yes, Vue.js 3 will fully support all 2 syntax.
shanemlk 7y ago
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 7y ago
  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.
  - neilsimp1 7y ago
    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.
  - untog 7y ago
    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.
    - deleted 7y ago
      [deleted]
  - caleblloyd 7y ago
    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.
htamas 7y ago
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?
- makotech222 7y ago
  Vue is super light-weight. You can drop the Vue.Js file on the page, put up a simple viewmodel, and you're done. No need for complicated Webpack-esque build systems (unless you want Single-File-Component Vue).
- amiga-workbench 7y ago
  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.
- lichtenberger 7y ago
  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 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.
- cubedrone 7y ago
  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.
  - james_s_tayler 7y ago
jimbob45 7y ago
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.
- amiga-workbench 7y ago
  Don't all frameworks do this, even on the back-end? None of them are API compatible with each other.
  - AdrianB1 7y ago
    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.
- randomsearch 7y ago
  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.
  - mrinterweb 7y ago
    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.
  - mrieck 7y ago
    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 https://www.superanimo.com/editor
seanwilson 7y ago
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 7y ago
  Vetur has experimental typed template support
  - seanwilson 7y ago
    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?
rolleiflex 7y ago
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 7y ago
  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 7y ago
    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.
edgarvaldes 7y ago
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 7y ago
  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.
- mlsarecmg 7y ago
  Npmtrends is a pretty good source: https://www.npmtrends.com/react-vs-vue-vs-@angular/core-vs-@angular/core-vs-angular 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.
wensley 7y ago
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.
- omnimus 7y ago
  Does it even improve performance when you include jquery?
- earthboundkid 7y ago
  https://github.com/dgraham/delegated-events https://github.com/dgraham/delegated-events
beders 7y ago
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.

130 points by lichtenberger 7y ago

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-temporal-nosql-document-store-during-hacktoberfest-pp4 https://dev.to/johanneslichtenberger/working-on-a-versioned-... https://dev.to/johanneslichtenberger/building-a-web-frontend-with-vue-js-v3-typescript-and-d3-js-during-hacktoberfest-1hbi 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 :-)

STRiDEX 7y ago
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 7y ago
  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.

dmix 7y ago

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

CryoLogic 7y ago

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.

Vanderson 7y ago
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.
ehutch79 7y ago
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.
The_rationalist 7y ago
How do you do when you have tightly coupled CSS, HTML and JS/TS?
plausibilities 7y ago
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 https://vuejs.org/v2/guide/single-file-components.html
7y ago

dsissitka 7y ago

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

codegeek 7y ago

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.

nek4life 7y ago
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.
nwsm 7y ago
Yes, Vue.js 3 will fully support all 2 syntax.

shanemlk 7y ago

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 7y ago
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.
- neilsimp1 7y ago
  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.
- untog 7y ago
  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.
  - deleted 7y ago
    [deleted]
- caleblloyd 7y ago
  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.

htamas 7y ago

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?

makotech222 7y ago
Vue is super light-weight. You can drop the Vue.Js file on the page, put up a simple viewmodel, and you're done. No need for complicated Webpack-esque build systems (unless you want Single-File-Component Vue).
amiga-workbench 7y ago
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.
lichtenberger 7y ago
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 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.
cubedrone 7y ago
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.
- james_s_tayler 7y ago

jimbob45 7y ago

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.

amiga-workbench 7y ago
Don't all frameworks do this, even on the back-end? None of them are API compatible with each other.
- AdrianB1 7y ago
  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.
randomsearch 7y ago
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.
- mrinterweb 7y ago
  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.
- mrieck 7y ago
  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 https://www.superanimo.com/editor

seanwilson 7y ago

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 7y ago
Vetur has experimental typed template support
- seanwilson 7y ago
  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?

rolleiflex 7y ago

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

edgarvaldes 7y ago

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 7y ago
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.
mlsarecmg 7y ago
Npmtrends is a pretty good source: https://www.npmtrends.com/react-vs-vue-vs-@angular/core-vs-@angular/core-vs-angular 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.

wensley 7y ago

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.

omnimus 7y ago
Does it even improve performance when you include jquery?
earthboundkid 7y ago
https://github.com/dgraham/delegated-events https://github.com/dgraham/delegated-events

beders 7y ago

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.