1 files changed, 85 insertions, 14 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
index 2b8b35b..47b95d5 100644
--- 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
@@ -1,41 +1,112 @@
 ---
 title: My love and hate relationship with Node.js
 url: my-love-and-hate-relationship-with-nodejs.html
-date: 2020-03-30
+date: 2020-03-30T12:00:00+02:00
 draft: false
 ---
-Previous project I was working on was being coded in [Golang](https://golang.org/). Also was my first project using it. And damn, that was an awesome experience. The whole thing is just superb. From how errors are handled. The C-like way you handle compiling. The way the language is structured making it incredibly versatile and easy to learn.
+Previous project I was working on was being coded in [Golang](https://golang.org/). 
+Also was my first project using it. And damn, that was an awesome experience. 
+The whole thing is just superb. From how errors are handled. The C-like way 
+you handle compiling. The way the language is structured making it incredibly 
+versatile and easy to learn.
-It may cause some pain for somebody that is not used of using interfaces to map JSON and doing the recompilation all the time. But we have tools like [entr](http://eradman.com/entrproject/) and [make](https://www.gnu.org/software/make/) to fix that.
+It may cause some pain for somebody that is not used of using interfaces to map 
+JSON and doing the recompilation all the time. But we have tools like 
+[entr](http://eradman.com/entrproject/) and [make](https://www.gnu.org/software/make/) 
+to fix that.
-But we are not here to talk about my undying love for **Golang**. Only in some way we probably should. It is an excellent example of how modern language should be designed. And because I have used it extensively in the last couple of years this probably taints my views of other languages. And is doing me a great disservice. Nevertheless, here we are.
+But we are not here to talk about my undying love for **Golang**. Only in some 
+way we probably should. It is an excellent example of how modern language 
+should be designed. And because I have used it extensively in the last couple 
+of years this probably taints my views of other languages. And is doing me a 
+great disservice. Nevertheless, here we are.
-About two years ago I started flirting with [Node.js](https://nodejs.org/en/) for a project I started working on. What I wanted was to have things written in a language that is widely used, and we could get additional developers for. As much as **Golang** is amazing it's really hard to get developers for it. Even now. And after playing around with it for a week I felt in love with the speed of iteration and massive package ecosystem. Do you want SSO? You got it! Do you want some esoteric library for something? There is a strong chance somebody wrote it. It is so extensive that you find yourself evaluating packages based on **GitHub stars** and number of contributors. You get swallowed by the vanity metrics and that potentially will become the downfall of Node.js.
+About two years ago I started flirting with [Node.js](https://nodejs.org/en/) 
+for a project I started working on. What I wanted was to have things written
+in a language that is widely used, and we could get additional developers for. 
+As much as **Golang** is amazing it's really hard to get developers for it. 
+Even now. And after playing around with it for a week I felt in love with the 
+speed of iteration and massive package ecosystem. Do you want SSO? You got it!
+Do you want some esoteric library for something? There is a strong chance 
+somebody wrote it. It is so extensive that you find yourself evaluating 
+packages based on **GitHub stars** and number of contributors. You get 
+swallowed by the vanity metrics and that potentially will become the downfall 
+of Node.js.
-Because of the sheer amount of choice I often got anxiety when choosing libraries. Will I choose the correct one? Is this library something that will be supported for a foreseeable future or not? I am used of using libraries that are being in development for 10 years plus (Python, C) and that gave me some sort of comfort. And it is probably unfair to Node.js and community to expect same dedication.
+Because of the sheer amount of choice I often got anxiety when choosing 
+libraries. Will I choose the correct one? Is this library something that will 
+be supported for a foreseeable future or not? I am used of using libraries that 
+are being in development for 10 years plus (Python, C) and that gave me some 
+sort of comfort. And it is probably unfair to Node.js and community to expect 
+same dedication.
-Moving forward ... Work started and things were great. **Speed of iteration was insane**. For some feature that I would need a day in Golang only took me hour or two. I became lazy! Using packages all over the place. Falling into the same trap as others. Packages on top of packages. And [npm](https://www.npmjs.com/) didn't help at all. The way that the package manager works is just horrendous. And not allowing to have node_modules outside the project is also the stupidest idea ever.
+Moving forward ... Work started and things were great. 
+**Speed of iteration was insane**. For some feature that I would need a day 
+in Golang only took me hour or two. I became lazy! Using packages all over 
+the place. Falling into the same trap as others. Packages on top of packages. 
+And [npm](https://www.npmjs.com/) didn't help at all. The way that the package
+manager works is just horrendous. And not allowing to have node_modules outside
+the project is also the stupidest idea ever.
-So at that point I started feeling the technical debt that comes with Node.js and the whole ecosystem. What nobody tells you is that **structuring large Node.js apps** is more problematic than one would think. And going microservice for every single thing is also a bad idea. The amount of networking you introduce with that approach always ends up being a pain in the ass. And I don't even want to go into system administration here. The overhead is insane. Package-lock.json made many days feel like living hell for me. And I would eat the cost of all this if it meant for better development experience. Well, it didn't.
+So at that point I started feeling the technical debt that comes with Node.js 
+and the whole ecosystem. What nobody tells you is that 
+**structuring large Node.js apps** is more problematic than one would think. 
+And going microservice for every single thing is also a bad idea. The amount 
+of networking you introduce with that approach always ends up being a pain in 
+the ass. And I don't even want to go into system administration here. The 
+overhead is insane. Package-lock.json made many days feel like living hell 
+for me. And I would eat the cost of all this if it meant for better development 
+experience. Well, it didn't.
-The **lack of Typescript** support in the interpreter is still mind boggling to me. Why haven't they added native support yet for this is beyond me?! That would have solved so many problems. Lack of type safety became a problem somewhere in the middle of the project where the codebase was sufficiently large enough to present problems. We started adding arguments to functions and there was **no way to implicitly define argument types**. And because at that point there were a lot of functions, it became impossible to know what each one accepts, development became more and more trial and error based.
+The **lack of Typescript** support in the interpreter is still mind boggling 
+to me. Why haven't they added native support yet for this is beyond me?! That
+would have solved so many problems. Lack of type safety became a problem 
+somewhere in the middle of the project where the codebase was sufficiently 
+large enough to present problems. We started adding arguments to functions 
+and there was **no way to implicitly define argument types**. And because at 
+that point there were a lot of functions, it became impossible to know what 
+each one accepts, development became more and more trial and error based.
-I tried **implementing Typescript**, but that would present a large refactor that we were not willing to do at that point. The benefits were not enough. I also tried [Flow - static type checker](https://flow.org/) but implementation was also horrible. What Typescript and Flow forces you is to have src folder and then **transpile** your code into dist folder and run it with node. WTH is that all about. Why can't this be done in memory or some virtual file system? Why? I see no reason why this couldn't be done like this. But it is what it is. I abandoned all hope for static type checking.
+I tried **implementing Typescript**, but that would present a large refactor 
+that we were not willing to do at that point. The benefits were not enough. 
+I also tried [Flow - static type checker](https://flow.org/) but implementation 
+was also horrible. What Typescript and Flow forces you is to have src folder 
+and then **transpile** your code into dist folder and run it with node. WTH is 
+that all about. Why can't this be done in memory or some virtual file system? 
+Why? I see no reason why this couldn't be done like this. But it is what it is.
+I abandoned all hope for static type checking.
-One of the problems that resulted from not having interfaces or types was inability to model out our data from **Elasticsearch**. I could have done a **pedestrian implementation** of it, but there must be a better way of doing this without resorting to some hack basically. Or maybe I haven't found a solution, which is also a possibility. I have looked, though. No juice!
+One of the problems that resulted from not having interfaces or types was 
+inability to model out our data from **Elasticsearch**. I could have done 
+a **pedestrian implementation** of it, but there must be a better way of doing 
+this without resorting to some hack basically. Or maybe I haven't found a 
+solution, which is also a possibility. I have looked, though. No juice!
 **Error handling?** Is that a joke?
-Thank god for **await/async**. Without it, I would have probably just abandoned the whole thing and went with something else like Python. That's all I am going to say about this :)
+Thank god for **await/async**. Without it, I would have probably just abandoned 
+the whole thing and went with something else like Python. That's all I am 
+going to say about this :)
+I started asking myself a question if Node.js is actually ready to be used in 
+a **large scale applications**? And this was a totally wrong question. What I 
+should have been asking myself was, how to use Node.js in large scale 
+application. And you don't get this in **marketing material** for Express or 
+Koa etc. They never tell you this. Making Node.js scale on infrastructure or 
+in codebase is really **more of an art than a science**. And just like with the 
+whole JavaScript ecosystem:
-I started asking myself a question if Node.js is actually ready to be used in a **large scale applications**? And this was a totally wrong question. What I should have been asking myself was, how to use Node.js in large scale application. And you don't get this in **marketing material** for Express or Koa etc. They never tell you this. Making Node.js scale on infrastructure or in codebase is really **more of an art than a science**. And just like with the whole JavaScript ecosystem:
 - impossible to master,
 - half of your time you work on your tooling,
 - just accept transpilers that convert one code into another (holly smokes),
 - error handling is a joke,
 - standards? What standards?
-But on the other hand. As I did, you will also learn to love it. Learn to use it quickly and do impossible things in crazy limited time.
+But on the other hand. As I did, you will also learn to love it. Learn to use 
+it quickly and do impossible things in crazy limited time.
 I hate to admit it. But I love Node.js. Dammit, I love it :)
+2023 Update: I hate Node.js!

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