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

51–60 of 152 posts

Re: Plans for the Next Iteration of Vue.js

#51

Post by avip »

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…

Underqualified to speak for Vue, but practically everything you're saying is addressed in the post in very simple terms. They are breaking bc because JS and browserland are doing so, and quite quickly. That is what major releases are for. If you never do that you sink in tech debt - you know, like angular.

Re: Plans for the Next Iteration of Vue.js

#52

Post by marcosdumay »

Someone1234 wrote: post #48
enraged_camel wrote: post #46

Earlier quoted context omitted.

>> 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. >> They also seem like they're going to drop IE10/11 support (ES2015 everything) It's funny because the article says the exact opposite of these things. Maybe you haven't read it, or actually attempted to comprehend it?

> It's funny because the article says the exact opposite of these things. It what now? > In addition, the API is designed with TypeScript type inference in mind. The 3.x codebase will itself be written in TypeScript, and providing improved TypeScript support. (That said, usage of TypeScript in an application is still entirely optional.) And: > Top level APIs will likely receive an overhaul to avoid globally mutating…

> In addition, the API is designed with TypeScript type inference in mind.

If I got that right, they plan a first-class TypeScript interface, and a second class Javascript one compiled from it. You choose whatever you want.

Their problem is that you can not derive a good TypeScript interface from Javascript. But there is no problem on doing the reverse. None of that implies in any development-time or runtime requirement.

> Top level APIs will likely receive an overhaul to avoid globally mutating the Vue runtime when installing plugins.

That is a breaking change, yes. But not a large one.

> We are breaking some internal functionalities into individual packages

That is clearly not a breaking change.

> The new codebase currently targets evergreen browsers only and assumes baseline native ES2015 support.

That one implies on development-time requirements. They still can remove that requirement from the JS compiled distribution.

Re: Plans for the Next Iteration of Vue.js

#53

Post by vezycash »

another-cuppa wrote: post #43
vezycash wrote: post #38

Earlier quoted context omitted.

It'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.

You can do that with React too.

I figured that's what he's doing with React. He probably stumbled upon complicated Vue tutorials.

edit: Sorry. Didn't know I was replying to you.

If you're happy with React, by all means continue with it. If you want to understand Vue, then get simpler articles/videos and ignore the unnecessarily complicated ones.

Re: Plans for the Next Iteration of Vue.js

#54

Post by spiffytech »

enraged_camel wrote: post #25
jaequery wrote: post #7

All I'd like to see is just better error reporting and debugging

Eh, 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)

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

Re: Plans for the Next Iteration of Vue.js

#55

Post by IgorPartola »

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

Re: Plans for the Next Iteration of Vue.js

#56

Post by skybrian »

Someone1234 wrote: post #50
enraged_camel wrote: post #47

Earlier quoted context omitted.

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

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

At no point did I question your motives. I do question whether you understand Vue's plans.

Re: Plans for the Next Iteration of Vue.js

#57

Post by sophiebits »

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…

Curious: if React makes more sense to you, what would tempt you to stick with Vue?

(I work on React. Vue seems to make more sense to many people, and React to many others.)

Re: Plans for the Next Iteration of Vue.js

#58

Post by AltruisticGap »

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

Re: Plans for the Next Iteration of Vue.js

#59

Post by porsager »

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 friendly community at gitter as well. Did i mention 0 dependencies?

If you want to give it a go quickly, just load up https://flems.io/mithril .

Here's a quick hello world. https://flems.io/#0=N4IgZglgNgpgziAXAbVAOwIYFsZJAOgAsAXLKEAG...

Re: Plans for the Next Iteration of Vue.js

#60

Post by ricardobeat »

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?

There 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.
Post reply on HN