Improving Awesome Vue.js about awesome-vue HOT 33 CLOSED

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

from awesome-vue.

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.

from awesome-vue.

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

from awesome-vue.

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

from awesome-vue.

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

from awesome-vue.

@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

from awesome-vue.

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.

from awesome-vue.

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.

from awesome-vue.

vscode-vue is removed

list them as two text editors

done brillout@67eeac2

from awesome-vue.

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

from awesome-vue.

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.

from awesome-vue.

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.

from awesome-vue.

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

from awesome-vue.

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

from awesome-vue.

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

from awesome-vue.

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

from awesome-vue.

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

from awesome-vue.

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

from awesome-vue.

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

from awesome-vue.

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

from awesome-vue.

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

from awesome-vue.

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

from awesome-vue.

@brillout please do.

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

from awesome-vue.

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

from awesome-vue.

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

from awesome-vue.

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

from awesome-vue.

@octref @brillout

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

from awesome-vue.

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

from awesome-vue.

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

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

from awesome-vue.

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.

from awesome-vue.

@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 😓

from awesome-vue.

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:)

from awesome-vue.

It's almost done; The PR: #958

from awesome-vue.