aboutsummaryrefslogtreecommitdiff
path: root/content/posts/2020-03-30-my-love-and-hate-relationship-with-nodejs.md
diff options
context:
space:
mode:
authorMitja Felicijan <m@mitjafelicijan.com>2023-07-08 23:25:41 +0200
committerMitja Felicijan <m@mitjafelicijan.com>2023-07-08 23:25:41 +0200
commitcd6644ea4ddc78597934ab0ef5ba50e3c3daa927 (patch)
tree03de331a8db6386dfd6fa75155bfbcea6b4feaf3 /content/posts/2020-03-30-my-love-and-hate-relationship-with-nodejs.md
parent84ed124529ffeee1590295b8de3a8faf51848680 (diff)
downloadmitjafelicijan.com-cd6644ea4ddc78597934ab0ef5ba50e3c3daa927.tar.gz
Moved to a simpler SSG
Diffstat (limited to 'content/posts/2020-03-30-my-love-and-hate-relationship-with-nodejs.md')
-rw-r--r--content/posts/2020-03-30-my-love-and-hate-relationship-with-nodejs.md110
1 files changed, 0 insertions, 110 deletions
diff --git a/content/posts/2020-03-30-my-love-and-hate-relationship-with-nodejs.md b/content/posts/2020-03-30-my-love-and-hate-relationship-with-nodejs.md
deleted file mode 100644
index daebb4c..0000000
--- a/content/posts/2020-03-30-my-love-and-hate-relationship-with-nodejs.md
+++ /dev/null
@@ -1,110 +0,0 @@
1---
2title: My love and hate relationship with Node.js
3url: my-love-and-hate-relationship-with-nodejs.html
4date: 2020-03-30T12:00:00+02:00
5draft: false
6---
7
8Previous project I was working on was being coded in
9[Golang](https://golang.org/). Also was my first project using it. And damn,
10that was an awesome experience. The whole thing is just superb. From how errors
11are handled. The C-like way you handle compiling. The way the language is
12structured making it incredibly versatile and easy to learn.
13
14It may cause some pain for somebody that is not used of using interfaces to map
15JSON and doing the recompilation all the time. But we have tools like
16[entr](http://eradman.com/entrproject/) and
17[make](https://www.gnu.org/software/make/) to fix that.
18
19But we are not here to talk about my undying love for **Golang**. Only in some
20way we probably should. It is an excellent example of how modern language should
21be designed. And because I have used it extensively in the last couple of years
22this probably taints my views of other languages. And is doing me a great
23disservice. Nevertheless, here we are.
24
25About two years ago I started flirting with [Node.js](https://nodejs.org/en/)
26for a project I started working on. What I wanted was to have things written in
27a language that is widely used, and we could get additional developers for. As
28much as **Golang** is amazing it's really hard to get developers for it. Even
29now. And after playing around with it for a week I felt in love with the speed
30of iteration and massive package ecosystem. Do you want SSO? You got it! Do you
31want some esoteric library for something? There is a strong chance somebody
32wrote it. It is so extensive that you find yourself evaluating packages based on
33**GitHub stars** and number of contributors. You get swallowed by the vanity
34metrics and that potentially will become the downfall of Node.js.
35
36Because of the sheer amount of choice I often got anxiety when choosing
37libraries. Will I choose the correct one? Is this library something that will be
38supported for a foreseeable future or not? I am used of using libraries that are
39being in development for 10 years plus (Python, C) and that gave me some sort of
40comfort. And it is probably unfair to Node.js and community to expect same
41dedication.
42
43Moving forward ... Work started and things were great. **Speed of iteration was
44insane**. For some feature that I would need a day in Golang only took me hour
45or two. I became lazy! Using packages all over the place. Falling into the same
46trap as others. Packages on top of packages. And [npm](https://www.npmjs.com/)
47didn't help at all. The way that the package manager works is just
48horrendous. And not allowing to have node_modules outside the project is also
49the stupidest idea ever.
50
51So at that point I started feeling the technical debt that comes with Node.js
52and the whole ecosystem. What nobody tells you is that **structuring large
53Node.js apps** is more problematic than one would think. And going microservice
54for every single thing is also a bad idea. The amount of networking you
55introduce with that approach always ends up being a pain in the ass. And I don't
56even want to go into system administration here. The overhead is
57insane. Package-lock.json made many days feel like living hell for me. And I
58would eat the cost of all this if it meant for better development
59experience. Well, it didn't.
60
61The **lack of Typescript** support in the interpreter is still mind boggling to
62me. Why haven't they added native support yet for this is beyond me?! That would
63have solved so many problems. Lack of type safety became a problem somewhere in
64the middle of the project where the codebase was sufficiently large enough to
65present problems. We started adding arguments to functions and there was **no
66way to implicitly define argument types**. And because at that point there were
67a lot of functions, it became impossible to know what each one accepts,
68development became more and more trial and error based.
69
70I tried **implementing Typescript**, but that would present a large refactor
71that we were not willing to do at that point. The benefits were not enough. I
72also tried [Flow - static type checker](https://flow.org/) but implementation
73was also horrible. What Typescript and Flow forces you is to have src folder and
74then **transpile** your code into dist folder and run it with node. WTH is that
75all about. Why can't this be done in memory or some virtual file system? Why? I
76see no reason why this couldn't be done like this. But it is what it is. I
77abandoned all hope for static type checking.
78
79One of the problems that resulted from not having interfaces or types was
80inability to model out our data from **Elasticsearch**. I could have done a
81**pedestrian implementation** of it, but there must be a better way of doing
82this without resorting to some hack basically. Or maybe I haven't found a
83solution, which is also a possibility. I have looked, though. No juice!
84
85**Error handling?** Is that a joke?
86
87Thank god for **await/async**. Without it, I would have probably just abandoned
88the whole thing and went with something else like Python. That's all I am going
89to say about this :)
90
91I started asking myself a question if Node.js is actually ready to be used in a
92**large scale applications**? And this was a totally wrong question. What I
93should have been asking myself was, how to use Node.js in large scale
94application. And you don't get this in **marketing material** for Express or Koa
95etc. They never tell you this. Making Node.js scale on infrastructure or in
96codebase is really **more of an art than a science**. And just like with the
97whole JavaScript ecosystem:
98
99- impossible to master,
100- half of your time you work on your tooling,
101- just accept transpilers that convert one code into another (holly smokes),
102- error handling is a joke,
103- standards? What standards?
104
105But on the other hand. As I did, you will also learn to love it. Learn to use it
106quickly and do impossible things in crazy limited time.
107
108I hate to admit it. But I love Node.js. Dammit, I love it :)
109
1102023 Update: I hate Node.js!