Live data from Hacker News

Plans for the Next Iteration of Vue.js

medium.com

131–140 of 152 posts

Re: Plans for the Next Iteration of Vue.js

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

> How was Angular 2 a disaster?

Because these were basically 2 different projects that have absolutely nothing in common. They should have called it something else. I'll be hyperbolic but imagine jQuery then jQuery2 is React, to give you an idea. Why still call that jQuery? for marketing purposes obviously and it's a bad reason.

Re: Plans for the Next Iteration of Vue.js

#132
post #74

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…

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

Re: Plans for the Next Iteration of Vue.js

#133

Earlier quoted context omitted.

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

Try it before saying something like that.

TS is like swift, and it does not require type declaration. A lot is automatic.

Re: Plans for the Next Iteration of Vue.js

#134

Earlier quoted context omitted.

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…

enums are probably the only TS thing which does not exist in plain JS (at least I can't think of any other one), and it's quite easy to replace. In your example you just replace enum by a hashmap and remove all the types and it's a valid JS file, it's not really that different. It would be quite easy for an automated tool to do that.

Re: Plans for the Next Iteration of Vue.js

#135
post #92

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.

I've been doing that for years in one of my projects. Just reference the CSS and JS files in the .vue file (e.g. ) instead of inlining them in their respective tags. How else would you want to do it?

I'd just like a directory containing a template, style and code file, the referencing would be straightforward to imply without having to repeat everywhere. Similar to how views work in Rails I guess.

Re: Plans for the Next Iteration of Vue.js

#136
post #92

Earlier quoted context omitted.

I've been doing that for years in one of my projects. Just reference the CSS and JS files in the .vue file (e.g. ) instead of inlining them in their respective tags. How else would you want to do it?

I'd just like a directory containing a template, style and code file, the referencing would be straightforward to imply without having to repeat everywhere. Similar to how views work in Rails I guess.

You want more magic, basically. I guess that's a personal choice.

I've never personally felt inconvenienced by having this at the bottom of my .vue files:

  
  
It's not like I ever have to type it out. It gets copied along with whatever else is in the .vue file I copied from.

Re: Plans for the Next Iteration of Vue.js

#137

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.

Because IE 11 is currently being used in a lot of places.

In my company, majority of desktops are on Win 7, hence edge is not an option.

the same must be the case in a lot of companies as well.

Re: Plans for the Next Iteration of Vue.js

#139

Earlier quoted context omitted.

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

> a non-language

It has a BNF that’s different from any other language, so it’s definitely a language. A language isn’t defined by its runtime.

> Think PHP for scripting.

PHP is a language...

> J2EE wasn't just a framework

What language features did J2EE introduce?

> You can't argue that it's not all bloat, as the resulting JS it produces runs fine without it all

Yeah, just like C, which compiles yo machine code, is complete bloat.

Re: Plans for the Next Iteration of Vue.js

#140

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…

I have been using it for the last few years and found it to be the easiest simplest and fastest library to create an app with.
Post reply on HN