
Plans for the Next Iteration of Vue.js - radubrehar
https://medium.com/the-vue-point/plans-for-the-next-iteration-of-vue-js-777ffea6fabf
======
russellbeattie
I'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.

~~~
eksemplar
I especially don’t get the ide support bit, because Visual Studio Code already
does that for regular JS.

I think typescript is s mistake that most people will regret because it adds
so much complexity to the process for so few advantages gained. I mean, we
were predominantly a C# house, if anyone should be using Typescript it should
be us, but we found it to be much less productive than JS exactly because
stuff like prototypes becomes more complex and typesafety kind of gets in the
way of the process when you’re not exactly sure what you’re making.

I don’t think it’s exactly coffeescript though, I mean, I just ranted about
typescript, but it doesn’t get in the way like coffescript. Since it
integrates sort of decent into JS, it’s not a horrible thing, we just found it
unnecessary.

~~~
james-mcelwain
> I especially don’t get the ide support bit, because Visual Studio Code
> already does that for regular JS.

The IDE support in VSCode is at least partially driven by type declarations
from TS projects, so regular JS is benefiting from TypeScript.

~~~
eksemplar
I didn’t say typescript was horrible, it’s just been unnecessary and
unproductive for us. I think it does have a place in applications like VS
code, because maintaining them is quite a lot bigger than most projects, and
you don’t include VS code in yours.

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

~~~
jhoh
How 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
While 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).

------
faitswulff
Nice 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.

------
Keats
Written 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.

~~~
cimmanom
Will it still be possible to run in an ES2015-compatible browser without
transpiling? That was one of the killer features of Vue for me.

~~~
ChristianBundy
Nope, and it won't run with ECMAScript-compatible editors, linters, static
analyzers, or type checkers (see: Flow).

I can't imagine recommending TypeScript to anyone I like.

~~~
manigandham
What are you talking about? Typescript is what the Vue source code will be
written in, which is compiled to javascript when distributed and includes
Typescript definitions for editors that make use of it.

Your code can continue to be written in regular javascript with whatever
toolchain you want.

And Typescript is a fantastic platform for bringing strong typing to
Javascript, it's a rather extreme comment to say you don't recommend it to
anyone.

------
another-cuppa
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 with React?

~~~
porsager
You can skip both, and most of the churn by taking a look at
[https://mithril.js.org](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](https://flems.io/mithril) .

Here's a quick hello world.
[https://flems.io/#0=N4IgZglgNgpgziAXAbVAOwIYFsZJAOgAsAXLKEAG...](https://flems.io/#0=N4IgZglgNgpgziAXAbVAOwIYFsZJAOgAsAXLKEAGhAGMB7NYmBvEAXwvW10QICsEqdBk2J5YxAATUoEagGs4EgLwSADAB00mrPiy0ArgwAUAE1rV9OBvgBGtEwE8KE4JokSAbhBgB3RBKMASmUAPgksIwByLAwINEiKN3dwqMIARgSJSIAJGCgoWgkfWgAnKBNIwMS0ZJTIm31iYnpM1xraiXppWTl-
INCpGXk4AGoRpPd2LLjqEpgrYkrq2ojIwgAmTMiAYSGFf0iJEcGeuECk87RWQMoaWiwAB2gYErwbDBs827g8mGpiCD0BA8ADsiBBbA4IEwODw+GocAEd2EzB4bAAulQZGgFEhUNCuHgsBBiIQStBbvoyngSMQHnBEAB6RmGB5yADm8PujOJpPJUAAAml8MKAGw8klk6D4fi3YgOB7cEBwWYQB6iVjo1hAA)

~~~
another-cuppa
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.

~~~
porsager
Well I'd be happy to make a pull request to fix it. What is your setup?

~~~
another-cuppa
I use the option "use theme colours" in Firefox and therefore my default
background is grey and default color is whitish. Basically, if you change
color, make sure you change background appropriately, and vice versa. Don't
assume background will be white and color will be black for everyone.

------
dlwdlw
I’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.

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

~~~
Roritharr
IE11 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
I’ve got almost 25% IE11 and XP to support. I feel your pain.

------
EB66
Their 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
Wow , 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.

~~~
aikah
> 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?

------
no1youknowz
As 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...](https://forum.vuejs.org/t/videojs-not-rendering-inside-using-linus-
iframe/44139)

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)

~~~
honopu
That's a lot of sets. I've have you tried out deep-model? I've had varying
success with this, essentially it creates a proxy object that wraps, its a
computed property on your component. If vuex is too much for your application,
but you're using that many $sets for whatever reason, maybe it would help?

~~~
no1youknowz
I havent tried deep-model. To be honest, knowing about 2.6-next/3.0 on it's
way. I can let it be for now and then refactor when the new version hits in
2019.

I'm not quite sure about VueX. There's this [0]. Which I'm going to attempt
soon. Would be nice if VueX could help. Would solve the UX and postMessage
issue that I have.

For context. It's a page builder like leadpages, elementor for wordpress,
unbounce, etc. It's one big array which then gets parsed as JSX and then
rendered out to the vDom.

[0]: [https://forum.vuejs.org/t/share-vuex-store-with-vue-app-
in-i...](https://forum.vuejs.org/t/share-vuex-store-with-vue-app-in-
iframe/15411)

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

~~~
atentaten
[https://vuejs.org/v2/guide/single-file-
components.html#What-...](https://vuejs.org/v2/guide/single-file-
components.html#What-About-Separation-of-Concerns)

~~~
rhengles
Having to repeat the component name in the "src" is less than ideal, IMO.

------
superasn
I 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.

------
nikkwong
Wow, 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
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 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.

~~~
emanuelmutsch
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."

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

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

~~~
honopu
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!

~~~
jakear
I 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
Yes trying with a fresh, TS-free, default setup of Vue, the props are still
verified only at run time.

------
agumonkey
Impressive list. I wonder if they can maintain the lean size. If so how faster
will it be ?

~~~
ssijak
If you have read the article you would have found answers to your questions.
-> Gziped <10kb, and about 100% faster then vue2 on average.

~~~
agumonkey
I skimmed but too fast obviously

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

~~~
enraged_camel
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)

~~~
spiffytech
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.

~~~
honopu
I 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.

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

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

~~~
rpastuszak
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.

~~~
baybal2
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.

