Please bear in mind: arguably, JS can be declared to be the biggest relief to the EE-world in the past decade. Finally, EE apps can be developed much faster, building up lighter yet well-performing codebase, shorter learning curves, more reliable services and it goes on…
It is a paradigm-shift without question, and like every shift, JS might also treat ungratefully those, who approaches unpreparedly. Ignoring the important principles can groove your project to go awry.
Welcome my golden rules for JS introduction to your EE project
- JS is not JAVA! The 2 languages can be considered antipodes rather than neighbours as for code and style conventions, paradigms and styles, project and code orchestration and modularity, project methodology and code culture. JS’ most basic term is the functional and has an own dynamic, typeless and free style, deal with it. You fail if you want to see Java reflecting in your JS code. Learn the basics and language features, learn them right and well.
- Diversity over monochromacity There are no standard ways, proposals or recommended blueprints, design patterns, 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.
- The start of everything is at your methodology and processes. JS is not just another language. It's nature has been derived from the functional paradigm, inherited from the OO paradigm and 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.
- Refactoring and Reorchestration are parts of the development cycle Spend time on them. To save ourselves from spaghetti-code, JS code demands some care from time to time as your codebase grows.
- Introduction of company-, or project-wide code/tool/style conformity is strongly advised. There are 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 and style justified by some business need, procreating a babel of fuzziness in your project.
- Simplicity is king. JS codebase must be kept as thin as possible and as functional as you can follow. Do not attempt to build up star-fleets or to construct autotelic abstraction-hills, you will die maintaining it and fail to feel the JS-flow.
- Lifetime of JS libs can be measured in months/quarters. There is a new king every quarter. The fast rolling JS-world which expects unwearying, tireless tenacity from you, is clearly unfolded. Be open and flexible and hungry, and do not want to prepare for retirement using the knowledge of today for decades. Another angle to consider is maintainability of the development and support of your project which lasts year sand is exposed to fluctuation.
+1. 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.
We will elaborate on these ideas in detail in a series of following blog posts, where we will look át hands on examples.
Feel free to share your thoughts in comments below, I am willing to exchange thoughts with you.
If you consider to start a new project soon or to move your stack to NodeJS and do not mind some support and consulting, please let us know.
We are open for business at NLV8 Technologies.