Percentage of Vue-Specific Code? about vuido HOT 17 CLOSED

The libui-node-dom package is implemented since version 0.1.2 so I'm closing this.

from vuido.

On the other hand there's also libui and libui-node, so in fact there will be 4 separate packages to modify 😃.

WinAPI/Cocoa/GTK - libui - libui-node - libui-node-components - vuido
                           |            |                       |
                           |            |                       |
                 V8 - node /------------/-----------------------/
             libuv -/

Feeling dizzy now...

from vuido.

I'm reopening this issue because it just occurred to me that there is a very easy solution to this problem...

I can add another build script to Vuido which bundles only the elements into a separate package, pretty much like packages/vuido-template-compiler works at the moment. So there can be a separate npm package, but it will be built from Vuido sources and no separate repository it needed.

How about calling it libui-node-dom? It's shorter that libui-node-components.

from vuido.

Hi, @EisenbergEffect vuido is based for the native part, on libui-node, which I'm the author of.
I can't answer which part of vuido code is specific for vue.js, but I think you want to develop a similar thing but for Aurelia, you should base your project on libui-node too.

Give it a look https://github.com/parro-it/libui-node

from vuido.

Yep. Checked that out today as well. Very cool stuff :) In this project, with a quick look, I noticed a good deal of code in src/runtime/elements that seemed like it was a potentially re-usable set of HTML-element-like bindings for libui-node. I think I'd have to create pretty much an exact copy of that from scratch to do the Aurelia integration. I'm wondering if that and any similar code could be extracted and used by other frameworks.

from vuido.

Yep. Checked that out today as well. Very cool stuff :)

Thank you!

from vuido.

Vuido is specific to Vue.js, just as Proton Native is specific to React. It would be hard to share code between these projects, because each framework works in a different way. It would be the same with Aurelia. But as @parro-it pointed out, all the hard work is done by libui-node, Vuido is really just an interface between Vue.js and libui-node.

from vuido.

But as @parro-it pointed out, all the hard work is done by libui-node

I didn't mean we are the only ones doing the hard work ☺️

from vuido.

Everything under src/runtime/elements seems to be reusable. At first glance, it appears to be a set of objects that mimics the DOM API but delegates to libui-node. I may have missed it, but I didn't see any Vue-specific code in there. For Aurelia, we'd have to build this exact same thing. I was hoping to not have to copy/paste that code but rather see if we could both work on a shared library. Does that make sense?

from vuido.

You don't have to copy/paste that, you can use the following code to import only the elements from Vuido:

const elements = require('vuido/src/runtime/elements');

from vuido.

Yes, that's possible. However, that creates an unnecessary dependency on the rest of the library and all of it's dependencies via NPM install, which doesn't make a lot of sense. I think it makes more sense to extract that into its own library. Then any framework that knows how to work against the HTML DOM would be able to seamlessly render the libui-node elements.

from vuido.

Not necessarily. Vuido can be a devDependency of your library and you can build a single script which contains both Vuido elements and your code specific to Amber bundled together.

This is exactly how I do it. Vuido includes large parts of Vue code, but you don’t need to install Vue and its dependencies in order to use Vuido.

Vue could also be separated into core code and DOM-specific code (like react and react-dom), but instead it’s a single package, because that makes development easier. For the same reason I don’t wan’t to split Vuido into two parts.

from vuido.

I understand if it's just something you don't want to do. I hope you'll reconsider in the future as it would be better to join community efforts in working on the shared parts, but without a real breakout of the package, it's just not something we can do. We're very strict about our dependencies.

If it's ease of development you're concerned most about, then you might want to explore using Lerna. It's meant for these types of scenarios.

Closing this ticket for now.

from vuido.

I also gave a look at the code in src/runtime/elements. It's really a great work, and I also think it could be really useful to adapt other frameworks that actually works only with browser DOM.

@mimecorg are you open to use it in vuido if I/we extract it to a separate package? I dont' want to be pushy, since you already expressed your opinion, but still...

from vuido.

As always I am open for discussion.

Technically nothing stops us from extracting this code, because it only depends on libui-node and nothing else. And I can see the value from having such shared code for other frameworks.

My main concern is that adding a new widget or making any other substantial change will require changing both the shared package and Vuido itself. For example, util/index.js contains a list of reserved tags and boolean attributes that need to be in sync with the elements. It won't be a big problem for me, but other contributors would have to create two PRs for the shared package and for Vuido. On the other hand there's also libui and libui-node, so in fact there will be 4 separate packages to modify 😃.

Also I'm still not convinced that including Vuido as a dev-dependency and importing only the relevant parts is not a viable option. Any decent bundler will do that without including entire Vuido in the final package.

from vuido.

How about calling it libui-node-dom? It's shorter that libui-node-components.

I like it! Both the name and the solution...

from vuido.

Thank you @mimecorg !

from vuido.