Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Plans for the Next Iteration of Vue.js

medium.com

Post reply on HN
Print view View original

61–70 of 152 posts

Re: Plans for the Next Iteration of Vue.js

#61

Post by emanuelmutsch »

Someone1234 wrote: post #40

Seems 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…

Did you even read the article?

"The new codebase currently targets evergreen browsers only and assumes baseline native ES2015 support. But alas, we know a lot of our users still need to support IE11 for the foreseeable future. Most of the ES2015 features used can be transpiled / polyfilled for IE11, with the exception for Proxies. Our plan is to implement an alternative observer with the same API, but using the good old ES5 Object.defineProperty API. A separate build of Vue 3.x will be distributed using this observer implementation. However, this build will be subject to the same change detection caveats of Vue 2.x and thus not fully compatible with the “modern” build of 3.x. We are aware that this imposes some inconvenience for library authors as they will need to be aware of compatibility for two different builds, but we will make sure to provide clear guidelines on this when we reach that stage."

Re: Plans for the Next Iteration of Vue.js

#62

Post by another-cuppa »

porsager wrote: post #59
another-cuppa wrote: post #15

I'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…

You can skip both, and most of the churn by taking a look at https://mithril.js.org . It's one of the only frameworks I've seen that gets you 95% of the way while supporting you through the last 5% instead of getting in your way. It includes all the regular things you need (view, router, requests) while staying under 10kb and having better performance than those two. If you need any help at all, there's a super frien…

That looks really great. Bookmarked.

Shame the site is one of the rather large group of sites that assume everyone's default CSS is black on white text, though.

Re: Plans for the Next Iteration of Vue.js

#63

Post by wishinghand »

Someone1234 wrote: post #40

Seems 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…

Most of these changes are going to be added as minor version updates to Vue 2. This is unwarranted FUD.

They're dropping IE11 in some version of Vue 3, but will maintain a compatibility build, along with polyfill if a compatibility isn't possible.

They're still light weight (going to be lighter), still simple, and at its most basic, will just be a script tag added at the bottom of your HTML page.

Re: Plans for the Next Iteration of Vue.js

#64

Post by twhb »

baybal2 wrote: post #3

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

Using DOMParser means parsing the template twice, once for DOMParser and once for your template syntax, making perf gains more questionable. Also, doing HTML and template parsing separately means either passing template syntax through the HTML parser, which limits possible template syntax and spends time instantiating bogus DOM elements/attributes, or passing HTML through a HTML-unaware templating language, creating all the problems and limitations of C’s #define and making it hard to react to data changes with minimal updates.

That said, it’s been done both ways. Mustache templates do string templating then use the native HTML parser, and one smaller library, I don’t remember which, parses the template as HTML then tree walks for templating controls, and cites perf benefits.

Re: Plans for the Next Iteration of Vue.js

#65

Post by basil-rash »

prima-facie wrote: post #23
lazarljubenovic wrote: post #14

Earlier quoted context omitted.

> 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. H…

Props can have a type.

The type is verified at runtime though

Re: Plans for the Next Iteration of Vue.js

#66

Post by jvanveen »

petepete wrote: post #18

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

Using such an approach in this project: https://github.com/garage11/ca11 You can just use the vue template compiler for that.

Re: Plans for the Next Iteration of Vue.js

#67

Post by EB66 »

Their decision to switch to a Proxy-based observer is very much welcomed. Other libraries ( 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.

Re: Plans for the Next Iteration of Vue.js

#68

Post by Someone1234 »

emanuelmutsch wrote: post #61
Someone1234 wrote: post #40

Seems 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…

Did you even read the article? "The new codebase currently targets evergreen browsers only and assumes baseline native ES2015 support. But alas, we know a lot of our users still need to support IE11 for the foreseeable future. Most of the ES2015 features used can be transpiled / polyfilled for IE11, with the exception for Proxies. Our plan is to implement an alternative observer with the same API, but using the good…

Yes? Your quote is literally one of the things I'm complaining about.

Re: Plans for the Next Iteration of Vue.js

#69

Post by honopu »

jakear wrote: post #2

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

As 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!

Re: Plans for the Next Iteration of Vue.js

#70

Post by honopu »

another-cuppa wrote: post #15

I'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…

Vue is really nice. I think a lot of the complexity, at least to me was wrapping my head around redux itself, which as you know is optional.

If next.js wasn't as nice as it appears to be, or nuxt was just as good, I wouldn't be looking at react for another project. The lack of plugins is "meh", the dev tools in React are pretty amazing. I haven't figured out a way to get a really nice stack trace in the browser for an error in Vue, react does this much better.

Experience in Vue (2.5 years and continued, 1 shipped SaaS, fairly large internal project) React (1.5 years off and on, big ecommerce furniture place)

Post reply on HN