Open WakanaYuki opened 4 years ago
Well...at the moment, yes. In the future, I might pick it up again, but I'm not entirely sure. I've been actually meaning to do a write-up of what's going on for quite some time now, so I guess this is the perfect place...
I love using Vue, and VueDart was one of my favorite Dart projects, but there were some aspects of it that were showing its age a bit. I didn't make some smart design decisions in the beginning, and there were some really annoying issues that I had to work around in the generator since VueDart was created before Dart 2 and package:build
, back in the days of pub serve
taking twelve hours (dang, it's been a long time...). None of this was unfixable, but I knew that I had to do some significant changes in the future.
Then Vue 3's composition API happened. Now, from a typing standpoint, it works absolutely marvelously with TypeScript. However, TypeScript has structural subtyping as part of its objects, which basically means that this is typed correctly:
let obj = { a: 1, b: 'abc' }
let {a, b} = obj
// a: number, b: string
The composition API relies on this a lot, but Dart simply doesn't. You would have to create a class containing a
and b
members in order to have type safety. It's a bit uglier, but not unworkable, and I had some plans laid out in #42 for this.
However, as I started hacking away at the compiler, a fundamental issue started to become apparent as I worked on this: Vue is a JavaScript library. This isn't a huge issue, but as it stands right now, the allowInterop family hurts code size and performance, and VueDart uses it and roundtrips across the JS and Dart boundaries everywhere. It also uses closures very heavily, which in turn runs into this code size issue. More efficient JS interop is on the roadmap, but until then VueDart's code size will be stuck larger than what you'd expect from a lighter framework.
In addition, the Dart <-> JS boundary line brought up some awkward issues with how to handle the composition API, partly due to the object typing I mentioned above. In particular, mixing in observable values returned from JS libraries that you'd inevitably end up using in Vue 3 would result in some nasty-ish boilerplate in many cases in order to cleanly type check.
That ended up bringing me around to what made me lose motivation: as cool as Vue 3 is, the fact that it was designed with JS/TS in mind will always cause adapting it to Dart to result in an inferior solution. In order to make #42 possible, I'd have to rewrite a lot of the compiler and runtime API, and I'd still have to eventually compile templates myself for consistency, all for...a framework that's bigger than the JS variant and more verbose? It was really hard to find motivation past that point.
FWIW I've still been meaning to fix #47, it's been on my todo list for months, I legit just never actually read my todo list and keep forgetting :sweat_smile:. I also plan on continuing to maintain aspen in the future, since that's something that some Dart projects I'll be working on in the future can make great use of. To be honest, I do want to play with Dart web frameworks again in the future, but it'll most likely be a from-scratch solution just for Dart, rather than trying to bind a JS framework.
If I had to give a recommendation on what to use, it would've probably actually been...AngularDart?! I didn't like Angular much in the TS land, but I found myself liking AngularDart quite a bit more, especially since there's no messing with RxJS and such. However, the repo is aging a bit, and the upcoming Git sync isn't quite ready yet. That being said, my next (small) Dart web project I have planned will probably just use AngularDart.
Anyway, I hope that summarizes pretty much everything. Sorry for the lack of transparency here, it was just hard to find the time to write some of this up.
@refi64 great writeup. Honestly, it would probably make more sense (but more effort) to take the ideas of Vue and just implement a 'simpler' version in Dart (similar in spirit of AngularDart) rather than doing all the JS interop but I certainly understand the reasoning. I do agree with just using AngularDart and I have the similar sentiment compared to Angular. Cheers.
@refi64 RxJS is quite a nice experience when you get into it :stuck_out_tongue:
Hi @refi64, there are new API for JS interop and WASM compilation target is comming.
Hey, I am currently on the search for a good web framework. I really hate Angular, so AngularDart is not really a option I want to go with. Over_React seems somewhat better, but I do want to have an alternative, like VueDart. So, is this Project dead? The last commit was about a year ago now :/