|
Listen to this story
|
People from all programming backgrounds use JavaScript, the lingua franca of the web, at some point in their careers. Therefore, even though it may have some nasty elements, it is necessary to accept them and learn how to avoid the bad parts. Make no mistake, one can write good codes in JavaScript if they understand the language’s failures and work around them. ‘Javascript: the Good Parts’ is an excellent book on this topic.
JavaScript is particularly hard to code in because it is a completely botched language design that people started using for something other than what it was initially meant for. It is an embodiment of almost three decades of decisions that cannot be discarded or reconsidered because almost all of the web runs on this technology, and any backwards-incompatible changes could affect millions of users.
Here are 6 pain points one can work around to write a good code in Javascript.
Code Architecture
You don’t have to be a master software architect, but at least perform some basic planning and put pieces together without massive layers of tooling. Expecting frameworks and other tools to do it for you isn’t very impressive.
Since JavaScript and HTML leave out some basic structures and components that are so commonly needed, these libraries often overlap in functionality and features. This also means some play poorly together. The availability of a plethora of options can be frustrating to choose from, as it ultimately decides the fate of a product.
Managing Dependencies
Most JavaScript projects start ambitiously, trying not to use too many NPM packages. But, even with a lot of effort, packages eventually pile up. Package.json lines increase over time, and package-lock.json makes pull requests look scary with the number of additions or deletions when dependencies are added.
Keep the main package registry (NPM, yarn) from being the only source of your dependencies. It may crash, go down, lose the packages etc. On the other hand, you may be unable to reach it, for example, due to network issues. Avoid packages registries being a single point of failure for your project. Use dedicated proxies or local repositories to minimize these risks.
State Management
All the bits of data managed in the app as the user interacts with it is app state. With any app, there is always state. This is likely the reason why beginners don’t grasp it. State is in so many places that it is hard to define it precisely. But once you see examples of it and know what it is, you realize it is everywhere.
State exists in every application, even those made with plain JavaScript. It’s not a concept specific to JS libraries; it’s necessary to understand for any app you intend to make. Unfortunately, for many, state management feels like a black box. Hence, state management is one of the most complicated topics in modern and JavaScript-focused front-end development.
Data Management
JavaScript automatically assigns memory as and when objects are created and freed when not used anymore. Unfortunately, this is a potential source of confusion: it can give developers the false impression that they don’t need to worry about memory management.
Generally, not caring enough about memory management doesn’t produce noticeable consequences regarding “old-fashioned” web pages. But the SPA (Single Page Application) advancement encourages being attentive to memory-related coding practices. If the application starts using more and more memory, it can seriously affect the performance and even crash the browser’s tab.
Debugging
JavaScript is the web language used by over 90% of websites. Still, it has a reputation for being difficult to debug. Unfortunately, what makes JavaScript great is also what makes it frustrating to debug. For example, its asynchronous nature makes it easy to manipulate the DOM in response to user events, but it also makes it difficult to locate problems.
You can’t debug JavaScript without using tools like alert(), Postman, Raygun, and the Chrome console. But these tools can also cause problems.
Finding Packages
The NPM website is great. You can search among all public packages and get various information such as documentation, GitHub link, and general data (version, number of issues, date of last publication). However, more than this might be needed to choose the right package that suits your project. You would need a complete overview to be more efficient in your choice.
Choosing the right package from an endless number of modules can be overwhelming. For example, you would like to know if a package is popular enough, well-maintained, supported by the community, and completely secure.
