Live data from Hacker News

Plans for the Next Iteration of Vue.js

medium.com

101–110 of 152 posts

Re: Plans for the Next Iteration of Vue.js

#101

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…

> …I like JavaScript, and Typescript isn't JS.

Considering that you don't need to use it unless you plan on contributing to Vue.js itself, my (sincere) question is: Why does it matter to you?

Re: Plans for the Next Iteration of Vue.js

#102
post #84

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.

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.

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

Re: Plans for the Next Iteration of Vue.js

#103
post #88

Earlier quoted context omitted.

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

Golang doesn't avoid all the compatibility issues. On the contrary, there's a ton of Golang that won't run on anything but Linux.

Can you expand on this? I’ve used a decent amount of Go packages and they all run as expected on my Mac.

Re: Plans for the Next Iteration of Vue.js

#106
> The constant baseline size for the new runtime is 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?

Re: Plans for the Next Iteration of Vue.js

#107

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…

> To me it's the new coffeescript combined with the verbosity of J2EE

How is this the top voted comment on here? How does one go from Coffeescript/J2EE to TS? Coffeescript was... well... Coffeescript, a JS variant with better ergonomics. J2EE was a Java framework that also has no resemblance or connection to TS. What a bizarre comment but truly disturbing to see masses voting this up.

Re: Plans for the Next Iteration of Vue.js

#108
post #90

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…

I agree that TS increases barrier to entry for contributors. However, it's very different from Coffeescript. It offers better program correctness via types whereas CS was mostly sugar. Libraries that (properly) use Flow/TS are less likely to have bugs and are safer to contribute to (you're less likely to introduce a bug) and that's a good thing.

Libraries that (properly) use {{insert anything here}} are less likely to have bugs and are .... etc

remove the (properly) and I'd give the technology some credit. Otherwise it's just "no true Scotsman" fallacy.

Re: Plans for the Next Iteration of Vue.js

#109

Earlier quoted context omitted.

Golang doesn't avoid all the compatibility issues. On the contrary, there's a ton of Golang that won't run on anything but Linux.

Can you expand on this? I’ve used a decent amount of Go packages and they all run as expected on my Mac.

Probably stuff that hardcodes paths like /tmp

Re: Plans for the Next Iteration of Vue.js

#110
post #88

Earlier quoted context omitted.

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

Golang doesn't avoid all the compatibility issues. On the contrary, there's a ton of Golang that won't run on anything but Linux.

I cross-compiled to Windows the other day for the first time (from Linux). It gave me a perfectly-working .exe in less than a second on my first try.

I love JS too, but I have yet to get Webpack or Babel working in less than a couple of hours.

Post reply on HN