Plans for the Next Iteration of Vue.js
medium.com
Plans for the Next Iteration of Vue.js
1–10 of 152 posts
Re: Plans for the Next Iteration of Vue.js
#2Looking forward to better type support. Just started using Vue about a week ago and my main complaint is the lack of any nontrivial type checking. Basically, types are only checked within the context of a single script block, I can’t ensure my props are the right type, or that my event handlers are expecting the right types.
Re: Plans for the Next Iteration of Vue.js
#3One thing I was finding weird about all those template compiling frameworks is the use of javascript for parsing the page/template instead of the lightning fast browser's native parser (DOMParser)
Can somebody shed some light on that design decision?
Re: Plans for the Next Iteration of Vue.js
#4As someone who writes complex applications on the client side, I welcome a lot of the changes coming up for the next release and they are seriously anticipated.
Anything that positions JSX for Vue to be similar to that of React would be awesome for me.
I have some issues with relativity with deeply nested JSX templates. Unfortunately I wasn't able to get any help from the discord channel as most are opposed to JSX, couldn't understand my code and also state I'm doing it wrong and should use Vue components. (sigh)
In one SFC, I have over 500 instances of this.$set, really looking forward to proxies.
Finally, iframe support isn't as mature as in React. Sure there is [0] but libraries such as VideoJS [2] don't work correctly. Thus you need another Vue instance inside the iframe and have postMessage communicating updates between both data Objects with something like [1]. Which ulimately slows down the UX.
[0]: https://forum.vuejs.org/t/render-inside-iframe/6419/2
[1]: https://gist.github.com/pbojinov/8965299
[2]: https://forum.vuejs.org/t/videojs-not-rendering-inside-using...
I should mention, I do love Vue, it's awesome and a major step up from something like jQuery.
-------
Maybe someone from the core team comes across this or someone might know [4].
Taken from the: State of Vue by Evan: [3]
He mentions 4 release channels:
- Stable
- Beta
- Nightly
- LTS
Would really like to see if 2.6-next beta/nightly fixes these issues.
How can I get my hands on such a release?
Re: Plans for the Next Iteration of Vue.js
#5One thing I was finding weird about all those template compiling frameworks is the use of javascript for parsing the page/template instead of the lightning fast browser's native parser (DOMParser) Can somebody shed some light on that design decision?
Virtual DOM tends to be faster because bridging between JS and native layers can be expensive. If diffing is done in the JS layer, some potentially expensive calls can be batched or ignored if a change is unnecessary.
Re: Plans for the Next Iteration of Vue.js
#6Impressive list. I wonder if they can maintain the lean size. If so how faster will it be ?
Re: Plans for the Next Iteration of Vue.js
#7All I'd like to see is just better error reporting and debugging
Re: Plans for the Next Iteration of Vue.js
#8Written in TypeScript and with TS type support in mind! That was the thing missing for me to look at Vue, looking forward to the release.
Re: Plans for the Next Iteration of Vue.js
#9Written in TypeScript and with TS type support in mind! That was the thing missing for me to look at Vue, looking forward to the release.
This was the only thing stopping me from using it in larger projects. Can't wait to see how it plays. Hopefully the class-based interface has no weird object notation (methods, props, computed) and uses decorators like Angular.
Re: Plans for the Next Iteration of Vue.js
#10One thing I was finding weird about all those template compiling frameworks is the use of javascript for parsing the page/template instead of the lightning fast browser's native parser (DOMParser) Can somebody shed some light on that design decision?
Virtual DOM tends to be faster because bridging between JS and native layers can be expensive. If diffing is done in the JS layer, some potentially expensive calls can be batched or ignored if a change is unnecessary.
I mean why they use it at the stage when they create their own virtual DOM copy from the template string, not during the time they do changes when the app is running.