13 ms·
Plans for the Next Iteration of Vue.js
- jakear 8y agoLooking 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.
- honopu 8y agoAs you know, you have to register your props. You can do this in the array shorthand where you don't get to specify anything except the prop handle, or via an object with the key being the prop handle and an object with type:Function,Array,String etc. and a required property which can be true or false. You can also provide a default value here. Hope that helps!
- jakear 8y agoI use the decorator (“@Prop”). If that doesn’t emit the appropriate types I would be very surprised, but then again the class style syntax has always seemed to be a bit of an afterthought, so perhaps I wouldn’t be too surprised. But regardless are those not purely runtime checks? I was of the impression that Vue would just print something to console if you messed up there, not issue an error at build time. (And playing around with an existing project it looks like it indeed does not error at build time. That or the “@Prop” decorator doesn’t do what I’d expect it to)
- jakear 8y agoYes trying with a fresh, TS-free, default setup of Vue, the props are still verified only at run time.
- baybal2 8y agoOne 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?
- rpastuszak 8y agoVirtual 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.
- baybal2 8y agoI 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.
- LukeShu 8y agoIMO, with Vue if your template needs to be parsed in-browser, you're doing something wrong (Vue has "full" and "runtime-only" builds; I don't think that you should use the full build in production). The template should be parsed+compiled to a render() function during the build process, and the browser should only ever see the render() function, not the template (except through a source-map).
- rk06 8y agoVue 1 used to do that. It caused issues, specifically, the svg attributes are camelCased and DOMParser would convert them to lowercase when used with v-bindings. So, Vue2 come up with its own parser to mitigate the issue.
- ricardobeat 8y agoThere are other approaches: Svelte compiles directly to DOM operations, choo/Marko use the native parser through morphdom, hyperhtml and lit-html use string literals and Template instances. Most of them are faster than React and Vue but nowhere as popular.
- no1youknowz 8y agoAs 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 https://forum.vuejs.org/t/render-inside-iframe/6419/2 [1]: https://gist.github.com/pbojinov/8965299 https://gist.github.com/pbojinov/8965299 [2]: https://forum.vuejs.org/t/videojs-not-rendering-inside-using-linus-iframe/44139 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? [3]: https://youtu.be/AiF3XOu02-0?t=1845 https://youtu.be/AiF3XOu02-0?t=1845 [4]: https://i.redd.it/0soip7wqxth11.png https://i.redd.it/0soip7wqxth11.png
- erikpukinskis 8y agoWhat does React do with iframes? I don’t understand how you could have a component in an I frame without having two instances of React either.
- no1youknowz 8y agoCheck the article here [0]. [0]: https://medium.com/@ryanseddon/rendering-to-iframes-in-react-d1cb92274f86 https://medium.com/@ryanseddon/rendering-to-iframes-in-react...
- 8y ago
- agumonkey 8y agoImpressive list. I wonder if they can maintain the lean size. If so how faster will it be ?
- jaequery 8y agoAll I'd like to see is just better error reporting and debugging
- enraged_camel 8y agoEh, debugging experience is already great. Vue Dev Tools is just phenomenal. Is there something specific you are looking for that is not addressed in the article? (e.g. they are adding render tracking)
- spiffytech 8y agoMy stack traces for JS errors inside component methods often stop at "This component had an error", with no line numbers or context to indicate which method had the error.
- honopu 8y agoI also have the same issue. I don't know what to do to resolve it. It's not a deal breaker but it would be nice to have it unwind the stack a little bit.
- jazoom 8y agoThis was the only thing I missed when I moved over from React 2 years ago. Vue's error messages are relatively useless, and they haven't ever improved much.
- Keats 8y agoWritten 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.
- lazarljubenovic 8y agoThis 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.
- Semaphor 8y agoWith the current TS helpers you have: @Prop myProp!: string; get myComputedGetter(): string {… set myComputedSetter(val: string) {… myMethod(in: number): string {… @Watch('property') methodToCallOnChange() {… And a bunch of decorators to connect vuex actions etc. I assume the Vue3 version will be similar
- jwdunne 8y agoYeah this is great. Last time I tried, Vue itself wasn't too bad to get going with TS. The real issue for us was Vuex. The official examples and the Typescript examples we found looked completely different. It wasn't easy to get started. We actually moved to React + Redux since it was early enough in the project to make that decision. Typescript support is much better there. If typescript support was better in Vue/Vuex, I doubt we'd have made that decision.
- lazarljubenovic 8y ago> Vue itself wasn't too bad to get going with TS Last time I tried, there wasn't any support for type check across component boundaries (props, events). Did something change? A deal-breaker for me. I mostly know types from within the component; if you keep them small enough it's not much of an issue to just look up/down to check for a name, for example. But cross-component communication is where I need TS the most. Hopefully 3.0 addresses that (didn't read the whole article thoroughly, maybe it's mentioned).
- faitswulff 8y agoNice performance improvements: > The constant baseline size for the new runtime is <10kb gzipped. > Faster: on preliminary benchmarks, we are seeing up to 100% performance improvement across the board, including raw Virtual DOM mounting & patching (we learned quite a few tricks from Inferno, the fastest Virtual DOM implementation out there), component instance initialization and data observation. 3.0 will shave off half the time spent in JavaScript when your app boots up.
- another-cuppa 8y agoI'd been out of the loop of frontend Web stuff for several years but I tried Vue.js because I read here and elsewhere that Angular was a mess. I just couldn't stand the weird hybrid html/css/js editing. At no point did I feel I had the slightest clue what was going on and it felt like I wasn't supposed to ask. React felt much more natural to me. Is there any way to do stuff differently with Vue or should I just stick with React?
- avip 8y agoI'm not sure what you call "hybrid html/css/js editing". Vue components are stored in single .vue file (newer angular versions also default to SFC). Within said .vue file, HTML/CSS/JS are very obviously separated. Scoped style and templates are very easy to reason about and manage, IMHO, as an underqualified front-end developer.
- mlevental 8y ago>At no point did I feel I had the slightest clue what was going on and it felt like I wasn't supposed to ask what exactly do you mean? you didn't understand the templating language? you didn't understand the data model? you didn't understand webpack? what does "i didn't have the slightest clue what was going on" even mean? do you know what gcc does when it compiles your C code to assembly? is that the resolution at which you'd like to know "what's happening" ???
- another-cuppa 8y agoIt's hard to explain. I know how the web works. I used to write HTML in Notepad many years ago. With Vue I just didn't know how the stuff I was writing was turning into the stuff that the web browser actually sees. React is just a JS library that you can add on to your HTML and CSS and makes sense in the standard model. I guess with Vue I just don't feel in control any more, and that's a big no for me.
- vezycash 8y agoIt's usually React that people complain about. If you like jQuery, you should like vue. Cause, you can use vue just by adding a script tag in your web page. You don't need command line, web pack or any other tool to use most of vue.
- petepete 8y agoThe ability to split Vue components into multiple (html, ts, scss) files in a single directory would be nice. I dislike the single file approach and it makes things like having nice syntax highlighting and completion more complex than it should be.
- rhengles 8y agoAnother one here building a simple architecture to build Vue components in a folder instead of a file, you can check it out here: https://unpkg.com/@arijs/vue-generator/outra/pagina/index.html https://unpkg.com/@arijs/vue-generator/outra/pagina/index.ht... https://github.com/arijs/VueGenerator https://github.com/arijs/VueGenerator
- atentaten 8y agohttps://vuejs.org/v2/guide/single-file-components.html#What-About-Separation-of-Concerns https://vuejs.org/v2/guide/single-file-components.html#What-...
- rhengles 8y agoHaving to repeat the component name in the "src" is less than ideal, IMO.
- jvanveen 8y agoUsing such an approach in this project: https://github.com/garage11/ca11 https://github.com/garage11/ca11 You can just use the vue template compiler for that.
- jazoom 8y agoI've been doing that for years in one of my projects. Just reference the CSS and JS files in the .vue file (e.g. <script src='./file.js'></script>) instead of inlining them in their respective tags. How else would you want to do it?
- petepete 8y agoI'd just like a directory containing a template, style and code file, the referencing would be straightforward to imply without having to repeat everywhere. Similar to how views work in Rails I guess.
- russellbeattie 8y agoI'm really worried about the wholesale move to Typescript in so many projects. To me it's the new coffeescript combined with the verbosity of J2EE. Yes it's corporate sponsored, so hopefully will be maintained indefinitely - but I like JavaScript, and Typescript isn't JS. What's worse is so many developers using their own slightly tweaked versions of JavaScript. I spent a solid day this week trying to get decorators and class fields to transpile reliably with as few dependencies as possible. It seems every project creates their own DSL that sorta-kinda is JS, then figures out a way to get it to compile and calls it a day. This sort of goes against the whole reason we have language standards in the first place. Anyways, I admire Evan's desire to hold back on the need for decorators and class fields, but since he's developing the project in Typescript, I have little faith that any of the projects that use Vue will avoid them.
- mo1ok 8y agoYep, this is a huge problem in the ecosystem right now. The irony is that JS, an interpreted language, is becoming slower to compile than some of the newer compiled language (i.e. golang, which compiles to machine code and therefore avoids all compatibility issues).
- klodolph 8y agoGolang doesn't avoid all the compatibility issues. On the contrary, there's a ton of Golang that won't run on anything but Linux.
- aczerepinski 8y agoCan you expand on this? I’ve used a decent amount of Go packages and they all run as expected on my Mac.
- ndnxhs 8y agoProbably stuff that hardcodes paths like /tmp
- 8y ago
- nikkwong 8y agoWow, hats off to the vuejs team. Vue is already lightning fast and I've been able to pull off some pretty computationally intense state changes which render like butter whilst other frameworks lagged. A speed increase of 100% is almost unimaginable—but welcome!
- Someone1234 8y agoSeems like they're repeating the mistakes of Angular 2.x+. Breaking backwards compatibility and adding a ton of tool requirements and libraries for basic usage. We're still stuck on Angular 1.x for exactly that reason. They also seem like they're going to drop IE10/11 support (ES2015 everything) thus either pushing the tool/library requirement even higher or simply not working on older browsers. Vue.js was attractive because it was the anti-Angular 2.x, it was light weight, simple, and with nearly no requirements (on either browser or developer's machine). Now they'll just be a "me too!" Angular 2.x clone, but with a smaller community.
- skybrian 8y agoDo you know any of that for sure? Maybe you should be asking more questions?
- Someone1234 8y agoIf you have something you want to contribute I'd prefer if you just did so. I don't feel like you're asking either question in good faith. I got my information from the article this thread is about. As to if the article itself is "sure" I don't know, if you do then go ahead and contribute something constructive to the discussion.
- enraged_camel 8y ago>> If you have something you want to contribute I'd prefer if you just did so. I don't feel like you're asking either question in good faith. Your original comment was not in good faith. It claimed the exact opposite of the things said in the article (such as dropping IE 11 support - NOT correct).
- Someone1234 8y ago> It claimed the exact opposite of the things said in the article I'm not sure why you've created two comment trees saying the same thing, I responded to your other comment above. > Your original comment was not in good faith. My original comment was my opinion based on my experience and after having read the article. If you disagree, fine, but I don't think it is fair to question my motives. Simple disagreement doesn't mean the person you're disagreeing with is responding in bad faith; asking loaded "questions" which read as thinly veiled insulted however...
- IgorPartola 8y agoPhew. After the Angular 2 disaster, I am traumatized by posts with this title format. It seems like the changes will be simple, useful, and mostly backwards compatible. I look forward to upgrading my current Vue projects to use 3.x. I am especially excited about not having to worry about missed observable mutations with arrays. That was annoying.
- jhoh 8y agoHow was Angular 2 a disaster? I know it was basically a new Framework but I think they made it very clear and even did a rebranding (AngularJS -> Angular) and AngularJS is still being maintained.
- barbecue_sauce 8y agoWhile I agree Angular 2 isn't a disaster, AngularJS -> Angular is probably the laziest and most ambiguous "rebranding" I've ever seen, considering the fact that historically AngularJS was often referred to as Angular. This will be a clunky simile, but it's like if all of a sudden Coca-Cola decided to rebrand Cherry Coke as just Coke and branded regular Coke as CokeNC. (Coke NoCherry).
- twblalock 8y agoThe front end team at my last company was pretty pissed that they spent months migrating to Angular and then learned that Angular 2 was not backwards compatible. They were hoping that by going to Angular they were buying in to a platform that would serve them for years, but that was not the case. That’s a huge deal. Why should they trust Angular ever again? I suspect the Angular 2 debacle was a big factor in moving React ahead of Angular.
- eksemplar 8y agoBig changes that come so sudden are disasters in the real world where people don’t adopt new things a lightning speed or for free. If you spend money upgrading your employees from whatever mvc to angular1 and then have to do the same thing a few years later, you’ll be pissed. If you have to take time out to learn a new framework every two years, just because. You’d be pissed. And you have to keep in mind that angular was meant for ebpnterprise, not young indies who change their frameworks more often than I change my pants, so that made it extra terrible. I mean, there is a reason COBOL is still a thing, enterprise doesn’t like change. I guess you could have kept going with angular1, but how would you hire for something that only lived s few years? Nobody knows it. I think Microsoft is in danger of going this route as well with all the changes they are doing to .net though, so it’s a general trend these days, by my god, it sucks.
- AltruisticGap 8y agoSounds great, but why bother with the added work supporting IE11 if Vue 2.x can be used with IE11? Especially that time continues to fly until 3.x is released, and IE11 is replaced with EDGE already. edit: I am guessing this has to do with having one codebase for projects that move to vue 3 and still need support for IE1.. makes sense. Hmm.
- Roritharr 8y agoIE11 is still supported by Microsoft atleast up until 2021, possibly further. We bet on Vue and 5% of our enterprisey customers rely solely on IE11 for some reason or another and our competition supports it unflinchingly. So, atleast we're very glad for this decision.
- reaperducer 8y agoI’ve got almost 25% IE11 and XP to support. I feel your pain.
- EB66 8y agoUnfortunately, IE11 is still quite prevalent in large enterprise organization with IT departments that control which browsers are installed on desktops across the org. There's a lot of bureaucracy and legacy apps to contend with before making a change to swap out a browser. For example, IT might first have to certify that a browser change would not break usability with any number of old internal company web apps. There are also quite a number of Win32 apps with embedded browsers that are essentially running IE11. Depending on what Win32 control/plug-in was used to embed a web browser, those embedded web browsers might be stuck on IE11 indefinitely (until the authors of the Win32 app re-compile with an embedded web browser that uses Edge).
- rk06 8y agoBecause IE 11 is currently being used in a lot of places. In my company, majority of desktops are on Win 7, hence edge is not an option. the same must be the case in a lot of companies as well.
- EB66 8y agoTheir decision to switch to a Proxy-based observer is very much welcomed. Other libraries ( https://github.com/ElliotNB/observable-slim https://github.com/ElliotNB/observable-slim ) have shown that Proxy-based observers are robust and performant, but do have some polyfill restrictions for IE11 users. The ability to monitor for properties added dynamically at runtime will allow for a lot more flexibility. Proxies still behave unusually with more complicated Objects (e.g., Date), but they work brilliantly with plain objects. Implementing an observer with Object.defineProperty is a lot more complicated IMHO.
- tinyvm 8y agoWow , reading comments was quite interesting. I didn't thought so much people got "exhausted" by Angular. I personally tried it ( v2 , v4 , v5 , v6) and i really fell in love with it. I use mostly Vue and Angular they complete each others very well , i prefer NGRX over Vuex and Angular native support for Typescript. Typescript with Vue is a bit of hassle to set up and maintain, but with this new update this a bit of a game changer. It appeals to a larger audience , especially those looking to build large scale project , while keeping the core of the community. Really great news.
- mrath 8y agoI share your view. I am generally a backend developer, I spent a lot of time with Angular(2+), recently started a project with react and also looked at Vue. so my time spent on Angular > React > Vue. If I have to choose a framework for a new project I would definitely choose between Angular and Vue, I won't write react unless I am paid. It is just verbose and ugly, no magic.
- aikah 8y ago> I didn't thought so much people got "exhausted" by Angular. I personally tried it ( v2 , v4 , v5 , v6) and i really fell in love with it. It's basically Java Spring IoC container ported to Javascript. But Javascript doesn't need an IoC container, it's a dynamic language... That's why I despise Angular. It's a framework that does absolutely nothing new then tries to mask its vacuity with layers and layers of complexity. It's like some people need to justify their salaries at Google so they churn useless yet elegant code. Why the heck does a JS view framework need a AOT compiler as well?
- dlwdlw 8y agoI’m somewhat sad that there’s so much focus on HOW related improvements and less on the WHY. What I really like about Vue was that it was one of the first tools where it’s whole MO was to get out of the way of the process of creation instead of being very in-your-face about specific features and techniques . It was iOS while react was Android. I hope that It’s initial success bringing it more mainstream doesn’t cause enterprise pressures to make the project lose focus on this core. Not having to deal with weird tricks for certain types of data mutations is quite nice though.
- mwcampbell 8y ago> The constant baseline size for the new runtime is <10kb gzipped. That's still way more than Preact (~3 KB gzipped), and Preact supports IE 11 out of the box. I wonder why the Vue 3 baseline runtime will still be so much larger. What does Preact sacrifice to get that small size?
- superasn 8y agoI wish there was some sort of inbuilt support for template inheritance that you currently have to do with stuff like "pug." Laravels blade templating engine does a great job at @extending templates from child to parent and it can be used for inspiration. Vue already has a slot tag so maybe then can add an extend tag for extending a parent template in a derived child template component.