Best Practice Guidelines for Javascript Applications?

[HaraldKi]

This movement will likely not fly without the guidelines someone suspected of being a framework in themselves once they are written. Guidelines help to understand what good components are and why they are good. A software framework (merely) tries to enforce getting out good components even without understanding why they are good.

The guidelines should assume that one does not use a framework with some reasonable definition of 'framework' as you did with the simplistic, but, I think effective: 'a framework calls your code' (in contrast your code calls a library)'.

The guidelines should describe what to do and what to avoid to get reusable software, in particular UI elements/components, with plain Javascript. I wouldn't expect to find, for example, a suggestion to use web components or not, but rather abstract recommendations what to watch out for regarding the non-exhaustive list

• creating, changing and removing DOM structures
• maintaining state
• attaching, removing and handling events in a non-intrusive way to facilitate reuse
• defining CSS rules for the component with reasonable prevention of littering the global namespace
• ...(you name it)...

These guideline could even be used as a checklist for libraries to include in a project, assuming that if too many guidelines are not followed by the library it may need extra thought before being depended on.

A lot of 'best practice javascript' sites are out there, so maybe some have good guidelines already, but the ones I looked at so far have 'coding best practice' and not much about 'design of reusable components'.

[francesco-strazzullo]

Hi @HaraldKi and thanks for your involvement.

I think that your pain about guidelines should not be part of this manifesto for two main reasons.

1. This repository is not just about JavaScript or Front-end components
2. A manifesto is not a "guide" but a "a public declaration of policy and aims"

But for the very reasons that you explained opening this issue, we created the Awesome Frameworkless. A list of videos, blog posts and code examples about Frameworkless in any language or ecosystem.

Feel free to add materials to the repo, we will be glad to accept them.

[foxbunny]

This movement will likely not fly without the guidelines someone suspected of being a framework in themselves once they are written.

I've been rooting for frameworkless development for a while now, and I'm realizing two issues:

• Majority of people who find frameworkless development unacceptable and vehemently oppose it are not actually thinking in terms of "framework" vs "frameworkless" but in terms of "what everyone else is doing". To them, deviation from the prevalent practice is the problem, not what method you use. If, for some reason, frameworkless ever became mainstream, they would probably be on the other side of the table cancelling those that use frameworks.
• Following guidelines blindly has the same effect as using a framework without understanding what they do. Personally my concern is that prematurely publishing such guidelines would turn frameworkless into a framework and create the same kind of cancel culture that surrounds framework usage.

The guidelines should describe what to do and what to avoid to get reusable software, in particular UI elements/components, with plain Javascript.

If you're strictly looking for the technical side of things, there's already plenty of material on MDN (at least for JavaScript and web development), so the problem is not the lack of material but the lack of people learning what's in those materials and effectively applying them to real-world problems.

I believe how you actually go about coding is not so important. The manifesto says "This risk is amplified without the presence of a strong bond between technical decision making, business goals, and user experience." Once this problem is resolved, technical decisions should naturally follow given sufficient level of expertise. When you take into account the business goals, UX, and the various programming techniques one needs to acquire in order to position themselves to make such decisions, I think it is not something you can summarize in a guideline. (At least not without leaving lots of room for wrong interpretations.)

Having said all that, a place where people can transfer their experiences to the interested practitioners is probably a welcome complement to the manifesto, because it's one thing to talk about it, and an entirely different matter to actually sit down and code. There's a bit of tacit knowledge in all this.