Vue-cli: Promote an Official Template for building VueJs web apps using best practices, naming conventions and other standards.

[iamyero]

Read an article about Angular (https://isl.co/2016/07/three-major-reasons-we-decided-to-ditch-angularjs/) and how fragmented and inconsistent the community was and I think the same could be said of VueJs in the future. VueJs flexibility could be what holds it back from total adoption/domination.

I have long admired how once you know EmberJs you can jump into any project and immediately become productive. BUT EmberJS learning curve is step unlike VueJs.

In talking with @LinusBorg he suggested I post here so the community can discuss.

Here is an example of what could be possible - https://github.com/iamyero/vue-baseline

Other Resources:

• https://ember-cli.com/user-guide/#naming-conventions
• http://laravelbook.com/laravel-architecture/
• https://laravel.com/docs/5.1/structure

It would be good where similar to embercli, vuecli encourages these standards.

[zigomir]

Hi @iamyero.

I mostly agree with you on ember-cli. The main difference in my opinion is that they have one and only one way to do it. We have many official templates to start with, not even counting that anyone can build their own.

We want vue-cli to stay focused and minimal tool to get (download) your template and from there you have just npm scripts with browserify or webpack (or none at all).

Most complete official template is definitely webpack one. You have docs, proxy server, linting, testing, configuration all prepared for you to use.

As you probably know you're not locked to official templates. This gives you freedom but in same time it causes you need to do more decisions yourself.

I think at the end is all just a meter of balance. How many of these decisions can we make up front for all (most) of our users and how many or which ones users want to do on their own.

What I would propose is that we keep or (even market?) a webpack template as official/blessed one, like ember-cli does. But on the other hand we need to tell that there are more options because there are developers who don't want webpack or even browserify or any build step.

I wouldn't go as far as ember-cli, because I think we have a good tooling today and there is not a lot of pain getting started with vue.

[iamyero]

Setting a standard doesn't preclude others from going out and doing their own.

It won't make vue-cli any heavier and it sets out the best practices for newbies and pros to follow.

Actually, If you follow @yyx990803 examples there appears to be an inherent pattern that could become the basis of this standard.

From a business perspective it would be better to use a standard and hire someone you knows the standard. New hires would immediately become productive on the team and not have to now learn some new way of doing things at each and every job they take up.

It's like people who hire for rails and emberjs, they are expected to know certain things.

The pain is never in starting, the pain is in continuing, maintaining and growing the code base.

Leaving most things up to developers is what is going to create the fragmentation and the inconsistencies.

Setting a standard is not limiting, it frees developers up to concentrate on what is important...writing code.

[chrisvfritz]

@iamyero As @zigomir said, I think we strike a good balance already. I personally use a variety of structures for different kinds of Vue applications. And as those applications change and grow, I often update that structure. There simply isn't One Golden Way that everyone should follow. As a member of the Rails community as well, I've seen too much convention lead to non-thinking and God files with thousands of lines - because there's no other obvious place for some logic, _yet_.

That said, one of our big goals for 2.0 is even better documentation, with more examples solving common problems. We're also exploring the development of a cookbook. By helping people learn where and why various patterns are useful, I think we can promote a smarter ecosystem.

[iamyero]

I agree that is good to have the flexibility and that there is no golden way to do everything.

However EmberJs has put together a set of best practices that developers can follow, "the Ember way", you still can do it how you feel BUT there is a community recommendation/foundation.

Pickup any Ember (or rails) project and you will be able to immediately start coding.

If everyone is using a "variety of structures for different kinds of Vue applications" then fragmentation and inconsistencies are going to be introduced.

Also how is this different from the Angular approach which lead to the article and perhaps the reasons why VueJs was inspired to be created?

Giving best practices for developers to follow isn't limiting or restricting, it will help developers structure their web app in away that will prevent pitfalls (similar to how in 2.0 you are removing .sync, broadcast and so on), reduce fragmentation and create a consistent way for most projects to be developed.

Setting out best practices is a win for the VueJs community in the long run.

[chrisvfritz]

@iamyero No one is arguing against establishing best practices where it makes sense. We simply disagree on where it does. I don't really mind whether someone keeps static assets in a folder called static or public, or whether the source directory is called src or app. When I work with different teams, I use the conventions they're already using. Familiarizing myself with their folder structure typically takes a few minutes. It's really not a big deal.

The only reason that Ember and Rails provide strict rules on the names and structure of files and folders is because their proprietary and implicit module resolution systems depend on those strict rules. If you don't follow them, everything breaks. What you're praising doesn't bring any inherent value and wasn't even an explicit design decision made by either team. It's just a _side effect_ of how they chose to resolve modules. I'd like to emphasize that:

When moving between projects, it's not folder structures and names that take a long time to learn - it's new concepts and tech stacks.

In Vue, we already provide the core concepts you'll need to build most frontend applications - complete with excellent documentation. We also provide officially supported companion libraries. When the article you linked to very briefly complained about the fragmentation in the early Angular ecosystem, they were referring to a _lack_ of defacto companion libraries. We've already solved that problem, so you need not be worried about Vue repeating the mistake.

Finally, I just have to address this:

Pickup any Ember (or rails) project and you will be able to immediately start coding.

This simply isn't true. I've consulted on plenty of Rails apps where new developers were afraid to touch anything for _weeks_. In fact, many of their problems came directly from a fear of venturing outside the conventions, because they were punished when they did. Rails didn't provide an obvious place for every concept in their app and no obvious way to extend the conventions, so they just dump logic in a model/controller/helper. They actually become afraid to think for themselves and create new folders.

[blake-newman]

On a seperate note, one thing that may bring value would be an Eslint plugin. Where different connection can be applied to Vue files. Eg casing for component names, and order of component properties.

This should be defined outside the tooling, and should be flexible. As @chrisvfritz mentioned, this is the easiest thing to learn about a project. An Eslint plugin could help provide consistency with project development.

This is on my roadmap to explore along with stylelint plugin. However, plenty to do at moment, but will defiantly investigate soon.

[iamyero]

@blake-newman I like where your going with that.

@chrisvfritz I get what you are saying, and I may have been overemphasising on structure but it's really more than just file and folder locations.

I like how @zigomir put it "webpack template as official" ... "But on the other hand we need to tell that there are more options".

Wouldn't it be great if VueJs webpack template proposed (in more detail) a common way of integrating all libs (vue-router, vue-resource, etc)? It would go afar way in uniting the community and having a common platform as the foundation.

[yyx990803]

FYI, I agree with most of @chrisvfritz 's opinion in this thread.

[iamyero]

Thanks for the feedback.

[chrisvfritz]

@iamyero If you haven't already seen, you may be interested to know that we are eventually interested in adding options for vue-router and other libraries to the Webpack template. I'd like to do more work to make the template more robust (i.e. testable) first though. We've been kicking around some ideas internally to accomplish that.

[iamyero]

Wasn't aware, looks like you are heading in the direction I am trying to articulate.