Fuck React!
Fuck BCryptjs!!
Fuck Insomnia!!!
Fuck ExpressJs!!!
Fuck MongoDB!!!!!!
Fuck Case sensitivity!!!
Fuck Nodemon!!!!
Fuck coding!!!!!

You can now punch the wall.

But non-case-sensitive comparisons just get more confusing the more you think about them.

you know... Common Lisp has none of the above, maybe you could try it

@kobenz well, it does sort of have coding …

React was never viable to begin with.

BCryptjs? You have scrypt in node btw

Insomnia went to shit recently with their mandatory accounts.

ExpressJs? You don't really need it anymore, node's http has req and res just like express

MongoDB loses in both performance and ease of use to postgres in pretty much all scenarios.

I can recommend only one of those tools

Fuck whitespace senstive languages

Thanks @kiki I'll check out scrypt

@kiki ExpressJS does a lot. The HTTP module always had req and res. That’s where the “standard” came from. Besides helper functions, express offers (just off the top of my head):

View engines
Routing
Middleware
Cookie parsing
Body parsing

Some pretty useful stuff above the base module

@AlgoRythm I eliminated express in production, replacing it with http module, and saved a lot of ram & dev time

@kiki It could work for simpler projects, especially ones that don't serve static files or manage cookies etc. But express is more than just the jQuery of node. It has some very useful functionality. For example, how were you able to implement authentication / authorization? Was it a headache?

@AlgoRythm it was way easier than with express

@kiki well how did you do it

@AlgoRythm my entire server (without controllers, obviously), but with everything else: body parsing, sessions, routing, logging, error handling, cors — is just 192 lines, without any dependencies. Though I only accept JSON bodies and use authorization header instead of cookies. In production, I serve static with nginx. In dev environment, I use my own 17 lines static server that is good enough.
How did I do it? I cleaned my mind of preexisting assumptions, namely “you cannot just update DOM directly, you need React” and “node api is too low-level, express is the defacto standard” and just wrote code that solved the problem.

@AlgoRythm what is it that express does for authentication specifically?

@kiki Express sets up the middleware chain for you so that you can implement authentication at endpoint level without doing it manually each time. Since middleware is a chain, any step in it can fail and the request will be gracefully rejected. Auth, size limits, validations - even body parsing are all implemented one time, added once to the express application, and then automatically executed for each request. Or, only specific requests (depending on your routing, which I assume you did by hand too? Seems like it would be a tiny bit of a pain to write the route parameter mapping)

If you can accomplish everything you need with the stability and security you need in 192 lines - more power to you. But express is not a bloated piece of crap that thinly wraps default node APIs. It is a smart tool, battle-tested, with lots of clean features. It gets a bad rap because it's usually bundled as the back end of angular or react apps, which are bloated POS.

@AlgoRythm authentication is, basically:
1. Accept email and password
2. Return token, as set-cookie or otherwise
3. For every request, parse cookies/body, look for the token
4. Go to the place where you store sessions. For me, it’s Postgres
5. Check if the token is valid
6. Pass the session data into the controller that is being called

Because I don’t have express, my flow is absolutely linear and transparent. I execute session checker before controllers, so I know exactly what is passed into them. Also, my controllers return data instead of calling res.send
Helps to keep them linear

@AlgoRythm agree
I handle thighs gracefully too: because controllers are linear functions that return values instead of calling callbacks, wrapping my entire router into try-catch will catch everything

@kiki Well it seems like you have your own system in place. My heart does go out to you when it comes to routing requests to controllers, especially if you're using RESTful route params, but if you truly want to avoid express, there's no reason to use it. I just assert that there's no pressing matter that should make you avoid it either. As far as node modules go, I find it one of the most respectable.

@AlgoRythm the main reason I ditched express was its magic. I do not understand middleware execution order, and I ate a lot of shit trying to make it work properly with stripe or otherwise. I also don’t like the idea of top-level code calling functions like app.get() that define controllers. I use es modules on the backend instead of cjs, and I don’t like that I can’t sort imports that are supposed to be sortable, because import order influencers how my app works.
Now, every external file I have is a proper es module that calls nothing on the top level. It’s just a collection of functions. Nothing gets executed when you import a file.
I pass everything controllers need as an object, including every external api my app uses.

@AlgoRythm routing? Mine is
… a lot of ifs
if (method === “GET” && url === “/foo/bar) return fooBarController
… a lot of ifs

If I need params, I use startsWith and parse the url inside the controller
So far so good. You can always make api schema simpler, no need for all that pattern matching express has

@kiki one of the reasons I’ve moved away from expressjs and nodejs backends was because of the growing pains associated with being a long-lived JavaScript runtime (&library).

Remember that when node came out, promises were just a little sparkle in the eye of the standard writers. Async JS used callbacks, thus, callback hell. And of course CommonJS was a solution born to fail. NodeJS couldn’t introduce non-canonical syntax, but the standard had not yet defined vanilla modules. These two things have caused a lasting mess, and it shows in many codebases unfortunately.

@AlgoRythm I had the luxury of building things from scratch knowing it may only work on the newest node version

@kiki Frankly, I bet if Node.JS came out today and we only started writing all the NPM modules anew using current standards, it would be much less of a laughing stock.

It's a little bit of a catch-22, though, because I do think that ES modules turned out the way they did because of CommonJS. So the egg indeed needed to come before the chicken.

@kobenz we found him guys. Thats the guy. Get em!