Javascript Ecosystem, How Trash It Actually Is?

This article is probably going to cause a lot of debate, primarily because of how much JavaScript is being used in our daily lives. This is going to be a harsh review but honest, and I want everyone, especially on Reddit, to discuss civilly and not end up with 1 million downvotes, which I am probably going to get, but I can take it. Don't worry.

We are going to start from the language, talk Typescript and then move down to the frameworks and libraries and at the end I am going to give a solution.

The Language

Being a high-level language, JavaScript gives us a lot of tools to work with. That means we can basically create everything with it, from frontend applications with complex UIs to backend architectures and solutions that solve modern-day problems, all with a simple syntax at first glance.

Yet, this is not true in the real world. JavaScript has a lot of features, and when I say a lot, I mean a lot:

1. Dynamic Typing

2. First-Class Functions

3. Prototype-based Inheritance

4. Event-driven Architecture

5. Asynchronous Programming with Promises

6. Lexical Scoping

7. Closure Scope Chain

8. Hoisting

9. Truthy and Falsy Values

10. Prototype Chain

11. Function Expressions vs. Function Declarations

12. The this Keyword

13. IIFE (Immediately Invoked Function Expressions)

14. Truthy and Falsy Coercion

15. Prototype Pollution

16. Memoization

17. Callback Hell

18. Event Loop

19. Currying

20. Memoization

21. Shallow Copy vs. Deep Copy

22. Ternary Operator

23. Truthy and Falsy Evaluation

24. Type Coercion

25. Typeof Operator

26. The new Keyword

27. The delete Operator

28. WeakMap and WeakSet

29. Function Composition

30. Garbage Collection

I can go on and on forever, but the thing you need to keep in mind is that this language does not have a specific purpose like Java, Kotlin, C#, or Python. I believe that JavaScript should have been kept only for working with the Web APIs and the DOM, as this is its main purpose, or at least it used to be.

The problems that this issue creates are many, but one of the main ones is that there is no single way to do things. There isn't a best practice; we just have abstractions on top of abstractions and so on.

You want to create a CLI? You have 30 libraries and frameworks to do it. You want SSR? You had Next.js, but now, for some reason, it has transitioned to a full-stack framework. Also, the language is OOP, but for some reason, we now want to make it functional.

Where does this stop? The answer is nowhere, and when you think you have solved everything, here comes TypeScript to fouck things up again.

Typescript

On top of all that, now we want to make JavaScript type-safe. So let's add 10 more configuration files, add a compiler, and now we have bullcrap^2. Just like Facebook invented HackLang, Microsoft invented TypeScript, but only companies of this magnitude need such features. The average Joe from Delaware does not need all that.

I have worked on projects with over 150K lines of code without TypeScript, and everything works just fine and is organized as well. However, if you have 30 employees working on a single project, of course, you need it.

Configuration Files

Strapi is a Headless CMS built with TypeScript. It has a backend and a frontend. Just take a look at how many configuration files it has just for running the project.

Yes, I know some of these files are for Docker, deployment, etc. But just looking at them seems daunting.

Frameworks and Libraries

Here we go to the fun part. I don't know where to start because we have 20 of them just for writing HTML. Vue, React, Angular, Lit, Svelte, Polymer, Ember, Preact, Next.js, etc.

Why do average developers need all of them just to write CSS and HTML? Every single one of them has a big learning curve, meaning that you write JavaScript, but every time it feels like you are learning a new language. This means these frameworks are like languages of their own.

If they were actually useful, you wouldn't need to spend 30 hours learning them when you already know the language.

For example, when you use Python, Java, C, or Go, if you know the language, there is no barrier to entry for any new technology in that language.

Abstractions on top of abstraction this is what they are.

Solution

Like every debate in life, arguing for 1 hour without giving a solution is a waste of time, so here is my solution.

Only use JavaScript for frontend development and interacting with the DOM. Don't use it on the backend or for anything server-related.

The average developer should use Vanilla JavaScript with Web Components when creating their UIs. If needed, use Polymer or Lit for utilizing web components, which are actually a native browser feature.

For larger companies that have many developers and very large codebases, again, use Polymer or Lit like YouTube does, and it works just fine.

React and other frameworks should only be used for very complex UIs that many developers work on. Then, and only then, add TypeScript. For example, when building a weather app with particles with a bunch of dashboards that utilize a lot of APIs and 10 developers work on it then you can use React or any other framework.

Final Words

In conclusion, while JavaScript has an expansive ecosystem that offers numerous possibilities, it's important to recognize its limitations and complexities. By focusing JavaScript usage primarily on frontend development and utilizing frameworks and libraries judiciously, developers can streamline their workflow and reduce unnecessary complications.

For larger projects with multiple developers, incorporating TypeScript and more sophisticated frameworks may be beneficial.

Thanks for reading, and I hope you found this article helpful. If you have any questions, feel free to email me at [e-mail], and I will respond.

You can also keep up with my latest updates by checking out my X here: x.com/sotergreco