This document provides 7 golden rules for introducing JavaScript to an embedded electronics project. The rules are: 1) JavaScript is not Java and has different fundamentals, 2) embrace diversity over standardized approaches, 3) start with processes as JavaScript impacts methodology, 4) regularly refactor and reorganize code to prevent spaghetti code, 5) introduce conventions for libraries, styles, and structures to avoid inconsistencies, 6) keep code simple, functional, and thin, and 7) be prepared for the short lifetimes of JavaScript libraries and flexible to change. An additional rule is to follow standards.

1. Golden rules for JS introduction
to your EE project
by NLV8 Technologies

2. New challenges
• arguably, JS can be declared to be the biggest relief to the
EE-world in the past decade
• EE apps can be developed
• much faster
• building up lighter yet well-performing codebase
• shorter learning curves
• more reliable services
• It is a paradigm-shift without question

3. New challenges
• Functional approach
• Full-stack JS
• Methodology
• Project and code management
• Development processes
• Toolsets
• Learning curves

4. Rule #1: JS is not JAVA!
• 2 languages can be considered antipodes rather
than neighbours
• JS is not a chunked, subset of Java
• You fail if you want to see Java reflecting in your
JS code
• Learn the basics and language features, learn
them right and well

5. Rule #2: Diversity over monochromacity
• There are no
• standard ways
• recommended blueprints
• design patterns
• good-for-everything solutions, stacks or frameworks
to bow to
• “Build your own comfort, do not seek for one.“
• Subtle differences can make strong distinctions, you can learn them
only by making experiments.

6. Rule #3: Start with processes
• JS is not just another language
• It's nature has been derived from the functional
paradigm, inherited from the OO paradigm
• JS follows a path pervaded by the dynamics as the
most basic principle
• JS impresses heavily on your software development
methodology, task distribution strategy, code culture
and test practices in general.
• Mind these aspects with adequate gravity.

7. Rule #4: Schedule reorchestration
• Do regular checkup on
• refactoring
• reorchestration
must-have parts of the development cycle
• To save yourself from spaghetti-code
• JS code demands some care from time to time as
your codebase grows

8. Rule #5: Introduction of conformity
• For:
• libraries/tools
• styles
• structures
• methodologies
• at least 5 ways to deal with async code by 50+ libs, you do not want to
see them mixed in the same function
• Libraries and frameworks have an intense attitude to bing own
conventions
• avoid the babel of fuzziness in your project

9. Rule #6: Simplicity is king
• JS codebase must be kept
• as thin as possible
• as functional as you can follow.
• Do not attempt to build up star-fleets or to construct autotelic
abstraction-hills
• Feel the JS-flow, the functional world
• functions & functionals
• prototypes
• streams

10. Rule #7: Lifetime of JS libs
• Can be measured in months - for given version(s)
• There is a new king every quarter
• JS-world expects unwearying, tireless tenacity from you
• Be open and flexible and hungry
• Another angle to consider is
• maintainability of the development
• support of your project which lasts years and is exposed
to fluctuation

11. Rule +1: Follow the standards!
• Try to avoid libs/framewoks wanting to become
the standard and not following any
• Sever affinity can be observed in JS-world,
especially in the MVCs' world for deviation from
standards
• No philosophical essays can be considered as
apology for breaking the only design pattern of
JS: respect the standards.