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

121–130 of 152 posts

Re: Plans for the Next Iteration of Vue.js

#121

Post by russellbeattie »

linkmotif wrote: post #107
russellbeattie wrote: post #81

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.

Coffeescript - like Typescript - is a non-language. There are no native VMs for either. They have to be transpiled to work. If you're writing in either language, you're basically using large DSL macros which pump out JavaScript. Think PHP for scripting.

J2EE wasn't just a framework, it was core enhancements to the Java language, which caused a ton of bloat. EJBs, JSF, annotations, XML configurations, etc. Very similar to Typescript's bloat it adds on top of JavaScript. (You can't argue that it's not all bloat, as the resulting JS it produces runs fine without it all.)

Re: Plans for the Next Iteration of Vue.js

#122

Post by eksemplar »

jhoh wrote: post #84
IgorPartola wrote: post #55

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.

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

Re: Plans for the Next Iteration of Vue.js

#123

Post by sebazzz »

russellbeattie wrote: post #117
CharlesW wrote: post #101

Earlier quoted context omitted.

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

One always ends up going through a library or framework's source code at one point or another while trying to track down bugs. Using Typescript makes this a lot harder. For example, I was going to contribute to the Visual Studio Code project with a simple tweak: A setting that would make global find key-command happen without have to click the search icon after. After asking online and then wading through the TS sour…

> Using Typescript makes this a lot harder.

Does it? I think type annotations makes it easier. It means you don't need to think less hard, which makes unknown code, which is always harder to read, a bit easier to read.

Re: Plans for the Next Iteration of Vue.js

#124

Post by russellbeattie »

realusername wrote: post #119
russellbeattie wrote: post #81

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…

Unlike CoffeeScript, you can't have any technical debt with TypeScript, if one day TypeScript disapears, you just remove the types and you have a perfectly working JS file.

Really? This isn't even close to valid JS.

enum Color { red = 1, green = 2, blue = 4 }

namespace Color { export function mixColor(colorName: string) { if (colorName == "yellow") { return Color.red + Color.green; } else if (colorName == "white") { return Color.red + Color.green + Color.blue; } else if (colorName == "magenta") { return Color.red + Color.blue; } else if (colorName == "cyan") { return Color.green + Color.blue; } } }

* Edited with a better example.

Re: Plans for the Next Iteration of Vue.js

#125

Post by eksemplar »

russellbeattie wrote: post #81

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

Re: Plans for the Next Iteration of Vue.js

#126

Post by jakear »

honopu wrote: post #69
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!

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)

Re: Plans for the Next Iteration of Vue.js

#127

Post by jakear »

jakear wrote: post #126
honopu wrote: post #69

Earlier quoted context omitted.

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!

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

Yes trying with a fresh, TS-free, default setup of Vue, the props are still verified only at run time.

Re: Plans for the Next Iteration of Vue.js

#128

Post by marcus_holmes »

peterkelly wrote: post #112
marcus_holmes wrote: post #111

Earlier quoted context omitted.

No, I get it. As a JS dev, Cofeescript appeared to be nothing more than an attempt to make JS more like Ruby. From this perspective, TS appears to be nothing more than an attempt to make JS more like C#. Either way, both appear to be attempts to use JS's massive flexibility to make the language work more like another language, because people are more familiar with that other language. And in both cases, there's a fam…

I suggest you give TypeScript a try. You might like it, you might not, but at least then you'll know. It uses gradual typing - you can use static types as little or as much as you like. It's not C#.

I'm writing the backend in Go, so static typing is not where the resistance is coming from ;)

It's more like separation of concerns. I want Postgres to take care of data integrity. I want Go to take care of type safety. I want to give Vue all the flexibility it needs to handle user interaction. I don't really want to care about types in the UI, because Go can sort out whatever it sends to the server.

If I have to start writing code in the browser to translate between Go structs and TS classes then that's a step too far imho.

Re: Plans for the Next Iteration of Vue.js

#129

Post by Too »

russellbeattie wrote: post #117
CharlesW wrote: post #101

Earlier quoted context omitted.

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

One always ends up going through a library or framework's source code at one point or another while trying to track down bugs. Using Typescript makes this a lot harder. For example, I was going to contribute to the Visual Studio Code project with a simple tweak: A setting that would make global find key-command happen without have to click the search icon after. After asking online and then wading through the TS sour…

Type annotations strongest advantage is when diving into a new code base you've never read before. Can't see how it can make it harder to track down bugs. It does prevent monkeypatching so some "i'll just add a quick fix here" are going to be harder, and that is a good thing, otherwise you end up with spaghetti soup.

Re: Plans for the Next Iteration of Vue.js

#130

Post by johnny22 »

eksemplar wrote: post #125
russellbeattie wrote: post #81

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

if you're not sure what you're making then just type everything you're spiking on with any or unknown?
Post reply on HN