- Clear best pratices provided with tools. Do you know how to code a react project ? The person next to you has a different answer.
- Reference implementations. We heard about the Flux pattern and the idea of stores for a long time before understanding concretly what it meant. And then pouf, 200 store and routing implementations differing in opinion, and no voice or advice about what to use and how.
- Integrations layers. Everything is a lib gets old really fast. And "look how redux is simple" as well. Assembly is simple but I don't code my website with it.
- Deprecation policies and clear migration path. Webpack was weird, quirky and badly documented. But the worst thing was that once you figured out something that works, a new version broke compat.
- Avoid dependancy creep. When a dependancy has more package metadata than code, there is a problem.
- Don't encourage a cowboy culture. It's great anybody can start coding in JS in an afternoon. It's not great that after a month the same person market his lib like it's the best thing ever and production ready.
- Documentation that makes sense. People explaining a new tool by showing you something webpack based or in in jsfiddle is not doing his job properly.
- Api best practices and design patterns have existed for a long time. Use them. KISS. DRY. Don't break user land. Principle of least surprise.
- Don't rename things that have had conventional names for decades. "Flux is a not MVC" is a lie. It's mono-directional, it encourages single instance immutable model. But it's still MVC. Most people looked for very complicated answer to what is flux because of that. And who name a lifecycle method "componentWillUpdate()" ? "onUpdate()" and "onPostUpdate()" are the legacy jargon. And then "UNSAFE_componentWillUpdate()" ? Really ? Like really ? Never heard of warnings ? Using the JS className instead of the HTML class in JSX is also still amazing me, not in a good way.
- Don't give the same name to 2 different products. Looking at you angular. Also SemVer is not a bad word, I and don't want your weird release name. That double the suff I potentially could google for.
- Conventions are nice. They should not replace configuration, but they complement it very well.
- There is such a thing as a "typical use case" for many tools. You should design for that, and if it's not possible for you, build a layer of top for that. Building facebook is not "a typical use case". Passing data from a children to a parent after a click and a preventDefault is. Why is the later so damn verbose ? Why did have I to google it ?
- Scaling down is as important as scaling up. Make simple things easy and complicated things possible, not the contrary.
- New is not always better, sorry barney stinson. Satisfying users with working software is. If you make or use something new, you should evaluate the cost for you and others before going "oh shiny !".
There are many others, but I don't feel happy writting this, so I'm going to stop.
- Clear best pratices provided with tools. Do you know how to code a react project ? The person next to you has a different answer.
- Reference implementations. We heard about the Flux pattern and the idea of stores for a long time before understanding concretly what it meant. And then pouf, 200 store and routing implementations differing in opinion, and no voice or advice about what to use and how.
- Integrations layers. Everything is a lib gets old really fast. And "look how redux is simple" as well. Assembly is simple but I don't code my website with it.
- Deprecation policies and clear migration path. Webpack was weird, quirky and badly documented. But the worst thing was that once you figured out something that works, a new version broke compat.
- Avoid dependancy creep. When a dependancy has more package metadata than code, there is a problem.
- Don't encourage a cowboy culture. It's great anybody can start coding in JS in an afternoon. It's not great that after a month the same person market his lib like it's the best thing ever and production ready.
- Documentation that makes sense. People explaining a new tool by showing you something webpack based or in in jsfiddle is not doing his job properly.
- Api best practices and design patterns have existed for a long time. Use them. KISS. DRY. Don't break user land. Principle of least surprise.
- Don't rename things that have had conventional names for decades. "Flux is a not MVC" is a lie. It's mono-directional, it encourages single instance immutable model. But it's still MVC. Most people looked for very complicated answer to what is flux because of that. And who name a lifecycle method "componentWillUpdate()" ? "onUpdate()" and "onPostUpdate()" are the legacy jargon. And then "UNSAFE_componentWillUpdate()" ? Really ? Like really ? Never heard of warnings ? Using the JS className instead of the HTML class in JSX is also still amazing me, not in a good way.
- Don't give the same name to 2 different products. Looking at you angular. Also SemVer is not a bad word, I and don't want your weird release name. That double the suff I potentially could google for.
- Conventions are nice. They should not replace configuration, but they complement it very well.
- There is such a thing as a "typical use case" for many tools. You should design for that, and if it's not possible for you, build a layer of top for that. Building facebook is not "a typical use case". Passing data from a children to a parent after a click and a preventDefault is. Why is the later so damn verbose ? Why did have I to google it ?
- Scaling down is as important as scaling up. Make simple things easy and complicated things possible, not the contrary.
- New is not always better, sorry barney stinson. Satisfying users with working software is. If you make or use something new, you should evaluate the cost for you and others before going "oh shiny !".
There are many others, but I don't feel happy writting this, so I'm going to stop.