Improving Awesome Vue.js

[brillout]

I'm the author of awesome-react-components and I published awesome-angular-components a few days ago.

I find Awesome Vue.js convenient and I believe it can be made much better;

• Improved & more categories. (Categorization a la awesome-react-components / awesome-angular-components)
• Only 2.0 stuff. (Saving 1.0 things by keeping the current list as a "1.0" branch.)
• Use only one star symbol.
• No emojis. (I find them distracting.)
• Remove unmaintained lirbaries.
• One framework = one entry. (See Squash listings under same brand #320)
• [Optional] Add the libraries of Aweome Vue.js to devarchy.com/vue as an alternative improved view. (In that case we could get rid of the stars in the repo readme.)

I'd be up for implementing this.

In general I believe that curated lists are the future for finding & publishing libraries.
One big strengh of Vue is it's practical approach and great doc. Aweomse Vue.js is part of that.

@miljan-aleksic
@PrimozRome
@posva
@FranzSkuffka
@LinusBorg
@blodone
@mgielda
@shershen08

What do you think?

[mgielda]

I think that if you can get this done - then this is the biggest value. For me the problem is the inconsistency: how can there be, for example, star counts when these change and there is no guarantee they have been updated? (and some frameworks don't have them at all). The usefulness of a standardised approach - I like devarchy BTW, though I didn't know it before - is that it can be used as a (imprecise, but still better than nothing) measure of the objective reality. Without consistency though, a list like that is not as useful as it could be.

[shershen08]

thanks for the input @brillout here's my view on that:

1) Remove unmaintained lirbaries.
should be done.
there are options, such as npmcompare.com uses for example.

2) Only 2.0 stuff. (Saving 1.0 things by keeping the current list as a "1.0" branch.)
could have tags instead.
many projects are on 1.x. for now - maybe just adding an obligatory v2 / v1 tag could be enough

 - [Optional] Add the libraries of Aweome Vue.js to devarchy.com/vue
  - No emojis. (I find them distracting.)
  - Improved & more categories.

opinionated

[posva]

Hey, thanks a lot for your interest in helping out!

There's some ongoing work for a better tool. Refer to #387 (comment). We'll probably consider what to do once the tool is ready

My personal opinion:
I also think this list should be cleaned up. Most important of all, we need to be more selective.
I also like the Only 2.0 stuff. (Saving 1.0 things by keeping the current list as a "1.0" branch.)
I'd remove the star count.

[brillout]

@mgielda

I think that if you can get this done - then this is the biggest value.

Same view here, it should be about actually doing something.
Even if it's not perfect.
Some issues have already been discussed for a while but nothing happened.

problem is the inconsistency

True, we should be careful about that

I like devarchy BTW

Thanks!

@shershen08

could have tags instead.

Eventually all 1.x things will be removed from Awesome Vue.js anyways, why not start now?
Plus it'd be an incentive for lib authors to migrate to 2.0.
And it kind of feels more clean to separate 2.0 from 1.0.

opinionated

Why not Improved & more categories.? People seem to like the categorization on awesome-react-components & awesome-angular-components.
As for devachy.com/vue, it would merely be a read-only view of github.com/vuejs/awesome-vue. Just a convenient alternative to browse awesome-view.

@posva

we need to be more selective.

Yea and that's what I implicitly meant with Remove unmaintained lirbaries.

There's some ongoing work for a better tool.

Cool.

@LinusBorg wrote:

We will probably be using github as a DB for the curated list. We probably won't do that for awesome-vue

At awesome-react we plan to move all libraries to awesome-react-components.
Is that what you have in mind; Having two curated lists; One for learning material and one for libraries?

What about Improved & more categories.? In my view, this is important. Especially for the libraries.

[miljan-aleksic]

@brillout, you already have the experience and the know-how. Thank you for sharing it and willing to help.

I consider all your suggestions correct. Maintaining a raw list with consistency is much simpler than maintaining a whole new tool (apparently the reason why it development stopped).

Having separated branches for older versions, make sense.

If my vote counts for anything, you got it ;) and I am ready to help as required.

[posva]

It'll have a search, but yes, we can improve on categories.
Maybe there'll only be one list

[brillout]

@miljan-aleksic

If my vote counts for anything, you got it ;)

Thanks!

and I am ready to help as required.

It'd be awesome for the learning material part.

@posva

It'll have a search

Sounds interesting, I'm thrilled.

yes, we can improve on categories.

Neat.
Can we start working on this? I'd just do a fork, add collaborators on my fork and finally do a PR.

[shershen08]

@brillout
Great, looking forward!
Would be glad to help

[airyland]

I think it would be better if component-collections split up into Desktop components and Mobile components

[shershen08]

also I thought that author's names could be removed from packages. so that typical line describing a component could be:
name_with_link | <stars> | description

[janwirth]

It seems like the needs and wishes of developers vary in terms of information architecture and navigation. Maybe it makes sense to use something like typed tags for each property while providing an easily customizable view and filters.

I recently had the idea of using a customizable chain of FP primitives like map, filter, groupBy etc. to provide super-powerful filtering and views. Also, a tag system can be easily extended and works well with a documentDB.

To use @brillout's example:

1. filter : entry => entry.type == 'component'
2. filter : entry => entry.deviceType == 'mobile'
3. sortBy : entry => entry.stargazers

Or @shershen08

1. render : => ({{name}})[{{link}}] -- {{stargazers}} -- {{description}}

It makes sense to create some premade processors that cover most use cases.
I would also love the GitHub Markdown Stylesheet being used as our eyes are used to it.
It is very readable as well as scannable (in my opinion).

[shershen08]

@FranzSkuffka nice idea! also a regular search with just input box should be present I guess )

also I was thinikng why we don't use Github pages to render the improved table from the *.md file plus extra UI, such as sorting, searching, categories, etc.
What I mean in steps:

1. the data source is still the current README.md after the @brillout improvements
2. the template is an index.html page with styles and js
3. on each merge script transforms .md into part of an index.html (eg via https://github.com/chjj/marked)
4. html page with UI will be available on https://vuejs.github.io/awesome-vue

the UI could be simmilar to what is on http://devarchy.com/react-components plus maybe some of the mentioned features. It may look smth like this:

With this we could easily leverage UI options, available for custom build html/js webapp - such as url parsing, bookmarking (see #2), etc.

[brillout]

@airyland Agree.

@shershen08 @FranzSkuffka
Interesting ideas (Although I'm a bit afraid that some parts could end up "too complicated" but I don't know, I will think more about it and let you know my thoughts.)

About the Awesome Vue.js cleanup.
We can start with better categorization + remove not-that-useful stuff + consistency. (Seems that we unanimously agree on that.)

As for the stars and the 1.0 stuff I'd suggest to start without them and at a later point we can discuss how/if we add them back.

I've created a fork, @miljan-aleksic @shershen08 should I add you as collaborators?

I'll have time this WE to work on this.

@posva any objections?

[shershen08]

@brillout please do.

concering my UI proposal - I'll make a proof of concept simple demop repo this we and share with you

[posva]

We can start with better categorization + remove not-that-useful stuff + consistency. (Seems that we unanimously agree on that.)

As for the stars and the 1.0 stuff I'd suggest to start without them and at a later point we can discuss how/if we add them back

Looks good to me as long as you don't add or rearrange items and keep one list FTM. Thanks a lot for taking the time for it!
About devarchy, I don't think you should worry about integrating it because there's already an ongoing work on a more advanced tool

[brillout]

Alright, it started; https://github.com/brillout/awesome-vue/issues/2

There is an open question of what to do with libraries without english docs; https://github.com/brillout/awesome-vue/issues/1.

For anyone who wants to participate; Let me know and I'll send you a collaborator invite.

@brillout please do.

done

concering my UI proposal - I'll make a proof of concept simple demop repo this we and share with you

Nice, can't wait to see:)

as long as you don't add

Ok.

or rearrange items

I guess you mean to preserve the guideline To be fair, the order is first-come-first-serve.. Ok.

keep one list FTM

I guess you mean to keep the learning material and the libraries in the same markdown. Ok.

About devarchy, I don't think you should worry about integrating it because there's already an ongoing work on a more advanced tool

I can see both tools to happily coexist. We could talk about it after the cleanup, if you want.

[brillout]

For anyone who wants to help; https://github.com/brillout/awesome-vue/issues/3

[shershen08]

just came across - the comparison spreadsheet in this article - that might be interesting from both sides:

• use Google Docs as a data source
• list of columns / filters used

[brillout]

@shershen08 yea I thought about adding license info and KB size, the other metrics require too much manual work though.

As for the cleanup; I've now reviewed around 200-250 libs.

The categorization until now; https://github.com/brillout/awesome-vue/blob/master/README_CLEANED.md. (I'll add lib descriptions automatically at the end of the cleanup.)

To see what lib I removed;

• https://github.com/brillout/awesome-vue#ui-components
• https://github.com/brillout/awesome-vue#component-collections

Only the ones stamped with good or good \(.*\) are kept, the rest is removed.

@posva let me know if you think that I'm being too permissive or too strict.

[posva]

@brillout Hey, nice job! I still haven't reviewed all of the changes but I like how the list is cleaned up.
IMO it's better to be too strict than too permissive because it's easier to get a lib back to the list if we said that we have cleaned up: authors will come back and open an issue.

I'll review it today and tell you

[brillout]

Hey, nice job! I still haven't reviewed all of the changes but I like how the list is cleaned up.

👍

IMO it's better to be too strict than too permissive because it's easier to get a lib back

Didn't think about that and good point.

tell you

I just sent you a collab invite, feel free to comment inline.

[posva]

Looks overall good. It's very nice that you included that help about no v2, no docs, not maintained, etc.

About Vux, I think we should keep it but say docs are in english chinese only

[octref]

I still think @shershen08 @FranzSkuffka's idea is worth pursuing.

1. Interactivity for sorting / filtering is much better than just a plain md file, no matter how nice you make it. Having a query saying vue.js 1x compatible && Chinese doc available && star count > 100 sounds awesome, and isn't achievable with md files.
2. You can hook up GitHub API to retrieve star count, last commit time, issue response frequency automatically. Then you can generate a static site using the data and publish to GH pages.

I already did 2 as a school project. I can give 1 a try if people are interested, but I'll be busy and would only have weekends for it...

[shershen08]

@octref @brillout

for example here there's a freely available API to retrieve packages details: https://libraries.io/api

[brillout]

@octref what speaks against having both? I.e. the data stored as a static md file with a dynamic website based on it.
@shershen08 ok

@ everyone

The todo list https://github.com/brillout/awesome-vue/issues/3 is getting smaller.

Anyone up for reviewing the learning material?
Anyone up for Boilerplates & Scaffolding?

[brillout]

It's almost done, libraries and projects are now reviewed.

Only the learning material part is left to be reviewed. Anyone up for it?

[brillout]

The cleaned & new Awesome Vue list: brillout/awesome-vue/README_CLEANED.md. Everything in Projects Using Vue.js has been reviewed by @Ffloriel and I reviewed everything in Components & Libraries.

I have added three top level categories; Resources, Projects using Vue.js, and Components & Libraries. Feel free to object.

@posva

I'd suggest the next steps to be

• I ping the authors to give them the opportunity to object the review (by mentioning their GitHub username on a new ticket on brillout/awesome-vue).
• PR from brillout/awesome-vue/README_CLEANED.md to vuejs/awesome-vue/README.md.

[octref]

vscode-vue is removed per #880 and #915.

VuePack is for Visual Studio. vetur is for Visual Studio Code. Would appreciate if you can list them as two text editors. They are totally different things.

[brillout]

vscode-vue is removed

list them as two text editors

done brillout@67eeac2

[posva]

@brillout next steps look good to me. Thanks a lot for taking the time for this and sorry for not being very reactive, I simply cannot find the time 😓

[brillout]

next steps look good to me

Step 1 done; https://github.com/brillout/awesome-vue/issues/6

I simply cannot find the time

Thanks for the clarification, I was actually afraid you didn't like something!

Thanks a lot for taking the time for this

I guess I'm excited about the future of collaborative lists like that:)

[airyland]

@posva Thanks for keeping VUX 😃 , and English document will be available in few days.

[brillout]

It's almost done; The PR: #958